Always on Command

Data Structures

In addition to grains that the minions send to the master, pillars are the data that the master sends to specific minions. These data structures can be used to define variables for templates, to store GPG-encrypted secrets, or to define simple mappings that abstract operating system-dependent differences.

The first step is to create the /srv/pillar/mappings.sls file with the content:

mappings:
  apache2:
    Debian:
      pkg_name: apache2
      srv_name: apache2
    Red Hat:
      pkg_name: httpd
      srv_name: httpd

Now you need to assign the pillar data to specific minions by creating a top file in /srv/pillar/top.sls with the content:

base:
   '*':
     - mappings

The following commands then update the pillars, and the pillar data is retrieved from minion01:

# salt 'minion01' saltutil.pillar refresh
# salt "minion01" pillar.items

As a result, you now see all pillar data associated with minion01 (Figure 3).

Figure 3: The pillar data assigned to minion01.

If needed, you can also retrieve only subsets of the pillar data. To retrieve only the data for the mappings:apache2:Debian namespace, use:

# salt "minion01" pillar.get "mappings:apache2:Debian"
minion 01:
    ----------
    pkg_name:
      apache2
    srv_name:
      apache2

This command now allows reconciliation of differences in package names for Apache2 on Debian- and Red Hat-based distributions. Another state file in /srv/salt/apache2.sls (Figure 4) is used for this purpose.

Figure 4: Another state file for Apache2.

Now add the following lines to the file /srv/salt/top.sls:

base:
   'minion1':
      - demo state
      - apache2

A state.apply command returns the information in Figure 5, which shows that the iotop package is set up, some Apache2 packages have been installed, and the Apache2 service is already running.

Figure 5: Output of the state.apply command.

Because of the mapping in the pillar data, the pkg.installed and service.running calls were automatically given the correct names. In other words, the same description works under both Debian derivatives and Red Hat offshoots.

A Look into the Future

In October 2020, VMware acquired SaltStack, whose future now seems more secure than ever. VMware said it wanted to expand its automation capabilities and use Salt for its multicloud strategy. However, one could also imagine a VMware tool package that includes a Salt minion and can be orchestrated by a future vSphere version. In this way, you could create templates in vSphere, install the operating system packages, and keep them up to date.