MySQL Technical Track

Managing files with SaltStack

3 min read

Aug 14, 2014 12:00:00 AM

Before we begin, take a look at my previous two blog posts, SaltStack for Remote Parallel Execution of Commands and Using SaltStack for Configuration Management. We manage files using configurations management much for the same reasons that we manage packages and services – we want/need consistency across all of our boxes, and to spend our time on tasks that add more business value than logging into all of our servers to change a line in a config file. Using Salt I will show you have to manage the message of the day (MOTD) on the server. Templates There are many examples of configuration files which differ only by a few lines between staging and production. A great example of this is a config file which has database host/user/pass information. The drive for consistency tells us that we would like the environment that our release is tested on to match (as closely as possible) the production environment where the code will run. Using templates allows us to affect the few lines in a configuration file, which we would like to change, while leaving the rest alone. This also simplifies the management of our servers and the configuration repository, allowing us to maintain one config file for many servers. Salt grains The salt minions know a lot of information about the boxes they run on. Everything from the hostname, to the IP address, to the kernel, and more is available to be queried by the salt master. These pieces of information are called "grains" in the salt world and allow us to insert dynamic variables into our templates. A great use case for grains would be the expansion of our Apache formula from my last post. On Red Hat-based machines, the Apache package is called "httpd" but on Debian-based machines the package is called "Apache2" Using the "osfamily" grain we can dynamically redefine the package name for each minion while maintaining a single formula for all servers. Likewise, any configurations files which need to have the current box IP address can benefit from grains. As each minion installs that configuration file it will see that the variable needs to be populated with a "grain" and will then do so as requested. Rather than maintaining an Apache vhost file for each of your 10 web servers where the only difference is the IP address declaration you can maintain one dynamic template which will ensure that everything else in that config file matches on each of the 10 nodes other then the one thing that needs to be dynamic (the IP address). Putting it all together - the MOTD In your /srv/salt dir we are going to create a subdir called motd. inside of that directory you will find 2 files. an init.sls which is the default top level formula for the director and an motd.template file which is our config file. The init.sls looks like this:

/etc/motd: 
  file.managed: 
  - user: root 
  - group: root 
  - mode: 0644 
  - source: salt://motd/motd.template 
  - template: jinja

For the file /etc/motd we are telling Salt that we want to manage the file that its owner and group should be root, that we want the file to have 0644 permissions. We are letting Salt know that it will find the config file (source) under the motd subdir, the salt:// maps to /srv/salt and that our template will be in the jinja format. Our template will look like:

------------------------------------------------------------------------------
 Welcome to 
 
 Server Stats at a Glance:
 ------------------------
 
 OS: 
 Kernel: 
 Memory:  MB
 
 This server is managed using a configuration management system (saltstack.org).
 Changes made to this box directly will likely be over-written by SALT. Instead
 modify server configuration via the configuration management git repository.
 ------------------------------------------------------------------------------

As each minion installs this MOTD file it will see the variables in use because they are grains the minion will know that it has the information required to populate the variable and will do so for each server. This will give you a final MOTD that looks like this:

[root@ip-10-0-0-172 ~]# cat /etc/motd
 
 ------------------------------------------------------------------------------
 Welcome to ip-10-0-0-172.ec2.internal
 
 Server Stats at a Glance:
 ------------------------
 
 OS: Amazon Linux AMI
 Kernel: 3.10.42-52.145.amzn1.x86_64
 Memory: 996 MB
 
 This server is managed using a configuration management system (saltstack.org).
 Changes made to this box directly will likely be over-written by SALT. Instead
 modify server configuration via the configuration management git repository.
 ------------------------------------------------------------------------------
 [root@ip-10-0-0-172 ~]#

As you can see each variable was populated with the information specific to the node. If we wanted to add, remove, or change anything in the MOTD, rather than having to box walk the entire infrastructure (which depending on your side, could tie up a resource for days), we can edit the single template file on the master and allow the tool to propagate the change out to the boxes for us, reducing that task from a very boring day (or more) to a few minutes!

On this page

Ready to unlock value from your data?

With Pythian, you can accomplish your data transformation goals and more.

Speak with Pythian consultants now →

What We Do

Managing files with SaltStack

Share this

Share this

More resources

MySQL high availability with ProxySQL, Consul and Orchestrator

Build an EBS 12.1.3 Sandbox in VirtualBox in 1 Hour

The Brand New Exadata X8M Deployment Process Revealed

Ready to unlock value from your data?