Understanding the Salt for Junos OS Components

Components Overview

You can use Salt to manage devices running Junos OS. Table 1 provides a high-level overview of the different Salt components. Each component is described in more detail in the sections that follow.

The following Salt components, which are integrated with the Salt software, are used to manage devices running Junos OS:

• Junos proxy

• Junos execution module

• Junos state module

• Junos syslog engine

Salt Master, Minions, and Proxy Minions

The Salt master is the main control server that manages one or more nodes or Salt minions. Salt typically uses an agent-based architecture in which the managed node runs the Salt minion process. Some devices, for example networking devices, might not support installing and running the Salt minion process directly on the device. In these cases, Salt supports using a proxy minion to manage a device that cannot directly run a Salt minion but can be managed through another protocol, for example, NETCONF. A minion (proxy or regular) is just a software process used to manage a device, and you can run multiple processes on the same server. A proxy minion process can run on either the Salt master or on a separate server, and by default, it is always connected to the managed node.

The standard Salt installation includes the Junos proxy module, which enables a Salt master to manage devices running Junos OS through a Salt proxy minion. The Junos proxy minion process can run on either the Salt master or a separate server and requires approximately 40 to 100 MB of RAM per process. You must have one proxy minion process for each managed device running Junos OS. The Junos proxy provides execution and state modules that enable you to perform operational and configuration tasks on devices running Junos OS.

The Junos proxy minion server must have the Junos PyEZ library and the jxmlease and yamlordereddictloader Python modules installed. Junos PyEZ is a microframework for Python that enables you to manage and automate devices running Junos OS. The Junos proxy minion connects to the Salt master using the ZeroMQ event bus and uses Junos PyEZ to establish a NETCONF session over SSH with the device running Junos OS. The jxmlease module converts XML to Python data structures and Python data structures to XML.

Grains

Grains are static pieces of data that the Salt master collects about a minion. Grain data includes properties about the system, for example, the model or serial number of the device. When the Salt master executes commands or enforces states, it can use grains to target certain groups of minions. For example, it might apply a state to all minions running a particular operating system or version.

When the Junos proxy minion establishes a connection with a device running Junos OS, it gathers the Junos OS facts and stores them in grains. Junos OS facts can be accessed in the same way as other grains.

To view the grains for a device running Junos OS, which includes the junos_facts grain, execute the grains.items function.

If you want to display just the Junos OS facts, you can request just the junos_facts grain item.

Alternatively, you can execute the facts function from the junos execution module. The junos.facts function returns the same data as the previous command.

The device facts are retrieved and cached when the Junos proxy minion connects to the device running Junos OS. When you display the facts, they are served from the cache. As a result, if the value of an already-cached fact changes, it is not automatically updated in the Salt system. To reload the facts from the device and display them, call the junos.facts_refresh function.

You can use grains to refine the set of minions on which to perform tasks. For example, the following command only executes the show chassis routing-engine command on devices running Junos OS that have dual Routing Engines:

Pillars

The Salt pillar system enables you to define data that can be distributed to minions. Salt pillars are treelike structures of user-defined data that are defined on the Salt master and are accessible by minions. Pillar data might define configuration data, user-defined variables, or sensitive information associated with the minion. You can restrict the pillar data that a minion can access by mapping the pillar to the appropriate targets in the pillar top file.

Pillar data can be defined in simple YAML files but can also be stored in and retrieved from a database such as SQL. By default, pillar data files are stored in the Salt master’s /srv/pillar directory. To change the location of the pillar data, set the pillar_roots parameter in the Salt master configuration file to the desired directory.

When managing devices running Junos OS, pillars are used to define the data for the Junos proxy, including the hostname and authentication information for a given device running Junos OS. The following sample pillar file contains the Junos proxy configuration for a device running Junos OS:

The Salt pillar top file, which generally resides at /srv/pillar/top.sls, defines the pillar data that a minion can access. When managing devices running Junos OS, the pillar top file maps the Junos proxy minion ID to the pillar file containing the proxy data for the corresponding device running Junos OS. In the following example, the top file maps the proxy minion ID router1 to the router1-proxy.sls pillar file in the base environment:

You can view a minion’s pillar data by executing the pillar.items function.

Salt State (SLS) Files

SaLt State (SLS) files define data structures that are used by the Salt system for various purposes. For example, they can be used to define pillar data or the state of a system. By default, Salt state files are written in YAML format and use the .sls file extension. State files support using Jinja syntax for added flexibility.

