mirror of https://github.com/docker/docs.git
parent
418a47c7bc
commit
5ddf631cd4
|
@ -39,7 +39,9 @@ The following table describes the driver-specific options that you can pass to
|
||||||
| `ipvlan_flag` | `bridge` | Sets the IPvlan mode flag. Can be one of: `bridge`, `private`, `vepa` |
|
| `ipvlan_flag` | `bridge` | Sets the IPvlan mode flag. Can be one of: `bridge`, `private`, `vepa` |
|
||||||
| `parent` | | Specifies the parent interface to use. |
|
| `parent` | | Specifies the parent interface to use. |
|
||||||
|
|
||||||
## Prerequisites
|
## Examples
|
||||||
|
|
||||||
|
### Prerequisites
|
||||||
|
|
||||||
- The examples on this page are all single host.
|
- The examples on this page are all single host.
|
||||||
- All examples can be performed on a single host running Docker. Any
|
- All examples can be performed on a single host running Docker. Any
|
||||||
|
@ -49,10 +51,9 @@ The following table describes the driver-specific options that you can pass to
|
||||||
`docker network create` all together and the driver will create a `dummy`
|
`docker network create` all together and the driver will create a `dummy`
|
||||||
interface that will enable local host connectivity to perform the examples.
|
interface that will enable local host connectivity to perform the examples.
|
||||||
- Kernel requirements:
|
- Kernel requirements:
|
||||||
- To check your current kernel version, use `uname -r`
|
- IPvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy). To check your current kernel version, use `uname -r`
|
||||||
- IPvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy)
|
|
||||||
|
|
||||||
## IPvlan L2 mode example usage
|
### IPvlan L2 mode example usage
|
||||||
|
|
||||||
An example of the IPvlan `L2` mode topology is shown in the following image.
|
An example of the IPvlan `L2` mode topology is shown in the following image.
|
||||||
The driver is specified with `-d driver_name` option. In this case `-d ipvlan`.
|
The driver is specified with `-d driver_name` option. In this case `-d ipvlan`.
|
||||||
|
@ -88,7 +89,7 @@ $ docker run --net=db_net -it --rm alpine /bin/sh
|
||||||
# they are intentionally filtered by Linux for additional isolation.
|
# they are intentionally filtered by Linux for additional isolation.
|
||||||
```
|
```
|
||||||
|
|
||||||
The default mode for IPvlan is `l2`. If `-o ipvlan_mode=` are left unspecified,
|
The default mode for IPvlan is `l2`. If `-o ipvlan_mode=` is left unspecified,
|
||||||
the default mode will be used. Similarly, if the `--gateway` is left empty, the
|
the default mode will be used. Similarly, if the `--gateway` is left empty, the
|
||||||
first usable address on the network will be set as the gateway. For example, if
|
first usable address on the network will be set as the gateway. For example, if
|
||||||
the subnet provided in the network create is `--subnet=192.168.1.0/24` then the
|
the subnet provided in the network create is `--subnet=192.168.1.0/24` then the
|
||||||
|
@ -156,7 +157,7 @@ $ docker exec -it cid2 /bin/sh
|
||||||
$ docker exec -it cid3 /bin/sh
|
$ docker exec -it cid3 /bin/sh
|
||||||
```
|
```
|
||||||
|
|
||||||
## IPvlan 802.1Q trunk L2 mode example usage
|
### IPvlan 802.1Q trunk L2 mode example usage
|
||||||
|
|
||||||
Architecturally, IPvlan L2 mode trunking is the same as Macvlan with regard to
|
Architecturally, IPvlan L2 mode trunking is the same as Macvlan with regard to
|
||||||
gateways and L2 path isolation. There are nuances that can be advantageous for
|
gateways and L2 path isolation. There are nuances that can be advantageous for
|
||||||
|
@ -202,7 +203,7 @@ without a router routing between the two networks. The default namespace is not
|
||||||
reachable per IPvlan design in order to isolate container namespaces from the
|
reachable per IPvlan design in order to isolate container namespaces from the
|
||||||
underlying host.
|
underlying host.
|
||||||
|
|
||||||
### VLAN ID 20
|
#### VLAN ID 20
|
||||||
|
|
||||||
In the first network tagged and isolated by the Docker host, `eth0.20` is the
|
In the first network tagged and isolated by the Docker host, `eth0.20` is the
|
||||||
parent interface tagged with VLAN id `20` specified with `-o parent=eth0.20`.
|
parent interface tagged with VLAN id `20` specified with `-o parent=eth0.20`.
|
||||||
|
@ -222,7 +223,7 @@ $ docker run --net=ipvlan20 -it --name ivlan_test1 --rm alpine /bin/sh
|
||||||
$ docker run --net=ipvlan20 -it --name ivlan_test2 --rm alpine /bin/sh
|
$ docker run --net=ipvlan20 -it --name ivlan_test2 --rm alpine /bin/sh
|
||||||
```
|
```
|
||||||
|
|
||||||
### VLAN ID 30
|
#### VLAN ID 30
|
||||||
|
|
||||||
In the second network, tagged and isolated by the Docker host, `eth0.30` is the
|
In the second network, tagged and isolated by the Docker host, `eth0.30` is the
|
||||||
parent interface tagged with VLAN id `30` specified with `-o parent=eth0.30`. The
|
parent interface tagged with VLAN id `30` specified with `-o parent=eth0.30`. The
|
||||||
|
@ -296,7 +297,7 @@ are as follows:
|
||||||
- VLAN: 30, Subnet: 10.1.100.0/16, Gateway: 10.1.100.1
|
- VLAN: 30, Subnet: 10.1.100.0/16, Gateway: 10.1.100.1
|
||||||
- `--subnet=10.1.100.0/16 --gateway=10.1.100.1 -o parent=eth0.30`
|
- `--subnet=10.1.100.0/16 --gateway=10.1.100.1 -o parent=eth0.30`
|
||||||
|
|
||||||
## IPvlan L3 mode example
|
### IPvlan L3 mode example
|
||||||
|
|
||||||
IPvlan will require routes to be distributed to each endpoint. The driver only
|
IPvlan will require routes to be distributed to each endpoint. The driver only
|
||||||
builds the IPvlan L3 mode port and attaches the container to the interface. Route
|
builds the IPvlan L3 mode port and attaches the container to the interface. Route
|
||||||
|
@ -327,7 +328,7 @@ mode that reduces a failure domain to a local host only.
|
||||||
requires a netlink route in the default namespace pointing to the IPvlan parent
|
requires a netlink route in the default namespace pointing to the IPvlan parent
|
||||||
interface.
|
interface.
|
||||||
- The parent interface used in this example is `eth0` and it is on the subnet
|
- The parent interface used in this example is `eth0` and it is on the subnet
|
||||||
`192.168.1.0/24`. Notice the `docker network` is **not** on the same subnet
|
`192.168.1.0/24`. Notice the `docker network` is not on the same subnet
|
||||||
as `eth0`.
|
as `eth0`.
|
||||||
- Unlike IPvlan l2 modes, different subnets/networks can ping one another as
|
- Unlike IPvlan l2 modes, different subnets/networks can ping one another as
|
||||||
long as they share the same parent interface `-o parent=`.
|
long as they share the same parent interface `-o parent=`.
|
||||||
|
@ -388,7 +389,7 @@ able to ping a remote host, the remote host or the physical network in between
|
||||||
need to have a route pointing to the host IP address of the container's Docker
|
need to have a route pointing to the host IP address of the container's Docker
|
||||||
host eth interface.
|
host eth interface.
|
||||||
|
|
||||||
## Dual stack IPv4 IPv6 IPvlan L2 mode
|
### Dual stack IPv4 IPv6 IPvlan L2 mode
|
||||||
|
|
||||||
- Not only does Libnetwork give you complete control over IPv4 addressing, but
|
- Not only does Libnetwork give you complete control over IPv4 addressing, but
|
||||||
it also gives you total control over IPv6 addressing as well as feature parity
|
it also gives you total control over IPv6 addressing as well as feature parity
|
||||||
|
@ -509,9 +510,9 @@ $ docker run --net=ipvlan140 --ip=192.168.140.10 -it --rm alpine /bin/sh
|
||||||
> subnet. However, IPvlan `L3` will route the unicast traffic between disparate
|
> subnet. However, IPvlan `L3` will route the unicast traffic between disparate
|
||||||
> subnets as long as they share the same `-o parent` parent link.
|
> subnets as long as they share the same `-o parent` parent link.
|
||||||
|
|
||||||
## Dual stack IPv4 IPv6 IPvlan L3 mode
|
### Dual stack IPv4 IPv6 IPvlan L3 mode
|
||||||
|
|
||||||
**Example:** IPvlan L3 Mode Dual Stack IPv4/IPv6, Multi-Subnet w/ 802.1Q VLAN Tag:118
|
Example: IPvlan L3 Mode Dual Stack IPv4/IPv6, Multi-Subnet w/ 802.1Q VLAN Tag:118
|
||||||
|
|
||||||
As in all of the examples, a tagged VLAN interface does not have to be used. The
|
As in all of the examples, a tagged VLAN interface does not have to be used. The
|
||||||
sub-interfaces can be swapped with `eth0`, `eth1`, `bond0` or any other valid
|
sub-interfaces can be swapped with `eth0`, `eth1`, `bond0` or any other valid
|
||||||
|
@ -571,7 +572,7 @@ $$ ip -6 route
|
||||||
default dev eth0 metric 1024
|
default dev eth0 metric 1024
|
||||||
```
|
```
|
||||||
|
|
||||||
> *Note*
|
> **Note**
|
||||||
>
|
>
|
||||||
> There may be a bug when specifying `--ip6=` addresses when you delete a
|
> There may be a bug when specifying `--ip6=` addresses when you delete a
|
||||||
> container with a specified v6 address and then start a new container with the
|
> container with a specified v6 address and then start a new container with the
|
||||||
|
@ -582,9 +583,9 @@ default dev eth0 metric 1024
|
||||||
docker: Error response from daemon: Address already in use.
|
docker: Error response from daemon: Address already in use.
|
||||||
```
|
```
|
||||||
|
|
||||||
## Manually create 802.1Q links
|
### Manually create 802.1Q links
|
||||||
|
|
||||||
### VLAN ID 40
|
#### VLAN ID 40
|
||||||
|
|
||||||
If a user does not want the driver to create the VLAN sub-interface, it needs to
|
If a user does not want the driver to create the VLAN sub-interface, it needs to
|
||||||
exist before running `docker network create`. If you have sub-interface
|
exist before running `docker network create`. If you have sub-interface
|
||||||
|
@ -613,7 +614,7 @@ $ docker run --net=ipvlan40 -it --name ivlan_test5 --rm alpine /bin/sh
|
||||||
$ docker run --net=ipvlan40 -it --name ivlan_test6 --rm alpine /bin/sh
|
$ docker run --net=ipvlan40 -it --name ivlan_test6 --rm alpine /bin/sh
|
||||||
```
|
```
|
||||||
|
|
||||||
**Example:** VLAN sub-interface manually created with any name:
|
Example: VLAN sub-interface manually created with any name:
|
||||||
|
|
||||||
```console
|
```console
|
||||||
# create a new sub interface tied to dot1q vlan 40
|
# create a new sub interface tied to dot1q vlan 40
|
||||||
|
|
|
@ -122,4 +122,4 @@ $ docker network create -d macvlan \
|
||||||
## Next steps
|
## Next steps
|
||||||
|
|
||||||
Learn how to use the Macvlan driver in the
|
Learn how to use the Macvlan driver in the
|
||||||
[Macvlan networking tutorial](../network-tutorial-macvlan.md)
|
[Macvlan networking tutorial](../network-tutorial-macvlan.md).
|
|
@ -31,7 +31,7 @@ $ docker run --rm --network none --name no-net-alpine alpine:latest ip addr show
|
||||||
|
|
||||||
## Next steps
|
## Next steps
|
||||||
|
|
||||||
- Go through the [host networking tutorial](../network-tutorial-host.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 [networking from the container's point of view](../index.md)
|
||||||
- Learn about [bridge networks](bridge.md)
|
- Learn about [bridge networks](bridge.md)
|
||||||
- Learn about [overlay networks](overlay.md)
|
- Learn about [overlay networks](overlay.md)
|
||||||
|
|
|
@ -44,7 +44,8 @@ Let's say you used this command to run a simple Python Flask application:
|
||||||
$ docker run -d -P training/webapp python app.py
|
$ docker run -d -P training/webapp python app.py
|
||||||
```
|
```
|
||||||
|
|
||||||
> **Note**:
|
> **Note**
|
||||||
|
>
|
||||||
> Containers have an internal network and an IP address.
|
> Containers have an internal network and an IP address.
|
||||||
> Docker can have a variety of network configurations. You can see more
|
> Docker can have a variety of network configurations. You can see more
|
||||||
> information on Docker networking [here](index.md).
|
> information on Docker networking [here](index.md).
|
||||||
|
@ -118,12 +119,14 @@ $ docker port nostalgic_morse 5000
|
||||||
127.0.0.1:49155
|
127.0.0.1:49155
|
||||||
```
|
```
|
||||||
|
|
||||||
> **Note**:
|
> **Note**
|
||||||
|
>
|
||||||
> The `-p` flag can be used multiple times to configure multiple ports.
|
> The `-p` flag can be used multiple times to configure multiple ports.
|
||||||
|
|
||||||
## Connect with the linking system
|
## Connect with the linking system
|
||||||
|
|
||||||
> **Note**:
|
> **Note**
|
||||||
|
>
|
||||||
> This section covers the legacy link feature in the default `bridge` network.
|
> This section covers the legacy link feature in the default `bridge` network.
|
||||||
> Refer to [differences between user-defined bridges and the default bridge](drivers/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.
|
> for more information on links in user-defined networks.
|
||||||
|
@ -170,7 +173,8 @@ aed84ee21bde training/webapp:latest python app.py 12 hours ago Up 2 seconds 0
|
||||||
You can also use `docker inspect` to return the container's name.
|
You can also use `docker inspect` to return the container's name.
|
||||||
|
|
||||||
|
|
||||||
> **Note**:
|
> **Note**
|
||||||
|
>
|
||||||
> Container names must be unique. That means you can only call
|
> Container names must be unique. That means you can only call
|
||||||
> one container `web`. If you want to re-use a container name you must delete
|
> one container `web`. If you want to re-use a container name you must delete
|
||||||
> the old container (with `docker container rm`) before you can create a new
|
> the old container (with `docker container rm`) before you can create a new
|
||||||
|
@ -266,9 +270,10 @@ command when the source container is started
|
||||||
These environment variables enable programmatic discovery from within the
|
These environment variables enable programmatic discovery from within the
|
||||||
target container of information related to the source container.
|
target container of information related to the source container.
|
||||||
|
|
||||||
> **Warning**:
|
> **Warning**
|
||||||
> It is important to understand that *all* environment variables originating
|
>
|
||||||
> from Docker within a container are made available to *any* container
|
> It is important to understand that all environment variables originating
|
||||||
|
> from Docker within a container are made available to any container
|
||||||
> that links to it. This could have serious security implications if sensitive
|
> that links to it. This could have serious security implications if sensitive
|
||||||
> data is stored in them.
|
> data is stored in them.
|
||||||
{ .warning }
|
{ .warning }
|
||||||
|
@ -279,9 +284,7 @@ listed in the `--link` parameter. For example, if a new container called
|
||||||
then Docker creates a `WEBDB_NAME=/web/webdb` variable in the `web` container.
|
then Docker creates a `WEBDB_NAME=/web/webdb` variable in the `web` container.
|
||||||
|
|
||||||
Docker also defines a set of environment variables for each port exposed by the
|
Docker also defines a set of environment variables for each port exposed by the
|
||||||
source container. Each variable has a unique prefix in the form:
|
source container. Each variable has a unique prefix in the form `<name>_PORT_<port>_<protocol>`
|
||||||
|
|
||||||
<name>_PORT_<port>_<protocol>
|
|
||||||
|
|
||||||
The components in this prefix are:
|
The components in this prefix are:
|
||||||
|
|
||||||
|
@ -383,7 +386,8 @@ PING webdb (172.17.0.5): 48 data bytes
|
||||||
56 bytes from 172.17.0.5: icmp_seq=2 ttl=64 time=0.256 ms
|
56 bytes from 172.17.0.5: icmp_seq=2 ttl=64 time=0.256 ms
|
||||||
```
|
```
|
||||||
|
|
||||||
> **Note**:
|
> **Note**
|
||||||
|
>
|
||||||
> In the example, you had to install `ping` because it was not included
|
> In the example, you had to install `ping` because it was not included
|
||||||
> in the container initially.
|
> in the container initially.
|
||||||
|
|
||||||
|
@ -391,7 +395,8 @@ Here, you used the `ping` command to ping the `db` container using its host entr
|
||||||
which resolves to `172.17.0.5`. You can use this host entry to configure an application
|
which resolves to `172.17.0.5`. You can use this host entry to configure an application
|
||||||
to make use of your `db` container.
|
to make use of your `db` container.
|
||||||
|
|
||||||
> **Note**:
|
> **Note**
|
||||||
|
>
|
||||||
> You can link multiple recipient containers to a single source. For
|
> You can link multiple recipient containers to a single source. For
|
||||||
> example, you could have multiple (differently named) web containers attached to your
|
> example, you could have multiple (differently named) web containers attached to your
|
||||||
>`db` container.
|
>`db` container.
|
||||||
|
|
|
@ -55,15 +55,12 @@ host.
|
||||||
|
|
||||||
4. Stop the container. It will be removed automatically as it was started using the `--rm` option.
|
4. Stop the container. It will be removed automatically as it was started using the `--rm` option.
|
||||||
|
|
||||||
```basn
|
```console
|
||||||
docker container stop my_nginx
|
docker container stop my_nginx
|
||||||
```
|
```
|
||||||
|
|
||||||
## Other networking tutorials
|
## Other networking tutorials
|
||||||
|
|
||||||
Now that you have completed the networking tutorials for standalone containers,
|
|
||||||
you might want to run through these other networking tutorials:
|
|
||||||
|
|
||||||
- [Standalone networking tutorial](network-tutorial-standalone.md)
|
- [Standalone networking tutorial](network-tutorial-standalone.md)
|
||||||
- [Overlay networking tutorial](network-tutorial-overlay.md)
|
- [Overlay networking tutorial](network-tutorial-overlay.md)
|
||||||
- [Macvlan networking tutorial](network-tutorial-macvlan.md)
|
- [Macvlan networking tutorial](network-tutorial-macvlan.md)
|
|
@ -68,7 +68,7 @@ on your network, your container appears to be physically attached to the network
|
||||||
3. Inspect the `my-macvlan-alpine` container and notice the `MacAddress` key
|
3. Inspect the `my-macvlan-alpine` container and notice the `MacAddress` key
|
||||||
within the `Networks` key:
|
within the `Networks` key:
|
||||||
|
|
||||||
```none
|
```console
|
||||||
$ docker container inspect my-macvlan-alpine
|
$ docker container inspect my-macvlan-alpine
|
||||||
|
|
||||||
...truncated...
|
...truncated...
|
||||||
|
@ -162,7 +162,7 @@ be physically attached to the network.
|
||||||
3. Inspect the `my-second-macvlan-alpine` container and notice the `MacAddress`
|
3. Inspect the `my-second-macvlan-alpine` container and notice the `MacAddress`
|
||||||
key within the `Networks` key:
|
key within the `Networks` key:
|
||||||
|
|
||||||
```none
|
```console
|
||||||
$ docker container inspect my-second-macvlan-alpine
|
$ docker container inspect my-second-macvlan-alpine
|
||||||
|
|
||||||
...truncated...
|
...truncated...
|
||||||
|
@ -217,10 +217,6 @@ be physically attached to the network.
|
||||||
```
|
```
|
||||||
|
|
||||||
## Other networking tutorials
|
## Other networking tutorials
|
||||||
|
|
||||||
Now that you have completed the networking tutorial for `macvlan` networks,
|
|
||||||
you might want to run through these other networking tutorials:
|
|
||||||
|
|
||||||
- [Standalone networking tutorial](network-tutorial-standalone.md)
|
- [Standalone networking tutorial](network-tutorial-standalone.md)
|
||||||
- [Overlay networking tutorial](network-tutorial-overlay.md)
|
- [Overlay networking tutorial](network-tutorial-overlay.md)
|
||||||
- [Host networking tutorial](network-tutorial-host.md)
|
- [Host networking tutorial](network-tutorial-host.md)
|
|
@ -168,7 +168,9 @@ connect a service to each of them.
|
||||||
service will publish port 80 to the outside world. All of the service
|
service will publish port 80 to the outside world. All of the service
|
||||||
task containers can communicate with each other without opening any ports.
|
task containers can communicate with each other without opening any ports.
|
||||||
|
|
||||||
> **Note**: Services can only be created on a manager.
|
> **Note**
|
||||||
|
>
|
||||||
|
> Services can only be created on a manager.
|
||||||
|
|
||||||
```console
|
```console
|
||||||
$ docker service create \
|
$ docker service create \
|
||||||
|
@ -222,7 +224,9 @@ connect a service to each of them.
|
||||||
`nginx-net-2` and notice that all the service task containers are connected
|
`nginx-net-2` and notice that all the service task containers are connected
|
||||||
to it.
|
to it.
|
||||||
|
|
||||||
> **Note**: Even though overlay networks are automatically created on swarm
|
> **Note**
|
||||||
|
>
|
||||||
|
> Even though overlay networks are automatically created on swarm
|
||||||
> worker nodes as needed, they are not automatically removed.
|
> worker nodes as needed, they are not automatically removed.
|
||||||
|
|
||||||
8. Clean up the service and the networks. From `manager`, run the following
|
8. Clean up the service and the networks. From `manager`, run the following
|
||||||
|
@ -369,6 +373,8 @@ example also uses Linux hosts, but the same commands work on Windows.
|
||||||
fb635f5ece59563e7b8b99556f816d24e6949a5f6a5b1fbd92ca244db17a4342
|
fb635f5ece59563e7b8b99556f816d24e6949a5f6a5b1fbd92ca244db17a4342
|
||||||
```
|
```
|
||||||
|
|
||||||
|
> **Note**
|
||||||
|
>
|
||||||
> Automatic DNS container discovery only works with unique container names.
|
> Automatic DNS container discovery only works with unique container names.
|
||||||
|
|
||||||
6. On `host2`, verify that `test-net` was created (and has the same NETWORK ID as `test-net` on `host1`):
|
6. On `host2`, verify that `test-net` was created (and has the same NETWORK ID as `test-net` on `host1`):
|
||||||
|
@ -455,8 +461,8 @@ need to have Docker installed and running.
|
||||||
The default `bridge` network is listed, along with `host` and `none`. The
|
The default `bridge` network is listed, along with `host` and `none`. The
|
||||||
latter two are not fully-fledged networks, but are used to start a container
|
latter two are not fully-fledged networks, but are used to start a container
|
||||||
connected directly to the Docker daemon host's networking stack, or to start
|
connected directly to the Docker daemon host's networking stack, or to start
|
||||||
a container with no network devices. **This tutorial will connect two
|
a container with no network devices. This tutorial will connect two
|
||||||
containers to the `bridge` network.**
|
containers to the `bridge` network.
|
||||||
|
|
||||||
2. Start two `alpine` containers running `ash`, which is Alpine's default shell
|
2. Start two `alpine` containers running `ash`, which is Alpine's default shell
|
||||||
rather than `bash`. The `-dit` flags mean to start the container detached
|
rather than `bash`. The `-dit` flags mean to start the container detached
|
||||||
|
@ -634,9 +640,6 @@ learn about user-defined bridge networks, continue to the
|
||||||
|
|
||||||
## Other networking tutorials
|
## Other networking tutorials
|
||||||
|
|
||||||
Now that you have completed the networking tutorials for overlay networks,
|
|
||||||
you might want to run through these other networking tutorials:
|
|
||||||
|
|
||||||
- [Host networking tutorial](network-tutorial-host.md)
|
- [Host networking tutorial](network-tutorial-host.md)
|
||||||
- [Standalone networking tutorial](network-tutorial-standalone.md)
|
- [Standalone networking tutorial](network-tutorial-standalone.md)
|
||||||
- [Macvlan networking tutorial](network-tutorial-macvlan.md)
|
- [Macvlan networking tutorial](network-tutorial-macvlan.md)
|
|
@ -9,8 +9,8 @@ For networking with swarm services, see
|
||||||
[Networking with swarm services](network-tutorial-overlay.md). If you need to
|
[Networking with swarm services](network-tutorial-overlay.md). If you need to
|
||||||
learn more about Docker networking in general, see the [overview](index.md).
|
learn more about Docker networking in general, see the [overview](index.md).
|
||||||
|
|
||||||
This topic includes three different tutorials. You can run each of them on
|
This topic includes two different tutorials. You can run each of them on
|
||||||
Linux, Windows, or a Mac, but for the last two, you need a second Docker
|
Linux, Windows, or a Mac, but for the last one, you need a second Docker
|
||||||
host running elsewhere.
|
host running elsewhere.
|
||||||
|
|
||||||
- [Use the default bridge network](#use-the-default-bridge-network) demonstrates
|
- [Use the default bridge network](#use-the-default-bridge-network) demonstrates
|
||||||
|
@ -49,8 +49,8 @@ need to have Docker installed and running.
|
||||||
The default `bridge` network is listed, along with `host` and `none`. The
|
The default `bridge` network is listed, along with `host` and `none`. The
|
||||||
latter two are not fully-fledged networks, but are used to start a container
|
latter two are not fully-fledged networks, but are used to start a container
|
||||||
connected directly to the Docker daemon host's networking stack, or to start
|
connected directly to the Docker daemon host's networking stack, or to start
|
||||||
a container with no network devices. **This tutorial will connect two
|
a container with no network devices. This tutorial will connect two
|
||||||
containers to the `bridge` network.**
|
containers to the `bridge` network.
|
||||||
|
|
||||||
2. Start two `alpine` containers running `ash`, which is Alpine's default shell
|
2. Start two `alpine` containers running `ash`, which is Alpine's default shell
|
||||||
rather than `bash`. The `-dit` flags mean to start the container detached
|
rather than `bash`. The `-dit` flags mean to start the container detached
|
||||||
|
@ -433,7 +433,7 @@ connected to both networks.
|
||||||
|
|
||||||
5. On user-defined networks like `alpine-net`, containers can not only
|
5. On user-defined networks like `alpine-net`, containers can not only
|
||||||
communicate by IP address, but can also resolve a container name to an IP
|
communicate by IP address, but can also resolve a container name to an IP
|
||||||
address. This capability is called **automatic service discovery**. Let's
|
address. This capability is called automatic service discovery. Let's
|
||||||
connect to `alpine1` and test this out. `alpine1` should be able to resolve
|
connect to `alpine1` and test this out. `alpine1` should be able to resolve
|
||||||
`alpine2` and `alpine4` (and `alpine1`, itself) to IP addresses.
|
`alpine2` and `alpine4` (and `alpine1`, itself) to IP addresses.
|
||||||
|
|
||||||
|
@ -615,9 +615,6 @@ connected to both networks.
|
||||||
|
|
||||||
## Other networking tutorials
|
## Other networking tutorials
|
||||||
|
|
||||||
Now that you have completed the networking tutorials for standalone containers,
|
|
||||||
you might want to run through these other networking tutorials:
|
|
||||||
|
|
||||||
- [Host networking tutorial](network-tutorial-host.md)
|
- [Host networking tutorial](network-tutorial-host.md)
|
||||||
- [Overlay networking tutorial](network-tutorial-overlay.md)
|
- [Overlay networking tutorial](network-tutorial-overlay.md)
|
||||||
- [Macvlan networking tutorial](network-tutorial-macvlan.md)
|
- [Macvlan networking tutorial](network-tutorial-macvlan.md)
|
||||||
|
|
|
@ -19,7 +19,7 @@ describes how to achieve that, and what caveats you need to be aware of.
|
||||||
|
|
||||||
## Add iptables policies before Docker's rules
|
## Add iptables policies before Docker's rules
|
||||||
|
|
||||||
Docker installs two custom iptables chains named `DOCKER-USER` and `DOCKER`,
|
Docker installs two custom `iptables` chains named `DOCKER-USER` and `DOCKER`,
|
||||||
and it ensures that incoming packets are always checked by these two chains
|
and it ensures that incoming packets are always checked by these two chains
|
||||||
first. These chains are part of the `FORWARD` chain.
|
first. These chains are part of the `FORWARD` chain.
|
||||||
|
|
||||||
|
@ -68,7 +68,7 @@ following rule restricts external access from all IP addresses except `192.168.1
|
||||||
$ iptables -I DOCKER-USER -i ext_if ! -s 192.168.1.1 -j DROP
|
$ iptables -I DOCKER-USER -i ext_if ! -s 192.168.1.1 -j DROP
|
||||||
```
|
```
|
||||||
|
|
||||||
Please note that you will need to change `ext_if` to correspond with your
|
You will need to change `ext_if` to correspond with your
|
||||||
host's actual external interface. You could instead allow connections from a
|
host's actual external interface. You could instead allow connections from a
|
||||||
source subnet. The following rule only allows access from the subnet `192.168.1.0/24`:
|
source subnet. The following rule only allows access from the subnet `192.168.1.0/24`:
|
||||||
|
|
||||||
|
@ -153,7 +153,7 @@ $ docker network create mybridge \
|
||||||
-o "com.docker.network.bridge.host_binding_ipv4=127.0.0.1"
|
-o "com.docker.network.bridge.host_binding_ipv4=127.0.0.1"
|
||||||
```
|
```
|
||||||
|
|
||||||
## Integration with Firewalld
|
## Integration with firewalld
|
||||||
|
|
||||||
If you are running Docker with [firewalld](https://firewalld.org)
|
If you are running Docker with [firewalld](https://firewalld.org)
|
||||||
on your system with `--iptables` enabled, Docker automatically creates a `firewalld`
|
on your system with `--iptables` enabled, Docker automatically creates a `firewalld`
|
||||||
|
|
Loading…
Reference in New Issue