In the past months I’ve tried to find a good configuration management software which is easy to use. I’ve worked with puppet but I wanted to look after an alternative. I’ve found SaltStack. SaltStack has enterprise version and community edition, written in python, and has huge user base, also won ‘Best of VMworld 2014’ award, so I wanted to give it a try. Not to mention that it has very good documentation, and dozens of positive things.
First you will need to enable EPEL repository:
Install the salt-master on the master server, and salt-minion on the managed systems
Now it’s time to enable the services on both server:
On the master enable and start the master:
systemctl enable salt-master
systemctl start salt-master
On managed systems run the minion:
systemctl enable salt-minion
systemctl start salt-minion
Now it’s time for configuration:
Default the master listens on ports 4505 and on port 4506, so we need to open firewalls on these ports:
First, define the service:
firewall-cmd –new-service=saltstack –permanent
then edit the xml file at /etc/firewalld/services/saltstack.xml
<?xml version=”1.0″ encoding=”utf-8″?>
<description>Saltstack communication ports</description>
<port protocol=”tcp” port=”4505″/>
<port protocol=”tcp” port=”4506″ />
Now it’s time to add it to your zone (currently using public in my environment):
firewall-cmd –permanent –add-service=saltstack
Now ports are opened, and the master is listening.
Master server is listening on all of the interfaces by default, now it’s fine for me. But we need to configure the minions to connect to the proper master. Default it will try to resolve hostname salt. You can edit this in the configuration file of the minion: /etc/salt/minion
After editing the minion configuration restart the service salt-minion!
When you first run the minion a new certificate will be generated which later will be used for authentication/authorization (just like as puppet). On the master it’s time to sign this certificate.
Run salt-minion on the minion, and then go to the master to check the keys:
In the list there will be a new unaccepted key, if you want to manage the host, accept the key:
salt-key -a hostnameofminion
If you list the keys again, you will see that now it’s accepts the minion’s key.
Now it’s time to run some commands on the minion :):
salt hostnameofminion test.ping
salt hostnameofminion cmd.run_stdout “uname -a”
If you want to get the available modules on the minion:
salt hostnameofminion sys.doc
Also it’s possible to run commands on all of the minions fairly simple:
salt ‘*’ cmd.run_stdout “uname -a”
So now a basic salt environment is built up, we can run commands, which is great, but we want to use the configuration management part. This can be done by using SLS formulas. The formulas contains the rules for files, packages, and anything related to a system. So an example to install midnight commander on all of the managed systems:
Edit the file /srv/salt/mc.sls, and add the following lines:
Now it’s time to install it on all minions:
salt ‘*’ state.sls mc
After the minions installed the package mc it will notify you on the console. (it will show what packages has been updated).
Comment: The following packages were installed/updated: mc.
Duration: 19222.654 ms
Succeeded: 1 (changed=1)
Total states run: 1
Now if you run the command again, it notices that it’s already installed, so no changes needed:
Comment: Package mc is already installed.
Duration: 345.686 ms
Total states run: 1
You can do the same things with files, users, everything what you want.
You can create jobs, use templates for configuration files, and you can use so called grains, which will help you to create sls files for different systems easily.