SaltStack or Salt for short is an open source configuration management platform. It was first released in the early 2010’s as a potential replacement for Chef and Puppet. In this guide we will walk through some high level details of Salt and a basic install. If you already have Salt installed, please skip ahead to the next article when it is published.
What is Configuration Management?
A configuration management tool allows you to remotely configure and dictate configurations of machines. Through this multi-part series we will work through that with the use case of https://blog.woohoosvcs.com/. At some point this site may need multiple front ends. It has not been decided if that method will be Kubernetes, Google App Engine or VMs. If the VM route is chosen it will make sense to have an easy template to use.
What Configuration Management is not
Configuration management typically does not involve the original provisioning of the server. There are typically other tools for that such as Terraform.
Salt has three main components to achieve configuration management. Those are the salt master, minion and client. Salt can be configured highly available with multi master but it is not necessary to start out there. For the sake of this document and per Salt’s best practices we can add that later if necessary. – https://docs.saltstack.com/en/latest/topics/development/architecture.html
The salt client is a command line client that accepts commands to be issued to the salt master. It is typically on the salt master. You can use it to trigger expected states.
The Salt Master is the broker of all configuration management and the brains. Requests/commands received from the client make their way to the master which then get pushed to the minion.
The minion is typically loaded onto each machine you wish to perform configuration management on. In our case, it will be the new front ends we spin up as we need them.
The Salt Master needs ports TCP/4505-4506 opened. The minions check in and connect to the master on those ports. No ports are needed for the minions as they do not listen on ports.
More on this can be found on their firewall page – https://docs.saltstack.com/en/latest/topics/tutorials/firewall.html
Where to install
Typically you want the master to be well connected since the minions will be connecting to it. Even if you are primarily on prem, it is not a bad idea to put a salt master in the cloud.
OS: CentOS 8
VM: 1 core, 1 GB RAM, 12 GB HDD
For the installation we will be closely following Salt’s documentation on installing for RHEL 8 – https://repo.saltstack.com/#rhel
For the sake of this lab we will have the client, master and minion all on the same server but it will allow us to build out the topology.
Now to the install!
# I always like to start out with the latest up to date OS sudo yum update # Install the salt repo for RHEL/CentOS sudo yum install https://repo.saltstack.com/py3/redhat/salt-py3-repo-latest.el8.noarch.rpm # Install minion and master sudo yum install salt-master salt-minion # Reboot for OS updates to take effect reboot
Post Install Configuration
We need to setup a few things first. The Salt guide is great at pointing these out – https://docs.saltstack.com/en/latest/ref/configuration/index.html
On the minion we need to edit “/etc/salt/minion”. The following changes need to be made. If/when you roll this out into production you can use DNS hostnames.
#master: salt master: 192.168.116.186
We will also open up the firewall ports on the master
firewall-cmd --permanent --zone=public --add-port=4505-4506/tcp firewall-cmd --reload
Start up Configuration Management Tools
Now we are ready to start up and see how it runs!
sudo systemctl enable salt-master salt-minion sudo systemctl start salt-master salt-minion
Wait about 5 minutes. It takes a little bit to initialize. Once it has you can run “sudo salt-key -L”. When a minion connects to the master, the master does not allow it to connect automatically. It has to be permitted/admitted. salt-key can be used to list minions and allow them.
$ sudo salt-key -L Accepted Keys: Denied Keys: Unaccepted Keys: saltmaster1.woohoosvcs.com Rejected Keys: $ sudo salt-key -A The following keys are going to be accepted: Unaccepted Keys: saltmaster1.woohoosvcs.com Proceed? [n/Y] Y Key for minion saltmaster1.woohoosvcs.com accepted. [dwcjr@saltmaster1 ~]$ sudo salt-key -L Accepted Keys: saltmaster1.woohoosvcs.com Denied Keys: Unaccepted Keys: Rejected Keys:
We used salt-key -A to accept all unaccepted keys.
$ sudo salt saltmaster1 test.version [WARNING ] /usr/lib/python3.6/site-packages/salt/transport/zeromq.py:42: VisibleDeprecationWarning: zmq.eventloop.minitornado is deprecated in pyzmq 14.0 and will be removed. Install tornado itself to use zmq with the tornado IOLoop. import zmq.eventloop.ioloop No minions matched the target. No command was sent, no jid was assigned. ERROR: No return received [root@saltmaster1 ~]# salt '*' test.version [WARNING ] /usr/lib/python3.6/site-packages/salt/transport/zeromq.py:42: VisibleDeprecationWarning: zmq.eventloop.minitornado is deprecated in pyzmq 14.0 and will be removed. Install tornado itself to use zmq with the tornado IOLoop. import zmq.eventloop.ioloop saltmaster1.woohoosvcs.com: 2019.2.2
Well that is an ugly error code. It seems to have been introduced in 2019.2.1 but not properly fixed in 2019.2.2. My guess is the next release will fix this but it seems harmless. – https://github.com/saltstack/salt/issues/54759. We do, however, get the response so this is a success.
At this point we have a salt-master and salt-minion setup, albeit on the same host. We have accepted the minion on the master and they are communicating. The next article will start to tackle setting up Salt states and other parts of the salt configuration.