Merge pull request #31023 from mstanleyjones/fix_liquid_errors
Fix some Liquid errors
This commit is contained in:
commit
88de5c36c7
3 changed files with 23 additions and 13 deletions
|
@ -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`
|
||||
|
|
Loading…
Reference in a new issue