4 ms·

In my corporate environment, I've played a bit with Puppet. Ansible looks to cover much of the same ground. Are there any compelling reasons to use one over the

In my corporate environment, I've played a bit with Puppet. Ansible looks to cover much of the same ground. Are there any compelling reasons to use one over the other?

core-questions 7y ago
I'm deeply experienced with Chef and have been using Ansible for some newer projects. Plusses: - Supported Ansible modules are usually more reliable and more clearly defined in terms of how they'll function than community cookbooks for Chef are - Upgrades between versions go smoothly - People can just go read your YAML and figure out what it's going to do Minuses: - It's not code, so if you want to do something more programmatic, you're going to end up with something ugly compared to what you can do in Chef/Puppet's Ruby DSL - It's still a bit immature in terms of comparison to Chef's server offering (Ansible Tower is pretty useless), and the Kitchen/Vagrant/Serverspec stuff is also not as advanced. Ansible seems to fit well as a replacement for the Chef Zero use case of fire-and-forget provisioning - works well inside Packer or inside of Terraform via a null_resource, but I don't tend to find myself wanting to use it for long-lived machines that in the Chef world benefitted from continually running the cookbooks to help keep config in sync.
- BossingAround 7y ago
  > It's not code, so if you want to do something more programmatic, you're going to end up with something ugly If you need code, you're encouraged to write your own module (pure Python, typically) > Ansible Tower is pretty useless Why?
- chr15p 7y ago
  > It's still a bit immature in terms of comparison to Chef's server offering (Ansible Tower is pretty useless) Meh, I really like Tower, but maybe that depends on what you're used to. > It's not code, so if you want to do something more programmatic, you're going to end up with something ugly this is true, ansibles DSL has its limits and the developers are pretty clear that there are some things that are too complicated for its yaml based syntax. 99% of use cases its great for, if you want that extra 1% then you have to write your own ansible modules (which is actually reasonably straightforward). I dont know chef but puppet has become more and more complicated over the years chasing the more advanced use cases and in many ways thats moved it away from a tool for sysadmins towards a being a tool for specialists so I think Ansibles outlook makes more sense. YMMV.
  - core-questions 7y ago
    > I dont know chef but puppet has become more and more complicated over the years chasing the more advanced use cases and in many ways thats moved it away from a tool for sysadmins towards a being a tool for specialists so I think Ansibles outlook makes more sense. YMMV. Yeah, I concur. There aren't too many cases where I can't work around the lack of programmability with some creative templates or what-have-you. (I wonder if I could render an Ansible task file from a template and then include it...)
    - snorkasaurus 7y ago
      Maybe I'm missing something, but I've got a lot of mileage out of custom Ansible modules and callback plugins. Maybe that's what you're looking for.
      - core-questions 7y ago
        Learning Python is never going to be something I'm looking for. Too much brainpower invested in Ruby now to switch...
- mobilemidget 7y ago
  They both work okay I guess, but I'm still unsure at what number of machines these kind of configuration tools are worth the overhead.
BossingAround 7y ago
They do different things. Puppet takes care of configuration drift, and makes sure that nothing you code into puppet changes. Ansible is more like a readable bash on steroids. It's basically a way to distribute and execute Python code into other machines. Unless you have AWX (Tower), or create a custom repeatable delivery, it won't take care of config drift. Overall, Ansible is much easier to write and understand. It's an extremely powerful tool. Puppet doesn't have any amazing advantages or disadvantages over Ansible (except of the simplicity, which is a large benefit for Ansible).
liveoneggs 7y ago
puppet masterless is basically the same but ansible is more popular
chr15p 7y ago
THey have slightly different sweet spots, puppet is really good for fixing configuration drift, run it every 30 mins and you know the server will always be in the state you expect. Ansible tends to be better for jobs you do when a sysadmin wants them done, its really good for scripting repeatable installations, or for doing updates in a consistent fashion on hundreds of machines, adding new users to a bunch of different applications, etc etc. You can use puppet for ad-hoc jobs, but its not really designed for that it tends to be overly complicated and a bit awkward (imho). You can do drift re-mediation with ansible and run it every 30 mins to fix issues and it will work but its not its real sweet spot. Personally I would use ansible for both use cases because its simpler, I understand it, and it has a more sysadmin way of thinking, but I know places that use both and that makes sense as well.
closeparen 7y ago
Puppet is declarative, Ansible is procedural. You may find Puppet obtuse if all you want is one time provisioning of new hosts. Sometimes you do care about procedural concerns like execution order, and in Puppet you have some influence (e.g. dependency relationships) but not direct control. You may find Ansible backs you into corners with long lived mutable infrastructure. Configurations may drift, and your ability to run a playbook may depend on the sequence of playbooks previously run on the target. Ansible doesn’t really have a notion of converging on a goal state; it’s closer to scripting. You can have a single idempotent playbook that you run every time, but it’s not opinionated about that.
thyrsus 7y ago
A big difference in our environment is that when puppet encounters a failure, it keeps going with everything that doesn't have an explicit dependecy on the failed resource. When ansible encounters a failure, it stops dead (of course, you can override that for specific tasks with "failed_when: false"). If you want the flexibility to choose what to fix next, you want puppet. In my arguably understaffed environment, it's useful to be able to say: "no, we can't do that yet, we must fix this first." Things end up cleaner.

