Configuration Management: Intro (90 Days of DevOps)

In this section of the 90 Days of DevOps series, we cover configuration management.

Why use configuration management?

Configuration management tools focus on using automation to help keep systems in a predefined, desired state. This “state” includes things like what’s saved in a system’s config files, which software packages are installed on a system, and which services are enabled/disabled.

Choosing to automate the configuration of these types of things can be much better than logging into individual systems and hand-modifying them. A manual configuration process can be prone to human error, especially in rushed situations like system recovery.

Another benefit of configuration management is that it can help with documenting important system configuration changes. Each important change to a managed system will most likely be reflected as an edit to one or more text files in a centralized IaC repository.

This all works hand-in-hand with DevOps ideals such as automation and efficient iteration, which is why this topic is covered here as part of the 90 Days of DevOps series.

Configuration management tools

A handful of configuration management tools have turned out to be especially popular over the years and have found widespread use. While the overall goals of these tools are fairly similar, their approaches to automation differ in some key ways.

Below is a brief bullet-point comparison of some of the most popular tools in use today:

Puppet

• One of the original configuration management tools in this list to gain widespread popularity
• Programming language it is built on: Ruby
• Approach to automation: Declarative (the user declares what the desired system state is, and lets the configuration management tool deal with how changes should be implemented)
• Pro: Has strong reporting and monitoring capabilities; its large user base can help make support easier to find when needed
• Con: Can be considered complicated to use, and requires knowledge of the Ruby programming language for some tasks

Chef

• Along with Puppet, this has also been in use for a comparatively long time
• Programming language it is built on: Ruby
• Approach to automation: Procedural/imperative (the user specifies how the configuration management tool should perform the desired configurations)
• Pro: A large number of Chef “recipes” are readily available for solving common user requirements
• Con: Its agent-based architecture means more effort is required to set it up before using

Ansible

• Unique in that it is comparatively simple to set up and use
• Programming language it is built on: Python
• Approach to automation: Procedural (imperative)
• Pro: Extremely widespread adoption; simple setup with no agent installation required on managed systems; built for ease of use
• Con: Its focus on ease of use means it is not focused on speed/powerful features like some other options

SaltStack

• Programming language it is built on: Python
• Approach to automation: Declarative
• Pro: Extremely fast/performant in large environments
• Con: Setup requires agent software pre-installed on every node

Of the above choices, we will be working with Ansible in the upcoming posts.

See you in the next post!

<< Back to 90 Days of DevOps posts

<<< Back to all posts