Sergey Nivens - Fotolia
Container systems, such as Docker, purport to make networking easier, but that's only mostly true if you do what the containerization platform dictates. It's nearly impossible to change the corporate network to fit containers, which means containers had better fit what's there instead.
An IT pro can make any containerized workload work with an understanding of the basic existing network model. Without it, the risk of a disconnect -- literally -- is too real to tolerate.
Determine which container network model is best for your system to effectively optimize a production deployment. There are three primary models and many variations on each.
Single subnet, simple setup
The easiest container network model uses a single subnet. The single-subnet corporate network typically serves businesses with a single facility for users and the internet for a primary WAN connection. Most small businesses -- and many larger ones -- rely on this setup.
The internet gateway provides a private IP address from a defined subnetwork; each piece of equipment is assigned an IP address from that pool. IT organizations may choose fixed addresses for servers and put client devices on a dynamic subnetwork. To communicate over one subnet, a device broadcasts a request for another entity to identify itself, and that entity responds with its IP address. The single-subnet model of deployment is fairly simple to use and suits less complex application deployments.
To deploy containers with this network model, assign the addresses for containers from the same Dynamic Host Configuration Protocol server as for the other users and servers to avoid duplication or use a different part of the subnet range for assignment. The subnet mask -- the parameter that defines how many bits of an IP address define subnet versus out-of-subnet addresses -- should include all the container, user and server address spaces. A few parameters in the container platform will then set up the network correctly.
A single subnet approach breaks down under certain conditions. It's inefficient if users work in multiple locations, particularly if those spaces don't have high-capacity network interconnections. Companies cannot control access to applications using firewalls and IP address screening with this network model. And the sheer number of users in a subnet can get large enough to create inefficiencies.
Apps gravitate to subnets in space
Subnets within an IP address space is the most widely used model for application networking. It relies on a defined company network, either a public or private IP address space. Large companies prefer the private Class A address, 10.x.x.x, which supports over 16 million assignments. The defined company address space is divided into subnets for users in various locations and for servers and applications. Within each subnet, the address assignment and partner IP address discovery work as in the single-subnet network model. When a user calls on an address from another subnet, they obtain it from a domain name system (DNS), and each subnet is equipped with a router that passes the message to the correct destination subnet, where it repeats the local process to find the user.
Container adopters in this model should treat each of the multiple subnets as a cluster for containers, enabling container mobility within sites. Docker users can either rely on the native swarm mode capability or embrace an orchestration tool, such as Kubernetes. To fully implement this container network model, create an IP address listing in the DNS server for all the resources used outside the subnet where they're deployed. That address will direct traffic to the right subnet, where the IP address is matched to the right container. This action is handled as in a single-subnet design.
Not your average network
Docker container deployments don't follow the same rules as WAN or virtual private networks. Learn how to enable container communication the right way for the real world before you move Docker to production.
The subnets-within-an-IP-space model has worked for decades and is the basis for both corporate networks and much of the internet. Problems emerged with the growth of virtualization. Real servers and real users reside in real places -- static and predictable -- so it's easy to plan and optimize a network structure. A VM or container could, in theory, be anywhere. The subnet for a container or VM might be extended accidentally to a distant data center when the application needs to spin up another copy or replace something that breaks.
Virtually the best option
The virtual-subnet model underpins virtualization and cloud agility, including dynamic replacement of failed components, rerouting of traffic around problems and horizontal scaling of components under load. The model works best with high-capacity connectivity among sites, though it's possible to work around interconnection quality mismatches via network policies.
User and application addressing in this container network model must be synchronized with changes in location, which generally require special tools to manage addresses. A software-defined networking (SDN) product, such as VMware NSX, Nuage Networks from Nokia or Juniper Contrail, manages IP and subnet addresses and accommodates changes in application components' locations. SDN platforms also manage the policies that control access to applications and how site connectivity influences where an application deploys or redeploys. Orchestration tools, common to DevOps shops, also work with SDN products to facilitate complex virtual network deployments connecting containers.
Before you commit to DevOps tools, or even to DevOps, be sure you understand the features available in the SDN product or toolchain you're considering and work SDN and DevOps integration into planning. A good SDN tool will simplify the role DevOps has to play.