refresh diagrams (#18567)

* refresh diagrams

* fix build

* tweaks to images

* remove old images

* review fixes

content/engine/swarm/how-swarm-mode-works/nodes.md

@@ -14,7 +14,7 @@ Engine 1.12 or later in swarm mode.
 There are two types of nodes: [**managers**](#manager-nodes) and
 [**workers**](#worker-nodes).
 
-![Swarm mode cluster](/engine/swarm/images/swarm-diagram.png)
+![Swarm mode cluster](/engine/swarm/images/swarm-diagram.webp)
 
 If you haven't already, read through the
 [swarm mode overview](../index.md) and

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.png)
+![TLS diagram](/engine/swarm/images/tls.webp)
 
 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.png)
+![ HTTP listener service with three replicas](../images/services-diagram.webp)
 
 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.png)
+![Services flow](../images/service-lifecycle.webp)
 
 ### Pending services
 
@@ -112,10 +112,10 @@ orchestrator creates a task and the scheduler assigns the task to the new node.
 Good candidates for global services are monitoring agents, anti-virus scanners
 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 yellow and a global service
+The diagram below shows a three-service replica in gray and a global service
-in gray.
+in black.
 
-![Global vs replicated services](../images/replicated-vs-global.png)
+![Global vs replicated services](../images/replicated-vs-global.webp)
 
 ## Learn more
 

content/engine/swarm/ingress.md

@@ -73,7 +73,7 @@ the node. For externally routable IP addresses, the port is available from
 outside the host. For all other IP addresses the access is only available from
 within the host.
 
-![Service ingress image](images/ingress-routing-mesh.png)
+![Service ingress image](images/ingress-routing-mesh.webp)
 
 You can publish a port for an existing service using the following command:
 
