docs(plugins): fix typos and formatting

Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>

docs/extend/index.md

@@ -1,24 +1,14 @@
 ---
+title: Docker Engine managed plugin system
 description: Develop and use a plugin with the managed plugin system
 keywords: "API, Usage, plugins, documentation, developer"
 ---
 
-<!-- This file is maintained within the docker/cli GitHub
-     repository at https://github.com/docker/cli/. Make all
-     pull requests against that repo. If you see this file in
-     another repository, consider it read-only there, as it will
-     periodically be overwritten by the definitive file. Pull
-     requests which include edits to this file in other repositories
-     will be rejected.
--->
-
-# Docker Engine managed plugin system
-
 - [Installing and using a plugin](index.md#installing-and-using-a-plugin)
 - [Developing a plugin](index.md#developing-a-plugin)
 - [Debugging plugins](index.md#debugging-plugins)
 
-Docker Engine's plugin system allows you to install, start, stop, and remove
+Docker Engine's plugin system lets you install, start, stop, and remove
 plugins using Docker Engine.
 
 For information about legacy (non-managed) plugins, refer to
@@ -49,78 +39,78 @@ enabled, and use it to create a volume.
 > **Note**
 >
 > This example is intended for instructional purposes only. Once the volume is
-> created, your SSH password to the remote host will be exposed as plaintext
-> when inspecting the volume. You should delete the volume as soon as you are
-> done with the example.
+> created, your SSH password to the remote host is exposed as plaintext when
+> inspecting the volume. Delete the volume as soon as you are done with the
+> example.
 
-1.  Install the `sshfs` plugin.
+1. Install the `sshfs` plugin.
 
-    ```console
-    $ docker plugin install vieux/sshfs
+   ```console
+   $ docker plugin install vieux/sshfs
 
-    Plugin "vieux/sshfs" is requesting the following privileges:
-    - network: [host]
-    - capabilities: [CAP_SYS_ADMIN]
-    Do you grant the above permissions? [y/N] y
+   Plugin "vieux/sshfs" is requesting the following privileges:
+   - network: [host]
+   - capabilities: [CAP_SYS_ADMIN]
+   Do you grant the above permissions? [y/N] y
 
-    vieux/sshfs
-    ```
+   vieux/sshfs
+   ```
 
-    The plugin requests 2 privileges:
+   The plugin requests 2 privileges:
 
-    - It needs access to the `host` network.
-    - It needs the `CAP_SYS_ADMIN` capability, which allows the plugin to run
-      the `mount` command.
+   - It needs access to the `host` network.
+   - It needs the `CAP_SYS_ADMIN` capability, which allows the plugin to run
+     the `mount` command.
 
-2.  Check that the plugin is enabled in the output of `docker plugin ls`.
+2. Check that the plugin is enabled in the output of `docker plugin ls`.
 
-    ```console
-    $ docker plugin ls
+   ```console
+   $ docker plugin ls
 
-    ID                    NAME                  TAG                 DESCRIPTION                   ENABLED
-    69553ca1d789          vieux/sshfs           latest              the `sshfs` plugin            true
-    ```
+   ID                    NAME                  TAG                 DESCRIPTION                   ENABLED
+   69553ca1d789          vieux/sshfs           latest              the `sshfs` plugin            true
+   ```
 
-3.  Create a volume using the plugin.
-    This example mounts the `/remote` directory on host `1.2.3.4` into a
-    volume named `sshvolume`.
+3. Create a volume using the plugin.
+   This example mounts the `/remote` directory on host `1.2.3.4` into a
+   volume named `sshvolume`.
 
-    This volume can now be mounted into containers.
+   This volume can now be mounted into containers.
 
-    ```console
-    $ docker volume create \
-      -d vieux/sshfs \
-      --name sshvolume \
-      -o sshcmd=user@1.2.3.4:/remote \
-      -o password=$(cat file_containing_password_for_remote_host)
+   ```console
+   $ docker volume create \
+     -d vieux/sshfs \
+     --name sshvolume \
+     -o sshcmd=user@1.2.3.4:/remote \
+     -o password=$(cat file_containing_password_for_remote_host)
 
-    sshvolume
-    ```
+   sshvolume
+   ```
 
-4.  Verify that the volume was created successfully.
+4. Verify that the volume was created successfully.
 
-    ```console
-    $ docker volume ls
+   ```console
+   $ docker volume ls
 
-    DRIVER              NAME
-    vieux/sshfs         sshvolume
-    ```
+   DRIVER              NAME
+   vieux/sshfs         sshvolume
+   ```
 
-5.  Start a container that uses the volume `sshvolume`.
+5. Start a container that uses the volume `sshvolume`.
 
-    ```console
-    $ docker run --rm -v sshvolume:/data busybox ls /data
+   ```console
+   $ docker run --rm -v sshvolume:/data busybox ls /data
 
-    <content of /remote on machine 1.2.3.4>
-    ```
+   <content of /remote on machine 1.2.3.4>
+   ```
 
-6.  Remove the volume `sshvolume`
+6. Remove the volume `sshvolume`
 
-    ```console
-    $ docker volume rm sshvolume
+   ```console
+   $ docker volume rm sshvolume
 
-    sshvolume
-    ```
+   sshvolume
+   ```
 
 To disable a plugin, use the `docker plugin disable` command. To completely
 remove it, use the `docker plugin remove` command. For other available
@@ -134,8 +124,10 @@ commands and options, see the
 The `rootfs` directory represents the root filesystem of the plugin. In this
 example, it was created from a Dockerfile:
 
-> **Note:** The `/run/docker/plugins` directory is mandatory inside of the
-> plugin's filesystem for docker to communicate with the plugin.
+> **Note**
+>
+> The `/run/docker/plugins` directory is mandatory inside of the
+> plugin's filesystem for Docker to communicate with the plugin.
 
 ```console
 $ git clone https://github.com/vieux/docker-volume-sshfs
@@ -219,11 +211,10 @@ INFO[0421] Path Called...    Returned path /data/samplevol  plugin=f52a3df433b9a
 INFO[0421] Unmount Called... Unmounted samplevol            plugin=f52a3df433b9aceee436eaada0752f5797aab1de47e5485f1690a073b860ff62
 ```
 
-#### Using docker-runc to obtain logfiles and shell into the plugin.
+#### Using runc to obtain logfiles and shell into the plugin.
 
-`docker-runc`, the default docker container runtime can be used for debugging
-plugins. This is specifically useful to collect plugin logs if they are
-redirected to a file.
+Use `runc`, the default docker container runtime, for debugging plugins by
+collecting plugin logs redirected to a file.
 
 ```console
 $ sudo runc --root /run/docker/runtime-runc/plugins.moby list

docs/extend/legacy_plugins.md

@@ -1,21 +1,11 @@
 ---
+title: Use Docker Engine plugins
 aliases:
 - "/engine/extend/plugins/"
 description: "How to add additional functionality to Docker with plugins extensions"
 keywords: "Examples, Usage, plugins, docker, documentation, user guide"
 ---
 
-<!-- This file is maintained within the docker/cli GitHub
-     repository at https://github.com/docker/cli/. Make all
-     pull requests against that repo. If you see this file in
-     another repository, consider it read-only there, as it will
-     periodically be overwritten by the definitive file. Pull
-     requests which include edits to this file in other repositories
-     will be rejected.
--->
-
-# Use Docker Engine plugins
-
 This document describes the Docker Engine plugins generally available in Docker
 Engine. To view information on plugins managed by Docker,
 refer to [Docker Engine plugin system](index.md).
@@ -40,7 +30,7 @@ Follow the instructions in the plugin's documentation.
 
 ## Finding a plugin
 
-The sections below provide an inexhaustive overview of available plugins.
+The sections below provide an overview of available third-party plugins.
 
 ### Network plugins
 
@@ -97,4 +87,4 @@ of the plugin for help. The Docker team may not be able to assist you.
 ## Writing a plugin
 
 If you are interested in writing a plugin for Docker, or seeing how they work
-under the hood, see the [docker plugins reference](plugin_api.md).
+under the hood, see the [Docker plugins reference](plugin_api.md).

docs/extend/plugin_api.md

@@ -1,19 +1,9 @@
 ---
+title: Docker Plugin API
 description: "How to write Docker plugins extensions "
 keywords: "API, Usage, plugins, documentation, developer"
 ---
 
-<!-- This file is maintained within the docker/cli GitHub
-     repository at https://github.com/docker/cli/. Make all
-     pull requests against that repo. If you see this file in
-     another repository, consider it read-only there, as it will
-     periodically be overwritten by the definitive file. Pull
-     requests which include edits to this file in other repositories
-     will be rejected.
--->
-
-# Docker Plugin API
-
 Docker plugins are out-of-process extensions which add capabilities to the
 Docker Engine.
 
@@ -26,8 +16,8 @@ If you just want to learn about or use Docker plugins, look
 
 ## What plugins are
 
-A plugin is a process running on the same or a different host as the docker daemon,
-which registers itself by placing a file on the same docker host in one of the plugin
+A plugin is a process running on the same or a different host as the Docker daemon,
+which registers itself by placing a file on the same Docker host in one of the plugin
 directories described in [Plugin discovery](#plugin-discovery).
 
 Plugins have human-readable names, which are short, lowercase strings. For
@@ -43,26 +33,26 @@ user or container tries to use one by name.
 
 There are three types of files which can be put in the plugin directory.
 
-* `.sock` files are UNIX domain sockets.
+* `.sock` files are Unix domain sockets.
 * `.spec` files are text files containing a URL, such as `unix:///other.sock` or `tcp://localhost:8080`.
 * `.json` files are text files containing a full json specification for the plugin.
 
-Plugins with UNIX domain socket files must run on the same docker host, whereas
-plugins with spec or json files can run on a different host if a remote URL is specified.
+Plugins with Unix domain socket files must run on the same Docker host.
+Plugins with `.spec` or `.json` files can run on a different host if you specify a remote URL.
 
-UNIX domain socket files must be located under `/run/docker/plugins`, whereas
+Unix domain socket files must be located under `/run/docker/plugins`, whereas
 spec files can be located either under `/etc/docker/plugins` or `/usr/lib/docker/plugins`.
 
 The name of the file (excluding the extension) determines the plugin name.
 
-For example, the `flocker` plugin might create a UNIX socket at
+For example, the `flocker` plugin might create a Unix socket at
 `/run/docker/plugins/flocker.sock`.
 
 You can define each plugin into a separated subdirectory if you want to isolate definitions from each other.
 For example, you can create the `flocker` socket under `/run/docker/plugins/flocker/flocker.sock` and only
 mount `/run/docker/plugins/flocker` inside the `flocker` container.
 
-Docker always searches for unix sockets in `/run/docker/plugins` first. It checks for spec or json files under
+Docker always searches for Unix sockets in `/run/docker/plugins` first. It checks for spec or json files under
 `/etc/docker/plugins` and `/usr/lib/docker/plugins` if the socket doesn't exist. The directory scan stops as
 soon as it finds the first plugin definition with the given name.
 
@@ -87,7 +77,7 @@ The `TLSConfig` field is optional and TLS will only be verified if this configur
 
 ## Plugin lifecycle
 
-Plugins should be started before Docker, and stopped after Docker.  For
+Plugins should be started before Docker, and stopped after Docker. For
 example, when packaging a plugin for a platform which supports `systemd`, you
 might use [`systemd` dependencies](
 https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=) to
@@ -103,7 +93,7 @@ When a plugin is first referred to -- either by a user referring to it by name
 use a plugin being started -- Docker looks for the named plugin in the plugin
 directory and activates it with a handshake. See Handshake API below.
 
-Plugins are *not* activated automatically at Docker daemon startup. Rather,
+Plugins are not activated automatically at Docker daemon startup. Rather,
 they are activated only lazily, or on-demand, when they are needed.
 
 ## Systemd socket activation
@@ -149,8 +139,8 @@ or if one of the plugin goes down accidentally).
 
 The Plugin API is RPC-style JSON over HTTP, much like webhooks.
 
-Requests flow *from* the Docker daemon *to* the plugin.  So the plugin needs to
-implement an HTTP server and bind this to the UNIX socket mentioned in the
+Requests flow from the Docker daemon to the plugin. The plugin needs to
+implement an HTTP server and bind this to the Unix socket mentioned in the
 "plugin discovery" section.
 
 All requests are HTTP `POST` requests.