Puppet is a great tool for managing containers, and so is Chef. There is nothing inherently good about YAML.
There is less buzz around those tools now however, and people tend to gravitate to other tools which are easier to get started with.
They may end up "silent heroes" (much like Ruby itself, I would say) or they may end up replaced by other tools. The concept of state as text in version control is a timeless concept and continue to exist in one form or another.
One of the problems with configurations management systems is that they are conceptually easy, everyone has opinions of them, and they really need to control your whole world in order to shine. There was never really room for one clear standard to emerge.
Puppet Inc.'s problem was that they kept chasing shiny stuff (agentless you say? we have that too!) in order to woo enterprise customers. Their customers should have been developers and sysadmins, not their bosses. There is only room for so many VMware in the world.
> Puppet is a great tool for managing containers, and so is Chef. There is nothing inherently good about YAML.
I am not sure what complex config state management solution brings to the table for immutable containers. The state is immutable, so there's nothing to manage after deployment. It's like using an atom bomb to take out a zit.
Puppet/Chef in their glory days, pre-cloud pre-container, excelled at managing desired state across numerous mutable static systems. With immutable solutions, Puppet/Chef are both cumbersome and expensive.
An application running as a container bascially carries the same configuration as one running without the container bits would. That may include things like endpoint addresses, certificates, secrets, but can also be things like feature flags, authorizations, API tokens. Basically anything that's not compiled in is configuration.
The deployment side also carries configuration, including things like desired amount of instances, request routing and filtering, log destinations, log retention, persistent volume sizes and location, backup rules, metrics and monitoring rules etc.
If anything, application deployments today carry more configuration, not less. Fifteen years ago, half of the above didn't even exist. Perhaps you pointed you application to a syslog server and that was it.
All of this configuration exists in disparate tools (JSON files, YAML files, firewalls, metrics dashboards, cloud providers proprietary APIs) and will over time slowly turn into a sprawling mess. Bringing control over this into a central repository is a good thing.
Not sure about expensive, as the aim is maintainability and reduced complexity, but these tools do tend to get cumbersome. After all, they want to do everything. It's a fundamental problem. It's not surprising that has led to a surge in less capable tools.
> That may include things like endpoint addresses, certificates, secrets, but can also be things like feature flags, authorizations, API tokens. Basically anything that's not compiled in is configuration.
But Kubernetes solves most of this problem in an easier way with Pods, ConfigMaps, Secrets, Services and Endpoints.
Yeah, but what's left after you slim down your VMs to a Linux kernel, an SSH daemon and a container runtime? Is a CM system really justified at that point? Why not bake VM images and treat the VMs as immutable?
Testing Puppet manifests locally is (was) THE WORST. Hiera and r10k really shouldn’t exist in 2020. IIRC you essentially need long-lived Git branches for managing different envs for different playbooks.
Ansible is just SSH and a binary. pip install and I’m done. This is great for building VMs, base Docker images, app deployments, whatever you need. Puppet has their own wire protocol and is very dependent on a client-server relationship. You need to edit config files and fake a puppet master. That’s work.
The each their own, these tools are conceptually simple but as you found out, there is a lot to learn.
What kind of branching strategy is most suitable is given from how your testing is organized, not which particular tools are chosen.
Ansible is completely equivalent to Puppet or Chef in this regard. They are all the same family of tools. Many find Ansible easier to get started with due to its agentless defaults, but there are some (perhaps Spotify was most well known at the time) who run Puppet agentless too.
Having a server, something like Tower, is necessary as soon as you want to manage distributed configuration for clusters, and if you manage monitoring and backup systems.
> Puppet is a great tool for managing containers, and so is Chef.
Eh. While I won't say that it can't be used, I will argue that it's not the best tool for the job. I wouldn't call it a "great tool" for that purpose, although I suppose that depends on your workflow. I prefer to take the approach that containers are immutable once built. If you want to change the container, fine- make your changes, build a new instance, hotswap the connections over, and bring down the old one. There's no need for any sort of config management in my eyes, at least not in the traditional sense.
Now, Puppet could be useful for things like managing the VMs that the containers are running on, but I would prefer those stay immutable too, and with containers, they easily can. I'm (sadly) very aware that not all enterprise software can fit in this model though. Enterprise always lags behind, but it will get there. Hell, even SAP is heavily exploring containers. It's only a matter of time.
Not sure what the argument here is. Different builds for prod, qa and test?
Even if that was workable, which is a question in itself, there is still configuration outside the packaged application. AWS keys, metrics and logs, dashboards, that sort of things.
Well, the container manifest (or whatever you call it) is checked into version control. How you choose to deploy that is up to you, but a ton of CICD tools out there are made for just that purpose.
Likewise, how you separate config data and deploy to production is an age old problem with many solutions as well. Sure, Puppet can even be a solution here, but you're just kicking the can down the road. How do you separate your Puppet code from data? Put it in Hiera? OK, how do you promote Hiera? It's the same issue.
Both of these issues were solved long ago before Puppet came along, and what we all learned from back then still applies: separate your data, config, and code. Version control as much as possible. There are many simple solutions that don't require Puppet. Hell, set up a bind mount to an external config store. Or something fancier like your CICD tool bundling the config data and signing it with a cert that only a certain environment can use so you never get dev code running in prod.
The argument is that when your infrastructure is immutable (which is the direction most of us are going) you don't need a tool to manage the configuration of said infrastructure. Because it can't change. When you do want it to change, you just follow the typical code SDLC and use the powers of version control and CICD.
It is absolutely workable to write a script to bundle data with your application. And one that exports configuration data from your data store to configure your cloud provider. And one for your monitoring system. That's where we all started.
Should you at some time replace all this with a common data format, then congratulations you have invented a configuration management system very similar to Chef.
The use of a version control system or a CI/CD system does not somehow negate the need to keep configuration, neither does a configuration management system do the job of the former. Nobody builds their software using Puppet, they use something like Jenkins. In fact, I would consider having VCS and CI/CD in place a prerequisite to any type of configuration management.
There is less buzz around those tools now however, and people tend to gravitate to other tools which are easier to get started with.
They may end up "silent heroes" (much like Ruby itself, I would say) or they may end up replaced by other tools. The concept of state as text in version control is a timeless concept and continue to exist in one form or another.
One of the problems with configurations management systems is that they are conceptually easy, everyone has opinions of them, and they really need to control your whole world in order to shine. There was never really room for one clear standard to emerge.
Puppet Inc.'s problem was that they kept chasing shiny stuff (agentless you say? we have that too!) in order to woo enterprise customers. Their customers should have been developers and sysadmins, not their bosses. There is only room for so many VMware in the world.