Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Ansible vs. Chef - which is better?
New on LowEndTalk? Please Register and read our Community Rules.

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?

aglodekaglodek Member
edited January 2015 in General

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?

And on a side note, a little popularity contest...
  1. Which one do you use to manage your inventory?20 votes
    1. Ansible
      50.00%
    2. Chef
      10.00%
    3. Puppet
      10.00%
    4. Own Bash scripts
      20.00%
    5. Another tool (please elaborate in comments)
      10.00%
«1

Comments

  • Played with both, preferred saltstack.

  • @bookstack said:
    Played with both, preferred saltstack.

    Same.

  • @bookstack said: Played with both, preferred saltstack.

    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++

    Thanked by 2aglodek NodePing
  • 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.

    Thanked by 1aglodek
  • We recently switched from Chef to Saltstack because of ease of learning for engineers and speed of deployment.

    Thanked by 1aglodek
  • @outime said:
    Same.

    Agreed.

  • outimeoutime Member
    edited January 2015

    I'll give some arguments for SaltStack.

    @etcSudoers said:
    I like Ansible because it's all SSH driven.

    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.

    @rawrwriter said:
    Ansible.
    Its just easy to get started with.

    SS as well. There aren't many terms to learn in my opinion plus the walkthrough is quite intuitive. Syntax is really easy.

    @rawrwriter said:
    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.

    You can do that in SS also.

    @rawrwriter said:
    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.

    And in SS too! salt '*' cmd.run "echo 'Hello world'".

    Thanked by 1aglodek
  • Ansible all the way.

    Thanked by 1aglodek
  • Awmusic12635Awmusic12635 Member, Host Rep

    I prefer puppet myself.

    Thanked by 1aglodek
  • 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.

    • Salt doesn't seem to force any particular directory structure onto you, something I don't really like that ansible does.
    • It seems if you do decide to go the agent route, salt can be imported and used by python scripts on the minion which is very cool.
    • Salt runs its minions as root, Not a terrible problem since ansible requires passwordless sudo on its account but still eh
    • Ansible docs leave something to be desired in my opinion.

    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 :)

    Thanked by 2outime aglodek
  • 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.

    Thanked by 1aglodek
  • I still prefer ASYD.

    Thanked by 1aglodek
  • SilvengaSilvenga Member
    edited January 2015

    outime said: Same.

    Same, infinitely better community, better docs, not to mention a lot more built in mods than Ansible.

    rawrwriter said: Salt runs its minions as root, Not a terrible problem since ansible requires passwordless sudo on its account but still eh

    You can run as a non-root user: http://docs.saltstack.com/en/latest/ref/configuration/nonroot.html :D

    @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.

    Thanked by 1aglodek
  • @rawrwriter said: 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.

    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.

    Thanked by 1aglodek
  • smansman Member
    edited January 2015

    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.

    Thanked by 1aglodek
  • raindog308raindog308 Administrator, Veteran

    etcSudoers said: At work I use cfEngine -- They claim it's much faster because it's written in c/c++

    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.

  • @sman said:
    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.

    As I mentioned above, SaltStack works with SSH as well.

  • smansman Member
    edited January 2015

    @outime said:
    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.

  • aglodekaglodek Member
    edited January 2015

    @William said: I still prefer ASYD.

    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?

    @etcSudoers said: 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++

    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.

    @bookstack said: 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.

    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 ;)

  • bookstack said: deal breaker is instantiating a file from template with parameters

    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.

    bookstack said: You have to bootstrap the system anyway, whether it is set salt-minion or ssh private keys, it is inevitable.

    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.

    Thanked by 1aglodek
  • 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?

    It's certainly much easier to use and write deploys for it

    Thanked by 1aglodek
  • @sman said:
    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.

    Wrong. From Salt documentation (http://docs.saltstack.com/en/latest/topics/ssh/):

    In version 0.17.0 of Salt a new transport system was introduced, the ability to use SSH for Salt communication. This addition allows for Salt routines to be executed on remote systems entirely through ssh, bypassing the need for a Salt Minion to be running on the remote systems and the need for a Salt Master.

    Thanked by 1aglodek
  • 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.

    Thanked by 1aglodek
  • drserverdrserver Member, Host Rep

    We are using ansible on daily basis, however i like Chef more.

  • @drserver said: 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?

  • drserverdrserver Member, Host Rep

    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.

    Thanked by 2aglodek vimalware
  • @drserver said: 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"?

  • drserverdrserver Member, Host Rep

    @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...

    Thanked by 2aglodek vimalware
Sign In or Register to comment.