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

resize images (#18588)

This commit is contained in:
Allie Sadler 2023-11-06 09:27:43 +00:00 committed by GitHub
parent ddb2ed1d0b
commit c7df570f30
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
14 changed files with 22 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/engine/swarm/how-swarm-mode-works/pki.md
View File

@ -32,7 +32,7 @@ the lifetime of the node in the current swarm.
The diagram below illustrates how manager nodes and worker nodes encrypt The diagram below illustrates how manager nodes and worker nodes encrypt
communications using a minimum of TLS 1.2. communications using a minimum of TLS 1.2.
![TLS diagram](/engine/swarm/images/tls.webp) ![TLS diagram](/engine/swarm/images/tls.webp?w=600)
The example below shows the information from a certificate from a worker node: The example below shows the information from a certificate from a worker node:

6
content/engine/swarm/how-swarm-mode-works/services.md
View File

@ -31,7 +31,7 @@ For example, imagine you want to load balance between three instances of an HTTP
listener. The diagram below shows an HTTP listener service with three replicas. listener. The diagram below shows an HTTP listener service with three replicas.
Each of the three instances of the listener is a task in the swarm. Each of the three instances of the listener is a task in the swarm.
![ HTTP listener service with three replicas](../images/services-diagram.webp) ![ HTTP listener service with three replicas](../images/services-diagram.webp?w=550)
A container is an isolated process. In the swarm mode model, each task invokes A container is an isolated process. In the swarm mode model, each task invokes
exactly one container. A task is analogous to a “slot” where the scheduler exactly one container. A task is analogous to a “slot” where the scheduler
@ -66,7 +66,7 @@ current version of Docker only supports container tasks.
The diagram below shows how swarm mode accepts service create requests and The diagram below shows how swarm mode accepts service create requests and
schedules tasks to worker nodes. schedules tasks to worker nodes.
![Services flow](../images/service-lifecycle.webp) ![Services flow](../images/service-lifecycle.webp?w=700)
### Pending services ### Pending services
@ -115,7 +115,7 @@ or other types of containers that you want to run on every node in the swarm.
The diagram below shows a three-service replica in gray and a global service The diagram below shows a three-service replica in gray and a global service
in black. in black.
![Global vs replicated services](../images/replicated-vs-global.webp) ![Global vs replicated services](../images/replicated-vs-global.webp?w=450)
## Learn more ## Learn more

BIN
content/network/drivers/images/vlans-deeper-look.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 38 KiB

1
content/network/drivers/images/vlans-deeper-look.svg
View File

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

Before

Width:  |  Height:  |  Size: 108 KiB

BIN
content/network/drivers/images/vlans-deeper-look.webp Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 82 KiB

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

@ -98,7 +98,7 @@ To help understand how this mode interacts with other hosts, the following
figure shows the same layer 2 segment between two Docker hosts that applies to figure shows the same layer 2 segment between two Docker hosts that applies to
and IPvlan L2 mode. and IPvlan L2 mode.
![Multiple IPvlan hosts](images/macvlan-bridge-ipvlan-l2.webp) ![Multiple IPvlan hosts](images/macvlan-bridge-ipvlan-l2.webp?w=700)
The following will create the exact same network as the network `db_net` created The following will create the exact same network as the network `db_net` created
earlier, with the driver defaults for `--gateway=192.168.1.1` and `-o ipvlan_mode=l2`. earlier, with the driver defaults for `--gateway=192.168.1.1` and `-o ipvlan_mode=l2`.
@ -175,7 +175,7 @@ practice of layered defense in depth architectures. VLANs or the equivocal VNI
(Virtual Network Identifier) when using the Overlay driver, are the first step (Virtual Network Identifier) when using the Overlay driver, are the first step
in isolating tenant traffic. in isolating tenant traffic.
![Docker VLANs in-depth](images/vlans-deeper-look.png) ![Docker VLANs in-depth](images/vlans-deeper-look.webp)
The Linux sub-interface tagged with a VLAN can either already exist or will be The Linux sub-interface tagged with a VLAN can either already exist or will be
created when you call a `docker network create`. `docker network rm` will delete created when you call a `docker network create`. `docker network rm` will delete
@ -307,7 +307,7 @@ upstream network will not know about without route distribution. For those
curious how IPvlan L3 will fit into container networking, see the following curious how IPvlan L3 will fit into container networking, see the following
examples. examples.
![Docker IPvlan L2 mode](images/ipvlan-l3.webp) ![Docker IPvlan L2 mode](images/ipvlan-l3.webp?w=500)
IPvlan L3 mode drops all broadcast and multicast traffic. This reason alone IPvlan L3 mode drops all broadcast and multicast traffic. This reason alone
makes IPvlan L3 mode a prime candidate for those looking for massive scale and makes IPvlan L3 mode a prime candidate for those looking for massive scale and

2
content/storage/_index.md
View File

@ -36,7 +36,7 @@ in the container's filesystem.
An easy way to visualize the difference among volumes, bind mounts, and `tmpfs` An easy way to visualize the difference among volumes, bind mounts, and `tmpfs`
mounts is to think about where the data lives on the Docker host. mounts is to think about where the data lives on the Docker host.
![Types of mounts and where they live on the Docker host](images/types-of-mounts.webp) ![Types of mounts and where they live on the Docker host](images/types-of-mounts.webp?w=450&h=300)
- Volumes are stored in a part of the host filesystem which is _managed by - Volumes are stored in a part of the host filesystem which is _managed by
Docker_ (`/var/lib/docker/volumes/` on Linux). Non-Docker processes should not Docker_ (`/var/lib/docker/volumes/` on Linux). Non-Docker processes should not

2
content/storage/bind-mounts.md
View File

@ -21,7 +21,7 @@ available. If you are developing new Docker applications, consider using
[named volumes](volumes.md) instead. You can't use Docker CLI commands to directly [named volumes](volumes.md) instead. You can't use Docker CLI commands to directly
manage bind mounts. manage bind mounts.
![Bind mounts on the Docker host](images/types-of-mounts-bind.webp) ![Bind mounts on the Docker host](images/types-of-mounts-bind.webp?w=450&h=300)
## Choose the -v or --mount flag ## Choose the -v or --mount flag

4
content/storage/storagedriver/_index.md
View File

@ -73,7 +73,7 @@ writing new files, modifying existing files, and deleting files, are written to
this thin writable container layer. The diagram below shows a container based this thin writable container layer. The diagram below shows a container based
on an `ubuntu:15.04` image. on an `ubuntu:15.04` image.
![Layers of a container based on the Ubuntu image](images/container-layers.webp) ![Layers of a container based on the Ubuntu image](images/container-layers.webp?w=450&h=300)
A _storage driver_ handles the details about the way these layers interact with A _storage driver_ handles the details about the way these layers interact with
each other. Different storage drivers are available, which have advantages each other. Different storage drivers are available, which have advantages
@ -91,7 +91,7 @@ stored in this container layer, multiple containers can share access to the same
underlying image and yet have their own data state. The diagram below shows underlying image and yet have their own data state. The diagram below shows
multiple containers sharing the same Ubuntu 15.04 image. multiple containers sharing the same Ubuntu 15.04 image.
![Containers sharing the same image](images/sharing-layers.webp) ![Containers sharing the same image](images/sharing-layers.webp?w=600&h=300)
Docker uses storage drivers to manage the contents of the image layers and the Docker uses storage drivers to manage the contents of the image layers and the
writable container layer. Each storage driver handles the implementation writable container layer. Each storage driver handles the implementation

8
content/storage/storagedriver/btrfs-driver.md
View File

@ -167,14 +167,14 @@ nested and snapshotted. The diagram below shows 4 subvolumes. 'Subvolume 2' and
'Subvolume 3' are nested, whereas 'Subvolume 4' shows its own internal directory 'Subvolume 3' are nested, whereas 'Subvolume 4' shows its own internal directory
tree. tree.
![Subvolume example](images/btfs_subvolume.webp) ![Subvolume example](images/btfs_subvolume.webp?w=350&h=100)
Only the base layer of an image is stored as a true subvolume. All the other Only the base layer of an image is stored as a true subvolume. All the other
layers are stored as snapshots, which only contain the differences introduced layers are stored as snapshots, which only contain the differences introduced
in that layer. You can create snapshots of snapshots as shown in the diagram in that layer. You can create snapshots of snapshots as shown in the diagram
below. below.
![Snapshots diagram](images/btfs_snapshots.webp) ![Snapshots diagram](images/btfs_snapshots.webp?w=350&h=100)
On disk, snapshots look and feel just like subvolumes, but in reality they are On disk, snapshots look and feel just like subvolumes, but in reality they are
much smaller and more space-efficient. Copy-on-write is used to maximize storage much smaller and more space-efficient. Copy-on-write is used to maximize storage
@ -182,7 +182,7 @@ efficiency and minimize layer size, and writes in the container's writable layer
are managed at the block level. The following image shows a subvolume and its are managed at the block level. The following image shows a subvolume and its
snapshot sharing data. snapshot sharing data.
![Snapshot and subvolume sharing data](images/btfs_pool.webp) ![Snapshot and subvolume sharing data](images/btfs_pool.webp?w=450&h=200)
For maximum efficiency, when a container needs more space, it is allocated in For maximum efficiency, when a container needs more space, it is allocated in
*chunks* of roughly 1 GB in size. *chunks* of roughly 1 GB in size.
@ -192,7 +192,7 @@ own Btrfs subvolume or snapshot. The base layer of an image is stored as a
subvolume whereas child image layers and containers are stored as snapshots. subvolume whereas child image layers and containers are stored as snapshots.
This is shown in the diagram below. This is shown in the diagram below.
![Btrfs container layers](images/btfs_container_layer.webp) ![Btrfs container layers](images/btfs_container_layer.webp?w=600)
The high level process for creating images and containers on Docker hosts The high level process for creating images and containers on Docker hosts
running the `btrfs` driver is as follows: running the `btrfs` driver is as follows:

4
content/storage/storagedriver/device-mapper-driver.md
View File

@ -741,7 +741,7 @@ container, it is a snapshot of the image the container is based on. The followin
example shows a Docker host with two running containers. The first is a `ubuntu` example shows a Docker host with two running containers. The first is a `ubuntu`
container and the second is a `busybox` container. container and the second is a `busybox` container.
![Ubuntu and busybox image layers](images/two_dm_container.webp) ![Ubuntu and busybox image layers](images/two_dm_container.webp?w=450&h=100)
## How container reads and writes work with `devicemapper` ## How container reads and writes work with `devicemapper`
@ -751,7 +751,7 @@ With `devicemapper`, reads happen at the block level. The diagram below shows
the high level process for reading a single block (`0x44f`) in an example the high level process for reading a single block (`0x44f`) in an example
container. container.
![Reading a block with devicemapper](images/dm_container.webp) ![Reading a block with devicemapper](images/dm_container.webp?w=650)
An application makes a read request for block `0x44f` in the container. Because An application makes a read request for block `0x44f` in the container. Because
the container is a thin snapshot of an image, it doesn't have the block, but it the container is a thin snapshot of an image, it doesn't have the block, but it

6
content/storage/storagedriver/zfs-driver.md
View File

@ -150,7 +150,7 @@ ZFS uses the following objects:
The process of creating a clone: The process of creating a clone:
![ZFS snapshots and clones](images/zfs_clones.webp) ![ZFS snapshots and clones](images/zfs_clones.webp?w=450)
1. A read-only snapshot is created from the filesystem. 1. A read-only snapshot is created from the filesystem.
@ -175,7 +175,7 @@ on a ZFS Snapshot of the top layer of the image it's created from.
The diagram below shows how this is put together with a running container based The diagram below shows how this is put together with a running container based
on a two-layer image. on a two-layer image.
![ZFS pool for Docker container](images/zfs_zpool.webp) ![ZFS pool for Docker container](images/zfs_zpool.webp?w=600)
When you start a container, the following steps happen in order: When you start a container, the following steps happen in order:
@ -209,7 +209,7 @@ the dataset it was created from (the snapshots of its parent layers). Read
operations are fast, even if the data being read is from a deep layer. operations are fast, even if the data being read is from a deep layer.
This diagram illustrates how block sharing works: This diagram illustrates how block sharing works:
![ZFS block sharing](images/zpool_blocks.webp) ![ZFS block sharing](images/zpool_blocks.webp?w=450)
### Writing files ### Writing files

2
content/storage/tmpfs.md
View File

@ -18,7 +18,7 @@ As opposed to volumes and bind mounts, a `tmpfs` mount is temporary, and only
persisted in the host memory. When the container stops, the `tmpfs` mount is persisted in the host memory. When the container stops, the `tmpfs` mount is
removed, and files written there won't be persisted. removed, and files written there won't be persisted.
![tmpfs on the Docker host](images/types-of-mounts-tmpfs.webp) ![tmpfs on the Docker host](images/types-of-mounts-tmpfs.webp?w=450&h=300)
This is useful to temporarily store sensitive files that you don't want to This is useful to temporarily store sensitive files that you don't want to
persist in either the host or the container writable layer. persist in either the host or the container writable layer.

2
content/storage/volumes.md
View File

@ -30,7 +30,7 @@ container's writable layer, because a volume doesn't increase the size of the
containers using it, and the volume's contents exist outside the lifecycle of a containers using it, and the volume's contents exist outside the lifecycle of a
given container. given container.
![Volumes on the Docker host](images/types-of-mounts-volume.webp) ![Volumes on the Docker host](images/types-of-mounts-volume.webp?w=450&h=300)
If your container generates non-persistent state data, consider using a If your container generates non-persistent state data, consider using a
[tmpfs mount](tmpfs.md) to avoid storing the data anywhere permanently, and to [tmpfs mount](tmpfs.md) to avoid storing the data anywhere permanently, and to