docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #17176 from dvdksn/engine/networking-overhaul 

engine/networking overhaul
This commit is contained in:
David Karlsson 2023-06-05 21:55:50 +02:00 committed by GitHub
parent 3cc39e25a0 2be681dea9
commit fb2f039a3b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
41 changed files with 696 additions and 356 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.github/vale/Vocab/Technology/accept.txt vendored
View File

@ -3,9 +3,9 @@ CVEs?
DHCP
DNS
Ethernet
GPG
GRUB
Git
GPG
HTTP
IPs?
IPv[46]
@ -56,6 +56,7 @@ stdout
subnet
swappable
systemd
ufw
umask
ungated
virtiofs

2
_data/engine-cli/docker_service_create.yaml
View File

@ -1585,7 +1585,7 @@ examples: |-
The swarm extends my-network to each node running the service.
Containers on the same network can access each other using
[service discovery](/network/overlay/#container-discovery).
[service discovery](/network/drivers/overlay/#container-discovery).
Long form syntax of `--network` allows to specify list of aliases and driver options:
`--network name=my-network,alias=web1,driver-opt=field1=value1`

2
_data/glossary.yaml
View File

@ -233,7 +233,7 @@ service: |
service account: |
A service account is a Docker ID used for automated management of container images or containerized applications. Service accounts are typically used in automated workflows, and do not share Docker IDs with the members in a Docker Team or Docker Business subscription plan.
service discovery: |
Swarm mode [container discovery](/network/overlay/#container-discovery) is a DNS component internal to the swarm that automatically assigns each service on an overlay network in the swarm a VIP and DNS entry. Containers on the network share DNS mappings for the service through gossip so any container on the network can access the service through its service name.
Swarm mode [container discovery](/network/drivers/overlay/#container-discovery) is a DNS component internal to the swarm that automatically assigns each service on an overlay network in the swarm a VIP and DNS entry. Containers on the network share DNS mappings for the service through gossip so any container on the network can access the service through its service name.
You don’t need to expose service-specific ports to make the service available to other services on the same overlay network. The swarm’s internal load balancer automatically distributes requests to the service VIP among the active tasks.
swarm: |

38
_data/toc.yaml
View File

@ -1352,22 +1352,28 @@ manuals:
section:
- path: /network/
title: Overview
- path: /config/containers/container-networking/
title: Container networking
- sectiontitle: Network drivers
section:
- path: /network/drivers/
title: Overview
- path: /network/drivers/bridge/
title: Bridge
- path: /network/drivers/overlay/
title: Overlay
- path: /network/drivers/host/
title: Host
- path: /network/drivers/ipvlan/
title: IPvlan
- path: /network/drivers/macvlan/
title: Macvlan
- path: /network/drivers/none/
title: None (no networking)
- path: /network/proxy/
title: Configure Docker to use a proxy server
- path: /network/bridge/
title: Bridge networks
- path: /network/overlay/
title: Overlay networks
- path: /network/host/
title: Host networking
- path: /network/ipvlan/
title: IPvlan networks
- path: /network/macvlan/
title: Macvlan networks
- path: /network/none/
title: Disable networking for a container
- path: /network/packet-filtering-firewalls/
title: Packet filtering and firewalls
- path: /config/daemon/ipv6/
title: Use IPv6
- sectiontitle: Networking tutorials
section:
- path: /network/network-tutorial-standalone/
@ -1550,14 +1556,10 @@ manuals:
title: Configuration overview
- path: /config/daemon/systemd/
title: Configure with systemd
- path: /config/daemon/ipv6/
title: Use IPv6
- path: /config/containers/live-restore/
title: Keep containers alive during daemon downtime
- path: /config/daemon/troubleshoot/
title: Troubleshoot
- path: /network/iptables/
title: Docker and iptables
- path: /config/daemon/remote-access/
title: Remote access
- path: /engine/context/working-with-contexts/

84
config/containers/container-networking.md
View File

@ -1,84 +0,0 @@
---
title: Container networking
description: How networking works from the container's point of view
keywords: networking, container, standalone
redirect_from:
- /engine/userguide/networking/configure-dns/
- /engine/userguide/networking/default_network/configure-dns/
- /engine/userguide/networking/default_network/binding/
- /engine/userguide/networking/default_network/container-communication/
---
A container has no information about what kind of network it's attached to,
whether it's a [bridge](../../network/bridge.md), an [overlay](../../network/overlay.md),
a [macvlan network](../../network/macvlan.md), or a custom network plugin.
A container only sees a network interface with an IP address,
a gateway, a routing table, DNS services, and other networking details.
That is, unless the container uses the `none` network driver.
This page describes networking from the point of view of the container.
## Published ports
By default, when you create or run a container using `docker create` or `docker run`,
the container doesn't expose any of its ports to the outside world.
To make a port available to services outside of Docker,
or to Docker containers running on a different network,
use the `--publish` or `-p` flag.
This creates a firewall rule in the container,
mapping a container port to a port on the Docker host to the outside world.
Here are some examples:
| Flag value | Description |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `-p 8080:80` | Map TCP port 80 in the container to port `8080` on the Docker host. |
| `-p 192.168.1.100:8080:80` | Map TCP port 80 in the container to port `8080` on the Docker host for connections to host IP `192.168.1.100`. |
| `-p 8080:80/udp` | Map UDP port 80 in the container to port `8080` on the Docker host. |
| `-p 8080:80/tcp -p 8080:80/udp` | Map TCP port 80 in the container to TCP port `8080` on the Docker host, and map UDP port `80` in the container to UDP port `8080` on the Docker host. |
## IP address and hostname
By default, the container gets an IP address for every Docker network it attaches to.
A container receives an IP address out of the IP pool of the network it attaches to.
The Docker daemon effectively acts as a DHCP server for each container.
Each network also has a default subnet mask and gateway.
When a container starts, it can only attach to a single network, using the `--network` flag.
You can connect a running container to multiple networks using the `docker network connect` command.
When you start a container using the `--network` flag,
you can specify the IP address for the container on that network using the `--ip` or `--ip6` flags.
When you connect an existing container to a different network using `docker network connect`,
you can use the `--ip` or `--ip6` flags on that command
to specify the container's IP address on the additional network.
In the same way, a container's hostname defaults to be the container's ID in Docker.
You can override the hostname using `--hostname`.
When connecting to an existing network using `docker network connect`,
you can use the `--alias` flag to specify an additional network alias for the container on that network.
## DNS services
By default, containers inherit the DNS settings of the host, as defined in the `/etc/resolv.conf` configuration file.
Containers that attach to the default `bridge` network receive a copy of this file.
Containers that attach to a
[custom network](../../network/network-tutorial-standalone.md#use-user-defined-bridge-networks)
use Docker's embedded DNS server.
The embedded DNS server forwards external DNS lookups to the DNS servers configured on the host.
Custom hosts, defined in `/etc/hosts` on the host machine, aren't inherited by containers.
To pass additional hosts into container, refer to
[add entries to container hosts file](../../engine/reference/commandline/run.md#add-host)
in the `docker run` reference documentation.
You can override these settings on a per-container basis.
| Flag | Description |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--dns` | The IP address of a DNS server. To specify multiple DNS servers, use multiple `--dns` flags. If the container can't reach any of the IP addresses you specify, it uses Google's public DNS server at `8.8.8.8`. This allows containers to resolve internet domains. |
| `--dns-search` | A DNS search domain to search non-fully-qualified hostnames. To specify multiple DNS search prefixes, use multiple `--dns-search` flags. |
| `--dns-opt` | A key-value pair representing a DNS option and its value. See your operating system's documentation for `resolv.conf` for valid options. |
| `--hostname` | The hostname a container uses for itself. Defaults to the container's ID if not specified. |
## Proxy server
If your container needs to use a proxy server, see
[Use a proxy server](../../network/proxy.md).

214
config/daemon/ipv6.md
View File

@ -6,35 +6,209 @@ redirect_from:
- /engine/userguide/networking/default_network/ipv6/
---
Before you can use IPv6 in Docker containers or swarm services, you need to
Before you can use IPv6 in Docker containers, you need to
enable IPv6 support in the Docker daemon. Afterward, you can choose to use
either IPv4 or IPv6 (or both) with any container, service, or network.
either IPv4 or IPv6 (or both) with any container or network.
> **Note**: IPv6 networking is only supported on Docker daemons running on Linux
> hosts.
> **Note**
>
> - IPv6 support is experimental, use it with caution.
> - IPv6 is only supported on Docker daemons running on Linux hosts.
1. Edit `/etc/docker/daemon.json`, set the `ipv6` key to `true` and the `fixed-cidr-v6` key
to your IPv6 subnet. In this example we are setting it to `2001:db8:1::/64`.
## Create an IPv6 network
```json
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}
```
The following steps show you how to create a Docker network that uses IPv6.
Save the file.
1. Edit the Docker daemon configuration file,
located at `/etc/docker/daemon.json`. Configure the following parameters:
2. Reload the Docker configuration file.
```json
{
"experimental": true,
"ip6tables": true
}
```
```console
$ systemctl reload docker
```
`ip6tables` enables additional IPv6 packet filter rules, providing network
isolation and port mapping. This parameter requires `experimental` to be
set to `true`.
You can now create networks with the `--ipv6` flag and assign containers IPv6
addresses using the `--ip6` flag.
2. Save the configuration file.
3. Restart the Docker daemon for your changes to take effect.
```console
$ sudo systemctl restart docker
```
4. Create a new IPv6 network.
- Using `docker network create`:
```console
$ docker network create --ipv6 --subnet 2001:0DB8::/112 ip6net
```
- Using a Docker Compose file:
```yaml
networks:
ip6net:
enable_ipv6: true
subnet: 2001:0DB8::/112
```
You can now run containers that attach to the `ip6net` network.
```console
$ docker run --rm --network ip6net -p 80:80 traefik/whoami
```
This publishes port 80 on both IPv6 and IPv4.
You can verify the IPv6 connection by running curl,
connecting to port 80 on the IPv6 loopback address:
```console
$ curl http://[::1]:80
Hostname: ea1cfde18196
IP: 127.0.0.1
IP: ::1
IP: 172.17.0.2
IP: fe80::42:acff:fe11:2
RemoteAddr: [fe80::42:acff:fe11:2]:54890
GET / HTTP/1.1
Host: [::1]
User-Agent: curl/8.1.2
Accept: */*
```
## Use IPv6 for the default bridge network
The following steps show you how to use IPv6 on the default bridge network.
1. Edit the Docker daemon configuration file,
located at `/etc/docker/daemon.json`. Configure the following parameters:
```json
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64",
"experimental": true,
"ip6tables": true
}
```
- `ipv6` enables IPv6 networking on the default network.
- `fixed-cidr-v6` assigns a subnet to the default bridge network,
enabling dynamic IPv6 address allocation.
- `ip6tables` enables additional IPv6 packet filter rules, providing network
isolation and port mapping. This parameter requires `experimental` to be
set to `true`.
2. Save the configuration file.
3. Restart the Docker daemon for your changes to take effect.
```console
$ sudo systemctl restart docker
```
You can now run containers on the default bridge network.
```console
$ docker run --rm -p 80:80 traefik/whoami
```
This publishes port 80 on both IPv6 and IPv4.
You can verify the IPv6 connection by making a request
to port 80 on the IPv6 loopback address:
```console
$ curl http://[::1]:80
Hostname: ea1cfde18196
IP: 127.0.0.1
IP: ::1
IP: 172.17.0.2
IP: fe80::42:acff:fe11:2
RemoteAddr: [fe80::42:acff:fe11:2]:54890
GET / HTTP/1.1
Host: [::1]
User-Agent: curl/8.1.2
Accept: */*
```
## Dynamic IPv6 subnet allocation
If you don't explicitly configure subnets for user-defined networks,
using `docker network create --subnet=<your-subnet>`,
those networks use the default address pools of the daemon as a fallback.
The default address pools are all IPv4 pools.
This also applies to networks created from a Docker Compose file,
with `enable_ipv6` set to `true`.
To enable dynamic subnet allocation for user-defined IPv6 networks,
you must manually configure address pools of the daemon to include:
- The default IPv4 address pools
- One or more IPv6 pools of your own
The default address pool configuration is:
```json
{
"default-address-pools": [
{ "base": "172.17.0.0/16", "size": 16 },
{ "base": "172.18.0.0/16", "size": 16 },
{ "base": "172.19.0.0/16", "size": 16 },
{ "base": "172.20.0.0/14", "size": 16 },
{ "base": "172.24.0.0/14", "size": 16 },
{ "base": "172.28.0.0/14", "size": 16 },
{ "base": "192.168.0.0/16", "size": 20 }
]
}
```
The following example shows a valid configuration with the default values and
an IPv6 pool. The IPv6 pool in the example provides up to 256 IPv6 subnets of
size `/112`, from an IPv6 pool of prefix length `/104`. Each `/112`-sized
subnet supports 65 536 IPv6 addresses.
> **Note**
>
> Be aware that the following known limitations exist for IPv6 pools:
>
> - The `base` value for IPv6 needs a minimum prefix length of `/64`.
> This is due to an integer overflow in the Docker daemon.
> See [moby/moby#42801](https://github.com/moby/moby/issues/42801).
> - The difference between the pool length and the pool size can't be larger
> than 24. Defining an excessive number of subnets causes the daemon to
> consume all available memory.
> See [moby/moby#40275](https://github.com/moby/moby/issues/40275).
```json
{
"default-address-pools": [
{ "base": "172.17.0.0/16", "size": 16 },
{ "base": "172.18.0.0/16", "size": 16 },
{ "base": "172.19.0.0/16", "size": 16 },
{ "base": "172.20.0.0/16", "size": 16 },
{ "base": "172.24.0.0/14", "size": 16 },
{ "base": "172.28.0.0/14", "size": 16 },
{ "base": "192.168.0.0/16", "size": 20 },
{ "base": "2001:db8::/104", "size": 112 }
]
}
```
> **Note**
>
> The address `2001:db8` in this example is
> [reserved for use in documentation][wikipedia-ipv6-reserved].
> Replace it with a valid IPv6 network.
> The default IPv4 pools are from the private address range,
> the IPv6 equivalent would be [ULA networks][wikipedia-ipv6-ula].
[wikipedia-ipv6-reserved]: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv6
[wikipedia-ipv6-ula]: https://en.wikipedia.org/wiki/Unique_local_address
## Next steps
- [Networking overview](../../network/index.md)
- [Container networking](../containers/container-networking.md)

2
engine/faq.md
View File

@ -101,7 +101,7 @@ thousands or even millions of containers.
### How do I connect Docker containers?
Currently the recommended way to connect containers is via the Docker network
feature. You can see details of [how to work with Docker networks](../network/bridge.md).
feature. You can see details of [how to work with Docker networks](../network/drivers/bridge.md).
### How do I run more than one process in a Docker container?

7
engine/install/debian.md
View File

@ -17,6 +17,13 @@ To get started with Docker Engine on Debian, make sure you
## Prerequisites
> **Note**
>
> If you use ufw or firewalld to manage firewall settings, be aware that
> when you expose container ports using Docker, these ports bypass your
> firewall rules. For more information, refer to
> [Docker and ufw](../../network/packet-filtering-firewalls.md#docker-and-ufw).
### OS requirements
To install Docker Engine, you need the 64-bit version of one of these Debian

7
engine/install/raspbian.md
View File

@ -14,6 +14,13 @@ To get started with Docker Engine on Raspbian, make sure you
## Prerequisites
> **Note**
>
> If you use ufw or firewalld to manage firewall settings, be aware that
> when you expose container ports using Docker, these ports bypass your
> firewall rules. For more information, refer to
> [Docker and ufw](../../network/packet-filtering-firewalls.md#docker-and-ufw).
### OS requirements
To install Docker Engine, you need the 64-bit version or 32-bit version of one of these Raspbian

7
engine/install/ubuntu.md
View File

@ -22,6 +22,13 @@ To get started with Docker Engine on Ubuntu, make sure you
## Prerequisites
> **Note**
>
> If you use ufw or firewalld to manage firewall settings, be aware that
> when you expose container ports using Docker, these ports bypass your
> firewall rules. For more information, refer to
> [Docker and ufw](../../network/packet-filtering-firewalls.md#docker-and-ufw).
### OS requirements
To install Docker Engine, you need the 64-bit version of one of these Ubuntu

2
engine/release-notes/23.0.md
View File

@ -468,7 +468,7 @@ To mitigate this, the previous build cache must be discarded. `docker builder pr
#### ipvlan networks ([tracking issue](https://github.com/moby/moby/issues/44925))
When upgrading to the 23.0 branch, the existence of any [ipvlan](/network/ipvlan/) networks will prevent the daemon from starting:
When upgrading to the 23.0 branch, the existence of any [ipvlan](../../network/drivers/ipvlan.md) networks will prevent the daemon from starting:
```
panic: interface conversion: interface {} is nil, not string

2
engine/security/index.md
View File

@ -281,4 +281,4 @@ pull requests, or comments on the Docker community forums.
* [Seccomp security profiles for Docker](seccomp.md)
* [AppArmor security profiles for Docker](apparmor.md)
* [On the Security of Containers (2014)](https://medium.com/@ewindisch/on-the-security-of-containers-2c60ffe25a9e)
* [Docker swarm mode overlay network security model](../../network/overlay.md)
* [Docker swarm mode overlay network security model](../../network/drivers/overlay.md)

2
engine/swarm/networking.md
View File

@ -231,7 +231,7 @@ endpoint mode with an external load balancer, or use multiple smaller overlay ne
Management and control plane data related to a swarm is always encrypted.
For more details about the encryption mechanisms, see the
[Docker swarm mode overlay network security model](../../network/overlay.md).
[Docker swarm mode overlay network security model](../../network/drivers/overlay.md).
Application data among swarm nodes is not encrypted by default. To encrypt this
traffic on a given overlay network, use the `--opt encrypted` flag on `docker

2
engine/swarm/services.md
View File

@ -546,7 +546,7 @@ $ docker service update --network-rm my-network my-web
For more information on overlay networking and service discovery, refer to
[Attach services to an overlay network](networking.md) and
[Docker swarm mode overlay network security model](../../network/overlay.md).
[Docker swarm mode overlay network security model](../../network/drivers/overlay.md).
### Grant a service access to secrets

102
network/bridge.md → network/drivers/bridge.md
View File

@ -1,13 +1,14 @@
---
title: Use bridge networks
title: Bridge network driver
description: All about using user-defined bridge networks and the default bridge
keywords: network, bridge, user-defined, standalone
redirect_from:
- /engine/userguide/networking/default_network/custom-docker0/
- /engine/userguide/networking/default_network/dockerlinks/
- /engine/userguide/networking/default_network/build-bridges/
- /engine/userguide/networking/work-with-networks/
- /config/containers/bridges/
- /config/containers/bridges/
- /engine/userguide/networking/default_network/build-bridges/
- /engine/userguide/networking/default_network/custom-docker0/
- /engine/userguide/networking/default_network/dockerlinks/
- /engine/userguide/networking/work-with-networks/
- /network/bridge/
---
In terms of networking, a bridge network is a Link Layer device
@ -37,7 +38,7 @@ network.**
- **User-defined bridges provide automatic DNS resolution between containers**.
Containers on the default bridge network can only access each other by IP
addresses, unless you use the [`--link` option](links.md), which is
addresses, unless you use the [`--link` option](../links.md), which is
considered legacy. On a user-defined bridge network, containers can resolve
each other by name or alias.
@ -80,7 +81,7 @@ network.**
- **Linked containers on the default bridge network share environment variables**.
Originally, the only way to share environment variables between two containers
was to link them using the [`--link` flag](links.md). This type of
was to link them using the [`--link` flag](../links.md). This type of
variable sharing is not possible with user-defined networks. However, there
are superior ways to share environment variables. A few ideas:
@ -91,14 +92,47 @@ network.**
compose file can define the shared variables.
- You can use swarm services instead of standalone containers, and take
advantage of shared [secrets](../engine/swarm/secrets.md) and
[configs](../engine/swarm/configs.md).
advantage of shared [secrets](../../engine/swarm/secrets.md) and
[configs](../../engine/swarm/configs.md).
Containers connected to the same user-defined bridge network effectively expose all ports
to each other. For a port to be accessible to containers or non-Docker hosts on
different networks, that port must be _published_ using the `-p` or `--publish`
flag.
## Options
The following table describes the driver-specific options that you can pass to
`--option` when creating a custom network using the `bridge` driver.
| Option | Default | Description |
| ------------------------------------------------ | -------------- | ----------------------------------------------------------- |
| `com.docker.network.bridge.name` | | Interface name to use when creating the Linux bridge. |
| `com.docker.network.bridge.enable_ip_masquerade` | `true` | Enable IP masquerading. |
| `com.docker.network.bridge.enable_icc` | `true` | Enable or Disable inter-container connectivity. |
| `com.docker.network.bridge.host_binding_ipv4` | | Default IP when binding container ports. |
| `com.docker.network.driver.mtu` | `0` (no limit) | Set the containers network Maximum Transmission Unit (MTU). |
| `com.docker.network.container_iface_prefix` | `eth` | Set a custom prefix for container interfaces. |
Some of these options are also available as flags to the `dockerd` CLI, and you
can use them to configure the default `docker0` bridge when starting the Docker
daemon. The following tables shows which options have equivalent flags in the
`dockerd` CLI.
| Option | Flag |
| ------------------------------------------------ | ----------- |
| `com.docker.network.bridge.name` | - |
| `com.docker.network.bridge.enable_ip_masquerade` | `--ip-masq` |
| `com.docker.network.bridge.enable_icc` | `--icc` |
| `com.docker.network.bridge.host_binding_ipv4` | `--ip` |
| `com.docker.network.driver.mtu` | `--mtu` |
| `com.docker.network.container_iface_prefix` | - |
The Docker daemon supports a `--bridge` flag, which you can use to define
your own `docker0` bridge. Use this option if you want to run multiple daemon
instances on the same host. For details, see
[Run multiple daemons](../../engine/reference/commandline/dockerd.md#run-multiple-daemons).
## Manage a user-defined bridge
Use the `docker network create` command to create a user-defined bridge
@ -110,7 +144,7 @@ $ docker network create my-net
You can specify the subnet, the IP address range, the gateway, and other
options. See the
[docker network create](../engine/reference/commandline/network_create.md#specify-advanced-options)
[docker network create](../../engine/reference/commandline/network_create.md#specify-advanced-options)
reference or the output of `docker network create --help` for details.
Use the `docker network rm` command to remove a user-defined bridge
@ -156,9 +190,9 @@ $ docker network connect my-net my-nginx
## Disconnect a container from a user-defined bridge
To disconnect a running container from a user-defined bridge, use the `docker
network disconnect` command. The following command disconnects the `my-nginx`
container from the `my-net` network.
To disconnect a running container from a user-defined bridge, use the
`docker network disconnect` command. The following command disconnects
the `my-nginx` container from the `my-net` network.
```console
$ docker network disconnect my-net my-nginx
@ -167,36 +201,13 @@ $ docker network disconnect my-net my-nginx
## Use IPv6
If you need IPv6 support for Docker containers, you need to
[enable the option](../config/daemon/ipv6.md) on the Docker daemon and reload its
[enable the option](../../config/daemon/ipv6.md) on the Docker daemon and reload its
configuration, before creating any IPv6 networks or assigning containers IPv6
addresses.
When you create your network, you can specify the `--ipv6` flag to enable
IPv6. You can't selectively disable IPv6 support on the default `bridge` network.
## Enable forwarding from Docker containers to the outside world
By default, traffic from containers connected to the default bridge network is
**not** forwarded to the outside world. To enable forwarding, you need to change
two settings. These are not Docker commands and they affect the Docker host's
kernel.
1. Configure the Linux kernel to allow IP forwarding.
```console
$ sysctl net.ipv4.conf.all.forwarding=1
```
2. Change the policy for the `iptables` `FORWARD` policy from `DROP` to
`ACCEPT`.
```console
$ sudo iptables -P FORWARD ACCEPT
```
These settings do not persist across a reboot, so you may need to add them to a
start-up script.
## Use the default bridge network
The default `bridge` network is considered a legacy detail of Docker and is not
@ -209,7 +220,7 @@ If you do not specify a network using the `--network` flag, and you do specify a
network driver, your container is connected to the default `bridge` network by
default. Containers connected to the default `bridge` network can communicate,
but only by IP address, unless they are linked using the
[legacy `--link` flag](links.md).
[legacy `--link` flag](../links.md).
### Configure the default bridge network
@ -237,9 +248,18 @@ If you configure Docker for IPv6 support (see [Use IPv6](#use-ipv6)), the
default bridge network is also configured for IPv6 automatically. Unlike
user-defined bridges, you can't selectively disable IPv6 on the default bridge.
## Connection limit for bridge networks
Due to limitations set by the Linux kernel, bridge networks become unstable and
inter-container communications may break when 1000 containers or more connect
to a single network.
For more information about this limitation, see
[moby/moby#44973](https://github.com/moby/moby/issues/44973#issuecomment-1543747718){: target="_blank" rel="noopener"}.
## Next steps
- Go through the [standalone networking tutorial](network-tutorial-standalone.md)
- Learn about [networking from the container's point of view](../config/containers/container-networking.md)
- Go through the [standalone networking tutorial](../network-tutorial-standalone.md)
- Learn about [networking from the container's point of view](../index.md)
- Learn about [overlay networks](overlay.md)
- Learn about [Macvlan networks](macvlan.md)

8
network/host.md → network/drivers/host.md
View File

@ -1,7 +1,9 @@
---
title: Use host networking
title: Host network driver
description: All about exposing containers on the Docker host's network
keywords: network, host, standalone
redirect_from:
- /network/host/
---
If you use the `host` network mode for a container, that container's network
@ -39,8 +41,8 @@ given swarm node.
## Next steps
- Go through the [host networking tutorial](network-tutorial-host.md)
- Learn about [networking from the container's point of view](../config/containers/container-networking.md)
- Go through the [host networking tutorial](../network-tutorial-host.md)
- Learn about [networking from the container's point of view](../index.md)
- Learn about [bridge networks](bridge.md)
- Learn about [overlay networks](overlay.md)
- Learn about [Macvlan networks](macvlan.md)

0
network/images/ipvlan-l3.gliffy → network/drivers/images/ipvlan-l3.gliffy
View File

0
network/images/ipvlan-l3.png → network/drivers/images/ipvlan-l3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 18 KiB

After

Width:  |  Height:  |  Size: 18 KiB

0
network/images/ipvlan-l3.svg → network/drivers/images/ipvlan-l3.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 43 KiB

After

Width:  |  Height:  |  Size: 43 KiB

0
network/images/ipvlan_l2_simple.gliffy → network/drivers/images/ipvlan_l2_simple.gliffy
View File

0
network/images/ipvlan_l2_simple.png → network/drivers/images/ipvlan_l2_simple.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

0
network/images/ipvlan_l2_simple.svg → network/drivers/images/ipvlan_l2_simple.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 39 KiB

After

Width:  |  Height:  |  Size: 39 KiB

0
network/images/macvlan-bridge-ipvlan-l2.gliffy → network/drivers/images/macvlan-bridge-ipvlan-l2.gliffy
View File

0
network/images/macvlan-bridge-ipvlan-l2.png → network/drivers/images/macvlan-bridge-ipvlan-l2.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

0
network/images/macvlan-bridge-ipvlan-l2.svg → network/drivers/images/macvlan-bridge-ipvlan-l2.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 53 KiB

After

Width:  |  Height:  |  Size: 53 KiB

0
network/images/vlans-deeper-look.gliffy → network/drivers/images/vlans-deeper-look.gliffy
View File

0
network/images/vlans-deeper-look.png → network/drivers/images/vlans-deeper-look.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 38 KiB

After

Width:  |  Height:  |  Size: 38 KiB

0
network/images/vlans-deeper-look.svg → network/drivers/images/vlans-deeper-look.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 108 KiB

After

Width:  |  Height:  |  Size: 108 KiB

76
network/drivers/index.md Normal file
View File

@ -0,0 +1,76 @@
---
title: Network drivers overview
description: Overview of Docker network drivers and related concepts
keywords: networking, drivers, bridge, routing, routing mesh, overlay, ports
---
Docker's networking subsystem is pluggable, using drivers. Several drivers
exist by default, and provide core networking functionality:
- `bridge`: The default network driver. If you don't specify a driver, this is
the type of network you are creating. Bridge networks are commonly used when
your application runs in a container that needs to communicate with other
containers on the same host.
See [Bridge network driver](bridge.md).
- `host`: Remove network isolation between the container and the Docker host,
and use the host's networking directly.
See [Host network driver](host.md).
- `overlay`: Overlay networks connect multiple Docker daemons together and
enable Swarm services and containers to communicate across nodes. This
strategy removes the need to do OS-level routing.
See [Overlay network driver](overlay.md).
- `ipvlan`: IPvlan networks give users total control over both IPv4 and IPv6
addressing. The VLAN driver builds on top of that in giving operators complete
control of layer 2 VLAN tagging and even IPvlan L3 routing for users
interested in underlay network integration.
See [IPvlan network driver](ipvlan.md).
- `macvlan`: Macvlan networks allow you to assign a MAC address to a container,
making it appear as a physical device on your network. The Docker daemon
routes traffic to containers by their MAC addresses. Using the `macvlan`
driver is sometimes the best choice when dealing with legacy applications that
expect to be directly connected to the physical network, rather than routed
through the Docker host's network stack.
See [Macvlan network driver](macvlan.md).
- `none`: Completely isolate a container from the host and other containers.
`none` is not available for Swarm services.
See [None network driver](none.md).
- [Network plugins](/engine/extend/plugins_services/): You can install and use
third-party network plugins with Docker.
### Network driver summary
- The default bridge network is good for running containers that don't require
special networking capabilities.
- User-defined bridge networks enable containers on the same Docker host to
communicate with each other. A user-defined network typically defines an
isolated network for multiple containers belonging to a common project or
component.
- Host network shares the host's network with the container. When you use this
driver, the container's network isn't isolated from the host.
- Overlay networks are best when you need containers running on different
Docker hosts to communicate, or when multiple applications work together
using Swarm services.
- Macvlan networks are best when you are migrating from a VM setup or need your
containers to look like physical hosts on your network, each with a unique
MAC address.
- IPvlan is similar to Macvlan, but doesn't assign unique MAC addresses to
containers. Consider using IPvlan when there's a restriction on the number of
MAC addresses that can be assigned to a network interface or port.
- Third-party network plugins allow you to integrate Docker with specialized
network stacks.
## Networking tutorials
Now that you understand the basics about Docker networks, deepen your
understanding using the following tutorials:
- [Standalone networking tutorial](../network-tutorial-standalone.md)
- [Host networking tutorial](../network-tutorial-host.md)
- [Overlay networking tutorial](../network-tutorial-overlay.md)
- [Macvlan networking tutorial](../network-tutorial-macvlan.md)

17
network/ipvlan.md → network/drivers/ipvlan.md
View File

@ -1,14 +1,16 @@
---
title: Use IPvlan networks
title: IPvlan network driver
description: All about using IPvlan to make your containers appear like physical machines on the network
keywords: network, ipvlan, l2, l3, standalone
redirect_from:
- /network/ipvlan/
---
The IPvlan driver gives users total control over both IPv4 and IPv6 addressing.
The VLAN driver builds on top of that in giving operators complete control of
layer 2 VLAN tagging and even IPvlan L3 routing for users interested in underlay
network integration. For overlay deployments that abstract away physical constraints
see the [multi-host overlay](network-tutorial-overlay.md) driver.
see the [multi-host overlay](../network-tutorial-overlay.md) driver.
IPvlan is a new twist on the tried and true network virtualization technique.
The Linux implementations are extremely lightweight because rather than using
@ -25,6 +27,17 @@ setup consisting of container interfaces, attached directly to the Docker host
interface. This result is easy to access for external facing services as there
is no need for port mappings in these scenarios.
## Options
The following table describes the driver-specific options that you can pass to
`--option` when creating a network using the `ipvlan` driver.
| Option | Default | Description |
| ------------- | -------- | --------------------------------------------------------------------- |
| `ipvlan_mode` | `l2` | Sets the IPvlan operating mode. Can be one of: `l2`, `l3`, `l3s` |
| `ipvlan_flag` | `bridge` | Sets the IPvlan mode flag. Can be one of: `bridge`, `private`, `vepa` |
| `parent` | | Specifies the parent interface to use. |
## Prerequisites
- The examples on this page are all single host.

47
network/macvlan.md → network/drivers/macvlan.md
View File

@ -1,10 +1,12 @@
---
title: Use macvlan networks
description: All about using macvlan to make your containers appear like physical machines on the network
title: Macvlan network driver
description: All about using Macvlan to make your containers appear like physical
machines on the network
keywords: network, macvlan, standalone
redirect_from:
- /engine/userguide/networking/get-started-macvlan/
- /config/containers/macvlan/
- /config/containers/macvlan/
- /engine/userguide/networking/get-started-macvlan/
- /network/macvlan/
---
Some applications, especially legacy applications or applications which monitor
@ -13,12 +15,13 @@ this type of situation, you can use the `macvlan` network driver to assign a MAC
address to each container's virtual network interface, making it appear to be
a physical network interface directly connected to the physical network. In this
case, you need to designate a physical interface on your Docker host to use for
the `macvlan`, as well as the subnet and gateway of the `macvlan`. You can even
isolate your `macvlan` networks using different physical network interfaces.
the Macvlan, as well as the subnet and gateway of the network. You can even
isolate your Macvlan networks using different physical network interfaces.
Keep the following things in mind:
- It is very easy to unintentionally damage your network due to IP address
exhaustion or to "VLAN spread", which is a situation in which you have an
- You may unintentionally damage your network due to IP address
exhaustion or to "VLAN spread", a situation that occurs when you have an
inappropriately large number of unique MAC addresses in your network.
- Your networking equipment needs to be able to handle "promiscuous mode",
@ -28,12 +31,22 @@ Keep the following things in mind:
overlay (to communicate across multiple Docker hosts), these solutions may be
better in the long term.
## Create a macvlan network
## Options
When you create a `macvlan` network, it can either be in bridge mode or 802.1q
The following table describes the driver-specific options that you can pass to
`--option` when creating a network using the `macvlan` driver.
| Option | Default | Description |
| -------------- | -------- | ----------------------------------------------------------------------------- |
| `macvlan_mode` | `bridge` | Sets the Macvlan mode. Can be one of: `bridge`, `vepa`, `passthru`, `private` |
| `parent` | | Specifies the parent interface to use. |
## Create a Macvlan network
When you create a Macvlan network, it can either be in bridge mode or 802.1q
trunk bridge mode.
- In bridge mode, `macvlan` traffic goes through a physical device on the host.
- In bridge mode, Macvlan traffic goes through a physical device on the host.
- In 802.1q trunk bridge mode, traffic goes through an 802.1q sub-interface
which Docker creates on the fly. This allows you to control routing and
@ -78,7 +91,7 @@ $ docker network create -d macvlan \
-o parent=eth0.50 macvlan50
```
### Use an ipvlan instead of macvlan
### Use an IPvlan instead of Macvlan
In the above example, you are still using a L3 bridge. You can use `ipvlan`
instead, and get an L2 bridge. Specify `-o ipvlan_mode=l2`.
@ -94,7 +107,7 @@ $ docker network create -d ipvlan \
## Use IPv6
If you have [configured the Docker daemon to allow IPv6](../config/daemon/ipv6.md),
If you have [configured the Docker daemon to allow IPv6](../../config/daemon/ipv6.md),
you can use dual-stack IPv4/IPv6 `macvlan` networks.
```console
@ -108,9 +121,5 @@ $ docker network create -d macvlan \
## Next steps
- Go through the [macvlan networking tutorial](network-tutorial-macvlan.md)
- Learn about [networking from the container's point of view](../config/containers/container-networking.md)
- Learn about [bridge networks](bridge.md)
- Learn about [overlay networks](overlay.md)
- Learn about [host networking](host.md)
- Learn about [Macvlan networks](macvlan.md)
Learn how to use the Macvlan driver in the
[Macvlan networking tutorial](../network-tutorial-macvlan.md)

38
network/drivers/none.md Normal file
View File

@ -0,0 +1,38 @@
---
title: None network driver
description: How to isolate the networking stack of a container using the none driver
keywords: network, none, standalone
redirect_from:
- /network/none/
---
If you want to completely isolate the networking stack of a container, you can
use the `--network none` flag when starting the container. Within the container,
only the loopback device is created.
The following example shows the output of `ip link show` in an `alpine`
container using the `none` network driver.
```console
$ docker run --rm --network none alpine:latest ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
```
No IPv6 loopback address is configured for containers using the `none` driver.
```console
$ docker run --rm --network none --name no-net-alpine alpine:latest ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
```
## Next steps
- Go through the [host networking tutorial](../network-tutorial-host.md)
- Learn about [networking from the container's point of view](../index.md)
- Learn about [bridge networks](bridge.md)
- Learn about [overlay networks](overlay.md)
- Learn about [Macvlan networks](macvlan.md)

22
network/overlay.md → network/drivers/overlay.md
View File

@ -1,10 +1,11 @@
---
title: Use overlay networks
title: Overlay network driver
description: All about using overlay networks
keywords: network, overlay, user-defined, swarm, service
redirect_from:
- /engine/userguide/networking/overlay-security-model/
- /config/containers/overlay/
- /config/containers/overlay/
- /engine/userguide/networking/overlay-security-model/
- /network/overlay/
---
The `overlay` network driver creates a distributed network among multiple
@ -187,7 +188,7 @@ from the swarm.
4. Create or re-create the `docker_gwbridge` bridge manually with your custom
settings, using the `docker network create` command.
This example uses the subnet `10.11.0.0/16`. For a full list of customizable
options, see [Bridge driver options](../engine/reference/commandline/network_create.md#bridge-driver-options).
options, see [Bridge driver options](../../engine/reference/commandline/network_create.md#bridge-driver-options).
```console
$ docker network create \
@ -284,9 +285,18 @@ routing on the individual Docker daemon hosts.
For most situations, you should connect to the service name, which is load-balanced and handled by all containers ("tasks") backing the service. To get a list of all tasks backing the service, do a DNS lookup for `tasks.<service-name>.`
## Connection limit for overlay networks
Due to limitations set by the Linux kernel, overlay networks become unstable and
inter-container communications may break when 1000 containers are co-located on
the same host.
For more information about this limitation, see
[moby/moby#44973](https://github.com/moby/moby/issues/44973#issuecomment-1543747718){: target="_blank" rel="noopener"}.
## Next steps
- Go through the [overlay networking tutorial](network-tutorial-overlay.md)
- Learn about [networking from the container's point of view](../config/containers/container-networking.md)
- Go through the [overlay networking tutorial](../network-tutorial-overlay.md)
- Learn about [networking from the container's point of view](../index.md)
- Learn about [standalone bridge networks](bridge.md)
- Learn about [Macvlan networks](macvlan.md)

1
network/images/multi_tenant_8021q_vlans.gliffy
View File

File diff suppressed because one or more lines are too long

BIN
network/images/multi_tenant_8021q_vlans.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 18 KiB

1
network/images/multi_tenant_8021q_vlans.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 48 KiB

199
network/index.md
View File

@ -1,103 +1,144 @@
---
title: Networking overview
description: Overview of Docker networks and networking concepts
keywords: networking, bridge, routing, routing mesh, overlay, ports
description: How networking works from the container's point of view
keywords: networking, container, standalone
redirect_from:
- /engine/userguide/networking/
- /engine/userguide/networking/dockernetworks/
- /articles/networking/
- /articles/networking/
- /config/containers/container-networking/
- /engine/userguide/networking/
- /engine/userguide/networking/configure-dns/
- /engine/userguide/networking/default_network/binding/
- /engine/userguide/networking/default_network/configure-dns/
- /engine/userguide/networking/default_network/container-communication/
- /engine/userguide/networking/dockernetworks/
---
One of the reasons Docker containers and services are so powerful is that
you can connect them together, or connect them to non-Docker workloads. Docker
containers and services do not even need to be aware that they are deployed on
Docker, or whether their peers are also Docker workloads or not. Whether your
Docker hosts run Linux, Windows, or a mix of the two, you can use Docker to
manage them in a platform-agnostic way.
Container networking refers to the ability for containers to connect to and
communicate with each other, or to non-Docker workloads.
This topic defines some basic Docker networking concepts and prepares you to
design and deploy your applications to take full advantage of these
capabilities.
A container has no information about what kind of network it's attached to,
or whether their peers are also Docker workloads or not.
A container only sees a network interface with an IP address,
a gateway, a routing table, DNS services, and other networking details.
That is, unless the container uses the `none` network driver.
## Scope of this topic
This page describes networking from the point of view of the container,
and the concepts around container networking.
This page doesn't describe OS-specific details about how Docker networks work.
For information about how Docker manipulates `iptables` rules on Linux,
see [Packet filtering and firewalls](packet-filtering-firewalls.md).
This topic does **not** go into OS-specific details about how Docker networks
work, so you will not find information about how Docker manipulates `iptables`
rules on Linux or how it manipulates routing rules on Windows servers, and you
will not find detailed information about how Docker forms and encapsulates
packets or handles encryption. See [Docker and iptables](iptables.md).
## Published ports
In addition, this topic does not provide any tutorials for how to create,
manage, and use Docker networks. Each section includes links to relevant
tutorials and command references.
By default, when you create or run a container using `docker create` or `docker run`,
the container doesn't expose any of its ports to the outside world.
Use the `--publish` or `-p` flag to make a port available to services
outside of Docker.
This creates a firewall rule in the host,
mapping a container port to a port on the Docker host to the outside world.
Here are some examples:
## Network drivers
| Flag value | Description |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `-p 8080:80` | Map TCP port 80 in the container to port `8080` on the Docker host. |
| `-p 192.168.1.100:8080:80` | Map TCP port 80 in the container to port `8080` on the Docker host for connections to host IP `192.168.1.100`. |
| `-p 8080:80/udp` | Map UDP port 80 in the container to port `8080` on the Docker host. |
| `-p 8080:80/tcp -p 8080:80/udp` | Map TCP port 80 in the container to TCP port `8080` on the Docker host, and map UDP port `80` in the container to UDP port `8080` on the Docker host. |
Docker's networking subsystem is pluggable, using drivers. Several drivers
exist by default, and provide core networking functionality:
> **Important**
>
> Publishing container ports is insecure by default. Meaning, when you publish
> a container's ports it becomes available not only to the Docker host, but to
> the outside world as well.
>
> If you include the localhost IP address (`127.0.0.1`) with the publish flag,
> only the Docker host can the published container port.
>
> ```console
> $ docker run -p 127.0.0.1:8080:80 nginx
> ```
>
> > **Warning**
> >
> > Hosts within the same L2 segment (for example, hosts connected to the same
> > network switch) can reach ports published to localhost.
> > For more information, see
> > [moby/moby#45610](https://github.com/moby/moby/issues/45610)
> {: .warning }
{: .important }
- `bridge`: The default network driver. If you don't specify a driver, this is
the type of network you are creating. **Bridge networks are usually used when
your applications run in standalone containers that need to communicate.** See
[bridge networks](bridge.md).
If you want to make a container accessible to other containers,
it isn't necessary to publish the container's ports.
Inter-container communication is enabled by connecting the containers to the
same network, usually a [bridge network](./drivers/bridge.md).
- `host`: For standalone containers, remove network isolation between the
container and the Docker host, and use the host's networking directly. See
[use the host network](host.md).
## IP address and hostname
- `overlay`: Overlay networks connect multiple Docker daemons together and
enable swarm services to communicate with each other. You can also use overlay
networks to facilitate communication between a swarm service and a standalone
container, or between two standalone containers on different Docker daemons.
This strategy removes the need to do OS-level routing between these
containers. See [overlay networks](overlay.md).
By default, the container gets an IP address for every Docker network it attaches to.
A container receives an IP address out of the IP subnet of the network.
The Docker daemon performs dynamic subnetting and IP address allocation for containers.
Each network also has a default subnet mask and gateway.
- `ipvlan`: IPvlan networks give users total control over both IPv4 and IPv6
addressing. The VLAN driver builds on top of that in giving operators complete
control of layer 2 VLAN tagging and even IPvlan L3 routing for users
interested in underlay network integration. See [IPvlan networks](ipvlan.md).
When you connect an existing container to a different network using `docker network connect`,
you can use the `--ip` or `--ip6` flags on that command
to specify the container's IP address on the additional network.
- `macvlan`: Macvlan networks allow you to assign a MAC address to a container,
making it appear as a physical device on your network. The Docker daemon
routes traffic to containers by their MAC addresses. Using the `macvlan`
driver is sometimes the best choice when dealing with legacy applications that
expect to be directly connected to the physical network, rather than routed
through the Docker host's network stack. See
[Macvlan networks](macvlan.md).
When a container starts, it can only attach to a single network, using the `--network` flag.
You can connect a running container to multiple networks using the `docker network connect` command.
When you start a container using the `--network` flag,
you can specify the IP address for the container on that network using the `--ip` or `--ip6` flags.
- `none`: For this container, disable all networking. Usually used in
conjunction with a custom network driver. `none` is not available for swarm
services. See
[disable container networking](none.md).
In the same way, a container's hostname defaults to be the container's ID in Docker.
You can override the hostname using `--hostname`.
When connecting to an existing network using `docker network connect`,
you can use the `--alias` flag to specify an additional network alias for the container on that network.
- [Network plugins](/engine/extend/plugins_services/): You can install and use
third-party network plugins with Docker. These plugins are available from
[Docker Hub](https://hub.docker.com/search?category=network&q=&type=plugin)
or from third-party vendors. See the vendor's documentation for installing and
using a given network plugin.
## DNS services
By default, containers inherit the DNS settings of the host,
as defined in the `/etc/resolv.conf` configuration file.
Containers that attach to the default `bridge` network receive a copy of this file.
Containers that attach to a
[custom network](network-tutorial-standalone.md#use-user-defined-bridge-networks)
use Docker's embedded DNS server.
The embedded DNS server forwards external DNS lookups to the DNS servers configured on the host.
### Network driver summary
You can configure DNS resolution on a per-container basis, using flags for the
`docker run` or `docker create` command used to start the container.
The following table describes the available `docker run` flags related to DNS
configuration.
- **User-defined bridge networks** are best when you need multiple containers to
communicate on the same Docker host.
- **Host networks** are best when the network stack should not be isolated from
the Docker host, but you want other aspects of the container to be isolated.
- **Overlay networks** are best when you need containers running on different
Docker hosts to communicate, or when multiple applications work together using
swarm services.
- **Macvlan networks** are best when you are migrating from a VM setup or
need your containers to look like physical hosts on your network, each with a
unique MAC address.
- **Third-party network plugins** allow you to integrate Docker with specialized
network stacks.
| Flag | Description |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--dns` | The IP address of a DNS server. To specify multiple DNS servers, use multiple `--dns` flags. If the container can't reach any of the IP addresses you specify, it uses Google's public DNS server at `8.8.8.8`. This allows containers to resolve internet domains. |
| `--dns-search` | A DNS search domain to search non-fully-qualified hostnames. To specify multiple DNS search prefixes, use multiple `--dns-search` flags. |
| `--dns-opt` | A key-value pair representing a DNS option and its value. See your operating system's documentation for `resolv.conf` for valid options. |
| `--hostname` | The hostname a container uses for itself. Defaults to the container's ID if not specified. |
## Networking tutorials
### Nameservers with IPv6 addresses
Now that you understand the basics about Docker networks, deepen your
understanding using the following tutorials:
If the `/etc/resolv.conf` file on the host system contains one or more
nameserver entries with an IPv6 address, those nameserver entries get copied
over to `/etc/resolv.conf` in containers that you run.
- [Standalone networking tutorial](network-tutorial-standalone.md)
- [Host networking tutorial](network-tutorial-host.md)
- [Overlay networking tutorial](network-tutorial-overlay.md)
- [Macvlan networking tutorial](network-tutorial-macvlan.md)
For containers using musl libc (in other words, Alpine Linux), this results in
a race condition for hostname lookup. As a result, hostname resolution might
sporadically fail if the external IPv6 DNS server wins the race condition
against the embedded DNS server.
It's rare that the external DNS server is faster than the embedded one. But
things like garbage collection, or large numbers of concurrent DNS requests,
can result in a roundtrip to the external server being faster than local
resolution, on some occasions.
### Custom hosts
Custom hosts, defined in `/etc/hosts` on the host machine, aren't inherited by containers.
To pass additional hosts into container, refer to
[add entries to container hosts file](../engine/reference/commandline/run.md#add-host)
in the `docker run` reference documentation.
## Proxy server
If your container needs to use a proxy server, see
[Use a proxy server](proxy.md).

6
network/links.md
View File

@ -17,7 +17,7 @@ with `--link` is sharing environment variables between containers. However,
you can use other mechanisms such as volumes to share environment variables
between containers in a more controlled way.
>
> See [Differences between user-defined bridges and the default bridge](bridge.md#differences-between-user-defined-bridges-and-the-default-bridge)
> See [Differences between user-defined bridges and the default bridge](drivers/bridge.md#differences-between-user-defined-bridges-and-the-default-bridge)
> for some alternatives to using `--link`.
{:.warning}
@ -30,7 +30,7 @@ Docker link feature to allow containers to discover each other and securely
transfer information about one container to another container. With the
introduction of the Docker networks feature, you can still create links but they
behave differently between default `bridge` network and
[user defined networks](bridge.md#differences-between-user-defined-bridges-and-the-default-bridge).
[user defined networks](drivers/bridge.md#differences-between-user-defined-bridges-and-the-default-bridge).
This section briefly discusses connecting via a network port and then goes into
detail on container linking in default `bridge` network.
@ -124,7 +124,7 @@ $ docker port nostalgic_morse 5000
> **Note**:
> This section covers the legacy link feature in the default `bridge` network.
> Refer to [differences between user-defined bridges and the default bridge](bridge.md#differences-between-user-defined-bridges-and-the-default-bridge)
> Refer to [differences between user-defined bridges and the default bridge](drivers/bridge.md#differences-between-user-defined-bridges-and-the-default-bridge)
> for more information on links in user-defined networks.
Network port mappings are not the only way Docker containers can connect to one

2
network/network-tutorial-standalone.md
View File

@ -22,7 +22,7 @@ host running elsewhere.
running on the same Docker host. This is recommended for standalone containers
running in production.
Although [overlay networks](overlay.md) are generally used for swarm services,
Although [overlay networks](drivers/overlay.md) are generally used for swarm services,
you can also use an overlay network for standalone containers. That's covered as
part of the [tutorial on using overlay networks](network-tutorial-overlay.md#use-an-overlay-network-for-standalone-containers).

54
network/none.md
View File

@ -1,54 +0,0 @@
---
title: Disable networking for a container
description: How to disable networking by using the none driver
keywords: network, none, standalone
---
If you want to completely disable the networking stack on a container, you can
use the `--network none` flag when starting the container. Within the container,
only the loopback device is created. The following example illustrates this.
1. Create the container.
```console
$ docker run --rm -dit \
--network none \
--name no-net-alpine \
alpine:latest \
ash
```
2. Check the container's network stack, by executing some common networking
commands within the container. Notice that no `eth0` was created.
```console
$ docker exec no-net-alpine ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1
link/ipip 0.0.0.0 brd 0.0.0.0
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN qlen 1
link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
```
```console
$ docker exec no-net-alpine ip route
```
The second command returns empty because there is no routing table.
3. Stop the container. It is removed automatically because it was created with
the `--rm` flag.
```console
$ docker stop no-net-alpine
```
## Next steps
- Go through the [host networking tutorial](network-tutorial-host.md)
- Learn about [networking from the container's point of view](../config/containers/container-networking.md)
- Learn about [bridge networks](bridge.md)
- Learn about [overlay networks](overlay.md)
- Learn about [Macvlan networks](macvlan.md)

105
network/iptables.md → network/packet-filtering-firewalls.md
View File

@ -1,7 +1,9 @@
---
title: Docker and iptables
description: The basics of how Docker works with iptables
keywords: network, iptables
title: Packet filtering and firewalls
description: How Docker works with packet filtering, iptables, and firewalls
keywords: network, iptables, firewall
redirect_from:
- /network/iptables/
---
On Linux, Docker manipulates `iptables` rules to provide network isolation.
@ -19,19 +21,41 @@ describes how to achieve that, and what caveats you need to be aware of.
Docker installs two custom iptables chains named `DOCKER-USER` and `DOCKER`,
and it ensures that incoming packets are always checked by these two chains
first.
first. These chains are part of the `FORWARD` chain.
All of Docker's `iptables` rules are added to the `DOCKER` chain. Do not
manipulate this chain manually. If you need to add rules which load before
Docker's rules, add them to the `DOCKER-USER` chain. These rules are applied
before any rules Docker creates automatically.
Rules added to the `FORWARD` chain -- either manually, or by another
iptables-based firewall -- are evaluated _after_ these chains. This means that
if you expose a port through Docker, this port gets exposed no matter what
rules your firewall has configured. If you want those rules to apply even
when a port gets exposed through Docker, you _must_ add these rules to the
`DOCKER-USER` chain.
Other rules added to the `FORWARD` chain, either manually, or by another
iptables-based firewall, are evaluated after the `DOCKER-USER` and `DOCKER` chains.
This means that if you publish a port through Docker,
this port gets published no matter what rules your firewall has configured.
If you want rules to apply even when a port gets published through Docker,
you must add these rules to the `DOCKER-USER` chain.
### Match the original IP and ports for requests
When packets arrive to the `DOCKER-USER` chain, they have already passed through
a Destination Network Address Translation (DNAT) filter. That means that the
`iptables` flags you use can only match internal IP addresses and ports of
containers.
If you want to match traffic based on the original IP and port in the network
request, you must use the
[`conntrack` iptables extension](https://ipset.netfilter.org/iptables-extensions.man.html#lbAO).
For example:
```console
$ sudo iptables -I DOCKER-USER -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$ sudo iptables -I DOCKER-USER -p tcp -m conntrack --ctorigsrc 1.2.3.4 --ctorigdstport 80 -j ACCEPT
```
> **Important**
>
> Using the `conntrack` extension may result in degraded performance.
{: .important }
### Restrict connections to the Docker host
@ -82,17 +106,52 @@ $ iptables -I DOCKER-USER -i src_if -o dst_if -j ACCEPT
## Prevent Docker from manipulating iptables
It is possible to set the `iptables` key to `false` in the Docker engine's configuration file at `/etc/docker/daemon.json`, but this option is not appropriate for most users. It is not possible to completely prevent Docker from creating `iptables` rules, and creating them after-the-fact is extremely involved and beyond the scope of these instructions. Setting `iptables` to `false` will more than likely break container networking for the Docker engine.
It is possible to set the `iptables` key to `false` in the Docker engine's configuration file at `/etc/docker/daemon.json`, but this option is not appropriate for most users. It is not possible to completely prevent Docker from creating `iptables` rules, and creating them after-the-fact is extremely involved and beyond the scope of these instructions. Setting `iptables` to `false` will more than likely break container networking for the Docker engine.
For system integrators who wish to build the Docker runtime into other applications, explore the [`moby` project](https://mobyproject.org/).
## Setting the default bind address for containers
By default, the Docker daemon will expose ports on the `0.0.0.0` address, i.e.
any address on the host. If you want to change that behavior to only
expose ports on an internal IP address, you can use the `--ip` option to
specify a different IP address. However, setting `--ip` only changes the
_default_, it does not _restrict_ services to that IP.
By default, the Docker daemon binds published container ports to the `0.0.0.0`
address. When you publish a container's ports as follows:
```console
docker run -p 8080:80 nginx
```
This publishes port 8080 to all network interfaces on the host, potentially
making them available to the outside world. Unless you've disabled IPv6 at the
kernel level, the port gets published on both IPv4 and IPv6.
You can change the default binding address for published container ports so that
they're only accessible to the Docker host by default. To do that, you can
configure the daemon to use the loopback address (`127.0.0.1`) instead.
To do so, configure the `"ip"` key in the `daemon.json` configuration file:
```json
{
"ip": "127.0.0.1"
}
```
This changes the default binding address to `127.0.0.1` for published container
ports on the default bridge network.
Restart the daemon for this change to take effect.
Alternatively, you can use the `dockerd --ip` flag when starting the daemon.
> **Note**
>
> Changing the default bind address doesn't have any effect on Swarm services.
> Swarm services are always exposed on the `0.0.0.0` network interface.
To configure this setting for user-defined bridge networks, use
the `com.docker.network.bridge.host_binding_ipv4`
[driver option](./drivers/bridge.md#options) when you create the network.
```console
$ docker network create mybridge \
-o "com.docker.network.bridge.host_binding_ipv4=127.0.0.1"
```
## Integration with Firewalld
@ -110,3 +169,17 @@ $ firewall-cmd --reload
```
Restarting `dockerd` daemon inserts the interface into the `docker` zone.
## Docker and ufw
[Uncomplicated Firewall](https://launchpad.net/ufw){: target="_blank" rel="noopener"}
(ufw) is a frontend that ships with Debian and Ubuntu,
and it lets you manage firewall rules. Docker and ufw use iptables in ways
that make them incompatible with each other.
When you publish a container's ports using Docker, traffic to and from that
container gets diverted before it goes through the ufw firewall settings.
Docker routes container traffic in the `nat` table, which means that packets
are diverted before it reaches the `INPUT` and `OUTPUT` chains that ufw uses.
Packets are routed before the firewall rules can be applied,
effectively ignoring your firewall configuration.