Salt

Salt is an event-driven automation tool and framework built on Python, designed to deploy, configure, and manage complex IT systems. It is used for configuration management to ensure infrastructure components operate in a consistent desired state.

Key capabilities include:

• Configuration Management: Managing OS deployment, installing software, and managing servers, VMs, containers, databases, and network devices.
• Orchestration: Automating routine IT processes like scheduled downtimes or application upgrades.
• Self-healing Systems: Creating systems that automatically respond to outages or administrative events.

Salt is pluggable and customizable, supporting nearly any operating system and various network device vendors.

Salt is a dual-purpose system designed for large-scale infrastructure management:

1. Configuration Management System: Maintains remote nodes in defined states (e.g., ensuring specific packages are installed or services are running).
2. Distributed Remote Execution System: Executes commands and queries data on remote nodes. Commands can be targeted at individual nodes or groups of nodes using arbitrary selection criteria (targeting by system properties rather than just hostname).

Salt is designed for high-speed, parallel execution across thousands of servers using a simple server/client topology.

The salt-key command is used on the Salt master to manage the public keys used for authentication with Salt minions. When a minion first connects, its key is sent to the master in an unaccepted state and must be manually accepted before communication can occur.

Minion Key States

• unaccepted: The key is waiting to be accepted.
• accepted: The key is accepted and the minion can communicate with the master.
• rejected: The key was explicitly rejected; the minion cannot communicate with the master.
• denied: The key was automatically rejected (e.g., due to duplicate IDs or rebuilt minions with new keys).

To change a key's state (e.g., from rejected to accepted), you must first delete the existing key using -d and then accept it.

salt-key [ options ]

Salt Virt (introduced in Salt 0.14.0) is an advanced cloud control system that allows you to manage private cloud virtual machines (VMs) directly with Salt. It is hypervisor-agnostic but currently has full implementation for KVM via libvirt.

Salt Virt facilitates fast, scalable cloud management, including complex VM networking, image/disk management, and VM migration (with or without shared storage). It can manage clouds ranging from specialized SAN-backed hardware to commodity Linux desktop clusters.

The Salt Package Manager (SPM) is a system designed to package Salt formulas—including states, pillars, file templates, and other associated files—into single files for simplified distribution to Salt masters.

SPM operates through three primary components:

1. Packaging System: Used to bundle formula files into a single package.
2. Repo System: Stores the created packages and metadata, making them accessible via http(s), ftp, or file URLs. Repositories can be hosted on a Salt Master, a Salt Minion, or any other system.
3. Salt Master: Configured via Salt master settings to point to one or more SPM repositories, allowing masters to install entire formulas quickly.

A Salt Syndic is an intermediate node type used to increase scalability and structural flexibility in Salt topologies. It acts as a specialized passthrough Minion.

A Syndic node runs two daemons on the same system:

1. salt-master: Controls a group of lower-level Minion nodes.
2. salt-syndic: Connects the local salt-master to a higher-level Master (often called a 'Master of Masters').

The salt-syndic daemon relays publications and events between the higher-level Master and the local salt-master. This allows a single high-level Master to control vast numbers of Minions by delegating control to Syndics.

The Salt Mine is a mechanism used to collect arbitrary data from Minions and store it on the Salt Master. This data is then made available to all Minions via the salt.modules.mine module.

Key Differences:

• Grains: Static, largely unchanging data that is refreshed infrequently.
• Salt Mine: Designed for frequently changing data. Instead of performing slow peer-to-peer publishing calls (where one Minion reaches out to others), the Master periodically collects data from all Minions at a defined mine_interval. This reduces overhead and provides much fresher data than Grains.

Pillar is an interface for Salt designed to provide global values (key-value pairs) that can be distributed to minions. It is managed similarly to the Salt State Tree.

Key Characteristics:

• Security: Pillar data is compiled on the Salt Master. Data for a specific minion is only accessible to that minion, making it ideal for storing sensitive, minion-specific information.
• Usage: Pillar data is accessible via the pillar dictionary within modules, renderers, and State SLS files, often using Jinja for substitution.

The mod_aggregate system allows for runtime modification of executing state data. It acts like a Just-In-Time (JIT) compiler for Salt's state system, enabling Salt to dynamically change the data used by states on the fly.

A common use case is the pkg state: instead of making multiple individual calls to a package manager (like yum or apt-get) for every package defined in different states, mod_aggregate can scan all slated states, collect all package names, and consolidate them into a single package manager call. This significantly improves execution efficiency.

A Salt Proxy Minion is a specialized component used to control devices that cannot run a standard salt-minion. This is common for:

• Network gear with proprietary operating systems and APIs.
• Devices with limited CPU or memory.
• Devices that are restricted from running a minion due to security policies.

Proxy minions provide the 'plumbing' for device enumeration, discovery, control, status monitoring, remote execution, and state management. If a device interface is not supported by existing proxy modules, you can write a custom proxy module in Python to interface with the device (e.g., via REST APIs, PyUSB, etc.).