Opinions: Ansible vs. SaltStack
-
@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
-
I think SS works better under Windows, especially the ready modules for RDP/local group policy, and the installer, so they are targeting that better.
-
@tim_g said in Opinions: Ansible vs. SaltStack:
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
I didn't find this article particularly useful.
-
I do realize this is an OLD post (relatively speaking) but I appreciate(d) finding it, as I'm currently revisiting "Salt vs. Ansible," and while I thought I was leaning towards Salt, perhaps it might be Ansible instead at this point. Not yet settled.
Nothing needs to be used, anything that is used will be primarily to ease my job of administering - primarily - client machines. (Currently not rolling out enough Linux (or Windows for that matter) servers to be considering a/ny config mgmt system - at this time).
Most sites have or can have a linux vm that I setup and maintain.
My need is for one mgmt tool that is: Viable for Windows and Mac OS endpoint management, and for simple basic (check for and) application of system updates, both fit the bill.Security is also (especially, as we all know) not at all a non-factor.
I do like that as of now - with the current build of Windows 10, ssh(d) is included.
And I hope to use a setup that will work over ssh, with client-nodes limiting connections (from source IP) by firewall, and ssh config limiting connections to/by key only.
I know that the default config of OpenSSH in Windows uses
"C: \ProgramData\ssh\administrators_authorized_keys"for said config, I have yet to verify if the MS-included (Apps > Optional Features) sshd uses the same.
-
@David_CSG said in Opinions: Ansible vs. SaltStack:
My need is for one mgmt tool that is: Viable for Windows and Mac OS endpoint management, and for simple basic (check for and) application of system updates, both fit the bill.
This is exactly why I am heavily testing out Ansible with @stacksofplates and @IRJ slapping me in the back of my head continuously.
