Push-button Deployment of a Docker Compose Project
I was recently working on figuring out how to automate the deployment of a simple docker compose project. This is a non mission-critical project that consisted of a redis container and a Docker image of Hubot that we’ve built. Here’s the gist of the docker-compose.yml file:
| hubot: | |
| image: registry:5000/zdirect/zbot | |
| ports: | |
| - "8081:8080" | |
| links: | |
| - redis | |
| restart: always | |
| environment: | |
| REDIS_URL: tcp://redis:6379 | |
| # lots more env vars... | |
| redis: | |
| image: redis | |
| volumes: | |
| - ./redis-data/:/data | |
| restart: always | |
Whenever a new version of the zdirect/zbot image is updated and published to the registry a deploy script can be run. For example, the script used to automatically deploy a new version of a Docker Compose project is shown here:
| #!/bin/bash | |
| cd /to/corect/dir/ | |
| docker-compose up -d |
Yup, that’s all. Its that simple. Behind the curtains, this command pulls the latest version of the image. Since the docker-compose.yml file doesn’t specify a tag it defaults to latest. The old container is then removed and a new one started. Any data specified in volumes are safe since its mounted on the host and not inside the container. Obviously a more complicated project would have a more involved deployment, but simpler is better!
Integrating this deployment script into Rundeck, Jenkins or your build tool of choice is a piece of cake and isn’t covered here, but might be in a future post. This automation allows you to bridge the gap between building your code and running it on your servers, aka the last-mile problem of continuous delivery.