The latest release of Docker Datacenter (DDC) on Docker Engine 1.12 brings many new networking features that were designed with service discovery and high availability in mind. As organizations continue their journey towards modernizing legacy apps and microservices architectures, these new features were created to address modern day infrastructure demands. DDC builds on and extends the built-in orchestration capabilities including declarative services, scheduling, networking and security features of Engine 1.12. In addition to these new features, we published a new Reference Architecture to help guide you in designing and implementing this for your unique application requirements.
Among the new features in DDC are:
DNS for service discovery
Automatic internal service load balancing
Cluster-wide transport-layer (L4) load balancing
Cluster-wide application-layer (L7) load balancing using the new HTTP Routing Mesh (HRM) experimental feature
When creating a microservice architecture where services are often decoupled and communicated using APIs, there is an intrinsic need for many of these services to know how to communicate with each other. If a new service is created, how will it know where to find the other services it needs to communicate with? As a service needs to be scaled, what mechanism can be used for the additional containers to be added to a load balancer pool? DDC ships with the tools that tackle these challenges and enable engineers to deliver software at the pace of ever shifting business needs.
As services are created in DDC, the service name registers in a DNS resolver for each docker network. Each service will register in the Docker DNS resolver and can be reached from other applications on the same network by its service name. DNS works well for service discovery; it requires minimal configuration and can integrate with existing systems since the model has existed for decades.
It’s also important for services to remain highly available after they discover each other. What good is a newly discovered service if you can’t reach the API that developers labored over for weeks? I think we all know the answer to that, and it’s a line in an Edwin Starr song (Hint: Absolutely nothing). There are a few new load balancing features introduced in DDC that are designed to always keep your services accessible. When services register in DNS, they are automatically assigned a Virtual IP (VIP). Internal requests pass through the VIP and then are load balanced. Docker handles the distribution of traffic among each healthy service task.
There are two new ways to load balance applications externally into a DDC managed cluster: the Swarm Mode Routing Mesh and the experimental HTTP Routing Mesh (HRM).
The Swarm Mode Routing Mesh works on the transport-layer (L4) where the admin assigns a port to a service (8080 in the example below) and when the external web traffic comes to the port on any host, the Routing Mesh will route the traffic onto any host that is running a container for that service. With Routing Mesh, the host that accepts the incoming traffic does not need to have the service running on it.
The HTTP Routing Mesh works on the application-layer (L7) where the admin assigns a label to the service that corresponds to the host address. The external load balancer routes the hostnames to the nodes and the Routing Mesh send the traffic across the nodes in the cluster to the correct containers for the service.
These offer multiple options to load balance and keep your application highly available
Finally, while it’s important to keep your services highly available, it’s also important for the management of your cluster to be highly available. We improved the API health checks for Docker Trusted Registry (DTR) so that a load balancer can easily be placed in front of all replicas in order to route traffic to healthy instances. The new health check API endpoint is /health and you can set a HTTPS check from your load balancer to the new endpoint to ensure high availability of DTR.
There is a new Reference Architecture available with more detailed information on load balancing with Docker Datacenter and Engine 1.12. Additionally because DDC is backwards compatible for applications built with previous versions of Docker Engine (1.11 and 1.10 using Docker Swarm 1.2), both the new Routing Mesh and Interlock based load balancing and service discovery are supported in parallel on the same DDC managed cluster. For your applications built with previous versions of Engine, a Reference Architecture for Load Balancing and Service Discovery with DDC + Docker Swarm 1.2 is also available.
New #DockerDatacenter networking features plus Reference Architecture
Click To Tweet
More Resources:
Read the latest RA: Docker UCP Service Discovery and Load Balancing
See What’s New in Docker Datacenter
Learn more by visiting the Docker Datacenter webpage
Sign up for a free 30 day trial
The post Get to Know the Docker Datacenter Networking Updates appeared first on Docker Blog.