Service Discovery and Blue/Green Update with Docker
- It is a perfect match for 12-Factor applications and microservices development. Do you want Agile Management? Do you want to build large applications? Do you want to keep a clear separation of concerns? Do you want to scale your project with "divide and conquer"?
- Thank to the Docker Hub, Docker Store and Github, it provides a huge amount of images you can easily pull, assemble and enhance to build the best experience to users.
- It is quite agnostic from your infrastructure or cloud provider. It allows to easily scale-out to handle load.
I've started a small project I've called docker-mate to present to some of the challenges you might face when running Docker as well as tools you can use to address them. To make it simple, I've built it on top of docker-compose. Hopefully, you will like some of the demonstrations it provides, clone the project, open issues and provide new ideas. I wish you will like docker even more once you've seen some of the fantastic tools people are building to use it.
Service Discovery and Blue/Green UpdateDocker network connects containers together so that calling container
Bis usually as easy as addressing a network alias that could be
container-a. However, when you are deploying containers in production, you want to be able to scale-out your service and have several containers running the same application at the same time. So, you will not only want to access container
Bbut, say container
B. You will probably also want to provide High Availability so that if container
A1fails, it will be withdrawn from the list of usable services. Assuming that works very well, you should then be able to perform Blue/Green Update by adding new versions of an existing application and removing the former versions. Last but not least, you would like all of that work without changing a single line of code.
There are a few ways to address service registration, service discovery and service addressing with Docker. One of them is to rely on Hashicorp Consul as a service registry, Gliderlabs/registrator for automatic container registration and de-registration as well as on eBay/fabio to load balance service calls, assuming they are HTTP calls. The
discoverydirectory contains an example of such a configuration with docker-compose.
To demonstrate how it works, we will also rely on a simple application named
simple-api. We will need to deploy 2 of it (1.0 and 2.0) and build the associated images from below:
cd discovery/simple-api make docker images simple-api cd ..To start the demonstration, run:
docker-compose up -d
docker-compose.ymlcontains version 1.0 of
simple-api. Because of the environment variables configuration, Fabio redirects the
http://127.0.0.1:9999/simple-apiURL to the right container. To test it, run the command, below in a new terminal:
while true; do echo -e "$(curl localhost:9999/simple-api/version 2>/dev/null)" sleep 1 doneIn order to perform a Blue/Green update, scaling up the "green" (2.0) version of
simple-apito 2 and scaling down the "blue" version of it to 0 like below:
docker-compose -f simple-api.yml scale green=2 docker-compose scale blue=0The monitoring script should show up the ramp-up of the new release as well as the deletion of the previous one. Remove the application container like below:
docker-compose -f simple-api.yml stop docker-compose -f simple-api.yml rm -f