26 March 2014

Using Docker with Github and Jenkins for repeatable deployments

Docker helps us deploy to Buddycloud’s testing and production environments. We use Docker to run Buddycloud’s hosted environment. And deploy after every commit to our testing and production Git branches.

Again and again.


Background: we’re holded up in the Austrian mountains working on the new Buddycloud hosting platform. We need to be able to reliably test and deploy code. What generally happens is that, unless servers are completely rebuilt between test or production, they slowly degrade over time. A new library here, a config change there. And soon your tests are no longer against a vanilla environment.


Also, we want to be testing on exactly the same environment that we are running in production.

Core services and Docker deployments

What services should be run under docker and what are “core” services that other apps use?

We separate core services like databases, DNS and LDAP (for server authentication) from services that are updated and managed by Docker. These is is our plumbing - it’s just got to be there.

This has the knock on effect that when we do deployments to services that use a database: the deployed service or the application MUST take care of ensuring that the database is at the correct schema version.

This is a good thing: it keeps us honest about upgrades working smoothly. And catching failures before they hit production.


By default docker exposes no ports. We need to expose some ports to the outside world, and some ports to localhost so that processes can intercommunication. For example our Apache instances run a reverse proxy back to the buddycloud-http-api. The ports are exposed using the docker startup commands.

For example Apache uses

docker run -d --name=apache -P -p 80:80 -p 443:443 -t apache


So we have designed the following code flow that takes code from a developers laptop to SI and if that’s passing, we manually make a call to push to production.


We ended up with the following code > deployment flow:

  1. Developer checks out works on their change or feature branch.
  2. when they are ready to test in a system integration environment they commit back to the dev-candy branch
  3. Github triggers a Jenkins hook that fires off the scripts from
  4. Jenkins tries to build the project
  5. If successful Jenkins calls the docker scripts that deploy to either production or system integration environments
  6. the service is started and visible on

Buddycloud helps you quickly add communication to your app. If you would like to try it out see Buddycloud Getting Started page.

TAGS: docker buddycloud

# Back

3 notes
  1. disorderlylife reblogged this from buddycloud
  2. buddycloud posted this