@@ -202,7 +202,7 @@ You can configure an external load balancer to route requests to a swarm
 service. For example, you could configure [HAProxy](https://www.haproxy.org) to
 balance requests to an nginx service published to port 8080.
 
-![Ingress with external load balancer image](images/ingress-lb.png)
+![Ingress with external load balancer image](images/ingress-lb.webp)
 
 In this case, port 8080 must be open between the load balancer and the nodes in
 the swarm. The swarm nodes can reside on a private network that is accessible to

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.png)
+![Multiple IPvlan hosts](images/macvlan-bridge-ipvlan-l2.webp)
 
 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`.
@@ -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.png)
+![Docker IPvlan L2 mode](images/ipvlan-l3.webp)
 
 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.png)
+![Types of mounts and where they live on the Docker host](images/types-of-mounts.webp)
 
 - 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.png)
+![Bind mounts on the Docker host](images/types-of-mounts-bind.webp)
 
 ## Choose the -v or --mount flag
 

content/storage/images/volumes-shared-storage.svg

@@ -1,121 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<svg width="740px" height="220px" viewBox="0 0 740 220" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" style="background: #FFFFFF;">
-    <!-- Generator: Sketch 49.1 (51147) - http://www.bohemiancoding.com/sketch -->
-    <title>volumes-shared-storage</title>
-    <desc>Created with Sketch.</desc>
-    <defs>
-        <circle id="path-1" cx="4" cy="4" r="4"></circle>
-        <circle id="path-2" cx="4" cy="4" r="4"></circle>
-        <circle id="path-3" cx="4" cy="4" r="4"></circle>
-    </defs>
-    <g id="volumes-shared-storage" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
-        <g id="group" transform="translate(154.000000, 9.000000)">
-            <g id="object-storage" transform="translate(34.000000, 163.000000)">
-                <rect id="node-border" fill="#445D6E" x="0" y="0" width="365" height="40" rx="2"></rect>
-                <text font-family="OpenSans, Open Sans" font-size="10" font-weight="normal" fill="#F7F8F9">
-                    <tspan x="139.191895" y="24">shared file storage</tspan>
-                </text>
-            </g>
-            <g id="dtr">
-                <text id="Datacenter" font-family="OpenSans-Semibold, Open Sans" font-size="10" font-weight="500" fill="#82949E">
-                    <tspan x="7.025" y="134.009524">Datacenter</tspan>
-                </text>
-                <g id="arrows-copy" transform="translate(104.000000, 119.000000)">
-                    <g id="arrow-copy-2" transform="translate(218.500000, 24.500000) rotate(-90.000000) translate(-218.500000, -24.500000) translate(194.500000, 20.500000)">
-                        <path d="M2,4 L47.5027472,4" id="Line" stroke="#445D6E" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path>
-                        <g id="Oval">
-                            <use fill="#445D6E" fill-rule="evenodd" xlink:href="#path-1"></use>
-                            <circle stroke="#F7F8F9" stroke-width="2" cx="4" cy="4" r="5"></circle>
-                        </g>
-                    </g>
-                    <g id="arrow-copy-3" transform="translate(111.500000, 24.500000) rotate(-90.000000) translate(-111.500000, -24.500000) translate(87.500000, 20.500000)">
-                        <path d="M2,4 L47.6344168,4" id="Line" stroke="#445D6E" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path>
-                        <g id="Oval">
-                            <use fill="#445D6E" fill-rule="evenodd" xlink:href="#path-2"></use>
-                            <circle stroke="#F7F8F9" stroke-width="2" cx="4" cy="4" r="5"></circle>
-                        </g>
-                    </g>
-                    <g id="arrow-copy-4" transform="translate(4.500000, 24.500000) rotate(-90.000000) translate(-4.500000, -24.500000) translate(-19.500000, 20.500000)">
-                        <path d="M2,4 L47.5027472,4" id="Line" stroke="#445D6E" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path>
-                        <g id="Oval">
-                            <use fill="#445D6E" fill-rule="evenodd" xlink:href="#path-3"></use>
-                            <circle stroke="#F7F8F9" stroke-width="2" cx="4" cy="4" r="5"></circle>
-                        </g>
-                    </g>
-                </g>
-                <g id="nodes" transform="translate(61.000000, 18.000000)">
-                    <g id="node-3" transform="translate(214.000000, 0.000000)">
-                        <g id="node">
-                            <g id="node-label">
-                                <path d="M0,2.00295631 C0,0.896754086 0.897702336,0 1.99174577,0 L71,0 L71,10.6452381 C71,16.5244408 66.2312425,21.2904762 60.3513837,21.2904762 L0,21.2904762 L0,2.00295631 Z" id="Rectangle-127" fill="#445D6E"></path>
-                                <text id="node-3" font-family="OpenSans, Open Sans" font-size="8" font-weight="normal" fill="#FFFFFF">
-                                    <tspan x="6" y="14">node-3</tspan>
-                                </text>
-                            </g>
-                        </g>
-                        <g id="engine" transform="translate(1.000000, 79.000000)">
-                            <rect id="Rectangle-138" fill="#1488C6" x="0" y="0" width="95" height="22" rx="2"></rect>
-                            <text id="Docker" font-family="OpenSans, Open Sans" font-size="10" font-weight="normal" fill="#FFFFFF">
-                                <tspan x="31.4838867" y="15">Docker</tspan>
-                            </text>
-                        </g>
-                        <g id="ucp" transform="translate(1.000000, 56.000000)">
-                            <rect id="Rectangle-138" fill="#1488C6" x="0" y="0" width="95" height="22" rx="2"></rect>
-                            <text id="service-replica-3" font-family="OpenSans, Open Sans" font-size="10" font-weight="normal" fill="#FFFFFF">
-                                <tspan x="10.1362305" y="15">service-replica-3</tspan>
-                            </text>
-                        </g>
-                        <rect id="node-border" stroke="#445D6E" stroke-width="2" x="0" y="0" width="97" height="102" rx="2"></rect>
-                    </g>
-                    <g id="node-2" transform="translate(107.000000, 0.000000)">
-                        <g id="node">
-                            <g id="node-label">
-                                <path d="M0,2.00295631 C0,0.896754086 0.897702336,0 1.99174577,0 L71,0 L71,10.6452381 C71,16.5244408 66.2312425,21.2904762 60.3513837,21.2904762 L0,21.2904762 L0,2.00295631 Z" id="Rectangle-127" fill="#445D6E"></path>
-                                <text id="node-2" font-family="OpenSans, Open Sans" font-size="8" font-weight="normal" fill="#FFFFFF">
-                                    <tspan x="6" y="14">node-2</tspan>
-                                </text>
-                            </g>
-                        </g>
-                        <g id="engine" transform="translate(1.000000, 79.000000)">
-                            <rect id="Rectangle-138" fill="#1488C6" x="0" y="0" width="95" height="22" rx="2"></rect>
-                            <text id="Docker" font-family="OpenSans, Open Sans" font-size="10" font-weight="normal" fill="#FFFFFF">
-                                <tspan x="31.4838867" y="15">Docker</tspan>
-                            </text>
-                        </g>
-                        <g id="ucp" transform="translate(1.000000, 56.000000)">
-                            <rect id="Rectangle-138" fill="#1488C6" x="0" y="0" width="95" height="22" rx="2"></rect>
-                            <text id="service-replica-2" font-family="OpenSans, Open Sans" font-size="10" font-weight="normal" fill="#FFFFFF">
-                                <tspan x="10.1362305" y="15">service-replica-2</tspan>
-                            </text>
-                        </g>
-                        <rect id="node-border" stroke="#445D6E" stroke-width="2" x="0" y="0" width="97" height="102" rx="2"></rect>
-                    </g>
-                    <g id="node-1">
-                        <g id="node">
-                            <g id="node-label">
-                                <path d="M0,2.00295631 C0,0.896754086 0.897702336,0 1.99174577,0 L71,0 L71,10.6452381 C71,16.5244408 66.2312425,21.2904762 60.3513837,21.2904762 L0,21.2904762 L0,2.00295631 Z" id="Rectangle-127" fill="#445D6E"></path>
-                                <text id="node-1" font-family="OpenSans, Open Sans" font-size="8" font-weight="normal" fill="#FFFFFF">
-                                    <tspan x="6" y="14">node-1</tspan>
-                                </text>
-                            </g>
-                        </g>
-                        <g id="engine" transform="translate(1.000000, 79.000000)">
-                            <rect id="Rectangle-138" fill="#1488C6" x="0" y="0" width="95" height="22" rx="2"></rect>
-                            <text id="Docker" font-family="OpenSans, Open Sans" font-size="10" font-weight="normal" fill="#FFFFFF">
-                                <tspan x="31.4838867" y="15">Docker</tspan>
-                            </text>
-                        </g>
-                        <g id="ucp" transform="translate(1.000000, 56.000000)">
-                            <rect id="Rectangle-138" fill="#1488C6" x="0" y="0" width="95" height="22" rx="2"></rect>
-                            <text id="service-replica-1" font-family="OpenSans, Open Sans" font-size="10" font-weight="normal" fill="#FFFFFF">
-                                <tspan x="10.1362305" y="15">service-replica-1</tspan>
-                            </text>
-                        </g>
-                        <rect id="node-border" stroke="#445D6E" stroke-width="2" x="0" y="0" width="97" height="102" rx="2"></rect>
-                    </g>
-                </g>
-                <path d="M0,2.00814042 C0,0.89907509 0.887227083,0 2.00256702,0 L430.997433,0 C432.10342,0 433,0.900800619 433,2.00814042 L433,141.99186 C433,143.100925 432.112773,144 430.997433,144 L2.00256702,144 C0.896579794,144 0,143.099199 0,141.99186 L0,2.00814042 Z" id="group" stroke="#82949E" stroke-width="2" stroke-dasharray="5,5,5,5"></path>
-            </g>
-        </g>
-    </g>
-</svg>

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.jpg)
+![Layers of a container based on the Ubuntu image](images/container-layers.webp)
 
 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.jpg)
+![Containers sharing the same image](images/sharing-layers.webp)
 
 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/aufs-driver.md

@@ -76,7 +76,7 @@ The unification process is referred to as a _union mount_.
 
 The diagram below shows a Docker container based on the `ubuntu:latest` image.
 
-![Layers of an Ubuntu container](images/aufs_layers.jpg)
+![Layers of an Ubuntu container](images/aufs_layers.webp) 
 
 Each image layer, and the container layer, are represented on the Docker host as
 subdirectories within `/var/lib/docker/`. The union mount provides the unified

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.jpg)
+![Subvolume example](images/btfs_subvolume.webp)
 
 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.jpg)
+![Snapshots diagram](images/btfs_snapshots.webp)
 
 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.jpg)
+![Snapshot and subvolume sharing data](images/btfs_pool.webp)
 
 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.jpg)
+![Btrfs container layers](images/btfs_container_layer.webp)
 
 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

@@ -740,7 +740,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.jpg)
+![Ubuntu and busybox image layers](images/two_dm_container.webp)
 
 ## How container reads and writes work with `devicemapper`
 
@@ -750,7 +750,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.jpg)
+![Reading a block with devicemapper](images/dm_container.webp)
 
 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/overlayfs-driver.md

@@ -213,7 +213,7 @@ The unified view is exposed through a directory called `merged` which is
 effectively the containers mount point. The diagram shows how Docker constructs
 map to OverlayFS constructs.
 
-![How Docker constructs map to OverlayFS constructs](images/overlay_constructs.jpg)
+![How Docker constructs map to OverlayFS constructs](images/overlay_constructs.webp)
 
 Where the image layer and the container layer contain the same files, the
 container layer "wins" and obscures the existence of the same files in the image

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.jpg)
+![ZFS snapshots and clones](images/zfs_clones.webp)
 
 
 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.jpg)
+![ZFS pool for Docker container](images/zfs_zpool.webp)
 
 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.jpg)
+![ZFS block sharing](images/zpool_blocks.webp)
 
 
 ### 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.png)
+![tmpfs on the Docker host](images/types-of-mounts-tmpfs.webp)
 
 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.png)
+![Volumes on the Docker host](images/types-of-mounts-volume.webp)
 
 If your container generates non-persistent state data, consider using a
 [tmpfs mount](tmpfs.md) to avoid storing the data anywhere permanently, and to
@@ -408,7 +408,7 @@ $ docker volume rm nginx-vol
 When building fault-tolerant applications, you may need to configure multiple
 replicas of the same service to have access to the same files.
 
-![shared storage](images/volumes-shared-storage.svg)
+![shared storage](images/volumes-shared-storage.webp)
 
 There are several ways to achieve this when developing your applications.
 One is to add logic to your application to store files on a cloud object