Docker Networking Concepts: Difference between revisions
(49 intermediate revisions by the same user not shown) | |||
Line 23: | Line 23: | ||
Network: bridge host macvlan null overlay | Network: bridge host macvlan null overlay | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Networks backed by different drivers may coexists within the same Docker server. By default, a Docker servers starts with three networks based on three different drivers: [[#The_Default_Bridge_Network|the "default" bridge network]], a [[Docker_Networking_Concepts#host|host network]] and a [[#none|"null" network]]: | |||
<syntaxhighlight lang='bash'> | |||
docker network ls | |||
NETWORK ID NAME DRIVER SCOPE | |||
638f161bfddd bridge bridge local | |||
036bdd552d37 host host local | |||
6f70805abd20 none null local | |||
</syntaxhighlight> | |||
By default, all containers will connect to the default "bridge" network. This default mode can be changed, for example [[Docker_Server_Configuration#--net|--net]] configures the server to allow containers to use the host's own network device and address. | |||
Detailed information about a specific network, including the subnet address, the gateway address, and the containers attached to it, can be obtained with: | |||
[[Docker_Network_Operations#Get_Detailed_Information_about_a_Network|docker network inspect]] <''network-name''> | |||
==bridge== | ==bridge== | ||
Line 29: | Line 46: | ||
{{External|https://docs.docker.com/network/network-tutorial-standalone/}} | {{External|https://docs.docker.com/network/network-tutorial-standalone/}} | ||
A ''bridge network'' consists of a software [[Network Concepts#Bridge|bridge]] that allows containers connected to it to communicate, while providing isolation from containers not connected to it. | A ''bridge network'' consists of a software [[Network Concepts#Bridge|bridge]] that allows containers connected to it to communicate, while providing isolation from containers not connected to it. It can be thought as a virtual switch into which containers plug in to communicate among themselves and with the outside world. A Docker server starts by default a [[#The_Default_Bridge_Network|default bridge, named "bridge"]], and all containers, unless configured otherwise, connect by default to it. This configuration is appropriate when multiple containers need to communicate on the same Docker host. The Docker bridge driver automatically installs rules on the host machine so that containers on different bridge networks cannot communicate directly with each other. | ||
===The Default Bridge Network=== | ===The Default Bridge Network=== | ||
By default, and without additional configuration, a default bridge network is created, and all containers executed by the Docker server will connect to it: | By default, and without additional configuration, a default bridge network is created, and all containers executed by the Docker server will connect to it. | ||
::[[Image:DockerNetworkingDefaultBridge.png]] | |||
[[Docker Network Operations#List_Networks|docker network ls]] | [[Docker Network Operations#List_Networks|docker network ls]] | ||
Line 41: | Line 60: | ||
158b89572a60 bridge bridge local | 158b89572a60 bridge bridge local | ||
The default bridge network is considered a legacy detail of Docker and it is not recommended for production use. [[#User-Defined_Bridge_Networks|User-defined bridge networks]] are recommended instead. | The default bridge network is considered a legacy detail of Docker and it is not recommended for production use. [[#User-Defined_Bridge_Networks|User-defined bridge networks]] are recommended instead. Details about the default bridge network can be obtained with | ||
[[Docker_Network_Operations#Get_Detailed_Information_about_a_Network|docker network inspect bridge]] | |||
The default bridge network can be configured in [[daemon.json#The_Default_Bridge_Network|daemon.json]] | The default bridge gateway address coincides with the IP address configured on the Docker host's TCP/IP stack "docker0" interface. The default bridge network can be configured in [[daemon.json#The_Default_Bridge_Network|daemon.json]]. All containers connected to it use the same configuration (such as MTU and iptables rules). Outgoing traffic originating from containers connected to the default bridge network is routed externally by default. To accept incoming traffic, [[#Inbound_Traffic|special port publishing configuration]] needs to be applied. | ||
====IP Forwarding==== | ====IP Forwarding==== | ||
By default, traffic from containers connected to the default bridge is | By default, traffic from containers connected to the default bridge is [[IP_Forwarding#Overview|forwarded]] to the outside world. Forwarding can be enabled or disabled [[Docker_Network_Operations#Enable_IP_Forwarding_from_Containers_on_the_Default_Bridge|as described here]]. | ||
===User-Defined Bridge Networks=== | ===User-Defined Bridge Networks=== | ||
Line 53: | Line 74: | ||
User-defined bridge networks [[Docker_Network_Operations#Create_a_New_User-Defined_Bridge_Network|can also be created]]. | User-defined bridge networks [[Docker_Network_Operations#Create_a_New_User-Defined_Bridge_Network|can also be created]]. | ||
{{Note|Docker documentation | {{Note|Docker documentation recommends this as the best configuration to use with standalone containers.}} | ||
Each user-defined bridge network creates a separate bridge, which can be configured independently. When a user-defined bridge is [[Docker_Network_Operations#Create_a_New_User-Defined_Bridge_Network|created]] or [[Docker_Network_Operations#Remove_a_User-Defined_Bridge_Network|removed]], or containers are [[Docker_Network_Operations#Connect_a_Container_to_a_Network|connected]] or [[Docker_Network_Operations#Disconnect_a_Container_from_a_Network|disconnected]] from the bridge, Docker uses OS-specific tools to manage the underlying network infrastructure, such as adding or removing bridge devices and configuring [[iptables]] rules. | Each user-defined bridge network creates a separate bridge, which can be configured independently. When a user-defined bridge is [[Docker_Network_Operations#Create_a_New_User-Defined_Bridge_Network|created]] or [[Docker_Network_Operations#Remove_a_User-Defined_Bridge_Network|removed]], or containers are [[Docker_Network_Operations#Connect_a_Container_to_a_Network|connected]] or [[Docker_Network_Operations#Disconnect_a_Container_from_a_Network|disconnected]] from the bridge, Docker uses OS-specific tools to manage the underlying network infrastructure, such as adding or removing bridge devices and configuring [[iptables]] rules. | ||
User-defined bridge networks have some advantages over the default bridge network: | User-defined bridge networks have some advantages over the default bridge network: | ||
* All containers connecting to a user-define bridge network open all ports to each other. | * All containers connecting to a user-define bridge network '''open all ports to each other'''. This is not the case with the default bridge network, for two containers on the default bridge network to communicate, they need to expose their ports with [[Docker_run#-p.2C_--publish|-p]]. | ||
* User-defined bridges provide automatic DNS resolution between containers, and resolves the names of the containers to their IP address. Containers on the default bridge network can only access each other by IP, unless --link is used, which is deprecated and it will be removed. Also, linked containers with --link share environment variables. For more details see https://docs.docker.com/network/links/. | * User-defined bridges provide <span id='Automatic_DNS_Resolution_between_Containers'></span>'''automatic DNS resolution between containers''', and resolves the names of the containers to their IP address. Containers on the default bridge network can only access each other by IP, unless --link is used, which is deprecated and it will be removed. Also, linked containers with --link share environment variables. For more details see https://docs.docker.com/network/links/. | ||
* In case of user-defined bridges, containers can be connected and disconnected from the network bridge dynamically. In case of the default bridge, a container can be disconnected only if it stopped and recreated with different network options. | * In case of user-defined bridges, containers can be connected and disconnected from the network bridge dynamically. In case of the default bridge, a container can be disconnected only if it stopped and recreated with different network options. | ||
Details about a specific user-define bridge network can be obtained with [[Docker_Network_Operations#Get_Detailed_Information_about_a_Network|docker network inspect <''network-name''>]]. Its gateway address coincides with the IP address of a Docker host's TCP/IP stack "br-...." interface. | |||
::[[Image:DockerNetworkingUserDefinedBridge.png]] | |||
====Configuration==== | |||
User-defined bridge networks can be configured with: | User-defined bridge networks can be configured with: | ||
====<span id='User-Defined_Bridge_Network_Subnet'></span>subnet==== | =====<span id='User-Defined_Bridge_Network_Subnet'></span>subnet===== | ||
Subnet in CIDR format that represents a network segment. | Subnet in CIDR format that represents a network segment. | ||
====<span id='User-Defined_Bridge_Network_IP_Range'></span>ip-range==== | =====<span id='User-Defined_Bridge_Network_IP_Range'></span>ip-range===== | ||
Allocate container ip from a sub-range. | Allocate container ip from a sub-range. | ||
====<span id='User-Defined_Bridge_Network_Gateway'></span>gateway==== | =====<span id='User-Defined_Bridge_Network_Gateway'></span>gateway===== | ||
IPv4 or IPv6 Gateway for the master subnet. | IPv4 or IPv6 Gateway for the master subnet. | ||
====Connecting Containers to a User-Defined Bridge Network==== | |||
{{Internal|Docker_Network_Operations#Connect_a_Container_to_a_Network|Connect a Container to a Network}} | |||
==host== | ==host== | ||
Line 79: | Line 110: | ||
{{External|https://docs.docker.com/network/network-tutorial-host/}} | {{External|https://docs.docker.com/network/network-tutorial-host/}} | ||
This network driver removes network isolation between the container and the Docker host, and it uses the host's networking directly. This use case is appropriate when the container's network stack should not be isolated from the Docker host, but other aspects of the containers should be isolated. | This network driver removes network isolation between the container and the Docker host, and it uses the host's networking directly. This use case is appropriate when the container's network stack should not be isolated from the Docker host, but other aspects of the containers should be isolated. A host network named "host" is available by default on the Docker server: | ||
docker network ls | |||
NETWORK ID NAME DRIVER SCOPE | |||
... | |||
036bdd552d37 '''host''' '''host''' local | |||
If a container is executed with "--network host", then the container will bind directly to the host network interface. No new Docker host-level interface will be created. | |||
==overlay== | ==overlay== | ||
Line 109: | Line 148: | ||
{{External|https://docs.docker.com/config/containers/container-networking/}} | {{External|https://docs.docker.com/config/containers/container-networking/}} | ||
A Docker container behaves like a host on a private network. Each container has its own virtual network stack, Ethernet interface and its own IP address | A Docker container behaves like a host on a private network. Each container has its own virtual network stack, Ethernet interface and its own IP address, a gateway, routing table, DNS services, etc. | ||
The network the container will be connected to is defined when the container is created: [[Docker_Network_Operations#Connect_a_Container_to_a_Network|Connect a Container to a Network]]. | |||
The | The type of network a container uses ([[#bridge|bridge]], [[#host|host]] or other, except [[#none|none]]) is transparent from the container. By default, the container is assigned an IP address for every Docker network it connects to. The IP address is assigned from the pool assigned to the network, so the Docker daemon effectively acts as a DHCP server for each container. However, a specific IP address can be "forced" with the --ip flag when the container is started. Each network also has a default subnet mask and gateway. | ||
<font color= | The container's hostname defaults to the container name, but can be changed with --hostname. | ||
When the container starts, it can only be connected to a single network, using --network. However, you can connect a running container to multiple networks, as shown in [[#Connecting_a_Container_to_More_Than_One_Bridge|Connecting a Container to More Than One Bridge]]. | |||
By default, a container inherits the NDS settings of the Docker Dameon, including /etc/hosts and /etc/resolv.conf. These settings can be overridden on a per-container basis with --dns (which specifies the address of the DNS server), --dns-search, --dns-opt. For more details see https://docs.docker.com/config/containers/container-networking/#dns-services. | |||
==Virtual Network Adapter== | |||
A container connects to one or more available [[Docker_Networking_Concepts#Network_Drivers|networks]] via one or more virtual network adapters. | |||
==Outbound Traffic== | |||
The IP traffic generated by the container goes over its network interface and into whatever networking driver the Docker server uses. It could be the [[#The_Default_Bridge_Network|default bridge]], a [[#User-Defined_Bridge_Networks|user-defined bridge]], a [[#host|host network]] or other. Depending on the network type, the traffic usually reaches the containers on the same Docker host network. | |||
==Inbound Traffic== | |||
When a container is created, it does not exposes any of its port to the outside world. Ports can be explicitly exposed with [[Docker_run#-p.2C_--publish|-p, --publish]]. This creates a firewall rule which maps a Docker host port to a container port, which is equivalent with the container "binding" to Docker host ports. <font color=darkgray>The inbound traffic passes over a proxy that is part of the Docker server before getting to containers.</font>. | |||
Also see: {{Internal|Linux_Namespaces#Network_Namespaces|Network Namespace}} | Also see: {{Internal|Linux_Namespaces#Network_Namespaces|Network Namespace}} | ||
===Configure the Container to Use a Proxy Server=== | |||
{{External|https://docs.docker.com/network/proxy/}} | |||
==Connecting a Container to More Than One Bridge== | |||
A container can be connected to more than one bridge. This can be achieved by running the container with a --network specification, and then executing | |||
docker network connect <''other-network''> <''container-name''> | |||
==Details about the Network the Container is Connected To== | |||
[[Docker_Network_Operations#Get_Detailed_Information_about_a_Network|docker network inspect]] <''network-name''> | |||
returns detailed information about a specific network, the output contains the containers attached to it. |
Latest revision as of 19:27, 2 May 2018
External
- https://docs.docker.com/engine/userguide/networking/
- https://stackoverflow.com/questions/24319662/from-inside-of-a-docker-container-how-do-i-connect-to-the-localhost-of-the-mach
Internal
Overview
Docker's networking subsystem uses drivers. Docker comes with several drivers, and others can be developed and deployed. The drivers available by default are described below:
Network Drivers
docker info lists the network drivers available to a certain Docker server:
...
Plugins:
...
Network: bridge host macvlan null overlay
Networks backed by different drivers may coexists within the same Docker server. By default, a Docker servers starts with three networks based on three different drivers: the "default" bridge network, a host network and a "null" network:
docker network ls
NETWORK ID NAME DRIVER SCOPE
638f161bfddd bridge bridge local
036bdd552d37 host host local
6f70805abd20 none null local
By default, all containers will connect to the default "bridge" network. This default mode can be changed, for example --net configures the server to allow containers to use the host's own network device and address.
Detailed information about a specific network, including the subnet address, the gateway address, and the containers attached to it, can be obtained with:
docker network inspect <network-name>
bridge
A bridge network consists of a software bridge that allows containers connected to it to communicate, while providing isolation from containers not connected to it. It can be thought as a virtual switch into which containers plug in to communicate among themselves and with the outside world. A Docker server starts by default a default bridge, named "bridge", and all containers, unless configured otherwise, connect by default to it. This configuration is appropriate when multiple containers need to communicate on the same Docker host. The Docker bridge driver automatically installs rules on the host machine so that containers on different bridge networks cannot communicate directly with each other.
The Default Bridge Network
By default, and without additional configuration, a default bridge network is created, and all containers executed by the Docker server will connect to it.
docker network ls [...] NETWORK ID NAME DRIVER SCOPE 158b89572a60 bridge bridge local
The default bridge network is considered a legacy detail of Docker and it is not recommended for production use. User-defined bridge networks are recommended instead. Details about the default bridge network can be obtained with
docker network inspect bridge
The default bridge gateway address coincides with the IP address configured on the Docker host's TCP/IP stack "docker0" interface. The default bridge network can be configured in daemon.json. All containers connected to it use the same configuration (such as MTU and iptables rules). Outgoing traffic originating from containers connected to the default bridge network is routed externally by default. To accept incoming traffic, special port publishing configuration needs to be applied.
IP Forwarding
By default, traffic from containers connected to the default bridge is forwarded to the outside world. Forwarding can be enabled or disabled as described here.
User-Defined Bridge Networks
User-defined bridge networks can also be created.
Docker documentation recommends this as the best configuration to use with standalone containers.
Each user-defined bridge network creates a separate bridge, which can be configured independently. When a user-defined bridge is created or removed, or containers are connected or disconnected from the bridge, Docker uses OS-specific tools to manage the underlying network infrastructure, such as adding or removing bridge devices and configuring iptables rules.
User-defined bridge networks have some advantages over the default bridge network:
- All containers connecting to a user-define bridge network open all ports to each other. This is not the case with the default bridge network, for two containers on the default bridge network to communicate, they need to expose their ports with -p.
- User-defined bridges provide automatic DNS resolution between containers, and resolves the names of the containers to their IP address. Containers on the default bridge network can only access each other by IP, unless --link is used, which is deprecated and it will be removed. Also, linked containers with --link share environment variables. For more details see https://docs.docker.com/network/links/.
- In case of user-defined bridges, containers can be connected and disconnected from the network bridge dynamically. In case of the default bridge, a container can be disconnected only if it stopped and recreated with different network options.
Details about a specific user-define bridge network can be obtained with docker network inspect <network-name>. Its gateway address coincides with the IP address of a Docker host's TCP/IP stack "br-...." interface.
Configuration
User-defined bridge networks can be configured with:
subnet
Subnet in CIDR format that represents a network segment.
ip-range
Allocate container ip from a sub-range.
gateway
IPv4 or IPv6 Gateway for the master subnet.
Connecting Containers to a User-Defined Bridge Network
host
This network driver removes network isolation between the container and the Docker host, and it uses the host's networking directly. This use case is appropriate when the container's network stack should not be isolated from the Docker host, but other aspects of the containers should be isolated. A host network named "host" is available by default on the Docker server:
docker network ls NETWORK ID NAME DRIVER SCOPE ... 036bdd552d37 host host local
If a container is executed with "--network host", then the container will bind directly to the host network interface. No new Docker host-level interface will be created.
overlay
Overlay networks connect multiple Docker daemons together.
macvlan
The macvlan driver allows assigning a MAC address to a container, making it appear as a physical device on the network. The Docker daemon routes traffic to containers by their MAC addresses.
none
Container networking can be disabled altogether.
iptables
Container Networking
A Docker container behaves like a host on a private network. Each container has its own virtual network stack, Ethernet interface and its own IP address, a gateway, routing table, DNS services, etc.
The network the container will be connected to is defined when the container is created: Connect a Container to a Network.
The type of network a container uses (bridge, host or other, except none) is transparent from the container. By default, the container is assigned an IP address for every Docker network it connects to. The IP address is assigned from the pool assigned to the network, so the Docker daemon effectively acts as a DHCP server for each container. However, a specific IP address can be "forced" with the --ip flag when the container is started. Each network also has a default subnet mask and gateway.
The container's hostname defaults to the container name, but can be changed with --hostname.
When the container starts, it can only be connected to a single network, using --network. However, you can connect a running container to multiple networks, as shown in Connecting a Container to More Than One Bridge.
By default, a container inherits the NDS settings of the Docker Dameon, including /etc/hosts and /etc/resolv.conf. These settings can be overridden on a per-container basis with --dns (which specifies the address of the DNS server), --dns-search, --dns-opt. For more details see https://docs.docker.com/config/containers/container-networking/#dns-services.
Virtual Network Adapter
A container connects to one or more available networks via one or more virtual network adapters.
Outbound Traffic
The IP traffic generated by the container goes over its network interface and into whatever networking driver the Docker server uses. It could be the default bridge, a user-defined bridge, a host network or other. Depending on the network type, the traffic usually reaches the containers on the same Docker host network.
Inbound Traffic
When a container is created, it does not exposes any of its port to the outside world. Ports can be explicitly exposed with -p, --publish. This creates a firewall rule which maps a Docker host port to a container port, which is equivalent with the container "binding" to Docker host ports. The inbound traffic passes over a proxy that is part of the Docker server before getting to containers..
Also see:
Configure the Container to Use a Proxy Server
Connecting a Container to More Than One Bridge
A container can be connected to more than one bridge. This can be achieved by running the container with a --network specification, and then executing
docker network connect <other-network> <container-name>
Details about the Network the Container is Connected To
docker network inspect <network-name>
returns detailed information about a specific network, the output contains the containers attached to it.