SALT-Stack Developer
Salt is:
- A configuration management system. Salt is capable of maintaining remote nodes in defined states. For example, it can ensure that specific packages are installed and that specific services are running.
- A distributed remote execution system used to execute commands and query data on remote nodes. Salt can query and execute commands either on individual nodes or by using an arbitrary selection criteria.
It was developed in order to bring the best solutions found in the world of remote execution together and make them better, faster, and more malleable. Salt accomplishes this through its ability to handle large loads of information, and not just dozens but hundreds and even thousands of individual servers quickly through a simple and manageable interface.
Simplicity
Providing versatility between massive scale deployments and smaller systems may seem daunting, but Salt is very simple to set up and maintain, regardless of the size of the project. The architecture of Salt is designed to work with any number of servers, from a handful of local network systems to international deployments across different data centers. The topology is a simple server/client model with the needed functionality built into a single set of daemons. While the default configuration will work with little to no modification, Salt can be fine tuned to meet specific needs.
Parallel execution
The core functions of Salt:
- enable commands to remote systems to be called in parallel rather than serially
- use a secure and encrypted protocol
- use the smallest and fastest network payloads possible
- provide a simple programming interface
Salt also introduces more granular controls to the realm of remote execution, allowing systems to be targeted not just by hostname, but also by system properties.
Builds on proven technology
Salt takes advantage of a number of technologies and techniques. The networking layer is built with the excellent ZeroMQ networking library, so the Salt daemon includes a viable and transparent AMQ broker. Salt uses public keys for authentication with the master daemon, then uses faster AES encryption for payload communication; authentication and encryption are integral to Salt. Salt takes advantage of communication via msgpack, enabling fast and light network traffic.
Python client interface
In order to allow for simple expansion, Salt execution routines can be written as plain Python modules. The data collected from Salt executions can be sent back to the master server, or to any arbitrary program. Salt can be called from a simple Python API, or from the command line, so that Salt can be used to execute one-off commands as well as operate as an integral part of a larger application.
Fast, flexible, scalable
The result is a system that can execute commands at high speed on target server groups ranging from one to very many servers. Salt is very fast, easy to set up, amazingly malleable and provides a single remote execution architecture that can manage the diverse requirements of any number of servers. The Salt infrastructure brings together the best of the remote execution world, amplifies its capabilities and expands its range, resulting in a system that is as versatile as it is practical, suitable for any network.
1 Salt Client
Overview
2 Salt Master
- Overview
- Moving Pieces
- Publisher
- EventPublisher
- MWorker
- ReqServerJob Flow
3 Salt Minion
- Overview
- Event System
- Minion Job Flow
4 A Note on ClearFuncs vs. AESFuncs Contributing
- Salt Coding Style
- Sending a GitHub pull request
- Salt’s Branch Topology
- Keeping Salt Forks in Sync
- Posting patches to the mailing list
- Issue and Pull Request Labeling System
- Mentionbot
- GPG Verification
- Bootstrap Script Changes
5 Deprecating Code
6 Installing Salt for development
- Running a self-contained development version
- Installing Salt from the Python Package Index
- Editing and previewing the documentation
- Running unit and integration tests
- Issue and Pull Request Labeling System
7 GitHub Labels and Milestones
- Milestones
- Labels
8 Logging Internals
9 Package Providers
- Package Functions
- Package Repo Functions
- Low-Package Functions
10 Pull Requests
11 Reporting Bugs
12 Salt Topology
- Servers
- PUB/SUB
- Return
13 Translating Documentation
- Building A Localized Version of the Documentation
14 Developing Salt Tutorial
- Fork
- Clone
- Fetch
- Branch
- EditCommit
- Push
- Merge
- Resources
15 Modular Systems
- Developing New Modules
- Configuration Options
- Loading Modules
- Module Types
16 Salt Extend
- Command line usage
- Choosing a template
- Adding templates
- API
17 Salt’s Test Suite
- Test Directory Structure
- Running The Tests
- Automated Test Runs
- Writing Tests
18 Integration Tests
- Preparing to Write Integration Tests
- Best Practices
- Integration Classes
- Examples
- Integration Test Files
- Destructive vs Non-Destructive Tests
- Cloud Provider Tests
- Adding New Directories
19 Writing Unit Tests
- Introduction
- Preparing to Write a Unit Test
- Best Practices
- Evaluating Truth
- Tests Using Mock Objects
- Modifying __salt__ In Place
- A Simple Example
- A More Complete Example
- A Complex Example
- 20 raet
- Protocol
- Header
- Packet
- Header Fields
- Session Bootstrap
- Session
- Service Types or Modular Services
21 SaltStack Git Policy
- New Code Entry
- Release Branching
22 Salt Conventions
- Writing Salt Documentation
- Salt Formulas
- SaltStack Packaging Guide
- Salt Release Process
- Salt Coding Style
23 Salt code and internals
Contents
24 Salt Community Projects
- Hubble stack
- alkali
- buoyant
- Salt Sandbox
- Salt Vagrant Demo
25 Salt’s Test Suite: An Introduction
- Getting Set Up For Tests
- Test Directory Structure
- Running the Test Suite
- Writing Tests for Salt
- Checking for Log Messages
- Automated Test Runs
- Additional Testing Documentation