In my corporate environment, I've played a bit with Puppet. Ansible looks to cover much of the same ground. Are there any compelling reasons to use one over the other?

core-questions 7y ago

I'm deeply experienced with Chef and have been using Ansible for some newer projects. Plusses: - Supported Ansible modules are usually more reliable and more clearly defined in terms of how they'll function than community cookbooks for Chef are - Upgrades between versions go smoothly - People can just go read your YAML and figure out what it's going to do Minuses: - It's not code, so if you want to do something more programmatic, you're going to end up with something ugly compared to what you can do in Chef/Puppet's Ruby DSL - It's still a bit immature in terms of comparison to Chef's server offering (Ansible Tower is pretty useless), and the Kitchen/Vagrant/Serverspec stuff is also not as advanced. Ansible seems to fit well as a replacement for the Chef Zero use case of fire-and-forget provisioning - works well inside Packer or inside of Terraform via a null_resource, but I don't tend to find myself wanting to use it for long-lived machines that in the Chef world benefitted from continually running the cookbooks to help keep config in sync.

BossingAround 7y ago
> It's not code, so if you want to do something more programmatic, you're going to end up with something ugly If you need code, you're encouraged to write your own module (pure Python, typically) > Ansible Tower is pretty useless Why?
chr15p 7y ago
> It's still a bit immature in terms of comparison to Chef's server offering (Ansible Tower is pretty useless) Meh, I really like Tower, but maybe that depends on what you're used to. > It's not code, so if you want to do something more programmatic, you're going to end up with something ugly this is true, ansibles DSL has its limits and the developers are pretty clear that there are some things that are too complicated for its yaml based syntax. 99% of use cases its great for, if you want that extra 1% then you have to write your own ansible modules (which is actually reasonably straightforward). I dont know chef but puppet has become more and more complicated over the years chasing the more advanced use cases and in many ways thats moved it away from a tool for sysadmins towards a being a tool for specialists so I think Ansibles outlook makes more sense. YMMV.
- core-questions 7y ago
  > I dont know chef but puppet has become more and more complicated over the years chasing the more advanced use cases and in many ways thats moved it away from a tool for sysadmins towards a being a tool for specialists so I think Ansibles outlook makes more sense. YMMV. Yeah, I concur. There aren't too many cases where I can't work around the lack of programmability with some creative templates or what-have-you. (I wonder if I could render an Ansible task file from a template and then include it...)
  - snorkasaurus 7y ago
    Maybe I'm missing something, but I've got a lot of mileage out of custom Ansible modules and callback plugins. Maybe that's what you're looking for.
    - core-questions 7y ago
      Learning Python is never going to be something I'm looking for. Too much brainpower invested in Ruby now to switch...
mobilemidget 7y ago
They both work okay I guess, but I'm still unsure at what number of machines these kind of configuration tools are worth the overhead.

BossingAround 7y ago

They do different things. Puppet takes care of configuration drift, and makes sure that nothing you code into puppet changes. Ansible is more like a readable bash on steroids. It's basically a way to distribute and execute Python code into other machines. Unless you have AWX (Tower), or create a custom repeatable delivery, it won't take care of config drift. Overall, Ansible is much easier to write and understand. It's an extremely powerful tool. Puppet doesn't have any amazing advantages or disadvantages over Ansible (except of the simplicity, which is a large benefit for Ansible).

liveoneggs 7y ago

puppet masterless is basically the same but ansible is more popular

chr15p 7y ago

THey have slightly different sweet spots, puppet is really good for fixing configuration drift, run it every 30 mins and you know the server will always be in the state you expect. Ansible tends to be better for jobs you do when a sysadmin wants them done, its really good for scripting repeatable installations, or for doing updates in a consistent fashion on hundreds of machines, adding new users to a bunch of different applications, etc etc. You can use puppet for ad-hoc jobs, but its not really designed for that it tends to be overly complicated and a bit awkward (imho). You can do drift re-mediation with ansible and run it every 30 mins to fix issues and it will work but its not its real sweet spot. Personally I would use ansible for both use cases because its simpler, I understand it, and it has a more sysadmin way of thinking, but I know places that use both and that makes sense as well.

closeparen 7y ago

Puppet is declarative, Ansible is procedural. You may find Puppet obtuse if all you want is one time provisioning of new hosts. Sometimes you do care about procedural concerns like execution order, and in Puppet you have some influence (e.g. dependency relationships) but not direct control. You may find Ansible backs you into corners with long lived mutable infrastructure. Configurations may drift, and your ability to run a playbook may depend on the sequence of playbooks previously run on the target. Ansible doesn’t really have a notion of converging on a goal state; it’s closer to scripting. You can have a single idempotent playbook that you run every time, but it’s not opinionated about that.

thyrsus 7y ago

A big difference in our environment is that when puppet encounters a failure, it keeps going with everything that doesn't have an explicit dependecy on the failed resource. When ansible encounters a failure, it stops dead (of course, you can override that for specific tasks with "failed_when: false"). If you want the flexibility to choose what to fix next, you want puppet. In my arguably understaffed environment, it's useful to be able to say: "no, we can't do that yet, we must fix this first." Things end up cleaner.