Configuration Management Options


Configuration Management
General Concepts
Configuration Management Options

A lot of options exist for configuration management and the different tools have different approaches to solving the same problem. It can be difficult to know where to start. This course is a high-level overview to help explain some of the concepts of configuration management.

If you have any feedback relating to this course, feel free to tell us about it at

Learning Objectives

  • Learn what configuration management is
  • Understand which configuration management tool is best for you
  • Learn about additional tools used to perform configuration management

Intended Audience

DevOps engineers, IT professionals, or anyone looking to improve the way they manage their infrastructure.


To get the most out of this course, you should already have experience in managing infrastructure deployments. Knowledge of DevOps techniques would also be beneficial.


Welcome back to what is configuration management.

When it comes to provisioning, not every CFM is equal, if it even offers the ability at all. In regards to the CFMs that were mentioned earlier, we'll briefly cover the provisioning abilities available from supported CFMs.

Ansible using an idempotent configuration management method in which resources converge to the specified Ansible code, upon an Ansible run being executed. This is considered in-place configuration management as it executes upon existing systems and instances.

Ansible has a robust module system that allows its capabilities to be easily expanded, not only to instances, but also infrastructure resources. There is support for provisioning a great majority of Amazon AWS resources, as well as most other cloud providers and their respective resources. This makes Ansible able to provision cross-vendor, cross-platform, infrastructure as code, in addition to executing configuration management on cloud instances or physical hosts.

Ansible is stateless, so there is no agent to maintain. As only SSH is required, Ansible can be used across most Linux/BSD distributions. In very large-scale Ansible farm deployments, there is an agent that can be use to facilitate scale. For small to medium environments, a commanded control Ansible machine executes all configuration management runs without the need for an agent.

Chef can also be considered an idempotent configuration management solution as it performs in-place operations to converge resources. Chef Client runs ensure resources configuration exists as it is specified in code. Chef is specific to the instance or host level, whereas Ansible has the ability to not only modify existing instances, but can control underlying infrastructure as well.

Puppet, like Chef, works at the instance or host level. It is another in-place configuration management solution that uses an agent to execute idempotent runs on Puppet-managed nodes. If instances are divergent from what is specified in code, instances should converge to the specified state upon Puppet run.

Cloudinit is a cross-cloud provider technology that provides configuration instructions to an instance as it comes up on the cloud. This is an immutable configuration management strategy, as typically, changes to deployed instances occur by destroying an existing instance and recreating with new cloudinit instructions.

Terraform is a tool which works at the infrastructure level, but has support for instance configuration management through userdata or cloudinit. This method of configuration management for instances is an example of immutable infrastructure, as when a change is made, the instance in question is terminated and recreated with the new configuration management instructions.

It is important to note other Terraform functionality such as non-instance infrastructure changes that work idempotently. Terraform maintains the state of the provisioned resources via a local tfstate file and also supports remote state backends such as etcd and consul.

Cloud formation is an AWS native configuration management tool. It is very similar in ability to Terraform, however it can only be used on AWS. CloudFormation scripts are JSON instructions that provide the necessary information for AWS to create resources and configure instances. Like Terraform, CloudFormation leverages cloudinit and userdata for instance configuration management, so it can be thought of as an immutable technology for instance configuration.

Like Terraform, other resources are configured idempotently. Docker is a containerization solution technology. Configuration management is accomplished via the Dockerfile, which specifies the base container image to launch and any additional configurations you apply on top of the base image. Docker is considered immutable as once the image is built from Dockerfile, it is not changed.

Changes should be made by updating Dockerfile and building a new container image. This new methodology for immutable configuration management and containerized deployments is the basis for the movement towards microservices. Additionally, Docker offers provisioning of Docker container infrastructure through the use of Docker Machine. This is containers only, not any cloud or virtual machines.

SaltStack is similar to Ansible in that it's Python-based and does not require a client on the target system for communication. However, it does support the classic client/server architecture, similar to Chef. SaltStack additionally supports provisioning of basic virtual machine infrastructures from many popular Cloud providers.

Using a good workflow for building out and managing your CMS environment is essential. This involves your choice of editors and VCS and incorporating a CICD methodology and taking into consideration test-driven development.

All of the configuration management systems mentioned thus far use a directory structure containing all the artifacts required for managing the environment. These can be configuration file themselves, along with any scripts, binary files, et cetera. The majority of your work will be editing these configuration files and committing to a VCS such as GitHub, as well as command line tools for creation and testing.

Many IEDs combine these features into one such as Eclipse and Atom. Using an IDE may make the workflow easier as it will automatically provide an interface to your VCS, an environment for building and testing locally, and finally, pushing your changes back out to your VCS.

To fully achieve a proper workflow, a CICD environment must be considered. Continuous Integration and Delivery is the concept of receiving fast, accurate feedback on the correctness of your code and determining if it's production-ready.

Once production-ready, it enters the next stage of the CD pipeline which will perform a more thorough test of the code and upon passing, deploy it to production. The ideology is to commit often and release often. This removes the stress and extra hour generally involved in the yearly, monthly, weekly or even daily release cycle.

Thank you for completing what is configuration management on Cloud Academy.

About the Author
Learning Paths

Stelligent's entire focus is DevOps automation and Continuous Delivery in the AWS cloud. Founded in 2007, Stelligent is an AWS Advanced Consulting Partner with the DevOps Competency. For more information please visit