Disclaimer

Over the past month, I have listened to interviews with developers on all three products and heard the statement "consider [Ansible / Salt / StackStorm] glue." And now I, as a self-made amateur, will say with pleasure that in my garage is not the only pot with glue. I have 6 different types of glue for different applications, different bonded materials and environmental conditions. All these 3 products are in the same camp, and each can be successfully used to achieve completely different goals. Recently there has been a big overlap of functionality, which consists in the fact that they all penetrate into the field of network automation. The opinions below are mine , not my employer (who sells network infrastructure products and deployments worth billions of dollars).

I used all three products, in the development of two of them (Salt and StackStorm) made a significant contribution and partially contributed to the development of Ansible. Speaking frankly, the product with which I am least familiar is Ansible, but I talked with colleagues and collected information to fill in the blanks.

If you are going to scroll through the text to the end and find out which product I declared the winner, you will be disappointed. Think over your requirements and try more than one product.

Use under adult supervision

Ask yourself a few questions:

• What environments need to be supported? What is the set of servers and network devices?
• Who are my users? Hardcore system administrators, information security specialists, developers?
• How much I am ready to allocate for user development

With or without an agent?

Give it attention, it really matters. In this article, I am going to focus on the automation of devices and their orchestration. These devices can be routers, switches, firewalls, emitting electromagnetic waves of the next generation of circulators - does not matter. What really matters is that an agent will not be installed in their operating system. Ansible had a compatible solution — using SSH as a transport, so it fits well into the world of endpoint configurations, for which SSH is the least common denominator. SaltStack was created as a bus for a high-speed and safe minion (agent) that manages communication, but it also has an agentless mode of use. StackStorm came out on the playing field last and in its architecture does not give preference to any of the works. It supports agent-based tools through packages for Chef, Puppet, Salt, as well as its own SSH remote controls and built-in support for calling Ansible playbook scripts.

API

Another key difference is the API:

• Ansible provides a CLI interface, Ansible Tower (corporate version) has an API;
• StackStorm has a CLI, but also has a REST API for all components and services in the free version;
• Salt has both the CLI and the REST API (it is not enabled by default), it is also possible to use the “Enterprise API” as part of the Enterprise product, which includes features such as RBAC.

Ansible

Ansible is the brainchild of Michael DeHaan. The product was designed to automate monotonous server administration tasks in large environments. Michael was in the newly formed technology group RedHat, where he founded various projects (such as Cobbler ), and after leaving RedHat he founded Ansible (although Ansible is now owned by RedHat). An excerpt from Michael's Ansible Basics blog explaining the purpose of the project:

“We wanted to create another very democratic project to solve new open source problems in Red Hat, which could involve a wide range of developers. We remembered the busrpc. This project existed to fill the gaps between Cobbler and Puppet. Cobbler can prepare the system, and Puppet can add configuration files. But, since Puppet is too descriptive, it cannot be used to perform operations such as rebooting servers or performing “on demand” tasks at an intermediate time .

These “on demand” tasks evolved into Ansible playbooks, and then the Ansible ecosystem of ecosystems appeared and began its development.

Design

Ansible is simple, which is its main quality (this will immediately become clear if you look at the other 2 qualities). It has neither demons nor databases, and installation requirements are minimal. Ansible is simply installed on a Linux machine and that's it. You can define target servers in a static file, group them into meaningful sections, or use some kind of dynamic host discovery module (such as Amazon EC2 or OpenStack) to search for virtual machines based on an API call. Once the inventory has been taken, you can select host-specific or group-specific variables for use in playbooks. They are, again, stored in static text files.

Then Ansible will connect to the selected host or group and start the playbook. A collection of scripts (playbook) is a sequence of Ansible modules for execution on remote hosts written in YAML.

Connecting to a remote host is a bit like a well-planned military exercise : he entered, did his job and left.

Ansible works according to the following algorithm: connecting to a server via SSH (or WS-Man / WinRM for Windows), copying Python code, executing and deleting itself.

Architecture

