If you are already familiar with Test Kitchen then a lot of this guide should be straight forward. ChefDK has most of the needed tools bundled up for you already, I recommend installing ChefDK and then extending it to work with Salt.
In addition to the Test Kitchen install dependencies, you will need to install the following (additional) gems in order to get Test Kitchen working with Salt:
- kitchen-vagrant
- kitchen-salt
Then create a “.kitchen.yml” file in your /srv/salt directory. This file tells Test Kitchen how to load in its configuration so it can test out your Salt configurations.
Here is a sample of what your .kitchen.yml file might look like.
---
driver:
name: vagrant
provisioner:
name: salt_solo
is_file_root: True
pillars-from-files:
base.sls: /srv/pillar/base.sls
pillars:
top.sls:
base:
'*':
- base
platforms:
- name: ubuntu-14.04
suites:
- name: default
There is a good reference that describes the various options in the kitchen-salt docs.
I had to play around with this config to get things working correctly so you may need to make your own adjustments. The key components are described in the “provisioner” section. “is_file_root” is important because it tells the minion where to look for its configuration, it essentially says look at the top.sls file on the server that runs Test Kitchen.
Use “pillars-from-files” to manually add in any custom pillar data you have. I had issues getting the default configuration to automatically add in pillar data so used this approach as a workaround.
Another caveat to mention here is that in order to get this method working I had to break the best practice of storing external Salt formulas in /srv/formulas and instead copy them directly in to the “root” diretory of /srv/salt. So basically all of the logic and formulas will live in this base location. If this point isn’t clear let me know and I can post more details.
Vagrant style testing
The next best alternative I have found to using the Salt driver for Test Kitchen is manually spinning up a customized vagrant box to test communication with the salt master or alternatively connecting via salt-ssh to run.
This method is a great compliment if you aren’t interested in running Salt in local mode and instead learning about and testing the salt-master and/or salt-ssh. This method is also straight forward.
Here is what the custom config looks like for Vagrant.
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
# OS config
config.vm.box = "ubuntu/trusty64"
config.vm.hostname = "salt-minion"
config.vm.network :private_network, ip: "192.168.33.10"
# Copy Salt master files for masterless provisioning
config.vm.synced_folder "/srv/salt/", "/srv/salt/"
# Install/config Salt
config.vm.provision :salt do |salt|
salt.minion_config = "/etc/salt/minion"
salt.run_highstate = false
install_type = "daily"
colorize = true
# For remote master preseeding
salt.minion_key = "salt-minion.pem"
salt.minion_pub = "salt-minion.pub"
# Debugging
#salt.bootstrap_options = "-D"
#salt.verbose = true
end
# Additional configuration
config.vm.provision "shell", inline: "echo '192.168.1.170 salt' >> /etc/hosts"
config.vm.provision "shell", inline: "apt-get install salt-ssh"
end
This config will do a few different things:
- Configure a static address to make some testing easier
- Dummy a host entry for your salt master
- Bootstrap the salt installation
- Copy over a centrally managed minion file (if you want to customize how the minion behaves)
- Install salt-ssh if you want to play around with ssh functionality
Note: To use salt-ssh you will need to create and entry in /etc/salt/roster for the Vagrant machine and set up credentials to connect. All of the configuration options can be found in the Vagrant docs. Obviously much more can be done in Vagrant but you will have to test all of the various options yourself to see what suits your needs.
To check current Salt keys, run the following commands on the master. This should not return anything yet since we haven’t created the keys.
sudo salt-key -L
So with this configuration we are generating a key once and reusing it so we only need to accept the key once from the Salt master. To generate the keys needed run the following command from the root vagrant directory.
sudo salt-key --gen-keys=salt-minion
Then to add the new entry on the Master (after bringing up the Vagrant box!):
sudo salt-key -a 'salt-minion'
Once this set of keys has been accepted, we can bring the minion VM up and down without having to worry about adding and deleting keys every time you need to test something. Obviously this approach should not be taken outside of testing environments in to production.
Lastly, use this command to delete an old minion:
sudo salt-key -d salt-minion
Conclusion
Being new to Salt I found the combination of using the custom Vagrant box coupled with the Test Kitchen provisioner a great way to learn and also how to test Salt configurations. The best part about using this method is that there is no additional work to getting the two methods to work together. For example, after you have your directory structure set up correctly on the host system (master confg) then you will already have everything ready to go for the Test Kitchen as well as the Vagrant box method of testing.
I have found the combination to be very useful in my own learning so far of Salt. Obviously this wont’ address all of the complexity of a deployment but is a great and easy way to get introduced to many of the concepts and ideas of Salt.
I am really enjoying Salt so far and I hope that readers can put some of my findings to help with their learning as well.
Read More
