The Tools To Use

Over the past couple of years, several tools have come up to solve some of the long standing problems for developers, DBAs and operations teams. This list is no where near exhaustive and your mileage may vary.

These tools should let you get up and coding, saving your code to a central place.

I run (Mac/Windows), I need a Linux server to learn some of this cool stuff, right?

Not exactly. VirtualBox is a virtualization project for multiple platforms (Mac, Win, Linux, Solaris) that allows you to run a guest OS right from your laptop or desktop. There are repositories of images (alternative here) that you can use to get yourself going quickly, or you can provision your own.

I set up (cool open source package here) and now my team wants to play with it.

Building repeatable environments is often a challenge and can involve shipping lots of files or writing really long HOWTO pages on a wiki or in email. Vagrant gives you a definition language for how to build out a server and, among other virtual environments, works with VirtualBox. It can also use multiple provisioners (Chef, Puppet, Salt, etc.) to deploy what you want into an environment.

The core of this is writing a Vagrantfile. It’s a simple file that tells Vagrant that you want to use VirtualBox, with a specific base image (ex. CentOS 6.5 minimal) and then you want to call Puppet after the virtual machine is up.

Here’s an example Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "CentOS-6.5-minimal"
  config.vm.box_url = "http://localhost/CentOS-6.5-minimal.box"

  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = "manifests"
    puppet.manifest_file = "init.pp"
    puppet.module_path = "modules"
  end
end

With this, we configure a box and provide a URL where the box can be downloaded (if it’s not already been downloaded). Then we tell it to provision with Puppet and provide the paths to init.pp and manifests and modules directories.

So this provisioner stuff. How does that stuff work?

Provisioners like Puppet and Chef provide a language that defines how your servers (or virtual servers) are built. For example, after you install your OS, how would you configure Apache? Likely by installing the httpd package, adding some configuration files and making sure that Apache is running. All of this can be done with the provisioner tools. The end result is that you have a consistent way that you build out your environment.

Here’s an rudimentary example for Puppet:

class myApache {
  package { 'httpd':
    ensure => latest
  }
  service { 'httpd':
    ensure => running,
    require => Package['httpd']
  }
}

Seems pretty straightforward, right? Ensure that httpd is installed and that the service is running. The service depends on that package being installed, so we inform Puppet of that relationship. If we didn’t, Puppet might try to ensure the service is running before the package is installed.

This isn’t limited to just your Vagrant/VirtualBox environment either. It can manage production servers as well. I prefer to build out roles (web-server, mysql-server, haproxy-server) that define what makes up each role and then assign roles to individual servers. Later down the road, when you have to add more web server capacity, it becomes trivial to add them.

That’s great, but they want to hack on it too. How do we share files?

The easiest solution might be to just archive your Vagrantfile and provisioner configuration and ship it over. Introducing a form of version control would simplify this process a lot. If you’re just hacking around, GitHub offers free public repositories. If you’re not ready for the world to see it, they also have cheap upgrades that give you private repositories. You can also bring them on site if you really need privacy.

You can install git on your Mac or Windows machine and create a new repository to store your Vagrantfile and provisioner details. Once pushed to GitHub, your team can collaborate, file bugs and write documentation together.

In Summary

Imagine bringing a new employee onto your team and asking them to get involved in a project to centralize all logging. They might have to spend time reading some form of team documentation, then build out the toolset they need to experiment with changes so they don’t affect your production services.

Now re-imagine this situation where they clone your log-aggregation repository from GitHub, and then they run “vagrant up” which builds the exact environment the rest of the team uses already. Vagrant creates one or more VirtualBox virtual servers and then calls Puppet to build out each of them with the required software. They’re up and running in minutes instead of hours or days.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s