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

Engdocs 1938 tier1 (#19068) 

* ENGDOCS-1938-tier1

* .

* .
This commit is contained in:
Allie Sadler 2024-01-11 08:19:40 +00:00 committed by GitHub
parent 418a47c7bc
commit 5ddf631cd4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 58 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
content/network/drivers/ipvlan.md
View File

@ -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` |
| `parent` | | Specifies the parent interface to use. |
## Prerequisites
## Examples
### Prerequisites
- The examples on this page are all single host.
- 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`
interface that will enable local host connectivity to perform the examples.
- Kernel requirements:
- To check your current kernel version, use `uname -r`
- IPvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy)
- IPvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy). To check your current kernel version, use `uname -r`
## IPvlan L2 mode example usage
### IPvlan L2 mode example usage
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`.
@ -88,7 +89,7 @@ $ docker run --net=db_net -it --rm alpine /bin/sh
# 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
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
@ -156,7 +157,7 @@ $ docker exec -it cid2 /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
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
underlying host.
### VLAN ID 20
#### VLAN ID 20
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`.
@ -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
```
### VLAN ID 30
#### VLAN ID 30
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
@ -296,7 +297,7 @@ are as follows:
- 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`
## IPvlan L3 mode example
### IPvlan L3 mode example
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
@ -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
interface.
- 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`.
- Unlike IPvlan l2 modes, different subnets/networks can ping one another as
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
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
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
> 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
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
```
> *Note*
> **Note**
>
> 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
@ -582,9 +583,9 @@ default dev eth0 metric 1024
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
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
```
**Example:** VLAN sub-interface manually created with any name:
Example: VLAN sub-interface manually created with any name:
```console
# create a new sub interface tied to dot1q vlan 40

2
content/network/drivers/macvlan.md
View File

@ -122,4 +122,4 @@ $ docker network create -d macvlan \
## Next steps
Learn how to use the Macvlan driver in the
[Macvlan networking tutorial](../network-tutorial-macvlan.md)
[Macvlan networking tutorial](../network-tutorial-macvlan.md).

2
content/network/drivers/none.md
View File

@ -31,7 +31,7 @@ $ docker run --rm --network none --name no-net-alpine alpine:latest ip addr show
## 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 [bridge networks](bridge.md)
- Learn about [overlay networks](overlay.md)

29
content/network/links.md
View File

@ -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
```
> **Note**:
> **Note**
>
> Containers have an internal network and an IP address.
> Docker can have a variety of network configurations. You can see more
> information on Docker networking [here](index.md).
@ -118,12 +119,14 @@ $ docker port nostalgic_morse 5000
127.0.0.1:49155
```
> **Note**:
> **Note**
>
> The `-p` flag can be used multiple times to configure multiple ports.
## Connect with the linking system
> **Note**:
> **Note**
>
> 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)
> 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.
> **Note**:
> **Note**
>
> 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
> 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
target container of information related to the source container.
> **Warning**:
> It is important to understand that *all* environment variables originating
> from Docker within a container are made available to *any* container
> **Warning**
>
> 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
> data is stored in them.
{ .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.
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:
<name>_PORT_<port>_<protocol>
source container. Each variable has a unique prefix in the form `<name>_PORT_<port>_<protocol>`
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
```
> **Note**:
> **Note**
>
> In the example, you had to install `ping` because it was not included
> 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
to make use of your `db` container.
> **Note**:
> **Note**
>
> You can link multiple recipient containers to a single source. For
> example, you could have multiple (differently named) web containers attached to your
>`db` container.

5
content/network/network-tutorial-host.md
View File

@ -55,15 +55,12 @@ host.
4. Stop the container. It will be removed automatically as it was started using the `--rm` option.
```basn
```console
docker container stop my_nginx
```
## 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)
- [Overlay networking tutorial](network-tutorial-overlay.md)
- [Macvlan networking tutorial](network-tutorial-macvlan.md)

8
content/network/network-tutorial-macvlan.md
View File

@ -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
within the `Networks` key:
```none
```console
$ docker container inspect my-macvlan-alpine
...truncated...
@ -162,7 +162,7 @@ be physically attached to the network.
3. Inspect the `my-second-macvlan-alpine` container and notice the `MacAddress`
key within the `Networks` key:
```none
```console
$ docker container inspect my-second-macvlan-alpine
...truncated...
@ -217,10 +217,6 @@ be physically attached to the network.
```
## 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)
- [Overlay networking tutorial](network-tutorial-overlay.md)
- [Host networking tutorial](network-tutorial-host.md)

17
content/network/network-tutorial-overlay.md
View File

@ -168,7 +168,9 @@ connect a service to each of them.
service will publish port 80 to the outside world. All of the service
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
$ 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
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.
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
```
> **Note**
>
> 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`):
@ -455,8 +461,8 @@ need to have Docker installed and running.
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
connected directly to the Docker daemon host's networking stack, or to start
a container with no network devices. **This tutorial will connect two
containers to the `bridge` network.**
a container with no network devices. This tutorial will connect two
containers to the `bridge` network.
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
@ -634,9 +640,6 @@ learn about user-defined bridge networks, continue to the
## 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)
- [Standalone networking tutorial](network-tutorial-standalone.md)
- [Macvlan networking tutorial](network-tutorial-macvlan.md)

13
content/network/network-tutorial-standalone.md
View File

@ -9,8 +9,8 @@ For networking with swarm services, see
[Networking with swarm services](network-tutorial-overlay.md). If you need to
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
Linux, Windows, or a Mac, but for the last two, you need a second Docker
This topic includes two different tutorials. You can run each of them on
Linux, Windows, or a Mac, but for the last one, you need a second Docker
host running elsewhere.
- [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
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
a container with no network devices. **This tutorial will connect two
containers to the `bridge` network.**
a container with no network devices. This tutorial will connect two
containers to the `bridge` network.
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
@ -433,7 +433,7 @@ connected to both networks.
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
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
`alpine2` and `alpine4` (and `alpine1`, itself) to IP addresses.
@ -615,9 +615,6 @@ connected to both networks.
## 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)
- [Overlay networking tutorial](network-tutorial-overlay.md)
- [Macvlan networking tutorial](network-tutorial-macvlan.md)

6
content/network/packet-filtering-firewalls.md
View File

@ -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
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
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
```
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
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"
```
## Integration with Firewalld
## Integration with firewalld
If you are running Docker with [firewalld](https://firewalld.org)
on your system with `--iptables` enabled, Docker automatically creates a `firewalld`