/ saltstack

Automating Server Configuration Using Salt

Salt is a configuration management and remote execution engine (trust me - that's what is says on the wiki page ;) ) that is rapidly gaining favour amongst system administrators that manage a large number of servers.

Salt uses ZeroMQ for it's network layer and all the effort is client side - this makes it ideal for managing one server or a thousand.

I've been using salt now for 12 months and it has changed the way I build and configure all of the servers that I look after. Once I have a base OS running I simply install the salt minion and do all the additional configuration and installation using salt.

To demonstrate the joy of Salt devops I'm going to walk through the steps and states I created when I recently built a simple office server. I know this isn't your typical devops target but it demonstrates the variety of existing "formulas" and leaves me with a set of states that can be used to quickly and painlessly recreate this server should I need to.

As this server is an on-premise file server the first thing I need is a bootable operating system. This is a simple case of installing Debian.

Then I need to install salt-minion. Salt has it's own repositories that include a Debian source -

# wget -O - https://repo.saltstack.com/apt/debian/9/amd64/latest/SALTSTACK-GPG-KEY.pub | apt-key add -

# echo "deb http://repo.saltstack.com/apt/debian/9/amd64/latest stretch main" > /etc/apt/sources.list.d/saltstack.list

# apt-get update

# apt-get install salt-minion

The only configuration change needed is to tell the salt-minion the hostname of the salt master.

This is the master: setting in /etc/salt/minion

master: salt.example.org

The salt minion then needs restarting to see this change -

# service salt-minion restart

The minion will then communicate to the salt master. On the master we need to accept the minion's key -

# salt-key --list-all

Accepted Keys:
Denied Keys:
Unaccepted Keys:
Rejected Keys:
# salt-key --accept server1.office.example.org

We now have the ability to remotely execute and configure this server. We can test this -

# salt 'server1*' test.ping

# salt 'server1*' cmd.run date

    Sun Sep 17 17:28:17 BST 2017

Now we need to define some states. The states I created for this server are very simple. All I need to do is install some packages, create some users and configure samba.

For that we need some states - which I'll get to in Part 2...