the end of a deathmarch. The team has been slogging away tirelessly for the last 2 months getting all the required features ready for the prospective client. But there's a problem. How is the client going to get the software installed? You cobble together a tarball of the software, attach it to an email, hit send, and clock off. It worked in dev. Ops' problem now. You cruise into the office at 09.45 next Monday, and discover your inbox has exploded. Your boss wants your head because the customer couldn't install the release, and when they eventually got it running they got owned 15 minutes later by the latest OpenSSL exploit. How can you get better assurance that the software you're building and shipping does what it says on the box? For this, we're using Serverspec.
infrastructure and applications. Built on top of Rspec, a popular ruby testing framework. It uses standard Rspec syntax, so you use all the existing Rspec functions, and there’s lots of resources on the web. You can run it via ssh, using vagrant, or locally.
should be owned by "flapjack" (FAILED - 1) 1) File "/var/log/flapjack/flapjack.log" should be owned by "flapjack" On host `127.0.0.1' Failure/Error: it { should be_owned_by 'flapjack' } expected `File "/var/log/flapjack/ flapjack.log".owned_by?("flapjack")` to return true, got false sudo -p 'Password: ' /bin/sh -c stat\ -c\ \%U\ / var/log/flapjack/flapjack.log\ \|\ grep\ --\ \\ \^flapjack\\\$ Example output…
Can only do QA during certain times of the day. Hard to scale - difficult to get more humans during busy periods. Serverspec will keep testing…and testing…the same way every time, at any time of the day or night.
with vagrant, you can easily test on multiple versions of multiple operating systems. This, of course, can be automated so you test all your operating systems with different vagrant boxes during one build.
much better chance of your release working as you expect! As a bonus, you’ll free up your QA people to write more Serverspec tests (and Capybara tests for the GUI elements)!
/Port 22/ } end Serverspec doesn’t only check for file existence - it also checks the type (whether it’s is a file, symlink or a directory). You can also check the contents of files, both checking for strings and regular expressions. This can be restricted to finding strings before or after another string in the file.
exist } it { should belong_to_group 'flapjack' } it { should have_home_directory ‘/opt/flapjack’ } it { should have_login_shell '/bin/bash' } end Serverspec provides full user and group support, including home directories, login shells and which users should belong to which group.
:type => 'ext4' )} it { should be_mounted.with( :options => { :rw => true } )} end You can check that filesystems are mounted as you expect, including the type and options. Here, the root filesystem - type ext4 - is mounted read-write.
} it { should be_reachable.with( :port => 22, :proto => 'tcp' )} end Serverspec doesn’t only check the host you’re on - it can also look at other hosts, and check that they’re reachable as well.
{ should have_property_value('qword value', :type_qword, 'adff32') } it { should have_property_value('binary value', :type_binary, 'dfa0f066') } end Serverspec saves me remembering / looking up how to test these things myself.
for validating your assumptions about how your servers are built, and how your application behaves after installation. For application developers, it’s not a replacement for the tests you may be doing already, such as unit tests, integration tests, but rather lets you test the overall behaviour of your app’s installation and that it runs successfully on all of your supported platforms.
Flapjack is a monitoring tool, it does notification routing + event processing. In lay-mans terms, it takes check output from Nagios, Sensu and friends, applies filters and works out who to notify and how. We are building packages for Debian, Ubuntu and CentOS using Omnibus. We use Serverspec to test our packages before they are made available to testers.
Fail Pass We build packages, test them with Serverspec, then publish them. But what about the different operating systems and releases that we support? We use docker! (Yes, there’s the mandatory docker reference in this talk). We take a pristine image of each distribution, add the newly created package, and run Serverspec on each docker instance itself.
# RedHat, Ubuntu, Debian and so on os[:release] # OS release version os[:arch] # i386 or x86_64 describe service('flapjack'), :if => os[:family] == 'ubuntu' do it { should be_enabled } end Not all tests are relevant to all operating systems. Serverspec allows you to add an if block to your test, which we use to run some of our tests only on Debian-based distros. Here’s a demonstration of our current serverspec test suite (including a few bonus fails).
research and development team at Bulletproof. This is us on Karekare Beach in Auckland, a great place to go to avoid talk preparation. We highly recommend you visit while you’re in town if you’re not from these parts.