The Ansible architecture is straightforward: there is an application running on the local computer and tasks performed on the remote host that support SSH communication and files transmitted via SCP / SFTP. Ansible does not have a server-client architecture, unlike the other two products, so task parallelization occurs on a local machine, but does not scale to multiple servers (if you do not use Tower).

Ansible when managing remote machines does not leave their code on them, so the question of how to update Ansible when upgrading to a new version is not really worth it.

Extensibility

Modules in Ansible are really easy to develop, as, indeed, in the other two products. Read the style guide if you later decide to try to mix your solution into the open source product repository instead of refactoring it.

#!/usr/bin/python import datetime import json date = str(datetime.datetime.now()) print json.dumps({ "time" : date }) 

 ansible/hacking/test-module -m ./timetest.py 

You should see something like this:

 {"time": "2012-03-14 22:13:48.539183"} 

In modules, you can define your own code to form “ facts ” about a remote host at the “ gathering ” stage, which can be used by your own or third-party modules. This can be implemented in the form of viewing both installed files and configuration to determine how to configure the service.

Corporate support

Ansible Tower is a corporate version (Enterprise) that turns Ansible command line into a service with a web interface, a scheduler and a notification system.

Task Manager

It also has a user interface for playbooks, through which you can automate the deployment of cloud infrastructure, and then automatically add virtual machines to the list.
It should be noted that the task scheduler, cloud deployments and the server are features of the free versions of both Salt and StackStorm.

Networking support

Ansible's section on network support is the most comprehensive among all three products and covers all major network equipment and platform vendors. In Ansible it is possible:

• Automate the configuration of everything related to network equipment - from specifying systems for connecting to configuring basic services, all with the help of modules and playbooks for a specific network platform.
• Test and verify the current state of the network, perform or postpone the process of collecting facts about the existing configuration.
• Continuously check compliance with changes to network settings.

Ansible supports Arista, Cisco (all programmable platforms), F5, Juniper and other manufacturers. Only in Ansible support is mainly provided and provided by vendors, and not by the community. At the moment, these are the best APIs, the greatest functionality and work with the latest platforms (since newer versions are supported).

Strengths

• Very quick and easy to get started.
• Many examples, documentation and modules from the community.
• Ansible Tower implements features for large enterprise deployments.
• Network modules supported by vendors.

Weak sides

• In the absence of proper control, operators can save playbooks and SSH keys to their own laptops. Not quite a flaw in Ansible, but constant monitoring is required.
• No history of automation events, control over the target host is maintained only for the duration of the playbook, not more. Cannot be used for long-term tasks.

Stackstorm

I used StackStorm from version v0.11 (early pre-beta) up to the latest version v2.2. This is a sophisticated multi-purpose platform, just like Salt. Although the story about it takes time, but still often the listener creates the wrong impression about the system. I see in this both strength and weakness. Weakness, because the complexity of the system can force you to abandon the deployment altogether or use a simpler, but incorrect solution where StackStorm would be a good alternative (often in such cases you even write your own solution from scratch). The strength is that as soon as it becomes clear how to use strengths, the system becomes truly flexible.


Interface StackStorm

Design

The core of StackStorm is an executable engine with pluggable rules, designed as a deeply tunable IFTTT service (if-this-then-that, "if it is, then that"). You can configure StackStorm to respond to events that occur by running a simple “action” (command) or a complex workflow. Workflows are available in two versions: as ActionChain - action chains (proprietary DSL workflow) or as a workflow on OpenStack Mistral, the engine of which is based on YAML.

StackStorm also includes a service for “chatops”, with which you can initiate workflows from events or chat platform messages (for example, Slack).

The list of basic components StackStorm:

