resize images (#18588)

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:
 

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
 

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

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

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
 

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

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:

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

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

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.

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