6 ms·

If someone will rewrite this article as Ansible vs. Puppet I will not only buy you a beer but I will throw a parade in your honor.

movedx 11y ago
Puppet has pretty much all of the same problems. Deploying Ansible: - SSH - SSH keys - Git - CI - ... fin? Deploying Puppet: - Install the agent on every system (using Ansible, ironically) - Install a set of masters (need HA) - Install a message bus for mcollective (if this is still even a thing?) - Upgrade the agent on ALL of your hosts as and when there's an update or a security patch - Have an agent/process running on ALL of your hosts with root access to the box to execute any command a hacker managers to inject - ... oh you've installed Ansible? I'll stop now then.
- quicksilver03 11y ago
  The only way I deploy Puppet today is in masterless mode, having the manifests on a private BitBucket repository. You still have an agent to deploy, but at least it doesn't run all the time, and there's no master and no mcollective to complicate things.
  - brazzledazzle 11y ago
    Despite some warts I like Puppet a lot because it's simple while still providing some flexibility to use Ruby. I prefer Ruby over Python by a huge margin and while that would seem to make Chef ideal, at the end of the day Puppet is more approachable for people with zero to minimal experience developing.
  - movedx 11y ago
    I believe this to be the only way to run Puppet, yeah. I'm glad it's solving problems for you... that is ultimately all I care about at the end of the day.
- brazzledazzle 11y ago
  I'm surprised that Puppet is still moving forward with mcollective. It might have been state of the art a few years back but it just feels unwieldy now. The only time it's relatively easy to deal with is in their enterprise product. Obviously they have to make a living but I'm not sure choosing to make a key component easier in your paid product and leaving it as a pain in the ass for your open source project is the best thing for customers. It feels harder to find community support and discussion because only a small subset use it and/or understand it.
- vegardx 11y ago
  Nobody is deploying Puppet (or Chef for that matter) using Ansible. You bake it into the images, use bootstrapping or any number of other ways, like cloud-config. How do you deal with dynamic resources, like automatic scaling, in Ansible? You don't, because it can't. With Puppet and Chef you can actually deal with that. If you don't have a rigid routine for updating packages on your systems you shouldn't manage systems. Security will always be an issue, thinking that Ansible solves all issues is naive.
  - movedx 11y ago
    "Nobody is deploying Puppet (or Chef for that matter) using Ansible. You bake it into the images, use bootstrapping or any number of other ways, like cloud-config." How do you initially bake the original image? What installs Puppet or Chef on that original image? Is it Puppet or Chef? Can it boot strap its self? The answer is no. Something has to create that image and "bake in" the ingredients. Some people use Ansible for this. "How do you deal with dynamic resources, like automatic scaling, in Ansible? You don't, because it can't. With Puppet and Chef you can actually deal with that." But it can. You've clearly never tried, but instead made an assumption. I've used both Puppet and Ansible, at large government projects, and the Puppet approach was a complete nightmare. For your auto-scaling example, I would use Sensu to monitor load and fire off a CI job when that load met some criteria (say 90%+ CPU/network for ten minutes.) That CI job would clone our Ansible repository and call a relevant playbook for spawning more VMs, configuring them accordingly. How many it spawned would just be defined in a YAML file, updated via git if you so chose. It's beautifully simple. I'll say it again: none of these CM solutions are all-in-one magic bullets - they're platforms or frameworks to build on top of. With Ansible, I would build on top of it with dynamic inventories, custom modules for monitoring and auditing the run time, etc. I do this from my local machine without some monolithic cluster to manage or an agent on all my boxes running as root (or with root privileges - same difference) 24/7. "If you don't have a rigid routine for updating packages on your systems you shouldn't manage systems." We create immutable instances which are updated as and when required, launch those new instances, and have our LBs use the new instances, keeping the old ones up whilst connections fade away, then they're destroyed. What's so difficult about that? What's your point with this remark? "Security will always be an issue, thinking that Ansible solves all issues is naive." Er, I never said it did? ... what? It's security 101, in case you didn't know, to run as minimal amounts of software as possible to reduce the potential number of attack vectors. I can't remember the statistic directly, but when I did a cyber security course online via MIT, there was a statistic along the lines of: for every 1,000 lines of code, there's one bug and potentially, an exploit. The take away from this is: run as few services and software packages as possible to help reduce the number of attack vectors. On that note, are you arguing that running Puppet/Chef in a master/agent configuration does NOT introduce more services, and thus more code, to maintain, secure, patch, make resilient, keep up, etc? Are you also saying that Ansible's default mode of operation (push and run versus pull and run) over SSH is not more secure? If you believe the latter, than I believe, with all due respect, that it is you that should potentially not be managing systems (I didn't want to resort to what is clearly a personal attack, but hey, you made this a school playground to begin with ["If you don't have a rigid routine for updating packages on your systems you shouldn't manage systems."] - shrug) -M

