Salt part one

From the documentation:

Salt is a new approach to infrastructure management built on a dynamic communication bus. Salt can be used for data-driven orchestration, remote execution for any infrastructure, configuration management for any app stack, and much more.

Salt is primarily agent based, with each host (known as a minion) reporting back to a master server.
An agentless mode is also possible which relies on key based SSH, not all Salt commands are supported in this mode.
Host attributes (known as grains) are collected automatically but can also be extended.
Fixed information, available to all hosts, is stored in pillars.
A specific host configuration can be achieved by applying a Salt state, a set of instructions that will be execute on each host the state is run against.

For these tests the Salt master is running in a Linux container, e.g.

lxc init template-ubuntu-18-04-image infra-salt -s lxd
lxc network attach bitsbr0 infra-salt eth0
lxc config device set infra-salt eth0 ipv4.address 10.1.1.62
lxc config set infra-salt security.privileged true
lxc start infra-salt

Installation

Simple as apt install salt-master
Including all dependencies (Python, etc) the download is just over 100MB, which does increase the size of a container somewhat.

For managed containers or servers install the minion version of salt, apt install salt-minion.
Two important notes

1. Before installing salt on a minion make sure that a fully qualified hostname is set, i.e hostname -f must return a fqdn.
   The hostname is used as the default minion ID and it’s easier to change the hostname now than change the minion ID later.
   
2. By default, minions will look for a DNS entry salt which points to the salt-master.
   That can be changed but it is easier to create that entry in your local DNS.
   
   

In both cases, salt will be installed, default configuration created and a systemd service installed and started.

The default configuration file (see below) is heavily commented and, so far, has required very few changes.

Subsequent installation, configuration and usage assumes user is root, login and sudo as needed for your environment.

salt-master

Configuration in: /etc/salt/master

Saltfs is a lightweight file server designed to deliver files from the master to minions.
Our file server root is defined in master config as:

file_roots:
  base:
    - /srv/salt/base/state/

For a given environment (base) file_roots is where salt will look first for state files.
base is the default environment and should always be defined.

Pillars define global data which can be targeted at specific groups of minions.
Our pillar data directory is defined in master config as:

pillar_roots:
  base:
    - /srv/salt/base/pillar

For a given environment (base) this is where salt will look first for pillar data.

After any change to master configuration restart salt, systemctl restart salt-master.

salt-minion

Configuration in: /etc/salt/minion
To date, we have not hade to make any changes to the minion configuration file.

Test

When master and minion are installed and configured, use salt-key on master to list accepted and pending keys.
Note that the master key is automatically accepted.

root@infra-salt:~# salt-key
Accepted Keys:
infra-salt.local.bits
Denied Keys:
Unaccepted Keys:
container20.lxd
Rejected Keys:

In the example there is one minion whose key has not yet been accepted, container20.lxd.
Run salt-key again to accept the key with the -a option.
Add a minion hostname to accept just one key or leave blank to accept all unaccepted keys.

root@infra-salt:~# salt-key -a container20.lxd
The following keys are going to be accepted:
Unaccepted Keys:
container20.lxd
Proceed? [n/Y] y
Key for minion container20.lxd accepted.

Now ping all the containers (including the master)

root@infra-salt:~# salt '*' test.ping
container20.lxd:
    True
infra-salt.local.bits:
    True

Can also use salt-run to check minion status, e.g.

# salt-run manage.status
down:
up:
    - container20.lxd
    - infra-salt.local.bits