4 ms·

> 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

> 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.

xorcist 6y ago
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.
- TheCraiggers 6y ago
  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.
  - xorcist 6y ago
    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.

xorcist 6y ago

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.

TheCraiggers 6y ago
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.
- xorcist 6y ago
  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.