Howdy, Stranger!

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

Sign In with OpenID
Advertise on LowEndTalk.com

In this Discussion

Ansible vs. Chef - which is better?

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?18 votes
    1. Ansible
      44.44%
    2. Chef
      11.11%
    3. Puppet
      11.11%
    4. Own Bash scripts
      22.22%
    5. Another tool (please elaborate in comments)
      11.11%
Andrew Glodek | Special Projects Director | 香港國際商務中心 HONG KONG INTERNATIONAL BUSINESS CENTRE

Comments

  • Played with both, preferred saltstack.

    My site, powered by Netlify and Let's Encrypt.

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

    Same.

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

    Okay, why?

    Andrew Glodek | Special Projects Director | 香港國際商務中心 HONG KONG INTERNATIONAL BUSINESS CENTRE
  • 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.

    Yourserver.se — Linux SSD servers in Sweden and Latvia

    Thanked by 1aglodek
  • @outime said: Same.

    Agreed.

    Arbi O. OneHopWeb.com Jump To Success - Shared, Reseller, LiteSpeed CloudLunux Hosting

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

    I recommend Prometeus, the best provider ever!

    Thanked by 1aglodek
  • Awmusic12635Awmusic12635 Member, Provider

    I prefer puppet myself.

    Subnet Labs, LLC Contact Us Deploy to: Seattle, Dallas or NYC
    Impact VPS | Cloud Servers | Storage Servers | Impact Shared | Shared Hosting

    Thanked by 1aglodek
  • outime said:

    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
  • WilliamWilliam Member, Provider

    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.

    Andrew Glodek | Special Projects Director | 香港國際商務中心 HONG KONG INTERNATIONAL BUSINESS CENTRE
  • 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.

    My site, powered by Netlify and Let's Encrypt.

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

    My Advice: VPS Advice

    For LET support, please click here.

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

    Andrew Glodek | Special Projects Director | 香港國際商務中心 HONG KONG INTERNATIONAL BUSINESS CENTRE
  • 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
  • WilliamWilliam Member, Provider

    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, Provider

    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?

    Andrew Glodek | Special Projects Director | 香港國際商務中心 HONG KONG INTERNATIONAL BUSINESS CENTRE
  • drserverdrserver Member, Provider

    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"?

    Andrew Glodek | Special Projects Director | 香港國際商務中心 HONG KONG INTERNATIONAL BUSINESS CENTRE
  • drserverdrserver Member, Provider

    @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
  • @drserver said: for example, our new management portal will use chef to clear firewall rules, change root pw, install custom software from playbook and so on...

    Nice :) Exactly my idea for a couple of SAAS projects I'm working on ;)

    Andrew Glodek | Special Projects Director | 香港國際商務中心 HONG KONG INTERNATIONAL BUSINESS CENTRE
    Thanked by 1drserver
  • rawrwriter said: 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.

    No, I am not talking about passing the global parameters in the runtime. And I am against this practice, all information should be checked in somewhere including the secrets.

    I am talking about the task to instantiate a file from the template, like setting up the nginx:

    - name: "set up /etc/nginx/sites-enabled/{{ app_role }}.conf" sudo: true action: template src=nginx.jinja2 dest=/etc/nginx/sites-enabled/{{ app_role }}.conf notify: restart nginx tags: - nginx

    The app_role and all the variables in nginx.jinja2 must be setup before ahead, you can not pass arbitrary key/value pairs to run this command. It is very awkward.

    Also the developer of ansible might be rude.

    My site, powered by Netlify and Let's Encrypt.

  • smansman Member
    edited January 2015

    aglodek said: preferable

    @outime said:

    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.

    That doesn't look the same to me. There are a bunch of however's, what have you's, exceptions, cannot yet do's, special configurations etc. Looks like something they bolted on to try compete with Ansible but it's not fully baked yet.

    Ansible just uses the operating system SSH keys so if you do that now you have zero additional config required and zero limitations.

    Thanked by 1aglodek
  • Follow up question: what are the minimum system requirements to run:

    • Ansible
    • SaltStack
    • Chef
    • ASYD

    To be clear, I'm not looking to break any records here, but rather for recommended stable, production system minimum. Will a 128MB KVM cut it?

    Andrew Glodek | Special Projects Director | 香港國際商務中心 HONG KONG INTERNATIONAL BUSINESS CENTRE
Sign In or Register to comment.