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...