When you containerize your applications you will find out that you can do so much more with container and in particular with docker than just running your applications. You can use docker in all stages for different purposes:
- prepare a docker image with all required development tools for a certain project. With it it’s easy to ramp up new team mates and keep everyone in sync.
- of course dockerize your application and use the dockerized version to be close to production even in the first stage. The downside is that this doesn’t work well on MacOS or Windows yet. On MacOS you can have docker running in a VM but the mounting of the host files are causing performance issues even with NFS.
- run your databases within a container. This makes it easy to start from predefined states when you have some import scripts prepared. One use case is to test data migrations easily.
- use the tooling container you already have for development also on your continuous integration server. Best case you don’t need to install any other tool than docker on the host which makes all ci-jobs totally independent of each other. This is very handy if you have only one Jenkins Server but it has to run jobs for a lot of different teams.
- use docker-compose for continuous integration testing. With it you can for example start your application together with a dockerized database and a third container runs the end to end tests against both. As long as you have enough memory and CPU you can bring up even more complex environments. Note that you can run these tests even on open pull requests.
- use Kubernetes, CoreOS or docker-compose to start new environments quickly – for example one per git branch.
- use centralized application logging systems like kibana or loggly to find bugs early. Dockerized applications can easily log to stdout and these logs can be shipped by logspout to a centralized syslog server or since docker 1.6 you can directly ship to syslog. To make the analysis simpler you should have a look at the @CEE logging project.
- use performance logging tools for example datadog. Consider that you need to think in layers which means you need to monitor the underlying infrastructure independently of your application layer. With a proper service discovery and an overlay network you can centralize the gathering process of all application metrics.
- just use the same things as in your staging environment.
These are just a few ideas how you can use docker in your continuous delivery pipeline. A general recommendation is to have your own self-hosted private docker repository or at least a docker registry cache running to avoid problems when your third party docker-registry is unavailable. These caches are speeding up the deployment times a little bit as well and reducing the bandwidth consumption which reduces your costs a little bit too.