What is Configuration Management in DevOps Practices?
Concept of Continuous Testing in DevOps was explained in detail in our previous tutorial.
The key highlight of configuration management in DevOps is delivering,
- Infrastructure as a code
- Configuration as a code
Must Read Through => Exclusive DevOps tutorial series
There are numerous benefits of ‘Infrastructure as a code’ and ‘Configuration as a code’ in DevOps practice.
-
- Configurations are Version controlled
- Automated and standardized
- Removes dependency
- Error-free infra setups
- Boosts collaboration between Operations and Development team
- Correcting configuration drift
- Treating infrastructure as a flexible resource
- Automated scaling of infrastructure
- Maintaining consistency in the setups
VIDEO Part 4 Block 1: Configuration Management – 23 minutes 7 seconds
Transcript:
In this part, we will learn about Configuration management, Release management and Application Performance Monitoring in DevOps.
Here, in block 1, we will focus on Configuration Management and understand what is configuration management and how is it different in DevOps and the traditional methods.
To start with, let’s know What is Configuration Management?
Configuration management as the name itself explains, is nothing but managing all the configurations of the environments that the software application hosts upon.
As we know, we have different environments throughout the SDLC in DevOps starting with Unit testing, integration testing, system testing, acceptance testing and end-user testing.
And I’ve also explained in my earlier tutorials that the environment set up’s for these tests would progressively become more complex as it moves towards pre-production and production environment.
So, basically, configuration management is the automated process to manage all the configurations of each of these environments.
Then what is the difference between traditional Configuration management and DevOps configuration management?
In our traditional configuration management methods, the team used to manage these configurations of various environments via formal documentation wherein each of the configurations used to be recorded in the documents and configuration team or manager used to handle the version control of these documents.
And as and when it undergoes changes, he would also take the responsibility of setting up the environment and managing the configurations manually
Now in DevOps, typically, all these configuration management processes are pretty well automated and the configurations are encapsulated in the form of code or scripts and controlled through the version control tool.
In this context, we can call that the Operations team is integrated with Development in managing the environments through the single version control tool.
So, the key highlight of configuration management in DevOps is delivering,
-
-
- Infrastructure as a code
- Configuration as a code
-
What actually ‘Infrastructure as, as a code’ mean? It is defining the entire environment definition as a code or a script instead of recording in a formal document.
Then what does environment definition include? Environment definition generally includes, set up of servers, configuring networks, and setting up of other computing resources, which are a part of the IT infrastructure set up. So, all these details would be written out as a file or in the form of a code and checked into version control tool.
This script or code, which is checked into the version control would become the single source of defining the environment or even updating those environments.
Just to give a simple Example, if we have to add a server to the specific environment, all that we would do is to update these information in to the environment scripts and run the delivery pipeline, instead of manually going and spinning out a new environment with the added server or seeking the help of the system admin people to do this.
So, the beauty here is that the developer or tester need not be a system admin expert to set up their servers for development or testing activity.
So, the infrastructure set up in DevOps will be completely automated, and basically follows the script that is checked in to version control starting from installing the servers, configuring them, installing the OS, till the communication channels of these instances are established with the deployed software.
What is the configuration as a code?
Configuration as a code is nothing but defining all the configurations of the servers or any other resources as a code or script and checking them into version control.
These configuration scripts which are checked into the version control are run as a part of the deployment pipeline in order to set up the infrastructure and its configurations in an automated fashion.
Well, defining configurations includes parameters that define the recommended settings for the software to run successfully. Or a set of commands to be run initially to set up the software application. Or even it could be configurations of each of the components of the software that are to be set, or specific user roles, user privileges etc.,
Simple Example would be to set the feature toggles, where default values are set up as a part of the configuration parameter.
Adding another port to a firewall would be another Example, which can be updated in the script and later these scripts are run as a part of the delivery pipeline.
Several tools are available to carry out the infrastructure automation in the market. Few of them are Chef, Puppet, Terraform, etc., Chef and Puppet are ruby based configuration management tool, whereas Terraform is a provisioning tool.
Also, these days as almost all the applications will be hosted on the cloud, AWS, they themselves provide RESTAPI’s, which can be leveraged for this purpose.
I have a huge list of benefits of configuration management in DevOps, rather than defining the infrastructure and configurations as a code.
Let’s go through them one by one.
All the configurations and infrastructure details are version controlled which is a big benefit in DevOps implementation.
#1) This helps the team to manage the changes to the servers and configuration in an automated fashion and helps to debug quickly if anything fails, within a short time span and also allows to rollback quickly to the previous version, without causing any interruptions to the customers.
#2) Since these scripts are located on the central server and everyone in the team knows what is there in each of these scripts and what are the changes made in each of these versions. This also enables the team, to go back to the older version, if there is any problem in the latest versions.
Imagine, if there is a server crash, how much time it would have taken to manually restore it. And now by defining infrastructure as a script and version controlling, we can immediately restore by going to the earlier version.
#3) Managing the configurations as a code also prevents someone from making changes to the system accidentally and prevents any damages causing later in the production.
Since configuration management is totally automated, manual intervention either to set up or update is completely eliminated.
Imagine the impact on the cost, quality and time when earlier, people used to depend on human resources to carry out these configurations manually and when certain configurations are missed out or not set as required.
So, automation of configuration management not only has benefited in time-saving but also in eliminating such human errors and improving the quality. Also, coding standard has helped the team in following the specified standard in coding and automating instead of following the fantasy of each of the person who writes the config guide.
As discussed earlier, configurations delivering as a code has removed the dependency on a single person or a team called config manager or config team. Development team need not have to wait for the config team to come and fix any infra or config problem.
Or even for setting up the infra and configurations, which are completely automated and version controlled. So, anybody in the team be it a developer or tester can spin a server and carry out the configurations for their development and testing purposes. Hence setting up the server and configurations has become person independent.
This also ensures that the same servers are not used by both the Development and QA teams for their activities, which generally used to be the case earlier.
Infrastructure and configurations defined as a common code along with automating and version controlling standardize all the environments and set up’s. So, this not only makes the debugging task easy for the developers but also eliminates the human errors resulting in error-free infra setups, otherwise which would cause huge damage, if not detected early.
Here, we can clearly see the clear collaboration between the Dev and Ops, where both of them rely on a single source for carrying out the infra set up and both the teams are actively involved in automating and setting up the entire configuration management.
This working together to achieve a common goal boosts the collaboration between both the teams, Development, and operations.
Correcting Configuration Drift
What is Configuration Drift?
Small differences and inconsistencies between the servers, which sometimes happens due to manual update, which accumulates over a period of time are called Configuration drift.
This is not a good situation, because this inconsistency in the servers leaves certain program files like manifest, playbook not to run reliably on all the servers and hence leads to automation failure. So, this needs to be avoided to make the team to use the automation of configurations effectively.
Managing infra and config as a code and version controlling them has helped the team to avoid or correct any kind of configuration drifts between various environments or between dev and production setups by consistently maintaining the configurations across all the servers.
Thus, a team can be best assured of similar config setups on the development set up as that of in production. This also helps them to simulate the production issues on the dev environment.
So, this helps to prevent any kind of unexpected changes that any of the team members might try to do on the infra, which might break the set up and also enforce the team to make no changes to the set up unless they are logged in as a code to the repository.
Delivering infrastructure and its configuration as a code has enabled the team to manage it as a flexible resource to meet the dynamic business needs of the customer.
Its a kind of plug and play now. A team can specifically get into the particular server or network and make the changes to them. It could be just updating the provisioning server or adding or modifying the storage in a particular network, or even updating the OS, and everything can be independently updated as a flexible resource.
Previously, to change one configuration parameter, it really used to take a lot of time, especially while it was required to update in all the servers, but now it is just a one go. Update the script and upload to the version control tool and it is all done.
There is a flexibility to completely scrap the existing infrastructure and totally bring up another one. So, managing the infrastructure and configurations has become quite easy now. Well, the cloud-based solutions have enabled the infrastructure to automatically scale up by adding the additional computing or storage resources as required and scaling down when they are not required.
This has enabled the optimization of resource usage based on the demand. If we want to scale up the infrastructure by increasing the size of the machine, we can do it immediately. Similarly, if we want to scale out or maybe add another setup, or add more front ends, we can just do it in seconds by simply updating it in the code and running the automated pipeline.
Last, but not the least, infrastructure, delivering as a code under a controlled environment helps in maintaining the consistency of the environments across various setups. This helps in debugging the issue also. This point I’ve covered earlier as well to some extent while talking about configuration drift.
That’s it and this completes our talk on Configuration management in DevOps, as of what is infrastructure and configurations as a code and what are its benefits.
In our upcoming tutorial, we will discuss the Release Management aspects in DevOps.