Multi-Container Apps on User-Defined Networks

One of the biggest challenges for implementing cloud native technologies is learning the fundamentals — especially when you need to fit your learning into a busy schedule.

In this series, we’ll break down core cloud native concepts, challenges, and best practices into short, manageable exercises and explainers, so you can learn five minutes at a time. These lessons assume a basic familiarity with the Linux command line and a Unix-like operating system — beyond that, you don’t need any special preparation to get started.

Last time, we ran a web app–the open source wiki platform Mediawiki–from a container in a single-container configuration, with a persistent volume and a container port published to the host machine. That gave us a functional development environment, from which we could modify and build on the application.

But cloud native deployments often consist of applications spread across multiple containers. How can we connect the constituent parts of a single application once they’ve been containerized? In this tutorial, we’ll learn how to let containers talk to one another by deploying Mediawiki in a multi-container configuration on a user-defined network.

Table of Contents

1. What is a Container?
2. Creating, Observing, and Deleting Containers
3. Build Image from Dockerfile
4. Using an Image Registry
5. Volumes and Persistent Storage
6. Container Networking and Opening Container Ports
7. Running a Containerized App
8. Multi-Container Apps on User-Defined Networks←You are here

User-defined networks

When containers reside on the default bridge network together, they should in theory be able to communicate with each other by name via Domain Name System (DNS)–but they can’t. Instead, those containerized apps need to know one another’s specific IP addresses to transmit data back and forth.

This is a deliberate restriction on the default bridge network. But why? Well, simply by virtue of being default, the docker0 bridge is apt to be a busy place, full of Docker containers without any necessary relationship to one another — without any need to communicate. That could be a security risk in a system predicated on isolation. So on the default bridge, Docker makes containers jump through a few extra hoops to communicate effectively.

When we have a group of containers that need to communicate, instead of using the default bridge we can place them in their own user-defined network. While this isn’t the only way to let containers communicate, it is the Docker-preferred way of doing things, since this creates a precisely scoped layer of isolation. We can create a user-defined network with the command:

docker network create <network name>

The -d (or --driver) argument for this command specifies a model for the new network: bridge, overlay, or a custom driver option added by the user.

• Bridge networks allow containers within the network — all of which must be on the same Docker daemon host — to communicate with one another while isolating them from other networks.
• Overlay networks allow containers within the network — which may be spread across multiple Docker daemon hosts–to communicate with one another while isolating them from other networks. This driver is used by the container orchestrator Docker Swarm.
• Custom drivers allow for custom network rules.

The bridge driver is the default, so if you don’t specify a driver, Docker will create a bridge network. The bridge driver is what we’ll be using in this lesson.

What about linking?

Another way to name-based communication between containers on the default bridge is container linking, which involves creating manual links between containers using the --link argument. This was once the standard technique for connecting containers, and you’ll still see it used in the docs for many images. But Docker considers this a legacy option, which means that it is not recommended and may be disabled in the future; linking has been superseded by user-defined networks.

Exercise: A multi-container wiki using container networking

You can follow along in this video tutorial:

To follow the rest of the tutorial, read the rest at the Mirantis blog.