The first hurdle to overcome with Continuous Delivery I think is not getting your product’s code onto the machine itself, but managing the actual machine and it’s software. And in talking to people it is the subtle nuances between machines due to people tweaking things on the fly that lead to the worst [most annoying] bugs to troubleshoot. The end-goal of managing your machines is that no one ever logs into the machine directly.

Ever.

These days it looks like your options in this space are Cfengine, Chef and Puppet. They each have their pluses and minuses, but I liked the syntax of Puppet so went with that one. (And yes, I know this means I can’t control Windows machines; I can live with that for this exploration.)

Puppet can controls your server by communicating via a local agent to a server which contains ‘manifests’ about what the server should look like. Or more accurately, what things it is told to care about look like. And when something deviates it corrects it. Technically you could use Puppet to manage the system resources and the application code but I like to separate these two tasks. Its another moving piece in the puzzle, but things like Capistrano or Fabric are purpose built for application deployments so are the better task for the job. For a ‘static’ website, this means…

  • Puppet installs Apache
  • Capistrano enables the Virtual Server
  • Capistrano deploys the code

As with any of these tools, there is a bit of a chicken-and-egg problem in that before you can manage servers via automation you have to manually create the server that controls the automation, the version control server that the manifests get pulled from, etc. That is an easily addressable problem through today’s OS installation tools (or if you are using something like EC2 you just create a base AMI that has your agent and everything installed).

I found the Puppet documentation all I needed to go off and hack Apache into being installed and started on the Amazon provided Linux AMI in about 6 hours. That I suspect is about 5.5 hours more had I been smart and used an Ubuntu AMI right from the start. Of course, making things work there sent me deep into the guts of Puppet and I learned a lot so perhaps it wasn’t time wasted.

So rather than create yet-another-step-by-step post (and there are plenty out there), if you are starting out with Puppet I suggest you:

Also, a useful command to debug things is:

<pre lang="bash">sudo puppet agent --no-daemonize --onetime --verbose --debug

I can’t tell you how many times I ran that since last night when I started on this…