movedx 11y ago

Puppet has pretty much all of the same problems. Deploying Ansible: - SSH - SSH keys - Git - CI - ... fin? Deploying Puppet: - Install the agent on every system (using Ansible, ironically) - Install a set of masters (need HA) - Install a message bus for mcollective (if this is still even a thing?) - Upgrade the agent on ALL of your hosts as and when there's an update or a security patch - Have an agent/process running on ALL of your hosts with root access to the box to execute any command a hacker managers to inject - ... oh you've installed Ansible? I'll stop now then.

quicksilver03 11y ago
The only way I deploy Puppet today is in masterless mode, having the manifests on a private BitBucket repository. You still have an agent to deploy, but at least it doesn't run all the time, and there's no master and no mcollective to complicate things.
- brazzledazzle 11y ago
  Despite some warts I like Puppet a lot because it's simple while still providing some flexibility to use Ruby. I prefer Ruby over Python by a huge margin and while that would seem to make Chef ideal, at the end of the day Puppet is more approachable for people with zero to minimal experience developing.
- movedx 11y ago
  I believe this to be the only way to run Puppet, yeah. I'm glad it's solving problems for you... that is ultimately all I care about at the end of the day.
brazzledazzle 11y ago
I'm surprised that Puppet is still moving forward with mcollective. It might have been state of the art a few years back but it just feels unwieldy now. The only time it's relatively easy to deal with is in their enterprise product. Obviously they have to make a living but I'm not sure choosing to make a key component easier in your paid product and leaving it as a pain in the ass for your open source project is the best thing for customers. It feels harder to find community support and discussion because only a small subset use it and/or understand it.
vegardx 11y ago
Nobody is deploying Puppet (or Chef for that matter) using Ansible. You bake it into the images, use bootstrapping or any number of other ways, like cloud-config. How do you deal with dynamic resources, like automatic scaling, in Ansible? You don't, because it can't. With Puppet and Chef you can actually deal with that. If you don't have a rigid routine for updating packages on your systems you shouldn't manage systems. Security will always be an issue, thinking that Ansible solves all issues is naive.
- movedx 11y ago
  "Nobody is deploying Puppet (or Chef for that matter) using Ansible. You bake it into the images, use bootstrapping or any number of other ways, like cloud-config." How do you initially bake the original image? What installs Puppet or Chef on that original image? Is it Puppet or Chef? Can it boot strap its self? The answer is no. Something has to create that image and "bake in" the ingredients. Some people use Ansible for this. "How do you deal with dynamic resources, like automatic scaling, in Ansible? You don't, because it can't. With Puppet and Chef you can actually deal with that." But it can. You've clearly never tried, but instead made an assumption. I've used both Puppet and Ansible, at large government projects, and the Puppet approach was a complete nightmare. For your auto-scaling example, I would use Sensu to monitor load and fire off a CI job when that load met some criteria (say 90%+ CPU/network for ten minutes.) That CI job would clone our Ansible repository and call a relevant playbook for spawning more VMs, configuring them accordingly. How many it spawned would just be defined in a YAML file, updated via git if you so chose. It's beautifully simple. I'll say it again: none of these CM solutions are all-in-one magic bullets - they're platforms or frameworks to build on top of. With Ansible, I would build on top of it with dynamic inventories, custom modules for monitoring and auditing the run time, etc. I do this from my local machine without some monolithic cluster to manage or an agent on all my boxes running as root (or with root privileges - same difference) 24/7. "If you don't have a rigid routine for updating packages on your systems you shouldn't manage systems." We create immutable instances which are updated as and when required, launch those new instances, and have our LBs use the new instances, keeping the old ones up whilst connections fade away, then they're destroyed. What's so difficult about that? What's your point with this remark? "Security will always be an issue, thinking that Ansible solves all issues is naive." Er, I never said it did? ... what? It's security 101, in case you didn't know, to run as minimal amounts of software as possible to reduce the potential number of attack vectors. I can't remember the statistic directly, but when I did a cyber security course online via MIT, there was a statistic along the lines of: for every 1,000 lines of code, there's one bug and potentially, an exploit. The take away from this is: run as few services and software packages as possible to help reduce the number of attack vectors. On that note, are you arguing that running Puppet/Chef in a master/agent configuration does NOT introduce more services, and thus more code, to maintain, secure, patch, make resilient, keep up, etc? Are you also saying that Ansible's default mode of operation (push and run versus pull and run) over SSH is not more secure? If you believe the latter, than I believe, with all due respect, that it is you that should potentially not be managing systems (I didn't want to resort to what is clearly a personal attack, but hey, you made this a school playground to begin with ["If you don't have a rigid routine for updating packages on your systems you shouldn't manage systems."] - shrug) -M