DevOps tools: What SaltStack is good for, and what tasks can be solved with it

In our blog on Habré, we continue to talk about building a DevOps culture in a company — we previously described the Continuous Integration system we created, as well as the mechanism for publishing and licensing software . Today we will discuss the choice of a system for managing the environment, as well as the delivery and deployment of software on servers.

What is the problem

For a better understanding of the hierarchy we use, you can think of it as a mix of type3 and type5 according to this classification. We have our own development, our services, we provide them to other teams, and the “iron” part is supplied to us by OPS.

Historically, in our company, the approach to process automation has been somewhat chaotic. When a need arose to automate one or another type of action on the light, crutches were often born, that is, we wrote a lot of our own scripts to perform actions like virtual machine cloning and installing software on them.
')
This could not go on forever - with the growth of the company and the number of its products, we faced the need to create a more reliable solution to automate typical actions and prepare the environment for the work of the services used.

It became clear that we would need a specialized automation platform, with the help of which it would be possible to solve the tasks. We chose from three options - Puppet, Ansible and SaltStack.

What and why we chose

As a result, the preferences were as follows:

• Puppet , in spite of all its popularity, “did not go” here - the main reason for using Ruby, while we in the company prefer Python. In addition, the input threshold for starting the work with the product was rather high due to the complex logic of describing the deployment scenarios.
  
  
• Ansible was not as monstrous as Puppet, it was much easier to deal with it. It didn’t fit due to the lack of a client - tried it before the second version was released).
  
  
• SaltStack - has become the most convenient option for us. The ability to choose between modes of operation (master-minion, masterless, ssh), the ability to store the history of operations performed in a convenient format. And due to the fact that our company has considerable expertise in the field of Python, we can quickly write our own modules, this greatly expands the capabilities of the system.

Consider the system architecture. In SaltStack terminology, the server of the system is called a master (master), and the client is called a minion.

As a transport protocol, the system uses the ZeroMQ permanent encrypted connection technology - when executing a large number of scenarios, this gives a significant increase in speed. An alternative RAET transport is under development. We didn’t use them, if you have any advice / cautions on it, we will be glad to see them in the comments.


Here and below, the images are taken from the official documentation of SALTSTACK COMPONENTS

Grains is a unit of system information, such as an IP address. The local equivalent of facts at Ansible and Puppet.


State files are an analogue of playbooks in Ansible. In them with the help state.modules , it is described, to what state it is necessary to lead the minion.


In addition, in SaltStack there is the concept of top-file . This is, in fact, a dictionary that helps to conveniently group minions by some attributes and indicate which steats or roles (if you use the role model) to play. For each environment (dev, test, prod) there can be a top-file.


Also, the system has a repository of data transmission ( Pillar ) and secret information, such as passwords, protected - the use of this mechanism prevents errors in which information about logins and passwords can be accidentally “flooded” in the wrong place. In the role of a source of information can be any of the modules . For each environment (dev, test, prod) there can be a pillar-file.


Execution Modules - can be compared with Ansible in ad-hoc mode. Needed for manual work with agents.


Often the Salt Mine is deprived of attention, which, in contrast to the “grains”, can be updated at an arbitrary interval. The tool allows you to use the grains of one minion at the time of the execution of the state on another. In the article SaltStack: Creating dependent or referring service configurations , the case is well described. The author (@ eugenechepurniy ), there are other articles on SaltStack.

Salt Returners - by default, the result of execution on minions is returned to the “master”. Returner allow you to override this output. Full list of “reterners” .


Another useful feature missing in other popular SCM systems is Reactor . This module acts as a “listener” that filters tagged messages and initiates some actions on this.


SaltStack can work without an agent - via SSH. Recently on Habré there was an article with examples of its use.

The official documentation has excellent step-by-step tutorials on using the system. I recommend starting with SaltStack Fundamentals

Where we use SaltStack

We at Positive Technologies solve the following tasks with SaltStack:

• setting build agents;
• monitoring setup;
• preparation of the test environment;
• container management;
• delivery of licenses (products of the company);
• delivery of updates (company products);
• VM life cycle management.

Of course, SaltStack has some disadvantages. For example, very heavy documentation, which is difficult to understand right away, as well as the developers' love to create completely new analog terms for things familiar to other systems (the same minions instead of clients).

Selecting SCM is similar to choosing an editor. Each company has its own needs.
We recommend to try several options and choose "your", which will cover your Wishlist.

PS The story about our experience of using SaltStack was presented in the framework of DevOps-mitap, which took place recently in Moscow.



The link presents presentations of 16 reports presented during the event. All presentations and video presentations will be added to the table at the end of this topic-announcement .

Author : Dmitry Miroshnichenko