Configuration Management, as applied in DevOps, is the practice of using tools to manage the configuration of our technical architecture. Put simply, we document the desired state of one or more servers in a machine-readable form, and then use a configuration management tool (e.g. Chef, Puppet, Salt, or Ansible) to setup the real items to match the configuration.
Why? As with many things, you might think “I barely have time to setup this server manually, never mind write a script for it”. But the reality is, in today’s world, we’re probably going to have to do the same setup multiple times. In enterprise environments, the software engineering process will require deployment to several environments (development, integration test, user acceptance test, performance test, then finally production). It’s critical that all these environments are identical (so far as is practical). This is a key tenet of DevOps operating practices – we can’t apply learnings from one environment to others if the environments are different. Even in a simpler environment, you’re probably going to replace your servers in a fairly short time frame.
Once upon a time, we used to buy server hardware and nurse it along for years. Nowadays, hardware and system software ends up obsolete in a matter of months, not years. If you’ve done your CM work properly, it’s faster to deploy to a fresh OS image than to patch an existing image. And if you’ve embraced virtualization or a cloud environment, you’ll find it’s easier to replace a server than to troubleshoot it.
There’s another advantage to Configuration Management: The system state is documented and version controlled. There’s no need to do archaeological work to find out what your technical architecture has evolved to – you just look at the configuration scripts.
So here’s your challenge for the next year: Stop managing your servers by hand. Setup an open-source Configuration Management system and create a configuration repository (I’m partial to Ansible. See https://www.webagesolutions.com/knowledgebase/kb024/kb024-install-sw-ansible for some tips to get started). Every time you find yourself ssh-ing or logging in to a server, stop yourself and create a playbook, recipe, or run-list in your CM repository. Make it a habit to use manual tools only to examine the server state, not to change anything. Run your servers the way developers write code: If it isn’t in version control, it didn’t happen!
For that matter, do the same thing on your laptop or workstation. You’ll soon find that you’re much less stressed about maintaining your configuration or upgrading your hardware.
