Salt provides several entry points for interfacing with Python applications.
These entry points are often referred to as *Client()
APIs. Each client
accesses different parts of Salt, either from the master or from a minion. Each
client is detailed below.
See also
There are many ways to access Salt programmatically.
Salt can be used from CLI scripts as well as via a REST interface.
See Salt's outputter system to retrieve structured data from Salt as JSON, or as shell-friendly text, or many other formats.
See the state.event
runner to utilize
Salt's event bus from shell scripts.
Salt's netapi module provides access to Salt externally via a REST interface. Review the netapi module documentation for more information.
opts
dictionary¶Some clients require access to Salt's opts
dictionary. (The dictionary
representation of the master or
minion config files.)
A common pattern for fetching the opts
dictionary is to defer to
environment variables if they exist or otherwise fetch the config from the
default location.
Modules in the Salt ecosystem are loaded into memory using a custom loader
system. This allows modules to have conditional requirements (OS, OS version,
installed libraries, etc) and allows Salt to inject special variables
(__salt__
, __opts__
, etc).
Most modules can be manually loaded. This is often useful in third-party Python
apps or when writing tests. However some modules require and expect a full,
running Salt system underneath. Notably modules that facilitate
master-to-minion communication such as the mine
,
publish
, and peer
execution
modules. The error KeyError: 'master_uri'
is a likely indicator for this
situation. In those instances use the Caller
class
to execute those modules instead.
Each module type has a corresponding loader function.