Docker Network

Content source : https://docs.docker.com/network/

Estimated reading time : 4 Minutes

One of the reasons Docker containers and services are so powerful is that you can connect

them together, or connect them to non-Docker workloads. Docker containers and services do

not even need to be aware that they are deployed on Docker, or whether their peers are also

Docker workloads or not. Whether your Docker hosts run Linux, Windows, or a mix of the

two, you can use Docker to manage them in a platform-agnostic way.

This topic defines some basic Docker networking concepts and prepares you to design and

deploy your applications to take full advantage of these capabilities.

Most of this content applies to all Docker installations. However, a few advanced features are

only available to Docker EE customers.

Scope of this topic

This topic does not go into OS-specific details about how Docker networks work, so you will

not find information about how Docker manipulates iptables rules on Linux or how it

manipulates routing rules on Windows servers, and you will not find detailed information

about how Docker forms and encapsulates packets or handles encryption. See Docker and

iptables and Docker Reference Architecture: Designing Scalable, Portable Docker Container

Networks for a much greater depth of technical detail.

In addition, this topic does not provide any tutorials for how to create, manage, and use

Docker networks. Each section includes links to relevant tutorials and command references.

Network drivers

Docker’s networking subsystem is pluggable, using drivers. Several drivers exist by default,

and provide core networking functionality:

• bridge: The default network driver. If you don’t specify a driver, this is the type of

network you are creating. Bridge networks are usually used when your

applications run in standalone containers that need to communicate. See bridge

networks.

• host: For standalone containers, remove network isolation between the container and

the Docker host, and use the host’s networking directly. host is only available for

swarm services on Docker 17.06 and higher. See use the host network.

Cloud Computing – Docker Network

• overlay: Overlay networks connect multiple Docker daemons together and enable

swarm services to communicate with each other. You can also use overlay networks

to facilitate communication between a swarm service and a standalone container, or

between two standalone containers on different Docker daemons. This strategy

removes the need to do OS-level routing between these containers. See overlay

networks.

• macvlan: Macvlan networks allow you to assign a MAC address to a container, making

it appear as a physical device on your network. The Docker daemon routes traffic to

containers by their MAC addresses. Using the macvlan driver is sometimes the best

choice when dealing with legacy applications that expect to be directly connected to

the physical network, rather than routed through the Docker host’s network stack.

See Macvlan networks.

• none: For this container, disable all networking. Usually used in conjunction with a

custom network driver. none is not available for swarm services. See disable container

networking.

• Network plugins: You can install and use third-party network plugins with Docker.

These plugins are available from Docker Hub or from third-party vendors. See the

vendor’s documentation for installing and using a given network plugin.

Network driver summary

User-defined bridge networks are best when you need multiple containers to communicate

on the same Docker host.

Host networks are best when the network stack should not be isolated from the Docker host,

but you want other aspects of the container to be isolated.

Overlay networks are best when you need containers running on different Docker hosts to

communicate, or when multiple applications work together using swarm services.

Macvlan networks are best when you are migrating from a VM setup or need your

containers to look like physical hosts on your network, each with a unique MAC address.

Third-party network plugins allow you to integrate Docker with specialized network stacks.

Cloud Computing – Docker Network

Docker bridge networks

Content source: https://docs.docker.com/network/bridge/

Estimated reading time : 9 Minutes

In terms of networking, a bridge network is a Link Layer device which forwards traffic between

network segments. A bridge can be a hardware device or a software device running within a

host machine’s kernel.

In terms of Docker, a bridge network uses a software bridge which allows containers

connected to the same bridge network to communicate, while providing isolation from

containers which are not connected to that bridge network. The Docker bridge driver

automatically installs rules in the host machine so that containers on different bridge

networks cannot communicate directly with each other.

Bridge networks apply to containers running on the same Docker daemon host. For

communication among containers running on different Docker daemon hosts, you can either

manage routing at the OS level, or you can use an overlay network.

When you start Docker, a default bridge network (also called bridge) is created automatically,

and newly-started containers connect to it unless otherwise specified. You can also create

user-defined custom bridge networks. User-defined bridge networks are superior to the

default bridge network.

Differences between user-defined bridges and the

default bridge

• User-defined bridges provide better isolation and interoperability between

containerized applications.

Containers connected to the same user-defined bridge network automatically expose all

ports to each other, and no ports to the outside world. This allows containerized applications

to communicate with each other easily, without accidentally opening access to the outside

world.

Imagine an application with a web front-end and a database back-end. The outside world

needs access to the web front-end (perhaps on port 80), but only the back-end itself needs

access to the database host and port. Using a user-defined bridge, only the web port needs

to be opened, and the database application doesn’t need any ports open, since the web front-

end can reach it over the user-defined bridge.

Cloud Computing – Docker Network

If you run the same application stack on the default bridge network, you need to open both

the web port and the database port, using the -p or --publish flag for each. This means the

Docker host needs to block access to the database port by other means.

• User-defined bridges provide automatic DNS resolution between containers.

Containers on the default bridge network can only access each other by IP addresses, unless

you use the --link option, which is considered legacy. On a user-defined bridge network,

containers can resolve each other by name or alias.

Imagine the same application as in the previous point, with a web front-end and a database

back-end. If you call your containers web and db, the web container can connect to the db

container at db, no matter which Docker host the application stack is running on.

If you run the same application stack on the default bridge network, you need to manually

create links between the containers (using the legacy --link flag). These links need to be

