buchachon - Fotolia
Set up Docker container networking for real production workloads
A technology as old as data centers -- networking -- threatens to derail the next new thing. Smart networking choices make Docker container deployments functional and organized.
Nearly every company has tried containers, yet most fail -- not because Docker doesn't work, but because container networking in general is a challenge.
It takes hard work on Docker container networking to produce a running application that's accessible to users. A Docker host lives in isolation by default; containers running within a host have no way to communicate. A Docker container network enables useful communication, but most novice Docker users fail to plan container networks in the same way as a WAN or virtual private network.
An administrator or architect sets up Docker and finds that she can't access any applications, even though the apps are running. Applications comprised of cooperative microservices can't communicate intra-app among the components in their separate containers. Administrators attempting Docker container networking commonly ask why the containers won't access the internet. It's because they're not connected to it by default.
Docker defines a single default network (docker0), a bridge network that acts like an IP subnetwork. This network is uniquely defined for each Docker host, and every container can reach its exposed ports on that network to allow the apps in the containers to intercommunicate. This standard model is a start, but containers won't communicate outside the Docker host, and there's little benefit to using containers on a single server.
Build a better container network
The basic bridge model builds IP subnetworks that must be linked to something that applications can access. Docker's other container networking models are the host model and the none model.
The best Docker networking model is none of the above. Applications should always communicate via a user-defined network. As a Docker container starts, it should reference the defined network and connect in the manner described for it. To describe a suitable network, start by mapping things out from user to server. Do this before writing a single Docker command.
Put containers in their place
A Docker container network should include a company IP address space that includes users and, in most cases, nonvirtualized servers and applications. Dockerized apps don't work if they don't have hosts on that same network, so decide which company-network addresses to assign to these applications.
For a fairly simple server setup, create Docker hosts and assign each application/container to a host. Use the user-defined network model bridge, which is similar to the default Docker network design described earlier. Use Docker's EXPOSE instruction to publish the ports that the container applications use to communicate on the Docker host. This enables all of the containers in a given host to talk to each other, but not to users or to other hosts.
This simple setup will probably fail in a large or distributed IT deployment. Instead, activate Docker swarm mode, which creates a multi-host cluster wherein each Docker host uses the same user-defined network in overlay mode. Each application runs in a cluster, and these clusters should reside on servers that have good high-speed switch connections to one another. List all clusters with a logical name, e.g., Accounting, and record which servers and applications are included in the cluster. The EXPOSE feature will make container ports available to other components in the cluster, but like the simple bridge single-host model, the containers still can't talk to the outside world.
To connect Docker container networks with users, expose the ports that users interact with, which were defined in the first planning step. Each application address that a user sees must become a public port in the Docker environment. Map one of the application addresses the user sees to a Docker port; Docker can do this when running a containerized application, or the administrator can use an external network address translation (NAT) bridge that connects to the Docker network. Every user-defined network will probably need a NAT bridge.
Internal Docker NAT is hard to synchronize with the domain name server (DNS) URL decoding used for applications, so unless the organization can rely on a simple Docker setup, consider opting for the external approach to NAT for Docker networking. That provides the administrator with more control over DNS server updates, and helps to keep public and private Docker and application address spaces organized.
Fear errors
The final point in Docker container networking is that all errors are a disaster. Users who do ad hoc command-line Docker setups for production applications are asking for problems.
Apply consistent deployment and redeployment techniques with the aid of orchestration for containers, such as Google Kubernetes or another tool. The user defines models and scripts for deploying applications and even redeploying if something breaks in the data center. Kubernetes can't prevent errors from incorrect setups, however. As one user said, Kubernetes can be a great way to automate your mistakes.
Systematic planning must occur alongside consistent deployment and redeployment for administrators to easily manage container networking. Without them, organizations face a barrage of confusion and failures.
