Containers 101: 10 Terms To Know

Containerized applications just became a little more network aware. Until last June, Docker offered few options for connecting one container to another, even if they were part of the same application, unless the developer took the trouble to lay out explicit connections at deployment.

And if the container moved, then the connection was lost, even if the directions had been provided.

In June, with Release 1.7, Docker gained a way to establish connections between containers that were part of the same application.

At DockerCon 2015 in San Francisco, Docker announced the capability would be available on an experimental basis. Containers could discover where in the cluster, in the data center, or even in a remote cloud their sister containers were residing and automatically connect to them. The experiment continued in September's Docker 1.8 release. Now, Docker announced, it is stable, production ready, and generally available in Release 1.9, which was released Tuesday, Nov. 3.

It's a big step toward reorganizing applications as sets of micro-services, each service having its own container, its own address, and its own ability to be upgraded as needed. The micro-service can move and its address will move with it, re-establishing its presence in a new location through the discovery mechanism built into Release 1.9.

[ Want to learn more about Docker on Windows Server? See Windows Server 2016 Will Run Docker Engine. ]

"We worked with users on what the user command line experience should be. We wanted to be sure we had enough feedback from users before locking it in," said Docker's Scott Johnston, senior VP of product management, in an interview.

The ability to network multiple containers to multiple hosts came about through Docker's acquisition of SocketPlane in March. No amount was disclosed in the purchase. The six employees of SocketPlane were networking experts oriented toward enabling broader container connections through software-defined networking. "They were a phenomenal team. They could see that containers were very different from virtual machines," Johnston said.

Virtual machines are managed like physical servers that happen to exist in software. They're stood up and run continuously for months. Containers, on the other hand, may be activated, used for a single task, and then sent away in a matter of a few minutes.

Docker 1.9 multi-host networking works with a plug-in from a network vendor. The plug-ins initially available are from Cisco, Microsoft, Midokura, Nuage, Project Calico, VMware, and Weave. The plug-ins allow the user to generate a virtual network overlay on top of the physical networking already in place.

In earlier releases, Docker included a beta version of Docker Swarm as a cluster orchestration and scheduling system. In the 1.9 release, it is generally available. Johnston said Swarm can be used to build clusters of 1,000 Docker hosts and run 30,000 containers on those hosts. Swarm knows how to find a suitable server or set of servers for a given workload such as finding a host with lots of free RAM for a memory-intensive application.

Docker 1.9 also includes a new storage volume management system that makes it easier to persist storage for containers that are part of a distributed application. Docker has been good at making stateless applications available as a unit of portable code. Release 1.9, with its volume management, makes stateful applications (such as those that require a known state for a database system) to be containerized as well. The new management system makes it possible for storage volumes to follow the container if it's moved to a new location in the cluster.

Volume management works from the command line interface with plug-ins from Blockbridge, Ceph, ClusterHQ, EMC, and Portworx.

Johnston said Docker was guided by "lots of feedback from the ecosystem" as it prepared the features for general availability in version 1.9.