d8dfun/virtual-kubelet
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Ria Bhatia
2017-12-04 13:32:57 -06:00
committed by Erik St. Martin
commit 0075e5b0f3
9056 changed files with 2523100 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
vendor/github.com/hyperhq/hypercli/man/Dockerfile generated vendored Normal file
View File

@@ -0,0 +1,7 @@
FROM golang:1.4
RUN mkdir -p /go/src/github.com/cpuguy83
RUN mkdir -p /go/src/github.com/cpuguy83 \
&& git clone -b v1.0.3 https://github.com/cpuguy83/go-md2man.git /go/src/github.com/cpuguy83/go-md2man \
&& cd /go/src/github.com/cpuguy83/go-md2man \
&& go get -v ./...
CMD ["/go/bin/go-md2man", "--help"]

472
vendor/github.com/hyperhq/hypercli/man/Dockerfile.5.md generated vendored Normal file
View File

@@ -0,0 +1,472 @@
% 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 an error.
```
One or more build-args were not consumed, failing build.
```
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.
> **Note:** It is not recommended to use build-time variables for
> passing secrets like github keys, user credentials etc.
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)

33
vendor/github.com/hyperhq/hypercli/man/README.md generated vendored Normal file
View File

@@ -0,0 +1,33 @@
Docker Documentation
====================
This directory contains the Docker user manual in the Markdown format.
Do *not* edit the man pages in the man1 directory. Instead, amend the
Markdown (*.md) files.
# Generating man pages from the Markdown files
The recommended approach for generating the man pages is via a Docker
container using the supplied `Dockerfile` to create an image with the correct
environment. This uses `go-md2man`, a pure Go Markdown to man page generator.
## Building the md2man image
There is a `Dockerfile` provided in the `/man` directory of your
'docker/docker' fork.
Using this `Dockerfile`, create a Docker image tagged `docker/md2man`:
docker build -t docker/md2man .
## Utilizing the image
From within the `/man` directory run the following command:
docker run -v $(pwd):/man -w /man -i docker/md2man ./md2man-all.sh
The `md2man` Docker container will process the Markdown files and generate
the man pages inside the `/man/man1` directory of your fork using
Docker volumes. For more information on Docker volumes see the man page for
`docker run` and also look at the article [Sharing Directories via Volumes]
(https://docs.docker.com/use/working_with_volumes/).

72
vendor/github.com/hyperhq/hypercli/man/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/confg.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>

99
vendor/github.com/hyperhq/hypercli/man/docker-attach.1.md generated vendored Normal file
View File

@@ -0,0 +1,99 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-attach - Attach to a running container
# SYNOPSIS
**docker attach**
[**--detach-keys**[=*[]*]]
[**--help**]
[**--no-stdin**]
[**--sig-proxy**[=*true*]]
CONTAINER
# DESCRIPTION
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`).
# OPTIONS
**--detach-keys**=""
Override the key sequence for detaching a container. Format is a single character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
**--help**
Print usage statement
**--no-stdin**=*true*|*false*
Do not attach STDIN. The default is *false*.
**--sig-proxy**=*true*|*false*
Proxy all received signals to the process (non-TTY mode only). SIGCHLD, SIGKILL, and SIGSTOP are not proxied. The default is *true*.
# Override the detach sequence
If you want, you can configure a override the Docker key sequence for detach.
This is is useful if the Docker default sequence conflicts with key squence you
use for other applications. There are two ways to defines a 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 )
* `@` (ampersand)
* `[` (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
# HISTORY
April 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>

307
vendor/github.com/hyperhq/hypercli/man/docker-build.1.md generated vendored Normal file
View File

@@ -0,0 +1,307 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-build - Build a new image from the source code at PATH
# SYNOPSIS
**docker build**
[**--build-arg**[=*[]*]]
[**--cpu-shares**[=*0*]]
[**--cgroup-parent**[=*CGROUP-PARENT*]]
[**--help**]
[**-f**|**--file**[=*PATH/Dockerfile*]]
[**--force-rm**]
[**--isolation**[=*default*]]
[**--no-cache**]
[**--pull**]
[**-q**|**--quiet**]
[**--rm**[=*true*]]
[**-t**|**--tag**[=*[]*]]
[**-m**|**--memory**[=*MEMORY*]]
[**--memory-swap**[=*LIMIT*]]
[**--shm-size**[=*SHM-SIZE*]]
[**--cpu-period**[=*0*]]
[**--cpu-quota**[=*0*]]
[**--cpuset-cpus**[=*CPUSET-CPUS*]]
[**--cpuset-mems**[=*CPUSET-MEMS*]]
[**--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*.
**--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](/reference/builder/#arg)
**--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.
**--no-cache**=*true*|*false*
Do not use cache when building the image. The default is *false*.
**--help**
Print usage statement
**--pull**=*true*|*false*
Always attempt to pull a newer version of the image. 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.
**-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.
**--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.
**--ulimit**=[]
Ulimit options
For more information about `ulimit` see [Setting ulimits in a
container](https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container)
# 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://` schema.
## 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>

70
vendor/github.com/hyperhq/hypercli/man/docker-commit.1.md generated vendored Normal file
View File

@@ -0,0 +1,70 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-commit - Create a new image from a container's changes
# SYNOPSIS
**docker commit**
[**-a**|**--author**[=*AUTHOR*]]
[**-c**|**--change**[=\[*DOCKERFILE INSTRUCTIONS*\]]]
[**--help**]
[**-m**|**--message**[=*MESSAGE*]]
[**-p**|**--pause**[=*true*]]
CONTAINER [REPOSITORY[:TAG]]
# DESCRIPTION
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.
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.
# OPTIONS
**-a**, **--author**=""
Author (e.g., "John Hannibal Smith <hannibal@a-team.com>")
**-c** , **--change**=[]
Apply specified Dockerfile instructions while committing the image
Supported Dockerfile instructions: `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`LABEL`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
**--help**
Print usage statement
**-m**, **--message**=""
Commit message
**-p**, **--pause**=*true*|*false*
Pause container during commit. The default is *true*.
# 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 commit -c="ENV DEBUG true" 98bd7fc99854 debug-image
# HISTORY
April 2014, Originally compiled by William Henry (whenry at redhat dot com)
based on docker.com source material and in
June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
July 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
Oct 2014, updated by Daniel, Dao Quang Minh <daniel at nitrous dot io>
June 2015, updated by Sally O'Malley <somalley@redhat.com>

165
vendor/github.com/hyperhq/hypercli/man/docker-cp.1.md generated vendored Normal file
View File

@@ -0,0 +1,165 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-cp - Copy files/folders between a container and the local filesystem.
# SYNOPSIS
**docker cp**
[**--help**]
CONTAINER:SRC_PATH DEST_PATH|-
**docker cp**
[**--help**]
SRC_PATH|- CONTAINER:DEST_PATH
# DESCRIPTION
The `docker 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` be a file or directory.
The `docker 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 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 cp`
command. If you specify the `-L` option, `docker cp` follows any symbolic link
in the `SRC_PATH`.
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 `/.`
- the source directory is copied into this directory
- `SRC_PATH` does end with `/.`
- 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`, and mounts created by the user in the container.
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
`DEST_PATH` streams the contents of the resource as a tar archive to `STDOUT`.
# OPTIONS
**-L**, **--follow-link**=*true*|*false*
Follow symbol link in SRC_PATH
**--help**
Print usage statement
# 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 cp` in your `~`
(home) directory on the local host:
$ docker 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 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 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 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 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 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 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.
# HISTORY
April 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>
May 2015, updated by Josh Hawn <josh.hawn@docker.com>

448
vendor/github.com/hyperhq/hypercli/man/docker-create.1.md generated vendored Normal file
View File

@@ -0,0 +1,448 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-create - Create a new container
# SYNOPSIS
**docker create**
[**-a**|**--attach**[=*[]*]]
[**--add-host**[=*[]*]]
[**--blkio-weight**[=*[BLKIO-WEIGHT]*]]
[**--blkio-weight-device**[=*[]*]]
[**--cpu-shares**[=*0*]]
[**--cap-add**[=*[]*]]
[**--cap-drop**[=*[]*]]
[**--cgroup-parent**[=*CGROUP-PATH*]]
[**--cidfile**[=*CIDFILE*]]
[**--cpu-period**[=*0*]]
[**--cpu-quota**[=*0*]]
[**--cpuset-cpus**[=*CPUSET-CPUS*]]
[**--cpuset-mems**[=*CPUSET-MEMS*]]
[**--device**[=*[]*]]
[**--device-read-bps**[=*[]*]]
[**--device-read-iops**[=*[]*]]
[**--device-write-bps**[=*[]*]]
[**--device-write-iops**[=*[]*]]
[**--dns**[=*[]*]]
[**--dns-search**[=*[]*]]
[**--dns-opt**[=*[]*]]
[**-e**|**--env**[=*[]*]]
[**--entrypoint**[=*ENTRYPOINT*]]
[**--env-file**[=*[]*]]
[**--expose**[=*[]*]]
[**--group-add**[=*[]*]]
[**-h**|**--hostname**[=*HOSTNAME*]]
[**--help**]
[**-i**|**--interactive**]
[**--ip**[=*IPv4-ADDRESS*]]
[**--ip6**[=*IPv6-ADDRESS*]]
[**--ipc**[=*IPC*]]
[**--isolation**[=*default*]]
[**--kernel-memory**[=*KERNEL-MEMORY*]]
[**-l**|**--label**[=*[]*]]
[**--label-file**[=*[]*]]
[**--link**[=*[]*]]
[**--log-driver**[=*[]*]]
[**--log-opt**[=*[]*]]
[**-m**|**--memory**[=*MEMORY*]]
[**--mac-address**[=*MAC-ADDRESS*]]
[**--memory-reservation**[=*MEMORY-RESERVATION*]]
[**--memory-swap**[=*LIMIT*]]
[**--memory-swappiness**[=*MEMORY-SWAPPINESS*]]
[**--name**[=*NAME*]]
[**--net**[=*"bridge"*]]
[**--net-alias**[=*[]*]]
[**--oom-kill-disable**]
[**--oom-score-adj**[=*0*]]
[**-P**|**--publish-all**]
[**-p**|**--publish**[=*[]*]]
[**--pid**[=*[]*]]
[**--privileged**]
[**--read-only**]
[**--restart**[=*RESTART*]]
[**--security-opt**[=*[]*]]
[**--stop-signal**[=*SIGNAL*]]
[**--shm-size**[=*[]*]]
[**-t**|**--tty**]
[**--tmpfs**[=*[CONTAINER-DIR[:<OPTIONS>]*]]
[**-u**|**--user**[=*USER*]]
[**--ulimit**[=*[]*]]
[**--uts**[=*[]*]]
[**-v**|**--volume**[=*[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]*]]
[**--volume-driver**[=*DRIVER*]]
[**--volumes-from**[=*[]*]]
[**-w**|**--workdir**[=*WORKDIR*]]
IMAGE [COMMAND] [ARG...]
# DESCRIPTION
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
**-a**, **--attach**=[]
Attach to STDIN, STDOUT or STDERR.
**--add-host**=[]
Add a custom host-to-IP mapping (host:ip)
**--blkio-weight**=*0*
Block IO weight (relative weight) accepts a weight value between 10 and 1000.
**--blkio-weight-device**=[]
Block IO weight (relative device weight, format: `DEVICE_NAME:WEIGHT`).
**--cpu-shares**=*0*
CPU shares (relative weight)
**--cap-add**=[]
Add Linux capabilities
**--cap-drop**=[]
Drop Linux capabilities
**--cgroup-parent**=""
Path to cgroups under which the cgroup for the container will be created. If the path is not absolute, the path is considered to be relative to the cgroups path of the init process. Cgroups will be created if they do not already exist.
**--cidfile**=""
Write the container ID to the file
**--cpu-period**=*0*
Limit the CPU CFS (Completely Fair Scheduler) period
**--cpuset-cpus**=""
CPUs in which to allow execution (0-3, 0,1)
**--cpuset-mems**=""
Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
If you have four memory nodes on your system (0-3), use `--cpuset-mems=0,1`
then processes in your Docker container will only use memory from the first
two memory nodes.
**--cpu-quota**=*0*
Limit the CPU CFS (Completely Fair Scheduler) quota
**--device**=[]
Add a host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm)
**--device-read-bps**=[]
Limit read rate (bytes per second) from a device (e.g. --device-read-bps=/dev/sda:1mb)
**--device-read-iops**=[]
Limit read rate (IO per second) from a device (e.g. --device-read-iops=/dev/sda:1000)
**--device-write-bps**=[]
Limit write rate (bytes per second) to a device (e.g. --device-write-bps=/dev/sda:1mb)
**--device-write-iops**=[]
Limit write rate (IO per second) to a device (e.g. --device-write-iops=/dev/sda:1000)
**--dns**=[]
Set custom DNS servers
**--dns-opt**=[]
Set custom DNS options
**--dns-search**=[]
Set custom DNS search domains (Use --dns-search=. if you don't wish to set the search domain)
**-e**, **--env**=[]
Set environment variables
**--entrypoint**=""
Overwrite the default ENTRYPOINT of the image
**--env-file**=[]
Read in a line-delimited file of environment variables
**--expose**=[]
Expose a port or a range of ports (e.g. --expose=3300-3310) from the container without publishing it to your host
**--group-add**=[]
Add additional groups to run as
**-h**, **--hostname**=""
Container host name
**--help**
Print usage statement
**-i**, **--interactive**=*true*|*false*
Keep STDIN open even if not attached. The default is *false*.
**--ip**=""
Sets the container's interface IPv4 address (e.g. 172.23.0.9)
It can only be used in conjunction with **--net** for user-defined networks
**--ip6**=""
Sets the container's interface IPv6 address (e.g. 2001:db8::1b99)
It can only be used in conjunction with **--net** for user-defined networks
**--ipc**=""
Default is to create a private IPC namespace (POSIX SysV IPC) for the container
'container:<name|id>': reuses another container shared memory, semaphores and message queues
'host': use the host shared memory,semaphores and message queues inside the container. Note: the host mode gives the container full access to local shared memory and is therefore considered insecure.
**--isolation**="*default*"
Isolation specifies the type of isolation technology used by containers.
**--kernel-memory**=""
Kernel memory limit (format: `<number>[<unit>]`, where unit = b, k, m or g)
Constrains the kernel memory available to a container. If a limit of 0
is specified (not using `--kernel-memory`), the container's kernel memory
is not limited. If you specify a limit, it may be rounded up to a multiple
of the operating system's page size and the value can be very large,
millions of trillions.
**-l**, **--label**=[]
Adds metadata to a container (e.g., --label=com.example.key=value)
**--label-file**=[]
Read labels from a file. Delimit each label with an EOL.
**--link**=[]
Add link to another container in the form of <name or id>:alias or just
<name or id> in which case the alias will match the name.
**--log-driver**="*json-file*|*syslog*|*journald*|*gelf*|*fluentd*|*awslogs*|*splunk*|*none*"
Logging driver for container. Default is defined by daemon `--log-driver` flag.
**Warning**: the `docker logs` command works only for the `json-file` and
`journald` logging drivers.
**--log-opt**=[]
Logging driver specific options.
**-m**, **--memory**=""
Memory limit (format: <number>[<unit>], where unit = b, k, m or g)
Allows you to constrain the memory available to a container. If the host
supports swap memory, then the **-m** memory setting can be larger than physical
RAM. If a limit of 0 is specified (not using **-m**), the container's memory is
not limited. The actual limit may be rounded up to a multiple of the operating
system's page size (the value would be very large, that's millions of trillions).
**--mac-address**=""
Container MAC address (e.g. 92:d0:c6:0a:29:33)
**--memory-reservation**=""
Memory soft limit (format: <number>[<unit>], where unit = b, k, m or g)
After setting memory reservation, when the system detects memory contention
or low memory, containers are forced to restrict their consumption to their
reservation. So you should always set the value below **--memory**, otherwise the
hard limit will take precedence. By default, memory reservation will be the same
as 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.
**--memory-swappiness**=""
Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.
**--name**=""
Assign a name to the container
**--net**="*bridge*"
Set the Network mode for the container
'bridge': create a network stack on the default Docker bridge
'none': no networking
'container:<name|id>': reuse another container's network stack
'host': use the Docker host network stack. Note: the host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.
'<network-name>|<network-id>': connect to a user-defined network
**--net-alias**=[]
Add network-scoped alias for the container
**--oom-kill-disable**=*true*|*false*
Whether to disable OOM Killer for the container or not.
**--oom-score-adj**=""
Tune the host's OOM preferences for containers (accepts -1000 to 1000)
**-P**, **--publish-all**=*true*|*false*
Publish all exposed ports to random ports on the host interfaces. The default is *false*.
**-p**, **--publish**=[]
Publish a container's port, or a range of ports, to the host
format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort
Both hostPort and containerPort can be specified as a range of ports.
When specifying ranges for both, the number of container ports in the range must match the number of host ports in the range. (e.g., `-p 1234-1236:1234-1236/tcp`)
(use 'docker port' to see the actual mapping)
**--pid**=*host*
Set the PID mode for the container
**host**: use the host's PID namespace inside the container.
Note: the host mode gives the container full access to local PID and is therefore considered insecure.
**--privileged**=*true*|*false*
Give extended privileges to this container. The default is *false*.
**--read-only**=*true*|*false*
Mount the container's root filesystem as read only.
**--restart**="*no*"
Restart policy to apply when a container exits (no, on-failure[:max-retry], always, unless-stopped).
**--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`.
**--security-opt**=[]
Security Options
**--stop-signal**=*SIGTERM*
Signal to stop a container. Default is SIGTERM.
**-t**, **--tty**=*true*|*false*
Allocate a pseudo-TTY. The default is *false*.
**--tmpfs**=[] Create a tmpfs mount
Mount a temporary filesystem (`tmpfs`) mount into a container, for example:
$ docker run -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image
This command mounts a `tmpfs` at `/tmp` within the container. The supported mount
options are the same as the Linux default `mount` flags. If you do not specify
any options, the systems uses the following options:
`rw,noexec,nosuid,nodev,size=65536k`.
**-u**, **--user**=""
Username or UID
**--ulimit**=[]
Ulimit options
**--uts**=*host*
Set the UTS mode for the container
**host**: use the host's UTS namespace inside the container.
Note: the host mode gives the container access to changing the host's hostname and is therefore considered insecure.
**-v**|**--volume**[=*[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]*]
Create a bind mount. If you specify, ` -v /HOST-DIR:/CONTAINER-DIR`, Docker
bind mounts `/HOST-DIR` in the host to `/CONTAINER-DIR` in the Docker
container. If 'HOST-DIR' is omitted, Docker automatically creates the new
volume on the host. The `OPTIONS` are a comma delimited list and can be:
* [rw|ro]
* [z|Z]
* [`[r]shared`|`[r]slave`|`[r]private`]
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 add `:ro` or `:rw` suffix to a volume to mount it read-only or
read-write mode, respectively. By default, the volumes are mounted read-write.
See examples.
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 propagaion 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.
**--volume-driver**=""
Container's volume driver. This driver creates volumes specified either from
a Dockerfile's `VOLUME` instruction or from the `docker run -v` flag.
See **docker-volume-create(1)** for full details.
**--volumes-from**=[]
Mount volumes from the specified container(s)
**-w**, **--workdir**=""
Working directory inside the container
# EXAMPLES
## 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
August 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
September 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
November 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

519
vendor/github.com/hyperhq/hypercli/man/docker-daemon.8.md generated vendored Normal file
View File

@@ -0,0 +1,519 @@
% DOCKER(8) Docker User Manuals
% Shishir Mahajan
% SEPTEMBER 2015
# NAME
docker-daemon - Enable daemon mode
# SYNOPSIS
**docker daemon**
[**--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*]]
[**-D**|**--debug**]
[**--default-gateway**[=*DEFAULT-GATEWAY*]]
[**--default-gateway-v6**[=*DEFAULT-GATEWAY-V6*]]
[**--default-ulimit**[=*[]*]]
[**--disable-legacy-registry**]
[**--dns**[=*[]*]]
[**--dns-opt**[=*[]*]]
[**--dns-search**[=*[]*]]
[**--exec-opt**[=*[]*]]
[**--exec-root**[=*/var/run/docker*]]
[**--fixed-cidr**[=*FIXED-CIDR*]]
[**--fixed-cidr-v6**[=*FIXED-CIDR-V6*]]
[**-G**|**--group**[=*docker*]]
[**-g**|**--graph**[=*/var/lib/docker*]]
[**-H**|**--host**[=*[]*]]
[**--help**]
[**--icc**[=*true*]]
[**--insecure-registry**[=*[]*]]
[**--ip**[=*0.0.0.0*]]
[**--ip-forward**[=*true*]]
[**--ip-masq**[=*true*]]
[**--iptables**[=*true*]]
[**--ipv6**]
[**-l**|**--log-level**[=*info*]]
[**--label**[=*[]*]]
[**--log-driver**[=*json-file*]]
[**--log-opt**[=*map[]*]]
[**--mtu**[=*0*]]
[**-p**|**--pidfile**[=*/var/run/docker.pid*]]
[**--raw-logs**]
[**--registry-mirror**[=*[]*]]
[**-s**|**--storage-driver**[=*STORAGE-DRIVER*]]
[**--selinux-enabled**]
[**--storage-opt**[=*[]*]]
[**--tls**]
[**--tlscacert**[=*~/.docker/ca.pem*]]
[**--tlscert**[=*~/.docker/cert.pem*]]
[**--tlskey**[=*~/.docker/key.pem*]]
[**--tlsverify**]
[**--userland-proxy**[=*true*]]
[**--userns-remap**[=*default*]]
# DESCRIPTION
**docker** has two distinct functions. It is used for starting the Docker
daemon and to run the CLI (i.e., to command the daemon to manage images,
containers etc.) So **docker** is both a server, as a daemon, and a client
to the daemon, through the CLI.
To run the Docker daemon you can specify **docker daemon**.
You can check the daemon options using **docker daemon --help**.
Daemon options should be specified after the **daemon** keyword in the following
format.
**docker daemon [OPTIONS]**
# OPTIONS
**--api-cors-header**=""
Set CORS headers in the remote 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.
**-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-ulimit**=[]
Set default ulimits for containers.
**--disable-legacy-registry**=*true*|*false*
Do not contact legacy registries
**--dns**=""
Force Docker to use specific DNS servers
**--dns-opt**=""
DNS options to use.
**--dns-search**=[]
DNS search domains to use.
**--exec-opt**=[]
Set exec driver options. See EXEC DRIVER OPTIONS.
**--exec-root**=""
Path to use as the root of the Docker exec driver. Default is `/var/run/docker`.
**--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`.
**-g**, **--graph**=""
Path to use as the root of the Docker runtime. Default is `/var/lib/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.
**--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".
**-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`)
**--log-driver**="*json-file*|*syslog*|*journald*|*gelf*|*fluentd*|*awslogs*|*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`.
**-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.
**--selinux-enabled**=*true*|*false*
Enable selinux support. Default is false. SELinux does not presently support the overlay storage driver.
**--storage-opt**=[]
Set storage driver options. See STORAGE DRIVER OPTIONS.
**--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.
**--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 only
backend that currently takes options is *devicemapper*. Therefore use these
flags with **-s=**devicemapper.
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.
Here is the list of *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 create snapshot volumes needed for images and
containers.
Managing the thin-pool outside of Docker makes for the most feature-rich method
of having Docker utilize device mapper thin provisioning as the backing storage
for Docker's 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.
Example use: `docker daemon --storage-opt dm.thinpooldev=/dev/mapper/thin-pool`
#### 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: `docker daemon --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: `docker daemon --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: `docker daemon --storage-opt dm.fs=xfs`
#### dm.mkfsarg
Specifies extra mkfs arguments to be used when creating the base device.
Example use: `docker daemon --storage-opt "dm.mkfsarg=-O ^has_journal"`
#### dm.mountopt
Specifies extra mount options used when mounting the thin devices.
Example use: `docker daemon --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: `docker daemon --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.
`docker daemon --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: `docker daemon --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: `docker daemon --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: `docker daemon --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: `docker daemon --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:
$ docker daemon --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.
# 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
docker daemon --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 remote API are allowed or denied by the plugin. If you have
multiple plugins installed, at least one 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.md) section in the
Docker extend section of this documentation.
# HISTORY
Sept 2015, Originally compiled by Shishir Mahajan <shishir.mahajan@redhat.com>
based on docker.com source material and internal work.

49
vendor/github.com/hyperhq/hypercli/man/docker-diff.1.md generated vendored Normal file
View File

@@ -0,0 +1,49 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-diff - Inspect changes on a container's filesystem
# SYNOPSIS
**docker diff**
[**--help**]
CONTAINER
# DESCRIPTION
Inspect changes on a container's filesystem. You can use the full or
shortened container ID or the container name set using
**docker run --name** option.
# OPTIONS
**--help**
Print usage statement
# EXAMPLES
Inspect the changes to on a nginx container:
# 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
# HISTORY
April 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>

96
vendor/github.com/hyperhq/hypercli/man/docker-events.1.md generated vendored Normal file
View File

@@ -0,0 +1,96 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-events - Get real time events from the server
# SYNOPSIS
**docker events**
[**--help**]
[**-f**|**--filter**[=*[]*]]
[**--since**[=*SINCE*]]
[**--until**[=*UNTIL*]]
# DESCRIPTION
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, die, exec_create, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause
and Docker images will report:
delete, import, pull, push, tag, untag
# OPTIONS
**--help**
Print usage statement
**-f**, **--filter**=[]
Provide filter values (i.e., 'event=stop')
**--since**=""
Show all events created since timestamp
**--until**=""
Stream events until this timestamp
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.
# HISTORY
April 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 Brian Goff <cpuguy83@gmail.com>
October 2015, updated by Mike Brown <mikebrow@gmail.com>

64
vendor/github.com/hyperhq/hypercli/man/docker-exec.1.md generated vendored Normal file
View File

@@ -0,0 +1,64 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-exec - Run a command in a running container
# SYNOPSIS
**docker exec**
[**-d**|**--detach**]
[**--detach-keys**[=*[]*]]
[**--help**]
[**-i**|**--interactive**]
[**--privileged**]
[**-t**|**--tty**]
[**-u**|**--user**[=*USER*]]
CONTAINER COMMAND [ARG...]
# DESCRIPTION
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
# OPTIONS
**-d**, **--detach**=*true*|*false*
Override the key sequence for detaching a container. Format is a single character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
**--detach-keys**=""
Define the key sequence which detaches the container.
**--help**
Print usage statement
**-i**, **--interactive**=*true*|*false*
Keep STDIN open even if not attached. The default is *false*.
**--privileged**=*true*|*false*
Give the process extended [Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html)
when running in a container. The default is *false*.
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.
**-t**, **--tty**=*true*|*false*
Allocate a pseudo-TTY. The default is *false*.
**-u**, **--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.
The **-t** option is incompatible with a redirection of the docker client
standard input.
# HISTORY
November 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

46
vendor/github.com/hyperhq/hypercli/man/docker-export.1.md generated vendored Normal file
View File

@@ -0,0 +1,46 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-export - Export the contents of a container's filesystem as a tar archive
# SYNOPSIS
**docker export**
[**--help**]
[**-o**|**--output**[=*""*]]
CONTAINER
# DESCRIPTION
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**.
# OPTIONS
**--help**
Print usage statement
**-o**, **--output**=""
Write to a file, instead of STDOUT
# 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.
# HISTORY
April 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>
January 2015, updated by Joseph Kern (josephakern at gmail dot com)

52
vendor/github.com/hyperhq/hypercli/man/docker-history.1.md generated vendored Normal file
View File

@@ -0,0 +1,52 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-history - Show the history of an image
# SYNOPSIS
**docker history**
[**--help**]
[**-H**|**--human**[=*true*]]
[**--no-trunc**]
[**-q**|**--quiet**]
IMAGE
# DESCRIPTION
Show the history of when and how an image was created.
# OPTIONS
**--help**
Print usage statement
**-H**, **--human**=*true*|*false*
Print sizes and dates in human readable format. The default is *true*.
**--no-trunc**=*true*|*false*
Don't truncate output. The default is *false*.
**-q**, **--quiet**=*true*|*false*
Only show numeric IDs. The default is *false*.
# 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 -
# HISTORY
April 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>

111
vendor/github.com/hyperhq/hypercli/man/docker-images.1.md generated vendored Normal file
View File

@@ -0,0 +1,111 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-images - List images
# SYNOPSIS
**docker images**
[**--help**]
[**-a**|**--all**]
[**--digests**]
[**-f**|**--filter**[=*[]*]]
[**--no-trunc**]
[**-q**|**--quiet**]
[REPOSITORY[:TAG]]
# DESCRIPTION
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.
# OPTIONS
**-a**, **--all**=*true*|*false*
Show all images (by default filter out the intermediate image layers). The default is *false*.
**--digests**=*true*|*false*
Show image digests. The default is *false*.
**-f**, **--filter**=[]
Filters the output. The dangling=true filter finds unused images. While label=com.foo=amd64 filters for images with a com.foo value of amd64. The label=com.foo filter finds images with the label com.foo of any value.
**--format**="*TEMPLATE*"
Pretty-print containers 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.
**--help**
Print usage statement
**--no-trunc**=*true*|*false*
Don't truncate output. The default is *false*.
**-q**, **--quiet**=*true*|*false*
Only show numeric IDs. The default is *false*.
# EXAMPLES
## Listing the images
To list the images in a local repository (not the registry) run:
docker images
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 images` 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 images` command lists all images in the
given repository.
docker images java
The `[REPOSITORY[:TAG]]` value must be an "exact match". This means that, for example,
`docker images 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 images java:8
To get a verbose list of images which contains all the intermediate images
used in builds use **-a**:
docker images -a
Previously, the docker images 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 only the shortened image IDs
Listing just the shortened image IDs. This can be useful for some automated
tools.
docker images -q
# HISTORY
April 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>

72
vendor/github.com/hyperhq/hypercli/man/docker-import.1.md generated vendored Normal file
View File

@@ -0,0 +1,72 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-import - Create an empty filesystem image and import the contents of the tarball (.tar, .tar.gz, .tgz, .bzip, .tar.xz, .txz) into it, then optionally tag it.
# SYNOPSIS
**docker import**
[**-c**|**--change**[=*[]*]]
[**-m**|**--message**[=*MESSAGE*]]
[**--help**]
file|URL|**-**[REPOSITORY[:TAG]]
# OPTIONS
**-c**, **--change**=[]
Apply specified Dockerfile instructions while importing the image
Supported Dockerfile instructions: `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
**--help**
Print usage statement
**-m**, **--message**=""
Set commit message for imported image
# DESCRIPTION
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 import http://example.com/exampleimage.tgz example/imagerepo
## Import from a local file
Import to docker via pipe and stdin:
# cat exampleimage.tgz | docker import - example/imagelocal
Import with a commit message
# cat exampleimage.tgz | docker import --message "New image imported from tarball" - exampleimagelocal:new
Import to a Docker image from a local file.
# docker import /path/to/exampleimage.tgz
## Import from a local file and tag
Import to docker via pipe and stdin:
# cat exampleimageV2.tgz | docker import - example/imagelocal:V-2.0
## Import from a local directory
# tar -c . | docker 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 import -c="ENV DEBUG true" - exampleimagedir
# See also
**docker-export(1)** to export the contents of a filesystem as a tar archive to STDOUT.
# HISTORY
April 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>

58
vendor/github.com/hyperhq/hypercli/man/docker-info.1.md generated vendored Normal file
View File

@@ -0,0 +1,58 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-info - Display system-wide information
# SYNOPSIS
**docker info**
[**--help**]
# DESCRIPTION
This command displays system wide information regarding the Docker installation.
Information displayed includes the number of containers and images, pool name,
data file, metadata file, data space used, total data space, metadata space used
, total metadata space, execution driver, and the kernel version.
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.
# OPTIONS
**--help**
Print usage statement
# EXAMPLES
## Display Docker system information
Here is a sample output:
# docker info
Containers: 14
Running: 3
Paused: 1
Stopped: 10
Images: 52
Server Version: 1.9.0
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Dirs: 80
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
Volume: local
Network: bridge null host
Kernel Version: 3.13.0-24-generic
Operating System: Ubuntu 14.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 2 GiB
# HISTORY
April 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>

323
vendor/github.com/hyperhq/hypercli/man/docker-inspect.1.md generated vendored Normal file
View File

@@ -0,0 +1,323 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-inspect - Return low-level information on a container or image
# SYNOPSIS
**docker inspect**
[**--help**]
[**-f**|**--format**[=*FORMAT*]]
[**-s**|**--size**]
[**--type**=*container*|*image*]
CONTAINER|IMAGE [CONTAINER|IMAGE...]
# DESCRIPTION
This displays all the information available in Docker for a given
container or image. 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.
# OPTIONS
**--help**
Print usage statement
**-f**, **--format**=""
Format the output using the given Go template.
**-s**, **--size**
Display total file sizes if the type is container.
**--type**="*container*|*image*"
Return JSON for specified type, permissible values are "image" or "container"
# 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",
"ExecDriver": "native-0.2",
"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 '{{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 an 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"
}
}
}
]
# HISTORY
April 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>
April 2015, updated by Qiang Huang <h.huangqiang@huawei.com>
October 2015, updated by Sally O'Malley <somalley@redhat.com>

28
vendor/github.com/hyperhq/hypercli/man/docker-kill.1.md generated vendored Normal file
View File

@@ -0,0 +1,28 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-kill - Kill a running container using SIGKILL or a specified signal
# SYNOPSIS
**docker kill**
[**--help**]
[**-s**|**--signal**[=*"KILL"*]]
CONTAINER [CONTAINER...]
# DESCRIPTION
The main process inside each container specified will be sent SIGKILL,
or any signal specified with option --signal.
# OPTIONS
**--help**
Print usage statement
**-s**, **--signal**="*KILL*"
Signal to send to the container
# HISTORY
April 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>

46
vendor/github.com/hyperhq/hypercli/man/docker-load.1.md generated vendored Normal file
View File

@@ -0,0 +1,46 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-load - Load an image from a tar archive or STDIN
# SYNOPSIS
**docker load**
[**--help**]
[**-i**|**--input**[=*INPUT*]]
# DESCRIPTION
Loads a tarred repository from a file or the standard input stream.
Restores both images and tags.
# OPTIONS
**--help**
Print usage statement
**-i**, **--input**=""
Read from a tar archive file, instead of STDIN. The tarball may be compressed with gzip, bzip, or xz.
# EXAMPLES
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
busybox latest 769b9341d937 7 weeks ago 2.489 MB
$ docker load --input fedora.tar
$ 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-save(1)** to save an image(s) to a tar archive (streamed to STDOUT by default).
# HISTORY
April 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>
July 2015 update by Mary Anthony <mary@docker.com>

60
vendor/github.com/hyperhq/hypercli/man/docker-login.1.md generated vendored Normal file
View File

@@ -0,0 +1,60 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-login - Register or log in to a Docker registry.
# SYNOPSIS
**docker login**
[**-e**|**--email**[=*EMAIL*]]
[**--help**]
[**-p**|**--password**[=*PASSWORD*]]
[**-u**|**--username**[=*USERNAME*]]
[SERVER]
# DESCRIPTION
Register or 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/articles/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.
> **Note**: When running `sudo docker login` credentials are saved in `/root/.docker/config.json`.
>
# OPTIONS
**-e**, **--email**=""
Email
**--help**
Print usage statement
**-p**, **--password**=""
Password
**-u**, **--username**=""
Username
# EXAMPLES
## Login to a registry on your localhost
# docker login localhost:8080
# See also
**docker-logout(1)** to log out from a Docker registry.
# HISTORY
April 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>
April 2015, updated by Mary Anthony for v2 <mary@docker.com>
November 2015, updated by Sally O'Malley <somalley@redhat.com>

32
vendor/github.com/hyperhq/hypercli/man/docker-logout.1.md generated vendored Normal file
View File

@@ -0,0 +1,32 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-logout - Log out from a Docker registry.
# SYNOPSIS
**docker logout**
[SERVER]
# DESCRIPTION
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.
# OPTIONS
There are no available options.
# EXAMPLES
## Log out from a registry on your localhost
# docker logout localhost:8080
# See also
**docker-login(1)** to register or log in to a Docker registry server.
# HISTORY
June 2014, Originally compiled by Daniel, Dao Quang Minh (daniel at nitrous dot io)
July 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
April 2015, updated by Mary Anthony for v2 <mary@docker.com>

64
vendor/github.com/hyperhq/hypercli/man/docker-logs.1.md generated vendored Normal file
View File

@@ -0,0 +1,64 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-logs - Fetch the logs of a container
# SYNOPSIS
**docker logs**
[**-f**|**--follow**]
[**--help**]
[**--since**[=*SINCE*]]
[**-t**|**--timestamps**]
[**--tail**[=*"all"*]]
CONTAINER
# DESCRIPTION
The **docker 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 logs).
The **docker logs --follow** command combines commands **docker 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.
# OPTIONS
**--help**
Print usage statement
**-f**, **--follow**=*true*|*false*
Follow log output. The default is *false*.
**--since**=""
Show logs since timestamp
**-t**, **--timestamps**=*true*|*false*
Show timestamps. The default is *false*.
**--tail**="*all*"
Output the specified number of lines at the end of logs (defaults to all logs)
The `--since` option can be Unix timestamps, date formated timestamps, or Go
duration strings (e.g. `10m`, `1h30m`) computed relative to the client machine’s
time. Supported formats for date formated 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` option with
either or both of the `--follow` or `--tail` options.
# HISTORY
April 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>
July 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
April 2015, updated by Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
October 2015, updated by Mike Brown <mikebrow@gmail.com>

69
vendor/github.com/hyperhq/hypercli/man/docker-network-connect.1.md generated vendored Normal file
View File

@@ -0,0 +1,69 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% OCT 2015
# NAME
docker-network-connect - connect a container to a network
# SYNOPSIS
**docker network connect**
[**--help**]
NETWORK CONTAINER
# DESCRIPTION
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 --net=<network-name>` option to start a container and immediately connect it to a network.
```bash
$ docker run -itd --net=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.
Paused containers remain connected and can be revealed by a `network inspect`.
When the container is stopped, it does not appear on the network until you restart
it.
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.
# OPTIONS
**NETWORK**
Specify network name
**CONTAINER**
Specify container name
**--help**
Print usage statement
# HISTORY
OCT 2015, created by Mary Anthony <mary@docker.com>

162
vendor/github.com/hyperhq/hypercli/man/docker-network-create.1.md generated vendored Normal file
View File

@@ -0,0 +1,162 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% OCT 2015
# NAME
docker-network-create - create a new network
# SYNOPSIS
**docker network create**
[**--aux-address**=*map[]*]
[**-d**|**--driver**=*DRIVER*]
[**--gateway**=*[]*]
[**--help**]
[**--internal**]
[**--ip-range**=*[]*]
[**--ipam-driver**=*default*]
[**--ipam-opt**=*map[]*]
[**-o**|**--opt**=*map[]*]
[**--subnet**=*[]*]
NETWORK-NAME
# DESCRIPTION
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 `docker daemon` 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://www.docker.com/engine/userguide/networking/get-started-overlay.md).
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 `--net` flag to connect it to a network.
This adds the `busybox` container to the `mynet` network.
```bash
$ docker run -itd --net=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 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
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 a=192.168.1.5 --aux-address b=192.168.1.6
--aux-address a=192.170.1.5 --aux-address b=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.
# OPTIONS
**--aux-address**=map[]
Auxiliary ipv4 or ipv6 addresses used by network driver
**-d**, **--driver**=*DRIVER*
Driver to manage the Network bridge or overlay. The default is bridge.
**--gateway**=[]
ipv4 or ipv6 Gateway for the master subnet
**--help**
Print usage
**--internal**
Restricts external access to the network
**--ip-range**=[]
Allocate container ip from a sub-range
**--ipam-driver**=*default*
IP Address Management Driver
**--ipam-opt**=map[]
Set custom IPAM driver options
**-o**, **--opt**=map[]
Set custom driver options
**--subnet**=[]
Subnet in CIDR format that represents a network segment
# HISTORY
OCT 2015, created by Mary Anthony <mary@docker.com>

36
vendor/github.com/hyperhq/hypercli/man/docker-network-disconnect.1.md generated vendored Normal file
View File

@@ -0,0 +1,36 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% OCT 2015
# NAME
docker-network-disconnect - disconnect a container from a network
# SYNOPSIS
**docker network disconnect**
[**--help**]
[**--force**]
NETWORK CONTAINER
# DESCRIPTION
Disconnects a container from a network.
```bash
$ docker network disconnect multi-host-network container1
```
# OPTIONS
**NETWORK**
Specify network name
**CONTAINER**
Specify container name
**--force**
Force the container to disconnect from a network
**--help**
Print usage statement
# HISTORY
OCT 2015, created by Mary Anthony <mary@docker.com>

111
vendor/github.com/hyperhq/hypercli/man/docker-network-inspect.1.md generated vendored Normal file
View File

@@ -0,0 +1,111 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% OCT 2015
# NAME
docker-network-inspect - inspect a network
# SYNOPSIS
**docker network inspect**
[**-f**|**--format**[=*FORMAT*]]
[**--help**]
NETWORK [NETWORK...]
# DESCRIPTION
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"
}
]
},
"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/16"
}
]
},
"Containers": {},
"Options": {}
}
]
```
# OPTIONS
**-f**, **--format**=""
Format the output using the given go template.
**--help**
Print usage statement
# HISTORY
OCT 2015, created by Mary Anthony <mary@docker.com>

138
vendor/github.com/hyperhq/hypercli/man/docker-network-ls.1.md generated vendored Normal file
View File

@@ -0,0 +1,138 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% OCT 2015
# NAME
docker-network-ls - list networks
# SYNOPSIS
**docker network ls**
[**-f**|**--filter**[=*[]*]]
[**--no-trunc**[=*true*|*false*]]
[**-q**|**--quiet**[=*true*|*false*]]
[**--help**]
# DESCRIPTION
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
7fca4eb8c647 bridge bridge
9f904ee27bf5 none null
cf03ee007fb4 host host
78b03ee04fc4 multi-host overlay
```
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:
* id (network's id)
* name (network's name)
* type (custom|builtin)
#### 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.
#### 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 ps --filter name=foo
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
06e7eef0a170 foobar bridge
```
#### ID
The `id` filter matches on all or part of a network's ID.
The following filter matches all networks with a name containing the
`06e7eef01700` string.
```bash
$ docker network ls --filter id=63d1ff1f77b07ca51070a8c227e962238358bd310bde1529cf62e6c307ade161
NETWORK ID NAME DRIVER
63d1ff1f77b0 dev bridge
```
You can also filter for a substring in a ID as this shows:
```bash
$ docker ps --filter id=95e74588f40d
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
$ docker ps --filter id=95e
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
```
# OPTIONS
**-f**, **--filter**=*[]*
filter output based on conditions provided.
**--no-trunc**=*true*|*false*
Do not truncate the output
**-q**, **--quiet**=*true*|*false*
Only display numeric IDs
**--help**
Print usage statement
# HISTORY
OCT 2015, created by Mary Anthony <mary@docker.com>

43
vendor/github.com/hyperhq/hypercli/man/docker-network-rm.1.md generated vendored Normal file
View File

@@ -0,0 +1,43 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% OCT 2015
# NAME
docker-network-rm - remove one or more networks
# SYNOPSIS
**docker network rm**
[**--help**]
NETWORK [NETWORK...]
# DESCRIPTION
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 id's. 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.
# OPTIONS
**NETWORK**
Specify network name or id
**--help**
Print usage statement
# HISTORY
OCT 2015, created by Mary Anthony <mary@docker.com>

30
vendor/github.com/hyperhq/hypercli/man/docker-pause.1.md generated vendored Normal file
View File

@@ -0,0 +1,30 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-pause - Pause all processes within a container
# SYNOPSIS
**docker pause**
CONTAINER [CONTAINER...]
# DESCRIPTION
The `docker pause` command uses the cgroups freezer to suspend all processes in
a container. 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.
See the [cgroups freezer documentation]
(https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt) for
further details.
# OPTIONS
There are no available options.
# See also
**docker-unpause(1)** to unpause all processes within a container.
# HISTORY
June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

47
vendor/github.com/hyperhq/hypercli/man/docker-port.1.md generated vendored Normal file
View File

@@ -0,0 +1,47 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-port - List port mappings for the CONTAINER, or lookup the public-facing port that is NAT-ed to the PRIVATE_PORT
# SYNOPSIS
**docker port**
[**--help**]
CONTAINER [PRIVATE_PORT[/PROTO]]
# DESCRIPTION
List port mappings for the CONTAINER, or lookup the public-facing port that is NAT-ed to the PRIVATE_PORT
# OPTIONS
**--help**
Print usage statement
# 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 port test
7890/tcp -> 0.0.0.0:4321
9876/tcp -> 0.0.0.0:1234
## Find out a specific mapping
# docker port test 7890/tcp
0.0.0.0:4321
# docker port test 7890
0.0.0.0:4321
## An example showing error for non-existent mapping
# docker port test 7890/udp
2014/06/24 11:53:36 Error: No public port '7890/udp' published for test
# HISTORY
April 2014, Originally compiled by William Henry (whenry at redhat dot com)
June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
November 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

126
vendor/github.com/hyperhq/hypercli/man/docker-ps.1.md generated vendored Normal file
View File

@@ -0,0 +1,126 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% FEBRUARY 2015
# NAME
docker-ps - List containers
# SYNOPSIS
**docker ps**
[**-a**|**--all**]
[**-f**|**--filter**[=*[]*]]
[**--format**=*"TEMPLATE"*]
[**--help**]
[**-l**|**--latest**]
[**-n**[=*-1*]]
[**--no-trunc**]
[**-q**|**--quiet**]
[**-s**|**--size**]
# DESCRIPTION
List the containers in the local repository. By default this shows only
the running containers.
# OPTIONS
**-a**, **--all**=*true*|*false*
Show all containers. Only running containers are shown by default. The default is *false*.
**-f**, **--filter**=[]
Filter output based on these conditions:
- exited=<int> an exit code of <int>
- label=<key> or label=<key>=<value>
- status=(created|restarting|running|paused|exited|dead)
- name=<string> a container's name
- id=<ID> a container's ID
- before=(<container-name>|<container-id>)
- since=(<container-name>|<container-id>)
- ancestor=(<image-name>[:tag]|<image-id>|<image@digest>) - containers created from an image or a descendant.
**--format**="*TEMPLATE*"
Pretty-print containers using a Go template.
Valid placeholders:
.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.
.Labels - All labels assigned to the container.
.Label - Value of a specific label for this container. For example `{{.Label "com.docker.swarm.cpu"}}`
**--help**
Print usage statement
**-l**, **--latest**=*true*|*false*
Show only the latest created container (includes all states). The default is *false*.
**-n**=*-1*
Show n last created containers (includes all states).
**--no-trunc**=*true*|*false*
Don't truncate output. The default is *false*.
**-q**, **--quiet**=*true*|*false*
Only display numeric IDs. The default is *false*.
**-s**, **--size**=*true*|*false*
Display total file sizes. The default is *false*.
# EXAMPLES
# Display all containers, including non-running
# docker ps -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 ps -a -q
a87ecb4f327c
01946d9d34d8
c1d3b0166030
41d50ecd2f57
# Display only IDs of all containers that have the name `determined_torvalds`
# docker ps -a -q --filter=name=determined_torvalds
c1d3b0166030
# Display containers with their commands
# docker ps --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 ps --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 ps --format 'table {{.ID}}\t{{(.Label "com.docker.swarm.node")}}'
CONTAINER ID NODE
a87ecb4f327c ubuntu
01946d9d34d8
c1d3b0166030 debian
41d50ecd2f57 fedora
# HISTORY
April 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>
August 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
November 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
February 2015, updated by André Martins <martins@noironetworks.com>

91
vendor/github.com/hyperhq/hypercli/man/docker-pull.1.md generated vendored Normal file
View File

@@ -0,0 +1,91 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-pull - Pull an image or a repository from a registry
# SYNOPSIS
**docker pull**
[**-a**|**--all-tags**]
[**--help**]
NAME[:TAG] | [REGISTRY_HOST[:REGISTRY_PORT]/]NAME[:TAG]
# DESCRIPTION
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.
# OPTIONS
**-a**, **--all-tags**=*true*|*false*
Download all tagged images in the repository. The default is *false*.
**--help**
Print usage statement
# EXAMPLE
## Pull a repository with multiple images with the -a|--all-tags option set to true.
Note that if the image is previously downloaded then the status would be
`Status: Image is up to date for fedora`.
$ docker 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
$ docker images
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
## Pull a repository with the -a|--all-tags option set to false (this is the default).
$ docker pull debian
Using default tag: latest
latest: Pulling from library/debian
2c49f83e0b13: Pull complete
4a5e6db8c069: Pull complete
Status: Downloaded newer image for debian:latest
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
debian latest 4a5e6db8c069 5 days ago 125.1 MB
## Pull an image, manually specifying path to Docker's public registry and tag
Note that if the image is previously downloaded then the status would be
`Status: Image is up to date for registry.hub.docker.com/fedora:20`
$ docker pull registry.hub.docker.com/fedora:20
Pulling repository fedora
3f2fed40e4b0: Download complete
511136ea3c5a: Download complete
fd241224e9cf: Download complete
Status: Downloaded newer image for registry.hub.docker.com/fedora:20
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
fedora 20 3f2fed40e4b0 4 days ago 372.7 MB
# HISTORY
April 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>
August 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
April 2015, updated by John Willis <john.willis@docker.com>
April 2015, updated by Mary Anthony for v2 <mary@docker.com>
September 2015, updated by Sally O'Malley <somalley@redhat.com>

52
vendor/github.com/hyperhq/hypercli/man/docker-push.1.md generated vendored Normal file
View File

@@ -0,0 +1,52 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-push - Push an image or a repository to a registry
# SYNOPSIS
**docker push**
[**--help**]
NAME[:TAG] | [REGISTRY_HOST[:REGISTRY_PORT]/]NAME[:TAG]
# DESCRIPTION
This command pushes an image or a repository to a registry. If you do not
specify a `REGISTRY_HOST`, the command uses Docker's public registry located at
`registry-1.docker.io` by default.
# OPTIONS
**--help**
Print usage statement
# EXAMPLES
# Pushing a new image to a registry
First save the new image by finding the container ID (using **docker ps**)
and then committing it to a new image name. Note that only a-z0-9-_. are
allowed when naming images:
# docker 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 tag rhel-httpd registry-host:5000/myadmin/rhel-httpd
# docker push registry-host:5000/myadmin/rhel-httpd
Check that this worked by running:
# docker images
You should see both `rhel-httpd` and `registry-host:5000/myadmin/rhel-httpd`
listed.
# HISTORY
April 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>
April 2015, updated by Mary Anthony for v2 <mary@docker.com>
June 2015, updated by Sally O'Malley <somalley@redhat.com>

15
vendor/github.com/hyperhq/hypercli/man/docker-rename.1.md generated vendored Normal file
View File

@@ -0,0 +1,15 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% OCTOBER 2014
# NAME
docker-rename - Rename a container
# SYNOPSIS
**docker rename**
OLD_NAME NEW_NAME
# OPTIONS
There are no available options.
# DESCRIPTION
Rename a container. Container may be running, paused or stopped.

26
vendor/github.com/hyperhq/hypercli/man/docker-restart.1.md generated vendored Normal file
View File

@@ -0,0 +1,26 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-restart - Restart a container
# SYNOPSIS
**docker restart**
[**--help**]
[**-t**|**--time**[=*10*]]
CONTAINER [CONTAINER...]
# DESCRIPTION
Restart each container listed.
# OPTIONS
**--help**
Print usage statement
**-t**, **--time**=*10*
Number of seconds to try to stop for before killing the container. Once killed it will then be restarted. Default is 10 seconds.
# HISTORY
April 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>

72
vendor/github.com/hyperhq/hypercli/man/docker-rm.1.md generated vendored Normal file
View File

@@ -0,0 +1,72 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-rm - Remove one or more containers
# SYNOPSIS
**docker rm**
[**-f**|**--force**]
[**-l**|**--link**]
[**-v**|**--volumes**]
CONTAINER [CONTAINER...]
# DESCRIPTION
**docker 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 ps -a** command.
# OPTIONS
**--help**
Print usage statement
**-f**, **--force**=*true*|*false*
Force the removal of a running container (uses SIGKILL). The default is *false*.
**-l**, **--link**=*true*|*false*
Remove the specified link and not the underlying container. The default is *false*.
**-v**, **--volumes**=*true*|*false*
Remove the volumes associated with the container. The default is *false*.
# 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 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 rm hopeful_morse
## Removing a container and all associated volumes
$ docker 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 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`.
# HISTORY
April 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>
July 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
August 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

42
vendor/github.com/hyperhq/hypercli/man/docker-rmi.1.md generated vendored Normal file
View File

@@ -0,0 +1,42 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-rmi - Remove one or more images
# SYNOPSIS
**docker rmi**
[**-f**|**--force**]
[**--help**]
[**--no-prune**]
IMAGE [IMAGE...]
# DESCRIPTION
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 images** command.
# OPTIONS
**-f**, **--force**=*true*|*false*
Force removal of the image. The default is *false*.
**--help**
Print usage statement
**--no-prune**=*true*|*false*
Do not delete untagged parents. The default is *false*.
# EXAMPLES
## Removing an image
Here is an example of removing an image:
docker rmi fedora/httpd
# HISTORY
April 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>
April 2015, updated by Mary Anthony for v2 <mary@docker.com>

935
vendor/github.com/hyperhq/hypercli/man/docker-run.1.md generated vendored Normal file
View File

@@ -0,0 +1,935 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-run - Run a command in a new container
# SYNOPSIS
**docker run**
[**-a**|**--attach**[=*[]*]]
[**--add-host**[=*[]*]]
[**--blkio-weight**[=*[BLKIO-WEIGHT]*]]
[**--blkio-weight-device**[=*[]*]]
[**--cpu-shares**[=*0*]]
[**--cap-add**[=*[]*]]
[**--cap-drop**[=*[]*]]
[**--cgroup-parent**[=*CGROUP-PATH*]]
[**--cidfile**[=*CIDFILE*]]
[**--cpu-period**[=*0*]]
[**--cpu-quota**[=*0*]]
[**--cpuset-cpus**[=*CPUSET-CPUS*]]
[**--cpuset-mems**[=*CPUSET-MEMS*]]
[**-d**|**--detach**]
[**--detach-keys**[=*[]*]]
[**--device**[=*[]*]]
[**--device-read-bps**[=*[]*]]
[**--device-read-iops**[=*[]*]]
[**--device-write-bps**[=*[]*]]
[**--device-write-iops**[=*[]*]]
[**--dns**[=*[]*]]
[**--dns-opt**[=*[]*]]
[**--dns-search**[=*[]*]]
[**-e**|**--env**[=*[]*]]
[**--entrypoint**[=*ENTRYPOINT*]]
[**--env-file**[=*[]*]]
[**--expose**[=*[]*]]
[**--group-add**[=*[]*]]
[**-h**|**--hostname**[=*HOSTNAME*]]
[**--help**]
[**-i**|**--interactive**]
[**--ip**[=*IPv4-ADDRESS*]]
[**--ip6**[=*IPv6-ADDRESS*]]
[**--ipc**[=*IPC*]]
[**--isolation**[=*default*]]
[**--kernel-memory**[=*KERNEL-MEMORY*]]
[**-l**|**--label**[=*[]*]]
[**--label-file**[=*[]*]]
[**--link**[=*[]*]]
[**--log-driver**[=*[]*]]
[**--log-opt**[=*[]*]]
[**-m**|**--memory**[=*MEMORY*]]
[**--mac-address**[=*MAC-ADDRESS*]]
[**--memory-reservation**[=*MEMORY-RESERVATION*]]
[**--memory-swap**[=*LIMIT*]]
[**--memory-swappiness**[=*MEMORY-SWAPPINESS*]]
[**--name**[=*NAME*]]
[**--net**[=*"bridge"*]]
[**--net-alias**[=*[]*]]
[**--oom-kill-disable**]
[**--oom-score-adj**[=*0*]]
[**-P**|**--publish-all**]
[**-p**|**--publish**[=*[]*]]
[**--pid**[=*[]*]]
[**--privileged**]
[**--read-only**]
[**--restart**[=*RESTART*]]
[**--rm**]
[**--security-opt**[=*[]*]]
[**--stop-signal**[=*SIGNAL*]]
[**--shm-size**[=*[]*]]
[**--sig-proxy**[=*true*]]
[**-t**|**--tty**]
[**--tmpfs**[=*[CONTAINER-DIR[:<OPTIONS>]*]]
[**-u**|**--user**[=*USER*]]
[**--ulimit**[=*[]*]]
[**--uts**[=*[]*]]
[**-v**|**--volume**[=*[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]*]]
[**--volume-driver**[=*DRIVER*]]
[**--volumes-from**[=*[]*]]
[**-w**|**--workdir**[=*WORKDIR*]]
IMAGE [COMMAND] [ARG...]
# DESCRIPTION
Run a process in a new container. **docker run** starts a process with its own
file system, its own networking, and its own isolated process tree. The IMAGE
which starts the process may define defaults related to the process that will be
run in the container, the networking to expose, and more, but **docker run**
gives final control to the operator or administrator who starts the container
from the image. For that reason **docker run** has more options than any other
Docker command.
If the IMAGE is not already loaded then **docker run** will pull the IMAGE, and
all image dependencies, from the repository in the same way running **docker
pull** IMAGE, before it starts the container from that image.
# OPTIONS
**-a**, **--attach**=[]
Attach to STDIN, STDOUT or STDERR.
In foreground mode (the default when **-d**
is not specified), **docker run** can start the process in the container
and attach the console to the process’s standard input, output, and standard
error. It can even pretend to be a TTY (this is what most commandline
executables expect) and pass along signals. The **-a** option can be set for
each of stdin, stdout, and stderr.
**--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.
**--blkio-weight**=*0*
Block IO weight (relative weight) accepts a weight value between 10 and 1000.
**--blkio-weight-device**=[]
Block IO weight (relative device weight, format: `DEVICE_NAME:WEIGHT`).
**--cpu-shares**=*0*
CPU shares (relative weight)
By default, all containers get the same proportion of CPU cycles. This proportion
can be modified by changing 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.
The proportion will only apply when CPU-intensive processes are running.
When tasks in one container are idle, other containers can use the
left-over CPU time. The actual amount of CPU time will vary depending on
the number of containers running on the system.
For example, consider three containers, one has a cpu-share of 1024 and
two others have a cpu-share setting of 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 a cpu-share
of 1024, the first container only gets 33% of the CPU. The remaining containers
receive 16.5%, 16.5% and 33% of the CPU.
On a multi-core system, the shares of CPU time are distributed over all 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 **-c=512** running one process, and another container
**{C1}** with **-c=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
**--cap-add**=[]
Add Linux capabilities
**--cap-drop**=[]
Drop Linux capabilities
**--cgroup-parent**=""
Path to cgroups under which the cgroup for the container will be created. If the path is not absolute, the path is considered to be relative to the cgroups path of the init process. Cgroups will be created if they do not already exist.
**--cidfile**=""
Write the container ID to the file
**--cpu-period**=*0*
Limit the CPU CFS (Completely Fair Scheduler) period
Limit the container's CPU usage. This flag tell the kernel to restrict the container's CPU usage to the period you specify.
**--cpuset-cpus**=""
CPUs in which to allow execution (0-3, 0,1)
**--cpuset-mems**=""
Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
If you have four memory nodes on your system (0-3), use `--cpuset-mems=0,1`
then processes in your Docker container will only use memory from the first
two memory nodes.
**--cpu-quota**=*0*
Limit the CPU CFS (Completely Fair Scheduler) quota
Limit the container's CPU usage. By default, containers run with the full
CPU resource. This flag tell the kernel to restrict the container's CPU usage
to the quota you specify.
**-d**, **--detach**=*true*|*false*
Detached mode: run the container in the background and print the new container ID. The default is *false*.
At any time you can run **docker ps** in
the other shell to view a list of the running containers. You can reattach to a
detached container with **docker attach**. If you choose to run a container in
the detached mode, then you cannot use the **-rm** option.
When attached in the tty mode, 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.
**--detach-keys**=""
Override the key sequence for detaching a container. Format is a single character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
**--device**=[]
Add a host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm)
**--device-read-bps**=[]
Limit read rate from a device (e.g. --device-read-bps=/dev/sda:1mb)
**--device-read-iops**=[]
Limit read rate from a device (e.g. --device-read-iops=/dev/sda:1000)
**--device-write-bps**=[]
Limit write rate to a device (e.g. --device-write-bps=/dev/sda:1mb)
**--device-write-iops**=[]
Limit write rate a a device (e.g. --device-write-iops=/dev/sda:1000)
**--dns-search**=[]
Set custom DNS search domains (Use --dns-search=. if you don't wish to set the search domain)
**--dns-opt**=[]
Set custom DNS options
**--dns**=[]
Set custom DNS servers
This option can be used to override the DNS
configuration passed to the container. Typically this is necessary when the
host DNS configuration is invalid for the container (e.g., 127.0.0.1). When this
is the case the **--dns** flags is necessary for every run.
**-e**, **--env**=[]
Set environment variables
This option allows you to specify arbitrary
environment variables that are available for the process that will be launched
inside of the container.
**--entrypoint**=""
Overwrite the default ENTRYPOINT of the image
This option allows you to overwrite the default entrypoint of the image that
is set in the Dockerfile. The ENTRYPOINT of an image is similar to a COMMAND
because it specifies what executable to run when the container starts, but it is
(purposely) more difficult to override. The ENTRYPOINT gives a container its
default nature or behavior, so that when you set an ENTRYPOINT you can run the
container as if it were that binary, complete with default options, and you can
pass in more options via the COMMAND. But, sometimes an operator may want to run
something else inside the container, so you can override the default ENTRYPOINT
at runtime by using a **--entrypoint** and a string to specify the new
ENTRYPOINT.
**--env-file**=[]
Read in a line delimited file of environment variables
**--expose**=[]
Expose a port, or a range of ports (e.g. --expose=3300-3310) 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.
**--group-add**=[]
Add additional groups to run as
**-h**, **--hostname**=""
Container host name
Sets the container host name that is available inside the container.
**--help**
Print usage statement
**-i**, **--interactive**=*true*|*false*
Keep STDIN open even if not attached. The default is *false*.
When set to true, keep stdin open even if not attached. The default is false.
**--ip**=""
Sets the container's interface IPv4 address (e.g. 172.23.0.9)
It can only be used in conjunction with **--net** for user-defined networks
**--ip6**=""
Sets the container's interface IPv6 address (e.g. 2001:db8::1b99)
It can only be used in conjunction with **--net** for user-defined networks
**--ipc**=""
Default is to create a private IPC namespace (POSIX SysV IPC) for the container
'container:<name|id>': reuses another container shared memory, semaphores and message queues
'host': use the host shared memory,semaphores and message queues inside the container. Note: the host mode gives the container full access to local shared memory and is therefore considered insecure.
**--isolation**="*default*"
Isolation specifies the type of isolation technology used by containers.
**-l**, **--label**=[]
Set metadata on the container (e.g., --label com.example.key=value)
**--kernel-memory**=""
Kernel memory limit (format: `<number>[<unit>]`, where unit = b, k, m or g)
Constrains the kernel memory available to a container. If a limit of 0
is specified (not using `--kernel-memory`), the container's kernel memory
is not limited. If you specify a limit, it may be rounded up to a multiple
of the operating system's page size and the value can be very large,
millions of trillions.
**--label-file**=[]
Read in a line delimited file of labels
**--link**=[]
Add link to another container in the form of <name or id>:alias or just <name or id>
in which case the alias will match the name
If the operator
uses **--link** when starting the new client container, then the client
container can access the exposed port via a private networking interface. Docker
will set some environment variables in the client container to help indicate
which interface and port to use.
**--log-driver**="*json-file*|*syslog*|*journald*|*gelf*|*fluentd*|*awslogs*|*splunk*|*none*"
Logging driver for container. Default is defined by daemon `--log-driver` flag.
**Warning**: the `docker logs` command works only for the `json-file` and
`journald` logging drivers.
**--log-opt**=[]
Logging driver specific options.
**-m**, **--memory**=""
Memory limit (format: <number>[<unit>], where unit = b, k, m or g)
Allows you to constrain the memory available to a container. If the host
supports swap memory, then the **-m** memory setting can be larger than physical
RAM. If a limit of 0 is specified (not using **-m**), the container's memory is
not limited. The actual limit may be rounded up to a multiple of the operating
system's page size (the value would be very large, that's millions of trillions).
**--memory-reservation**=""
Memory soft limit (format: <number>[<unit>], where unit = b, k, m or g)
After setting memory reservation, when the system detects memory contention
or low memory, containers are forced to restrict their consumption to their
reservation. So you should always set the value below **--memory**, otherwise the
hard limit will take precedence. By default, memory reservation will be the same
as 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.
**--mac-address**=""
Container MAC address (e.g. 92:d0:c6:0a:29:33)
Remember that the MAC address in an Ethernet network must be unique.
The IPv6 link-local address will be based on the device's MAC address
according to RFC4862.
**--name**=""
Assign a name to the container
The operator can identify a container in three ways:
UUID long identifier (“f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778”)
UUID short identifier (“f78375b1c487”)
Name (“jonah”)
The UUID identifiers come from the Docker daemon, and if a name is not assigned
to the container with **--name** then the daemon will also generate a random
string name. The name is useful when defining links (see **--link**) (or any
other place you need to identify a container). This works for both background
and foreground Docker containers.
**--net**="*bridge*"
Set the Network mode for the container
'bridge': create a network stack on the default Docker bridge
'none': no networking
'container:<name|id>': reuse another container's network stack
'host': use the Docker host network stack. Note: the host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.
'<network-name>|<network-id>': connect to a user-defined network
**--net-alias**=[]
Add network-scoped alias for the container
**--oom-kill-disable**=*true*|*false*
Whether to disable OOM Killer for the container or not.
**--oom-score-adj**=""
Tune the host's OOM preferences for containers (accepts -1000 to 1000)
**-P**, **--publish-all**=*true*|*false*
Publish all exposed ports to random ports on the host interfaces. The default is *false*.
When set to true publish all exposed ports to the host interfaces. The
default is false. If the operator uses -P (or -p) then Docker will make the
exposed port accessible on the host and the ports will be available to any
client that can reach the host. When using -P, Docker will bind any exposed
port to a random port on the host within an *ephemeral port range* defined by
`/proc/sys/net/ipv4/ip_local_port_range`. To find the mapping between the host
ports and the exposed ports, use `docker port`.
**-p**, **--publish**=[]
Publish a container's port, or range of ports, to the host.
Format: `ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort`
Both hostPort and containerPort can be specified as a range of ports.
When specifying ranges for both, the number of container ports in the range must match the number of host ports in the range.
(e.g., `docker run -p 1234-1236:1222-1224 --name thisWorks -t busybox`
but not `docker run -p 1230-1236:1230-1240 --name RangeContainerPortsBiggerThanRangeHostPorts -t busybox`)
With ip: `docker run -p 127.0.0.1:$HOSTPORT:$CONTAINERPORT --name CONTAINER -t someimage`
Use `docker port` to see the actual mapping: `docker port CONTAINER $CONTAINERPORT`
**--pid**=*host*
Set the PID mode for the container
**host**: use the host's PID namespace inside the container.
Note: the host mode gives the container full access to local PID and is therefore considered insecure.
**--uts**=*host*
Set the UTS mode for the container
**host**: use the host's UTS namespace inside the container.
Note: the host mode gives the container access to changing the host's hostname and is therefore considered insecure.
**--privileged**=*true*|*false*
Give extended privileges to this container. The default is *false*.
By default, Docker containers are
“unprivileged” (=false) and cannot, for example, run a Docker daemon inside the
Docker container. This is because by default a container is not allowed to
access any devices. A “privileged” container is given access to all devices.
When the operator executes **docker run --privileged**, Docker will enable access
to all devices on the host as well as set some configuration in AppArmor to
allow the container nearly all the same access to the host as processes running
outside of a container on the host.
**--read-only**=*true*|*false*
Mount the container's root filesystem as read only.
By default a container will have its root filesystem writable allowing processes
to write files anywhere. By specifying the `--read-only` flag the container will have
its root filesystem mounted as read only prohibiting any writes.
**--restart**="*no*"
Restart policy to apply when a container exits (no, on-failure[:max-retry], always, unless-stopped).
**--rm**=*true*|*false*
Automatically remove the container when it exits (incompatible with -d). The default is *false*.
**--security-opt**=[]
Security Options
"label:user:USER" : Set the label user for the container
"label:role:ROLE" : Set the label role for the container
"label:type:TYPE" : Set the label type for the container
"label:level:LEVEL" : Set the label level for the container
"label:disable" : Turn off label confinement for the container
**--stop-signal**=*SIGTERM*
Signal to stop a container. Default is SIGTERM.
**--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`.
**--sig-proxy**=*true*|*false*
Proxy received signals to the process (non-TTY mode only). SIGCHLD, SIGSTOP, and SIGKILL are not proxied. The default is *true*.
**--memory-swappiness**=""
Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.
**-t**, **--tty**=*true*|*false*
Allocate a pseudo-TTY. The default is *false*.
When set to true Docker can allocate a pseudo-tty and attach to the standard
input of any container. This can be used, for example, to run a throwaway
interactive shell. The default is false.
The **-t** option is incompatible with a redirection of the docker client
standard input.
**--tmpfs**=[] Create a tmpfs mount
Mount a temporary filesystem (`tmpfs`) mount into a container, for example:
$ docker run -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image
This command mounts a `tmpfs` at `/tmp` within the container. The supported mount
options are the same as the Linux default `mount` flags. If you do not specify
any options, the systems uses the following options:
`rw,noexec,nosuid,nodev,size=65536k`.
**-u**, **--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.
**--ulimit**=[]
Ulimit options
**-v**|**--volume**[=*[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]*]
Create a bind mount. If you specify, ` -v /HOST-DIR:/CONTAINER-DIR`, Docker
bind mounts `/HOST-DIR` in the host to `/CONTAINER-DIR` in the Docker
container. If 'HOST-DIR' is omitted, Docker automatically creates the new
volume on the host. The `OPTIONS` are a comma delimited list and can be:
* [rw|ro]
* [z|Z]
* [`[r]shared`|`[r]slave`|`[r]private`]
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 add `:ro` or `:rw` suffix to a volume to mount it read-only or
read-write mode, respectively. By default, the volumes are mounted read-write.
See examples.
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 propagaion 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.
**--volume-driver**=""
Container's volume driver. This driver creates volumes specified either from
a Dockerfile's `VOLUME` instruction or from the `docker run -v` flag.
See **docker-volume-create(1)** for full details.
**--volumes-from**=[]
Mount volumes from the specified container(s)
Mounts already mounted volumes from a source container onto another
container. You must supply the source's container-id. To share
a volume, use the **--volumes-from** option when running
the target container. You can share volumes even if the source container
is not running.
By default, Docker mounts the volumes in the same mode (read-write or
read-only) as it is mounted in the source container. Optionally, you
can change this by suffixing the container-id with either the `:ro` or
`:rw ` keyword.
If the location of the volume from the source container overlaps with
data residing on a target container, then the volume hides
that data on the target.
**-w**, **--workdir**=""
Working directory inside the container
The default working directory for
running binaries within a container is the root directory (/). The developer can
set a different default with the Dockerfile WORKDIR instruction. The operator
can override the working directory by using the **-w** option.
# Exit Status
The exit code from `docker run` gives information about why the container
failed to run or why it exited. When `docker run` exits with a non-zero code,
the exit codes follow the `chroot` standard, see below:
**_125_** if the error is with Docker daemon **_itself_**
$ docker run --foo busybox; echo $?
# flag provided but not defined: --foo
See 'docker run --help'.
125
**_126_** if the **_contained command_** cannot be invoked
$ docker run busybox /etc; echo $?
# exec: "/etc": permission denied
docker: Error response from daemon: Contained command could not be invoked
126
**_127_** if the **_contained command_** cannot be found
$ docker run busybox foo; echo $?
# exec: "foo": executable file not found in $PATH
docker: Error response from daemon: Contained command not found or does not exist
127
**_Exit code_** of **_contained command_** otherwise
$ docker run busybox /bin/sh -c 'exit 3'
# 3
# EXAMPLES
## Running container in read-only mode
During container image development, containers often need to write to the image
content. Installing packages into /usr, for example. In production,
applications seldom need to write to the image. Container applications write
to volumes if they need to write to file systems at all. Applications can be
made more secure by running them in read-only mode using the --read-only switch.
This protects the containers image from modification. Read only containers may
still need to write temporary data. The best way to handle this is to mount
tmpfs directories on /run and /tmp.
# docker run --read-only --tmpfs /run --tmpfs /tmp -i -t fedora /bin/bash
## Exposing log messages from the container to the host's log
If you want messages that are logged in your container to show up in the host's
syslog/journal then you should bind mount the /dev/log directory as follows.
# docker run -v /dev/log:/dev/log -i -t fedora /bin/bash
From inside the container you can test this by sending a message to the log.
(bash)# logger "Hello from my container"
Then exit and check the journal.
# exit
# journalctl -b | grep Hello
This should list the message sent to logger.
## Attaching to one or more from STDIN, STDOUT, STDERR
If you do not specify -a then Docker will attach everything (stdin,stdout,stderr)
. You can specify to which of the three standard streams (stdin, stdout, stderr)
you’d like to connect instead, as in:
# docker run -a stdin -a stdout -i -t fedora /bin/bash
## Sharing IPC between containers
Using shm_server.c available here: https://www.cs.cf.ac.uk/Dave/C/node27.html
Testing `--ipc=host` mode:
Host shows a shared memory segment with 7 pids attached, happens to be from httpd:
```
$ sudo ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x01128e25 0 root 600 1000 7
```
Now run a regular container, and it correctly does NOT see the shared memory segment from the host:
```
$ docker run -it shm ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
```
Run a container with the new `--ipc=host` option, and it now sees the shared memory segment from the host httpd:
```
$ docker run -it --ipc=host shm ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x01128e25 0 root 600 1000 7
```
Testing `--ipc=container:CONTAINERID` mode:
Start a container with a program to create a shared memory segment:
```
$ docker run -it shm bash
$ sudo shm/shm_server &
$ sudo ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0000162e 0 root 666 27 1
```
Create a 2nd container correctly shows no shared memory segment from 1st container:
```
$ docker run shm ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
```
Create a 3rd container using the new --ipc=container:CONTAINERID option, now it shows the shared memory segment from the first:
```
$ docker run -it --ipc=container:ed735b2264ac shm ipcs -m
$ sudo ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0000162e 0 root 666 27 1
```
## Linking Containers
> **Note**: This section describes linking between containers on the
> default (bridge) network, also known as "legacy links". Using `--link`
> on user-defined networks uses the DNS-based discovery, which does not add
> entries to `/etc/hosts`, and does not set environment variables for
> discovery.
The link feature allows multiple containers to communicate with each other. For
example, a container whose Dockerfile has exposed port 80 can be run and named
as follows:
# docker run --name=link-test -d -i -t fedora/httpd
A second container, in this case called linker, can communicate with the httpd
container, named link-test, by running with the **--link=<name>:<alias>**
# docker run -t -i --link=link-test:lt --name=linker fedora /bin/bash
Now the container linker is linked to container link-test with the alias lt.
Running the **env** command in the linker container shows environment variables
with the LT (alias) context (**LT_**)
# env
HOSTNAME=668231cb0978
TERM=xterm
LT_PORT_80_TCP=tcp://172.17.0.3:80
LT_PORT_80_TCP_PORT=80
LT_PORT_80_TCP_PROTO=tcp
LT_PORT=tcp://172.17.0.3:80
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LT_NAME=/linker/lt
SHLVL=1
HOME=/
LT_PORT_80_TCP_ADDR=172.17.0.3
_=/usr/bin/env
When linking two containers Docker will use the exposed ports of the container
to create a secure tunnel for the parent to access.
If a container is connected to the default bridge network and `linked`
with other containers, then the container's `/etc/hosts` file is updated
with the linked container's name.
> **Note** Since Docker may live update the container’s `/etc/hosts` file, there
may be situations when processes inside the container can end up reading an
empty or incomplete `/etc/hosts` file. In most cases, retrying the read again
should fix the problem.
## Mapping Ports for External Usage
The exposed port of an application can be mapped to a host port using the **-p**
flag. For example, a httpd port 80 can be mapped to the host port 8080 using the
following:
# docker run -p 8080:80 -d -i -t fedora/httpd
## Creating and Mounting a Data Volume Container
Many applications require the sharing of persistent data across several
containers. Docker allows you to create a Data Volume Container that other
containers can mount from. For example, create a named container that contains
directories /var/volume1 and /tmp/volume2. The image will need to contain these
directories so a couple of RUN mkdir instructions might be required for you
fedora-data image:
# docker run --name=data -v /var/volume1 -v /tmp/volume2 -i -t fedora-data true
# docker run --volumes-from=data --name=fedora-container1 -i -t fedora bash
Multiple --volumes-from parameters will bring together multiple data volumes from
multiple containers. And it's possible to mount the volumes that came from the
DATA container in yet another container via the fedora-container1 intermediary
container, allowing to abstract the actual data source from users of that data:
# docker run --volumes-from=fedora-container1 --name=fedora-container2 -i -t fedora bash
## Mounting External Volumes
To mount a host directory as a container volume, specify the absolute path to
the directory and the absolute path for the container directory separated by a
colon:
# docker run -v /var/db:/data1 -i -t fedora bash
When using SELinux, be aware that the host has no knowledge of container SELinux
policy. Therefore, in the above example, if SELinux policy is enforced, the
`/var/db` directory is not writable to the container. A "Permission Denied"
message will occur and an avc: message in the host's syslog.
To work around this, at time of writing this man page, the following command
needs to be run in order for the proper SELinux policy type label to be attached
to the host directory:
# chcon -Rt svirt_sandbox_file_t /var/db
Now, writing to the /data1 volume in the container will be allowed and the
changes will also be reflected on the host in /var/db.
## Using alternative security labeling
You can override the default labeling scheme for each container by specifying
the `--security-opt` flag. For example, you can specify the MCS/MLS level, a
requirement for MLS systems. Specifying the level in the following command
allows you to share the same content between containers.
# docker run --security-opt label:level:s0:c100,c200 -i -t fedora bash
An MLS example might be:
# docker run --security-opt label:level:TopSecret -i -t rhel7 bash
To disable the security labeling for this container versus running with the
`--permissive` flag, use the following command:
# docker run --security-opt label:disable -i -t fedora bash
If you want a tighter security policy on the processes within a container,
you can specify an alternate type for the container. You could run a container
that is only allowed to listen on Apache ports by executing the following
command:
# docker run --security-opt label:type:svirt_apache_t -i -t centos bash
Note:
You would have to write policy defining a `svirt_apache_t` type.
## Setting device weight
If you want to set `/dev/sda` device weight to `200`, you can specify the device
weight by `--blkio-weight-device` flag. Use the following command:
# docker run -it --blkio-weight-device "/dev/sda:200" ubuntu
## Specify isolation technology for container (--isolation)
This option is useful in situations where you are running Docker containers on
Microsoft Windows. The `--isolation <value>` option sets a container's isolation
technology. On Linux, the only supported is the `default` option which uses
Linux namespaces. These two commands are equivalent on Linux:
```
$ docker run -d busybox top
$ docker run -d --isolation default busybox top
```
On Microsoft Windows, can take any of 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.
In practice, when running on Microsoft Windows without a `daemon` option set, these two commands are equivalent:
```
$ docker run -d --isolation default busybox top
$ docker run -d --isolation process busybox top
```
If you have set the `--exec-opt isolation=hyperv` option on the Docker `daemon`, any of these commands also result in `hyperv` isolation:
```
$ docker run -d --isolation default busybox top
$ docker run -d --isolation hyperv busybox top
```
# HISTORY
April 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>
July 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
November 2015, updated by Sally O'Malley <somalley@redhat.com>

45
vendor/github.com/hyperhq/hypercli/man/docker-save.1.md generated vendored Normal file
View File

@@ -0,0 +1,45 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-save - Save an image(s) to a tar archive (streamed to STDOUT by default)
# SYNOPSIS
**docker save**
[**--help**]
[**-o**|**--output**[=*OUTPUT*]]
IMAGE [IMAGE...]
# DESCRIPTION
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**.
# OPTIONS
**--help**
Print usage statement
**-o**, **--output**=""
Write to a file, instead of STDOUT
# EXAMPLES
Save all fedora repository images to a fedora-all.tar and save the latest
fedora image to a fedora-latest.tar:
$ docker save fedora > fedora-all.tar
$ docker 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-load(1)** to load an image from a tar archive on STDIN.
# HISTORY
April 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>
November 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

65
vendor/github.com/hyperhq/hypercli/man/docker-search.1.md generated vendored Normal file
View File

@@ -0,0 +1,65 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-search - Search the Docker Hub for images
# SYNOPSIS
**docker search**
[**--automated**]
[**--help**]
[**--no-trunc**]
[**-s**|**--stars**[=*0*]]
TERM
# DESCRIPTION
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
# OPTIONS
**--automated**=*true*|*false*
Only show automated builds. The default is *false*.
**--help**
Print usage statement
**--no-trunc**=*true*|*false*
Don't truncate output. The default is *false*.
**-s**, **--stars**=*X*
Only displays with at least X stars. The default is zero.
# 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 -s 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 --automated -s 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]
# HISTORY
April 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>
April 2015, updated by Mary Anthony for v2 <mary@docker.com>

39
vendor/github.com/hyperhq/hypercli/man/docker-start.1.md generated vendored Normal file
View File

@@ -0,0 +1,39 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-start - Start one or more containers
# SYNOPSIS
**docker start**
[**-a**|**--attach**]
[**--detach-keys**[=*[]*]]
[**--help**]
[**-i**|**--interactive**]
CONTAINER [CONTAINER...]
# DESCRIPTION
Start one or more containers.
# OPTIONS
**-a**, **--attach**=*true*|*false*
Attach container's STDOUT and STDERR and forward all signals to the
process. The default is *false*.
**--detach-keys**=""
Override the key sequence for detaching a container. Format is a single character `[a-Z]` or `ctrl-<value>` where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`.
**--help**
Print usage statement
**-i**, **--interactive**=*true*|*false*
Attach container's STDIN. The default is *false*.
# See also
**docker-stop(1)** to stop a container.
# HISTORY
April 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>

43
vendor/github.com/hyperhq/hypercli/man/docker-stats.1.md generated vendored Normal file
View File

@@ -0,0 +1,43 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-stats - Display a live stream of one or more containers' resource usage statistics
# SYNOPSIS
**docker stats**
[**-a**|**--all**]
[**--help**]
[**--no-stream**]
[CONTAINER...]
# DESCRIPTION
Display a live stream of one or more containers' resource usage statistics
# OPTIONS
**-a**, **--all**=*true*|*false*
Show all containers. Only running containers are shown by default. The default is *false*.
**--help**
Print usage statement
**--no-stream**=*true*|*false*
Disable streaming stats and only pull the first result, default setting is false.
# EXAMPLES
Running `docker stats` on all running containers
$ docker stats
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O
1285939c1fd3 0.07% 796 KB / 64 MB 1.21% 788 B / 648 B 3.568 MB / 512 KB
9c76f7834ae2 0.07% 2.746 MB / 64 MB 4.29% 1.266 KB / 648 B 12.4 MB / 0 B
d1ea048f04e4 0.03% 4.583 MB / 64 MB 6.30% 2.854 KB / 648 B 27.7 MB / 0 B
Running `docker stats` on multiple containers by name and id.
$ docker stats fervent_panini 5acfcb1b4fd1
CONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/O
5acfcb1b4fd1 0.00% 115.2 MB/1.045 GB 11.03% 1.422 kB/648 B
fervent_panini 0.02% 11.08 MB/1.045 GB 1.06% 648 B/648 B

30
vendor/github.com/hyperhq/hypercli/man/docker-stop.1.md generated vendored Normal file
View File

@@ -0,0 +1,30 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-stop - Stop a container by sending SIGTERM and then SIGKILL after a grace period
# SYNOPSIS
**docker stop**
[**--help**]
[**-t**|**--time**[=*10*]]
CONTAINER [CONTAINER...]
# DESCRIPTION
Stop a container (Send SIGTERM, and then SIGKILL after
grace period)
# OPTIONS
**--help**
Print usage statement
**-t**, **--time**=*10*
Number of seconds to wait for the container to stop before killing it. Default is 10 seconds.
#See also
**docker-start(1)** to restart a stopped container.
# HISTORY
April 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>

61
vendor/github.com/hyperhq/hypercli/man/docker-tag.1.md generated vendored Normal file
View File

@@ -0,0 +1,61 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-tag - Tag an image into a repository
# SYNOPSIS
**docker tag**
[**--help**]
IMAGE[:TAG] [REGISTRY_HOST/][USERNAME/]NAME[:TAG]
# DESCRIPTION
Assigns a new alias to an image in a registry. An alias refers to the
entire image name including the optional `TAG` after the ':'.
If you do not specify a `REGISTRY_HOST`, the command uses Docker's public
registry located at `registry-1.docker.io` by default.
# "OPTIONS"
**--help**
Print usage statement.
**REGISTRY_HOST**
The hostname of the registry if required. This may also include the port
separated by a ':'
**USERNAME**
The username or other qualifying identifier for the image.
**NAME**
The image name.
**TAG**
The tag you are assigning to the image. Though this is arbitrary it is
recommended to be used for a version to distinguish images with the same name.
Also, for consistency tags should only include a-z0-9-_. .
Note that here TAG is a part of the overall name or "tag".
# EXAMPLES
## Giving an image a new alias
Here is an example of aliasing an image (e.g., 0e5574283393) as "httpd" and
tagging it into the "fedora" repository with "version1.0":
docker tag 0e5574283393 fedora/httpd:version1.0
## 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 tag 0e5574283393 myregistryhost:5000/fedora/httpd:version1.0
# HISTORY
April 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>
July 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
April 2015, updated by Mary Anthony for v2 <mary@docker.com>
June 2015, updated by Sally O'Malley <somalley@redhat.com>

36
vendor/github.com/hyperhq/hypercli/man/docker-top.1.md generated vendored Normal file
View File

@@ -0,0 +1,36 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-top - Display the running processes of a container
# SYNOPSIS
**docker top**
[**--help**]
CONTAINER [ps OPTIONS]
# DESCRIPTION
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.
# OPTIONS
**--help**
Print usage statement
# EXAMPLES
Run **docker top** with the ps option of -x:
$ docker top 8601afda2b -x
PID TTY STAT TIME COMMAND
16623 ? Ss 0:00 sleep 99999
# HISTORY
April 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 Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
December 2015, updated by Pavel Pospisil <pospispa@gmail.com>

27
vendor/github.com/hyperhq/hypercli/man/docker-unpause.1.md generated vendored Normal file
View File

@@ -0,0 +1,27 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-unpause - Unpause all processes within a container
# SYNOPSIS
**docker unpause**
CONTAINER [CONTAINER...]
# DESCRIPTION
The `docker unpause` command uses the cgroups freezer to un-suspend all
processes in a container.
See the [cgroups freezer documentation]
(https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt) for
further details.
# OPTIONS
There are no available options.
# See also
**docker-pause(1)** to pause all processes within a container.
# HISTORY
June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

93
vendor/github.com/hyperhq/hypercli/man/docker-update.1.md generated vendored Normal file
View File

@@ -0,0 +1,93 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-update - Update resource configs of one or more containers
# SYNOPSIS
**docker update**
[**--blkio-weight**[=*[BLKIO-WEIGHT]*]]
[**--cpu-shares**[=*0*]]
[**--cpu-period**[=*0*]]
[**--cpu-quota**[=*0*]]
[**--cpuset-cpus**[=*CPUSET-CPUS*]]
[**--cpuset-mems**[=*CPUSET-MEMS*]]
[**--help**]
[**--kernel-memory**[=*KERNEL-MEMORY*]]
[**-m**|**--memory**[=*MEMORY*]]
[**--memory-reservation**[=*MEMORY-RESERVATION*]]
[**--memory-swap**[=*MEMORY-SWAP*]]
CONTAINER [CONTAINER...]
# DESCRIPTION
The `docker update` command dynamically updates container resources. 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` value, you can specify these
options on a running or a stopped container. You can only update
`--kernel-memory` on a stopped container. When you run `docker update` on
stopped container, the next time you restart it, the container uses those
values.
# OPTIONS
**--blkio-weight**=0
Block IO weight (relative weight) accepts a weight value between 10 and 1000.
**--cpu-shares**=0
CPU shares (relative weight)
**--cpu-period**=0
Limit the CPU CFS (Completely Fair Scheduler) period
**--cpu-quota**=0
Limit the CPU CFS (Completely Fair Scheduler) quota
**--cpuset-cpus**=""
CPUs in which to allow execution (0-3, 0,1)
**--cpuset-mems**=""
Memory nodes(MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
**--help**
Print usage statement
**--kernel-memory**=""
Kernel memory limit (format: `<number>[<unit>]`, where unit = b, k, m or g)
Note that you can not update kernel memory to a running container, it can only
be updated to a stopped container, and affect after it's started.
**-m**, **--memory**=""
Memory limit (format: <number><optional unit>, where unit = b, k, m or g)
**--memory-reservation**=""
Memory soft limit (format: <number>[<unit>], where unit = b, k, m or g)
**--memory-swap**=""
Total memory limit (memory + swap)
# EXAMPLES
The following sections illustrate ways to use this command.
### Update a container with cpu-shares=512
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 update --cpu-shares 512 abebf7571666
```
### Update a container with cpu-shares and memory
To update multiple resource configurations for multiple containers:
```bash
$ docker update --cpu-shares 512 -m 300M abebf7571666 hopeful_morse
```

62
vendor/github.com/hyperhq/hypercli/man/docker-version.1.md generated vendored Normal file
View File

@@ -0,0 +1,62 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2015
# NAME
docker-version - Show the Docker version information.
# SYNOPSIS
**docker version**
[**--help**]
[**-f**|**--format**[=*FORMAT*]]
# DESCRIPTION
This command displays version information for both the Docker client and
daemon.
# OPTIONS
**--help**
Print usage statement
**-f**, **--format**=""
Format the output using the given go template.
# 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"}}
# HISTORY
June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>
June 2015, updated by John Howard <jhoward@microsoft.com>
June 2015, updated by Patrick Hemmer <patrick.hemmer@gmail.com

55
vendor/github.com/hyperhq/hypercli/man/docker-volume-create.1.md generated vendored Normal file
View File

@@ -0,0 +1,55 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JULY 2015
# NAME
docker-volume-create - Create a new volume
# SYNOPSIS
**docker volume create**
[**-d**|**--driver**[=*DRIVER*]]
[**--help**]
[**--name**[=*NAME*]]
[**-o**|**--opt**[=*[]*]]
# DESCRIPTION
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 --name 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).
*Note*: The built-in `local` volume driver does not currently accept any options.
# OPTIONS
**-d**, **--driver**="*local*"
Specify volume driver name
**--help**
Print usage statement
**--name**=""
Specify volume name
**-o**, **--opt**=[]
Set driver specific options
# HISTORY
July 2015, created by Brian Goff <cpuguy83@gmail.com>

29
vendor/github.com/hyperhq/hypercli/man/docker-volume-inspect.1.md generated vendored Normal file
View File

@@ -0,0 +1,29 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JULY 2015
# NAME
docker-volume-inspect - Get low-level information about a volume
# SYNOPSIS
**docker volume inspect**
[**-f**|**--format**[=*FORMAT*]]
[**--help**]
VOLUME [VOLUME...]
# DESCRIPTION
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
http://golang.org/pkg/text/template/ package describes all the details of the
format.
# OPTIONS
**-f**, **--format**=""
Format the output using the given go template.
**--help**
Print usage statement
# HISTORY
July 2015, created by Brian Goff <cpuguy83@gmail.com>

30
vendor/github.com/hyperhq/hypercli/man/docker-volume-ls.1.md generated vendored Normal file
View File

@@ -0,0 +1,30 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JULY 2015
# NAME
docker-volume-ls - List all volumes
# SYNOPSIS
**docker volume ls**
[**-f**|**--filter**[=*FILTER*]]
[**--help**]
[**-q**|**--quiet**[=*true*|*false*]]
# DESCRIPTION
Lists all the volumes Docker knows about. 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"`)
There is a single supported filter `dangling=value` which takes a boolean of `true` or `false`.
# OPTIONS
**-f**, **--filter**=""
Provide filter values (i.e. 'dangling=true')
**--help**
Print usage statement
**-q**, **--quiet**=*true*|*false*
Only display volume names
# HISTORY
July 2015, created by Brian Goff <cpuguy83@gmail.com>

26
vendor/github.com/hyperhq/hypercli/man/docker-volume-rm.1.md generated vendored Normal file
View File

@@ -0,0 +1,26 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JULY 2015
# NAME
docker-volume-rm - Remove a volume
# SYNOPSIS
**docker volume rm**
[**--help**]
VOLUME [VOLUME...]
# DESCRIPTION
Removes one or more volumes. You cannot remove a volume that is in use by a container.
```
$ docker volume rm hello
hello
```
# OPTIONS
**--help**
Print usage statement
# HISTORY
July 2015, created by Brian Goff <cpuguy83@gmail.com>

30
vendor/github.com/hyperhq/hypercli/man/docker-wait.1.md generated vendored Normal file
View File

@@ -0,0 +1,30 @@
% DOCKER(1) Docker User Manuals
% Docker Community
% JUNE 2014
# NAME
docker-wait - Block until a container stops, then print its exit code.
# SYNOPSIS
**docker wait**
[**--help**]
CONTAINER [CONTAINER...]
# DESCRIPTION
Block until a container stops, then print its exit code.
# OPTIONS
**--help**
Print usage statement
# EXAMPLES
$ docker run -d fedora sleep 99
079b83f558a2bc52ecad6b2a5de13622d584e6bb1aea058c11b36511e85e7622
$ docker wait 079b83f558a2bc
0
# HISTORY
April 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>

244
vendor/github.com/hyperhq/hypercli/man/docker.1.md generated vendored Normal file
View File

@@ -0,0 +1,244 @@
% DOCKER(1) Docker User Manuals
% William Henry
% APRIL 2014
# NAME
docker \- Docker image and container command line interface
# SYNOPSIS
**docker** [OPTIONS] COMMAND [arg...]
**docker** daemon [--help|...]
**docker** [--help|-v|--version]
# DESCRIPTION
**docker** has two distinct functions. It is used for starting the Docker
daemon and to run the CLI (i.e., to command the daemon to manage images,
containers etc.) So **docker** is both a server, as a daemon, and a client
to the daemon, through the CLI.
To run the Docker daemon you can specify **docker daemon**.
You can view the daemon options using **docker daemon --help**.
To see the man page for the daemon, run **man docker daemon**.
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
**attach**
Attach to a running container
See **docker-attach(1)** for full documentation on the **attach** command.
**build**
Build an image from a Dockerfile
See **docker-build(1)** for full documentation on the **build** command.
**commit**
Create a new image from a container's changes
See **docker-commit(1)** for full documentation on the **commit** command.
**cp**
Copy files/folders between a container and the local filesystem
See **docker-cp(1)** for full documentation on the **cp** command.
**create**
Create a new container
See **docker-create(1)** for full documentation on the **create** command.
**diff**
Inspect changes on a container's filesystem
See **docker-diff(1)** for full documentation on the **diff** command.
**events**
Get real time events from the server
See **docker-events(1)** for full documentation on the **events** command.
**exec**
Run a command in a running container
See **docker-exec(1)** for full documentation on the **exec** command.
**export**
Stream the contents of a container as a tar archive
See **docker-export(1)** for full documentation on the **export** command.
**history**
Show the history of an image
See **docker-history(1)** for full documentation on the **history** command.
**images**
List images
See **docker-images(1)** for full documentation on the **images** command.
**import**
Create a new filesystem image from the contents of a tarball
See **docker-import(1)** for full documentation on the **import** command.
**info**
Display system-wide information
See **docker-info(1)** for full documentation on the **info** command.
**inspect**
Return low-level information on a container or image
See **docker-inspect(1)** for full documentation on the **inspect** command.
**kill**
Kill a running container (which includes the wrapper process and everything
inside it)
See **docker-kill(1)** for full documentation on the **kill** command.
**load**
Load an image from a tar archive
See **docker-load(1)** for full documentation on the **load** command.
**login**
Register or login to a Docker Registry
See **docker-login(1)** for full documentation on the **login** command.
**logout**
Log the user out of a Docker Registry
See **docker-logout(1)** for full documentation on the **logout** command.
**logs**
Fetch the logs of a container
See **docker-logs(1)** for full documentation on the **logs** command.
**pause**
Pause all processes within a container
See **docker-pause(1)** for full documentation on the **pause** command.
**port**
Lookup the public-facing port which is NAT-ed to PRIVATE_PORT
See **docker-port(1)** for full documentation on the **port** command.
**ps**
List containers
See **docker-ps(1)** for full documentation on the **ps** command.
**pull**
Pull an image or a repository from a Docker Registry
See **docker-pull(1)** for full documentation on the **pull** command.
**push**
Push an image or a repository to a Docker Registry
See **docker-push(1)** for full documentation on the **push** command.
**rename**
Rename a container.
See **docker-rename(1)** for full documentation on the **rename** command.
**restart**
Restart a container
See **docker-restart(1)** for full documentation on the **restart** command.
**rm**
Remove one or more containers
See **docker-rm(1)** for full documentation on the **rm** command.
**rmi**
Remove one or more images
See **docker-rmi(1)** for full documentation on the **rmi** command.
**run**
Run a command in a new container
See **docker-run(1)** for full documentation on the **run** command.
**save**
Save an image to a tar archive
See **docker-save(1)** for full documentation on the **save** command.
**search**
Search for an image in the Docker index
See **docker-search(1)** for full documentation on the **search** command.
**start**
Start a container
See **docker-start(1)** for full documentation on the **start** command.
**stats**
Display a live stream of one or more containers' resource usage statistics
See **docker-stats(1)** for full documentation on the **stats** command.
**stop**
Stop a container
See **docker-stop(1)** for full documentation on the **stop** command.
**tag**
Tag an image into a repository
See **docker-tag(1)** for full documentation on the **tag** command.
**top**
Lookup the running processes of a container
See **docker-top(1)** for full documentation on the **top** command.
**unpause**
Unpause all processes within a container
See **docker-unpause(1)** for full documentation on the **unpause** command.
**version**
Show the Docker version information
See **docker-version(1)** for full documentation on the **version** command.
**wait**
Block until a container stops, then print its exit code
See **docker-wait(1)** for full documentation on the **wait** command.
# EXEC DRIVER OPTIONS
Use the **--exec-opt** flags to specify options to the execution driver.
The following options are available:
#### native.cgroupdriver
Specifies the management of the container's `cgroups`. You can specify
`cgroupfs` or `systemd`. If you specify `systemd` and it is not available, the
system uses `cgroupfs`.
#### Client
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.

22
vendor/github.com/hyperhq/hypercli/man/md2man-all.sh generated vendored Executable file
View File

@@ -0,0 +1,22 @@
#!/bin/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