diff --git a/docs/extend/index.md b/docs/extend/index.md index e8b964ba15..661bfc9f71 100644 --- a/docs/extend/index.md +++ b/docs/extend/index.md @@ -36,7 +36,7 @@ Hub or on a private registry. You install the plugin using a single command: `docker plugin install `. The `plugin install` command pulls the plugin from the Docker Hub or private -registry. If necessary the CLI prompts you to accept any privilige requriements. +registry. If necessary the CLI prompts you to accept any privilege requriements. For example the plugin may require access to a device on the host system. Finally it enables the plugin. @@ -63,7 +63,7 @@ to create a volume. The plugin requests 2 privileges, the `CAP_SYS_ADMIN` capability to be able to do mount inside the plugin and `host networking`. -2. Check for a value of `true` the `ENABLED` column to verify the plugin +2. Check for a value of `true` the `ENABLED` column to verify the plugin started without error. ```bash @@ -73,7 +73,7 @@ started without error. vieux/sshfs latest true ``` -3. Create a volume using the plugin. +3. Create a volume using the plugin. ```bash $ docker volume create \ @@ -92,7 +92,7 @@ started without error. ``` -5. Verify the plugin successfully created the volume. +5. Verify the plugin successfully created the volume. ```bash $ docker volume ls diff --git a/docs/extend/plugin_api.md b/docs/extend/plugin_api.md index edf05872cf..8e796e569b 100644 --- a/docs/extend/plugin_api.md +++ b/docs/extend/plugin_api.md @@ -121,6 +121,7 @@ ExecStart=/usr/lib/docker/your-plugin WantedBy=multi-user.target ``` The `socket` file (for example `/lib/systemd/system/your-plugin.socket`): + ``` [Unit] Description=Your plugin diff --git a/docs/reference/builder.md b/docs/reference/builder.md index 5b22fa1412..dab06da992 100644 --- a/docs/reference/builder.md +++ b/docs/reference/builder.md @@ -21,7 +21,7 @@ Practices](../userguide/eng-image/dockerfile_best-practices.md) for a tip-orient The [`docker build`](commandline/build.md) command builds an image from a `Dockerfile` and a *context*. The build's context is the files at a specified location `PATH` or `URL`. The `PATH` is a directory on your local filesystem. -The `URL` is a the location of a Git repository. +The `URL` is a Git repository location. A context is processed recursively. So, a `PATH` includes any subdirectories and the `URL` includes the repository and its submodules. A simple build command @@ -504,7 +504,7 @@ default is `/bin/sh -c` on Linux or `cmd /S /C` on Windows) - `RUN ["executable", "param1", "param2"]` (*exec* form) The `RUN` instruction will execute any commands in a new layer on top of the -current image and commit the results. The resulting comitted image will be +current image and commit the results. The resulting committed image will be used for the next step in the `Dockerfile`. Layering `RUN` instructions and generating commits conforms to the core @@ -519,13 +519,15 @@ command. In the *shell* form you can use a `\` (backslash) to continue a single RUN instruction onto the next line. For example, consider these two lines: + ``` -RUN /bin/bash -c 'source $HOME/.bashrc ;\ +RUN /bin/bash -c 'source $HOME/.bashrc; \ echo $HOME' ``` Together they are equivalent to this single line: + ``` -RUN /bin/bash -c 'source $HOME/.bashrc ; echo $HOME' +RUN /bin/bash -c 'source $HOME/.bashrc; echo $HOME' ``` > **Note**: @@ -641,7 +643,7 @@ If the user specifies arguments to `docker run` then they will override the default specified in `CMD`. > **Note**: -> don't confuse `RUN` with `CMD`. `RUN` actually runs a command and commits +> Don't confuse `RUN` with `CMD`. `RUN` actually runs a command and commits > the result; `CMD` does not execute anything at build time, but specifies > the intended command for the image. @@ -751,7 +753,7 @@ and ENV myDog Rex The Dog ENV myCat fluffy -will yield the same net results in the final container, but the first form +will yield the same net results in the final image, but the first form is preferred because it produces a single cache layer. The environment variables set using `ENV` will persist when a container is run @@ -773,7 +775,7 @@ ADD has two forms: whitespace) The `ADD` instruction copies new files, directories or remote file URLs from `` -and adds them to the filesystem of the container at the path ``. +and adds them to the filesystem of the image at the path ``. Multiple `` resource may be specified but if they are files or directories then they must be relative to the source directory that is @@ -806,7 +808,7 @@ of whether or not the file has changed and the cache should be updated. > can only contain a URL based `ADD` instruction. You can also pass a > compressed archive through STDIN: (`docker build - < archive.tar.gz`), > the `Dockerfile` at the root of the archive and the rest of the -> archive will get used at the context of the build. +> archive will be used as the context of the build. > **Note**: > If your URL files are protected using authentication, you @@ -848,7 +850,7 @@ guide](../userguide/eng-image/dockerfile_best-practices.md#build-cache) for more - If `` is a *local* tar archive in a recognized compression format (identity, gzip, bzip2 or xz) then it is unpacked as a directory. Resources from *remote* URLs are **not** decompressed. When a directory is copied or - unpacked, it has the same behavior as `tar -x`: the result is the union of: + unpacked, it has the same behavior as `tar -x`, the result is the union of: 1. Whatever existed at the destination path and 2. The contents of the source tree, with conflicts resolved in favor @@ -1677,7 +1679,7 @@ a shell operates. For example, using `SHELL cmd /S /C /V:ON|OFF` on Windows, del environment variable expansion semantics could be modified. The `SHELL` instruction can also be used on Linux should an alternate shell be -required such `zsh`, `csh`, `tcsh` and others. +required such as `zsh`, `csh`, `tcsh` and others. The `SHELL` feature was added in Docker 1.12.