As for the network, a bridge network (also called a bridge) is a link-layer device used to forward traffic between network segments. A bridge can be a hardware device or a software device running in the host kernel.
For Docker, a bridge network uses a software bridge that allows containers to connect to the same bridge network to communicate while providing isolation from containers not connected to the bridge network. The Docker bridge driver automatically installs rules in the host so that containers on different bridge networks cannot communicate directly with each other.
A bridged network is used for container communication running on the same Docker daemon. For containers of different Docker daemons, routing can be managed at the operating system level or overlay networks can be used to enable communication.
When starting Docker, the default bridge network is automatically created. If the newly launched container is not specified, it will be connected to this default bridge network. You can also create a user-defined bridge network, and the user-defined bridge network is higher than the default priority.
1. The difference between user-defined bridge and default bridge
1.1 User-defined bridges provide better 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 will make communication between containerized applications more convenient without unexpected opening into the outside world.
Suppose an application contains a web front-end and a database back-end. The front-end needs to be accessed (probably port 80), but only the front-end needs to access the database back-end. Using a user-defined bridge, you only need to expose the front-end port to the outside. The database application does not need to open any ports, because the web front-end can be directly accessed through the user-defined bridge.
If you run the same application stack on the default bridge, you need to open the ports of the web front-end and database back-end at the same time, you need to use the -p or --publish flags every time. This means that the Docker host needs to restrict access to the database backend port in other ways.
1.2 User-defined bridge provides automatic DNS resolution between containers (automatic DNS resolution)
The containers on the default bridge can only be accessed by IP addresses unless you use the --link option, which is considered legacy. In a user-defined bridge, containers can be accessed by aliasing names between each other.
Here we will use the above example to analyze the web front-end and database back-end. If the container is called web and db, the web container can connect to the db container at db, regardless of which Docker host the application stack runs on.
If you run the same application stack on the default bridge, you need to manually create connections 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 inside the container, but this can create difficult debugging problems.
1.3 The container can be connected and disconnected from the user's customized network during operation
During the life cycle of a container, the container can be connected and disconnected from the user-defined network during the container operation. To remove a container from the default bridge, the container needs to be stopped and recreated with different network options.
1.4 Create a configurable bridge for each user's 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 of the default bridge occurs outside Docker and requires restarting Docker.
User-defined bridges are created and configured through docker network create. If different packets of applications have different network requirements, you can configure each user's custom bridge independently, just like creating it 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 using the --link flag. This type of variable sharing method cannot be used in user-defined networks. However, there are better ways to share environment variables. Some thoughts:
- Multiple containers can use Docker volume volume to mount the same file or directory for sharing information.
- Multiple containers can be started simultaneously through docker-compose, and the compose file can define shared variables.
- Swarm service can be used instead of independent containers, and swarm's shared secrets and configs can be utilized.
A container connected to the same user-defined bridge can effectively expose all ports to the other party. To enable containers or non-Docker hosts on different networks to access a container's port, the port must be published using the -p or --publish flag.
2. Manage user-defined bridges
Create a user-defined bridge through the docker network create command:
$ docker network create my-net
Subnet subnet, IP address segment, gateway and other options can be specified. View the docker network create command reference manual or view details through the docker network create --help command.
Delete user-defined bridges 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 when you arrived?
When you create or delete 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 and deleting bridge devices or configuring iptables rules on Linux). These are the specific implementation details. Just let Docker manage your user-defined bridges for you.
3. Connect the container to the user-defined bridge
You can specify one or more --network flags when creating a new container. The following example connects an Nginx container to a my-net network. At the same time, the container's port 8080 is also published to the Docker host's port 8080, so that external clients can access this port. Any other container connected to my-net's network can access all ports of other containers in this 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-nginx container to the existing my-net network:
$ docker network connect my-net my-nginx
4. Disconnect the container to the user's custom network
Use the docker network disconnect command to disconnect the running container to a user-defined bridge. The following command will disconnect the my-nginx container to the my-net network:
$ docker network disconnect my-net my-nginx
5. Using IPv6
If Docker containers need IPv6 support, you need to be in the Docker daemon before creating any IPv6 network or assigning IPv6 addresses to the containerEnable optionsand reload the configuration.
When creating a network, specify the --ipv6 flag to enable IPv6. IPv6 cannot be disabled selectively on the default bridge.
6. Turn on the container to external access
By default, traffic sent from the container to the default bridge is not forwarded externally. To enable forwarding, two settings need to be changed. These are not Docker commands, and they affect the kernel of the Docker host.
Configure the Linux kernel to allow IP forwarding
$ sysctl net.=1
Change the policy of iptables, the FORWARD policy changed from DROP to ACCEPT
$ sudo iptables -P FORWARD ACCEPT
These settings fail on restart, so they may need to be added to the startup script.
7. Use the default bridge
The default bridge network is considered a legacy of Docker and is not recommended for production purposes. 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 is not declared through the --network flag 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 IP addresses unless they are linked using the legacy flag --link.
7.2 Configuring the default bridge
To configure the default bridge, you need to specify options in the configuration file. The following example declares several options. Just specify the settings you need 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 take effect.
7.3 Using IPv6 through the default bridge
If Docker is configured to support IPv6 (View UseIPv6), then the default bridge will be automatically configured to support IPv6. Unlike user-defined bridges, IPv6 cannot be turned off selectively in the default bridge.
8. Next steps
passIndependent web tutorials
The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.