Continuous Deployment of MuzHack with Docker on Tutum
I have recently implemented continuous deployment of my MuzHack Web application to the Docker hosting service Tutum, in both production and staging versions. I am really pleased with the smoothness of the whole process of setting it up, and the ease of day-to-day administration.
Docker Image Definition
The very first thing I had to do was to define MuzHack’s Docker image. This is done in the so-called Dockerfile. I base it off the standard Node image. Then I add the PhantomJS headless browser, since it’s required by Meteor (for SEO purposes), and convert MuzHack from a Meteor application into a Node equivalent.
Docker Image Registry
Before being able to deploy, I needed Docker image hosting. I decided to use the service Quay.io, which is free for open source projects, and supports automatically building images when new commits are pushed to corresponding GitHub repositories. Importantly, Quay can also notify other services after building an image.
Setting Up GitHub Trigger
In order to trigger Quay upon pushing to the master branch of the MuzHack repository, I had to create a "Custom Git Repository Push" trigger in the Quay project’s settings (I couldn’t quite make the standard "GitHub Repository Push" trigger work). This required installing a corresponding webhook in the settings of the GitHub repository as well. Once this was done, continuous building of images hosted on Quay worked beautifully.
Setting up Tutum Trigger
In order to implement the next part of the chain, continuous deployment, I had to add a "Webhook POST" notification for the "Push to Repository" event in Quay. This is configured to invoke a trigger on Tutum, which re-deploys the staging version of the MuzHack service. But more on this later.
Deployment to Docker Hosting (Tutum)
Having solved the problem of hosting the Docker images, I could move on to setting up deployment of MuzHack to a Docker hosting service. I decided on Tutum, since I found it offered the best available experience due to its Stack model, which makes it a breeze to maintain different environments (e.g. staging and production). It also runs on top of the server provider DigitalOcean, which is already my preference in this space.
Stacks
To deploy to Tutum, I wrote a couple of stack definitions, that define three different Docker services per deployment (i.e. staging and production): MongoDB, MuzHack and Nginx (services correspond to Docker containers, although a service might spin up several containers to scale out). MongoDB is the database used by MuzHack and Nginx acts as a facade Web server, for basal duties such as handling SSL. The stack definitions ensure that MuzHack is linked to the MongoDB service and that Nginx is linked to MuzHack (as Nginx' backend server).
Stacks are defined in YAML, and there is at the time of writing one for staging, tutum-staging.yaml, and one for production, tutum-production.yaml.
To create the stacks on Tutum, I used the tutum stack up command, e.g. for staging: tutum stack up -n tutum-staging -f docker/tutum-staging.yaml
.
Automatic Deployment
So far, I’ve only set up automatic re-deployment of the staging version. This is done through a Tutum trigger for the MuzHack service of the Staging stack, which gets invoked by Quay.io when new images of the master branch are built. It works great by the way!
Administration of Deployments
Day to day administration of the MuzHack deployments is handled with ease through Tutum’s Web UI, which while relatively simplistic is really quite smart. After clicking one of the stacks (e.g. Staging), I can see its individual services and also the individual containers per service (even though I haven’t gone beyond one container per service yet).
So far, there hasn’t really been anything to administration duties, it just works :) I can see the logs of the individual services, and there is basic monitoring. I would like better monitoring eventually (especially log searching), but unless I’m mistaken Tutum/Docker can be integrated with dedicated services for this.