Review: Puppet, Chef, Ansible, Salt
Leading configuration management tools have a different approach to server automation.
From the translator : in connection with the imminent introduction of one of the systems described in this article, we have to study previously unknown products. I wanted to translate, since I did not find such review articles in Russian (I do not exclude that I was looking badly), and, I hope, someone will come in handy. For possible errors and inaccuracies of the translation, please do not kick with your feet.
The rapid development of virtualization, coupled with an increase in the capacity of servers that meet industry standards, as well as the availability of cloud computing, has led to a significant increase in the number of servers that need to be managed, both inside and outside the organization. And if once we did this with the help of racks with physical servers in the data center on the floor below, then now we need to manage a much larger number of servers that can be distributed across the globe.
At this point, configuration management tools come into play. In many cases, we manage groups of identical servers running the same applications and services. They are hosted on virtualization systems within the organization, or they are launched as cloud and guest in remote data centers. In some cases, we can talk about a large amount of equipment that exists only to support very large applications or about equipment serving a myriad of small services. In any case, the ability to “wave a magic wand” and force them all to fulfill the will of the system administrator cannot be devalued. This is the only way to manage huge and growing infrastructures.
')
Puppet, Chef, Ansible and Salt were conceived to simplify the setup and maintenance of tens, hundreds and Jae of thousands of servers. This does not mean that small companies will not benefit from these tools, since automation usually makes life easier in infrastructure of any size.
I looked closely at each of these four tools, examined their design and functionality, and am convinced that although some are rated higher than others, there is a place for everyone, depending on the implementation goals. Here I am summarizing my findings.
Puppet enterprise
Puppet is considered the most used of the four. It is most complete in terms of possible actions, modules and user interfaces, presenting a complete picture of the data center, covering almost every operating system and providing utilities for all major operating systems. The initial installation is relatively simple; it requires the deployment of the parent server and client agents on each managed system.
The command line interface allows you to download and install modules using the puppet command. Then, changes in the configuration files are required to configure the module for the required task, and clients who need to receive instructions will receive them the next time they contact the head server or via a request from the server that initiates the change process immediately.
There are also modules with which you can configure virtual and hosted in the "clouds" of servers. All modules and configurations are built using an embedded, ruby-based language, or ruby ​​itself. This will require some programming knowledge, in addition to system administration skills.
Test results in a test data center
| Availability
| Compatibility
| Control
| Scalability
| Performance
| Cost of
| The overall result
| |
| 20%
| 20%
| 20%
| 20%
| ten%
| ten%
| ||
| AnsibleWorks Ansible 1.3
| 9
| 7
| eight
| eight
| 9
| 9
| 8.2
Very good |
| 20%
| 20%
| 20%
| 20%
| ten%
| ten%
| ||
| Enterprise Chef 11.4
| 9
| eight
| 7
| 9
| eight
| 9
| 8.3
Very good |
| 20%
| 20%
| 20%
| 20%
| ten%
| ten%
| ||
| Puppet Enterprise 3.0
| 9
| 9
| 9
| 9
| 9
| 9
| 9
Fine |
| 20%
| 20%
| 20%
| 20%
| ten%
| ten%
| ||
| SaltStack Enterprise 0.17.0
| 9
| eight
| 9
| 9
| 9
| 9
| 8,8
Very good |
Puppet Enterprise has the most comprehensive web interface of all, allowing you to control managed nodes in real time using pre-built modules and cookbooks hosted on the host servers. The web interface is good for management, but does not allow for “fine-tuning” of the modules. The reporting tools are well developed, providing in-depth detail about the behavior of agents and the changes made.
Enterprise chef
Chef is similar to Puppet in terms of its overall concept; it also has a head server and agents installed on managed nodes. In addition to the head server, installing Chef also requires a workstation to manage it. Agents can be installed from a workstation using the utility knife, which uses the SSH protocol for deployment, easing the installation burden. After that, the managed nodes are authenticated with the head using certificates.
The Chef configuration is closely related to the Git version control system, so knowledge of how Git works is essential to work. Like Puppet, Chef is ruby-based, so knowledge of this language is also required. As in the case of Puppet. The modules can be loaded or written from scratch, and then installed on control nodes, in accordance with the required settings.
Unlike Puppet, Chef does not yet have a well-implemented push function, although a beta version of the code is available. This means that agents must be configured to periodically synchronize with the parent server, and the changes cannot be applied immediately.
The web user interface is functional, but does not provide the ability to modify configurations. It is not as complete as the Puppet Enterprise web interface, it is inferior in building reports and some other functions, but it allows you to keep track of equipment and organization of nodes.
Like Puppet, Chef has a large set of modules and configuration recipes, mostly ruby. For this reason, Chef is well suited for development-oriented infrastructures.
AnsibleWorks Ansible
Ansible is more like Salt than Puppet or Chef. Ansible focuses on optimization and speed, and does not require the installation of agents on managed nodes - all functions are performed over SSH. Ansible is written in python, unlike Puppet and Chef, based on ruby.
Ansible installation can be accomplished by cloning a Git repository onto the parent server. Following this, nodes over which management is required are added to the Ansible configuration, and authorized SSH keys are “tied” to each node, relating to the user on whose behalf Ansible will be launched. Once this is done, the head server can connect to the nodes using the SSH protocol and perform all the necessary tasks. To work with systems that do not allow SSH root access, Ansible uses credentials that allow you to perform actions on behalf of the superuser using the sudo command.
Ansible can use Paramiko - an implementation of the SSH2 protocol in python, or a standard implementation of SSH, but there is also an accelerated mode for faster and more extensive communication.
Ansible can be run from the command line without using configuration files for simple tasks, such as checking that a service is running, or for updating triggers and reloading. For more complex tasks, configuration files are created using YAML and are called “scripts” (playbook). They can be used templates to extend the functionality.
Ansible has a set of modules that can be used to manage various systems, as well as "cloud" infrastructures, such as Amazon EC2 and OpenStack. Additional modules can be written in almost any programming language, provided that the output will be in JSON format.
The web interface is available as AnsibleWorks AWX, but is not directly related to the command line interface. This means that the configuration elements specified via the command line will not appear in the web interface until the synchronization cycle is started. You can use the built-in utility for this, but you need to schedule it to run regularly. By itself, the web interface is quite functional, but not as complete as the command line interface, so you will either switch between the two, or just use the command line.
SaltStack Enterprise
Salt is similar to Ansible in that it is based on the command line. It uses the push method to communicate with clients. It can be installed via Git or through the package management system on the core server and clients. The client makes a request to the head server, and if it gives permission, it allows you to manage this node using an agent (in terms of Salt - minion).
Salt can communicate with clients using the SSH protocol, but scalability is greatly expanded by client agents. Also, Salt includes an asynchronous file server to speed up agent maintenance, allowing you to build highly scalable systems.
As in the case of Ansible, you can issue commands, such as starting services or installing packages directly to agents from the command line, or you can use configuration files in the YAML (state) format to handle complex tasks. There are also centrally located datasets (pillar) to which configuration files have access during operation.
You can request configuration information — such as kernel version or detailed network interface information — directly from agents via the command line. Agents can also be specified through the use of inventory items, called “grains”, which make it easy to send commands to specific servers, regardless of the configured groups. For example, one command can send a request to agents located on servers with a specific kernel version.
Like previous products, Salt provides a large number of modules for a variety of software, operating systems and cloud services. Auxiliary modules can be written in python or PyDSL. Salt provides the ability to manage and Windows-nodes, as well as Unix, but more designed for Unix and Linux systems.
The Salt - Halite web interface is too new and not complete, as are the user interfaces of other systems. With it, you can view the system log messages and the status of managed nodes, and it is possible to execute commands on them. This instrument is being actively developed, and promises significant improvements, but for now this is a bare “skeleton” and contains many bugs.
The biggest advantage of Salt is its scalability and flexibility. You can have several levels of host servers organizing a connected structure to provide load balancing and increase fault tolerance. The top-level headend servers can manage the hierarchy and their subordinate nodes. Another advantage is the peer-to-peer messaging system, which allows subordinate nodes to ask questions of the head, and they can receive answers from other servers to complete the picture. This can be useful if the data to complete the configuration of the node are in the real-time database.
Puppet or Chef? Ansible or Salt?
While Puppet and Chef are focused on developers, Salt and Ansible are more suited to the needs of system administrators. Simple interface and user-friendliness Ansible suits the thinking of system administrators in companies with a large number of Unix and Linux systems. Ansible is quick and easy to run out of the box.
Salt is the most reliable of the four and is also suitable for system administrators. Well scalable and possessing sufficient functionality, only the web interface leaves much to be desired.
Puppet is the most mature and probably the most affordable of the four products in terms of ease of use, although solid ruby ​​is strongly recommended. Puppet is not as optimized as Ansible or Salt, and its configuration at times may resemble a “literacy tag”. Puppet is safer for heterogeneous environments, but you may find Ansible or Salt more suitable for larger or more homogeneous infrastructures.
Chef is a stable and well-developed solution, but so far it does not reach the Puppet level in terms of basic functions, but it can be expanded. Chef may be difficult for administrators to learn with inadequate programming skills, but may be suitable for software development companies.
If you are interested in learning more about these products, read the full reviews:
Review: Ansible orchestration is a veteran Unix admin's dream
Review: Chef cooks up configuration management
Review: Puppet 3.0 pulls more strings
Review: Salt keeps server automation simple
General view
| Puppet 3.0
| Chef 11.4
| Ansible 1.3
| Salt 0.17
| |
| Behind
|
|
|
|
|
| Vs
|
|
|
|
|
| Prices
| Free open source version; Puppet Enterprise costs $ 100 per computer per year
| Free open source version; Enterprise Chef is free for 5 computers, $ 120 per month for 20 computers, $ 300 per month for 50 computers, $ 600 per month for 100, and so on
| Free open source version; AWX is free for 10 computers, then $ 100 or $ 250 per computer per year, depending on support
| Free open source version; SaltStack Enterprise costs $ 150 per node per year, with discounts depending on the number and volume licenses
|
Posted by: Paul Venezia
Original article
Source: https://habr.com/ru/post/211306/
All Articles