Change and Configuration Management — The DevOps Way
What is Configuration Management?
First, what is configuration management and why is it so critical? Configuration management ensures the system’s physical form and mission function are not only known initially but also remain knowable throughout the system life cycle.
As such, configuration management includes all actions necessary to identify and document your IT infrastructure and software’s functions, characteristics and interrelationships. Also, it ensures that when you make changes to the system, such as functions, model numbers, vendor information, and more, you record them. Finally, configuration management includes creating and tracking timetables for testing and maintenance.
In the DevOps mind set especially in this age of cloud computing therefore involves what is popularly referred to as “Infrastructure as code — IaC”. This is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.
What is Change Management?
With this frame of reference, change management ties in almost seamlessly. Change management from a project management point of view involves the ability to recognize and adapt to a project’s changing requirements and adjust the delivering process/equipment effectively and appropriately with the most efficiency.
So, how is change management mission critical in the DevOps mind set? Well, seeing as change management handles the heavy lifting — Provisioning and Orchestration — change management thereby ensures what is commonly called configuration version control.
When infrastructure setup and provisioning is handled as a set of human readable configuration files (IaC’s main philosophy) then basic version control tools/practices that are used for code versioning can in turn be applied to ensure any changes to said configurations adhere to the same. This is intended to make it easier to revert to a previous working state of configurations should the need ever arise. It to in turn ensures the at every time all the stakeholders in the CI/CD pipeline (Developers, Testers, QA) all have production similar environment against which they perform their respective roles.
Benefits of Configuration and Change Management for Servers
There are indeed a host of benefits that accrue when configuration and change management is especially applied to server provisioning.
The ability to rapidly set up and actively manage changes to a large number of servers is itself a huge benefit to enterprises but it too carries with itself other benefits. Key among said benefits are:
Organization
With a well ordered configuration and change management system/practice in place, all the key stakeholders, be they IT Ops or Devs, should be able to see all of the past system implementations of the business, and can better address future needs and changes to keep the system up to date and running smoothly.
Reliability
Configuration and change management intentionally promotes higher reliability ensuring that system’s are ever configured to work their best in turn reducing down time due to maintenance or breakdowns. In the event that a breakdown occurs, the versioning system with which configurations/changes to servers were made ensures speedy recovery making systems more reliable.
When working with cloud hosted servers like on AWS EC2 or GCP, this practice adds an additional layer of reliability. Where this platforms promote/ensure physical reliability (protection against physical causes of system breakdown, like power outages), configuration and change management though IaC in turn ensures infrastructural reliability.
Cost and Risk Reductions
With increased reliability of systems, the cost of repairs and risk of failure are too greatly reduced by the configuration and change management practices. Configuration Management saves money with the constant system maintenance, record keeping, and checks and balances to prevent repetition and mistakes.
When server configurations and or updates are systemic, well planned out and executed then all changes versioned and documented, then security breaches are reduced ergo reducing the threat of potential lawsuits should an enterprise’s systems be hacked.
There are numerous other benefits that come as a result of Configuration and Change Management. You can find some more here.
Tools For Configuration Management
As you have a server online longer and longer, the configuration can potentially change between servers as you go to quickly fix one thing and you forget to keep it consistent elsewhere. It is therefore necessary to use automation to enforce consistency.
So how do I manage large sets of servers at scale with repeatable and automated configuration enforcement? Configuration management tools.
You’re treating infrastructure as code that can be source controlled and deployed. A huge benefit in DevOps is that in so doing we’re really just treating environments, like a configuration file. As such one can easily spin them up reliably and any changes are thus applied systematically versus manually. One does not go in and update individual servers with a new policy. instead they update a policy centrally and either push or pull that information out to each affected server.
So what tools are there to help one in this respect?
Chef
With Chef you can create these cookbooks and recipes with Ruby, manage tens of thousands of Windows or Linux machines from a central server. Or you can do a Chef solo, without a centralized server, and have servers that kind of maintain their own configuration that they can just have stored locally and you can push locally.
It does have Azure integration now. So you can even do cloud integration with a lot of these tools.
SaltStack
With Salt you can set up this sort of agent list model, that uses SSH instead. So not this sort of idea of the same central server per se, but that has agents on individual boxes. You can still have a centralized server, a master server, or you can just run these minions all over the place on Windows and Linux machines as well. So I could do Master or Master Lists.
The key with Salt is to kind of focus on the more high-speed communication between the nodes versus the polling sort of strategy, that things like Chef or Puppet use.
Puppet
This is an open source tool for creating declarative infrastructure definitions. With Puppet one can manage the system life cycle from provisioning to runtime and deployment and reporting. It works with Windows and Linux and comes with a lot of prebuilt modules that you can see, that plug in and let you support things like IIS on Windows or Apache on Linux. Moreover, it already has a lot of these modules for managing and maintaining commercial software and open source software.
Ansible
I’ve personally just started working with Ansible but I can say for a fact that it is indeed a great tool. This also uses SSH instead of agents on boxes, meant for automating configuration management, provisioning, and more. It’s got this concept of playbooks for configuring and deploying and orchestrating deployments. The only downside I can point out at the moment is there’s not a lot of Windows support yet. Nonetheless, it’s a great popular tool.
Windows PowerShell — DSF (Desired State Configuration)
Albeit a newer entrant into the Configuration Management space, PowerShell DSC allows one to actually set things up as well now and enforce configuration across Windows and now pretty recently, Linux machines.
This lets you deploy and manage configuration information for these machines. Enable and disable roles and features, manage files, start and stop services, manage the registry, deploy software; all that and more. You can have a central configuration with a pull server or again push this thing out to individual machines.
Docker
Since launching back in 2013, this industry newbie has taken the DevOps and software development world by storm. The key to Docker’s success is its lightweight containerization technology.
Their technology deploys software applications with all the necessary parts in a container, thereby ensuring it will run on any Linux server, regardless of configuration and/or settings. Containers can be created, configured, and saved as templates for use on other hosts running the Docker engine. These templates can then be used to create more containers with the same OS, configuration, and binaries.
Factors to Consider When Choosing a CM Tool
There are a lot of things that are coming up in this space. Chef, and Puppet, and CFEngine, and others have been around for a while. But you’re also seeing Ansible and Salt, and some other things coming through as well.
When considering which tool to adopt you may want to stop and think about what you need. That said, you wouldn’t just know out of the box which of these amazing tools are the best for your organizational needs until you really play with some of them.
That said, there are some factors that might help you arrive at your decision.
- Does the tool require the DevOps team to learn a new language?
In the case Chef and Puppet which are both written in Ruby, having the team learn, at the very least, the basics of Ruby might be a plus. For other tools such as SaltStack which is written in Python and may occasionally require configuration to be written in PyDSL, this too should factor into your decision when considering it as the tool to adopt.
- How does the tool integrate with other parts of the DevOps Stack?
This is pretty straight forward but also quite essential. Configuration management albeit a key part of the DevOps life cycle is not the only part and as such the tools you choose should be those that best integrate with the others you are using in your CI/CD pipeline.
- How complex is the tool to learn, in terms of setup and getting started?
The tools above are but a few of the one’s being offered in the CM space. They have different learning curves and some may appear simpler to use to respective individuals in the team given their technical background (be it Dev or IT Ops). When choosing a tool, the ease of learning should also be considered. A tool is only as powerful/useful to the extent one is able to use it.
- Push vs. pull: How are updates to nodes triggered?
You have seen it mentioned above and probably have a vague idea of what is implied but this is indeed another very crucial aspect when considering the tool you want to use. Some provide for both, other are just one-sided. In the case of Pull system of change propagation, when changes are pushed to the Master server, the workers/minions/clients at their configured times (or when certain conditions are met) will pull said changes and update their configurations accordingly.
The Push model is the reverse, changes once made to the central server are in turn — almost immediately — propagated to the clients. Depending on what best works for the systems your servers are running, the mode of propagation of changes really matters a lot.
- How good is the available documentation?
The sheer breadth and/or depth of the functionality provided by some of this tools is overwhelming. It is therefore very crucial to choose one that has readily available documentation. The documentation, despite being technical, should too be easy to use with great details and easy-to-understand/DIY examples.
- Is there active community support?
Community is everything in the software development space. Most of the tools discussed above are Open Source and as such have a significant community backing them up continually adding and improving features, they too — owing to the popularity of some — have an even larger community of loyal users. The ability to receive support from the community around any of them would and should be a point of consideration when choosing a tool to learn or adopt.
Closing Remarks
Each of the aforementioned CM tools have advantages and disadvantages, so we recommend taking the time to do your research. Consider some of the questions we’ve raised along with the needs and requirements of your organization before choosing one to use.
Understanding your system configurations and how they change plays a very crucial role in the development of a Configuration and Change Management practice. It also allows your organization or team to readily adapt and grow its line of product offerings with ease and confidence they will not only be durable but reliable as well.
