Navigating the Configuration Landscape

Welcome back to another week of DevOps Insights!

It has been about 3 weeks since I released a newsletter…

I’m sorry for this.

The good news is that they will be starting again. Why was I gone for so long?

I got certified as a Solutions Architect in AWS! I took the test this past week and passed! It wasn’t required for anything specific, but I wanted to expand my knowledge. I’m more confident in my ability to propose design and architectural decisions overall, not just in AWS.

Regardless, today I’d like to talk about configuration management. Previously, I had talked about using a Golden AMI for deploying your apps. Sometimes this is not possible or maybe just isn’t the right solution. Some products and services that companies utilize do not need to scale infinitely, and that’s okay. It is still good practice to have the configuration of the service in code. That way, in the case of a disaster or upgrades, you can redeploy the service easily with certainty.

What is Configuration Management?

Configuration management is a fundamental practice in DevOps. It encompasses everything from the time the infrastructure resources are created to the services running on those resources.

For example, when you deploy a docker container on an EC2 instance, there’s some minor things that need to be done first. You need to run commands to setup Docker on the machine. You may need to inject your secrets onto the server if it is not done programmatically elsewhere. All of this is included in the realm of configuration management.

Major Benefits of Configuration Management

By using the best practices of configuration management, organizations can become more efficient. It’s simply faster than having a human spend time and effort into configuring VMs.

You’ll find less errors in your instance configuration. If you have a human handling the configuration, they are bound to make a mistake at some point.

If you have any requirements for compliance and governance, it becomes much easier to manage. You can simply define the requirements in code and they are done every time the instance is configured. You can also update the configuration over time if things change.

How Do We Do This?

There’s a lot of ways to handle configuration management. If you’re configuration is quite simple for a single server, you can utilize cloud-init. Cloud init is a general name for an initial setup script that runs when a VM is started. Generally, this can be an inline script or an actual script that is loaded with the VM creation. How it is configured depends on the platform you’re running your instance on.

Cloud init does have it’s limitations though. Validation of what happened during cloud-init can be quite difficult to manage. Idempotency can be difficult to achieve when executing a complex script. Debugging can also be difficult, especially if part of your cloud-init includes adding SSH configuration or other networking updates that may cause you to lose connection to the instance for a brief period.

That’s where Ansible comes in. Ansible is an open-source automation tool that aims to simplify configuration management tasks. Ansible is a simple tool and is quite straightforward to use. It uses SSH to run commands against your target machine(s), which means you do need to install any agent on the target. Ansible handles idempotency and it will check if needs to run a specific task before it is complete. Lastly, the documentation is fantastic. It is amazing how many things you can do with Ansible.

Ansible is not the only tool. There are others like chef and puppet, but I have experience with Ansible and enjoy using it as a tool.

Problems with Configuration Management

Configuration management isn’t a perfect science. It can be difficult at times. There’s an operational overhead to managing the Ansible scripts. It can become complex quickly if your servers need a lot of configuration.

Scaling can be somewhat difficult to manage. If you have more than 10 servers at a time being deployed, it can be difficult to run through Ansible logs to understand and debug any errors.

Change management policies need to be set into place to make sure that you avoid configuration drift. Configuration drift can cause major problems down the line. This happens when someone makes a change to a server without making a change in Ansible. If that happens, things get messy extremely quick. Therefore, it’s important to have policies in place to ensure this doesn’t happen.

Conclusion

If your company is not using configuration management tools to handle configuration on servers, I’d recommend starting. It’s important to maintaining consistent deployment of servers. It can be costly to start due to the development resources, however, it is incredibly valuable moving forward. Your deployments become as simple as grabbing a coffee and running your Ansible tasks. It’s a beautiful thing.

If you enjoyed this content, please let me know! If there’s anything you are not clear about in the DevOps space, I’d love to know what you want to hear about. I’ll be glad to cover it here!

Also, if you are new and have not read any of the previous newsletters, you can read them online here:

Thanks and have a wonderful week!