If you have tried setting up a DevOps pipeline to achieve continuous deployment, and ran into configuration drift issues – you will know the pains quite well. A consistent and uniform configuration is a prerequisite to any automation. If the automated workflow finds that the target configuration is not as anticipated, it will either take the exception route, or revert to notification for manual intervention.
What is configuration drift?
When a given system configuration or an application configuration changes from the “blessed” or “vetted” state, to another state, it is called configuration drift. For example, if the IT team provides web server instance with a preset configuration file, and as part of the application deployment process or application customization process, that configuration is changed – that constitutes a configuration drift. Similar drifts can occur at the OS level, for packages or commercial software.
Why does it matter?
It is important to mitigate and remediate any configuration drifts because without it, the environment will become unmanageable, especially as you scale. Consider the web server example above, when there is an application outage in your production environment. As part of finding the root cause of failure, you will now also need to walk back the steps of every configuration changed from the original version, to rule out any issues caused because of those changes. This can cause time and efforts to be deployed towards tangential activities. With consistent deployment automation, you can confidently evaluate the issues plaguing the core application, given all other things to be constant.
Another reason that reducing or preventing configuration drift is paramount, is to make sure that any additional deployments on the base tier can be automated. In the above example, it is much easier to automate application deployment on a web server delivered as PaaS, than deploying the same application on a web server that might’ve been customized, or drifted from its desired state.
How to mitigate or prevent configuration drift?
There are many ways you can address the resolution of configuration drift. The common factor for all scenarios is to make sure the deployments are automated. Firstly, you’d have to define what constitutes a configuration drift. For example, if you are providing your customers with IaaS machines, would adding a new printer constitute configuration drift? Or would that be classified under allowed customizations, that have no material effect on your service delivery? The rules of configuration will need to be defined.
Secondly, you’d want to automate the deployments of your builds and configurations. This could mean using an orchestration framework to deploy the desired service through a self-service catalog, or another automated mechanism. Thirdly, you’d want to make sure that the release and update process for various infrastructure and application components flows through a source control management (SCM) system. Any and all deployments should pick up the latest version of the configs from SCM. And by deploying a systems configuration management solution, you can now check the configuration states of your target systems against the latest versions of those configurations in SCM. There are many other steps you can take to mitigate configuration drift, depending upon the severity of the drift and the penalty you pay for not addressing it.
Keyva has helped several organizations address the common challenge of preventing configuration drift. There are several processes and tools an organization can use to address their customized needs for preventing configuration drifts in their infrastructure and applications. If you’d like to have us review your environment and provide suggestions on what might work for you, please contact us at info@keyvatech.com
Anuj joined Keyva from Tech Data where he was the Director of Automation Solutions. In this role, he specializes in developing and delivering vendor-agnostic solutions that avoid the “rip-and-replace” of existing IT investments. Tuli has worked on Cloud Automation, DevOps, Cloud Readiness Assessments and Migrations projects for healthcare, banking, ISP, telecommunications, government and other sectors.
During his previous years at Avnet, Seamless Technologies, and other organizations, he held multiple roles in the Cloud and Automation areas. Most recently, he led the development and management of Cloud Automation IP (intellectual property) and related professional services. He holds certifications for AWS, VMware, HPE, BMC and ITIL, and offers a hands-on perspective on these technologies.
Like what you read? Follow Anuj on LinkedIn at https://www.linkedin.com/in/anujtuli/