I went the other way around instead, from salt(-ssh) to Ansible. I could not bear the slow speed though, so I suggest everyone who hasn't tried yet to use it with Mitogen. I don't think I will ever go back and in fact I expect upstream to eventually adopt it.<p>Major issues with Salt: lots and lots of bugs and quirks. I have had my fair share of those in Ansible over the years as well, but Salt is just not good enough for my taste. A strong NIH is perceived all over its design.
What people don't get about salt, is that its literally kubernetes (as in orchestrator) for your infrastructure.<p>It takes the "operator" concept to a very new level:
You can tell it to react automatically and enlarge a disk in a machine due to space constrains, reschedule workloads according to load, configure a loadbalacner according to rules you write once, create resiliency rules, deploy new machines or containers...<p>It scales ridiculously, i have seen 30000 minions to a master.<p>Why you would use it via ssh other than bootstrapping is beyond me...<p>btw: you can run ansible via the salt bus transport = salstack in the ansible.cfg, be amazed.
This seems like a <i>lot</i> of work for such a small problem in Ansible that can actually be fixed without any patches. Here's an example.<p><pre><code> - name: Pretend to install stuff.
debug: var=item
with_items: [git, httpd, vim]
when:
- "'all' in ansible_run_tags or item in ansible_run_tags"
- item not in ansible_skip_tags
tags: always
</code></pre>
If you run without any tags it will install everything and if you specify --tags=git it will only install git and if you specify --skip-tags=vim it will do the correct thing.<p>Ref: <a href="https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html" rel="nofollow">https://docs.ansible.com/ansible/latest/reference_appendices...</a><p>And in the specific case of installing packages you can speed this process up dramatically with something like the following without having to use tags.<p><pre><code> - name: Probe the host for installed packages.
package_facts:
- name: Install packages.
package: name={{ item }}
with_items: [git, httpd, vim]
when: item not in ansible_facts.packages
</code></pre>
But this itself is really inefficient too because you're still calling the module for every package instead of calling the module once with all the packages. Older versions of Ansible did this automatically but it was super magic so it's probably better that it was removed. We can do it ourselves though.<p><pre><code> - name: Install packages.
package: name={{ to_install }}
vars:
packages: [git, httpd, vim]
to_install: "{{ packages | difference(ansible_facts.packages) | list }}"</code></pre>
The author's example of using loop data out of loops is overlooking anchors and aliases in YAML. His example can be rewritten as:<p><pre><code> - hosts: all
tasks:
- name: Install distro packages
package:
name: "{{ item }}"
state: present
with_list: &packages
- git
- htop
tags: *packages</code></pre>
Isn't it possible to create many small playbooks, instead of a big one. This would allow you to just run the stuff you need. And if you need all e.g. for bootstraping then you can create one playbook that simply includes the smaller ones with the import_playbook statement. This also gives you the flexibility to create other subsets based on your needs.
Regarding VMware buying SaltStack, it is a good thing, Tom will have more time to code, according to TheHacks podcast episode about it at <a href="https://www.saltstack.com/the-hacks/" rel="nofollow">https://www.saltstack.com/the-hacks/</a> that I usually listen from page <a href="https://thehacks.libsyn.com/" rel="nofollow">https://thehacks.libsyn.com/</a> .<p>From other podcast episodes I got to know that they at SaltStack are currently merging those many differently maintained SaltStack repos together to less repos, so it will make progress faster.<p>Disclaimer: I do not work at SaltStack. I just happily listen to their podcasts and I have used SaltStack for managing my servers.
You lost me when you when the author failed to properly understand how to use {{ item }} by defining with_items:<p><a href="https://www.educba.com/ansible-with_items/" rel="nofollow">https://www.educba.com/ansible-with_items/</a><p>Let me fix his code here:
<a href="https://pastebin.com/PQDAnHiJ" rel="nofollow">https://pastebin.com/PQDAnHiJ</a><p>I use with_items at least once a day in this manner.
The main reasons I started using Ansible in 2013 were its agentless setup (which this article covers nicely) and its --check --diff options (which this article leaves out). Does salt have a do-nothing sanity check mode?
As it happens, I moved from Ansible to Chef not too long ago as my provisioner of choice.<p>It can be used with just SSH and Chef Zero (no need for a Chef Server), and it's built with Ruby and Chef's DSL and not YAML.<p>It took me several years to not hate Chef's approach, though, compared to the ease of use of Ansible.
Hm as others mentioned it is possible to use Ansible in a very "usual" way to solve this problem.<p>I would love if we standardize in Packer, Ansible and Terraform. Luckily it seems like the devops world is standardizing in this stack ... there's very little you can't do in an elegant way using those 3 tools (only use the 3 if you need, a lot of shops only use Ansible for example)
Slightly OT:<p>I have recently done some scripting work on a single machine and used Ansible because it makes it so convenient to parse output, generate config files etc., mostly shell and jinja2<p>Is that valid use of Ansible or should I be ashamed and use something else?
I fondly remember CFengine. Though it did require installation on the host to be managed, but that seemed rather simple: Log in, install CFengine and git, clone the repo, and off you go to run it.
I like the look of the file.keyvalue. Anything like that in ansible?
<a href="https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html" rel="nofollow">https://docs.saltstack.com/en/latest/ref/states/all/salt.sta...</a>