Salt enables you to work with managed systems’ configurations in a declarative manner. The Junos state module (for Salt), salt.states.junos, provides functions that you can use in state files to declare and enforce certain states on devices running Junos OS. For example, you might want to ensure that the device configuration includes a specific set of statements or that the device reflects a specific operational state.

The general structure for an SLS file that defines the state for a managed device is as follows, although this can vary depending on the module and function:

For example, the following state file uses the junos.install_config function to apply the configuration in the given template to the target devices running Junos OS:

You can apply an individual state to one or more target devices. For example:

Alternatively, the Salt top file can be used to apply one or more states to a minion during execution of a highstate.

When you execute a highstate on a given target, the Salt system applies all of the states that are configured in the top.sls file for that target.

For more information about the Junos state module, see Understanding the Junos Execution and State Salt Modules.

Top File

When you use Salt to manage devices, you can group minions into different categories, or environments. By default, all minions are in the base environment, but you might place other minions in a development or production environment. A Salt top file maps a device or group of devices to the state files that should be applied to them and to the pillar data that they can access within the given environment. Top files are named top.sls by default, and exist at the top of the directory hierarchy that contains Salt state files.

By default, the top file used for states resides at /srv/salt/top.sls. It uses the following syntax to map the target devices to their corresponding state files within the given environment. The file must always define the base environment.

For example, the following top file applies the core.sls and common_config.sls state files to all minions in the base environment that have an ID starting with "router":

To apply the states, execute a highstate and specify the target devices.

Similarly the Pillar top file, which generally resides at /srv/pillar/top.sls, maps a pillar file to the minions that are allowed to access the data in that file. When managing devices running Junos OS, the Pillar top file maps a Junos proxy minion ID to the state file containing the pillar data for the corresponding device running Junos OS, as described in the Pillars section.

Execution and State Modules

Salt is a configuration management and remote execution tool that enables you to declare and enforce the state of a system and perform operational and configuration tasks on managed devices. Salt execution modules are Python modules that run on a Salt minion. They define functions that enable you to perform tasks on the minion. You can execute ad hoc commands on the Salt master that instruct the target minions to execute the given function and return the result. Similarly, Salt state modules define functions that manage the application of a state to a minion.

For example, to test connectivity to all minions, you can execute the test module’s ping function and specify the target as '*' to indicate all minions.

The Salt installation includes the Junos execution and state modules, which define functions that enable you to perform operational and configuration tasks and manage the application of states on devices running Junos OS. For detailed information about using the Junos execution and state modules, see Understanding the Junos Execution and State Salt Modules.

Junos Syslog Engine, Salt Event Bus, and Salt Reactors

The Salt architecture is centered around a high-performance event bus, which uses ZeroMQ as the default message and event transport mechanism for communication between the Salt master and minions. Components communicate by sending messages through the bus, and external events can be injected on the bus. The Salt master and each Salt minion has its own event bus.

The event system uses a publish-subscribe (pub/sub) model. Events are published on the event bus, and subscribers listen for published events and react as directed. For example, when you execute a function on a minion, the Salt master publishes a job event, and the matching minion executes the job and fires a return event, which contains the job results, onto the bus. Salt provides methods to publish external events on the bus and to react to events, which enables you to use Salt to monitor and respond to events in real time.

Salt engines are external system processes that enable you to export or import events on the Salt event bus. The Salt installation includes the Junos syslog engine (for Salt), which can monitor Junos OS system log (syslog) messages that are sent to the Salt server and publish them on the Salt event bus. When enabled, the Junos syslog engine listens on the specified port for syslog events from managed devices running Junos OS. When the Junos syslog engine receives an event, it extracts the event information, translates it to Salt format, and publishes it on the Salt event bus.

The following output is a sample UI_COMMIT_COMPLETED event that was sent from a device running Junos OS and published on the Salt event bus by the Junos syslog engine:

You can use the Junos syslog engine, in conjunction with Salt reactors, for event-based state management of devices running Junos OS. Salt reactors enable you to take action in response to events on the Salt event bus. When you enable the Salt Reactor system, it monitors the Salt event bus and triggers actions for matching events based on your configured rules. To enable the Salt Reactor system, you configure the reactor option in the Salt master configuration file, and associate event tags with one or more reactor SLS files. The reactor files define the actions to take when that event occurs.

For more information about the Junos syslog engine and creating reactors for Junos OS events, see:

• Junos Syslog Engine for Salt

• Configuring Salt Reactors for Junos OS Events

• https://docs.saltstack.com/en/latest/ref/engines/all/salt.engines.junos_syslog.html