mirrors/binctr
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

add better generate

Browse source 
Signed-off-by: Jess Frazelle <acidburn@microsoft.com>
This commit is contained in:
Jess Frazelle 2018-03-20 01:33:56 -04:00
parent 3fc6abf56b
commit cdd93563f5
5655 changed files with 1187011 additions and 392 deletions
Download patch file Download diff file Expand all files Collapse all files

474
vendor/github.com/docker/docker-ce/components/cli/man/Dockerfile.5.md generated vendored Normal file
View file

@ -0,0 +1,474 @@
% DOCKERFILE(5) Docker User Manuals
% Zac Dover
% May 2014
# NAME
Dockerfile - automate the steps of creating a Docker image
# INTRODUCTION
The **Dockerfile** is a configuration file that automates the steps of creating
a Docker image. It is similar to a Makefile. Docker reads instructions from the
**Dockerfile** to automate the steps otherwise performed manually to create an
image. To build an image, create a file called **Dockerfile**.
The **Dockerfile** describes the steps taken to assemble the image. When the
**Dockerfile** has been created, call the `docker build` command, using the
path of directory that contains **Dockerfile** as the argument.
# SYNOPSIS
INSTRUCTION arguments
For example:
FROM image
# DESCRIPTION
A Dockerfile is a file that automates the steps of creating a Docker image.
A Dockerfile is similar to a Makefile.
# USAGE
docker build .
-- Runs the steps and commits them, building a final image.
The path to the source repository defines where to find the context of the
build. The build is run by the Docker daemon, not the CLI. The whole
context must be transferred to the daemon. The Docker CLI reports
`"Sending build context to Docker daemon"` when the context is sent to the
daemon.
```
docker build -t repository/tag .
```
-- specifies a repository and tag at which to save the new image if the build
succeeds. The Docker daemon runs the steps one-by-one, committing the result
to a new image if necessary, before finally outputting the ID of the new
image. The Docker daemon automatically cleans up the context it is given.
Docker re-uses intermediate images whenever possible. This significantly
accelerates the *docker build* process.
# FORMAT
`FROM image`
`FROM image:tag`
`FROM image@digest`
-- The **FROM** instruction sets the base image for subsequent instructions. A
valid Dockerfile must have **FROM** as its first instruction. The image can be any
valid image. It is easy to start by pulling an image from the public
repositories.
-- **FROM** must be the first non-comment instruction in Dockerfile.
-- **FROM** may appear multiple times within a single Dockerfile in order to create
multiple images. Make a note of the last image ID output by the commit before
each new **FROM** command.
-- If no tag is given to the **FROM** instruction, Docker applies the
`latest` tag. If the used tag does not exist, an error is returned.
-- If no digest is given to the **FROM** instruction, Docker applies the
`latest` tag. If the used tag does not exist, an error is returned.
**MAINTAINER**
-- **MAINTAINER** sets the Author field for the generated images.
Useful for providing users with an email or url for support.
**RUN**
-- **RUN** has two forms:
```
# the command is run in a shell - /bin/sh -c
RUN <command>
# Executable form
RUN ["executable", "param1", "param2"]
```
-- The **RUN** instruction executes any commands in a new layer on top of the current
image and commits the results. The committed image is used for the next step in
Dockerfile.
-- Layering **RUN** instructions and generating commits conforms to the core
concepts of Docker where commits are cheap and containers can be created from
any point in the history of an image. This is similar to source control. The
exec form makes it possible to avoid shell string munging. The exec form makes
it possible to **RUN** commands using a base image that does not contain `/bin/sh`.
Note that the exec form is parsed as a JSON array, which means that you must
use double-quotes (") around words not single-quotes (').
**CMD**
-- **CMD** has three forms:
```
# Executable form
CMD ["executable", "param1", "param2"]`
# Provide default arguments to ENTRYPOINT
CMD ["param1", "param2"]`
# the command is run in a shell - /bin/sh -c
CMD command param1 param2
```
-- There should be only one **CMD** in a Dockerfile. If more than one **CMD** is listed, only
the last **CMD** takes effect.
The main purpose of a **CMD** is to provide defaults for an executing container.
These defaults may include an executable, or they can omit the executable. If
they omit the executable, an **ENTRYPOINT** must be specified.
When used in the shell or exec formats, the **CMD** instruction sets the command to
be executed when running the image.
If you use the shell form of the **CMD**, the `<command>` executes in `/bin/sh -c`:
Note that the exec form is parsed as a JSON array, which means that you must
use double-quotes (") around words not single-quotes (').
```
FROM ubuntu
CMD echo "This is a test." | wc -
```
-- If you run **command** without a shell, then you must express the command as a
JSON array and give the full path to the executable. This array form is the
preferred form of **CMD**. All additional parameters must be individually expressed
as strings in the array:
```
FROM ubuntu
CMD ["/usr/bin/wc","--help"]
```
-- To make the container run the same executable every time, use **ENTRYPOINT** in
combination with **CMD**.
If the user specifies arguments to `docker run`, the specified commands
override the default in **CMD**.
Do not confuse **RUN** with **CMD**. **RUN** runs a command and commits the result.
**CMD** executes nothing at build time, but specifies the intended command for
the image.
**LABEL**
-- `LABEL <key>=<value> [<key>=<value> ...]`or
```
LABEL <key>[ <value>]
LABEL <key>[ <value>]
...
```
The **LABEL** instruction adds metadata to an image. A **LABEL** is a
key-value pair. To specify a **LABEL** without a value, simply use an empty
string. To include spaces within a **LABEL** value, use quotes and
backslashes as you would in command-line parsing.
```
LABEL com.example.vendor="ACME Incorporated"
LABEL com.example.vendor "ACME Incorporated"
LABEL com.example.vendor.is-beta ""
LABEL com.example.vendor.is-beta=
LABEL com.example.vendor.is-beta=""
```
An image can have more than one label. To specify multiple labels, separate
each key-value pair by a space.
Labels are additive including `LABEL`s in `FROM` images. As the system
encounters and then applies a new label, new `key`s override any previous
labels with identical keys.
To display an image's labels, use the `docker inspect` command.
**EXPOSE**
-- `EXPOSE <port> [<port>...]`
The **EXPOSE** instruction informs Docker that the container listens on the
specified network ports at runtime. Docker uses this information to
interconnect containers using links and to set up port redirection on the host
system.
**ENV**
-- `ENV <key> <value>`
The **ENV** instruction sets the environment variable <key> to
the value `<value>`. This value is passed to all future
**RUN**, **ENTRYPOINT**, and **CMD** instructions. This is
functionally equivalent to prefixing the command with `<key>=<value>`. The
environment variables that are set with **ENV** persist when a container is run
from the resulting image. Use `docker inspect` to inspect these values, and
change them using `docker run --env <key>=<value>`.
Note that setting "`ENV DEBIAN_FRONTEND noninteractive`" may cause
unintended consequences, because it will persist when the container is run
interactively, as with the following command: `docker run -t -i image bash`
**ADD**
-- **ADD** has two forms:
```
ADD <src> <dest>
# Required for paths with whitespace
ADD ["<src>",... "<dest>"]
```
The **ADD** instruction copies new files, directories
or remote file URLs to the filesystem of the container at path `<dest>`.
Multiple `<src>` resources may be specified but if they are files or directories
then they must be relative to the source directory that is being built
(the context of the build). The `<dest>` is the absolute path, or path relative
to **WORKDIR**, into which the source is copied inside the target container.
If the `<src>` argument is a local file in a recognized compression format
(tar, gzip, bzip2, etc) then it is unpacked at the specified `<dest>` in the
container's filesystem. Note that only local compressed files will be unpacked,
i.e., the URL download and archive unpacking features cannot be used together.
All new directories are created with mode 0755 and with the uid and gid of **0**.
**COPY**
-- **COPY** has two forms:
```
COPY <src> <dest>
# Required for paths with whitespace
COPY ["<src>",... "<dest>"]
```
The **COPY** instruction copies new files from `<src>` and
adds them to the filesystem of the container at path <dest>. The `<src>` must be
the path to a file or directory relative to the source directory that is
being built (the context of the build) or a remote file URL. The `<dest>` is an
absolute path, or a path relative to **WORKDIR**, into which the source will
be copied inside the target container. If you **COPY** an archive file it will
land in the container exactly as it appears in the build context without any
attempt to unpack it. All new files and directories are created with mode **0755**
and with the uid and gid of **0**.
**ENTRYPOINT**
-- **ENTRYPOINT** has two forms:
```
# executable form
ENTRYPOINT ["executable", "param1", "param2"]`
# run command in a shell - /bin/sh -c
ENTRYPOINT command param1 param2
```
-- An **ENTRYPOINT** helps you configure a
container that can be run as an executable. When you specify an **ENTRYPOINT**,
the whole container runs as if it was only that executable. The **ENTRYPOINT**
instruction adds an entry command that is not overwritten when arguments are
passed to docker run. This is different from the behavior of **CMD**. This allows
arguments to be passed to the entrypoint, for instance `docker run <image> -d`
passes the -d argument to the **ENTRYPOINT**. Specify parameters either in the
**ENTRYPOINT** JSON array (as in the preferred exec form above), or by using a **CMD**
statement. Parameters in the **ENTRYPOINT** are not overwritten by the docker run
arguments. Parameters specified via **CMD** are overwritten by docker run
arguments. Specify a plain string for the **ENTRYPOINT**, and it will execute in
`/bin/sh -c`, like a **CMD** instruction:
```
FROM ubuntu
ENTRYPOINT wc -l -
```
This means that the Dockerfile's image always takes stdin as input (that's
what "-" means), and prints the number of lines (that's what "-l" means). To
make this optional but default, use a **CMD**:
```
FROM ubuntu
CMD ["-l", "-"]
ENTRYPOINT ["/usr/bin/wc"]
```
**VOLUME**
-- `VOLUME ["/data"]`
The **VOLUME** instruction creates a mount point with the specified name and marks
it as holding externally-mounted volumes from the native host or from other
containers.
**USER**
-- `USER daemon`
Sets the username or UID used for running subsequent commands.
The **USER** instruction can optionally be used to set the group or GID. The
followings examples are all valid:
USER [user | user:group | uid | uid:gid | user:gid | uid:group ]
Until the **USER** instruction is set, instructions will be run as root. The USER
instruction can be used any number of times in a Dockerfile, and will only affect
subsequent commands.
**WORKDIR**
-- `WORKDIR /path/to/workdir`
The **WORKDIR** instruction sets the working directory for the **RUN**, **CMD**,
**ENTRYPOINT**, **COPY** and **ADD** Dockerfile commands that follow it. It can
be used multiple times in a single Dockerfile. Relative paths are defined
relative to the path of the previous **WORKDIR** instruction. For example:
```
WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd
```
In the above example, the output of the **pwd** command is **a/b/c**.
**ARG**
-- ARG <name>[=<default value>]
The `ARG` instruction defines a variable that users can pass at build-time to
the builder with the `docker build` command using the `--build-arg
<varname>=<value>` flag. If a user specifies a build argument that was not
defined in the Dockerfile, the build outputs a warning.
```
[Warning] One or more build-args [foo] were not consumed
```
The Dockerfile author can define a single variable by specifying `ARG` once or many
variables by specifying `ARG` more than once. For example, a valid Dockerfile:
```
FROM busybox
ARG user1
ARG buildno
...
```
A Dockerfile author may optionally specify a default value for an `ARG` instruction:
```
FROM busybox
ARG user1=someuser
ARG buildno=1
...
```
If an `ARG` value has a default and if there is no value passed at build-time, the
builder uses the default.
An `ARG` variable definition comes into effect from the line on which it is
defined in the `Dockerfile` not from the argument's use on the command-line or
elsewhere. For example, consider this Dockerfile:
```
1 FROM busybox
2 USER ${user:-some_user}
3 ARG user
4 USER $user
...
```
A user builds this file by calling:
```
$ docker build --build-arg user=what_user Dockerfile
```
The `USER` at line 2 evaluates to `some_user` as the `user` variable is defined on the
subsequent line 3. The `USER` at line 4 evaluates to `what_user` as `user` is
defined and the `what_user` value was passed on the command line. Prior to its definition by an
`ARG` instruction, any use of a variable results in an empty string.
> **Warning:** It is not recommended to use build-time variables for
> passing secrets like github keys, user credentials etc. Build-time variable
> values are visible to any user of the image with the `docker history` command.
You can use an `ARG` or an `ENV` instruction to specify variables that are
available to the `RUN` instruction. Environment variables defined using the
`ENV` instruction always override an `ARG` instruction of the same name. Consider
this Dockerfile with an `ENV` and `ARG` instruction.
```
1 FROM ubuntu
2 ARG CONT_IMG_VER
3 ENV CONT_IMG_VER v1.0.0
4 RUN echo $CONT_IMG_VER
```
Then, assume this image is built with this command:
```
$ docker build --build-arg CONT_IMG_VER=v2.0.1 Dockerfile
```
In this case, the `RUN` instruction uses `v1.0.0` instead of the `ARG` setting
passed by the user:`v2.0.1` This behavior is similar to a shell
script where a locally scoped variable overrides the variables passed as
arguments or inherited from environment, from its point of definition.
Using the example above but a different `ENV` specification you can create more
useful interactions between `ARG` and `ENV` instructions:
```
1 FROM ubuntu
2 ARG CONT_IMG_VER
3 ENV CONT_IMG_VER ${CONT_IMG_VER:-v1.0.0}
4 RUN echo $CONT_IMG_VER
```
Unlike an `ARG` instruction, `ENV` values are always persisted in the built
image. Consider a docker build without the --build-arg flag:
```
$ docker build Dockerfile
```
Using this Dockerfile example, `CONT_IMG_VER` is still persisted in the image but
its value would be `v1.0.0` as it is the default set in line 3 by the `ENV` instruction.
The variable expansion technique in this example allows you to pass arguments
from the command line and persist them in the final image by leveraging the
`ENV` instruction. Variable expansion is only supported for [a limited set of
Dockerfile instructions.](#environment-replacement)
Docker has a set of predefined `ARG` variables that you can use without a
corresponding `ARG` instruction in the Dockerfile.
* `HTTP_PROXY`
* `http_proxy`
* `HTTPS_PROXY`
* `https_proxy`
* `FTP_PROXY`
* `ftp_proxy`
* `NO_PROXY`
* `no_proxy`
To use these, simply pass them on the command line using the `--build-arg
<varname>=<value>` flag.
**ONBUILD**
-- `ONBUILD [INSTRUCTION]`
The **ONBUILD** instruction adds a trigger instruction to an image. The
trigger is executed at a later time, when the image is used as the base for
another build. Docker executes the trigger in the context of the downstream
build, as if the trigger existed immediately after the **FROM** instruction in
the downstream Dockerfile.
You can register any build instruction as a trigger. A trigger is useful if
you are defining an image to use as a base for building other images. For
example, if you are defining an application build environment or a daemon that
is customized with a user-specific configuration.
Consider an image intended as a reusable python application builder. It must
add application source code to a particular directory, and might need a build
script called after that. You can't just call **ADD** and **RUN** now, because
you don't yet have access to the application source code, and it is different
for each application build.
-- Providing application developers with a boilerplate Dockerfile to copy-paste
into their application is inefficient, error-prone, and
difficult to update because it mixes with application-specific code.
The solution is to use **ONBUILD** to register instructions in advance, to
run later, during the next build stage.
# HISTORY
*May 2014, Compiled by Zac Dover (zdover at redhat dot com) based on docker.com Dockerfile documentation.
*Feb 2015, updated by Brian Goff (cpuguy83@gmail.com) for readability
*Sept 2015, updated by Sally O'Malley (somalley@redhat.com)
*Oct 2016, updated by Addam Hardy (addam.hardy@gmail.com)

15
vendor/github.com/docker/docker-ce/components/cli/man/README.md generated vendored Normal file
View file

@ -0,0 +1,15 @@
Docker Documentation
====================
This directory contains scripts for generating the man pages. Many of the man
pages are generated directly from the `spf13/cobra` `Command` definition. Some
legacy pages are still generated from the markdown files in this directory.
Do *not* edit the man pages in the man1 directory. Instead, update the
Cobra command or amend the Markdown files for legacy pages.
## Generate the man pages
From within the project root directory run:
make manpages

359
vendor/github.com/docker/docker-ce/components/cli/man/docker-build.1.md generated vendored Normal file
View file

@ -0,0 +1,359 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-build - Build an image from a Dockerfile
# SYNOPSIS
**docker build**
[**--add-host**[=*[]*]]
[**--build-arg**[=*[]*]]
[**--cache-from**[=*[]*]]
[**--cpu-shares**[=*0*]]
[**--cgroup-parent**[=*CGROUP-PARENT*]]
[**--help**]
[**--iidfile**[=*CIDFILE*]]
[**-f**|**--file**[=*PATH/Dockerfile*]]
[**-squash**] *Experimental*
[**--force-rm**]
[**--isolation**[=*default*]]
[**--label**[=*[]*]]
[**--no-cache**]
[**--pull**]
[**--compress**]
[**-q**|**--quiet**]
[**--rm**[=*true*]]
[**-t**|**--tag**[=*[]*]]
[**-m**|**--memory**[=*MEMORY*]]
[**--memory-swap**[=*LIMIT*]]
[**--network**[=*"default"*]]
[**--shm-size**[=*SHM-SIZE*]]
[**--cpu-period**[=*0*]]
[**--cpu-quota**[=*0*]]
[**--cpuset-cpus**[=*CPUSET-CPUS*]]
[**--cpuset-mems**[=*CPUSET-MEMS*]]
[**--target**[=*[]*]]
[**--ulimit**[=*[]*]]
PATH | URL | -
# DESCRIPTION
This will read the Dockerfile from the directory specified in **PATH**.
It also sends any other files and directories found in the current
directory to the Docker daemon. The contents of this directory would
be used by **ADD** commands found within the Dockerfile.
Warning, this will send a lot of data to the Docker daemon depending
on the contents of the current directory. The build is run by the Docker
daemon, not by the CLI, so the whole context must be transferred to the daemon.
The Docker CLI reports "Sending build context to Docker daemon" when the context is sent to
the daemon.
When the URL to a tarball archive or to a single Dockerfile is given, no context is sent from
the client to the Docker daemon. In this case, the Dockerfile at the root of the archive and
the rest of the archive will get used as the context of the build. When a Git repository is
set as the **URL**, the repository is cloned locally and then sent as the context.
# OPTIONS
**-f**, **--file**=*PATH/Dockerfile*
Path to the Dockerfile to use. If the path is a relative path and you are
building from a local directory, then the path must be relative to that
directory. If you are building from a remote URL pointing to either a
tarball or a Git repository, then the path must be relative to the root of
the remote context. In all cases, the file must be within the build context.
The default is *Dockerfile*.
**--squash**=*true*|*false*
**Experimental Only**
Once the image is built, squash the new layers into a new image with a single
new layer. Squashing does not destroy any existing image, rather it creates a new
image with the content of the squashed layers. This effectively makes it look
like all `Dockerfile` commands were created with a single layer. The build
cache is preserved with this method.
**Note**: using this option means the new image will not be able to take
advantage of layer sharing with other images and may use significantly more
space.
**Note**: using this option you may see significantly more space used due to
storing two copies of the image, one for the build cache with all the cache
layers in tact, and one for the squashed version.
**--add-host**=[]
Add a custom host-to-IP mapping (host:ip)
Add a line to /etc/hosts. The format is hostname:ip. The **--add-host**
option can be set multiple times.
**--build-arg**=*variable*
name and value of a **buildarg**.
For example, if you want to pass a value for `http_proxy`, use
`--build-arg=http_proxy="http://some.proxy.url"`
Users pass these values at build-time. Docker uses the `buildargs` as the
environment context for command(s) run via the Dockerfile's `RUN` instruction
or for variable expansion in other Dockerfile instructions. This is not meant
for passing secret values. [Read more about the buildargs instruction](https://docs.docker.com/engine/reference/builder/#arg)
**--cache-from**=""
Set image that will be used as a build cache source.
**--force-rm**=*true*|*false*
Always remove intermediate containers, even after unsuccessful builds. The default is *false*.
**--isolation**="*default*"
Isolation specifies the type of isolation technology used by containers.
**--label**=*label*
Set metadata for an image
**--no-cache**=*true*|*false*
Do not use cache when building the image. The default is *false*.
**--iidfile**=""
Write the image ID to the file
**--help**
Print usage statement
**--pull**=*true*|*false*
Always attempt to pull a newer version of the image. The default is *false*.
**--compress**=*true*|*false*
Compress the build context using gzip. The default is *false*.
**-q**, **--quiet**=*true*|*false*
Suppress the build output and print image ID on success. The default is *false*.
**--rm**=*true*|*false*
Remove intermediate containers after a successful build. The default is *true*.
**-t**, **--tag**=""
Repository names (and optionally with tags) to be applied to the resulting
image in case of success. Refer to **docker-tag(1)** for more information
about valid tag names.
**-m**, **--memory**=*MEMORY*
Memory limit
**--memory-swap**=*LIMIT*
A limit value equal to memory plus swap. Must be used with the **-m**
(**--memory**) flag. The swap `LIMIT` should always be larger than **-m**
(**--memory**) value.
The format of `LIMIT` is `<number>[<unit>]`. Unit can be `b` (bytes),
`k` (kilobytes), `m` (megabytes), or `g` (gigabytes). If you don't specify a
unit, `b` is used. Set LIMIT to `-1` to enable unlimited swap.
**--network**=*bridge*
Set the networking mode for the RUN instructions during build. Supported standard
values are: `bridge`, `host`, `none` and `container:<name|id>`. Any other value
is taken as a custom network's name or ID which this container should connect to.
**--shm-size**=*SHM-SIZE*
Size of `/dev/shm`. The format is `<number><unit>`. `number` must be greater than `0`.
Unit is optional and can be `b` (bytes), `k` (kilobytes), `m` (megabytes), or `g` (gigabytes). If you omit the unit, the system uses bytes.
If you omit the size entirely, the system uses `64m`.
**--cpu-shares**=*0*
CPU shares (relative weight).
By default, all containers get the same proportion of CPU cycles.
CPU shares is a 'relative weight', relative to the default setting of 1024.
This default value is defined here:
```
cat /sys/fs/cgroup/cpu/cpu.shares
1024
```
You can change this proportion by adjusting the container's CPU share
weighting relative to the weighting of all other running containers.
To modify the proportion from the default of 1024, use the **--cpu-shares**
flag to set the weighting to 2 or higher.
Container CPU share Flag
{C0} 60% of CPU --cpu-shares=614 (614 is 60% of 1024)
{C1} 40% of CPU --cpu-shares=410 (410 is 40% of 1024)
The proportion is only applied when CPU-intensive processes are running.
When tasks in one container are idle, the other containers can use the
left-over CPU time. The actual amount of CPU time used varies depending on
the number of containers running on the system.
For example, consider three containers, where one has **--cpu-shares=1024** and
two others have **--cpu-shares=512**. When processes in all three
containers attempt to use 100% of CPU, the first container would receive
50% of the total CPU time. If you add a fourth container with **--cpu-shares=1024**,
the first container only gets 33% of the CPU. The remaining containers
receive 16.5%, 16.5% and 33% of the CPU.
Container CPU share Flag CPU time
{C0} 100% --cpu-shares=1024 33%
{C1} 50% --cpu-shares=512 16.5%
{C2} 50% --cpu-shares=512 16.5%
{C4} 100% --cpu-shares=1024 33%
On a multi-core system, the shares of CPU time are distributed across the CPU
cores. Even if a container is limited to less than 100% of CPU time, it can
use 100% of each individual CPU core.
For example, consider a system with more than three cores. If you start one
container **{C0}** with **--cpu-shares=512** running one process, and another container
**{C1}** with **--cpu-shares=1024** running two processes, this can result in the following
division of CPU shares:
PID container CPU CPU share
100 {C0} 0 100% of CPU0
101 {C1} 1 100% of CPU1
102 {C1} 2 100% of CPU2
**--cpu-period**=*0*
Limit the CPU CFS (Completely Fair Scheduler) period.
Limit the container's CPU usage. This flag causes the kernel to restrict the
container's CPU usage to the period you specify.
**--cpu-quota**=*0*
Limit the CPU CFS (Completely Fair Scheduler) quota.
By default, containers run with the full CPU resource. This flag causes the
kernel to restrict the container's CPU usage to the quota you specify.
**--cpuset-cpus**=*CPUSET-CPUS*
CPUs in which to allow execution (0-3, 0,1).
**--cpuset-mems**=*CPUSET-MEMS*
Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on
NUMA systems.
For example, if you have four memory nodes on your system (0-3), use `--cpuset-mems=0,1`
to ensure the processes in your Docker container only use memory from the first
two memory nodes.
**--cgroup-parent**=*CGROUP-PARENT*
Path to `cgroups` under which the container's `cgroup` are created.
If the path is not absolute, the path is considered relative to the `cgroups` path of the init process.
Cgroups are created if they do not already exist.
**--target**=""
Set the target build stage name.
**--ulimit**=[]
Ulimit options
For more information about `ulimit` see [Setting ulimits in a
container](https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit)
# EXAMPLES
## Building an image using a Dockerfile located inside the current directory
Docker images can be built using the build command and a Dockerfile:
docker build .
During the build process Docker creates intermediate images. In order to
keep them, you must explicitly set `--rm=false`.
docker build --rm=false .
A good practice is to make a sub-directory with a related name and create
the Dockerfile in that directory. For example, a directory called mongo may
contain a Dockerfile to create a Docker MongoDB image. Likewise, another
directory called httpd may be used to store Dockerfiles for Apache web
server images.
It is also a good practice to add the files required for the image to the
sub-directory. These files will then be specified with the `COPY` or `ADD`
instructions in the `Dockerfile`.
Note: If you include a tar file (a good practice), then Docker will
automatically extract the contents of the tar file specified within the `ADD`
instruction into the specified target.
## Building an image and naming that image
A good practice is to give a name to the image you are building. Note that
only a-z0-9-_. should be used for consistency. There are no hard rules here but it is best to give the names consideration.
The **-t**/**--tag** flag is used to rename an image. Here are some examples:
Though it is not a good practice, image names can be arbitrary:
docker build -t myimage .
A better approach is to provide a fully qualified and meaningful repository,
name, and tag (where the tag in this context means the qualifier after
the ":"). In this example we build a JBoss image for the Fedora repository
and give it the version 1.0:
docker build -t fedora/jboss:1.0 .
The next example is for the "whenry" user repository and uses Fedora and
JBoss and gives it the version 2.1 :
docker build -t whenry/fedora-jboss:v2.1 .
If you do not provide a version tag then Docker will assign `latest`:
docker build -t whenry/fedora-jboss .
When you list the images, the image above will have the tag `latest`.
You can apply multiple tags to an image. For example, you can apply the `latest`
tag to a newly built image and add another tag that references a specific
version.
For example, to tag an image both as `whenry/fedora-jboss:latest` and
`whenry/fedora-jboss:v2.1`, use the following:
docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 .
So renaming an image is arbitrary but consideration should be given to
a useful convention that makes sense for consumers and should also take
into account Docker community conventions.
## Building an image using a URL
This will clone the specified GitHub repository from the URL and use it
as context. The Dockerfile at the root of the repository is used as
Dockerfile. This only works if the GitHub repository is a dedicated
repository.
docker build github.com/scollier/purpletest
Note: You can set an arbitrary Git repository via the `git://` scheme.
## Building an image using a URL to a tarball'ed context
This will send the URL itself to the Docker daemon. The daemon will fetch the
tarball archive, decompress it and use its contents as the build context. The
Dockerfile at the root of the archive and the rest of the archive will get used
as the context of the build. If you pass an **-f PATH/Dockerfile** option as well,
the system will look for that file inside the contents of the tarball.
docker build -f dev/Dockerfile https://10.10.10.1/docker/context.tar.gz
Note: supported compression formats are 'xz', 'bzip2', 'gzip' and 'identity' (no compression).
## Specify isolation technology for container (--isolation)
This option is useful in situations where you are running Docker containers on
Windows. The `--isolation=<value>` option sets a container's isolation
technology. On Linux, the only supported is the `default` option which uses
Linux namespaces. On Microsoft Windows, you can specify these values:
* `default`: Use the value specified by the Docker daemon's `--exec-opt` . If the `daemon` does not specify an isolation technology, Microsoft Windows uses `process` as its default value.
* `process`: Namespace isolation only.
* `hyperv`: Hyper-V hypervisor partition-based isolation.
Specifying the `--isolation` flag without a value is the same as setting `--isolation="default"`.
# HISTORY
March 2014, Originally compiled by William Henry (whenry at redhat dot com)
based on docker.com source material and internal work.
June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
June 2015, updated by Sally O'Malley <somalley@redhat.com>

72
vendor/github.com/docker/docker-ce/components/cli/man/docker-config-json.5.md generated vendored Normal file
View file

@ -0,0 +1,72 @@
% CONFIG.JSON(5) Docker User Manuals
% Docker Community
% JANUARY 2016
# NAME
HOME/.docker/config.json - Default Docker configuration file
# INTRODUCTION
By default, the Docker command line stores its configuration files in a
directory called `.docker` within your `$HOME` directory. Docker manages most of
the files in the configuration directory and you should not modify them.
However, you *can modify* the `config.json` file to control certain aspects of
how the `docker` command behaves.
Currently, you can modify the `docker` command behavior using environment
variables or command-line options. You can also use options within
`config.json` to modify some of the same behavior. When using these
mechanisms, you must keep in mind the order of precedence among them. Command
line options override environment variables and environment variables override
properties you specify in a `config.json` file.
The `config.json` file stores a JSON encoding of several properties:
* The `HttpHeaders` property specifies a set of headers to include in all messages
sent from the Docker client to the daemon. Docker does not try to interpret or
understand these header; it simply puts them into the messages. Docker does not
allow these headers to change any headers it sets for itself.
* The `psFormat` property specifies the default format for `docker ps` output.
When the `--format` flag is not provided with the `docker ps` command,
Docker's client uses this property. If this property is not set, the client
falls back to the default table format. For a list of supported formatting
directives, see **docker-ps(1)**.
* The `detachKeys` property specifies the default key sequence which
detaches the container. When the `--detach-keys` flag is not provide
with the `docker attach`, `docker exec`, `docker run` or `docker
start`, Docker's client uses this property. If this property is not
set, the client falls back to the default sequence `ctrl-p,ctrl-q`.
* The `imagesFormat` property specifies the default format for `docker images`
output. When the `--format` flag is not provided with the `docker images`
command, Docker's client uses this property. If this property is not set, the
client falls back to the default table format. For a list of supported
formatting directives, see **docker-images(1)**.
You can specify a different location for the configuration files via the
`DOCKER_CONFIG` environment variable or the `--config` command line option. If
both are specified, then the `--config` option overrides the `DOCKER_CONFIG`
environment variable:
docker --config ~/testconfigs/ ps
This command instructs Docker to use the configuration files in the
`~/testconfigs/` directory when running the `ps` command.
## Examples
Following is a sample `config.json` file:
{
"HttpHeaders": {
"MyHeader": "MyValue"
},
"psFormat": "table {{.ID}}\\t{{.Image}}\\t{{.Command}}\\t{{.Labels}}",
"imagesFormat": "table {{.ID}}\\t{{.Repository}}\\t{{.Tag}}\\t{{.CreatedAt}}",
"detachKeys": "ctrl-e,e"
}
# HISTORY
January 2016, created by Moxiegirl <mary@docker.com>

1135
vendor/github.com/docker/docker-ce/components/cli/man/docker-run.1.md generated vendored Normal file
View file

File diff suppressed because it is too large Load diff

70
vendor/github.com/docker/docker-ce/components/cli/man/docker.1.md generated vendored Normal file
View file

@ -0,0 +1,70 @@
% DOCKER(1) Docker User Manuals
% William Henry
% APRIL 2014
# NAME
docker \- Docker image and container command line interface
# SYNOPSIS
**docker** [OPTIONS] COMMAND [ARG...]
**docker** [--help|-v|--version]
# DESCRIPTION
**docker** is a client for interacting with the daemon (see **dockerd(8)**) through the CLI.
The Docker CLI has over 30 commands. The commands are listed below and each has
its own man page which explain usage and arguments.
To see the man page for a command run **man docker <command>**.
# OPTIONS
**--help**
Print usage statement
**--config**=""
Specifies the location of the Docker client configuration files. The default is '~/.docker'.
**-D**, **--debug**=*true*|*false*
Enable debug mode. Default is false.
**-H**, **--host**=[*unix:///var/run/docker.sock*]: tcp://[host]:[port][path] to bind or
unix://[/path/to/socket] to use.
The socket(s) to bind to in daemon mode specified using one or more
tcp://host:port/path, unix:///path/to/socket, fd://* or fd://socketfd.
If the tcp port is not specified, then it will default to either `2375` when
`--tls` is off, or `2376` when `--tls` is on, or `--tlsverify` is specified.
**-l**, **--log-level**="*debug*|*info*|*warn*|*error*|*fatal*"
Set the logging level. Default is `info`.
**--tls**=*true*|*false*
Use TLS; implied by --tlsverify. Default is false.
**--tlscacert**=*~/.docker/ca.pem*
Trust certs signed only by this CA.
**--tlscert**=*~/.docker/cert.pem*
Path to TLS certificate file.
**--tlskey**=*~/.docker/key.pem*
Path to TLS key file.
**--tlsverify**=*true*|*false*
Use TLS and verify the remote (daemon: verify client, client: verify daemon).
Default is false.
**-v**, **--version**=*true*|*false*
Print version information and quit. Default is false.
# COMMANDS
Use "docker help" or "docker --help" to get an overview of available commands.
# EXAMPLES
For specific client examples please see the man page for the specific Docker
command. For example:
man docker-run
# HISTORY
April 2014, Originally compiled by William Henry (whenry at redhat dot com) based on docker.com source material and internal work.

833
vendor/github.com/docker/docker-ce/components/cli/man/dockerd.8.md generated vendored Normal file
View file

@ -0,0 +1,833 @@
% DOCKER(8) Docker User Manuals
% Shishir Mahajan
% SEPTEMBER 2015
# NAME
dockerd - Enable daemon mode
# SYNOPSIS
**dockerd**
[**--add-runtime**[=*[]*]]
[**--allow-nondistributable-artifacts**[=*[]*]]
[**--api-cors-header**=[=*API-CORS-HEADER*]]
[**--authorization-plugin**[=*[]*]]
[**-b**|**--bridge**[=*BRIDGE*]]
[**--bip**[=*BIP*]]
[**--cgroup-parent**[=*[]*]]
[**--cluster-store**[=*[]*]]
[**--cluster-advertise**[=*[]*]]
[**--cluster-store-opt**[=*map[]*]]
[**--config-file**[=*/etc/docker/daemon.json*]]
[**--containerd**[=*SOCKET-PATH*]]
[**--data-root**[=*/var/lib/docker*]]
[**-D**|**--debug**]
[**--default-gateway**[=*DEFAULT-GATEWAY*]]
[**--default-gateway-v6**[=*DEFAULT-GATEWAY-V6*]]
[**--default-runtime**[=*runc*]]
[**--default-ipc-mode**=*MODE*]
[**--default-shm-size**[=*64MiB*]]
[**--default-ulimit**[=*[]*]]
[**--dns**[=*[]*]]
[**--dns-opt**[=*[]*]]
[**--dns-search**[=*[]*]]
[**--exec-opt**[=*[]*]]
[**--exec-root**[=*/var/run/docker*]]
[**--experimental**[=*false*]]
[**--fixed-cidr**[=*FIXED-CIDR*]]
[**--fixed-cidr-v6**[=*FIXED-CIDR-V6*]]
[**-G**|**--group**[=*docker*]]
[**-H**|**--host**[=*[]*]]
[**--help**]
[**--icc**[=*true*]]
[**--init**[=*false*]]
[**--init-path**[=*""*]]
[**--insecure-registry**[=*[]*]]
[**--ip**[=*0.0.0.0*]]
[**--ip-forward**[=*true*]]
[**--ip-masq**[=*true*]]
[**--iptables**[=*true*]]
[**--ipv6**]
[**--isolation**[=*default*]]
[**-l**|**--log-level**[=*info*]]
[**--label**[=*[]*]]
[**--live-restore**[=*false*]]
[**--log-driver**[=*json-file*]]
[**--log-opt**[=*map[]*]]
[**--mtu**[=*0*]]
[**--max-concurrent-downloads**[=*3*]]
[**--max-concurrent-uploads**[=*5*]]
[**--node-generic-resources**[=*[]*]]
[**-p**|**--pidfile**[=*/var/run/docker.pid*]]
[**--raw-logs**]
[**--registry-mirror**[=*[]*]]
[**-s**|**--storage-driver**[=*STORAGE-DRIVER*]]
[**--seccomp-profile**[=*SECCOMP-PROFILE-PATH*]]
[**--selinux-enabled**]
[**--shutdown-timeout**[=*15*]]
[**--storage-opt**[=*[]*]]
[**--swarm-default-advertise-addr**[=*IP|INTERFACE*]]
[**--tls**]
[**--tlscacert**[=*~/.docker/ca.pem*]]
[**--tlscert**[=*~/.docker/cert.pem*]]
[**--tlskey**[=*~/.docker/key.pem*]]
[**--tlsverify**]
[**--userland-proxy**[=*true*]]
[**--userland-proxy-path**[=*""*]]
[**--userns-remap**[=*default*]]
# DESCRIPTION
**dockerd** is used for starting the Docker daemon (i.e., to command the daemon
to manage images, containers etc). So **dockerd** is a server, as a daemon.
To run the Docker daemon you can specify **dockerd**.
You can check the daemon options using **dockerd --help**.
Daemon options should be specified after the **dockerd** keyword in the
following format.
**dockerd [OPTIONS]**
# OPTIONS
**--add-runtime**=[]
Runtimes can be registered with the daemon either via the
configuration file or using the `--add-runtime` command line argument.
The following is an example adding 2 runtimes via the configuration:
```json
{
"default-runtime": "runc",
"runtimes": {
"runc": {
"path": "runc"
},
"custom": {
"path": "/usr/local/bin/my-runc-replacement",
"runtimeArgs": [
"--debug"
]
}
}
}
```
This is the same example via the command line:
```bash
$ sudo dockerd --add-runtime runc=runc --add-runtime custom=/usr/local/bin/my-runc-replacement
```
**Note**: defining runtime arguments via the command line is not supported.
**--allow-nondistributable-artifacts**=[]
Push nondistributable artifacts to the specified registries.
List can contain elements with CIDR notation to specify a whole subnet.
This option is useful when pushing images containing nondistributable
artifacts to a registry on an air-gapped network so hosts on that network can
pull the images without connecting to another server.
**Warning**: Nondistributable artifacts typically have restrictions on how
and where they can be distributed and shared. Only use this feature to push
artifacts to private registries and ensure that you are in compliance with
any terms that cover redistributing nondistributable artifacts.
**--api-cors-header**=""
Set CORS headers in the Engine API. Default is cors disabled. Give urls like
"http://foo, http://bar, ...". Give "*" to allow all.
**--authorization-plugin**=""
Set authorization plugins to load
**-b**, **--bridge**=""
Attach containers to a pre\-existing network bridge; use 'none' to disable
container networking
**--bip**=""
Use the provided CIDR notation address for the dynamically created bridge
(docker0); Mutually exclusive of \-b
**--cgroup-parent**=""
Set parent cgroup for all containers. Default is "/docker" for fs cgroup
driver and "system.slice" for systemd cgroup driver.
**--cluster-store**=""
URL of the distributed storage backend
**--cluster-advertise**=""
Specifies the 'host:port' or `interface:port` combination that this
particular daemon instance should use when advertising itself to the cluster.
The daemon is reached through this value.
**--cluster-store-opt**=""
Specifies options for the Key/Value store.
**--config-file**="/etc/docker/daemon.json"
Specifies the JSON file path to load the configuration from.
**--containerd**=""
Path to containerd socket.
**--data-root**=""
Path to the directory used to store persisted Docker data such as
configuration for resources, swarm cluster state, and filesystem data for
images, containers, and local volumes. Default is `/var/lib/docker`.
**-D**, **--debug**=*true*|*false*
Enable debug mode. Default is false.
**--default-gateway**=""
IPv4 address of the container default gateway; this address must be part of
the bridge subnet (which is defined by \-b or \--bip)
**--default-gateway-v6**=""
IPv6 address of the container default gateway
**--default-runtime**="runc"
Set default runtime if there're more than one specified by `--add-runtime`.
**--default-ipc-mode**="**private**|**shareable**"
Set the default IPC mode for newly created containers. The argument
can either be **private** or **shareable**.
**--default-shm-size**=*64MiB*
Set the daemon-wide default shm size for containers. Default is `64MiB`.
**--default-ulimit**=[]
Default ulimits for containers.
**--dns**=""
Force Docker to use specific DNS servers
**--dns-opt**=""
DNS options to use.
**--dns-search**=[]
DNS search domains to use.
**--exec-opt**=[]
Set runtime execution options. See RUNTIME EXECUTION OPTIONS.
**--exec-root**=""
Path to use as the root of the Docker execution state files. Default is
`/var/run/docker`.
**--experimental**=""
Enable the daemon experimental features.
**--fixed-cidr**=""
IPv4 subnet for fixed IPs (e.g., 10.20.0.0/16); this subnet must be nested in
the bridge subnet (which is defined by \-b or \-\-bip).
**--fixed-cidr-v6**=""
IPv6 subnet for global IPv6 addresses (e.g., 2a00:1450::/64)
**-G**, **--group**=""
Group to assign the unix socket specified by -H when running in daemon mode.
use '' (the empty string) to disable setting of a group. Default is `docker`.
**-H**, **--host**=[*unix:///var/run/docker.sock*]: tcp://[host:port] to bind or
unix://[/path/to/socket] to use.
The socket(s) to bind to in daemon mode specified using one or more
tcp://host:port, unix:///path/to/socket, fd://* or fd://socketfd.
**--help**
Print usage statement
**--icc**=*true*|*false*
Allow unrestricted inter\-container and Docker daemon host communication. If
disabled, containers can still be linked together using the **--link** option
(see **docker-run(1)**). Default is true.
**--init**
Run an init process inside containers for signal forwarding and process
reaping.
**--init-path**
Path to the docker-init binary.
**--insecure-registry**=[]
Enable insecure registry communication, i.e., enable un-encrypted and/or
untrusted communication.
List of insecure registries can contain an element with CIDR notation to
specify a whole subnet. Insecure registries accept HTTP and/or accept HTTPS
with certificates from unknown CAs.
Enabling `--insecure-registry` is useful when running a local registry.
However, because its use creates security vulnerabilities it should ONLY be
enabled for testing purposes. For increased security, users should add their
CA to their system's list of trusted CAs instead of using
`--insecure-registry`.
**--ip**=""
Default IP address to use when binding container ports. Default is `0.0.0.0`.
**--ip-forward**=*true*|*false*
Enables IP forwarding on the Docker host. The default is `true`. This flag
interacts with the IP forwarding setting on your host system's kernel. If
your system has IP forwarding disabled, this setting enables it. If your
system has IP forwarding enabled, setting this flag to `--ip-forward=false`
has no effect.
This setting will also enable IPv6 forwarding if you have both
`--ip-forward=true` and `--fixed-cidr-v6` set. Note that this may reject
Router Advertisements and interfere with the host's existing IPv6
configuration. For more information, please consult the documentation about
"Advanced Networking - IPv6".
**--ip-masq**=*true*|*false*
Enable IP masquerading for bridge's IP range. Default is true.
**--iptables**=*true*|*false*
Enable Docker's addition of iptables rules. Default is true.
**--ipv6**=*true*|*false*
Enable IPv6 support. Default is false. Docker will create an IPv6-enabled
bridge with address fe80::1 which will allow you to create IPv6-enabled
containers. Use together with `--fixed-cidr-v6` to provide globally routable
IPv6 addresses. IPv6 forwarding will be enabled if not used with
`--ip-forward=false`. This may collide with your host's current IPv6
settings. For more information please consult the documentation about
"Advanced Networking - IPv6".
**--isolation**="*default*"
Isolation specifies the type of isolation technology used by containers.
Note that the default on Windows server is `process`, and the default on
Windows client is `hyperv`. Linux only supports `default`.
**-l**, **--log-level**="*debug*|*info*|*warn*|*error*|*fatal*"
Set the logging level. Default is `info`.
**--label**="[]"
Set key=value labels to the daemon (displayed in `docker info`)
**--live-restore**=*false*
Enable live restore of running containers when the daemon starts so that they
are not restarted. This option is applicable only for docker daemon running
on Linux host.
**--log-driver**="*json-file*|*syslog*|*journald*|*gelf*|*fluentd*|*awslogs*|*splunk*|*etwlogs*|*gcplogs*|*none*"
Default driver for container logs. Default is `json-file`.
**Warning**: `docker logs` command works only for `json-file` logging driver.
**--log-opt**=[]
Logging driver specific options.
**--mtu**=*0*
Set the containers network mtu. Default is `0`.
**--max-concurrent-downloads**=*3*
Set the max concurrent downloads for each pull. Default is `3`.
**--max-concurrent-uploads**=*5*
Set the max concurrent uploads for each push. Default is `5`.
**--node-generic-resources**=*[]*
Advertise user-defined resource. Default is `[]`.
Use this if your swarm cluster has some nodes with custom
resources (e.g: NVIDIA GPU, SSD, ...) and you need your services to land on
nodes advertising these resources.
Usage example: `--node-generic-resources "NVIDIA-GPU=UUID1"
--node-generic-resources "NVIDIA-GPU=UUID2"`
**-p**, **--pidfile**=""
Path to use for daemon PID file. Default is `/var/run/docker.pid`
**--raw-logs**
Output daemon logs in full timestamp format without ANSI coloring. If this
flag is not set, the daemon outputs condensed, colorized logs if a terminal
is detected, or full ("raw") output otherwise.
**--registry-mirror**=*<scheme>://<host>*
Prepend a registry mirror to be used for image pulls. May be specified
multiple times.
**-s**, **--storage-driver**=""
Force the Docker runtime to use a specific storage driver.
**--seccomp-profile**=""
Path to seccomp profile.
**--selinux-enabled**=*true*|*false*
Enable selinux support. Default is false.
**--shutdown-timeout**=*15*
Set the shutdown timeout value in seconds. Default is `15`.
**--storage-opt**=[]
Set storage driver options. See STORAGE DRIVER OPTIONS.
**--swarm-default-advertise-addr**=*IP|INTERFACE*
Set default address or interface for swarm to advertise as its
externally-reachable address to other cluster members. This can be a
hostname, an IP address, or an interface such as `eth0`. A port cannot be
specified with this option.
**--tls**=*true*|*false*
Use TLS; implied by --tlsverify. Default is false.
**--tlscacert**=*~/.docker/ca.pem*
Trust certs signed only by this CA.
**--tlscert**=*~/.docker/cert.pem*
Path to TLS certificate file.
**--tlskey**=*~/.docker/key.pem*
Path to TLS key file.
**--tlsverify**=*true*|*false*
Use TLS and verify the remote (daemon: verify client, client: verify daemon).
Default is false.
**--userland-proxy**=*true*|*false*
Rely on a userland proxy implementation for inter-container and
outside-to-container loopback communications. Default is true.
**--userland-proxy-path**=""
Path to the userland proxy binary.
**--userns-remap**=*default*|*uid:gid*|*user:group*|*user*|*uid*
Enable user namespaces for containers on the daemon. Specifying "default"
will cause a new user and group to be created to handle UID and GID range
remapping for the user namespace mappings used for contained processes.
Specifying a user (or uid) and optionally a group (or gid) will cause the
daemon to lookup the user and group's subordinate ID ranges for use as the
user namespace mappings for contained processes.
# STORAGE DRIVER OPTIONS
Docker uses storage backends (known as "graphdrivers" in the Docker
internals) to create writable containers from images. Many of these
backends use operating system level technologies and can be
configured.
Specify options to the storage backend with **--storage-opt** flags. The
backends that currently take options are *devicemapper*, *zfs* and *btrfs*.
Options for *devicemapper* are prefixed with *dm*, options for *zfs*
start with *zfs* and options for *btrfs* start with *btrfs*.
Specifically for devicemapper, the default is a "loopback" model which
requires no pre-configuration, but is extremely inefficient. Do not
use it in production.
To make the best use of Docker with the devicemapper backend, you must
have a recent version of LVM. Use `lvm` to create a thin pool; for
more information see `man lvmthin`. Then, use `--storage-opt
dm.thinpooldev` to tell the Docker engine to use that pool for
allocating images and container snapshots.
## Devicemapper options
#### dm.thinpooldev
Specifies a custom block storage device to use for the thin pool.
If using a block device for device mapper storage, it is best to use `lvm`
to create and manage the thin-pool volume. This volume is then handed to Docker
to exclusively create snapshot volumes needed for images and containers.
Managing the thin-pool outside of Engine makes for the most feature-rich
method of having Docker utilize device mapper thin provisioning as the
backing storage for Docker containers. The highlights of the lvm-based
thin-pool management feature include: automatic or interactive thin-pool
resize support, dynamically changing thin-pool features, automatic thinp
metadata checking when lvm activates the thin-pool, etc.
As a fallback if no thin pool is provided, loopback files are
created. Loopback is very slow, but can be used without any
pre-configuration of storage. It is strongly recommended that you do
not use loopback in production. Ensure your Engine daemon has a
`--storage-opt dm.thinpooldev` argument provided.
Example use:
$ dockerd \
--storage-opt dm.thinpooldev=/dev/mapper/thin-pool
#### dm.directlvm_device
As an alternative to manually creating a thin pool as above, Docker can
automatically configure a block device for you.
Example use:
$ dockerd \
--storage-opt dm.directlvm_device=/dev/xvdf
##### dm.thinp_percent
Sets the percentage of passed in block device to use for storage.
###### Example:
$ sudo dockerd \
--storage-opt dm.thinp_percent=95
##### `dm.thinp_metapercent`
Sets the percentage of the passed in block device to use for metadata storage.
###### Example:
$ sudo dockerd \
--storage-opt dm.thinp_metapercent=1
##### dm.thinp_autoextend_threshold
Sets the value of the percentage of space used before `lvm` attempts to
autoextend the available space [100 = disabled]
###### Example:
$ sudo dockerd \
--storage-opt dm.thinp_autoextend_threshold=80
##### dm.thinp_autoextend_percent
Sets the value percentage value to increase the thin pool by when `lvm`
attempts to autoextend the available space [100 = disabled]
###### Example:
$ sudo dockerd \
--storage-opt dm.thinp_autoextend_percent=20
#### dm.basesize
Specifies the size to use when creating the base device, which limits
the size of images and containers. The default value is 10G. Note,
thin devices are inherently "sparse", so a 10G device which is mostly
empty doesn't use 10 GB of space on the pool. However, the filesystem
will use more space for base images the larger the device
is.
The base device size can be increased at daemon restart which will allow
all future images and containers (based on those new images) to be of the
new base device size.
Example use: `dockerd --storage-opt dm.basesize=50G`
This will increase the base device size to 50G. The Docker daemon will throw an
error if existing base device size is larger than 50G. A user can use
this option to expand the base device size however shrinking is not permitted.
This value affects the system-wide "base" empty filesystem that may already
be initialized and inherited by pulled images. Typically, a change to this
value requires additional steps to take effect:
$ sudo service docker stop
$ sudo rm -rf /var/lib/docker
$ sudo service docker start
Example use: `dockerd --storage-opt dm.basesize=20G`
#### dm.fs
Specifies the filesystem type to use for the base device. The
supported options are `ext4` and `xfs`. The default is `ext4`.
Example use: `dockerd --storage-opt dm.fs=xfs`
#### dm.mkfsarg
Specifies extra mkfs arguments to be used when creating the base device.
Example use: `dockerd --storage-opt "dm.mkfsarg=-O ^has_journal"`
#### dm.mountopt
Specifies extra mount options used when mounting the thin devices.
Example use: `dockerd --storage-opt dm.mountopt=nodiscard`
#### dm.use_deferred_removal
Enables use of deferred device removal if `libdm` and the kernel driver
support the mechanism.
Deferred device removal means that if device is busy when devices are
being removed/deactivated, then a deferred removal is scheduled on
device. And devices automatically go away when last user of the device
exits.
For example, when a container exits, its associated thin device is removed. If
that device has leaked into some other mount namespace and can't be removed,
the container exit still succeeds and this option causes the system to schedule
the device for deferred removal. It does not wait in a loop trying to remove a
busy device.
Example use: `dockerd --storage-opt dm.use_deferred_removal=true`
#### dm.use_deferred_deletion
Enables use of deferred device deletion for thin pool devices. By default,
thin pool device deletion is synchronous. Before a container is deleted, the
Docker daemon removes any associated devices. If the storage driver can not
remove a device, the container deletion fails and daemon returns.
`Error deleting container: Error response from daemon: Cannot destroy container`
To avoid this failure, enable both deferred device deletion and deferred
device removal on the daemon.
`dockerd --storage-opt dm.use_deferred_deletion=true --storage-opt dm.use_deferred_removal=true`
With these two options enabled, if a device is busy when the driver is
deleting a container, the driver marks the device as deleted. Later, when the
device isn't in use, the driver deletes it.
In general it should be safe to enable this option by default. It will help
when unintentional leaking of mount point happens across multiple mount
namespaces.
#### dm.loopdatasize
**Note**: This option configures devicemapper loopback, which should not be
used in production.
Specifies the size to use when creating the loopback file for the "data" device
which is used for the thin pool. The default size is 100G. The file is sparse,
so it will not initially take up this much space.
Example use: `dockerd --storage-opt dm.loopdatasize=200G`
#### dm.loopmetadatasize
**Note**: This option configures devicemapper loopback, which should not be
used in production.
Specifies the size to use when creating the loopback file for the "metadata"
device which is used for the thin pool. The default size is 2G. The file is
sparse, so it will not initially take up this much space.
Example use: `dockerd --storage-opt dm.loopmetadatasize=4G`
#### dm.datadev
(Deprecated, use `dm.thinpooldev`)
Specifies a custom blockdevice to use for data for a Docker-managed thin pool.
It is better to use `dm.thinpooldev` - see the documentation for it above for
discussion of the advantages.
#### dm.metadatadev
(Deprecated, use `dm.thinpooldev`)
Specifies a custom blockdevice to use for metadata for a Docker-managed thin
pool. See `dm.datadev` for why this is deprecated.
#### dm.blocksize
Specifies a custom blocksize to use for the thin pool. The default
blocksize is 64K.
Example use: `dockerd --storage-opt dm.blocksize=512K`
#### dm.blkdiscard
Enables or disables the use of `blkdiscard` when removing devicemapper devices.
This is disabled by default due to the additional latency, but as a special
case with loopback devices it will be enabled, in order to re-sparsify the
loopback file on image/container removal.
Disabling this on loopback can lead to *much* faster container removal times,
but it also prevents the space used in `/var/lib/docker` directory from being
returned to the system for other use when containers are removed.
Example use: `dockerd --storage-opt dm.blkdiscard=false`
#### dm.override_udev_sync_check
By default, the devicemapper backend attempts to synchronize with the `udev`
device manager for the Linux kernel. This option allows disabling that
synchronization, to continue even though the configuration may be buggy.
To view the `udev` sync support of a Docker daemon that is using the
`devicemapper` driver, run:
$ docker info
[...]
Udev Sync Supported: true
[...]
When `udev` sync support is `true`, then `devicemapper` and `udev` can
coordinate the activation and deactivation of devices for containers.
When `udev` sync support is `false`, a race condition occurs between the
`devicemapper` and `udev` during create and cleanup. The race condition results
in errors and failures. (For information on these failures, see
[docker#4036](https://github.com/docker/docker/issues/4036))
To allow the `docker` daemon to start, regardless of whether `udev` sync is
`false`, set `dm.override_udev_sync_check` to true:
$ dockerd --storage-opt dm.override_udev_sync_check=true
When this value is `true`, the driver continues and simply warns you the errors
are happening.
**Note**: The ideal is to pursue a `docker` daemon and environment that does
support synchronizing with `udev`. For further discussion on this topic, see
[docker#4036](https://github.com/docker/docker/issues/4036).
Otherwise, set this flag for migrating existing Docker daemons to a daemon with
a supported environment.
#### dm.min_free_space
Specifies the min free space percent in a thin pool require for new device
creation to succeed. This check applies to both free data space as well
as free metadata space. Valid values are from 0% - 99%. Value 0% disables
free space checking logic. If user does not specify a value for this option,
the Engine uses a default value of 10%.
Whenever a new a thin pool device is created (during `docker pull` or during
container creation), the Engine checks if the minimum free space is available.
If the space is unavailable, then device creation fails and any relevant
`docker` operation fails.
To recover from this error, you must create more free space in the thin pool to
recover from the error. You can create free space by deleting some images and
containers from tge thin pool. You can also add more storage to the thin pool.
To add more space to an LVM (logical volume management) thin pool, just add
more storage to the group container thin pool; this should automatically
resolve any errors. If your configuration uses loop devices, then stop the
Engine daemon, grow the size of loop files and restart the daemon to resolve
the issue.
Example use:: `dockerd --storage-opt dm.min_free_space=10%`
#### dm.xfs_nospace_max_retries
Specifies the maximum number of retries XFS should attempt to complete IO when
ENOSPC (no space) error is returned by underlying storage device.
By default XFS retries infinitely for IO to finish and this can result in
unkillable process. To change this behavior one can set xfs_nospace_max_retries
to say 0 and XFS will not retry IO after getting ENOSPC and will shutdown
filesystem.
Example use:
$ sudo dockerd --storage-opt dm.xfs_nospace_max_retries=0
##### dm.libdm_log_level
Specifies the maxmimum libdm log level that will be forwarded to the dockerd
log (as specified by --log-level). This option is primarily intended for
debugging problems involving libdm. Using values other than the defaults may
cause false-positive warnings to be logged.
Values specified must fall within the range of valid libdm log levels. At the
time of writing, the following is the list of libdm log levels as well as their
corresponding levels when output by dockerd.
| libdm Level | Value | --log-level |
| ----------- | -----:| ----------- |
| _LOG_FATAL | 2 | error |
| _LOG_ERR | 3 | error |
| _LOG_WARN | 4 | warn |
| _LOG_NOTICE | 5 | info |
| _LOG_INFO | 6 | info |
| _LOG_DEBUG | 7 | debug |
Example use:
$ sudo dockerd \
--log-level debug \
--storage-opt dm.libdm_log_level=7
## ZFS options
#### zfs.fsname
Set zfs filesystem under which docker will create its own datasets. By default
docker will pick up the zfs filesystem where docker graph (`/var/lib/docker`)
is located.
Example use: `dockerd -s zfs --storage-opt zfs.fsname=zroot/docker`
## Btrfs options
#### btrfs.min_space
Specifies the minimum size to use when creating the subvolume which is used for
containers. If user uses disk quota for btrfs when creating or running a
container with **--storage-opt size** option, docker should ensure the **size**
cannot be smaller than **btrfs.min_space**.
Example use: `docker daemon -s btrfs --storage-opt btrfs.min_space=10G`
# CLUSTER STORE OPTIONS
The daemon uses libkv to advertise the node within the cluster. Some Key/Value
backends support mutual TLS, and the client TLS settings used by the daemon can
be configured using the **--cluster-store-opt** flag, specifying the paths to
PEM encoded files.
#### kv.cacertfile
Specifies the path to a local file with PEM encoded CA certificates to trust
#### kv.certfile
Specifies the path to a local file with a PEM encoded certificate. This
certificate is used as the client cert for communication with the Key/Value
store.
#### kv.keyfile
Specifies the path to a local file with a PEM encoded private key. This
private key is used as the client key for communication with the Key/Value
store.
# Access authorization
Docker's access authorization can be extended by authorization plugins that
your organization can purchase or build themselves. You can install one or more
authorization plugins when you start the Docker `daemon` using the
`--authorization-plugin=PLUGIN_ID` option.
```bash
dockerd --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
```
The `PLUGIN_ID` value is either the plugin's name or a path to its
specification file. The plugin's implementation determines whether you can
specify a name or path. Consult with your Docker administrator to get
information about the plugins available to you.
Once a plugin is installed, requests made to the `daemon` through the
command line or Docker's Engine API are allowed or denied by the plugin.
If you have multiple plugins installed, each plugin, in order, must
allow the request for it to complete.
For information about how to create an authorization plugin, see [authorization
plugin](https://docs.docker.com/engine/extend/authorization/) section in the
Docker extend section of this documentation.
# RUNTIME EXECUTION OPTIONS
You can configure the runtime using options specified with the `--exec-opt` flag.
All the flag's options have the `native` prefix. A single `native.cgroupdriver`
option is available.
The `native.cgroupdriver` option specifies the management of the container's
cgroups. You can only specify `cgroupfs` or `systemd`. If you specify
`systemd` and it is not available, the system errors out. If you omit the
`native.cgroupdriver` option,` cgroupfs` is used.
This example sets the `cgroupdriver` to `systemd`:
```bash
$ sudo dockerd --exec-opt native.cgroupdriver=systemd
```
Setting this option applies to all containers the daemon launches.
# HISTORY
Sept 2015, Originally compiled by Shishir Mahajan <shishir.mahajan@redhat.com>
based on docker.com source material and internal work.

108
vendor/github.com/docker/docker-ce/components/cli/man/generate.go generated vendored Normal file
View file

@ -0,0 +1,108 @@
package main
import (
"fmt"
"io/ioutil"
"log"
"os"
"path/filepath"
"github.com/docker/cli/cli/command"
"github.com/docker/cli/cli/command/commands"
"github.com/docker/docker/pkg/term"
"github.com/spf13/cobra"
"github.com/spf13/cobra/doc"
"github.com/spf13/pflag"
)
const descriptionSourcePath = "man/src/"
func generateManPages(opts *options) error {
header := &doc.GenManHeader{
Title: "DOCKER",
Section: "1",
Source: "Docker Community",
}
stdin, stdout, stderr := term.StdStreams()
dockerCli := command.NewDockerCli(stdin, stdout, stderr, false)
cmd := &cobra.Command{Use: "docker"}
commands.AddCommands(cmd, dockerCli)
source := filepath.Join(opts.source, descriptionSourcePath)
if err := loadLongDescription(cmd, source); err != nil {
return err
}
cmd.DisableAutoGenTag = true
cmd.DisableFlagsInUseLine = true
return doc.GenManTreeFromOpts(cmd, doc.GenManTreeOptions{
Header: header,
Path: opts.target,
CommandSeparator: "-",
})
}
func loadLongDescription(cmd *cobra.Command, path string) error {
for _, cmd := range cmd.Commands() {
cmd.DisableFlagsInUseLine = true
if cmd.Name() == "" {
continue
}
fullpath := filepath.Join(path, cmd.Name()+".md")
if cmd.HasSubCommands() {
loadLongDescription(cmd, filepath.Join(path, cmd.Name()))
}
if _, err := os.Stat(fullpath); err != nil {
log.Printf("WARN: %s does not exist, skipping\n", fullpath)
continue
}
content, err := ioutil.ReadFile(fullpath)
if err != nil {
return err
}
cmd.Long = string(content)
fullpath = filepath.Join(path, cmd.Name()+"-example.md")
if _, err := os.Stat(fullpath); err != nil {
continue
}
content, err = ioutil.ReadFile(fullpath)
if err != nil {
return err
}
cmd.Example = string(content)
}
return nil
}
type options struct {
source string
target string
}
func parseArgs() (*options, error) {
opts := &options{}
cwd, _ := os.Getwd()
flags := pflag.NewFlagSet(os.Args[0], pflag.ContinueOnError)
flags.StringVar(&opts.source, "root", cwd, "Path to project root")
flags.StringVar(&opts.target, "target", "/tmp", "Target path for generated man pages")
err := flags.Parse(os.Args[1:])
return opts, err
}
func main() {
opts, err := parseArgs()
if err != nil {
fmt.Fprintln(os.Stderr, err.Error())
}
fmt.Printf("Project root: %s\n", opts.source)
fmt.Printf("Generating man pages into %s\n", opts.target)
if err := generateManPages(opts); err != nil {
fmt.Fprintf(os.Stderr, "Failed to generate man pages: %s\n", err.Error())
}
}

7
vendor/github.com/docker/docker-ce/components/cli/man/import.go generated vendored Normal file
View file

@ -0,0 +1,7 @@
// +build never
package main
// Not used, but required for generating other man pages.
// Import it here so that the package is included by vndr.
import _ "github.com/cpuguy83/go-md2man"

22
vendor/github.com/docker/docker-ce/components/cli/man/md2man-all.sh generated vendored Executable file
View file

@ -0,0 +1,22 @@
#!/usr/bin/env bash
set -e
# get into this script's directory
cd "$(dirname "$(readlink -f "$BASH_SOURCE")")"
[ "$1" = '-q' ] || {
set -x
pwd
}
for FILE in *.md; do
base="$(basename "$FILE")"
name="${base%.md}"
num="${name##*.}"
if [ -z "$num" -o "$name" = "$num" ]; then
# skip files that aren't of the format xxxx.N.md (like README.md)
continue
fi
mkdir -p "./man${num}"
go-md2man -in "$FILE" -out "./man${num}/${name}"
done

2
vendor/github.com/docker/docker-ce/components/cli/man/src/attach.md generated vendored Normal file
View file

@ -0,0 +1,2 @@
Alias for `docker container attach`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/commit.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container commit`.

66
vendor/github.com/docker/docker-ce/components/cli/man/src/container/attach.md generated vendored Normal file
View file

@ -0,0 +1,66 @@
The **docker attach** command allows you to attach to a running container using
the container's ID or name, either to view its ongoing output or to control it
interactively. You can attach to the same contained process multiple times
simultaneously, screen sharing style, or quickly view the progress of your
detached process.
To stop a container, use `CTRL-c`. This key sequence sends `SIGKILL` to the
container. You can detach from the container (and leave it running) using a
configurable key sequence. The default sequence is `CTRL-p CTRL-q`. You
configure the key sequence using the **--detach-keys** option or a configuration
file. See **config-json(5)** for documentation on using a configuration file.
It is forbidden to redirect the standard input of a `docker attach` command while
attaching to a tty-enabled container (i.e.: launched with `-t`).
# Override the detach sequence
If you want, you can configure an override the Docker key sequence for detach.
This is useful if the Docker default sequence conflicts with key sequence you
use for other applications. There are two ways to define your own detach key
sequence, as a per-container override or as a configuration property on your
entire configuration.
To override the sequence for an individual container, use the
`--detach-keys="<sequence>"` flag with the `docker attach` command. The format of
the `<sequence>` is either a letter [a-Z], or the `ctrl-` combined with any of
the following:
* `a-z` (a single lowercase alpha character )
* `@` (at sign)
* `[` (left bracket)
* `\\` (two backward slashes)
* `_` (underscore)
* `^` (caret)
These `a`, `ctrl-a`, `X`, or `ctrl-\\` values are all examples of valid key
sequences. To configure a different configuration default key sequence for all
containers, see **docker(1)**.
# EXAMPLES
## Attaching to a container
In this example the top command is run inside a container, from an image called
fedora, in detached mode. The ID from the container is passed into the **docker
attach** command:
$ ID=$(sudo docker run -d fedora /usr/bin/top -b)
$ sudo docker attach $ID
top - 02:05:52 up 3:05, 0 users, load average: 0.01, 0.02, 0.05
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 373572k total, 355560k used, 18012k free, 27872k buffers
Swap: 786428k total, 0k used, 786428k free, 221740k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 17200 1116 912 R 0 0.3 0:00.03 top
top - 02:05:55 up 3:05, 0 users, load average: 0.01, 0.02, 0.05
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 373572k total, 355244k used, 18328k free, 27872k buffers
Swap: 786428k total, 0k used, 786428k free, 221776k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 17208 1144 932 R 0 0.3 0:00.03 top

30
vendor/github.com/docker/docker-ce/components/cli/man/src/container/commit.md generated vendored Normal file
View file

@ -0,0 +1,30 @@
Create a new image from an existing container specified by name or
container ID. The new image will contain the contents of the
container filesystem, *excluding* any data volumes. Refer to **docker-tag(1)**
for more information about valid image and tag names.
While the `docker commit` command is a convenient way of extending an
existing image, you should prefer the use of a Dockerfile and `docker
build` for generating images that you intend to share with other
people.
# EXAMPLES
## Creating a new image from an existing container
An existing Fedora based container has had Apache installed while running
in interactive mode with the bash shell. Apache is also running. To
create a new image run `docker ps` to find the container's ID and then run:
$ docker commit -m="Added Apache to Fedora base image" \
-a="A D Ministrator" 98bd7fc99854 fedora/fedora_httpd:20
Note that only a-z0-9-_. are allowed when naming images from an
existing container.
## Apply specified Dockerfile instructions while committing the image
If an existing container was created without the DEBUG environment
variable set to "true", you can create a new image based on that
container by first getting the container's ID with `docker ps` and
then running:
$ docker container commit -c="ENV DEBUG true" 98bd7fc99854 debug-image

145
vendor/github.com/docker/docker-ce/components/cli/man/src/container/cp.md generated vendored Normal file
View file

@ -0,0 +1,145 @@
The `docker container cp` utility copies the contents of `SRC_PATH` to the `DEST_PATH`.
You can copy from the container's file system to the local machine or the
reverse, from the local filesystem to the container. If `-` is specified for
either the `SRC_PATH` or `DEST_PATH`, you can also stream a tar archive from
`STDIN` or to `STDOUT`. The `CONTAINER` can be a running or stopped container.
The `SRC_PATH` or `DEST_PATH` can be a file or directory.
The `docker container cp` command assumes container paths are relative to the container's
`/` (root) directory. This means supplying the initial forward slash is optional;
The command sees `compassionate_darwin:/tmp/foo/myfile.txt` and
`compassionate_darwin:tmp/foo/myfile.txt` as identical. Local machine paths can
be an absolute or relative value. The command interprets a local machine's
relative paths as relative to the current working directory where `docker container cp` is
run.
The `cp` command behaves like the Unix `cp -a` command in that directories are
copied recursively with permissions preserved if possible. Ownership is set to
the user and primary group at the destination. For example, files copied to a
container are created with `UID:GID` of the root user. Files copied to the local
machine are created with the `UID:GID` of the user which invoked the `docker container cp`
command. If you specify the `-L` option, `docker container cp` follows any symbolic link
in the `SRC_PATH`. `docker container cp` does *not* create parent directories for
`DEST_PATH` if they do not exist.
Assuming a path separator of `/`, a first argument of `SRC_PATH` and second
argument of `DEST_PATH`, the behavior is as follows:
- `SRC_PATH` specifies a file
- `DEST_PATH` does not exist
- the file is saved to a file created at `DEST_PATH`
- `DEST_PATH` does not exist and ends with `/`
- Error condition: the destination directory must exist.
- `DEST_PATH` exists and is a file
- the destination is overwritten with the source file's contents
- `DEST_PATH` exists and is a directory
- the file is copied into this directory using the basename from
`SRC_PATH`
- `SRC_PATH` specifies a directory
- `DEST_PATH` does not exist
- `DEST_PATH` is created as a directory and the *contents* of the source
directory are copied into this directory
- `DEST_PATH` exists and is a file
- Error condition: cannot copy a directory to a file
- `DEST_PATH` exists and is a directory
- `SRC_PATH` does not end with `/.` (that is: _slash_ followed by _dot_)
- the source directory is copied into this directory
- `SRC_PATH` does end with `/.` (that is: _slash_ followed by _dot_)
- the *content* of the source directory is copied into this
directory
The command requires `SRC_PATH` and `DEST_PATH` to exist according to the above
rules. If `SRC_PATH` is local and is a symbolic link, the symbolic link, not
the target, is copied by default. To copy the link target and not the link,
specify the `-L` option.
A colon (`:`) is used as a delimiter between `CONTAINER` and its path. You can
also use `:` when specifying paths to a `SRC_PATH` or `DEST_PATH` on a local
machine, for example `file:name.txt`. If you use a `:` in a local machine path,
you must be explicit with a relative or absolute path, for example:
`/path/to/file:name.txt` or `./file:name.txt`
It is not possible to copy certain system files such as resources under
`/proc`, `/sys`, `/dev`, tmpfs, and mounts created by the user in the container.
However, you can still copy such files by manually running `tar` in `docker exec`.
For example (consider `SRC_PATH` and `DEST_PATH` are directories):
$ docker exec foo tar Ccf $(dirname SRC_PATH) - $(basename SRC_PATH) | tar Cxf DEST_PATH -
or
$ tar Ccf $(dirname SRC_PATH) - $(basename SRC_PATH) | docker exec -i foo tar Cxf DEST_PATH -
Using `-` as the `SRC_PATH` streams the contents of `STDIN` as a tar archive.
The command extracts the content of the tar to the `DEST_PATH` in container's
filesystem. In this case, `DEST_PATH` must specify a directory. Using `-` as
the `DEST_PATH` streams the contents of the resource as a tar archive to `STDOUT`.
# EXAMPLES
Suppose a container has finished producing some output as a file it saves
to somewhere in its filesystem. This could be the output of a build job or
some other computation. You can copy these outputs from the container to a
location on your local host.
If you want to copy the `/tmp/foo` directory from a container to the
existing `/tmp` directory on your host. If you run `docker container cp` in your `~`
(home) directory on the local host:
$ docker container cp compassionate_darwin:tmp/foo /tmp
Docker creates a `/tmp/foo` directory on your host. Alternatively, you can omit
the leading slash in the command. If you execute this command from your home
directory:
$ docker container cp compassionate_darwin:tmp/foo tmp
If `~/tmp` does not exist, Docker will create it and copy the contents of
`/tmp/foo` from the container into this new directory. If `~/tmp` already
exists as a directory, then Docker will copy the contents of `/tmp/foo` from
the container into a directory at `~/tmp/foo`.
When copying a single file to an existing `LOCALPATH`, the `docker container cp` command
will either overwrite the contents of `LOCALPATH` if it is a file or place it
into `LOCALPATH` if it is a directory, overwriting an existing file of the same
name if one exists. For example, this command:
$ docker container cp sharp_ptolemy:/tmp/foo/myfile.txt /test
If `/test` does not exist on the local machine, it will be created as a file
with the contents of `/tmp/foo/myfile.txt` from the container. If `/test`
exists as a file, it will be overwritten. Lastly, if `/test` exists as a
directory, the file will be copied to `/test/myfile.txt`.
Next, suppose you want to copy a file or folder into a container. For example,
this could be a configuration file or some other input to a long running
computation that you would like to place into a created container before it
starts. This is useful because it does not require the configuration file or
other input to exist in the container image.
If you have a file, `config.yml`, in the current directory on your local host
and wish to copy it to an existing directory at `/etc/my-app.d` in a container,
this command can be used:
$ docker container cp config.yml myappcontainer:/etc/my-app.d
If you have several files in a local directory `/config` which you need to copy
to a directory `/etc/my-app.d` in a container:
$ docker container cp /config/. myappcontainer:/etc/my-app.d
The above command will copy the contents of the local `/config` directory into
the directory `/etc/my-app.d` in the container.
Finally, if you want to copy a symbolic link into a container, you typically
want to copy the linked target and not the link itself. To copy the target, use
the `-L` option, for example:
$ ln -s /tmp/somefile /tmp/somefile.ln
$ docker container cp -L /tmp/somefile.ln myappcontainer:/tmp/
This command copies content of the local `/tmp/somefile` into the file
`/tmp/somefile.ln` in the container. Without `-L` option, the `/tmp/somefile.ln`
preserves its symbolic link but not its content.

35
vendor/github.com/docker/docker-ce/components/cli/man/src/container/create-example.md generated vendored Normal file
View file

@ -0,0 +1,35 @@
### Specify isolation technology for container (--isolation)
This option is useful in situations where you are running Docker containers on
Windows. The `--isolation=<value>` option sets a container's isolation
technology. On Linux, the only supported is the `default` option which uses
Linux namespaces. On Microsoft Windows, you can specify these values:
* `default`: Use the value specified by the Docker daemon's `--exec-opt` . If the `daemon` does not specify an isolation technology, Microsoft Windows uses `process` as its default value.
* `process`: Namespace isolation only.
* `hyperv`: Hyper-V hypervisor partition-based isolation.
Specifying the `--isolation` flag without a value is the same as setting `--isolation="default"`.
### Dealing with dynamically created devices (--device-cgroup-rule)
Devices available to a container are assigned at creation time. The
assigned devices will both be added to the cgroup.allow file and
created into the container once it is run. This poses a problem when
a new device needs to be added to running container.
One of the solution is to add a more permissive rule to a container
allowing it access to a wider range of devices. For example, supposing
our container needs access to a character device with major `42` and
any number of minor number (added as new devices appear), the
following rule would be added:
```
docker create --device-cgroup-rule='c 42:* rmw' -name my-container my-image
```
Then, a user could ask `udev` to execute a script that would `docker exec my-container mknod newDevX c 42 <minor>`
the required device when it is added.
NOTE: initially present devices still need to be explicitly added to
the create/run command

88
vendor/github.com/docker/docker-ce/components/cli/man/src/container/create.md generated vendored Normal file
View file

@ -0,0 +1,88 @@
Creates a writeable container layer over the specified image and prepares it for
running the specified command. The container ID is then printed to STDOUT. This
is similar to **docker run -d** except the container is never started. You can
then use the **docker start <container_id>** command to start the container at
any point.
The initial status of the container created with **docker create** is 'created'.
### OPTIONS
The `CONTAINER-DIR` must be an absolute path such as `/src/docs`. The `HOST-DIR`
can be an absolute path or a `name` value. A `name` value must start with an
alphanumeric character, followed by `a-z0-9`, `_` (underscore), `.` (period) or
`-` (hyphen). An absolute path starts with a `/` (forward slash).
If you supply a `HOST-DIR` that is an absolute path, Docker bind-mounts to the
path you specify. If you supply a `name`, Docker creates a named volume by that
`name`. For example, you can specify either `/foo` or `foo` for a `HOST-DIR`
value. If you supply the `/foo` value, Docker creates a bind mount. If you
supply the `foo` specification, Docker creates a named volume.
You can specify multiple **-v** options to mount one or more mounts to a
container. To use these same mounts in other containers, specify the
**--volumes-from** option also.
You can supply additional options for each bind mount following an additional
colon. A `:ro` or `:rw` suffix mounts a volume in read-only or read-write
mode, respectively. By default, volumes are mounted in read-write mode.
You can also specify the consistency requirement for the mount, either
`:consistent` (the default), `:cached`, or `:delegated`. Multiple options are
separated by commas, e.g. `:ro,cached`.
Labeling systems like SELinux require that proper labels are placed on volume
content mounted into a container. Without a label, the security system might
prevent the processes running inside the container from using the content. By
default, Docker does not change the labels set by the OS.
To change a label in the container context, you can add either of two suffixes
`:z` or `:Z` to the volume mount. These suffixes tell Docker to relabel file
objects on the shared volumes. The `z` option tells Docker that two containers
share the volume content. As a result, Docker labels the content with a shared
content label. Shared volume labels allow all containers to read/write content.
The `Z` option tells Docker to label the content with a private unshared label.
Only the current container can use a private volume.
By default bind mounted volumes are `private`. That means any mounts done
inside container will not be visible on host and vice-a-versa. One can change
this behavior by specifying a volume mount propagation property. Making a
volume `shared` mounts done under that volume inside container will be
visible on host and vice-a-versa. Making a volume `slave` enables only one
way mount propagation and that is mounts done on host under that volume
will be visible inside container but not the other way around.
To control mount propagation property of volume one can use `:[r]shared`,
`:[r]slave` or `:[r]private` propagation flag. Propagation property can
be specified only for bind mounted volumes and not for internal volumes or
named volumes. For mount propagation to work source mount point (mount point
where source dir is mounted on) has to have right propagation properties. For
shared volumes, source mount point has to be shared. And for slave volumes,
source mount has to be either shared or slave.
Use `df <source-dir>` to figure out the source mount and then use
`findmnt -o TARGET,PROPAGATION <source-mount-dir>` to figure out propagation
properties of source mount. If `findmnt` utility is not available, then one
can look at mount entry for source mount point in `/proc/self/mountinfo`. Look
at `optional fields` and see if any propagation properties are specified.
`shared:X` means mount is `shared`, `master:X` means mount is `slave` and if
nothing is there that means mount is `private`.
To change propagation properties of a mount point use `mount` command. For
example, if one wants to bind mount source directory `/foo` one can do
`mount --bind /foo /foo` and `mount --make-private --make-shared /foo`. This
will convert /foo into a `shared` mount point. Alternatively one can directly
change propagation properties of source mount. Say `/` is source mount for
`/foo`, then use `mount --make-shared /` to convert `/` into a `shared` mount.
> **Note**:
> When using systemd to manage the Docker daemon's start and stop, in the systemd
> unit file there is an option to control mount propagation for the Docker daemon
> itself, called `MountFlags`. The value of this setting may cause Docker to not
> see mount propagation changes made on the mount point. For example, if this value
> is `slave`, you may not be able to use the `shared` or `rshared` propagation on
> a volume.
To disable automatic copying of data from the container path to the volume, use
the `nocopy` flag. The `nocopy` flag can be set on named volumes, and does not
apply to bind mounts..

39
vendor/github.com/docker/docker-ce/components/cli/man/src/container/diff.md generated vendored Normal file
View file

@ -0,0 +1,39 @@
List the changed files and directories in a container᾿s filesystem since the
container was created. Three different types of change are tracked:
| Symbol | Description |
|--------|---------------------------------|
| `A` | A file or directory was added |
| `D` | A file or directory was deleted |
| `C` | A file or directory was changed |
You can use the full or shortened container ID or the container name set using
**docker run --name** option.
# EXAMPLES
Inspect the changes to an `nginx` container:
```bash
$ docker diff 1fdfd1f54c1b
C /dev
C /dev/console
C /dev/core
C /dev/stdout
C /dev/fd
C /dev/ptmx
C /dev/stderr
C /dev/stdin
C /run
A /run/nginx.pid
C /var/lib/nginx/tmp
A /var/lib/nginx/tmp/client_body
A /var/lib/nginx/tmp/fastcgi
A /var/lib/nginx/tmp/proxy
A /var/lib/nginx/tmp/scgi
A /var/lib/nginx/tmp/uwsgi
C /var/log/nginx
A /var/log/nginx/access.log
A /var/log/nginx/error.log
```

25
vendor/github.com/docker/docker-ce/components/cli/man/src/container/exec.md generated vendored Normal file
View file

@ -0,0 +1,25 @@
Run a process in a running container.
The command started using `docker exec` will only run while the container's primary
process (`PID 1`) is running, and will not be restarted if the container is restarted.
If the container is paused, then the `docker exec` command will wait until the
container is unpaused, and then run
# CAPABILITIES
`privileged` gives the process extended
[Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html)
when running in a container.
Without this flag, the process run by `docker exec` in a running container has
the same capabilities as the container, which may be limited. Set
`--privileged` to give all capabilities to the process.
# USER
`user` sets the username or UID used and optionally the groupname or GID for the specified command.
The followings examples are all valid:
--user [user | user:group | uid | uid:gid | user:gid | uid:group ]
Without this argument the command will be run as root in the container.

20
vendor/github.com/docker/docker-ce/components/cli/man/src/container/export.md generated vendored Normal file
View file

@ -0,0 +1,20 @@
Export the contents of a container's filesystem using the full or shortened
container ID or container name. The output is exported to STDOUT and can be
redirected to a tar file.
Stream to a file instead of STDOUT by using **-o**.
# EXAMPLES
Export the contents of the container called angry_bell to a tar file
called angry_bell.tar:
$ docker export angry_bell > angry_bell.tar
$ docker export --output=angry_bell-latest.tar angry_bell
$ ls -sh angry_bell.tar
321M angry_bell.tar
$ ls -sh angry_bell-latest.tar
321M angry_bell-latest.tar
# See also
**docker-import(1)** to create an empty filesystem image
and import the contents of the tarball into it, then optionally tag it.

2
vendor/github.com/docker/docker-ce/components/cli/man/src/container/kill.md generated vendored Normal file
View file

@ -0,0 +1,2 @@
The main process inside each container specified will be sent SIGKILL,
or any signal specified with option --signal.

40
vendor/github.com/docker/docker-ce/components/cli/man/src/container/logs.md generated vendored Normal file
View file

@ -0,0 +1,40 @@
The **docker container logs** command batch-retrieves whatever logs are present for
a container at the time of execution. This does not guarantee execution
order when combined with a docker run (i.e., your run may not have generated
any logs at the time you execute docker container logs).
The **docker container logs --follow** command combines commands **docker container logs** and
**docker attach**. It will first return all logs from the beginning and
then continue streaming new output from the container's stdout and stderr.
**Warning**: This command works only for the **json-file** or **journald**
logging drivers.
The `--since` and `--until` options can be Unix timestamps, date formatted timestamps,
or Go duration strings (e.g. `10m`, `1h30m`) computed relative to the client machine's
time. Supported formats for date formatted time stamps include RFC3339Nano,
RFC3339, `2006-01-02T15:04:05`, `2006-01-02T15:04:05.999999999`,
`2006-01-02Z07:00`, and `2006-01-02`. The local timezone on the client will be
used if you do not provide either a `Z` or a `+-00:00` timezone offset at the
end of the timestamp. When providing Unix timestamps enter
seconds[.nanoseconds], where seconds is the number of seconds that have elapsed
since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (aka Unix
epoch or Unix time), and the optional .nanoseconds field is a fraction of a
second no more than nine digits long. You can combine the `--since` or `--until`
options with either or both of the `--follow` or `--tail` options.
The `docker container logs --details` command will add on extra attributes, such as
environment variables and labels, provided to `--log-opt` when creating the
container.
In order to retrieve logs before a specific point in time, run:
```bash
$ docker run --name test -d busybox sh -c "while true; do $(echo date); sleep 1; done"
$ date
Tue 14 Nov 2017 16:40:00 CET
$ docker logs -f --until=2s
Tue 14 Nov 2017 16:40:00 CET
Tue 14 Nov 2017 16:40:01 CET
Tue 14 Nov 2017 16:40:02 CET
```

117
vendor/github.com/docker/docker-ce/components/cli/man/src/container/ls.md generated vendored Normal file
View file

@ -0,0 +1,117 @@
List the containers in the local repository. By default this shows only
the running containers.
## Filters
Filter output based on these conditions:
- ancestor=(<image-name>[:tag]|<image-id>|<image@digest>)
containers created from an image or a descendant.
- before=(<container-name>|<container-id>)
- expose=(<port>[/<proto>]|<startport-endport>/[<proto>])
- exited=<int> an exit code of <int>
- health=(starting|healthy|unhealthy|none)
- id=<ID> a container's ID
- isolation=(`default`|`process`|`hyperv`) (Windows daemon only)
- is-task=(true|false)
- label=<key> or label=<key>=<value>
- name=<string> a container's name
- network=(<network-id>|<network-name>)
- publish=(<port>[/<proto>]|<startport-endport>/[<proto>])
- since=(<container-name>|<container-id>)
- status=(created|restarting|removing|running|paused|exited)
- volume=(<volume name>|<mount point destination>)
## Format
The formatting option (**--format**) pretty-prints container output
using a Go template.
Valid placeholders for the Go template are listed below:
- .ID - Container ID.
- .Image - Image ID.
- .Command - Quoted command.
- .CreatedAt - Time when the container was created.
- .RunningFor - Elapsed time since the container was started.
- .Ports - Exposed ports.
- .Status - Container status.
- .Size - Container disk size.
- .Names - Container names.
- .Labels - All labels assigned to the container.
- .Label - Value of a specific label for this container.
For example **'{{.Label "com.docker.swarm.cpu"}}'**.
- .Mounts - Names of the volumes mounted in this container.
- .Networks - Names of the networks attached to this container.
# EXAMPLES
## Display all containers, including non-running
$ docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a87ecb4f327c fedora:20 /bin/sh -c #(nop) MA 20 minutes ago Exit 0 desperate_brattain
01946d9d34d8 vpavlin/rhel7:latest /bin/sh -c #(nop) MA 33 minutes ago Exit 0 thirsty_bell
c1d3b0166030 acffc0358b9e /bin/sh -c yum -y up 2 weeks ago Exit 1 determined_torvalds
41d50ecd2f57 fedora:20 /bin/sh -c #(nop) MA 2 weeks ago Exit 0 drunk_pike
## Display only IDs of all containers, including non-running
$ docker container ls -a -q
a87ecb4f327c
01946d9d34d8
c1d3b0166030
41d50ecd2f57
## Display only IDs of all containers that have the name `determined_torvalds`
$ docker container ls -a -q --filter=name=determined_torvalds
c1d3b0166030
## Display containers with their commands
$ docker container ls --format "{{.ID}}: {{.Command}}"
a87ecb4f327c: /bin/sh -c #(nop) MA
01946d9d34d8: /bin/sh -c #(nop) MA
c1d3b0166030: /bin/sh -c yum -y up
41d50ecd2f57: /bin/sh -c #(nop) MA
## Display containers with their labels in a table
$ docker container ls --format "table {{.ID}}\t{{.Labels}}"
CONTAINER ID LABELS
a87ecb4f327c com.docker.swarm.node=ubuntu,com.docker.swarm.storage=ssd
01946d9d34d8
c1d3b0166030 com.docker.swarm.node=debian,com.docker.swarm.cpu=6
41d50ecd2f57 com.docker.swarm.node=fedora,com.docker.swarm.cpu=3,com.docker.swarm.storage=ssd
## Display containers with their node label in a table
$ docker container ls --format 'table {{.ID}}\t{{(.Label "com.docker.swarm.node")}}'
CONTAINER ID NODE
a87ecb4f327c ubuntu
01946d9d34d8
c1d3b0166030 debian
41d50ecd2f57 fedora
## Display containers with `remote-volume` mounted
$ docker container ls --filter volume=remote-volume --format "table {{.ID}}\t{{.Mounts}}"
CONTAINER ID MOUNTS
9c3527ed70ce remote-volume
## Display containers with a volume mounted in `/data`
$ docker container ls --filter volume=/data --format "table {{.ID}}\t{{.Mounts}}"
CONTAINER ID MOUNTS
9c3527ed70ce remote-volume
## Display containers that have published port of 80:
$ docker ps --filter publish=80
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fc7e477723b7 busybox "top" About a minute ago Up About a minute 0.0.0.0:32768->80/tcp admiring_roentgen
## Display containers that have exposed TCP port in the range of `8000-8080`:
$ docker ps --filter expose=8000-8080/tcp
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9833437217a5 busybox "top" 21 seconds ago Up 19 seconds 8080/tcp dreamy_mccarthy

12
vendor/github.com/docker/docker-ce/components/cli/man/src/container/pause.md generated vendored Normal file
View file

@ -0,0 +1,12 @@
The `docker container pause` command suspends all processes in the specified containers.
On Linux, this uses the cgroups freezer. Traditionally, when suspending a process
the `SIGSTOP` signal is used, which is observable by the process being suspended.
With the cgroups freezer the process is unaware, and unable to capture,
that it is being suspended, and subsequently resumed. On Windows, only Hyper-V
containers can be paused.
See the [cgroups freezer documentation]
(https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt) for
further details.
**docker-container-unpause(1)** to unpause all processes within a container.

26
vendor/github.com/docker/docker-ce/components/cli/man/src/container/port.md generated vendored Normal file
View file

@ -0,0 +1,26 @@
List port mappings for the CONTAINER, or lookup the public-facing port that is NAT-ed to the PRIVATE_PORT
# EXAMPLES
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b650456536c7 busybox:latest top 54 minutes ago Up 54 minutes 0.0.0.0:1234->9876/tcp, 0.0.0.0:4321->7890/tcp test
## Find out all the ports mapped
$ docker container port test
7890/tcp -> 0.0.0.0:4321
9876/tcp -> 0.0.0.0:1234
## Find out a specific mapping
$ docker container port test 7890/tcp
0.0.0.0:4321
$ docker container port test 7890
0.0.0.0:4321
## An example showing error for non-existent mapping
$ docker container port test 7890/udp
2014/06/24 11:53:36 Error: No public port '7890/udp' published for test

1
vendor/github.com/docker/docker-ce/components/cli/man/src/container/rename.md generated vendored Normal file
View file

@ -0,0 +1 @@
Rename a container. Container may be running, paused or stopped.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/container/restart.md generated vendored Normal file
View file

@ -0,0 +1 @@
Restart each container listed.

37
vendor/github.com/docker/docker-ce/components/cli/man/src/container/rm.md generated vendored Normal file
View file

@ -0,0 +1,37 @@
**docker container rm** will remove one or more containers from the host node. The
container name or ID can be used. This does not remove images. You cannot
remove a running container unless you use the **-f** option. To see all
containers on a host use the **docker container ls -a** command.
# EXAMPLES
## Removing a container using its ID
To remove a container using its ID, find either from a **docker ps -a**
command, or use the ID returned from the **docker run** command, or retrieve
it from a file used to store it using the **docker run --cidfile**:
docker container rm abebf7571666
## Removing a container using the container name
The name of the container can be found using the **docker ps -a**
command. The use that name as follows:
docker container rm hopeful_morse
## Removing a container and all associated volumes
$ docker container rm -v redis
redis
This command will remove the container and any volumes associated with it.
Note that if a volume was specified with a name, it will not be removed.
$ docker create -v awesome:/foo -v /bar --name hello redis
hello
$ docker container rm -v hello
In this example, the volume for `/foo` will remain in tact, but the volume for
`/bar` will be removed. The same behavior holds for volumes inherited with
`--volumes-from`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/container/run.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker run`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/container/start.md generated vendored Normal file
View file

@ -0,0 +1 @@
Start one or more containers.

43
vendor/github.com/docker/docker-ce/components/cli/man/src/container/stats.md generated vendored Normal file
View file

@ -0,0 +1,43 @@
Display a live stream of one or more containers' resource usage statistics
# Format
Pretty-print containers statistics using a Go template.
Valid placeholders:
.Container - Container name or ID.
.Name - Container name.
.ID - Container ID.
.CPUPerc - CPU percentage.
.MemUsage - Memory usage.
.NetIO - Network IO.
.BlockIO - Block IO.
.MemPerc - Memory percentage (Not available on Windows).
.PIDs - Number of PIDs (Not available on Windows).
# EXAMPLES
Running `docker container stats` on all running containers.
$ docker container stats
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O
1285939c1fd3 0.07% 796 KiB / 64 MiB 1.21% 788 B / 648 B 3.568 MB / 512 KB
9c76f7834ae2 0.07% 2.746 MiB / 64 MiB 4.29% 1.266 KB / 648 B 12.4 MB / 0 B
d1ea048f04e4 0.03% 4.583 MiB / 64 MiB 6.30% 2.854 KB / 648 B 27.7 MB / 0 B
Running `docker container stats` on multiple containers by name and id.
$ docker container stats fervent_panini 5acfcb1b4fd1
CONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/O
5acfcb1b4fd1 0.00% 115.2 MiB/1.045 GiB 11.03% 1.422 kB/648 B
fervent_panini 0.02% 11.08 MiB/1.045 GiB 1.06% 648 B/648 B
Running `docker container stats` with customized format on all (Running and Stopped) containers.
$ docker container stats --all --format "table {{.ID}}\t{{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
CONTAINER ID NAME CPU % MEM USAGE / LIMIT
c9dfa83f0317f87637d5b7e67aa4223337d947215c5a9947e697e4f7d3e0f834 ecstatic_noether 0.00% 56KiB / 15.57GiB
8f92d01cf3b29b4f5fca4cd33d907e05def7af5a3684711b20a2369d211ec67f stoic_goodall 0.07% 32.86MiB / 15.57GiB
38dd23dba00f307d53d040c1d18a91361bbdcccbf592315927d56cf13d8b7343 drunk_visvesvaraya 0.00% 0B / 0B
5a8b07ec4cc52823f3cbfdb964018623c1ba307bce2c057ccdbde5f4f6990833 big_heisenberg 0.00% 0B / 0B
`drunk_visvesvaraya` and `big_heisenberg` are stopped containers in the above example.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/container/stop.md generated vendored Normal file
View file

@ -0,0 +1 @@
Stop a container (Send SIGTERM, and then SIGKILL after grace period)

11
vendor/github.com/docker/docker-ce/components/cli/man/src/container/top.md generated vendored Normal file
View file

@ -0,0 +1,11 @@
Display the running process of the container. ps-OPTION can be any of the options you would pass to a Linux ps command.
All displayed information is from host's point of view.
# EXAMPLES
Run **docker container top** with the ps option of -x:
$ docker container top 8601afda2b -x
PID TTY STAT TIME COMMAND
16623 ? Ss 0:00 sleep 99999

6
vendor/github.com/docker/docker-ce/components/cli/man/src/container/unpause.md generated vendored Normal file
View file

@ -0,0 +1,6 @@
The `docker container unpause` command un-suspends all processes in a container.
On Linux, it does this using the cgroups freezer.
See the [cgroups freezer documentation]
(https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt) for
further details.

102
vendor/github.com/docker/docker-ce/components/cli/man/src/container/update.md generated vendored Normal file
View file

@ -0,0 +1,102 @@
The **docker container update** command dynamically updates container configuration.
You can use this command to prevent containers from consuming too many
resources from their Docker host. With a single command, you can place
limits on a single container or on many. To specify more than one container,
provide space-separated list of container names or IDs.
With the exception of the **--kernel-memory** option, you can specify these
options on a running or a stopped container. On kernel version older than
4.6, You can only update **--kernel-memory** on a stopped container or on
a running container with kernel memory initialized.
# OPTIONS
## kernel-memory
Kernel memory limit (format: `<number>[<unit>]`, where unit = b, k, m or g)
Note that on kernel version older than 4.6, you can not update kernel memory on
a running container if the container is started without kernel memory initialized,
in this case, it can only be updated after it's stopped. The new setting takes
effect when the container is started.
## memory
Memory limit (format: <number><optional unit>, where unit = b, k, m or g)
Note that the memory should be smaller than the already set swap memory limit.
If you want update a memory limit bigger than the already set swap memory limit,
you should update swap memory limit at the same time. If you don't set swap memory
limit on docker create/run but only memory limit, the swap memory is double
the memory limit.
# EXAMPLES
The following sections illustrate ways to use this command.
### Update a container's cpu-shares
To limit a container's cpu-shares to 512, first identify the container
name or ID. You can use **docker ps** to find these values. You can also
use the ID returned from the **docker run** command. Then, do the following:
```bash
$ docker container update --cpu-shares 512 abebf7571666
```
### Update a container with cpu-shares and memory
To update multiple resource configurations for multiple containers:
```bash
$ docker container update --cpu-shares 512 -m 300M abebf7571666 hopeful_morse
```
### Update a container's kernel memory constraints
You can update a container's kernel memory limit using the **--kernel-memory**
option. On kernel version older than 4.6, this option can be updated on a
running container only if the container was started with **--kernel-memory**.
If the container was started *without* **--kernel-memory** you need to stop
the container before updating kernel memory.
For example, if you started a container with this command:
```bash
$ docker run -dit --name test --kernel-memory 50M ubuntu bash
```
You can update kernel memory while the container is running:
```bash
$ docker container update --kernel-memory 80M test
```
If you started a container *without* kernel memory initialized:
```bash
$ docker run -dit --name test2 --memory 300M ubuntu bash
```
Update kernel memory of running container `test2` will fail. You need to stop
the container before updating the **--kernel-memory** setting. The next time you
start it, the container uses the new value.
Kernel version newer than (include) 4.6 does not have this limitation, you
can use `--kernel-memory` the same way as other options.
### Update a container's restart policy
You can change a container's restart policy on a running container. The new
restart policy takes effect instantly after you run `docker container update` on a
container.
To update restart policy for one or more containers:
```bash
$ docker container update --restart=on-failure:3 abebf7571666 hopeful_morse
```
Note that if the container is started with "--rm" flag, you cannot update the restart
policy for it. The `AutoRemove` and `RestartPolicy` are mutually exclusive for the
container.

8
vendor/github.com/docker/docker-ce/components/cli/man/src/container/wait.md generated vendored Normal file
View file

@ -0,0 +1,8 @@
Block until a container stops, then print its exit code.
# EXAMPLES
$ docker run -d fedora sleep 99
079b83f558a2bc52ecad6b2a5de13622d584e6bb1aea058c11b36511e85e7622
$ docker container wait 079b83f558a2bc
0

1
vendor/github.com/docker/docker-ce/components/cli/man/src/cp.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container cp`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/create.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container create`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/diff.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container diff`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/events.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker system events`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/exec.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container exec`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/export.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container export`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/history.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker image history`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/image/build.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker build`.

54
vendor/github.com/docker/docker-ce/components/cli/man/src/image/history.md generated vendored Normal file
View file

@ -0,0 +1,54 @@
Show the history of when and how an image was created.
# EXAMPLES
$ docker history fedora
IMAGE CREATED CREATED BY SIZE COMMENT
105182bb5e8b 5 days ago /bin/sh -c #(nop) ADD file:71356d2ad59aa3119d 372.7 MB
73bd853d2ea5 13 days ago /bin/sh -c #(nop) MAINTAINER Lokesh Mandvekar 0 B
511136ea3c5a 10 months ago 0 B Imported from -
## Display comments in the image history
The `docker commit` command has a **-m** flag for adding comments to the image. These comments will be displayed in the image history.
$ sudo docker history docker:scm
IMAGE CREATED CREATED BY SIZE COMMENT
2ac9d1098bf1 3 months ago /bin/bash 241.4 MB Added Apache to Fedora base image
88b42ffd1f7c 5 months ago /bin/sh -c #(nop) ADD file:1fd8d7f9f6557cafc7 373.7 MB
c69cab00d6ef 5 months ago /bin/sh -c #(nop) MAINTAINER Lokesh Mandvekar 0 B
511136ea3c5a 19 months ago 0 B Imported from -
### Format the output
The formatting option (`--format`) will pretty-prints history output
using a Go template.
Valid placeholders for the Go template are listed below:
| Placeholder | Description |
| --------------- | ----------- |
| `.ID` | Image ID |
| `.CreatedSince` | Elapsed time since the image was created if `--human=true`, otherwise timestamp of when image was created |
| `.CreatedAt` | Timestamp of when image was created |
| `.CreatedBy` | Command that was used to create the image |
| `.Size` | Image disk size |
| `.Comment` | Comment for image |
When using the `--format` option, the `history` command will either
output the data exactly as the template declares or, when using the
`table` directive, will include column headers as well.
The following example uses a template without headers and outputs the
`ID` and `CreatedSince` entries separated by a colon for all images:
```bash
$ docker images --format "{{.ID}}: {{.Created}} ago"
cc1b61406712: 2 weeks ago
<missing>: 2 weeks ago
<missing>: 2 weeks ago
<missing>: 2 weeks ago
<missing>: 2 weeks ago
<missing>: 3 weeks ago
<missing>: 3 weeks ago
<missing>: 3 weeks ago
```

42
vendor/github.com/docker/docker-ce/components/cli/man/src/image/import.md generated vendored Normal file
View file

@ -0,0 +1,42 @@
Create a new filesystem image from the contents of a tarball (`.tar`,
`.tar.gz`, `.tgz`, `.bzip`, `.tar.xz`, `.txz`) into it, then optionally tag it.
# EXAMPLES
## Import from a remote location
# docker image import http://example.com/exampleimage.tgz example/imagerepo
## Import from a local file
Import to docker via pipe and stdin:
# cat exampleimage.tgz | docker image import - example/imagelocal
Import with a commit message.
# cat exampleimage.tgz | docker image import --message "New image imported from tarball" - exampleimagelocal:new
Import to a Docker image from a local file.
# docker image import /path/to/exampleimage.tgz
## Import from a local file and tag
Import to docker via pipe and stdin:
# cat exampleimageV2.tgz | docker image import - example/imagelocal:V-2.0
## Import from a local directory
# tar -c . | docker image import - exampleimagedir
## Apply specified Dockerfile instructions while importing the image
This example sets the docker image ENV variable DEBUG to true by default.
# tar -c . | docker image import -c="ENV DEBUG true" - exampleimagedir
# See also
**docker-export(1)** to export the contents of a filesystem as a tar archive to STDOUT.

25
vendor/github.com/docker/docker-ce/components/cli/man/src/image/load.md generated vendored Normal file
View file

@ -0,0 +1,25 @@
Loads a tarred repository from a file or the standard input stream.
Restores both images and tags. Write image names or IDs imported it
standard output stream.
# EXAMPLES
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
busybox latest 769b9341d937 7 weeks ago 2.489 MB
$ docker load --input fedora.tar
# […]
Loaded image: fedora:rawhide
# […]
Loaded image: fedora:20
# […]
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
busybox latest 769b9341d937 7 weeks ago 2.489 MB
fedora rawhide 0d20aec6529d 7 weeks ago 387 MB
fedora 20 58394af37342 7 weeks ago 385.5 MB
fedora heisenbug 58394af37342 7 weeks ago 385.5 MB
fedora latest 58394af37342 7 weeks ago 385.5 MB
# See also
**docker-image-save(1)** to save one or more images to a tar archive (streamed to STDOUT by default).

118
vendor/github.com/docker/docker-ce/components/cli/man/src/image/ls.md generated vendored Normal file
View file

@ -0,0 +1,118 @@
This command lists the images stored in the local Docker repository.
By default, intermediate images, used during builds, are not listed. Some of the
output, e.g., image ID, is truncated, for space reasons. However the truncated
image ID, and often the first few characters, are enough to be used in other
Docker commands that use the image ID. The output includes repository, tag, image
ID, date created and the virtual size.
The title REPOSITORY for the first title may seem confusing. It is essentially
the image name. However, because you can tag a specific image, and multiple tags
(image instances) can be associated with a single name, the name is really a
repository for all tagged images of the same name. For example consider an image
called fedora. It may be tagged with 18, 19, or 20, etc. to manage different
versions.
## Filters
Filters the output based on these conditions:
- dangling=(true|false) - find unused images
- label=<key> or label=<key>=<value>
- before=(<image-name>[:tag]|<image-id>|<image@digest>)
- since=(<image-name>[:tag]|<image-id>|<image@digest>)
- reference=(pattern of an image reference)
## Format
Pretty-print images using a Go template.
Valid placeholders:
.ID - Image ID
.Repository - Image repository
.Tag - Image tag
.Digest - Image digest
.CreatedSince - Elapsed time since the image was created
.CreatedAt - Time when the image was created
.Size - Image disk size
# EXAMPLES
## Listing the images
To list the images in a local repository (not the registry) run:
docker image ls
The list will contain the image repository name, a tag for the image, and an
image ID, when it was created and its virtual size. Columns: REPOSITORY, TAG,
IMAGE ID, CREATED, and SIZE.
The `docker image ls` command takes an optional `[REPOSITORY[:TAG]]` argument
that restricts the list to images that match the argument. If you specify
`REPOSITORY` but no `TAG`, the `docker image ls` command lists all images in the
given repository.
docker image ls java
The `[REPOSITORY[:TAG]]` value must be an "exact match". This means that, for example,
`docker image ls jav` does not match the image `java`.
If both `REPOSITORY` and `TAG` are provided, only images matching that
repository and tag are listed. To find all local images in the "java"
repository with tag "8" you can use:
docker image ls java:8
To get a verbose list of images which contains all the intermediate images
used in builds use **-a**:
docker image ls -a
Previously, the docker image ls command supported the --tree and --dot arguments,
which displayed different visualizations of the image data. Docker core removed
this functionality in the 1.7 version. If you liked this functionality, you can
still find it in the third-party dockviz tool: https://github.com/justone/dockviz.
## Listing images in a desired format
When using the --format option, the image command will either output the data
exactly as the template declares or, when using the `table` directive, will
include column headers as well. You can use special characters like `\t` for
inserting tab spacing between columns.
The following example uses a template without headers and outputs the ID and
Repository entries separated by a colon for all images:
docker images --format "{{.ID}}: {{.Repository}}"
77af4d6b9913: <none>
b6fa739cedf5: committ
78a85c484bad: ipbabble
30557a29d5ab: docker
5ed6274db6ce: <none>
746b819f315e: postgres
746b819f315e: postgres
746b819f315e: postgres
746b819f315e: postgres
To list all images with their repository and tag in a table format you can use:
docker images --format "table {{.ID}}\t{{.Repository}}\t{{.Tag}}"
IMAGE ID REPOSITORY TAG
77af4d6b9913 <none> <none>
b6fa739cedf5 committ latest
78a85c484bad ipbabble <none>
30557a29d5ab docker latest
5ed6274db6ce <none> <none>
746b819f315e postgres 9
746b819f315e postgres 9.3
746b819f315e postgres 9.3.5
746b819f315e postgres latest
Valid template placeholders are listed above.
## Listing only the shortened image IDs
Listing just the shortened image IDs. This can be useful for some automated
tools.
docker image ls -q

189
vendor/github.com/docker/docker-ce/components/cli/man/src/image/pull.md generated vendored Normal file
View file

@ -0,0 +1,189 @@
This command pulls down an image or a repository from a registry. If
there is more than one image for a repository (e.g., fedora) then all
images for that repository name can be pulled down including any tags
(see the option **-a** or **--all-tags**).
If you do not specify a `REGISTRY_HOST`, the command uses Docker's public
registry located at `registry-1.docker.io` by default.
# EXAMPLES
### Pull an image from Docker Hub
To download a particular image, or set of images (i.e., a repository), use
`docker image pull`. If no tag is provided, Docker Engine uses the `:latest` tag as a
default. This command pulls the `debian:latest` image:
$ docker image pull debian
Using default tag: latest
latest: Pulling from library/debian
fdd5d7827f33: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:e7d38b3517548a1c71e41bffe9c8ae6d6d29546ce46bf62159837aad072c90aa
Status: Downloaded newer image for debian:latest
Docker images can consist of multiple layers. In the example above, the image
consists of two layers; `fdd5d7827f33` and `a3ed95caeb02`.
Layers can be reused by images. For example, the `debian:jessie` image shares
both layers with `debian:latest`. Pulling the `debian:jessie` image therefore
only pulls its metadata, but not its layers, because all layers are already
present locally:
$ docker image pull debian:jessie
jessie: Pulling from library/debian
fdd5d7827f33: Already exists
a3ed95caeb02: Already exists
Digest: sha256:a9c958be96d7d40df920e7041608f2f017af81800ca5ad23e327bc402626b58e
Status: Downloaded newer image for debian:jessie
To see which images are present locally, use the **docker-images(1)**
command:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
debian jessie f50f9524513f 5 days ago 125.1 MB
debian latest f50f9524513f 5 days ago 125.1 MB
Docker uses a content-addressable image store, and the image ID is a SHA256
digest covering the image's configuration and layers. In the example above,
`debian:jessie` and `debian:latest` have the same image ID because they are
actually the *same* image tagged with different names. Because they are the
same image, their layers are stored only once and do not consume extra disk
space.
For more information about images, layers, and the content-addressable store,
refer to [understand images, containers, and storage drivers](https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/)
in the online documentation.
## Pull an image by digest (immutable identifier)
So far, you've pulled images by their name (and "tag"). Using names and tags is
a convenient way to work with images. When using tags, you can `docker image pull` an
image again to make sure you have the most up-to-date version of that image.
For example, `docker image pull ubuntu:14.04` pulls the latest version of the Ubuntu
14.04 image.
In some cases you don't want images to be updated to newer versions, but prefer
to use a fixed version of an image. Docker enables you to pull an image by its
*digest*. When pulling an image by digest, you specify *exactly* which version
of an image to pull. Doing so, allows you to "pin" an image to that version,
and guarantee that the image you're using is always the same.
To know the digest of an image, pull the image first. Let's pull the latest
`ubuntu:14.04` image from Docker Hub:
$ docker image pull ubuntu:14.04
14.04: Pulling from library/ubuntu
5a132a7e7af1: Pull complete
fd2731e4c50c: Pull complete
28a2f68d1120: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
Status: Downloaded newer image for ubuntu:14.04
Docker prints the digest of the image after the pull has finished. In the example
above, the digest of the image is:
sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
Docker also prints the digest of an image when *pushing* to a registry. This
may be useful if you want to pin to a version of the image you just pushed.
A digest takes the place of the tag when pulling an image, for example, to
pull the above image by digest, run the following command:
$ docker image pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2: Pulling from library/ubuntu
5a132a7e7af1: Already exists
fd2731e4c50c: Already exists
28a2f68d1120: Already exists
a3ed95caeb02: Already exists
Digest: sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
Status: Downloaded newer image for ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
Digest can also be used in the `FROM` of a Dockerfile, for example:
FROM ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
MAINTAINER some maintainer <maintainer@example.com>
> **Note**: Using this feature "pins" an image to a specific version in time.
> Docker will therefore not pull updated versions of an image, which may include
> security updates. If you want to pull an updated image, you need to change the
> digest accordingly.
## Pulling from a different registry
By default, `docker image pull` pulls images from Docker Hub. It is also possible to
manually specify the path of a registry to pull from. For example, if you have
set up a local registry, you can specify its path to pull from it. A registry
path is similar to a URL, but does not contain a protocol specifier (`https://`).
The following command pulls the `testing/test-image` image from a local registry
listening on port 5000 (`myregistry.local:5000`):
$ docker image pull myregistry.local:5000/testing/test-image
Registry credentials are managed by **docker-login(1)**.
Docker uses the `https://` protocol to communicate with a registry, unless the
registry is allowed to be accessed over an insecure connection. Refer to the
[insecure registries](https://docs.docker.com/engine/reference/commandline/dockerd/#insecure-registries)
section in the online documentation for more information.
## Pull a repository with multiple images
By default, `docker image pull` pulls a *single* image from the registry. A repository
can contain multiple images. To pull all images from a repository, provide the
`-a` (or `--all-tags`) option when using `docker image pull`.
This command pulls all images from the `fedora` repository:
$ docker image pull --all-tags fedora
Pulling repository fedora
ad57ef8d78d7: Download complete
105182bb5e8b: Download complete
511136ea3c5a: Download complete
73bd853d2ea5: Download complete
....
Status: Downloaded newer image for fedora
After the pull has completed use the `docker images` command to see the
images that were pulled. The example below shows all the `fedora` images
that are present locally:
$ docker images fedora
REPOSITORY TAG IMAGE ID CREATED SIZE
fedora rawhide ad57ef8d78d7 5 days ago 359.3 MB
fedora 20 105182bb5e8b 5 days ago 372.7 MB
fedora heisenbug 105182bb5e8b 5 days ago 372.7 MB
fedora latest 105182bb5e8b 5 days ago 372.7 MB
## Canceling a pull
Killing the `docker image pull` process, for example by pressing `CTRL-c` while it is
running in a terminal, will terminate the pull operation.
$ docker image pull fedora
Using default tag: latest
latest: Pulling from library/fedora
a3ed95caeb02: Pulling fs layer
236608c7b546: Pulling fs layer
^C
> **Note**: Technically, the Engine terminates a pull operation when the
> connection between the Docker Engine daemon and the Docker Engine client
> initiating the pull is lost. If the connection with the Engine daemon is
> lost for other reasons than a manual interaction, the pull is also aborted.

34
vendor/github.com/docker/docker-ce/components/cli/man/src/image/push.md generated vendored Normal file
View file

@ -0,0 +1,34 @@
Use `docker image push` to share your images to the [Docker Hub](https://hub.docker.com)
registry or to a self-hosted one.
Refer to **docker-image-tag(1)** for more information about valid image and tag names.
Killing the **docker image push** process, for example by pressing **CTRL-c** while it
is running in a terminal, terminates the push operation.
Registry credentials are managed by **docker-login(1)**.
# EXAMPLES
## Pushing a new image to a registry
First save the new image by finding the container ID (using **docker container ls**)
and then committing it to a new image name. Note that only a-z0-9-_. are
allowed when naming images:
# docker container commit c16378f943fe rhel-httpd
Now, push the image to the registry using the image ID. In this example the
registry is on host named `registry-host` and listening on port `5000`. To do
this, tag the image with the host name or IP address, and the port of the
registry:
# docker image tag rhel-httpd registry-host:5000/myadmin/rhel-httpd
# docker image push registry-host:5000/myadmin/rhel-httpd
Check that this worked by running:
# docker image ls
You should see both `rhel-httpd` and `registry-host:5000/myadmin/rhel-httpd`
listed.

11
vendor/github.com/docker/docker-ce/components/cli/man/src/image/rm.md generated vendored Normal file
View file

@ -0,0 +1,11 @@
Removes one or more images from the host node. This does not remove images from
a registry. You cannot remove an image of a running container unless you use the
**-f** option. To see all images on a host use the **docker image ls** command.
# EXAMPLES
## Removing an image
Here is an example of removing an image:
docker image rm fedora/httpd

19
vendor/github.com/docker/docker-ce/components/cli/man/src/image/save.md generated vendored Normal file
View file

@ -0,0 +1,19 @@
Produces a tarred repository to the standard output stream. Contains all
parent layers, and all tags + versions, or specified repo:tag.
Stream to a file instead of STDOUT by using **-o**.
# EXAMPLES
Save all fedora repository images to a fedora-all.tar and save the latest
fedora image to a fedora-latest.tar:
$ docker image save fedora > fedora-all.tar
$ docker image save --output=fedora-latest.tar fedora:latest
$ ls -sh fedora-all.tar
721M fedora-all.tar
$ ls -sh fedora-latest.tar
367M fedora-latest.tar
# See also
**docker-image-load(1)** to load an image from a tar archive on STDIN.

54
vendor/github.com/docker/docker-ce/components/cli/man/src/image/tag.md generated vendored Normal file
View file

@ -0,0 +1,54 @@
Assigns a new alias to an image in a registry. An alias refers to the
entire image name including the optional `TAG` after the ':'.
# OPTIONS
**NAME**
The image name which is made up of slash-separated name components,
optionally prefixed by a registry hostname. The hostname must comply with
standard DNS rules, but may not contain underscores. If a hostname is
present, it may optionally be followed by a port number in the format
`:8080`. If not present, the command uses Docker's public registry located at
`registry-1.docker.io` by default. Name components may contain lowercase
letters, digits and separators. A separator is defined as a period, one or
two underscores, or one or more dashes. A name component may not start or end
with a separator.
**TAG**
The tag assigned to the image to version and distinguish images with the same
name. The tag name must be valid ASCII and may contain lowercase and
uppercase letters, digits, underscores, periods and hyphens. A tag name
may not start with a period or a hyphen and may contain a maximum of 128
characters.
# EXAMPLES
## Tagging an image referenced by ID
To tag a local image with ID "0e5574283393" into the "fedora" repository with
"version1.0":
docker image tag 0e5574283393 fedora/httpd:version1.0
## Tagging an image referenced by Name
To tag a local image with name "httpd" into the "fedora" repository with
"version1.0":
docker image tag httpd fedora/httpd:version1.0
Note that since the tag name is not specified, the alias is created for an
existing local version `httpd:latest`.
## Tagging an image referenced by Name and Tag
To tag a local image with name "httpd" and tag "test" into the "fedora"
repository with "version1.0.test":
docker image tag httpd:test fedora/httpd:version1.0.test
## Tagging an image for a private repository
To push an image to a private registry and not the central Docker
registry you must tag it with the registry hostname and port (if needed).
docker image tag 0e5574283393 myregistryhost:5000/fedora/httpd:version1.0

1
vendor/github.com/docker/docker-ce/components/cli/man/src/images.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker image ls`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/import.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker image import`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/info.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker system info`.

286
vendor/github.com/docker/docker-ce/components/cli/man/src/inspect.md generated vendored Normal file
View file

@ -0,0 +1,286 @@
This displays the low-level information on Docker object(s) (e.g. container,
image, volume,network, node, service, or task) identified by name or ID. By default,
this will render all results in a JSON array. If the container and image have
the same name, this will return container JSON for unspecified type. If a format
is specified, the given template will be executed for each result.
# EXAMPLES
Get information about an image when image name conflicts with the container name,
e.g. both image and container are named rhel7:
$ docker inspect --type=image rhel7
[
{
"Id": "fe01a428b9d9de35d29531e9994157978e8c48fa693e1bf1d221dffbbb67b170",
"Parent": "10acc31def5d6f249b548e01e8ffbaccfd61af0240c17315a7ad393d022c5ca2",
....
}
]
## Getting information on a container
To get information on a container use its ID or instance name:
$ docker inspect d2cc496561d6
[{
"Id": "d2cc496561d6d520cbc0236b4ba88c362c446a7619992123f11c809cded25b47",
"Created": "2015-06-08T16:18:02.505155285Z",
"Path": "bash",
"Args": [],
"State": {
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 0,
"ExitCode": 0,
"Error": "",
"StartedAt": "2015-06-08T16:18:03.643865954Z",
"FinishedAt": "2015-06-08T16:57:06.448552862Z"
},
"Image": "ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4",
"NetworkSettings": {
"Bridge": "",
"SandboxID": "6b4851d1903e16dd6a567bd526553a86664361f31036eaaa2f8454d6f4611f6f",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": {},
"SandboxKey": "/var/run/docker/netns/6b4851d1903e",
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "7587b82f0dada3656fda26588aee72630c6fab1536d36e394b2bfbcf898c971d",
"Gateway": "172.17.0.1",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"MacAddress": "02:42:ac:12:00:02",
"Networks": {
"bridge": {
"NetworkID": "7ea29fc1412292a2d7bba362f9253545fecdfa8ce9a6e37dd10ba8bee7129812",
"EndpointID": "7587b82f0dada3656fda26588aee72630c6fab1536d36e394b2bfbcf898c971d",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "02:42:ac:12:00:02"
}
}
},
"ResolvConfPath": "/var/lib/docker/containers/d2cc496561d6d520cbc0236b4ba88c362c446a7619992123f11c809cded25b47/resolv.conf",
"HostnamePath": "/var/lib/docker/containers/d2cc496561d6d520cbc0236b4ba88c362c446a7619992123f11c809cded25b47/hostname",
"HostsPath": "/var/lib/docker/containers/d2cc496561d6d520cbc0236b4ba88c362c446a7619992123f11c809cded25b47/hosts",
"LogPath": "/var/lib/docker/containers/d2cc496561d6d520cbc0236b4ba88c362c446a7619992123f11c809cded25b47/d2cc496561d6d520cbc0236b4ba88c362c446a7619992123f11c809cded25b47-json.log",
"Name": "/adoring_wozniak",
"RestartCount": 0,
"Driver": "devicemapper",
"MountLabel": "",
"ProcessLabel": "",
"Mounts": [
{
"Source": "/data",
"Destination": "/data",
"Mode": "ro,Z",
"RW": false
"Propagation": ""
}
],
"AppArmorProfile": "",
"ExecIDs": null,
"HostConfig": {
"Binds": null,
"ContainerIDFile": "",
"Memory": 0,
"MemorySwap": 0,
"CpuShares": 0,
"CpuPeriod": 0,
"CpusetCpus": "",
"CpusetMems": "",
"CpuQuota": 0,
"BlkioWeight": 0,
"OomKillDisable": false,
"Privileged": false,
"PortBindings": {},
"Links": null,
"PublishAllPorts": false,
"Dns": null,
"DnsSearch": null,
"DnsOptions": null,
"ExtraHosts": null,
"VolumesFrom": null,
"Devices": [],
"NetworkMode": "bridge",
"IpcMode": "",
"PidMode": "",
"UTSMode": "",
"CapAdd": null,
"CapDrop": null,
"RestartPolicy": {
"Name": "no",
"MaximumRetryCount": 0
},
"SecurityOpt": null,
"ReadonlyRootfs": false,
"Ulimits": null,
"LogConfig": {
"Type": "json-file",
"Config": {}
},
"CgroupParent": ""
},
"GraphDriver": {
"Name": "devicemapper",
"Data": {
"DeviceId": "5",
"DeviceName": "docker-253:1-2763198-d2cc496561d6d520cbc0236b4ba88c362c446a7619992123f11c809cded25b47",
"DeviceSize": "171798691840"
}
},
"Config": {
"Hostname": "d2cc496561d6",
"Domainname": "",
"User": "",
"AttachStdin": true,
"AttachStdout": true,
"AttachStderr": true,
"ExposedPorts": null,
"Tty": true,
"OpenStdin": true,
"StdinOnce": true,
"Env": null,
"Cmd": [
"bash"
],
"Image": "fedora",
"Volumes": null,
"VolumeDriver": "",
"WorkingDir": "",
"Entrypoint": null,
"NetworkDisabled": false,
"MacAddress": "",
"OnBuild": null,
"Labels": {},
"Memory": 0,
"MemorySwap": 0,
"CpuShares": 0,
"Cpuset": "",
"StopSignal": "SIGTERM"
}
}
]
## Getting the IP address of a container instance
To get the IP address of a container use:
$ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' d2cc496561d6
172.17.0.2
## Listing all port bindings
One can loop over arrays and maps in the results to produce simple text
output:
$ docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} \
{{$p}} -> {{(index $conf 0).HostPort}} {{end}}' d2cc496561d6
80/tcp -> 80
You can get more information about how to write a Go template from:
https://golang.org/pkg/text/template/.
## Getting size information on a container
$ docker inspect -s d2cc496561d6
[
{
....
"SizeRw": 0,
"SizeRootFs": 972,
....
}
]
## Getting information on an image
Use an image's ID or name (e.g., repository/name[:tag]) to get information
about the image:
$ docker inspect ded7cd95e059
[{
"Id": "ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4",
"Parent": "48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731",
"Comment": "",
"Created": "2015-05-27T16:58:22.937503085Z",
"Container": "76cf7f67d83a7a047454b33007d03e32a8f474ad332c3a03c94537edd22b312b",
"ContainerConfig": {
"Hostname": "76cf7f67d83a",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": null,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": null,
"Cmd": [
"/bin/sh",
"-c",
"#(nop) ADD file:4be46382bcf2b095fcb9fe8334206b584eff60bb3fad8178cbd97697fcb2ea83 in /"
],
"Image": "48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731",
"Volumes": null,
"VolumeDriver": "",
"WorkingDir": "",
"Entrypoint": null,
"NetworkDisabled": false,
"MacAddress": "",
"OnBuild": null,
"Labels": {}
},
"DockerVersion": "1.6.0",
"Author": "Lokesh Mandvekar \u003clsm5@fedoraproject.org\u003e",
"Config": {
"Hostname": "76cf7f67d83a",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": null,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": null,
"Cmd": null,
"Image": "48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731",
"Volumes": null,
"VolumeDriver": "",
"WorkingDir": "",
"Entrypoint": null,
"NetworkDisabled": false,
"MacAddress": "",
"OnBuild": null,
"Labels": {}
},
"Architecture": "amd64",
"Os": "linux",
"Size": 186507296,
"VirtualSize": 186507296,
"GraphDriver": {
"Name": "devicemapper",
"Data": {
"DeviceId": "3",
"DeviceName": "docker-253:1-2763198-ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4",
"DeviceSize": "171798691840"
}
}
}
]

1
vendor/github.com/docker/docker-ce/components/cli/man/src/kill.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container kill`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/load.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker image load`.

22
vendor/github.com/docker/docker-ce/components/cli/man/src/login.md generated vendored Normal file
View file

@ -0,0 +1,22 @@
Log in to a Docker Registry located on the specified
`SERVER`. You can specify a URL or a `hostname` for the `SERVER` value. If you
do not specify a `SERVER`, the command uses Docker's public registry located at
`https://registry-1.docker.io/` by default. To get a username/password for Docker's public registry, create an account on Docker Hub.
`docker login` requires user to use `sudo` or be `root`, except when:
1. connecting to a remote daemon, such as a `docker-machine` provisioned `docker engine`.
2. user is added to the `docker` group. This will impact the security of your system; the `docker` group is `root` equivalent. See [Docker Daemon Attack Surface](https://docs.docker.com/engine/security/security/#/docker-daemon-attack-surface) for details.
You can log into any public or private repository for which you have
credentials. When you log in, the command stores encoded credentials in
`$HOME/.docker/config.json` on Linux or `%USERPROFILE%/.docker/config.json` on Windows.
# EXAMPLES
## Login to a registry on your localhost
# docker login localhost:8080
# See also
**docker-logout(1)** to log out from a Docker registry.

13
vendor/github.com/docker/docker-ce/components/cli/man/src/logout.md generated vendored Normal file
View file

@ -0,0 +1,13 @@
Log out of a Docker Registry located on the specified `SERVER`. You can
specify a URL or a `hostname` for the `SERVER` value. If you do not specify a
`SERVER`, the command attempts to log you out of Docker's public registry
located at `https://registry-1.docker.io/` by default.
# EXAMPLES
## Log out from a registry on your localhost
# docker logout localhost:8080
# See also
**docker-login(1)** to log in to a Docker registry server.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/logs.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container logs`.

39
vendor/github.com/docker/docker-ce/components/cli/man/src/network/connect.md generated vendored Normal file
View file

@ -0,0 +1,39 @@
Connects a container to a network. You can connect a container by name
or by ID. Once connected, the container can communicate with other containers in
the same network.
```bash
$ docker network connect multi-host-network container1
```
You can also use the `docker run --network=<network-name>` option to start a container and immediately connect it to a network.
```bash
$ docker run -itd --network=multi-host-network --ip 172.20.88.22 --ip6 2001:db8::8822 busybox
```
You can pause, restart, and stop containers that are connected to a network.
A container connects to its configured networks when it runs.
If specified, the container's IP address(es) is reapplied when a stopped
container is restarted. If the IP address is no longer available, the container
fails to start. One way to guarantee that the IP address is available is
to specify an `--ip-range` when creating the network, and choose the static IP
address(es) from outside that range. This ensures that the IP address is not
given to another container while this container is not on the network.
```bash
$ docker network create --subnet 172.20.0.0/16 --ip-range 172.20.240.0/20 multi-host-network
```
```bash
$ docker network connect --ip 172.20.128.2 multi-host-network container2
```
To verify the container is connected, use the `docker network inspect` command. Use `docker network disconnect` to remove a container from the network.
Once connected in network, containers can communicate using only another
container's IP address or name. For `overlay` networks or custom plugins that
support multi-host connectivity, containers connected to the same multi-host
network but launched from different Engines can also communicate in this way.
You can connect a container to one or more networks. The networks need not be the same type. For example, you can connect a single container bridge and overlay networks.

177
vendor/github.com/docker/docker-ce/components/cli/man/src/network/create.md generated vendored Normal file
View file

@ -0,0 +1,177 @@
Creates a new network. The `DRIVER` accepts `bridge` or `overlay` which are the
built-in network drivers. If you have installed a third party or your own custom
network driver you can specify that `DRIVER` here also. If you don't specify the
`--driver` option, the command automatically creates a `bridge` network for you.
When you install Docker Engine it creates a `bridge` network automatically. This
network corresponds to the `docker0` bridge that Engine has traditionally relied
on. When launch a new container with `docker run` it automatically connects to
this bridge network. You cannot remove this default bridge network but you can
create new ones using the `network create` command.
```bash
$ docker network create -d bridge my-bridge-network
```
Bridge networks are isolated networks on a single Engine installation. If you
want to create a network that spans multiple Docker hosts each running an
Engine, you must create an `overlay` network. Unlike `bridge` networks overlay
networks require some pre-existing conditions before you can create one. These
conditions are:
* Access to a key-value store. Engine supports Consul, Etcd, and Zookeeper (Distributed store) key-value stores.
* A cluster of hosts with connectivity to the key-value store.
* A properly configured Engine `daemon` on each host in the cluster.
The `dockerd` options that support the `overlay` network are:
* `--cluster-store`
* `--cluster-store-opt`
* `--cluster-advertise`
To read more about these options and how to configure them, see ["*Get started
with multi-host
network*"](https://docs.docker.com/engine/userguide/networking/get-started-overlay/).
It is also a good idea, though not required, that you install Docker Swarm on to
manage the cluster that makes up your network. Swarm provides sophisticated
discovery and server management that can assist your implementation.
Once you have prepared the `overlay` network prerequisites you simply choose a
Docker host in the cluster and issue the following to create the network:
```bash
$ docker network create -d overlay my-multihost-network
```
Network names must be unique. The Docker daemon attempts to identify naming
conflicts but this is not guaranteed. It is the user's responsibility to avoid
name conflicts.
## Connect containers
When you start a container use the `--network` flag to connect it to a network.
This adds the `busybox` container to the `mynet` network.
```bash
$ docker run -itd --network=mynet busybox
```
If you want to add a container to a network after the container is already
running use the `docker network connect` subcommand.
You can connect multiple containers to the same network. Once connected, the
containers can communicate using only another container's IP address or name.
For `overlay` networks or custom plugins that support multi-host connectivity,
containers connected to the same multi-host network but launched from different
Engines can also communicate in this way.
You can disconnect a container from a network using the `docker network
disconnect` command.
## Specifying advanced options
When you create a network, Engine creates a non-overlapping subnetwork for the
network by default. This subnetwork is not a subdivision of an existing network.
It is purely for ip-addressing purposes. You can override this default and
specify subnetwork values directly using the `--subnet` option. On a
`bridge` network you can only create a single subnet:
```bash
$ docker network create -d bridge --subnet=192.168.0.0/16 br0
```
Additionally, you also specify the `--gateway` `--ip-range` and `--aux-address`
options.
```bash
$ docker network create \
--driver=bridge \
--subnet=172.28.0.0/16 \
--ip-range=172.28.5.0/24 \
--gateway=172.28.5.254 \
br0
```
If you omit the `--gateway` flag the Engine selects one for you from inside a
preferred pool. For `overlay` networks and for network driver plugins that
support it you can create multiple subnetworks.
```bash
$ docker network create -d overlay \
--subnet=192.168.0.0/16 \
--subnet=192.170.0.0/16 \
--gateway=192.168.0.100 \
--gateway=192.170.0.100 \
--ip-range=192.168.1.0/24 \
--aux-address="my-router=192.168.1.5" --aux-address="my-switch=192.168.1.6" \
--aux-address="my-printer=192.170.1.5" --aux-address="my-nas=192.170.1.6" \
my-multihost-network
```
Be sure that your subnetworks do not overlap. If they do, the network create
fails and Engine returns an error.
### Network internal mode
By default, when you connect a container to an `overlay` network, Docker also
connects a bridge network to it to provide external connectivity. If you want
to create an externally isolated `overlay` network, you can specify the
`--internal` option.
### Network ingress mode
You can create the network which will be used to provide the routing-mesh in the
swarm cluster. You do so by specifying `--ingress` when creating the network. Only
one ingress network can be created at the time. The network can be removed only
if no services depend on it. Any option available when creating an overlay network
is also available when creating the ingress network, besides the `--attachable` option.
```bash
$ docker network create -d overlay \
--subnet=10.11.0.0/16 \
--ingress \
--opt com.docker.network.mtu=9216 \
--opt encrypted=true \
my-ingress-network
```
### Run services on predefined networks
You can create services on the predefined docker networks `bridge` and `host`.
```bash
$ docker service create --name my-service \
--network host \
--replicas 2 \
busybox top
```
### Swarm networks with local scope drivers
You can create a swarm network with local scope network drivers. You do so
by promoting the network scope to `swarm` during the creation of the network.
You will then be able to use this network when creating services.
```bash
$ docker network create -d bridge \
--scope swarm \
--attachable \
swarm-network
```
For network drivers which provide connectivity across hosts (ex. macvlan), if
node specific configurations are needed in order to plumb the network on each
host, you will supply that configuration via a configuration only network.
When you create the swarm scoped network, you will then specify the name of the
network which contains the configuration.
```bash
node1$ docker network create --config-only --subnet 192.168.100.0/24 --gateway 192.168.100.115 mv-config
node2$ docker network create --config-only --subnet 192.168.200.0/24 --gateway 192.168.200.202 mv-config
node1$ docker network create -d macvlan --scope swarm --config-from mv-config --attachable swarm-network
```

5
vendor/github.com/docker/docker-ce/components/cli/man/src/network/disconnect.md generated vendored Normal file
View file

@ -0,0 +1,5 @@
Disconnects a container from a network.
```bash
$ docker network disconnect multi-host-network container1
```

183
vendor/github.com/docker/docker-ce/components/cli/man/src/network/inspect.md generated vendored Normal file
View file

@ -0,0 +1,183 @@
Returns information about one or more networks. By default, this command renders all results in a JSON object. For example, if you connect two containers to the default `bridge` network:
```bash
$ sudo docker run -itd --name=container1 busybox
f2870c98fd504370fb86e59f32cd0753b1ac9b69b7d80566ffc7192a82b3ed27
$ sudo docker run -itd --name=container2 busybox
bda12f8922785d1f160be70736f26c1e331ab8aaf8ed8d56728508f2e2fd4727
```
The `network inspect` command shows the containers, by id, in its
results. You can specify an alternate format to execute a given
template for each result. Go's
[text/template](http://golang.org/pkg/text/template/) package
describes all the details of the format.
```bash
$ sudo docker network inspect bridge
[
{
"Name": "bridge",
"Id": "b2b1a2cba717161d984383fd68218cf70bbbd17d328496885f7c921333228b0f",
"Scope": "local",
"Driver": "bridge",
"IPAM": {
"Driver": "default",
"Config": [
{
"Subnet": "172.17.42.1/16",
"Gateway": "172.17.42.1"
}
]
},
"Internal": false,
"Ingress": false,
"Containers": {
"bda12f8922785d1f160be70736f26c1e331ab8aaf8ed8d56728508f2e2fd4727": {
"Name": "container2",
"EndpointID": "0aebb8fcd2b282abe1365979536f21ee4ceaf3ed56177c628eae9f706e00e019",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16",
"IPv6Address": ""
},
"f2870c98fd504370fb86e59f32cd0753b1ac9b69b7d80566ffc7192a82b3ed27": {
"Name": "container1",
"EndpointID": "a00676d9c91a96bbe5bcfb34f705387a33d7cc365bac1a29e4e9728df92d10ad",
"MacAddress": "02:42:ac:11:00:01",
"IPv4Address": "172.17.0.1/16",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
}
}
]
```
Returns the information about the user-defined network:
```bash
$ docker network create simple-network
69568e6336d8c96bbf57869030919f7c69524f71183b44d80948bd3927c87f6a
$ docker network inspect simple-network
[
{
"Name": "simple-network",
"Id": "69568e6336d8c96bbf57869030919f7c69524f71183b44d80948bd3927c87f6a",
"Scope": "local",
"Driver": "bridge",
"IPAM": {
"Driver": "default",
"Config": [
{
"Subnet": "172.22.0.0/16",
"Gateway": "172.22.0.1"
}
]
},
"Containers": {},
"Options": {}
}
]
```
`docker network inspect --verbose` for swarm mode overlay networks shows service-specific
details such as the service's VIP and port mappings. It also shows IPs of service tasks,
and the IPs of the nodes where the tasks are running.
Following is an example output for an overlay network `ov1` that has one service `s1`
attached to. service `s1` in this case has three replicas.
```bash
$ docker network inspect --verbose ov1
[
{
"Name": "ov1",
"Id": "ybmyjvao9vtzy3oorxbssj13b",
"Created": "2017-03-13T17:04:39.776106792Z",
"Scope": "swarm",
"Driver": "overlay",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "10.0.0.0/24",
"Gateway": "10.0.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"Containers": {
"020403bd88a15f60747fd25d1ad5fa1272eb740e8a97fc547d8ad07b2f721c5e": {
"Name": "s1.1.pjn2ik0sfgkfzed3h0s00gs9o",
"EndpointID": "ad16946f416562d658f3bb30b9830d73ad91ccf6feae44411269cd0ff674714e",
"MacAddress": "02:42:0a:00:00:04",
"IPv4Address": "10.0.0.4/24",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.driver.overlay.vxlanid_list": "4097"
},
"Labels": {},
"Peers": [
{
"Name": "net-3-5d3cfd30a58c",
"IP": "192.168.33.13"
},
{
"Name": "net-1-6ecbc0040a73",
"IP": "192.168.33.11"
},
{
"Name": "net-2-fb80208efd75",
"IP": "192.168.33.12"
}
],
"Services": {
"s1": {
"VIP": "10.0.0.2",
"Ports": [],
"LocalLBIndex": 257,
"Tasks": [
{
"Name": "s1.2.q4hcq2aiiml25ubtrtg4q1txt",
"EndpointID": "040879b027e55fb658e8b60ae3b87c6cdac7d291e86a190a3b5ac6567b26511a",
"EndpointIP": "10.0.0.5",
"Info": {
"Host IP": "192.168.33.11"
}
},
{
"Name": "s1.3.yawl4cgkp7imkfx469kn9j6lm",
"EndpointID": "106edff9f120efe44068b834e1cddb5b39dd4a3af70211378b2f7a9e562bbad8",
"EndpointIP": "10.0.0.3",
"Info": {
"Host IP": "192.168.33.12"
}
},
{
"Name": "s1.1.pjn2ik0sfgkfzed3h0s00gs9o",
"EndpointID": "ad16946f416562d658f3bb30b9830d73ad91ccf6feae44411269cd0ff674714e",
"EndpointIP": "10.0.0.4",
"Info": {
"Host IP": "192.168.33.13"
}
}
]
}
}
}
]
```

182
vendor/github.com/docker/docker-ce/components/cli/man/src/network/ls.md generated vendored Normal file
View file

@ -0,0 +1,182 @@
Lists all the networks the Engine `daemon` knows about. This includes the
networks that span across multiple hosts in a cluster, for example:
```bash
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
7fca4eb8c647 bridge bridge local
9f904ee27bf5 none null local
cf03ee007fb4 host host local
78b03ee04fc4 multi-host overlay swarm
```
Use the `--no-trunc` option to display the full network id:
```bash
$ docker network ls --no-trunc
NETWORK ID NAME DRIVER
18a2866682b85619a026c81b98a5e375bd33e1b0936a26cc497c283d27bae9b3 none null
c288470c46f6c8949c5f7e5099b5b7947b07eabe8d9a27d79a9cbf111adcbf47 host host
7b369448dccbf865d397c8d2be0cda7cf7edc6b0945f77d2529912ae917a0185 bridge bridge
95e74588f40db048e86320c6526440c504650a1ff3e9f7d60a497c4d2163e5bd foo bridge
63d1ff1f77b07ca51070a8c227e962238358bd310bde1529cf62e6c307ade161 dev bridge
```
## Filtering
The filtering flag (`-f` or `--filter`) format is a `key=value` pair. If there
is more than one filter, then pass multiple flags (e.g. `--filter "foo=bar" --filter "bif=baz"`).
Multiple filter flags are combined as an `OR` filter. For example,
`-f type=custom -f type=builtin` returns both `custom` and `builtin` networks.
The currently supported filters are:
* driver
* id (network's id)
* label (`label=<key>` or `label=<key>=<value>`)
* name (network's name)
* scope (`swarm|global|local`)
* type (custom|builtin)
#### Driver
The `driver` filter matches networks based on their driver.
The following example matches networks with the `bridge` driver:
```bash
$ docker network ls --filter driver=bridge
NETWORK ID NAME DRIVER
db9db329f835 test1 bridge
f6e212da9dfd test2 bridge
```
#### ID
The `id` filter matches on all or part of a network's ID.
The following filter matches all networks with an ID containing the
`63d1ff1f77b0...` string.
```bash
$ docker network ls --filter id=63d1ff1f77b07ca51070a8c227e962238358bd310bde1529cf62e6c307ade161
NETWORK ID NAME DRIVER
63d1ff1f77b0 dev bridge
```
You can also filter for a substring in an ID as this shows:
```bash
$ docker network ls --filter id=95e74588f40d
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
$ docker network ls --filter id=95e
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
```
#### Label
The `label` filter matches networks based on the presence of a `label` alone or a `label` and a
value.
The following filter matches networks with the `usage` label regardless of its value.
```bash
$ docker network ls -f "label=usage"
NETWORK ID NAME DRIVER
db9db329f835 test1 bridge
f6e212da9dfd test2 bridge
```
The following filter matches networks with the `usage` label with the `prod` value.
```bash
$ docker network ls -f "label=usage=prod"
NETWORK ID NAME DRIVER
f6e212da9dfd test2 bridge
```
#### Name
The `name` filter matches on all or part of a network's name.
The following filter matches all networks with a name containing the `foobar` string.
```bash
$ docker network ls --filter name=foobar
NETWORK ID NAME DRIVER
06e7eef0a170 foobar bridge
```
You can also filter for a substring in a name as this shows:
```bash
$ docker network ls --filter name=foo
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
06e7eef0a170 foobar bridge
```
#### Scope
The `scope` filter matches networks based on their scope.
The following example matches networks with the `swarm` scope:
```bash
$ docker network ls --filter scope=swarm
NETWORK ID NAME DRIVER SCOPE
xbtm0v4f1lfh ingress overlay swarm
ic6r88twuu92 swarmnet overlay swarm
```
The following example matches networks with the `local` scope:
```bash
$ docker network ls --filter scope=local
NETWORK ID NAME DRIVER SCOPE
e85227439ac7 bridge bridge local
0ca0e19443ed host host local
ca13cc149a36 localnet bridge local
f9e115d2de35 none null local
```
#### Type
The `type` filter supports two values; `builtin` displays predefined networks
(`bridge`, `none`, `host`), whereas `custom` displays user defined networks.
The following filter matches all user defined networks:
```bash
$ docker network ls --filter type=custom
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
63d1ff1f77b0 dev bridge
```
By having this flag it allows for batch cleanup. For example, use this filter
to delete all user defined networks:
```bash
$ docker network rm `docker network ls --filter type=custom -q`
```
A warning will be issued when trying to remove a network that has containers
attached.
## Format
Format uses a Go template to print the output. The following variables are
supported:
* .ID - Network ID
* .Name - Network name
* .Driver - Network driver
* .Scope - Network scope (local, global)
* .IPv6 - Whether IPv6 is enabled on the network or not
* .Internal - Whether the network is internal or not
* .Labels - All labels assigned to the network
* .Label - Value of a specific label for this network. For example `{{.Label "project.version"}}`

20
vendor/github.com/docker/docker-ce/components/cli/man/src/network/rm.md generated vendored Normal file
View file

@ -0,0 +1,20 @@
Removes one or more networks by name or identifier. To remove a network,
you must first disconnect any containers connected to it.
To remove the network named 'my-network':
```bash
$ docker network rm my-network
```
To delete multiple networks in a single `docker network rm` command, provide
multiple network names or ids. The following example deletes a network with id
`3695c422697f` and a network named `my-network`:
```bash
$ docker network rm 3695c422697f my-network
```
When you specify multiple networks, the command attempts to delete each in turn.
If the deletion of one network fails, the command continues to the next on the
list and tries to delete that. The command reports success or failure for each
deletion.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/pause.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container pause`.

43
vendor/github.com/docker/docker-ce/components/cli/man/src/plugin/ls.md generated vendored Normal file
View file

@ -0,0 +1,43 @@
Lists all the plugins that are currently installed. You can install plugins
using the `docker plugin install` command.
You can also filter using the `-f` or `--filter` flag.
## Filters
Filter output based on these conditions:
- enabled=(true|false) - plugins that are enabled or not
- capability=<string> - filters plugins based on capabilities (currently `volumedriver`, `networkdriver`, `ipamdriver`, or `authz`)
## Format
Pretty-print plugins using a Go template.
Valid placeholders:
.ID - Plugin ID.
.Name - Plugin Name.
.Description - Plugin description.
.Enabled - Whether plugin is enabled or not.
# EXAMPLES
## Display all plugins
$ docker plugin ls
ID NAME DESCRIPTION ENABLED
869080b57404 tiborvass/sample-volume-plugin:latest A sample volume plugin for Docker true
141bf6c02ddd vieux/sshfs:latest sshFS plugin for Docker false
## Display plugins with their ID and names
$ docker plugin ls --format "{{.ID}}: {{.Name}}"
869080b57404: tiborvass/sample-volume-plugin:latest
## Display enabled plugins
$ docker plugin ls --filter enabled=true
ID NAME DESCRIPTION ENABLED
869080b57404 tiborvass/sample-volume-plugin:latest A sample volume plugin for Docker true
## Display plugins with `volumedriver` capability
$ docker plugin ls --filter capability=volumedriver --format "table {{.ID}}\t{{.Name}}"
ID Name
869080b57404 tiborvass/sample-volume-plugin:latest

1
vendor/github.com/docker/docker-ce/components/cli/man/src/port.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container port`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/ps.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container ls`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/pull.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker image pull`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/push.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker image push`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/rename.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container rename`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/restart.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container restart`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/rm.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container rm`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/rmi.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker image rm`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/save.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker image save`.

36
vendor/github.com/docker/docker-ce/components/cli/man/src/search.md generated vendored Normal file
View file

@ -0,0 +1,36 @@
Search Docker Hub for images that match the specified `TERM`. The table
of images returned displays the name, description (truncated by default), number
of stars awarded, whether the image is official, and whether it is automated.
*Note* - Search queries will only return up to 25 results
## Filter
Filter output based on these conditions:
- stars=<numberOfStar>
- is-automated=(true|false)
- is-official=(true|false)
# EXAMPLES
## Search Docker Hub for ranked images
Search a registry for the term 'fedora' and only display those images
ranked 3 or higher:
$ docker search --filter=stars=3 fedora
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
mattdm/fedora A basic Fedora image corresponding roughly... 50
fedora (Semi) Official Fedora base image. 38
mattdm/fedora-small A small Fedora image on which to build. Co... 8
goldmann/wildfly A WildFly application server running on a ... 3 [OK]
## Search Docker Hub for automated images
Search Docker Hub for the term 'fedora' and only display automated images
ranked 1 or higher:
$ docker search --filter=is-automated=true --filter=stars=1 fedora
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
goldmann/wildfly A WildFly application server running on a ... 3 [OK]
tutum/fedora-20 Fedora 20 image with SSH access. For the r... 1 [OK]

1
vendor/github.com/docker/docker-ce/components/cli/man/src/start.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container start`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/stats.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container stats`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/stop.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container stop`.

134
vendor/github.com/docker/docker-ce/components/cli/man/src/system/events.md generated vendored Normal file
View file

@ -0,0 +1,134 @@
Get event information from the Docker daemon. Information can include historical
information and real-time information.
Docker containers will report the following events:
attach, commit, copy, create, destroy, detach, die, exec_create, exec_detach, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause, update
Docker images report the following events:
delete, import, load, pull, push, save, tag, untag
Docker volumes report the following events:
create, mount, unmount, destroy
Docker networks report the following events:
create, connect, disconnect, destroy
# OPTIONS
The `--since` and `--until` parameters can be Unix timestamps, date formatted
timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed
relative to the client machine's time. If you do not provide the `--since` option,
the command returns only new and/or live events. Supported formats for date
formatted time stamps include RFC3339Nano, RFC3339, `2006-01-02T15:04:05`,
`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local
timezone on the client will be used if you do not provide either a `Z` or a
`+-00:00` timezone offset at the end of the timestamp. When providing Unix
timestamps enter seconds[.nanoseconds], where seconds is the number of seconds
that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap
seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a
fraction of a second no more than nine digits long.
# EXAMPLES
## Listening for Docker events
After running docker events a container 786d698004576 is started and stopped
(The container name has been shortened in the output below):
# docker events
2015-01-28T20:21:31.000000000-08:00 59211849bc10: (from whenry/testimage:latest) start
2015-01-28T20:21:31.000000000-08:00 59211849bc10: (from whenry/testimage:latest) die
2015-01-28T20:21:32.000000000-08:00 59211849bc10: (from whenry/testimage:latest) stop
## Listening for events since a given date
Again the output container IDs have been shortened for the purposes of this document:
# docker events --since '2015-01-28'
2015-01-28T20:25:38.000000000-08:00 c21f6c22ba27: (from whenry/testimage:latest) create
2015-01-28T20:25:38.000000000-08:00 c21f6c22ba27: (from whenry/testimage:latest) start
2015-01-28T20:25:39.000000000-08:00 c21f6c22ba27: (from whenry/testimage:latest) create
2015-01-28T20:25:39.000000000-08:00 c21f6c22ba27: (from whenry/testimage:latest) start
2015-01-28T20:25:40.000000000-08:00 c21f6c22ba27: (from whenry/testimage:latest) die
2015-01-28T20:25:42.000000000-08:00 c21f6c22ba27: (from whenry/testimage:latest) stop
2015-01-28T20:25:45.000000000-08:00 c21f6c22ba27: (from whenry/testimage:latest) start
2015-01-28T20:25:45.000000000-08:00 c21f6c22ba27: (from whenry/testimage:latest) die
2015-01-28T20:25:46.000000000-08:00 c21f6c22ba27: (from whenry/testimage:latest) stop
The following example outputs all events that were generated in the last 3 minutes,
relative to the current time on the client machine:
# docker events --since '3m'
2015-05-12T11:51:30.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
2015-05-12T15:52:12.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
2015-05-12T15:53:45.999999999Z07:00 7805c1d35632: (from redis:2.8) die
2015-05-12T15:54:03.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
If you do not provide the --since option, the command returns only new and/or
live events.
## Format
If a format (`--format`) is specified, the given template will be executed
instead of the default format. Go's **text/template** package describes all the
details of the format.
# docker events --filter 'type=container' --format 'Type={{.Type}} Status={{.Status}} ID={{.ID}}'
Type=container Status=create ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=attach ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=start ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=resize ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=die ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
Type=container Status=destroy ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299c126a87812311951e26
If a format is set to `{{json .}}`, the events are streamed as valid JSON
Lines. For information about JSON Lines, please refer to http://jsonlines.org/ .
# docker events --format '{{json .}}'
{"status":"create","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
{"status":"attach","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
{"Type":"network","Action":"connect","Actor":{"ID":"1b50a5bf755f6021dfa78e..
{"status":"start","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f42..
{"status":"resize","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
## Filters
$ docker events --filter 'event=stop'
2014-05-10T17:42:14.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2014-09-03T17:42:14.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
$ docker events --filter 'image=ubuntu-1:14.04'
2014-05-10T17:42:14.999999999Z07:00 container start 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
$ docker events --filter 'container=7805c1d35632'
2014-05-10T17:42:14.999999999Z07:00 container die 7805c1d35632 (image=redis:2.8)
2014-09-03T15:49:29.999999999Z07:00 container stop 7805c1d35632 (image= redis:2.8)
$ docker events --filter 'container=7805c1d35632' --filter 'container=4386fb97867d'
2014-09-03T15:49:29.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container die 7805c1d35632 (image=redis:2.8)
2014-09-03T15:49:29.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
$ docker events --filter 'container=7805c1d35632' --filter 'event=stop'
2014-09-03T15:49:29.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
$ docker events --filter 'type=volume'
2015-12-23T21:05:28.136212689Z volume create test-event-volume-local (driver=local)
2015-12-23T21:05:28.383462717Z volume mount test-event-volume-local (read/write=true, container=562fe10671e9273da25eed36cdce26159085ac7ee6707105fd534866340a5025, destination=/foo, driver=local, propagation=rprivate)
2015-12-23T21:05:28.650314265Z volume unmount test-event-volume-local (container=562fe10671e9273da25eed36cdce26159085ac7ee6707105fd534866340a5025, driver=local)
2015-12-23T21:05:28.716218405Z volume destroy test-event-volume-local (driver=local)
$ docker events --filter 'type=network'
2015-12-23T21:38:24.705709133Z network create 8b111217944ba0ba844a65b13efcd57dc494932ee2527577758f939315ba2c5b (name=test-event-network-local, type=bridge)
2015-12-23T21:38:25.119625123Z network connect 8b111217944ba0ba844a65b13efcd57dc494932ee2527577758f939315ba2c5b (name=test-event-network-local, container=b4be644031a3d90b400f88ab3d4bdf4dc23adb250e696b6328b85441abe2c54e, type=bridge)
$ docker events --filter 'type=plugin' (experimental)
2016-07-25T17:30:14.825557616Z plugin pull ec7b87f2ce84330fe076e666f17dfc049d2d7ae0b8190763de94e1f2d105993f (name=tiborvass/sample-volume-plugin:latest)
2016-07-25T17:30:14.888127370Z plugin enable ec7b87f2ce84330fe076e666f17dfc049d2d7ae0b8190763de94e1f2d105993f (name=tiborvass/sample-volume-plugin:latest)

163
vendor/github.com/docker/docker-ce/components/cli/man/src/system/info.md generated vendored Normal file
View file

@ -0,0 +1,163 @@
This command displays system wide information regarding the Docker installation.
Information displayed includes the kernel version, number of containers and images.
The number of images shown is the number of unique images. The same image tagged
under different names is counted only once.
If a format is specified, the given template will be executed instead of the
default format. Go's **text/template** package
describes all the details of the format.
Depending on the storage driver in use, additional information can be shown, such
as pool name, data file, metadata file, data space used, total data space, metadata
space used, and total metadata space.
The data file is where the images are stored and the metadata file is where the
meta data regarding those images are stored. When run for the first time Docker
allocates a certain amount of data space and meta data space from the space
available on the volume where `/var/lib/docker` is mounted.
# EXAMPLES
## Display Docker system information
Here is a sample output for a daemon running on Ubuntu, using the overlay2
storage driver:
$ docker -D info
Containers: 14
Running: 3
Paused: 1
Stopped: 10
Images: 52
Server Version: 1.13.0
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: active
NodeID: rdjq45w1op418waxlairloqbm
Is Manager: true
ClusterID: te8kdyw33n36fqiz74bfjeixd
Managers: 1
Nodes: 2
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Number of Old Snapshots to Retain: 0
Heartbeat Tick: 1
Election Tick: 3
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Node Address: 172.16.66.128 172.16.66.129
Manager Addresses:
172.16.66.128:2477
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 8517738ba4b82aff5662c97ca4627e7e4d03b531
runc version: ac031b5bf1cc92239461125f4c1ffb760522bbf2
init version: N/A (expected: v0.13.0)
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-31-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.937 GiB
Name: ubuntu
ID: H52R:7ZR6:EIIA:76JG:ORIY:BVKF:GSFU:HNPG:B5MK:APSC:SZ3Q:N326
Docker Root Dir: /var/lib/docker
Debug Mode (client): true
Debug Mode (server): true
File Descriptors: 30
Goroutines: 123
System Time: 2016-11-12T17:24:37.955404361-08:00
EventsListeners: 0
Http Proxy: http://test:test@proxy.example.com:8080
Https Proxy: https://test:test@proxy.example.com:8080
No Proxy: localhost,127.0.0.1,docker-registry.somecorporation.com
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
storage=ssd
staging=true
Experimental: false
Insecure Registries:
127.0.0.0/8
Registry Mirrors:
http://192.168.1.2/
http://registry-mirror.example.com:5000/
Live Restore Enabled: false
The global `-D` option tells all `docker` commands to output debug information.
The example below shows the output for a daemon running on Red Hat Enterprise Linux,
using the devicemapper storage driver. As can be seen in the output, additional
information about the devicemapper storage driver is shown:
$ docker info
Containers: 14
Running: 3
Paused: 1
Stopped: 10
Untagged Images: 52
Server Version: 1.10.3
Storage Driver: devicemapper
Pool Name: docker-202:2-25583803-pool
Pool Blocksize: 65.54 kB
Base Device Size: 10.74 GB
Backing Filesystem: xfs
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 1.68 GB
Data Space Total: 107.4 GB
Data Space Available: 7.548 GB
Metadata Space Used: 2.322 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.145 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
Library Version: 1.02.107-RHEL7 (2015-12-01)
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
Volume: local
Network: null host bridge
Kernel Version: 3.10.0-327.el7.x86_64
Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 991.7 MiB
Name: ip-172-30-0-91.ec2.internal
ID: I54V:OLXT:HVMM:TPKO:JPHQ:CQCD:JNLC:O3BZ:4ZVJ:43XJ:PFHZ:6N2S
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Username: gordontheturtle
Registry: https://index.docker.io/v1/
Insecure registries:
myinsecurehost:5000
127.0.0.0/8
You can also specify the output format:
$ docker info --format '{{json .}}'
{"ID":"I54V:OLXT:HVMM:TPKO:JPHQ:CQCD:JNLC:O3BZ:4ZVJ:43XJ:PFHZ:6N2S","Containers":14, ...}

1
vendor/github.com/docker/docker-ce/components/cli/man/src/tag.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker image tag`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/top.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container top`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/unpause.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container unpause`.

1
vendor/github.com/docker/docker-ce/components/cli/man/src/update.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container update`.

37
vendor/github.com/docker/docker-ce/components/cli/man/src/version.md generated vendored Normal file
View file

@ -0,0 +1,37 @@
This command displays version information for both the Docker client and
daemon.
# EXAMPLES
## Display Docker version information
The default output:
$ docker version
Client:
Version: 1.8.0
API version: 1.20
Go version: go1.4.2
Git commit: f5bae0a
Built: Tue Jun 23 17:56:00 UTC 2015
OS/Arch: linux/amd64
Server:
Version: 1.8.0
API version: 1.20
Go version: go1.4.2
Git commit: f5bae0a
Built: Tue Jun 23 17:56:00 UTC 2015
OS/Arch: linux/amd64
Get server version:
$ docker version --format '{{.Server.Version}}'
1.8.0
Dump raw data:
To view all available fields, you can use the format `{{json .}}`.
$ docker version --format '{{json .}}'
{"Client":{"Version":"1.8.0","ApiVersion":"1.20","GitCommit":"f5bae0a","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","BuildTime":"Tue Jun 23 17:56:00 UTC 2015"},"ServerOK":true,"Server":{"Version":"1.8.0","ApiVersion":"1.20","GitCommit":"f5bae0a","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","KernelVersion":"3.13.2-gentoo","BuildTime":"Tue Jun 23 17:56:00 UTC 2015"}}

14
vendor/github.com/docker/docker-ce/components/cli/man/src/volume.md generated vendored Normal file
View file

@ -0,0 +1,14 @@
The `docker volume` command has subcommands for managing data volumes. A data
volume is a specially-designated directory that by-passes storage driver
management.
Data volumes persist data independent of a container's life cycle. When you
delete a container, the Docker daemon does not delete any data volumes. You can
share volumes across multiple containers. Moreover, you can share data volumes
with other computing resources in your system.
To see help for a subcommand, use:
docker volume COMMAND --help
For full details on using docker volume visit Docker's online documentation.

35
vendor/github.com/docker/docker-ce/components/cli/man/src/volume/create.md generated vendored Normal file
View file

@ -0,0 +1,35 @@
Creates a new volume that containers can consume and store data in. If a name
is not specified, Docker generates a random name. You create a volume and then
configure the container to use it, for example:
$ docker volume create hello
hello
$ docker run -d -v hello:/world busybox ls /world
The mount is created inside the container's `/src` directory. Docker doesn't
not support relative paths for mount points inside the container.
Multiple containers can use the same volume in the same time period. This is
useful if two containers need access to shared data. For example, if one
container writes and the other reads the data.
## Driver specific options
Some volume drivers may take options to customize the volume creation. Use the
`-o` or `--opt` flags to pass driver options:
$ docker volume create --driver fake --opt tardis=blue --opt timey=wimey
These options are passed directly to the volume driver. Options for different
volume drivers may do different things (or nothing at all).
The built-in `local` driver on Windows does not support any options.
The built-in `local` driver on Linux accepts options similar to the linux
`mount` command:
$ docker volume create --driver local --opt type=tmpfs --opt device=tmpfs --opt o=size=100m,uid=1000
Another example:
$ docker volume create --driver local --opt type=btrfs --opt device=/dev/sda2

4
vendor/github.com/docker/docker-ce/components/cli/man/src/volume/inspect.md generated vendored Normal file
View file

@ -0,0 +1,4 @@
Returns information about one or more volumes. By default, this command renders
all results in a JSON array. You can specify an alternate format to execute a
given template is executed for each result. Go's https://golang.org/pkg/text/template/
package describes all the details of the format.

11
vendor/github.com/docker/docker-ce/components/cli/man/src/volume/ls.md generated vendored Normal file
View file

@ -0,0 +1,11 @@
Lists all the volumes Docker manages. You can filter using the `-f` or
`--filter` flag. The filtering format is a `key=value` pair. To specify
more than one filter, pass multiple flags (for example,
`--filter "foo=bar" --filter "bif=baz"`)
The currently supported filters are:
* `dangling` (boolean - `true` or `false`, `1` or `0`)
* `driver` (a volume driver's name)
* `label` (`label=<key>` or `label=<key>=<value>`)
* `name` (a volume's name)

1
vendor/github.com/docker/docker-ce/components/cli/man/src/wait.md generated vendored Normal file
View file

@ -0,0 +1 @@
Alias for `docker container wait`.