• Sensors - Python plug-ins for inbound or outbound integration, receiving or observing events. When an event in the external system is handled by the sensor, the StackStorm trigger will fire.
• Triggers - views of external events in StackStorm. There are common triggers (for example, timers and webbooks) and integration triggers (for example, an alarm in Sensu or a task update in JIRA). A new type of trigger can be determined by writing a sensor plugin.
• Actions are outgoing StackStorm integration. There are common actions (ssh, REST call), integrations (OpenStack, Docker, Puppet) or custom actions. Actions are either Python plugins or other scripts that integrate into StackStorm by adding a few lines of metadata. Actions can be invoked directly by the user through the CLI or API, or used and invoked as part of the rules and workflows.
• Rules bind triggers to actions (or workflows), applying matching criteria and binding the information obtained from the trigger to the input of actions.
• Workflows combine actions into “uber-actions”, defining the order, conditions for the transition, and transferring data between them. Most automation solutions contain more than one step and, therefore, require more than one action. Workflows, like "atomic" actions, are available in the action library, can be called manually or started according to the rules .
• Packages are content placement units for deployment. They simplify managing and sharing plug-in content by StackStorm by grouping integration tools (triggers and actions) and automation (rules and workflows). A growing number of packages are available in the StackStorm community. The user can create their own packages, post them on Github or send them to StackStorm Exchange .
• An audit trail with complete information about the context launch and the results of actions launched manually or automatically.

Design

StackStorm consists of a number of services that use a message queue (rabbit) and a data warehouse (mongo) to save their state and exchange data among themselves. StackStorm also has a web interface (yes, even in the free version!), Which allows you to customize rules, perform “on demand” actions and check the audit log.

Architecture

Unlike Ansible and Salt, StackStorm was not designed to set up workstations or communications. StackStorm includes packages for Salt, Chef, Puppet and Ansible, so if you need to use Chef for the agent and configuration management system, use StackStorm to call API-based services, such as Sensu or Kubernetes. This is an easily achievable and obvious solution. In Salt, there is still a concept of execution on the end machine or on the master (optional). If you want to call the Kubernetes API, then the question of which computer caused the API becomes controversial. The same goes for network device configuration.

MongoDB can be scaled using well-documented templates, the same goes for RabbitMQ. The services themselves were developed with the HTTP / RESTful API and can use load balancing for scaling. Roles can be deployed on a single server or distributed across multiple servers depending on needs.

I really like StackStorm extensibility, this is definitely a key advantage over the other two products. StackStorm extension points are called packages . They are standalone, can be stored in Git, and manage their dependencies through virtual Python-level package environments. When you install the package, you specify the Git URL or HTTP URL, (optional) credentials, and StackStorm already downloads, configures, and installs the package.

If StackStorm were a programming language, it would be strongly typed . For actions, types of all input data are specified, for triggers fields and types are specified. This makes it easy to predict what will be returned by a third-party extension, and is a unique feature of StackStorm.

Unlike Salt and Ansible, StackStorm does not contain any extensions on delivery , all of which must be installed individually. This facilitates deployment and simplifies dependencies.
When designing the integration mechanism for StackStorm, you can create sensors, actions, and workflows in one definition. The Salt and Ansible modules are autonomous. Thus, if an extension (for example, Salt) includes the Beacons, Execution Modules, and Status Modules, then they have nothing in common except for the name and the author. This can create problems when managing pip dependencies.

The solution to this problem in StackStorm is that each package has its own requirements.txt file, as well as a YAML file that describes the purpose, requirements, and version of the package. You can upgrade the package in a linear fashion while maintaining the existing configuration. Packages also contain a template configuration, in contrast to Ansible and Salt, in which the module configuration format is kept only in the documentation, making them more prone to user error. In addition, you often have to look at the module code if the developer did not bother to document the configuration parameters properly.

Another unique feature is that ChatOps aliases (chat commands) are built into the packages. Therefore, when installing, for example, the NAPALM package, all chat commands for NAPALM are also installed.

Corporate support

StackStorm is an open source Apache-2 licensed product hosted on GitHub. StackStorm is owned by Brocade (which recently sold part of its assets, and part of StackStorm is now owned by Extreme Networks).

