Docker Configuring the network to use the bridge network

In the case of networks, a bridge network (bridge network, also known as a bridge) is a link-layer device used to transfer traffic between nodes of a network. bridge can be a hardware device or a software device running in the host kernel.

For Docker, the bridge network USES a software bridge that allows containers to connect to communicate with a bridge network, while providing isolation from containers that are not connected to the bridge network. Docker bridge drivers automatically install rules in the host that prevent containers on different bridge networks from communicating directly with each other.

The bridge network is used to communicate with containers running on an Docker daemon. For containers with different Docker daemons, routing can be managed at the operating system level or communication can be achieved using the overlay network.

When Docker is started, the default bridge network is automatically created to which all newly started containers are connected if not specifically specified. It is also possible to create a user-defined bridge network with a higher priority than the default.

1. The difference between user-defined bridge and default bridge

1.1 User-defined Bridges provide better interoperability between isolated and containerized applications

Containers connected to the same user-defined bridge automatically expose all ports to each other without external exposure. This makes communication between containerized applications easier without accidentally opening up to the outside world.

Suppose an application contains an web front end and a database back end. The external needs to access the front end (probably port 80), but only the front end needs to access the database back end. With a user-defined bridge, you only need to expose the ports on the front end to the outside world. The database application does not need to open any ports, because the web front end can be accessed directly through the user-defined bridge.

If you are running the same application stack on the default bridge, you need to open both the web front end and the database back end ports, each time using the -ES32en or --publish flag. This means that the Docker host needs to restrict access to the database backend port in other ways.

1.2 User-defined bridge provides inter-container automatic DNS parsing (automatic DNS resolution)

Containers on the default bridge can only access each other via the IP address, unless you use the --link option, which is considered legacy. In user-defined Bridges, containers can access each other by name and alias.

Again, the web front end and the database back end are analyzed using the example above. If the containers are called web and db, the web container can be connected to the db container on db (the web container connect connect db container at), regardless of which Docker host the application stack is running on.

If you are running the same application stack on the default bridge, you need to manually create a connection between containers (using the legacy --link) flag. These connections need to be created in both directions, so the complexity increases exponentially when the number of containers to communicate is greater than 2. Alternatively, you can edit the /etc/hosts file in the container, but this can cause difficult debugging problems.

1.3 The container can be connected and disconnected from the user-defined network while running

During the lifetime of a container, it is possible to connect and disconnect the container from the user-defined network while the container is running. To remove the container from the default bridge, you need to stop the container and recreate it with different network options.

1.4 Create 1 configurable bridge per user custom network

If your container USES the default bridge, you can configure it, but all containers use the same Settings, such as the MTU and iptables rules. In addition, the configuration for the default bridge occurs outside of Docker and requires a restart of Docker.

User-defined Bridges are created and configured via docker network create. If different groups of applications have different network requirements, you can configure each user's custom bridge independently, just as you would create one separately.

1.5 Containers connected in the default bridge share environment variables

Initially, the only way to share environment variables between two containers was to connect them using the --link flag. This type of variable sharing cannot be used in user-defined networks. However, there are better ways to share environment variables. 1. Some Ideas:

Multiple containers can use the Docker volume volume to mount the same file or directory used to share information. Multiple containers can be started simultaneously via ES96en-ES97en, and the compose file can define Shared variables. You can use swarm services instead of stand-alone containers, and you can leverage swarm's Shared secrets and configs.

Containers connected to the same user-defined bridge can effectively expose all ports to each other. For containers or non-Docker hosts on different networks to access the port of the container, the port must be published using the -p or --publish flag.

2. Manage user-defined Bridges

Create a user-defined bridge with the docker network create command:

$ docker network create my-net

You can specify subnet subnet, IP address block, gateway, and other options. Check out the docker network create command reference manual or check out the docker network create --help command for details.

Delete the user-defined bridge with the docker network rm command. If the container is still connected to the network, you need to disconnect first to remove the bridge.

$ docker network rm my-net

What happens when you arrive?

When you create or remove a user-defined bridge, or connect or disconnect containers from a user-defined bridge, Docker USES operating system-specific tools to manage the underlying network architecture (such as adding or deleting bridge devices or configuring iptables rules on Linux). These are the implementation details. Let Docker manage your user-defined Bridges for you.

3. Connect the container to a user-defined bridge

You can specify one or more --network flags when you create a new container. The following example connects the Nginx container to the ES148en-ES149en network. Port 80 of the container is also published to port 8080 of the Docker host so that external clients can access the port. Any other container connected to the my-net network can access all ports of other containers in that network and vice versa.

$ docker create --name my-nginx \
 --network my-net \
 --publish 8080:80 \
 nginx:latest

Use the docker network connect command to connect a running container to an existing user-defined bridge. The following command connects the running my-ES160en container to the existing my-net network:

$ docker network connect my-net my-nginx

4. Disconnect the container from the user-defined network

Disconnect a running container from a user-defined bridge using the docker network disconnect command. The following command will disconnect the my-ES172en container from the ES173en-net network:

$ docker network disconnect my-net my-nginx

5. Use IPv6

If you want the Docker container to support IPv6, you need to turn on the options and reload the configuration in the Docker daemon before creating any IPv6 network or assigning the IPv6 address to the container.

Specify --ipv6 flag to enable IPv6 when creating the network. IPv6 cannot be selectively disabled on the default bridge.

6. Open container to external access

By default, traffic sent from the container to the default bridge is not forwarded externally. To enable forwarding, you need to change two Settings. These are not Docker commands, and they affect the kernel of the Docker host.

Configure the Linux kernel to allow IP forwarding

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

Change the iptables policy, FORWARD policy from DROP to ACCEPT

$ sudo iptables -P FORWARD ACCEPT

These Settings fail on reboot, so you may need to add them to the boot script.

7. Use the default bridge

The default bridge network is considered a legacy detail of Docker and is not recommended for production use. Configuring the default bridge is a manual operation, and it has technical drawbacks.

7.1 Connect the container to the default bridge

If the --network flag does not declare the network, and the network driver is specified, the container is connected to the default bridge by default. Containers connected to the default bridge network can communicate, but only via the IP address, unless they are linked using the legacy flag, link.

7.2 Configure the default bridge

To configure the default bridge, specify the options in the ES229en.json configuration file. The following example declares several options. You only need to specify the Settings you want to customize in the file.

{
 "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 to make the change effective.

7.3 Use IPv6 through the default bridge

If Docker is configured to support IPv6 (see Using IPv6), the default bridge is automatically configured to support IPv6. Unlike user-defined Bridges, IPv6 cannot be selectively closed in the default bridge.

8. Next steps

Through a separate web tutorial