Skip to main content

Posts

Showing posts from September, 2012

Devopsdays Rome 2012

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 but no

Salt Diaries: keeping salt up-to-date (episode 4)

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