Shulou(Shulou.com)06/02 Report--

As far as networks are concerned, a bridged network (bridge network, also known as a bridge) is a link layer device that forwards traffic between network segments. The bridge can be a hardware device or a software device running in the host kernel.

For Docker, bridging networks use software bridges that allow containers to connect to the same bridging network to communicate, while providing isolation from containers that are not connected to the bridging network. The Docker bridge driver automatically installs rules in the host so that containers on different bridged networks cannot communicate directly with each other.

Bridging networks are used to communicate with containers running on the same Docker daemon. For containers with different Docker daemons, routing can be managed at the operating system level or overlay networks can be used for communication.

When you start Docker, a default bridging network is automatically created, and the newly launched container will connect to this default bridging network if not specifically specified. User-defined bridging networks can also be created, and user-defined bridging networks have higher priority than the default.

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

1.1 user-defined bridges provide better isolation and interoperability between containerized applications

Containers connected to the same user-defined bridge automatically expose all ports to each other and are not exposed to the outside. This makes it easier to communicate between containerized applications without accidentally opening up to the outside world.

Suppose an application consists of a web front end and a database back end. External access to the front end (possibly port 80) is required, but only the front end needs access to the database back end. To use a user-defined bridge, you only need to expose the front-end port to the outside, and the database application does not need to open any port, because the web front-end can be directly accessed through the user-defined bridge.

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

1.2 user customized bridge provides automatic DNS parsing between containers (automatic DNS resolution)

Containers on the default bridge can only access each other through IP addresses, unless you use the-- link option, which is considered a legacy. In a user-defined bridge, containers can access each other by aliases.

Here we will use the above example to analyze the web front end and database back end. If the containers are called web and db,web containers, you can connect to the db container (the web container can connect to the db container at db) on the db, no matter which Docker host the application stack is running on.

If you run the same application stack on the default bridge, you need to manually create the 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 that need to communicate is greater than 2. Alternatively, you can edit the / etc/hosts file in the container, but this can cause problems that are difficult to debug.

1.3 Container can connect and disconnect from user-defined network during operation

During the life cycle of a container, you can 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 each user-defined network creates a configurable bridge

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

User-defined bridges are created and configured through docker network create. If different groups of applications have different network requirements, each user-defined bridge can be configured independently, just as if it were created independently.

1.5 Container shared environment variables connected in the default bridge

Initially, the only way to share environment variables between two containers is to connect them with the-- link flag. This type of variable sharing cannot be used in a user-defined network. However, there are better ways to share environment variables. Some ideas:

Multiple containers can use Docker volume volumes to mount the same file or directory used to share information. Multiple containers can be started at the same time through docker-compose, and compose files can define shared variables. You can use swarm services instead of separate containers, and you can take advantage of 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 container's port, the port must be published with the-p or-- publish flag.

two。 Manage user-defined Brid

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

$docker network create my-net

You can specify subnet subnet,IP address fields, gateways, and other options. Check the docker network create command reference manual or use the docker network create-- help command to see details.

Delete the user-defined bridge through the docker network rm command. If the container is still connected to the network, you need to disconnect before you can delete the bridge.

$docker network rm my-net

What happened to the arrival?

When you create or delete user-defined bridges, or connect or disconnect containers from user-defined bridges, 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 specific implementation details. Just let Docker manage your user-defined bridge 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 my-net network. At the same time, port 80 of the container is published to port 8080 of the Docker host so that external clients can access this 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 nginx:latest

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

$docker network connect my-net my-nginx

4. Disconnect the container from the user-defined network

Use the docker network disconnect command to disconnect the running container to a user-defined bridge. The following command disconnects the my-nginx container from the my-net network:

$docker network disconnect my-net my-nginx

5. Use IPv6

If you need the Docker container to support IPv6, you need to turn on the option in the Docker daemon and reload the configuration before creating any IPv6 networks or assigning IPv6 addresses to the container.

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

6. Open the container for 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 iptables policy, FORWARD policy from DROP to ACCEPT

$sudo iptables-P FORWARD ACCEPT

These settings fail on restart, so you may need to add them to the startup script.

7. Use the default bridge

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

7.1 Connect the container to the default bridge

If the network is not declared with the-- network flag, and the network driver is specified, the container is connected to the default bridge by default. Containers connected to the default bridged network can communicate, but only through IP addresses, unless they are linked using the legacy flag, link.

7.2 configure the default bridge

To configure the default bridge, you need to specify options in the daemon.json configuration file. The following example declares several options. You only need to specify the settings that need to be customized in the file.

{"bip": "192.168.1.5lap24", "fixed-cidr": "192.168.1.5lap25", "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.

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 turned off in the default bridge.

8. Next step

Through independent online tutorials

The above is the whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.