Configuration Management System

Today in the Linux user’s glossary🐧 the term is — configuration management systems. As per tradition, we’ll give a definition of the term, find out what types exist and popular implementations of such systems. And of course briefly about the advantages and disadvantages🧐.

Please note that this theoretical post📗 precedes future materials on Ansible🛠. Among them: an article on installation and configuration, a playbook for basic configuration of a Linux server, a playbook for deploying an OpenConnect server and client, and so on. I have a lot of ideas😉.

Instead of an introduction: why are configuration management systems needed?

Resilience and stability. Configuration management systems reduce the risk of failures and errors. Automating processes eliminates the human factor and keeps the infrastructure state unchanged.

Reducing administration costs. CM systems automate routine tasks, reducing the load on administrators and allowing them to concentrate on strategic tasks.

Version control and repeatability. CM tools record the history of changes and allow you to quickly roll back to previous versions. This is important when problems arise or when there’s a need to return to a previous configuration.

Flexibility and scalability. CM systems provide flexibility when deploying infrastructure, making it ready for quick adaptation under conditions of increasing load or the introduction of new technologies.

blah blah blah😶🌫️

A Bit of History of CM Systems

Configuration management systems emerged in response to the need to automate repetitive tasks in server management and reduce the load on system administrators. In the early 2000s, with the growth of web applications and data scale, administrators faced a problem: infrastructure was growing, and managing it manually started taking too much time and human resources. Developers and engineers realized that server configurations, like code, could be recorded in repositories, and their modification and deployment automated. That’s when things really took off😳.

One of the first such systems was CFEngine, created by Mark Burgess in 1993. It laid the foundation for automated CM tools, establishing basic principles that are still used in more modern systems today. CFEngine was developed against the backdrop of UNIX systems and was built around the idea of maintaining server state. Over time, its ideas spread and influenced the emergence of other systems such as Puppet and Chef.

About Types of CM Systems

CM systems can be divided into two types: push and pull oriented. These approaches determine exactly how CM systems interact with the managed servers.

1. Push-oriented systems In push systems, the central management server sends commands to the target machines. This approach gives full control over the deployment process. One of the most well-known examples of a push system is Ansible.
2. Pull-oriented systems In pull systems, agents installed on the target machines regularly check in with the server for updates. This allows automating the configuration management process even in distributed systems. An example of such a system is Puppet.

Popular CM Systems and Their Features

1. Ansible (our everything🙃)
   • Written in: Python;
   • License: GPL 3.0;
   • Advantages: simplicity of configuration, no agents required (uses only SSH and Python), YAML support for describing configurations;
   • Disadvantages: sequential task execution can slow down work in large environments;
   • History: Created by Michael DeHaan in 2012, Ansible developed as a lightweight solution for DevOps tasks, and was soon acquired by Red Hat. Interestingly, despite its youth, Ansible turned out to be so successful that it became one of the CM standards.
2. Puppet
   • Written in: Ruby;
   • License: Apache License 2.0;
   • Advantages: a mature tool with a large community, supports a declarative configuration style, suitable for large companies;
   • Disadvantages: requires installing agents, difficult for beginners;
   • History: Puppet was developed in 2005 by Luke Kanies, when the need for configuration management for large-scale environments was already evident. Puppet Labs, the company behind Puppet, actively participated in shaping approaches to DevOps. The largest companies, such as Google, Oracle, Cisco, and others, built their infrastructures on Puppet.
3. Chef
   • Written in: Ruby (client side) and Erlang (server side);
   • License: Apache License 2.0;
   • Advantages: flexibility, Ruby support, and a high degree of customization;
   • Disadvantages: high barrier to entry for those unfamiliar with Ruby, need to install agents;
   • History: Chef, created in 2009, was inspired by Puppet’s ideas but provided more freedom through the ability to use Ruby for programming infrastructure. This helped the company Opscode (now Chef) attract specialists oriented towards programming to the tool. Chef was one of the first CM systems to actively support DevOps ideas.
4. SaltStack
   • Written in: Python;
   • License: Apache;
   • Advantages: high speed of operation, support for both push- and pull-oriented models;
   • Disadvantages: can be difficult to configure;
   • History: SaltStack was released in 2011 and attracted attention thanks to fast command processing and flexibility. Unlike other systems, SaltStack provides a hybrid approach, which makes it popular in high-load environments.

Conclusion

Configuration management systems have come a long way from the first developments in the 1990s to modern solutions such as Ansible, Puppet, Chef, and SaltStack. Each of these solutions has its own features and advantages that make them suitable for certain tasks and environments. The choice of a tool, as is often the case, depends on the needs, infrastructure, and level of management requirements🤵‍♂️.

Coming soon on the Raven blog site is an introductory note on the installation and initial setup of a configuration management system — Ansible. Preference is given to this CM for obvious reasons: configurations are described in convenient Yaml, and only SSH and Python installed on the remote server are required for operation. Although in fact you could do without Python, but that’s more for gourmets🤪.

Thanks for reading!

Useful sources

• Configuration Management | Wikipedia
• Ansible | Wikipedia
• Puppet | Wikipedia
• Chef | Wikipedia
• SaltStack | Wikipedia
• Configuration Management: Puppet vs. Chef vs. Ansible | Habr

👨‍💻And…

Don’t forget about our Telegram channel 📱 and chat

Or maybe you want to become a co-author? Then click here🔗

💬 All the best ✌️

That should be it. If not, check the logs 🙂