When licensing StackStorm, a product called “Brocade Workflow Composer” is purchased, and the license holder receives additional functionality, as well as Enterprise-level-support. The system I worked with, deployed in a production environment, was licensed, and their support team left me with the impression of being responsive and knowledgeable. You also get RBAC, in which you can specify for each level of actions, who and what actions have access to.

Brocade Workflow Composer

Networking support

You're lucky if you use Brocade VLX or SDX, as they are well supported , which is to be expected.

In April 2017, they combined support for the NAPALM library and the cross-platform Python abstraction pack for Cisco, Juniper, Arista, and other vendors. Now you can use NAPALM functionality in terms of routing, interfaces, BGP peering and some other great features. Matt Oswalt (co-author of O'Reilly's book on network automation) wrote a good blog about progress in this direction.

Demonstration of NAPALM for StackStorm

Strengths

• The free default web interface is easy to use and does not require deep knowledge of Python or DevOps.
• ChatOps integration is built in, works out of the box (using Slack, the API key is simply deployed) and supports many other chat platforms.
• OpenStack Mistral is really powerful, and if you master it, it will be possible to immediately cover several DevOps tools, it is easy to create branches and loops.
• Brocade Workflow Composer is a great way to get non-developers to use the system.

Weak sides

• Does not have as many expansion packs available as Salt and Ansible. First check to see if the packages are available for your systems and API and what features are included in them.
• The OpenStack Mistral system is still rather poorly documented, there is a lot of trial and error in the syntax of YAQL queries.

Salt

First of all, Salt is a product, SaltStack is a company. So when I talk about Salt, I talk about Salt Open, an open source version.

Salt has a massive list of constituents, at first (and when I say “at first”, I mean “first year”), it can be really amazing. Salt performs many functions, therefore, as a rule, comparing Salt with Ansible, Salt-fans say “yes, but he does much more”. As with StackStorm, it works for and against Salt. If I just told you to bring grains (crystals) from the mine, you would think that I mean Tolkien's novel, but as soon as you know what a Salt mine is in Salt terminology, everything will become obvious.

Design

Salt was born as a distributed system for remote execution of commands and request data at remote sites or minions . Remote execution is possible either on individual nodes or on groups using arbitrary selection criteria - “ targeting ”.

Salt has been expanded to a configuration management system capable of supporting remote nodes in predetermined states (for example, ensuring that certain packages are installed on them and certain services are running). Salt has a lot of components , and I’m just sure I missed something!

• A master server that runs basic services for communicating with the Salt minions. It also contains a keystore for encrypting between it and the minions.
• Minions are agents that use the Salt micro version for local execution and communication with the master.

• The engines - they are Salt Engines (salt engines) - are external processes, executed for a long time, that work with Salt.

  
  
• States or formulas are files containing YAML and template data for customizing minions. The template mechanism is also very flexible . It is not limited to Jinja support, but also supports chetah, genshi, mako (very important for those who have experience with Puppet), wempy, or even pure Python.

Minions (proxy or regular) can be addressed using grains (grains, crystals), pillars (pillars, columns) or identifiers. There are other plug-ins for targeting , as well as the ability to create your own, based on something like SQL-query or KVP-storage.

• Grains - Salt contains an interface for getting information about the system below. It is called the interface of "grains", because it is a "salt", consisting of "grains" of information. Grains are collected for the operating system, domain name, IP address, kernel, OS type, memory, and many other system properties. The grains interface is available for Salt modules and components, so the necessary minion commands are automatically available in the respective systems.

  
  
• Pillars is a Salt interface designed to provide global values ​​that are distributed among minions. Pillar is a free-form data resource, which can be JSON, YAML or other required and can be stored in files or externally . This is a unique Salt property that allows it to be integrated with other systems in which a common data warehouse would be useful (for example, ITSM or a resource registry).

To retrieve data, you can also use data from minions and store them in Salt mine (salt mine). In the future, this data can be used in other tasks, such as the configuration of states based on templates. Unlike Ansible (which only supports YAML), it can be implemented in different formats.

Architecture

