But it’s not agentless. It depends on ssh. And we discovered back in 1995 that parallel ssh to even a medium sized number of hosts doesn’t scale. In fact, it anti-scales.
There’s a reason why tools like Puppet and Chef have agents. It’s so that they can have a more scalable parallel UDP-based communications mechanism between them and their agents.
Heck, some tools even do a torrent-style mechanism for the lengthy stuff.
These are lessons that Ansible actively refused to learn. At least until recently.
And shells are variable across platforms and versions thereof. If you’re depending on your bash script running exactly the same wheat everywhere in the world, you’re going to be in a world of pain. There’s a reason why defensive bash scripting is hard and convoluted. And I don’t think that any of the Ansible playbooks have really been written to be sufficiently robust in this manner.
Moreover, all of these tools end up treating your infrastructure like pets, because you’re applying one set of operations on top of another on top of another, ad infinitum.
Instead, you want to treat your infrastructure like cattle, and ideally use immutable infrastructure. If you want to make any changes to the infrastructure, you don’t change the existing ones, instead you spin up new replacements and then tear down the old ones.
To make that easy, you want a robust and reliable build system to create OS images that have everything you want/need, and then you run them read-only. Logs and other things that might want/need local write access use a different partition.
And the further you go down that road, the less and less it looks like Puppet or Chef or Ansible or any of those kinds of tools will be helpful to you.
Of course instances themselves are only part of the equation. You also need to be able to configure network devices and all the other aspects of infrastructure in a similar immutable manner, and tools like Puppet or Chef or Ansible have never really been able to offer much in the way of configuring anything other than hosts/instances.
IMO, you’re asking the wrong questions. You instead want to know how you can deploy your static-built code onto your immutable infrastructure, and what kinds of tools are available to help you do that.
They continued to get repeated complaints about scalability, and it became more and more clear to them that they would have to implement their own agent, in the vein of Puppet and Chef.
They also got complaints about Ansible scripts failing in weird ways because of all the different shell versions, and their scripts weren’t written in a sufficiently robust manner.
Various private conversations that I had with folks at Opscode/Chef and various people I’ve spoken to from AnsibleWorks.
UT Austin was a user of Cobbler, and after leaving UT Austin, I learned Chef to completely redesign and redeploy the production service networks for a small startup here in Austin, by the name of ihiji (who was since bought by Control4). Many thanks to my good friend Matt Ray for that referral.
I have stayed in the Chef community and broader DevOps community, working as a consultant for Momentum Software (before and after they got bought by VMWare), and even leading up to the work I was doing as a consultant at Whole Foods (before they got bought by Amazon), I continued to have contacts and conversations with various people in this space.
So, nothing on paper. Just private conversations with various people over the years.
There’s a reason why tools like Puppet and Chef have agents. It’s so that they can have a more scalable parallel UDP-based communications mechanism between them and their agents.
Heck, some tools even do a torrent-style mechanism for the lengthy stuff.
These are lessons that Ansible actively refused to learn. At least until recently.
And shells are variable across platforms and versions thereof. If you’re depending on your bash script running exactly the same wheat everywhere in the world, you’re going to be in a world of pain. There’s a reason why defensive bash scripting is hard and convoluted. And I don’t think that any of the Ansible playbooks have really been written to be sufficiently robust in this manner.
Moreover, all of these tools end up treating your infrastructure like pets, because you’re applying one set of operations on top of another on top of another, ad infinitum.
Instead, you want to treat your infrastructure like cattle, and ideally use immutable infrastructure. If you want to make any changes to the infrastructure, you don’t change the existing ones, instead you spin up new replacements and then tear down the old ones.
To make that easy, you want a robust and reliable build system to create OS images that have everything you want/need, and then you run them read-only. Logs and other things that might want/need local write access use a different partition.
And the further you go down that road, the less and less it looks like Puppet or Chef or Ansible or any of those kinds of tools will be helpful to you.
Of course instances themselves are only part of the equation. You also need to be able to configure network devices and all the other aspects of infrastructure in a similar immutable manner, and tools like Puppet or Chef or Ansible have never really been able to offer much in the way of configuring anything other than hosts/instances.
IMO, you’re asking the wrong questions. You instead want to know how you can deploy your static-built code onto your immutable infrastructure, and what kinds of tools are available to help you do that.