Network
Last updated
Last updated
One of Docker's strengths is encapsulation. With Docker we can package an application into a container by building an image. Behind that are many things that make up this encapsulation, one of which is the Docker network.
Docker network will be responsible for connecting the network between containers, connecting the container to the outside, as well as connecting between clusters of docker containers.
With Docker containers and services, you can connect them together or connect them to other networks outside of Docker.
Docker containers don't even need to know that they are deployed on Docker, or whether the other processes it is communicating with are Docker workloads. Whether your Docker server runs Linux, Windows, or a combination of both, you can use Docker to run it regardless of the platform in use.
From the perspective of a beginner docker, in today's article I will summarize the basic Docker network and a few points to note when using the Docker network that I have learned (go).
The Docker network system is plugable, using drivers. Most drivers are provided by default, with core functions of common network functions.
Docker network can provide most of the functions that a normal network system needs.
- BRIDGE
This is Docker's default network driver. If no driver is specified, the bridge will be the default network driver upon initialization.
When we install Docker, virtual bridge docker0 will be created, docker finds an unused subnet on the host and assigns an address to docker0
Bridge networks are often used when applications need to be run as independent containers that need to communicate with each other. Containers in the same network can communicate with each other via IP addresses. Docker does not support host identification on this network, so if you want to connect, you must use options links so that Docker can understand the addresses of the services.
Bridge is the best driver for communicating multiple containers on a single host.
- HOST
Used when the container needs to communicate with the host and use the network at the host, because it uses the network of the running server, there is no network layer between the container and the Docker Host suitable when needing to connect from the container directly to the host.
And it use for containers that need high performance by bypassing Docker’s network stack.
- OVERLAY
Overlay network creates a distributed network between multiple Docker hosts. Connect multiple Docker daemons together and enable clusters of services to communicate with each other. We can use an overlay network to easily communicate between a cluster of services and an independent container, or between two containers located on different Docker daemons.
Thanks to the Overlay network, there is no need to set up routing between containers through the operating system. Overlay networks create an overlay on the host network and allow connected containers (including clusters of containers) to communicate securely. Docker ensures routing of packets to and from the correct destination container.
And it's used for Docker Swarm services to enable communication across multiple Docker hosts.
- MACVLAN
Macvlan network allows us to assign MAC addresses to containers, this makes each container as a physical device in the network. Docker daemon routes access to containers by MAC address. Using the macvlan driver is a good choice when other applications need to connect to physical addresses rather than through the server's network layers.
- NONE
For containers that do not need networking or need to disable all networking, we will choose this driver. Often used with custom networks. This driver cannot be used in a swarm cluster.
Completely isolates a container from any network.
Initialize a docker network
In which options -d
is the driver, to create an overlay network you can use it. -d overlay
In addition, there are many options depending on the level of customization that we can add. Many of these numbers I don't really understand, I only care about one thing. several options
Example: Initialize network with bridge driver with subnet 10.11.0.0/16, gateway ip is 10.11.0.1
Use network when running a container
Use the --network option to run a container on that network bridge
Use network via docker-compose
When using docker-compose, if you do not declare a network, docker will automatically create a network for the app and the driver will be the bridge.
Now check the network list and there will be the network that docker-compose just created
And when you stop the app, docker will delete this network
If we want to declare the network for each container in a cluster, we can use the following two ways:
Declare the host driver for the container app via network_mode. This declaration can change the driver for the container
In case we want the app to use the host's network without using the docker network, declare it as follows:
Declare over networks in docker-compose.yml
Using network in docker swarm cluster
Docker swarm often uses the docker-compose.yml file to deploy, and in this file it is necessary to select the network overlay
so that docker can connect multiple host networks together.
Delete network
Isolating Containers:
Scenario: You need to ensure that containers are isolated from each other and can only communicate through defined networks.
Example: Running multiple applications on the same host without them interfering with each other.
Enabling Container Communication:
Scenario: Containers need to communicate with each other, such as a web server communicating with a database server.
Example: A multi-container application with a frontend, backend, and database.
Custom Network Configurations:
Scenario: You require custom IP address management, subnet configuration, or DNS settings.
Example: Assigning static IP addresses to containers for easier management and troubleshooting.
Connecting to External Services:
Scenario: Containers need to connect to external services or databases running outside of Docker.
Example: A Dockerized application connecting to a cloud-hosted database.
Service Discovery:
Scenario: Automatically discovering services without hardcoding IP addresses.
Example: Using service names to refer to containers, enabling dynamic scaling and reconfiguration.