Ansible seems to have more traction: https://www.google.com/trends/explore#q=ansible%2C%20saltsta...
Moving away from Puppet: SaltStack or Ansible?
61–70 of 182 posts
Re: Moving away from Puppet: SaltStack or Ansible?
#62Does anyone have experience using Configuration Management software in a heterogeneous environment? For example, I've seen large environments running Windows 2008/2008R2/2012/2012R2, various flavors and versions of Linux including Ubuntu Server, CentOS, SUSE, etc... What's the pretty? What's the ugly? I understand consolidation and standardization of operating systems is usually the best state to be in, but in a lot…
We are very heterogenous--something like 60/40 Windows/Linux split. Traditional Windows folks don't really use configuration management or even have any clue about it. Or at least that's my impression. I'm a Linux guy and have been fighting a one-man battle to CM-ize our infrastructure. I have no interest in using Microsoft's DSC on the Windows side (their brand-new CM-like solution in PowerShell) and something else…
>Traditional Windows folks don't really use configuration management or even have any clue about it.
That's a tad unfair, I could say just as easily say the same thing about some of the Linux admins I've worked (and interviewed) with but that's not taking the discussion down a constructive road.
CM/DSC methodology is about awareness of the technologies available. There are a lot of admins out there, regardless of OS expertise, who've never heard of it full stop. I learned about it whilst working as a developer in the banking sector 12 years ago but using eye-wateringly expensive tooling from the likes of IBM and CA.
We have a 65/35 Windows/Linux environment, I have for years wanted to "CM-ize" our environments but we have two different silos of scripts and tomfoolery that get stuff done, we have a lot of friction points because of this. But one of the problems with CM tooling such as Chef, Puppet, Ansible and Salt has been the lack of sane support for Windows. Puppet seems to be getting better at it compared to the other three contenders. For example handling reboots sensibly [0] (and you know how Windows loves its reboots, and in the right order after some MSI or MSU has executed).
There is also a somewhat blinkered world view with regards to Windows i.e. "yuk, windows, not touching that", and at the risk of offending some, it's snobbery and cargo-cultism. A lot of the young folks around here have probably never tried modern Windows server management, it ain't that bad these days. If you can be bothered to learn bash and all this clever stuff on Unix, you can get a handle on learning Windows config management with Powershell which is very bloody good now.
The result is that we have silos of C/VBscript and Powershell code that go and built Windows environments in their own special Windows way because previously tools such as Chef, Ansible et al and their respective development teams don't (rightly but mostly wrongly) don't see any value in Windows support.
I speak as a platform agnostic devops person who has to live in both worlds and has supported Windows and Linux/Unix for longer than most of you have been alive :)
Re: Moving away from Puppet: SaltStack or Ansible?
#63We are moving from puppet to salt and I'm half way through and so far my git commits looks like this over the past month
puppet repo -14000 lines salt repo +1600 lines
What it really comes down to is salt has a ton of built in modules while puppet the old way to do it was add it as a module in your main module search path which for us was in our repo
Re: Moving away from Puppet: SaltStack or Ansible?
#64Salt all the way. We moved digedu's highly distributed infrastructure from puppet to salt and couldn't be happier with salt-cloud, salt-master, salt states, pillar and jinja.
Re: Moving away from Puppet: SaltStack or Ansible?
#65We've been very happily trucking along with Ansible the past year or so over here at Front Row. Tried Chef for a few weeks, hated every moment of it, switched to Ansible and it all made complete sense.
For us Ansible takes care of configuring the various types of machines we have in AWS, of building, testing and deploying binaries, of configuring and keeping our development environments in sync and more.
It's pretty exciting that the project keeps getting better with every version.
Re: Moving away from Puppet: SaltStack or Ansible?
#66Earlier quoted context omitted.
Yep. I understand that, but part of having an open source project is that others may find open bugs and decide to fix them because they're also having the same issue. Closing legitimate bugs hides them from the world and also gives people the impression that it's not something to fix. The performance issue was very likely one of the more major deciding factors. Managing users was so slow that it was painful to do sma…
I think it's something that can be improved, yes. I'm not sure it's a bug, and I'm not sure it's really all that slow. We're talking about 0.5 seconds and maybe it could get down to 0.4? If you dig into the module I'm not sure what you would change. (Again, a fine discussion for ansible-devel probably? How would you solve it?) In your case, managing a list of 80 users to be sure there or not, I might have suggested p…
As a comparison, Salt checks the users, groups, ssh keys, etc. in under 1 second. Ansible to do the same set of actions was taking nearly 2 minutes. This was just to check, not even to take action.
So, yeah, the majority of time in an initial run is waiting on apt/yum, when nothing is changing the majority of the time is spent on checking things.
When you're making config management a part of your application's deployment process, waiting on checking is painful. This would have added 2 minutes to deployment time. When we doubled the number of users managed it would add 4. That's a really, really long time.
Re: Moving away from Puppet: SaltStack or Ansible?
#67Earlier quoted context omitted.
In this specific case I submitted a bug and was told the bug wasn't valid and it was closed. After I pointed out why this was in fact a valid bug, the bug wasn't reopened, but instead left closed while I was told "you're welcome to submit a PR". Basically I'm being told the bug isn't important enough for the upstream to fix and that they care so little about the bug that they won't even leave it open for someone othe…
> In this specific case I submitted a bug and was told the bug wasn't valid and it was closed. Maybe that is what you might have said in your blog post instead of a snarky comment. Remember, many people in open source are not from the upper middle class United States / West Coast and will likely not pick up on clever passive aggressive jabs. I completely understand that they are great for being able to deny any accou…
It wasn't meant as snark or passive aggressive. It's a common topic in open source projects, but it's possible that I was speaking towards an audience that already knows the topic. Sorry if I hadn't explained well, that's my failure.
Re: Moving away from Puppet: SaltStack or Ansible?
#68As someone who used Puppet for some years, went to Salt[1], then Ansible[2], I've setteled on POSIX sh[3],
1: http://git.uggedal.com/historic/states/
Re: Moving away from Puppet: SaltStack or Ansible?
#69Interesting article but the design of the site made reading it give me a headache. I recently also made a move as well, went from Chef to Ansible and I am really happy I did. Chef was a pain.
We're soon going to be evaluating various configuration management frameworks. Could you outline a few points why Chef was considered a pain?
My major pain point was the complexity of Chef Cookbooks in comparison to Ansible Playbooks. I could hardly wrap my mind around how to write my own Cookbooks after exploring some of the ones I used (Ruby, rbenv, Git, Nginx.) Another major thing for me at least was the documentation, it seemed like Ansible had better documentation to me vs Chef. Finally another thing was the product offerings of Chef vs Ansible. Chef has some paid versions that offer more features, whereas Ansible is feature complete for free and they offer a GUI and Support instead which I preferred.
Re: Moving away from Puppet: SaltStack or Ansible?
#70It's unfortunate that this article focuses on running the playbooks/salt states locally. The use of ssh by ansible was the killer feature for me. Configuring a remote cluster without requiring a persistent master. There are valid arguments for maintaining a persistent master, but it's just not in the cards sometimes. I know salt-ssh exists but it's still alpha, I look forward to seeing how it pans out and whether it…
I'll follow-up with a post about how we're working without a master. We need neither SSH, nor a master. We're very heavily using autoscaling, which makes SSH a no-go. Ansible has Tower for this, but it's proprietary. We /could/ use a salt master for autoscaling, but we prefer masterless in this situation because it scales better.
You might want to look at the new life cycle states: http://aws.amazon.com/blogs/aws/auto-scaling-update-lifecycl... . That should make it possible to bootstrap via SSH now. as to whether or not you'd want to.. That's another matter :)