It's certainly possible to do with shell scripts and by stringing lots of small utilities such as expect together. But I've been there, and after a few years and a handful of consultants came and went, it's all a big ball of mud. I know how many of my colleagues get spaces in file names, tmp races, and error handling right in their shell scripts, and they're not many.
What Puppet et al brings to the table is a bit of structure and best practice. After a two day introduction, anyone can start making changes to our infrastructure, and I'm pretty confident that the new hire in two years' time will understand it as well. And if I need to restore a previous environment, it's all in version control, and will work since it defines state as opposed to transforming it.
But the big win with a configuration management tool is not even in the tool itself. It's having a central database of _all_ configuration in every environment.
Suddenly you can start doing things like tell an application to connect to its auth service, and it'll know which one it is or even mock it if required. Your monitoring software knows every app in every environment, and can configure itself, so it's literally impossible for someone to forget to set up monitoring for a new service.
It's a huge win. Once you used to it, you never really understand how you managed without. But you really need to go all in on it to see the benefits. Automated systems integration is possible only when you store configuration in one and only one place.
> What Puppet et al brings to the table is a bit of structure and best practice.
> But the big win with a configuration management tool is not even in the tool itself. It's having a central database of _all_ configuration in every environment.
I agree that is the big win. Though in theory you don't need a configuration management tool to get it. Just sufficient discipline and attention to best-practices.
What the config management tools provide, here, is a framework for combining "site-wide" configuration, "local/discovered" facts, and "human-assigned" roles and classes and exposing it all, consistently, to a specialized scripting language.
The library of modules/cookbooks/etc. also often take care of a lot tedious logic/details that would otherwise have to be in the code (although this part can still get in the way...).
What Puppet et al brings to the table is a bit of structure and best practice. After a two day introduction, anyone can start making changes to our infrastructure, and I'm pretty confident that the new hire in two years' time will understand it as well. And if I need to restore a previous environment, it's all in version control, and will work since it defines state as opposed to transforming it.
But the big win with a configuration management tool is not even in the tool itself. It's having a central database of _all_ configuration in every environment.
Suddenly you can start doing things like tell an application to connect to its auth service, and it'll know which one it is or even mock it if required. Your monitoring software knows every app in every environment, and can configure itself, so it's literally impossible for someone to forget to set up monitoring for a new service.
It's a huge win. Once you used to it, you never really understand how you managed without. But you really need to go all in on it to see the benefits. Automated systems integration is possible only when you store configuration in one and only one place.