"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

So your argument is that anybody using Chef or Puppet, or just about any master/agent-based CM shouldn't manage systems. I guess a lot of people would be out of jobs then.

There are a number of tools to "bake it" into the original image. Most people don't really "bake it", they bootstrap it using things like cloud-init. And it can most definitively bootstrap itself into an environment.

While a novel approach to automatic scaling it seems rather hacky, instead of using the tools provided by whatever provider you're using, that are built for this exact thing. I can see a number of things that can, and probably will, go wrong with that setup. Sensu having a hiccup, f.ex.

And your assumptions about me not trying Ansible is incorrect. I've used it, and I like some of the concepts of it. But for anything other than one-off configurations or smaller environments, moving to Puppet was an easy choice. Speed being one of the biggest factor, and Puppet is slow as fuck compared to say, Chef. How do you do testing in Ansible?

The last remark wasn't an attempt at "school playground", just a factual statement to counter the argument the article raised about old versions of Chef. If you can't upgrade your packages, the why are you even looking at CM?

I never said that Ansible was insecure, or somehow more insecure than Puppet or Chef, I'm not sure where you even think I wrote that.

"So your argument is that anybody using Chef or Puppet, or just about any master/agent-based CM shouldn't manage systems. I guess a lot of people would be out of jobs then."

I said nothing of the sort. Please quote me.

"There are a number of tools to "bake it" into the original image. Most people don't really "bake it", they bootstrap it using things like cloud-init. And it can most definitively bootstrap itself into an environment."

I would be interested to see Puppet/Chef bootstrap its self into an environment. It could be useful for future use cases.

"While a novel approach to automatic scaling it seems rather hacky, instead of using the tools provided by whatever provider you're using, that are built for this exact thing. I can see a number of things that can, and probably will, go wrong with that setup. Sensu having a hiccup, f.ex."

Because using what your Cloud provider gives you is locking you into that vendor. Amazon and Google both have great offerings when it comes to autoscaling various bits of your estate, but the moment you start using features they offer you, features no one else offers (so virtually all of Amazon's catalog, then), it becomes incredibly difficult to move away from that provider.

"And your assumptions about me not trying Ansible is incorrect. I've used it, and I like some of the concepts of it. But for anything other than one-off configurations or smaller environments, moving to Puppet was an easy choice. Speed being one of the biggest factor, and Puppet is slow as fuck compared to say, Chef. How do you do testing in Ansible?"

Fair enough. Then I withdraw and apologise for my bad assumption.

I've never really found Anible to be slow, because I manage networks in chunks, correctly partitioned, and fenced from each other, which means an update to a product, service, or resource is generally done on only a few servers.

If I had an estate with, let's say, 500 web servers in it and those servers were on a flat network (the same VLAN), I wouldn't dream of rolling out a change to their configuration in one big swoop. That would be a mental thing to do. Instead I would do it with chunks of servers at a time, something Ansible can do for you. I would also utilise Ansible's failsafe features, so if there are any or enough errors during a run, it will back off and stop provisioning. I'm sure Puppet/Chef can do this to.

"The last remark wasn't an attempt at "school playground", just a factual statement to counter the argument the article raised about old versions of Chef. If you can't upgrade your packages, the why are you even looking at CM?"

This is true to a point, but if you're like me, you're probably bored of the OS by now. I am. I don't want to play around with kernel params, disk issues, packages, etc... I want that abstracted away and made easier.

Also, I've seen people, friends of mine, successfully take someone from zero to hero with regards to Linux, using Ansible as a learning tool: you do something in Ansible, you look at and understand the result. It complements learning nicely.

"I never said that Ansible was insecure, or somehow more insecure than Puppet or Chef, I'm not sure where you even think I wrote that."

You said: "Security will always be an issue, thinking that Ansible solves all issues is naive."

And my response is: security is a complex matter, but one way to reduce that complexity is through the use of as little software as possible. Ansible introduces virtually ZERO new pieces of software on your network (the actual boxes you're provisioning), Puppet and Chef introduce a lot, way too much, across your entire estate, and thus is less secure by definition.