@@ -183,7 +183,11 @@ Log tags are now generated in a standard way across different logging drivers.

 Because of which, the driver specific log tag options `syslog-tag`, `gelf-tag` and

 `fluentd-tag` have been deprecated in favor of the generic `tag` option.

-    docker --log-driver=syslog --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"

+```bash

+{% raw %}

+docker --log-driver=syslog --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"

+{% endraw %}

+```

 ### LXC built-in exec driver

 **Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**

@@ -20,7 +20,7 @@ title: Managed plugin system

 * [Debugging plugins](index.md#debugging-plugins)

 Docker Engine's plugins system allows you to install, start, stop, and remove

-plugins using Docker Engine. 

+plugins using Docker Engine.

 For information about the legacy plugin system available in Docker Engine 1.12

 and earlier, see [Understand legacy Docker Engine plugins](legacy_plugins.md).

@@ -78,7 +78,7 @@ enabled, and use it to create a volume.

 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.

     ```bash

@@ -110,7 +110,7 @@ enabled, and use it to create a volume.

 6.  Remove the volume `sshvolume`

     ```bash

     docker volume rm sshvolume

-    

+

     sshvolume

     ```

 To disable a plugin, use the `docker plugin disable` command. To completely

@@ -122,10 +122,10 @@ commands and options, see the

 In swarm mode, it is possible to create a service that allows for attaching

 to networks or mounting volumes. Swarm schedules services based on plugin availability

-on a node. In this example, a volume plugin is installed on a swarm worker and a volume 

+on a node. In this example, a volume plugin is installed on a swarm worker and a volume

 is created using the plugin. In the manager, a service is created with the relevant

 mount options. It can be observed that the service is scheduled to run on the worker

-node with the said volume plugin and volume. 

+node with the said volume plugin and volume.

 In the following example, node1 is the manager and node2 is the worker.

@@ -152,7 +152,7 @@ In the following example, node1 is the manager and node2 is the worker.

     Status: Downloaded newer image for tiborvass/sample-volume-plugin:latest

     Installed plugin tiborvass/sample-volume-plugin

     ```

-	

+

     ```bash

     $ docker volume create -d tiborvass/sample-volume-plugin --name pluginVol

     ```

@@ -163,15 +163,17 @@ In the following example, node1 is the manager and node2 is the worker.

     $ docker service create --name my-service --mount type=volume,volume-driver=tiborvass/sample-volume-plugin,source=pluginVol,destination=/tmp busybox top

     $ docker service ls

-    z1sj8bb8jnfn  my-service   replicated  1/1       busybox:latest 

+    z1sj8bb8jnfn  my-service   replicated  1/1       busybox:latest

     ```

     docker service ls shows service 1 instance of service running.

 4. Observe the task getting scheduled in node 2:

     ```bash

-    $ docker ps --format '{{.ID}}\t {{.Status}} {{.Names}} {{.Command}}' 

+    {% raw %}

+    $ docker ps --format '{{.ID}}\t {{.Status}} {{.Names}} {{.Command}}'

     83fc1e842599     Up 2 days my-service.1.9jn59qzn7nbc3m0zt1hij12xs "top"

+    {% endraw %}

     ```

 ## Developing a plugin

@@ -228,7 +230,7 @@ with Docker Engine. This plugin has no runtime parameters.

 A new plugin can be created by running

 `docker plugin create <plugin-name> ./path/to/plugin/data` where the plugin

 data contains a plugin configuration file `config.json` and a root filesystem

-in subdirectory `rootfs`. 

+in subdirectory `rootfs`.

 After that the plugin `<plugin-name>` will show up in `docker plugin ls`.

 Plugins can be pushed to remote registries with

@@ -292,7 +294,7 @@ $ docker-runc exec -t f52a3df433b9aceee436eaada0752f5797aab1de47e5485f1690a073b8

 #### Using curl to debug plugin socket issues.

 To verify if the plugin API socket that the docker daemon communicates with

-is responsive, use curl. In this example, we will make API calls from the 

+is responsive, use curl. In this example, we will make API calls from the

 docker host to volume and network plugins using curl 7.47.0 to ensure that

 the plugin is listening on the said socket. For a well functioning plugin,

 these basic requests should work. Note that plugin sockets are available on the host under `/var/run/docker/plugins/<pluginID>`

@@ -309,8 +311,8 @@ curl -H "Content-Type: application/json" -XPOST -d '{}' --unix-socket /var/run/d

 {"Scope":"local"}

 ```

-When using curl 7.5 and above, the URL should be of the form 

-`http://hostname/APICall`, where `hostname` is the valid hostname where the 

+When using curl 7.5 and above, the URL should be of the form

+`http://hostname/APICall`, where `hostname` is the valid hostname where the

 plugin is installed and `APICall` is the call to the plugin API.

 For example, `http://localhost/VolumeDriver.List`

@@ -287,7 +287,9 @@ and `Parent`. `Parent` may be an empty string, in which case there is no parent.

 **Response**:

 ```

+{% raw %}

 {{ TAR STREAM }}

+{% endraw %}

 ```

 ### /GraphDriver.Changes

@@ -330,7 +332,9 @@ Respond with a non-empty string error if an error occurred.

 **Request**:

 ```

+{% raw %}

 {{ TAR STREAM }}

+{% endraw %}

 ```

 Extract the changeset from the given diff into the layer with the specified `ID`