Salt architecture is based on the principle of the wheel hub and the spokes (fan structure). Some very large deployments use several wizards, but this is quite rare. Wizards can easily scale to many thousands of nodes in part because of the lightweight ZeroMQ message bus. Other deployment models:

1. Installation without a wizard.
2. Hierarchical wizards that are interconnected with syndics.

The wizard contains status files that are usually placed on a shared storage volume. They are configured as a tree to allow targeting to define server groups for configuration and environments / applications for deployment.

The event-based Salt system uses beacons. Like the StackStorm sensor and trigger system, Salt beacons trigger events to the message bus, which can then be processed in the reactor (on the master). The mechanism of the rules in the reactor is rather crude compared to StackStorm, since usually the state or execution command is activated behind the beacon triggering the event. However, beacons work on minions, so if events are detected on servers, everything is very clear. Since StackStorm and Ansible do not have agents, this will be a unique feature of Salt.

Thorium (thorium) - complex reactor for Salt, was included in the last release as an experiment and, perhaps , will be supported in future releases. Thorium adds support for more complex rules and event collection.

Extensibility

Everything in Salt is extensible, up to modules that display the results of execution in the CLI. This is a big plus of Salt, as you can easily implement your own changes without having to maintain a parallel fork in the main project. Each function in Salt is also pluggable.

The most common scenarios for expansion can be the development of a state module (to describe how a piece of software or a service should be configured) or an execution module (code to interact with an API or system). Both types of modules can be written in a relatively small pattern, both are well documented and can be tested using a good built-in test environment. You can perform nodal checking of modules using PyTest, even without being on the master or without a working master at all. Linux testing is required for integration testing, although modules with small hacker skills can also be run on OSX (there is no question about Windows, as is the case with StackStorm with Ansible).

It’s possible to either maintain your standalone package or directly contribute to the Salt project on GitHub. , . 3-5 , , Salt « », .

Salt , SPM , (state files). , , ( ).

Salt . - . ( Salt), , , .

«Salt Open» — , "Salt Enterprise", , :

• - , , LDAP;
• ServiceNow, ServiceNow ITSM;
• RBAC LDAP ();
• «Enterprise API», Enterprise REST API.

Salt , ZeroMQ , , Salt. Salt « ». - — — , SSH, HTTP . , , . Puppet ( , ), , , , . , . 40 . -, Python, . Salt SaltConf.

:

• JunOS (Juniper);
• NXOS (Cisco);
• Cisco NSO ( NETCONF Cisco);
• NAPALM.
  
  Salt NAPALM Cloudflare. NSO NAPALM , NSO Cisco, , .

NAPALM Salt

• Salt , ( salt-ssh ).
• ZeroMQ.
• Windows, Linux .
• (, LinkedIn) .
• Salt API- .

Weak sides

• , , .
• , . . pip-.

Conclusion

?

. Salt StackStorm . StackStorm , (), , , . Salt — , , . . Ansible ( ) .

, Ansible , ( Brocade StackStorm) . , Ansible . NAPALM NSO StackStorm, Salt , Arista, JunOS (Juniper), Cisco APIC-EM, NXOS ..

Ansible — (, , ). CLI - . (, ), , . , , .

Salt , . Hashicorp Vault, . SQL, , , « ». , , .

Security

Ansible Salt, Salt , Ansible SSH . Ansible, , , (, ). Salt . , grains . StackStorm MongoDB, , , , .

Training

, , . Salt Ansible , StackStorm — . Salt (RedHat) Ansible , StackStorm — (). Salt Ansible PluralSight, .

Salt, StackStorm Apache-2, Ansible — GPLv3. OSS, - «TLDR Legal». Salt SuSE ( - OSS).

Skills

( ), Ansible DevOps . , Ansible , Salt StackStorm. DevOps , , .

?

, . , , DevOps, , , .

, , , — .

: Salt, StackStorm, Ansible .

Dimension Data, , , Python, opensource, .

Links

1. Ansible vs Salt (SaltStack) vs StackStorm .