SaltStack notes

Primitives #

Minions #

Minions: salt “clients”, aka hosts / provision targets. (not to be confused with the salt command-line client salt)

Master #

master: the salt server, drives the provisioning of minions. the salt cli client runs on the master. The master is an ensemble of several services and worker processes.

Grains #

Grains are basically facts in the ansible/puppet world.

Pillar #

Pillar is a global value/config storage, spelled out on the master. This is basically YAML which is laid out in folder hierarchies, which maps to environment config. It’s minion-specific and invisible to others, so useful for secrets.

State #

References to state, state trees, and .sls refer to YAML arranged in a folder hierarchy, similar to the Pillar layout. These files are stored on the Salt master. Basically .sls files are the core of actual configuration management, similar to ansible playbooks. The state tree may also contain raw files to be provisioned to hosts, etc. As in Ansible, raw YAML (a data structure) becomes program-like using inclusion/extension, and as in Ansible, Jinja is used under the hood to render templated data.

Advanced #

Eventing #

.. placeholder re: the event system ..

Site Questions #

Short list of intro questions that ought to be relevant for most site-specific installations/use-cases.

General Questions #

Unanswered Salt-specific questions on design, architecture, and implementation.

Compare and Contrast #

Architecture #

SaltStack architecture is well-thought out, and really very beautiful. But “using a distributed system to solve a problem means you now have 2 problems”. This additional complexity may really only be justified for “enterprise” bigness, and do we think that starts at a dozen servers, 100 servers, or 1000? Without lots of servers, an Ansible user accustomed to agent-free, server-free decentralized-by-default interaction with CM will probably be left wondering.. what is all this SaltStack architecture actually for?

Ansible is mostly a CM language, and only very slightly a CM driver, a value store, or a server. For most use-cases there is zero architecture to learn, but then again there is zero to leverage. (Ansible Tower is probably beginning to change some of this). Turning Ansible into something more scalable/distributed is mostly a matter of having many workers, and that can be done by leveraging an existing system for work distribution (like Jenkins slaves).

Speed, Eventing & Pull-mode #

This section is partially answering “what is the SaltStack architecture for?”, a question that was posed in the last section.

A primary aspect of SaltStack architecture is the queue, and the simplest consequence is having workers out-of-the-box, which also immediately implies speed. Presumably server/agent interaction also offers huge speed increases over ansible’s use of ssh as a ubiquitous transport mechanism.

The eventing mechanism

..placeholder..

CM as process of templating, inclusion, extension #

Jinja as a templating engine is all that ansible supports, whereas in salt this aspect is pluggable, for better or worse. As a result of supporting pydsl etc there’s no upper limit on how gnarly .sls files can get, and no guarantee about their portability between separate Salt installations.

Conclusion #

..placeholder..

References #

Quick links and further reading:

 
4
Kudos
 
4
Kudos

Now read this

On the importance of self-hosted backups.

A long time ago I built a pretty big storage computer (16TB) which I built because SSDs at the time were pretty small and most laptops came with only a single possible SATA drive bay for storage. I’m also quite a large proponent of... Continue →