Opinions: Ansible vs. SaltStack
-
Looking at system automation tools and Ansible and Salt are definitely the two that look the most interesting. I've worked with Chef and cfEngine quite a bit in the past and they are not what we are looking for. Salt and Ansible seem to be much stronger, forward looking options.
What do people like about each?
-
As you know, I have been using ansible lately and I must say I am really liking it a lot. It is very easy to get started with since it uses ssh. I had to make absolutely no change on my vms to start using it since I already had everything setup.
Its concepts of facts, playbooks, roles, vault and handlers have been easier to understand for me than the grains, pillars, states and runners though I do recognize I have only skimmed though saltstacks documentation.
-
I think you know mine. I've never used Salt. The thing that I find awesome with Ansible, is I can install Ansible with Ansible (and provision ansible-pull from push). I think the biggest plus for Ansible is the number of modules they have. 944 in this list http://docs.ansible.com/ansible/list_of_all_modules.html
They also have a new one that deals just with containers and no SSH. https://www.ansible.com/ansible-container
There is also an LXC module that will run commands in an LXC container from the host.
Tower is supposed to be open sourced this year. I've been using ansible-pull, but I'd like to switch back to push because I've lost the ability to run playbooks with things like tags easily. It also has awesome central auditing.
-
Plus the ansible-galaxy init function is awesome. No more manually making the directories and yml files for the roles.
-
@stacksofplates said in Opinions: Ansible vs. Salt:
Tower is supposed to be open sourced this year.
I was looking at that, any guess as to a time frame?
-
@scottalanmiller said in Opinions: Ansible vs. Salt:
@stacksofplates said in Opinions: Ansible vs. Salt:
Tower is supposed to be open sourced this year.
I was looking at that, any guess as to a time frame?
Someone on Reddit said they were talking with a dev and it was supposed to be the end of Q1, but I'm skeptical. I don't remember where I saw it on there.
I'm assuming it will be an upstream like all of their other products, so I don't know what it will and won't include also.
-
Q1 isn't for too much longer. Would be nice to get to really try it out.
-
@scottalanmiller said in Opinions: Ansible vs. Salt:
Q1 isn't for too much longer. Would be nice to get to really try it out.
Ya I have it here at home and it's really nice for the couple machines I've tested it on.
-
On my side I've used Ansible a bit just for a small activity - more of a test- just because the learning curve is smoother: Salt has a more enterprise approach since day-0, which is not something I was in search for at the time.
@scottalanmiller have you seen this? It is not the first time I listen to people who dislikes the community support on ansible.
Complains about community/support are not to be neglectable to me, when we talk about community supported SW.It is basically about the scale of your job: do simple/small things, even if a lot: go ansible, maybe slower but easier to start with and poke around. If performance is a major hit and/or you are going to run complex devoperated networks of servers then Salt is a better investment in the long run.
-
@matteo-nunziati interesting take. I wonder if the new Red Hat governance will change that?
I also have a certain affinity for Salt as one of the code contributors is a friend of mine.
-
One thing that I like about Salt is the agent model. No open ports for management, at all. Pure "reach out" for added security.
-
@matteo-nunziati I saw that post before, and actually commented on it. They aren't leveraging tags at all from what it seems like. A lot of people have a full run and then after the full run, if you're just doing CM, they set up tags for configuration.
It's also 3 years old using Ansible 1.6, and is now currently on 2.2. There were a lot of big changes going to 2. Ansible-pull wasn't as mature as it is now.
Like I've said other places, I don't put much stock in community complaints. The second one he mentions about the lib/library, I don't see why they should change the whole structure for that one person. If he is the only one that has complained, I don't see that as rude.
I don't think it's slow at all. I've run both Puppet and Ansible and they seem pretty comparable.
-
@stacksofplates said in Opinions: Ansible vs. Salt:
I don't think it's slow at all. I've run both Puppet and Ansible and they seem pretty comparable.
Not necessarily a good comparison, Puppet is one of the slow ones that Salt specifically was designed to address. Not saying Ansible is slow, I don't know. I just know that Salt was specifically designed to be fast because Puppet was so slow.
-
@scottalanmiller said in Opinions: Ansible vs. Salt:
@stacksofplates said in Opinions: Ansible vs. Salt:
I don't think it's slow at all. I've run both Puppet and Ansible and they seem pretty comparable.
Not necessarily a good comparison, Puppet is one of the slow ones that Salt specifically was designed to address. Not saying Ansible is slow, I don't know. I just know that Salt was specifically designed to be fast because Puppet was so slow.
I have seen it be really slow. I don't like saying one is faster than the other with anecdotal evidence, that's why I worded it that way. So with that said:
I've found Ansible to be faster in a lot of areas (again anecdotal). It also depends on how you're running. Pull is faster than push. I mistakenly said in another area it SSHs into the local machine, but it has a local connection that you specify. If you are doing push you still do the local machine with the local connection. You can also cache facts which speeds things up. My stuff checks in every 10 minutes and on a no change run it takes about 10-20 seconds, and we do all of our SCAP hardening with it. We don't really do users and groups, that's all through LDAP, but I have done it and it didn't seem slow at all.
-
tbh I think that speed really matters only after you scale a bit. having to administer a few tens of VM is not so influenced by speed. having to manage few hundreds is a different thing.
I've choosed ansible in the past because you have less stuff to learn at first and I prefer the no-agent approach (and usually I have an ssh connection open anyway). but my needs are really limited.
btw, zeromq is the fastest thing you can have in the python world, so if speed really matters, there is no other solution than salt.
-
I have different separate networks but each has a little less than 100 machines (physical and virtual) and they are all managed with Ansible. Even with full changes the playbooks take less than a minute.
Pipelining also drastically improves speed. You have to disable requiretty (which is arguable in its adding security anyway).
One thing that would be nice is central reporting for ansible-pull logs.
-
@stacksofplates Doesn't the use of tags allow for writing tasks that are not idempotent and this is not recommended?
-
@Romo said in Opinions: Ansible vs. Salt:
@stacksofplates Doesn't the use of tags allow for writing tasks that are not idempotent and this is not recommended?
They're still idempotent. But you just don't include the installation of the application if it's just configuration. You don't have to do that, and it might not save that much time.
However, its really nice for dev machines to make sure something is running properly.
-
learned a new English word today.
-
I found a more up to date (march of 2017) article doing a good SaltStack vs Ansible comparison.
https://www.upguard.com/articles/saltstack-vs-ansible-revisited
