Docker-based Blue-Green Deployer

Docker-BGD is a demonstration of deploying a new version of a containerized application. In this case, a new application version (app-green) is deployed into an existing environment (app-blue). Once app-green is fully deployed, app-blue can be torn down. Overlapping versions provide continuous service to connections inbound from the load-balanced endpoint.

How Docker-BGD works

Docker-BGD is built from commonly-used open-source tools and scripts. The following ingredients go into Docker-BGD

• Docker installed on the host system.
• Hashicorp Consul as a service registry.
• GliderLabs Registrator to register and deregister containers.
• Nginx and Hashicorp Consul-template to automatically configure load-balanced backends for a sample app, as well as provide backends for blue and green versions of a sample app.

The Docker-BGD stack itself is launched using docker-compose. Once the service discovery and load balancing components are launched, Registrator listens for new containers launched on an instance, then registers them in Consul as new tasks for a service. Nginx in proxying-load-balancer mode receives configuration updates using Consul-Template. The same process works in reverse when containers for old versions are torn down.

Using this Demo

This demo can be operated manually to demonstrate a blue-green deploy. Simply clone this repo to a computer running Docker and Docker-Compose. The demo has three major steps:

1. Build images
2. Raise a stack
3. Orchestrate a deployment

1. Build images

Images are built automatically when a make stack-build is executed; however make targets are present in the Makefile to individually build images as needed. The most-recently built version is tagged as latest. Containers can be individually rebuilt after changes by running make build-green, make build-blue, or make build-lb.

2. Raise a stack

Building a stack will automatically build images, though they can be built individually if needed. Run the following command to build images and raise a stack: make build-stack

2. Orchestrate a stack

The automatically-updating load balancer provides zero downtime while versions are deployed and torn down. Targets in the Makefile allow manual simulation of a container orchestrator performing deployment and tear-down operations. To simulate a scale or deployment operation, perform the following steps - assume the initial configuration is for version sample-app-blue:

1. Deploy the green app using make deploy-green. It may begin to appear while refreshing your browser at url http://localhost:80.
2. Tear down the blue app using make teardown-blue. It should no longer appear while refreshing your browser at url http://localhost:80.
3. (Optional) Roll back a deployment by running make deploy-blue, then make teardown-green to roll back.
4. (Optional) Update a version by making changes to files in sample-app-<color>/content, in which color is blue or green. First make that the opposite color is in use. Then, build the new server by running make build-<color>. Once the new container is built, deploy it by running make deploy-<color>. Once it is deployed, tear-down the opposite color by running make teardown-<opposite-color>.
5. (Optional) Clean up all the components for this stack by running make cleanup

All containers are configured to log to the console, so their output can be inspected with docker-compose logs, or docker-compose logs <service> to isolate a single service.

Caveats and Assumptions

"Zero Downtime" high-availability is the focus of this demonstration. The primary component is a service-discovery-driven load balancer that automatically introduces new versions into an environment without terminating overall application service.

This system is an exercise demonstrating Docker container orchestration. It is not intended for production environments. It demonstrates function at a host level; in order to function in clusters, a formal cluster-aware container orchestrator (i.e. Kubernetes, Mesos, Swarm, etc.) is needed.

Additional load balancer features that ensure production-grade application behaviors during version transitions (such as health-checks and connection draining) are not present in this demonstration.

Deployment automation can be introduced by webhooks, CI/CD servers, scripts, or a variety of other mechanisms. Full automation can be achieved in conjunction with sensors and controls like health-checks and connection draining.

Application versions are represented here by directories. Application versions can be stored in monolithic or atomic repositories.

License

Docker-BGD is GPLv2 open-source software. See LICENSE for more details.