created in both directions, so you can see this gets complex with more than two containers

which need to communicate. Alternatively, you can manipulate the /etc/hosts files within

the containers, but this creates problems that are difficult to debug.

• Containers can be attached and detached from user-defined networks on the

fly.

During a container’s lifetime, you can connect or disconnect it from user-defined networks on

the fly. To remove a container from the default bridge network, you need to stop the container

and recreate it with different network options.

• Each user-defined network creates a configurable bridge.

If your containers use the default bridge network, you can configure it, but all the containers

use the same settings, such as MTU and iptables rules. In addition, configuring the default

bridge network happens outside of Docker itself, and requires a restart of Docker.

User-defined bridge networks are created and configured using docker network create. If

different groups of applications have different network requirements, you can configure each

user-defined bridge separately, as you create it.

• Linked containers on the default bridge network share environment variables.

Originally, the only way to share environment variables between two containers was to link

them using the --link flag. This type of variable sharing is not possible with user-defined

networks. However, there are superior ways to share environment variables. A few ideas:

Cloud Computing – Docker Network

Multiple containers can mount a file or directory containing the shared information, using a

Docker volume.

Multiple containers can be started together using docker-compose and the compose file can

define the shared variables.

You can use swarm services instead of standalone containers, and take advantage of

shared secrets and configs.

Containers connected to the same user-defined bridge network effectively expose all ports to

each other. For a port to be accessible to containers or non-Docker hosts on different

networks, that port must be published using the -p or --publish flag.

Manage a user-defined bridge

Use the docker network create command to create a user-defined bridge network.

$ docker network create my-net

You can specify the subnet, the IP address range, the gateway, and other options. See

the docker network create reference or the output of docker network create --help for

details.

Use the docker network rm command to remove a user-defined bridge network. If containers

are currently connected to the network, disconnect them first.

$ docker network rm my-net

What’s really happening?

When you create or remove a user-defined bridge or connect or disconnect a container

from a user-defined bridge, Docker uses tools specific to the operating system to manage

the underlying network infrastructure (such as adding or removing bridge devices or

configuring iptables rules on Linux). These details should be considered implementation

details. Let Docker manage your user-defined networks for you.

Connect a container to a user-defined bridge

When you create a new container, you can specify one or more --network flags. This example

connects a Nginx container to the my-net network. It also publishes port 80 in the container

to port 8080 on the Docker host, so external clients can access that port. Any other container

connected to the my-net network has access to all ports on the my-nginx container, and vice

versa.

Cloud Computing – Docker Network

$ docker create --name my-nginx \

--network my-net \

--publish 8080:80 \

nginx:latest

To connect a running container to an existing user-defined bridge, use the docker network

connect command.

The

following

command

connects

already-running my-

nginx container to an already-existing my-net network:

$ docker network connect my-net my-nginx

Disconnect a container from a user-defined

bridge

To disconnect a running container from a user-defined bridge, use the docker network

disconnect command. The following command disconnects the my-nginx container from

the my-net network.

$ docker network disconnect my-net my-nginx

Use IPv6

If you need IPv6 support for Docker containers, you need to enable the option on the Docker

daemon and reload its configuration, before creating any IPv6 networks or assigning

containers IPv6 addresses.

When you create your network, you can specify the --ipv6 flag to enable IPv6. You can’t

selectively disable IPv6 support on the default bridge network.

Enable forwarding from Docker containers to the

outside world

By default, traffic from containers connected to the default bridge network is not forwarded

to the outside world. To enable forwarding, you need to change two settings. These are not

Docker commands and they affect the Docker host’s kernel.

1. Configure the Linux kernel to allow IP forwarding.

Cloud Computing – Docker Network

$ sysctl net.ipv4.conf.all.forwarding=1

2. Change the policy for the iptables FORWARD policy from DROP to ACCEPT.

$ sudo iptables -P FORWARD ACCEPT

These settings do not persist across a reboot, so you may need to add them to a start-up

script.

Use the default bridge network

The default bridge network is considered a legacy detail of Docker and is not recommended

for production use. Configuring it is a manual operation, and it has technical shortcomings.

Connect a container to the default bridge network

If you do not specify a network using the --network flag, and you do specify a network driver,

your container is connected to the default bridge network by default. Containers connected

to the default bridge network can communicate, but only by IP address, unless they are

linked using the legacy --link flag.

Configure the default bridge network

To configure the default bridge network, you specify options in daemon.json. Here is an

example daemon.json with several options specified. Only specify the settings you need to

customize.

{

"bip": "192.168.1.5/24",

"fixed-cidr": "192.168.1.5/25",

"fixed-cidr-v6": "2001:db8::/64",

"mtu": 1500,

"default-gateway": "10.20.1.1",

"default-gateway-v6": "2001:db8:abcd::89",

"dns": ["10.20.1.2","10.20.1.3"]

}

Restart Docker for the changes to take effect.

Use IPv6 with the default bridge network

Cloud Computing – Docker Network

If you configure Docker for IPv6 support (see Use IPv6), the default bridge network is also

configured for IPv6 automatically. Unlike user-defined bridges, you can’t selectively disable

IPv6 on the default bridge.

Networking tutorials

Now that you understand the basics about Docker networks, deepen your understanding

using the following tutorials:

• Standalone networking tutorial

• Host networking tutorial

• Overlay networking tutorial

• Macvlan networking tutorial

Cloud Computing – Docker Network