We have discussed in Chapter 6, Distributed Application Architecture, what blue–green deployments are, in an abstract way. It turns out that on Docker Swarm we cannot really implement blue–green deployments for arbitrary services. The service discovery and load balancing between two services running in Docker Swarm are part of the swarm routing mesh and cannot be (easily) customized. If Service A wants to call Service B, then Docker does it all implicitly. Docker, given the name of the target service, will use the Docker DNS service to resolve this name to a virtual IP (VIP) address. When the request is then targeted at the VIP, the Linux IPVS service will do another lookup in the Linux kernel IP tables with the VIP and load balances the request to one of the physical IP addresses of the tasks of the service represented by the VIP, as shown in the following figure:
Unfortunately, there is no easy way to intercept this mechanism and replace it with a custom behavior. But this would be needed to allow for a true blue–green deployment of Service B, which is the target service in our example. As we will see in Chapter 13, Deploying, Updating, and Securing an Application with Kubernetes, Kubernetes it is more flexible in this area.
That said, we can always deploy the public-facing services in a blue–green fashion. We can use interlock 2 and its layer 7 routing mechanism to allow for a true blue–green deployment.