unicolet.org

One of the hardest parts about Infrastructure As Code and  Configuration Management is establishing a discipline on developing, testing and deploying changes. Developers follow established practices and tools have been built and perfected over the last decade and a half. On the other hand sysadmins and ops people do not have the same tooling and culture because estensive automation has only become a trend recently. So if Infrastructure As Code allows you to version the infrastructure your code runs on, what good is it if then there are no tools or established practices to follow? Luckily the situation is changing and in this post I'm outlining a methodology for test driven development of SaltStack Formulas . The idea is that with a single command you can run your formula against a matrix of platforms (operating systems) and suites (or configurations). Each cell of the matrix will be tested and the result is a build failure or success much alike to what every half-decent de...

This is an attempt to record my thoughts and describe a solution with regard on how to target/classify minions in a SaltStack environment. SaltStack logo An interesting discussion on the topic can be found in this (rather old) thread on the Salt-User mailing list: https://groups.google.com/forum/#!topic/salt-users/R_jgNdYDPk0 Basically I share the same concern of the thread author Martin F. Kraft, who in an attempt to put and end to this madness ended up writing reklass . Roles seem to be easy enough to understand and provide for a clear separation between the actual infrastructure and the desired configuration state, while allowing extensibility and customization (a more specific role can override some settings from another role).

How do you, at once, extend a LVM logical volume on a fleet of identical linux ( Centos ) servers using SaltStack ? Here's how and, thanks to Salt, it only took 5m.

In enterprise environments VMware vSphere is the most common virtualization choice. Hence when it comes to provisioning most rely on vm templates to accelerate and standardize the creation of new virtual machines. While templates work well for both Windows and Linux vms it still leaves a lot out and administrators may have additional work that has to be carried out manually (like configure networking, optionally move the vm in the right network/resource group, create application accounts, set up IIS, tomcat, java, etc, etc). True, most of this post-bootstrap setup can be taken care of with Puppet, Chef or, in my case, Saltstack , but what I wanted was a push-button vm provisioning that does all of the following automagically: create a new vm (only Linux vms are supported as of now) assign a pre-determined static ip address/name move vm into appropriate network configure it with Saltstack register the vm into out monitoring system (currently OpenNMS )

Disclaimer: this is just a shameless post to get myself a place at the great Rome event ;-). Oh well, this does not mean this post is not interesting to read. When I went to the Extreme Programming conference in Alghero (Sardinia) in 2001 I was consulting mostly as a Systems Administrator. So I felt a little bit like a fish out of water and actually one of the participants asked me: do you think there are aspects of XP that can be applied to systems administration? I think I said yes, but at that time it was kind of hard for me to find points of contact between the two. Maybe unit testing could be associated with putting a pervasive monitoring in place so that when I refactored a configuration I would know if it worked before clients did. Or coding standards could be associated with using automated installers for deploying servers, but what about keeping the configuration in sync after, when the systems went into production? And what about the rest of the rules? Last bu...

See all my Salt-related posts Welcome back! In our quest to simplify the configuration and automate our systems we have  installed  Salt on all our servers and then moved on to some  basic state management . We want of course to do more sophisticated stuff with salt and we'll get to that too. But first we want to make sure that all minions are aligned to the same salt version (the latest in this case). To do that we will add another state to our configuration which we will call (very much unimaginatively) salt.sls. The content is below: salt-minion: pkg: - latest service: - running - watch: - pkg: salt-minion This instructs minions to upgrade the salt-minion package on the node and, if upgraded, restart the service. To activate this state we'll edit the top.sls state file as follows: base: '*': - ntp - salt We are now ready to apply the changes. Let's start with a guinea-pig minion: [prompt]# salt 'expendab...

Welcome to the third episode of the series ! In the previous posts we have installed salt on CentOS machines and then moved on with a basic state configuration (we will cover more in the coming postst). Now it's time to handle those pesky SLES hosts for which there are no pre built binaries. Therefore we'll have to install salt using pip . I'll cover SLES11 in this post as that's the only variant I have. Hopefully other versions should require only minor changes. Note: active subscription to Novell update service is required as the following packages can only be found on SLES 11 SDK (it's an iso, and a large one, so if you don't have it around start downloading it before you start):  python-devel libopenssl-devel zlib-devel swig Installation Add the SDK iso in the Software Management sources. Then, as root, run the following commands (answer yes when required): zypper in gcc-c++ python-devel libopenssl-devel zlib-devel swig zypper -p http://downlo...

After part 1  of this series I had Salt running properly on all minions. It's now time to get some work done with it. We will start with something simple like making sure that ntp is installed and running on all minions. In order to to do that we will use the Salt  states enforcement feature. The default salt states configuration requires that: state definitions be kept in  /srv/salt the default state be named top.sls We will probably need to create both the directory and the files, which we can do with the following command (check that you are not overwriting your own state, needs to be done on the master only!): mkdir -p /srv/salt cat <<EOF >/srv/salt/top.sls base: '*': - ntp EOF What this state definition means is that the base state requires all nodes (as selected by '*') to apply the ntp state. Since we have not yet defined an ntp state we are going to do it right away: cat <<EOF >/srv/salt/ntp.sls ntp: pkg: - ins...

This post is the first in a series documenting the deployment of Salt on a small network ( ~ 100 hosts, initially targeting only linux-based ones which account for roughly half of it). Due to the low number of hosts I have gone for a single master layout. The linux hosts are for the greatest part running Centos 5.[4,5] in both x86 and x64 favors, and just a couple running SLES. Installing salt master The easiest way to install salt on Centos is to pull in the epel repository  : rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm then install salt with yum: yum install -y salt-master Since minions by default will attempt to connect to the salt master by resolving an host named  salt  I configured a salt cname record for the salt master host in the dns server. At this point the master can be started with: /etc/init.d/salt-master start Note : I don't have firewall or SELinux enabled. In particular SE...

Mapserver  is probably the most popular Open Source web mapping platform (even though Geoserver is getting much of the limelight nowadays). One of the advantages that Mapserver has against Geoserver is that its configuration is pretty easy because it consists of a flat text file (Geoserver instead uses a xml-backed repository). Because of this kind of repository managing a Geoserver farm becomes complicated when changes have to be replicated across all hosts and the services restarted to pick up the changes. To address this issue there have been recent efforts to build a multi-master replication mechanism plugged into Geoserver. While this is pretty cool (and it's done by an Italian company of which of course I'm proud of, being an Italian myself) I think it's even cooler to see how easy it is to manage Mapserver configuration files in a similar cluster environment. The Mapserver setup is as follows: a cluster of mapserver servers serving WMS through a number of ma...