All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Ansible vs. Chef - which is better?
I'm taking a real close look at both Ansible and Chef. While at it, interested in hearing from people who have had hands-on experience with both and then settled on one of them - which one and why (i.e. which feature(s) won you over)?
I'm looking to automate sysadmin tasks on my inventory (at present about 30 VM's, but expecting this to grow into hundreds). In addition to mundane sysadmin tasks like OS and apps hardening, automated upgrades and the like, I'm also interested in hi-end solutions like:
managing dynamic inventory (creating boxes on the fly with providers like DO)
playbooks/cookbooks automating responses to triggers (server monitors)
automating building and managing nodes with KVM's, OpenVZ or LXC containers
playbooks/cookbooks with different levels of access (different tasks accessible to different assistants/sysadmins)
Which one - Ansible or Chef - is better suited to meet the aforementioned needs?
- Which one do you use to manage your inventory?20 votes
- Ansible50.00%
- Chef10.00%
- Puppet10.00%
- Own Bash scripts20.00%
- Another tool (please elaborate in comments)10.00%
Comments
Played with both, preferred saltstack.
Same.
Okay, why?
I like Ansible because it's all SSH driven.. but the syntax is awful IMO. At work I use cfEngine -- They claim it's much faster because it's written in c/c++
Ansible.
Its just easy to get started with.
Use shell scripts already?
Then you can use the script module to run them in parallel across multiple servers while you transition newer tasks to be fully ansible based.
Just need to run a single command? then
ansible all -m shell -a "echo 'Hello world'"
will run it on every server in your inventory.
Someone posted a 50% off code to Ansible for Devops a few days ago, Its well worth the money in my opinion so try that.
We recently switched from Chef to Saltstack because of ease of learning for engineers and speed of deployment.
Agreed.
I'll give some arguments for SaltStack.
SaltStack supports SSH since 0.17.0: http://docs.saltstack.com/en/latest/topics/ssh/ it's true that it was a notable difference between Ansible and SS but not anymore. Plus I like the master-minion approach more because of the performance - however if you don't have a big pool of servers (>100) to deal with then it shouldn't matter that much.
SS as well. There aren't many terms to learn in my opinion plus the walkthrough is quite intuitive. Syntax is really easy.
You can do that in SS also.
And in SS too!
salt '*' cmd.run "echo 'Hello world'"
.Ansible all the way.
I prefer puppet myself.
hmm, I went with ansible to start since I didn't want to use a minion based system.
That being said a quick look at the saltstack docs and they seem to be very similar, Both using python and YAML.
We have started to use ansible where I work, switching from chef, so I'll end up with more experience with it but I think you might have just won me over a bit.
Damn you for making such good points
Used cfengine, ansible, and chef - in that order.
Of the three, Ansible's probably the easiest and straightforward if you want to transcribe existing human-readable playbooks to code. It was lacking secret control though when I used it, but I think that's fixed with Vault.
Chef is more composable as I find myself using other people's cookbooks (especially os and ssh hardening) more often as part of the stack. My Ansible experience was very NIH and involved a lot of frustrating cutting and pasting. You get more control and assurances of things not changing from under you but you're now responsible for the entire lot. Chef is vulnerable to regressions on other people's code or baseimage, but the entire ecosystem developed kitchen, version pinning, and testing with ServerSpec to minimize the OMG moments.
I also ended up using Chef with knife-zero, which basically operates like Ansible in that there's no longer a full standup Chef Server. Instead, my machine connects out, reverse proxies a fake Chef Server (zero) and have the remote clients connect to that stub. On days where I need something that responds more dynamically using Chef search, I stand up an actual Chef Server. The flexibility and test assurance is pretty much why I haven't gone back to Ansible - although I miss it if I want to hack something together fast.
I still prefer ASYD.
Same, infinitely better community, better docs, not to mention a lot more built in mods than Ansible.
You can run as a non-root user: http://docs.saltstack.com/en/latest/ref/configuration/nonroot.html
@aglodek, this could be an interesting read, a comparison through experience: http://ryandlane.com/blog/2014/08/04/moving-away-from-puppet-saltstack-or-ansible/
I personally like the metaphors in Salt. You create a state for a server and you have the minion maintain it. I can have a VPS ready and normalized as soon as it connects to the "swarm" automagically.
Already bought it Staring out, this book and a few tutorials I've come across are a big push in favor of Ansible. On the other hand, Chef seems to have more recipies ready to go.
First I heard of Saltstack here (thanks to all who have commented on it). I'll be sure to give it a closer look. This said, I like Ansible's centralized philosophy, as opposed to the master-minion approach.
There are multiple reasons why I prefer saltstack over ansible, but essentially it is all about the DSL languages.
ansible takes the chef approach: the deployment is a series of commands; while the saltstack takes the puppet approach: the deployment is migration of the states. I think the latter makes more sense.
Also ansible takes the ruby approach: convention over configuration. The fact, variables, templates, command, metas are scatter in different folders, and it is quite annoying.
The deal breaker is instantiating a file from template with parameters. You can not feed the parameter in the task, it has be to fed via the variables file. And my colleague uses the duplicated roles to provision several service with one role, it is just pain of a** to modify a simple text file.
I did not see the ssh access is a big win for ansible. You have to bootstrap the system anyway, whether it is set salt-minion or ssh private keys, it is inevitable.
The only people who seem to like Chef are people who already know how to code in Ruby imho.
I specifically DON'T like it because of that. If it was Python I would probably be a much bigger fan.
I like Ansible because it just uses SSH with no additional software required. Since I already do everything over SSH it's a natural fit. Not a fan of YAML though or the way stuff tends to get spread out between different files.
It also runs in something like 30 bytes.
I exaggerate but it requires extremely little memory, and its overall model of opportunistic network and promises is excellent. It's also been around for a long time.
As I mentioned above, SaltStack works with SSH as well.
You need to set up the whole master minion thing. So while it may be able to talk over SSH, that's not quite what I meant. I haven't used Saltstack but I plan to give it a try one of these days. I don't mind having to set up a master.
The documentation seems to be improving and I think that was Saltstacks biggest problem compared to Ansible.
Okay, first I heard of it, but took a quick look and looks interesting (like the others). What features make it preferable for you, William?
Took a look at cfEngine a year or two back and quickly forgot about it. Very complicated going in or maybe that's just me Having no experience with (yet!), can't speak for Ansible's syntax or structure, but at first glance the logic of it all makes a lot of sense to me.
It was my understanding you could also run Ansible commands on remote servers using passwords? Please correct me if I'm wrong...
This said, you make a good point. I'm still not a fan of the master-minion concept, but this discussion has made me look at this with a more open mind
This can be done if I'm reading you right.
ansible --ask-pass blah.yml --extra-vars "blah=blah" --extra-vars "{'list_of_blah': [1,2,3]}"
as an example.
Yeah you do, but as @aglodek said you can use a password from the command line and I think its best practice to have a single playbook that bootstraps the server.
I used signed keypairs so its easy, I just add my user, setup passwordless sudo and modify sshd_config to reject root and only accept my CA.
This is nice and quick and you only have to enter the password once before the server is secure.
Link to the playbook if you are interested
Don't run it on your server without changing it though, it'll lock you out.
It's certainly much easier to use and write deploys for it
Wrong. From Salt documentation (http://docs.saltstack.com/en/latest/topics/ssh/):
I'm big on Chef. We use it to manage a few thousand hosts at work, and it does the job well. I agree it's a bit heavier than some of the other options out there, but the resources it offers are pretty thorough. Chef Solo is much lighter and can probably fill most people's needs, although I use Chef with a server for search, data bags, and basic asset tracking.
I didn't know any ruby before getting into Chef, and can say I'm pretty good at it now. I give Chef training at work and contribute to a few projects, so I'm pretty vested in it.
We also use Ansible in some areas, but mainly for the parallel execution, not really for the CM aspect.
We are using ansible on daily basis, however i like Chef more.
Why do you like Chef more? And why do you use Ansible then?
Ansible is ssh based and works great in ideal enviroment, for ecample when end user will not change ssh port. I am using it because i have all delpyments scripts written on it.
Later we have started using foreman on part of deployment. I liked agent approach. I also like integtation possibility of chef.
What exactly do you mean by this last: "integtation possibility of chef"?
@aglodek for example, our new management portal will use chef to clear firewall rules, change root pw, install custom software from playbook and so on...