diff --git a/content/engine/swarm/how-swarm-mode-works/pki.md b/content/engine/swarm/how-swarm-mode-works/pki.md index 62484e6795..c8998fb7d3 100644 --- a/content/engine/swarm/how-swarm-mode-works/pki.md +++ b/content/engine/swarm/how-swarm-mode-works/pki.md @@ -32,7 +32,7 @@ the lifetime of the node in the current swarm. The diagram below illustrates how manager nodes and worker nodes encrypt 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: diff --git a/content/engine/swarm/how-swarm-mode-works/services.md b/content/engine/swarm/how-swarm-mode-works/services.md index a6b691fa13..51861666b7 100644 --- a/content/engine/swarm/how-swarm-mode-works/services.md +++ b/content/engine/swarm/how-swarm-mode-works/services.md @@ -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. 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 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 schedules tasks to worker nodes. -![Services flow](../images/service-lifecycle.webp) +![Services flow](../images/service-lifecycle.webp?w=700) ### 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 in black. -![Global vs replicated services](../images/replicated-vs-global.webp) +![Global vs replicated services](../images/replicated-vs-global.webp?w=450) ## Learn more diff --git a/content/network/drivers/images/vlans-deeper-look.png b/content/network/drivers/images/vlans-deeper-look.png deleted file mode 100644 index 32d95f600e..0000000000 Binary files a/content/network/drivers/images/vlans-deeper-look.png and /dev/null differ diff --git a/content/network/drivers/images/vlans-deeper-look.svg b/content/network/drivers/images/vlans-deeper-look.svg deleted file mode 100644 index 96cd21d52f..0000000000 --- a/content/network/drivers/images/vlans-deeper-look.svg +++ /dev/null @@ -1 +0,0 @@ -DockerHost:Frontend,Backend &CreditCardAppTiersareIsolatedbutcanstillcommunicateinsideinterfaceoranyotherDockerhostsusingtheparentVLANID802.1QTrunk -canbeasingleEthernetlinkorMultipleBondedEthernetlinksInterfaceeth0Container(s)Eth010.1.20.0/24Parent:eth0.20VLANID:20CreditCardsBackendContainer(s)Eth010.1.30.0/24Container(s)Eth010.1.10.0/24FrontendGateway10.1.20.1andothercontainersonthesameVLAN/subnetGateway10.1.10.1andothercontainersonthesameVLAN/subnetGateway10.1.30.1andothercontainersonthesameVLAN/subnet:Parenteth0.10VLANID:10Parent:eth0.30VLAN:30Network & otherDockerHosts \ No newline at end of file diff --git a/content/network/drivers/images/vlans-deeper-look.webp b/content/network/drivers/images/vlans-deeper-look.webp new file mode 100644 index 0000000000..3f41b69df7 Binary files /dev/null and b/content/network/drivers/images/vlans-deeper-look.webp differ diff --git a/content/network/drivers/ipvlan.md b/content/network/drivers/ipvlan.md index 91df24c651..2a540dd348 100644 --- a/content/network/drivers/ipvlan.md +++ b/content/network/drivers/ipvlan.md @@ -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 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 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 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 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 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 makes IPvlan L3 mode a prime candidate for those looking for massive scale and diff --git a/content/storage/_index.md b/content/storage/_index.md index 00baa66415..fdf455fe7f 100644 --- a/content/storage/_index.md +++ b/content/storage/_index.md @@ -36,7 +36,7 @@ in the container's filesystem. 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. -![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 Docker_ (`/var/lib/docker/volumes/` on Linux). Non-Docker processes should not diff --git a/content/storage/bind-mounts.md b/content/storage/bind-mounts.md index 9ad952d608..6e5bbc05c2 100644 --- a/content/storage/bind-mounts.md +++ b/content/storage/bind-mounts.md @@ -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 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 diff --git a/content/storage/storagedriver/_index.md b/content/storage/storagedriver/_index.md index 538c7a22e4..471a7e8827 100644 --- a/content/storage/storagedriver/_index.md +++ b/content/storage/storagedriver/_index.md @@ -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 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 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 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 writable container layer. Each storage driver handles the implementation diff --git a/content/storage/storagedriver/btrfs-driver.md b/content/storage/storagedriver/btrfs-driver.md index 9fc800132b..47ddf29767 100644 --- a/content/storage/storagedriver/btrfs-driver.md +++ b/content/storage/storagedriver/btrfs-driver.md @@ -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 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 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 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 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 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 *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. 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 running the `btrfs` driver is as follows: diff --git a/content/storage/storagedriver/device-mapper-driver.md b/content/storage/storagedriver/device-mapper-driver.md index b6c5a93d53..961b9be430 100644 --- a/content/storage/storagedriver/device-mapper-driver.md +++ b/content/storage/storagedriver/device-mapper-driver.md @@ -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` 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` @@ -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 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 the container is a thin snapshot of an image, it doesn't have the block, but it diff --git a/content/storage/storagedriver/zfs-driver.md b/content/storage/storagedriver/zfs-driver.md index b07b407392..154a72cd66 100644 --- a/content/storage/storagedriver/zfs-driver.md +++ b/content/storage/storagedriver/zfs-driver.md @@ -150,7 +150,7 @@ ZFS uses the following objects: 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. @@ -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 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: @@ -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. 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 diff --git a/content/storage/tmpfs.md b/content/storage/tmpfs.md index 5371a21a22..9e30f9357b 100644 --- a/content/storage/tmpfs.md +++ b/content/storage/tmpfs.md @@ -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 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 persist in either the host or the container writable layer. diff --git a/content/storage/volumes.md b/content/storage/volumes.md index b091ddb914..0f626f8094 100644 --- a/content/storage/volumes.md +++ b/content/storage/volumes.md @@ -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 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 [tmpfs mount](tmpfs.md) to avoid storing the data anywhere permanently, and to