DevOps introduced us to development practices within an operational context. But infrastructure as code and configuration as code, when combined with modern tools and methodologies, takes everything to a completely different level. What you actually end up with is a much more rigid, streamlined process that is faster, better automated and drastically reduces the error rate, and also gives you a very consistent output each and every time. We are also now focusing a lot on stability and repeatability, and this is what configuration as code gives us. It provides us with a lot more stability and a lot more repeatability because we can just keep running code over and over again.
What is Configuration as Code?
Configuration as Code (CaC) is about defining the state in which you would like your operating system to be in, such as users, files, services, permissions, SELinux. For example, maybe you want SELinux should be enabled, that is what configuration as a code lets you do. Configuration as a code allows you to describe the configuration you need to run the application. For example, with CaC, you can decide – which user should exist, what should be the user’s password, which file should exist, service X should be disabled, but service Y should be enabled, which is literally the definition of configuration as code. All you have got to do is write the code to define what you want things to look like, and the software suite will take care of the rest for you.
We are also moving away from graphical user interfaces, web consoles, terminals, etc. Now instead of using consoles to edit infrastructure, we are going to use code. So, you are going to log into your system, open up your text editor, you are going to edit some code, and then you will commit via Git. Then you will push the code, and an automated process is going to take over from there. And hopefully, if your tests pass, you will end up with that code going live and production-ready. Tools like Ansible, Puppet, Saltstack, Chef give us our configuration as a code interface to our operating systems and do everything at the operating system level. Ansible is my tool of choice where I use it to configure Debian systems, Ubuntu systems, rail systems, even Windows systems.
Configuration as Code Benefits
Below are the essential benefits of using Configuration as Code:
- Standardization: You will be able to use the best development coding practices when you are writing the source code for the configuration. All the configuration files must be reviewed and tested before they are committed to the master branch, and these new commits must follow the standards. With the configuration as code, you can even manage complex microservices architecture by having some standard processes in place that help the services to work together.
- Traceability: You should have a separate version control system for configurations so that it is easy to store and track changes in the code related to the configuration files. So, if there is a bug related to the configuration source code, you will be able to easily point to the source of the problem and fix it quickly.
- Increased Productivity: With all your configurations getting managed through code, the build pipeline becomes simple to use. So, the overall productivity of the development and operations team as well as end-users increases. In addition, the developers are aware that their configuration source code is correct as they are tested at various stages in the pipeline.
- Security: With all the configurations getting codified in the configuration as code process, the access of different level of configuration code can be handled at the user level by assigning necessary permissions.
- Manageability: With the configuration as code applied in the CICD pipeline, you can have additional steps of approval and testing of some specific configuration code to ensure that everything is running correctly.
Configuration as Code vs. Infrastructure as Code
People often get confused between these two terms configuration as code (CaC) and infrastructure as code (IaC). There are many who think both CaC and IaC are similar things, which is not valid.
The fundamental difference between infrastructure as code and configuration as code is that in infrastructure as code, you are required to manage and provision the infrastructure using code, and there is no manual process used for configuring the systems or devices. For infrastructure as code, you use management tools such as Chef, Puppet, AWS CloudFormation, and Terraform. In the case of configuration as code, you are required to manage the configuration data or settings of the application and not its infrastructure.
This does not mean that IaC and CaC are completely opposite of each other. Most of the time, both are used in the production environment, as they also complement each other. Configuration as Code is somewhat similar to Infrastructure as Code but not the same. Instead of describing the infrastructure, in CaC, you will describe what the configuration is for your application. Your individual configuration for your application is stored in source code. So once again, now everything is versioned together. Now when you build the CICD pipeline to release your application into production, you have the infrastructure, and you also have the configuration that you need to do to configure your infrastructure. So, it is ready to deploy your application.
Final Thoughts
So that was all you needed to know about Configuration as Code. Configuration as code is a concept where instead of describing the infrastructure itself, you describe how your infrastructure needs to be configured to run your application. So, it is not that we would be provisioning an infrastructure or deploying resources. It’s more of configuring it the way we want it to be to run the application.
