For a few years, applications offering to deploy configurations and remotely execute commands on equipments have been more and more popular. The increase in the number of websites, web applications, and Internet users, as well as the services diversification massively raised the size of the machine parks managed by hosting providers and other services providers. It is relatively simple to handle the configuration of 10 machines by treating them one after the other, but it cannot be done for 1000 machines.
That is why NBS System now uses the open-source tool Salt to automate the management of its machine park, thanks to the remote execution of commands and the automation of configuration deployments.
Why choose SALT ?
Before using Salt, NBS System used Fabric, an open-source tool allowing to remotely launch commands through SSH. The drawback of Fabric was that SSH connexions are relatively slow, thus the actions and manipulations made through this tool took a long time. Over time, with the development of the company and the acquisition of new clients, time became more and more important as a resource, and we felt the need for a tool that can automate configuration deployments.
Our experts thus looked for another tool, giving the opportunity to both remotely execute commands and deploy configurations… as well as respecting other major constraints. The first one was not to use SSH connexions, which were not efficient enough. The chosen software also had to be free, written in a language known and mastered by our internal resources, with an active community that can quickly react in case we need help.
As you probably understood, Salt, an open-source tool written in Python, answered all of our requests. After having tested it, we adopted it and deployed it on all of our park. Our team also takes part in the project : it produced fixes and modules of the tool.
Remote command execution
Salt works in a pretty simple way. There is a Salt server, the master, from which all actions are taken. “Salt minions” are installed on all the machines in the park; they connect to the master through dedicated ports, and wait for instructions from it.
The Support teams thus work on the master server and can send Salt commands (install a packet, create a new user…) towards a chosen machine, or on any machine of a given environment. This industrialization level allows, for instance, to make sure that the master/replicate servers are homogeneous, since a single command is sent to all the machines.
But Salt becomes particularly interesting for the massive deployment of configurations. When a machine is created on our park, it starts from an image containing a minimal version of Debian, and its Salt minion.
Depending on the role of the machine, the applications that have to be installed are, of course, different… That is why our Research & Development team created configuration files describing, depending on the role of the machine, which applications and matching configuration have to be deployed. At the start, the Salt minion will thus look for the applications and configurations matching the machine’s role and automatically install them on it. Remains one issue: how can the Salt minion know what the role the machine is ?
For that, our team developed a Salt module interfacing with our client information database, Guy. The latter lists all the machines in our park, and the services provided by these machines: this is the information that is gathered by Salt, through this module. It includes precisions about the PHP, MySQL or Java versions that have to be used on these machines. To create a new machine, the Support team has to fill it in into Guy, write its role and other useful information, then launch the deployment. Salt then gets the information from Guy, and automatically handles the deployment according to the matching configuration. (Discover in details how a deployment works in our article about hypervisors).
Today, this automation is set up for the most important and most common roles in our park (about 80% of the machines). The other roles are currently being automated. However, it takes time, because all the possible combinaisons of machine, versions, etc. have to be tested before starting using these developments in a production environment!
Salt and flexibility
To conclude, the main advantage of Salt is its flexibility: its basic postulate is to be very modular and easily scalable. It enables the tool to easily interface with diverse applications, and gives its users the opportunity to build a powerful tool. By the way, Salt won a “InfoWorld Technology of the Year Award” in 2014!
Technical source : Emmanuel Seyman