docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' of github.com:docker/docker.github.io

This commit is contained in:
Jeffrey Morgan 2018-12-03 15:14:51 -05:00
parent 1f5d8fdb3e 1c090c8d82
commit 5cdb36d5a1
178 changed files with 1269 additions and 72066 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
_data/engine-cli/docker.yaml
View File

@ -2,6 +2,7 @@ command: docker
cname:
- docker attach
- docker build
- docker builder
- docker checkpoint
- docker commit
- docker config
@ -10,6 +11,7 @@ cname:
- docker create
- docker deploy
- docker diff
- docker engine
- docker events
- docker exec
- docker export
@ -59,6 +61,7 @@ cname:
clink:
- docker_attach.yaml
- docker_build.yaml
- docker_builder.yaml
- docker_checkpoint.yaml
- docker_commit.yaml
- docker_config.yaml
@ -67,6 +70,7 @@ clink:
- docker_create.yaml
- docker_deploy.yaml
- docker_diff.yaml
- docker_engine.yaml
- docker_events.yaml
- docker_exec.yaml
- docker_export.yaml

91
_data/engine-cli/docker_build.yaml
View File

@ -293,6 +293,16 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: progress
value_type: string
default_value: auto
description: |
Set type of progress output (auto, plain, tty). Use plain to show container output
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: pull
value_type: bool
default_value: "false"
@ -321,6 +331,17 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: secret
value_type: stringArray
default_value: '[]'
description: |
Secret file to expose to the build (only if BuildKit enabled): id=mysecret,src=/local/secret
deprecated: false
min_api_version: "1.39"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: security-opt
value_type: stringSlice
default_value: '[]'
@ -349,6 +370,17 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: ssh
value_type: stringArray
default_value: '[]'
description: |
SSH agent socket or keys to expose to the build (only if BuildKit enabled) (format: default|<id>[=<socket>|<key>[,<key>]])
deprecated: false
min_api_version: "1.39"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: stream
value_type: bool
default_value: "false"
@ -477,21 +509,27 @@ examples: "### Build with PATH\n\n```bash\n$ docker build .\n\nUploading context
build an image on.\n\nA good example is `http_proxy` or source versions for pulling
intermediate\nfiles. The `ARG` instruction lets Dockerfile authors define values
that users\ncan set at build-time using the `--build-arg` flag:\n\n```bash\n$ docker
build --build-arg HTTP_PROXY=http://10.20.30.2:1234 .\n```\n\nThis flag allows you
to pass the build-time variables that are\naccessed like regular environment variables
in the `RUN` instruction of the\nDockerfile. Also, these values don't persist in
the intermediate or final images\nlike `ENV` values do.\n\nUsing this flag will
not alter the output you see when the `ARG` lines from the\nDockerfile are echoed
during the build process.\n\nFor detailed information on using `ARG` and `ENV` instructions,
see the\n[Dockerfile reference](../builder.md).\n\n### Optional security options
(--security-opt)\n\nThis flag is only supported on a daemon running on Windows,
and only supports\nthe `credentialspec` option. The `credentialspec` must be in
the format\n`file://spec.txt` or `registry://keyname`.\n\n### Specify isolation
technology for container (--isolation)\n\nThis option is useful in situations where
you are running Docker containers on\nWindows. The `--isolation=<value>` option
sets a container's isolation\ntechnology. On Linux, the only supported is the `default`
option which uses\nLinux namespaces. On Microsoft Windows, you can specify these
values:\n\n\n| Value | Description |\n|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|\n|
build --build-arg HTTP_PROXY=http://10.20.30.2:1234 --build-arg FTP_PROXY=http://40.50.60.5:4567
.\n```\n\nThis flag allows you to pass the build-time variables that are\naccessed
like regular environment variables in the `RUN` instruction of the\nDockerfile.
Also, these values don't persist in the intermediate or final images\nlike `ENV`
values do. You must add `--build-arg` for each build argument. \n\nUsing this
flag will not alter the output you see when the `ARG` lines from the\nDockerfile
are echoed during the build process.\n\nFor detailed information on using `ARG`
and `ENV` instructions, see the\n[Dockerfile reference](../builder.md).\n\nYou may
also use the `--build-arg` flag without a value, in which case the value\nfrom the
local environment will be propagated into the Docker container being\nbuilt:\n\n```bash\n$
export HTTP_PROXY=http://10.20.30.2:1234\n$ docker build --build-arg HTTP_PROXY
.\n```\n\nThis is similar to how `docker run -e` works. Refer to the [`docker run`
documentation](https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file)\nfor
more information.\n\n### Optional security options (--security-opt)\n\nThis flag
is only supported on a daemon running on Windows, and only supports\nthe `credentialspec`
option. The `credentialspec` must be in the format\n`file://spec.txt` or `registry://keyname`.\n\n###
Specify isolation technology for container (--isolation)\n\nThis option is useful
in situations where you are running Docker containers on\nWindows. The `--isolation=<value>`
option sets a container's isolation\ntechnology. On Linux, the only supported is
the `default` option which uses\nLinux namespaces. On Microsoft Windows, you can
specify these values:\n\n\n| Value | Description |\n|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|\n|
`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. |\n| `process` | Namespace isolation only. |\n|
@ -519,19 +557,18 @@ examples: "### Build with PATH\n\n```bash\n$ docker build .\n\nUploading context
sharing layers between\nimages (saving space).\n\nFor most use cases, multi-stage
are a better alternative, as they give more\nfine-grained control over your build,
and can take advantage of future\noptimizations in the builder. Refer to the [use
multi-stage builds](https://docs.docker.com/engine/userguide/eng-image/multistage-build/)\nsection
multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/)\nsection
in the userguide for more information.\n\n\n#### Known limitations\n\nThe `--squash`
option has a number of known limitations:\n\n- When squashing layers, the resulting
image cannot take advantage of layer \n sharing with other images, and may use
significantly more space. Sharing the\n base image is still supported.\n- When
using this option you may see significantly more space used due to\n storing two
copies of the image, one for the build cache with all the cache\n layers in tact,
and one for the squashed version.\n- While squashing layers may produce smaller
images, it may have a negative\n impact on performance, as a single layer takes
longer to extract, and\n downloading a single layer cannot be parallelized.\n-
When attempting to squash an image that does not make changes to the\n filesystem
(for example, the Dockerfile only contains `ENV` instructions),\n the squash step
will fail (see [issue #33823](https://github.com/moby/moby/issues/33823)\n\n####
image cannot take advantage of layer\n sharing with other images, and may use significantly
more space. Sharing the\n base image is still supported.\n- When using this option
you may see significantly more space used due to\n storing two copies of the image,
one for the build cache with all the cache\n layers in tact, and one for the squashed
version.\n- While squashing layers may produce smaller images, it may have a negative\n
\ impact on performance, as a single layer takes longer to extract, and\n downloading
a single layer cannot be parallelized.\n- When attempting to squash an image that
does not make changes to the\n filesystem (for example, the Dockerfile only contains
`ENV` instructions),\n the squash step will fail (see [issue #33823](https://github.com/moby/moby/issues/33823)\n\n####
Prerequisites\n\nThe example on this page is using experimental mode in Docker 1.13.\n\nExperimental
mode can be enabled by using the `--experimental` flag when starting the Docker
daemon or setting `experimental: true` in the `daemon.json` configuration file.\n\nBy
@ -551,7 +588,7 @@ examples: "### Build with PATH\n\n```bash\n$ docker build .\n\nUploading context
>> /hello\nRUN touch remove_me /remove_me\nENV HELLO world\nRUN rm /remove_me\n```\n\nAn
image named `test` is built with `--squash` argument.\n\n```bash\n$ docker build
--squash -t test .\n\n[...]\n```\n\nIf everything is right, the history will look
like this:\n\n```bash\n$ docker history test \n\nIMAGE CREATED CREATED
like this:\n\n```bash\n$ docker history test\n\nIMAGE CREATED CREATED
BY SIZE COMMENT\n4e10cb5b4cac
\ 3 seconds ago 12 B
\ merge sha256:88a7b0112a41826885df0e7072698006ee8f621c6ab99fca7fe9151d7b599702

16
_data/engine-cli/docker_builder.yaml Normal file
View File

@ -0,0 +1,16 @@
command: docker builder
short: Manage builds
long: Manage builds
usage: docker builder
pname: docker
plink: docker.yaml
cname:
- docker builder prune
clink:
- docker_builder_prune.yaml
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false

51
_data/engine-cli/docker_builder_prune.yaml Normal file
View File

@ -0,0 +1,51 @@
command: docker builder prune
short: Remove build cache
long: Remove build cache
usage: docker builder prune
pname: docker builder
plink: docker_builder.yaml
options:
- option: all
shorthand: a
value_type: bool
default_value: "false"
description: Remove all unused images, not just dangling ones
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: filter
value_type: filter
description: Provide filter values (e.g. 'unused-for=24h')
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: force
shorthand: f
value_type: bool
default_value: "false"
description: Do not prompt for confirmation
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: keep-storage
value_type: bytes
default_value: "0"
description: Amount of disk space to keep for cache
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
deprecated: false
min_api_version: "1.39"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false

1
_data/engine-cli/docker_checkpoint.yaml
View File

@ -18,4 +18,5 @@ experimental: true
experimentalcli: false
kubernetes: false
swarm: false
os_type: linux

1
_data/engine-cli/docker_checkpoint_create.yaml
View File

@ -28,4 +28,5 @@ experimental: true
experimentalcli: false
kubernetes: false
swarm: false
os_type: linux

1
_data/engine-cli/docker_checkpoint_ls.yaml
View File

@ -20,4 +20,5 @@ experimental: true
experimentalcli: false
kubernetes: false
swarm: false
os_type: linux

1
_data/engine-cli/docker_checkpoint_rm.yaml
View File

@ -20,4 +20,5 @@ experimental: true
experimentalcli: false
kubernetes: false
swarm: false
os_type: linux

4
_data/engine-cli/docker_container_create.yaml
View File

@ -82,6 +82,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: cpu-percent
value_type: int64
default_value: "0"
@ -91,6 +92,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: cpu-period
value_type: int64
default_value: "0"
@ -394,6 +396,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: io-maxiops
value_type: uint64
default_value: "0"
@ -403,6 +406,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: ip
value_type: string
description: IPv4 address (e.g., 172.30.100.104)

4
_data/engine-cli/docker_container_run.yaml
View File

@ -82,6 +82,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: cpu-percent
value_type: int64
default_value: "0"
@ -91,6 +92,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: cpu-period
value_type: int64
default_value: "0"
@ -412,6 +414,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: io-maxiops
value_type: uint64
default_value: "0"
@ -421,6 +424,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: ip
value_type: string
description: IPv4 address (e.g., 172.30.100.104)

2
_data/engine-cli/docker_container_start.yaml
View File

@ -23,6 +23,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: linux
- option: checkpoint-dir
value_type: string
description: Use a custom checkpoint storage directory
@ -31,6 +32,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: linux
- option: detach-keys
value_type: string
description: Override the key sequence for detaching a container

6
_data/engine-cli/docker_create.yaml
View File

@ -93,6 +93,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: cpu-percent
value_type: int64
default_value: "0"
@ -102,6 +103,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: cpu-period
value_type: int64
default_value: "0"
@ -405,6 +407,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: io-maxiops
value_type: uint64
default_value: "0"
@ -414,6 +417,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: ip
value_type: string
description: IPv4 address (e.g., 172.30.100.104)
@ -961,7 +965,7 @@ examples: |-
Then, a user could ask `udev` to execute a script that would `docker exec my-container mknod newDevX c 42 <minor>`
the required device when it is added.
NOTE: initially present devices still need to be explicitely added to
NOTE: initially present devices still need to be explicitly added to
the create/run command
deprecated: false
experimental: false

12
_data/engine-cli/docker_deploy.yaml
View File

@ -19,13 +19,21 @@ options:
shorthand: c
value_type: stringSlice
default_value: '[]'
description: Path to a Compose file
description: Path to a Compose file, or "-" to read from stdin
deprecated: false
min_api_version: "1.25"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: namespace
value_type: string
description: Kubernetes namespace to use
deprecated: false
experimental: false
experimentalcli: false
kubernetes: true
swarm: false
- option: prune
value_type: bool
default_value: "false"
@ -122,5 +130,5 @@ min_api_version: "1.25"
experimental: true
experimentalcli: false
kubernetes: false
swarm: true
swarm: false

20
_data/engine-cli/docker_engine.yaml Normal file
View File

@ -0,0 +1,20 @@
command: docker engine
short: Manage the docker engine
long: Manage the docker engine
usage: docker engine COMMAND
pname: docker
plink: docker.yaml
cname:
- docker engine activate
- docker engine check
- docker engine update
clink:
- docker_engine_activate.yaml
- docker_engine_check.yaml
- docker_engine_update.yaml
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false

95
_data/engine-cli/docker_engine_activate.yaml Normal file
View File

@ -0,0 +1,95 @@
command: docker engine activate
short: Activate Enterprise Edition
long: |
Activate Enterprise Edition.
With this command you may apply an existing Docker enterprise license, or
interactively download one from Docker. In the interactive exchange, you can
sign up for a new trial, or download an existing license. If you are
currently running a Community Edition engine, the daemon will be updated to
the Enterprise Edition Docker engine with additional capabilities and long
term support.
For more information about different Docker Enterprise license types visit
https://www.docker.com/licenses
For non-interactive scriptable deployments, download your license from
https://hub.docker.com/ then specify the file with the '--license' flag.
usage: docker engine activate [OPTIONS]
pname: docker engine
plink: docker_engine.yaml
options:
- option: containerd
value_type: string
description: override default location of containerd endpoint
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: display-only
value_type: bool
default_value: "false"
description: only display license information and exit
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: engine-image
value_type: string
description: Specify engine image
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: format
value_type: string
description: Pretty-print licenses using a Go template
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: license
value_type: string
description: License File
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: quiet
value_type: bool
default_value: "false"
description: Only display available licenses by ID
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: registry-prefix
value_type: string
default_value: docker.io/store/docker
description: Override the default location where engine images are pulled
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: version
value_type: string
description: |
Specify engine version (default is to use currently running version)
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false

85
_data/engine-cli/docker_engine_check.yaml Normal file
View File

@ -0,0 +1,85 @@
command: docker engine check
short: Check for available engine updates
long: Check for available engine updates
usage: docker engine check [OPTIONS]
pname: docker engine
plink: docker_engine.yaml
options:
- option: containerd
value_type: string
description: override default location of containerd endpoint
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: downgrades
value_type: bool
default_value: "false"
description: Report downgrades (default omits older versions)
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: engine-image
value_type: string
description: |
Specify engine image (default uses the same image as currently running)
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: format
value_type: string
description: Pretty-print updates using a Go template
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: pre-releases
value_type: bool
default_value: "false"
description: Include pre-release versions
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: quiet
shorthand: q
value_type: bool
default_value: "false"
description: Only display available versions
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: registry-prefix
value_type: string
default_value: docker.io/store/docker
description: |
Override the existing location where engine images are pulled
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: upgrades
value_type: bool
default_value: "true"
description: Report available upgrades
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false

47
_data/engine-cli/docker_engine_update.yaml Normal file
View File

@ -0,0 +1,47 @@
command: docker engine update
short: Update a local engine
long: Update a local engine
usage: docker engine update [OPTIONS]
pname: docker engine
plink: docker_engine.yaml
options:
- option: containerd
value_type: string
description: override default location of containerd endpoint
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: engine-image
value_type: string
description: |
Specify engine image (default uses the same image as currently running)
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: registry-prefix
value_type: string
default_value: docker.io/store/docker
description: Override the current location where engine images are pulled
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: version
value_type: string
description: Specify engine version
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false

1
_data/engine-cli/docker_events.yaml
View File

@ -19,6 +19,7 @@ long: |-
- `die`
- `exec_create`
- `exec_detach`
- `exec_die`
- `exec_start`
- `export`
- `health_status`

2
_data/engine-cli/docker_export.yaml
View File

@ -6,7 +6,7 @@ long: |-
the container, `docker export` will export the contents of the *underlying*
directory, not the contents of the volume.
Refer to [Backup, restore, or migrate data volumes](https://docs.docker.com/engine/tutorials/dockervolumes/#backup-restore-or-migrate-data-volumes)
Refer to [Backup, restore, or migrate data volumes](https://docs.docker.com/v17.03/engine/tutorials/dockervolumes/#backup-restore-or-migrate-data-volumes)
in the user guide for examples on exporting data in a volume.
usage: docker export [OPTIONS] CONTAINER
pname: docker

14
_data/engine-cli/docker_history.yaml
View File

@ -89,19 +89,13 @@ examples: |-
`table` directive, will include column headers as well.
The following example uses a template without headers and outputs the
`ID` and `CreatedSince` entries separated by a colon for all images:
`ID` and `CreatedSince` entries separated by a colon for the `busybox` image:
```bash
$ docker images --format "{{.ID}}: {{.Created}} ago"
$ docker history --format "{{.ID}}: {{.CreatedSince}}" busybox
cc1b61406712: 2 weeks ago
<missing>: 2 weeks ago
<missing>: 2 weeks ago
<missing>: 2 weeks ago
<missing>: 2 weeks ago
<missing>: 3 weeks ago
<missing>: 3 weeks ago
<missing>: 3 weeks ago
f6e427c148a7: 4 weeks ago
<missing>: 4 weeks ago
```
deprecated: false
experimental: false

32
_data/engine-cli/docker_image_build.yaml
View File

@ -191,6 +191,16 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: progress
value_type: string
default_value: auto
description: |
Set type of progress output (auto, plain, tty). Use plain to show container output
deprecated: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: pull
value_type: bool
default_value: "false"
@ -219,6 +229,17 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: secret
value_type: stringArray
default_value: '[]'
description: |
Secret file to expose to the build (only if BuildKit enabled): id=mysecret,src=/local/secret
deprecated: false
min_api_version: "1.39"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: security-opt
value_type: stringSlice
default_value: '[]'
@ -247,6 +268,17 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: ssh
value_type: stringArray
default_value: '[]'
description: |
SSH agent socket or keys to expose to the build (only if BuildKit enabled) (format: default|<id>[=<socket>|<key>[,<key>]])
deprecated: false
min_api_version: "1.39"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: stream
value_type: bool
default_value: "false"

9
_data/engine-cli/docker_image_import.yaml
View File

@ -23,6 +23,15 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: platform
value_type: string
description: Set platform if server is multi-platform capable
deprecated: false
min_api_version: "1.32"
experimental: true
experimentalcli: false
kubernetes: false
swarm: false
deprecated: false
experimental: false
experimentalcli: false

9
_data/engine-cli/docker_import.yaml
View File

@ -35,6 +35,15 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: platform
value_type: string
description: Set platform if server is multi-platform capable
deprecated: false
min_api_version: "1.32"
experimental: true
experimentalcli: false
kubernetes: false
swarm: false
examples: |-
### Import from a remote location

86
_data/engine-cli/docker_login.yaml
View File

@ -25,49 +25,49 @@ long: "Login to a registry.\n\n### Login to a self-hosted registry\n\nIf you wan
helpers and where\nyou can download them from:\n\n- D-Bus Secret Service: https://github.com/docker/docker-credential-helpers/releases\n-
Apple macOS keychain: https://github.com/docker/docker-credential-helpers/releases\n-
Microsoft Windows Credential Manager: https://github.com/docker/docker-credential-helpers/releases\n-
[pass](https://www.passwordstore.org/): https://github.com/docker/docker-credential-helpers/releases\n\nYou
need to specify the credentials store in `$HOME/.docker/config.json`\nto tell the
docker engine to use it. The value of the config property should be\nthe suffix
of the program to use (i.e. everything after `docker-credential-`).\nFor example,
to use `docker-credential-osxkeychain`:\n\n```json\n{\n\t\"credsStore\": \"osxkeychain\"\n}\n```\n\nIf
you are currently logged in, run `docker logout` to remove\nthe credentials from
the file and run `docker login` again.\n\n### Default behavior\n\nBy default, Docker
looks for the native binary on each of the platforms, i.e.\n\"osxkeychain\" on macOS,
\"wincred\" on windows, and \"pass\" on Linux. A special\ncase is that on Linux,
Docker will fall back to the \"secretservice\" binary if\nit cannot find the \"pass\"
binary. If none of these binaries are present, it\nstores the credentials (i.e.
password) in base64 encoding in the config files\ndescribed above.\n\n### Credential
helper protocol\n\nCredential helpers can be any program or script that follows
a very simple protocol.\nThis protocol is heavily inspired by Git, but it differs
in the information shared.\n\nThe helpers always use the first argument in the command
to identify the action.\nThere are only three possible values for that argument:
`store`, `get`, and `erase`.\n\nThe `store` command takes a JSON payload from the
standard input. That payload carries\nthe server address, to identify the credential,
the user name, and either a password\nor an identity token.\n\n```json\n{\n\t\"ServerURL\":
\"https://index.docker.io/v1\",\n\t\"Username\": \"david\",\n\t\"Secret\": \"passw0rd1\"\n}\n```\n\nIf
the secret being stored is an identity token, the Username should be set to\n`<token>`.\n\nThe
`store` command can write error messages to `STDOUT` that the docker engine\nwill
show if there was an issue.\n\nThe `get` command takes a string payload from the
standard input. That payload carries\nthe server address that the docker engine
needs credentials for. This is\nan example of that payload: `https://index.docker.io/v1`.\n\nThe
`get` command writes a JSON payload to `STDOUT`. Docker reads the user name\nand
password from this payload:\n\n```json\n{\n\t\"Username\": \"david\",\n\t\"Secret\":
\"passw0rd1\"\n}\n```\n\nThe `erase` command takes a string payload from `STDIN`.
That payload carries\nthe server address that the docker engine wants to remove
credentials for. This is\nan example of that payload: `https://index.docker.io/v1`.\n\nThe
`erase` command can write error messages to `STDOUT` that the docker engine\nwill
show if there was an issue.\n\n### Credential helpers\n\nCredential helpers are
similar to the credential store above, but act as the\ndesignated programs to handle
credentials for *specific registries*. The default\ncredential store (`credsStore`
or the config file itself) will not be used for\noperations concerning credentials
of the specified registries.\n\n### Logging out\n\nIf you are currently logged in,
run `docker logout` to remove\nthe credentials from the default store.\n\nCredential
helpers are specified in a similar way to `credsStore`, but\nallow for multiple
helpers to be configured at a time. Keys specify the\nregistry domain, and values
specify the suffix of the program to use\n(i.e. everything after `docker-credential-`).\nFor
example:\n\n```json\n{\n \"credHelpers\": {\n \"registry.example.com\": \"registryhelper\",\n
\ \"awesomereg.example.org\": \"hip-star\",\n \"unicorn.example.io\": \"vcbait\"\n
\ }\n}\n```"
[pass](https://www.passwordstore.org/): https://github.com/docker/docker-credential-helpers/releases\n\n####
Configure the credentials store\n\nYou need to specify the credentials store in
`$HOME/.docker/config.json`\nto tell the docker engine to use it. The value of the
config property should be\nthe suffix of the program to use (i.e. everything after
`docker-credential-`).\nFor example, to use `docker-credential-osxkeychain`:\n\n```json\n{\n\t\"credsStore\":
\"osxkeychain\"\n}\n```\n\nIf you are currently logged in, run `docker logout` to
remove\nthe credentials from the file and run `docker login` again.\n\n#### Default
behavior\n\nBy default, Docker looks for the native binary on each of the platforms,
i.e.\n\"osxkeychain\" on macOS, \"wincred\" on windows, and \"pass\" on Linux. A
special\ncase is that on Linux, Docker will fall back to the \"secretservice\" binary
if\nit cannot find the \"pass\" binary. If none of these binaries are present, it\nstores
the credentials (i.e. password) in base64 encoding in the config files\ndescribed
above.\n\n#### Credential helper protocol\n\nCredential helpers can be any program
or script that follows a very simple protocol.\nThis protocol is heavily inspired
by Git, but it differs in the information shared.\n\nThe helpers always use the
first argument in the command to identify the action.\nThere are only three possible
values for that argument: `store`, `get`, and `erase`.\n\nThe `store` command takes
a JSON payload from the standard input. That payload carries\nthe server address,
to identify the credential, the user name, and either a password\nor an identity
token.\n\n```json\n{\n\t\"ServerURL\": \"https://index.docker.io/v1\",\n\t\"Username\":
\"david\",\n\t\"Secret\": \"passw0rd1\"\n}\n```\n\nIf the secret being stored is
an identity token, the Username should be set to\n`<token>`.\n\nThe `store` command
can write error messages to `STDOUT` that the docker engine\nwill show if there
was an issue.\n\nThe `get` command takes a string payload from the standard input.
That payload carries\nthe server address that the docker engine needs credentials
for. This is\nan example of that payload: `https://index.docker.io/v1`.\n\nThe `get`
command writes a JSON payload to `STDOUT`. Docker reads the user name\nand password
from this payload:\n\n```json\n{\n\t\"Username\": \"david\",\n\t\"Secret\": \"passw0rd1\"\n}\n```\n\nThe
`erase` command takes a string payload from `STDIN`. That payload carries\nthe server
address that the docker engine wants to remove credentials for. This is\nan example
of that payload: `https://index.docker.io/v1`.\n\nThe `erase` command can write
error messages to `STDOUT` that the docker engine\nwill show if there was an issue.\n\n###
Credential helpers\n\nCredential helpers are similar to the credential store above,
but act as the\ndesignated programs to handle credentials for *specific registries*.
The default\ncredential store (`credsStore` or the config file itself) will not
be used for\noperations concerning credentials of the specified registries.\n\n####
Configure credential helpers\n\nIf you are currently logged in, run `docker logout`
to remove\nthe credentials from the default store.\n\nCredential helpers are specified
in a similar way to `credsStore`, but\nallow for multiple helpers to be configured
at a time. Keys specify the\nregistry domain, and values specify the suffix of the
program to use\n(i.e. everything after `docker-credential-`).\nFor example:\n\n```json\n{\n
\ \"credHelpers\": {\n \"registry.example.com\": \"registryhelper\",\n \"awesomereg.example.org\":
\"hip-star\",\n \"unicorn.example.io\": \"vcbait\"\n }\n}\n```"
usage: docker login [OPTIONS] [SERVER]
pname: docker
plink: docker.yaml

2
_data/engine-cli/docker_logs.yaml
View File

@ -7,7 +7,7 @@ long: |-
> the `json-file` or `journald` logging driver.
For more information about selecting and configuring logging drivers, refer to
[Configure logging drivers](https://docs.docker.com/engine/admin/logging/overview/).
[Configure logging drivers](https://docs.docker.com/config/containers/logging/configure/).
The `docker logs --follow` command will continue streaming the new output from
the container's `STDOUT` and `STDERR`.

24
_data/engine-cli/docker_manifest.yaml
View File

@ -9,25 +9,25 @@ long: "The `docker manifest` command by itself performs no action. In order to o
in the same way as\nan image name in `docker pull` and `docker run` commands, for
example.\n\nIdeally a manifest list is created from images that are identical in
function for\ndifferent os/arch combinations. For this reason, manifest lists are
often referred to as\n\"multi-arch images.\" However, a user could create a manifest
often referred to as\n\"multi-arch images\". However, a user could create a manifest
list that points\nto two images -- one for windows on amd64, and one for darwin
on amd64.\n\n### manifest inspect\n\n```\nmanifest inspect --help\n\nUsage: docker
manifest inspect [OPTIONS] [MANIFEST_LIST] MANIFEST\n\nisplay an image manifest,
or manifest list\n\nOptions:\n --help Print usage\n --insecure allow
manifest inspect [OPTIONS] [MANIFEST_LIST] MANIFEST\n\nDisplay an image manifest,
or manifest list\n\nOptions:\n --help Print usage\n --insecure Allow
communication with an insecure registry\n -v, --verbose Output additional info
including layers and platform\n```\n\n### manifest create \n\n```bash\nUsage: docker
manifest create MANFEST_LIST MANIFEST [MANIFEST...]\n\nCreate a local manifest list
for annotating and pushing to a registry\n\nOptions:\n -a, --amend Amend an existing
manifest list\n --insecure allow communication with an insecure registry\n
\ --help Print usage\n```\n\n### manifest annotate\n```bash\nUsage: docker
manifest annotate [OPTIONS] MANIFEST_LIST MANIFEST\n\nAdd additional information
manifest create MANIFEST_LIST MANIFEST [MANIFEST...]\n\nCreate a local manifest
list for annotating and pushing to a registry\n\nOptions:\n -a, --amend Amend
an existing manifest list\n --insecure Allow communication with an insecure
registry\n --help Print usage\n```\n\n### manifest annotate\n```bash\nUsage:
\ docker manifest annotate [OPTIONS] MANIFEST_LIST MANIFEST\n\nAdd additional information
to a local image manifest\n\nOptions:\n --arch string Set architecture\n
\ --help Print usage\n --os string Set
operating system\n --os-features stringSlice Set operating system feature\n
\ --variant string Set architecture variant\n\n```\n\n### manifest
push\n```bash\nUsage: docker manifest push [OPTIONS] MANIFEST_LIST\n\nPush a manifest
list to a repository\n\nOptions:\n --help Print usage\n --insecure
\ allow push to an insecure registry\n -p, --purge Remove the local manifest
list to a repository\n\nOptions:\n --help Print usage\n --insecure
\ Allow push to an insecure registry\n -p, --purge Remove the local manifest
list after push\n```\n\n### Working with insecure registries\n\nThe manifest command
interacts solely with a Docker registry. Because of this, it has no way to query
the engine for the list of allowed insecure registries. To allow the CLI to interact
@ -51,7 +51,7 @@ clink:
- docker_manifest_create.yaml
- docker_manifest_inspect.yaml
- docker_manifest_push.yaml
examples: "### inspect an image's manifest object\n \n```bash\n$ docker manifest inspect
examples: "### Inspect an image's manifest object\n \n```bash\n$ docker manifest inspect
hello-world\n{\n \"schemaVersion\": 2,\n \"mediaType\": \"application/vnd.docker.distribution.manifest.v2+json\",\n
\ \"config\": {\n \"mediaType\": \"application/vnd.docker.container.image.v1+json\",\n
\ \"size\": 1520,\n \"digest\": \"sha256:1815c82652c03bfd8644afda26fb184f2ed891d921b20a0703b46768f9755c57\"\n
@ -64,7 +64,7 @@ examples: "### inspect an image's manifest object\n \n```bash\n$ docker manifest
as with other docker commands that take image names, you can refer to an image with
or\nwithout a tag, or by digest (e.g. hello-world@sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f).\n\nHere
is an example of inspecting an image's manifest with the `--verbose` flag:\n\n```bash\n$
docker manifest inspect -v hello-world\n{\n \"Ref\": \"docker.io/library/hello-world:latest\",\n
docker manifest inspect --verbose hello-world\n{\n \"Ref\": \"docker.io/library/hello-world:latest\",\n
\ \"Digest\": \"sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f\",\n
\ \"SchemaV2Manifest\": {\n \"schemaVersion\": 2,\n \"mediaType\":
\"application/vnd.docker.distribution.manifest.v2+json\",\n \"config\":

4
_data/engine-cli/docker_manifest_create.yaml
View File

@ -1,7 +1,7 @@
command: docker manifest create
short: Create a local manifest list for annotating and pushing to a registry
long: Create a local manifest list for annotating and pushing to a registry
usage: docker manifest create MANFEST_LIST MANIFEST [MANIFEST...]
usage: docker manifest create MANIFEST_LIST MANIFEST [MANIFEST...]
pname: docker manifest
plink: docker_manifest.yaml
options:
@ -18,7 +18,7 @@ options:
- option: insecure
value_type: bool
default_value: "false"
description: allow communication with an insecure registry
description: Allow communication with an insecure registry
deprecated: false
experimental: false
experimentalcli: false

2
_data/engine-cli/docker_manifest_inspect.yaml
View File

@ -8,7 +8,7 @@ options:
- option: insecure
value_type: bool
default_value: "false"
description: allow communication with an insecure registry
description: Allow communication with an insecure registry
deprecated: false
experimental: false
experimentalcli: false

6
_data/engine-cli/docker_rmi.yaml
View File

@ -43,11 +43,11 @@ examples: |-
Error: Conflict, cannot delete image fd484f19954f because it is tagged in multiple repositories, use -f to force
2013/12/11 05:47:16 Error: failed to remove one or more images
$ docker rmi test1
$ docker rmi test1:latest
Untagged: test1:latest
$ docker rmi test2
$ docker rmi test2:latest
Untagged: test2:latest
@ -57,7 +57,7 @@ examples: |-
REPOSITORY TAG IMAGE ID CREATED SIZE
test latest fd484f19954f 23 seconds ago 7 B (virtual 4.964 MB)
$ docker rmi test
$ docker rmi test:latest
Untagged: test:latest
Deleted: fd484f19954f4920da7ff372b5067f5b7ddb2fd3830cecd17b96ea9e286ba5b8

10
_data/engine-cli/docker_run.yaml
View File

@ -93,6 +93,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: cpu-percent
value_type: int64
default_value: "0"
@ -102,6 +103,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: cpu-period
value_type: int64
default_value: "0"
@ -423,6 +425,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: io-maxiops
value_type: uint64
default_value: "0"
@ -432,6 +435,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: windows
- option: ip
value_type: string
description: IPv4 address (e.g., 172.30.100.104)
@ -1138,7 +1142,7 @@ examples: |-
```
The `my-label` key doesn't specify a value so the label defaults to an empty
string(`""`). To add multiple labels, repeat the label flag (`-l` or `--label`).
string (`""`). To add multiple labels, repeat the label flag (`-l` or `--label`).
The `key=value` must be unique to avoid overwriting the label value. If you
specify labels with identical keys but different values, each subsequent value
@ -1312,7 +1316,7 @@ examples: |-
|:---------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `no` | Do not automatically restart the container when it exits. This is the default. |
| `on-failure[:max-retries]` | Restart only if the container exits with a non-zero exit status. Optionally, limit the number of restart retries the Docker daemon attempts. |
| `unless-stopped` | Restart the container unless it is explicitly stopped or Docker itself is stopped or restarted. |
| `unless-stopped` | Restart the container unless it is explicitly stopped or Docker itself is stopped or restarted. |
| `always` | Always restart the container regardless of the exit status. When you specify always, the Docker daemon will try to restart the container indefinitely. The container will also always start on daemon startup, regardless of the current state of the container. |
```bash
@ -1323,7 +1327,7 @@ examples: |-
so that if the container exits, Docker will restart it.
More detailed information on restart policies can be found in the
[Restart Policies (--restart)](../run.md#restart-policies-restart)
[Restart Policies (--restart)](../run.md#restart-policies---restart)
section of the Docker run reference page.
### Add entries to container hosts file (--add-host)

9
_data/engine-cli/docker_secret_create.yaml
View File

@ -1,8 +1,9 @@
command: docker secret create
short: Create a secret from a file or STDIN as content
long: "Creates a secret using standard input or from a file for the secret content.
You must run this command on a manager node. \n\nFor detailed information about
using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/)."
long: |-
Creates a secret using standard input or from a file for the secret content. You must run this command on a manager node.
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/).
usage: docker secret create [OPTIONS] SECRET [file|-]
pname: docker secret
plink: docker_secret.yaml
@ -38,7 +39,7 @@ examples: |-
### Create a secret
```bash
$ echo <secret> | docker secret create my_secret -
$ printf <secret> | docker secret create my_secret -
onakdyv307se2tl7nl20anokv

11
_data/engine-cli/docker_service_create.yaml
View File

@ -196,6 +196,17 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: init
value_type: bool
default_value: "false"
description: |
Use an init inside each service container to forward signals and reap processes
deprecated: false
min_api_version: "1.37"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: isolation
value_type: string
description: Service container isolation mode

11
_data/engine-cli/docker_service_update.yaml
View File

@ -306,6 +306,17 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: init
value_type: bool
default_value: "false"
description: |
Use an init inside each service container to forward signals and reap processes
deprecated: false
min_api_version: "1.37"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: isolation
value_type: string
description: Service container isolation mode

17
_data/engine-cli/docker_stack.yaml
View File

@ -1,7 +1,7 @@
command: docker stack
short: Manage Docker stacks
long: Manage stacks.
usage: docker stack
usage: docker stack [OPTIONS]
pname: docker
plink: docker.yaml
cname:
@ -22,22 +22,21 @@ options:
description: Kubernetes config file
deprecated: false
experimental: false
experimentalcli: true
experimentalcli: false
kubernetes: true
swarm: false
- option: namespace
- option: orchestrator
value_type: string
default_value: default
description: Kubernetes namespace to use
description: Orchestrator to use (swarm|kubernetes|all)
deprecated: false
experimental: false
experimentalcli: true
kubernetes: true
experimentalcli: false
kubernetes: false
swarm: false
deprecated: false
min_api_version: "1.25"
experimental: false
experimentalcli: false
kubernetes: true
swarm: true
kubernetes: false
swarm: false

27
_data/engine-cli/docker_stack_deploy.yaml
View File

@ -20,13 +20,21 @@ options:
shorthand: c
value_type: stringSlice
default_value: '[]'
description: Path to a Compose file
description: Path to a Compose file, or "-" to read from stdin
deprecated: false
min_api_version: "1.25"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: namespace
value_type: string
description: Kubernetes namespace to use
deprecated: false
experimental: false
experimentalcli: false
kubernetes: true
swarm: false
- option: prune
value_type: bool
default_value: "false"
@ -63,17 +71,16 @@ inherited_options:
description: Kubernetes config file
deprecated: false
experimental: false
experimentalcli: true
experimentalcli: false
kubernetes: true
swarm: false
- option: namespace
- option: orchestrator
value_type: string
default_value: default
description: Kubernetes namespace to use
description: Orchestrator to use (swarm|kubernetes|all)
deprecated: false
experimental: false
experimentalcli: true
kubernetes: true
experimentalcli: false
kubernetes: false
swarm: false
examples: |-
### Compose file
@ -117,7 +124,7 @@ examples: |-
`--compose-file` flags.
```bash
$ docker stack deploy --compose-file docker-compose.yml -f docker-compose.prod.yml vossibility
$ docker stack deploy --compose-file docker-compose.yml -c docker-compose.prod.yml vossibility
Ignoring unsupported options: links
@ -176,6 +183,6 @@ deprecated: false
min_api_version: "1.25"
experimental: false
experimentalcli: false
kubernetes: true
swarm: true
kubernetes: false
swarm: false

51
_data/engine-cli/docker_stack_ls.yaml
View File

@ -2,10 +2,19 @@ command: docker stack ls
aliases: list
short: List stacks
long: Lists the stacks.
usage: docker stack ls
usage: docker stack ls [OPTIONS]
pname: docker stack
plink: docker_stack.yaml
options:
- option: all-namespaces
value_type: bool
default_value: "false"
description: List stacks from all Kubernetes namespaces
deprecated: false
experimental: false
experimentalcli: false
kubernetes: true
swarm: false
- option: format
value_type: string
description: Pretty-print stacks using a Go template
@ -14,23 +23,31 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: namespace
value_type: stringSlice
default_value: '[]'
description: Kubernetes namespaces to use
deprecated: false
experimental: false
experimentalcli: false
kubernetes: true
swarm: false
inherited_options:
- option: kubeconfig
value_type: string
description: Kubernetes config file
deprecated: false
experimental: false
experimentalcli: true
experimentalcli: false
kubernetes: true
swarm: false
- option: namespace
- option: orchestrator
value_type: string
default_value: default
description: Kubernetes namespace to use
description: Orchestrator to use (swarm|kubernetes|all)
deprecated: false
experimental: false
experimentalcli: true
kubernetes: true
experimentalcli: false
kubernetes: false
swarm: false
examples: |-
The following command shows all stacks and some additional information:
@ -38,9 +55,9 @@ examples: |-
```bash
$ docker stack ls
ID SERVICES
vossibility-stack 6
myapp 2
ID SERVICES ORCHESTRATOR
myapp 2 Kubernetes
vossibility-stack 6 Swarm
```
### Formatting
@ -49,10 +66,12 @@ examples: |-
Valid placeholders for the Go template are listed below:
| Placeholder | Description |
| ----------- | ------------------ |
| `.Name` | Stack name |
| `.Services` | Number of services |
| Placeholder | Description |
| --------------- | ------------------ |
| `.Name` | Stack name |
| `.Services` | Number of services |
| `.Orchestrator` | Orchestrator name |
| `.Namespace` | Namespace |
When using the `--format` option, the `stack ls` command either outputs
the data exactly as the template declares or, when using the
@ -70,6 +89,6 @@ deprecated: false
min_api_version: "1.25"
experimental: false
experimentalcli: false
kubernetes: true
swarm: true
kubernetes: false
swarm: false

25
_data/engine-cli/docker_stack_ps.yaml
View File

@ -15,7 +15,7 @@ options:
experimental: false
experimentalcli: false
kubernetes: false
swarm: true
swarm: false
- option: format
value_type: string
description: Pretty-print tasks using a Go template
@ -24,6 +24,14 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: namespace
value_type: string
description: Kubernetes namespace to use
deprecated: false
experimental: false
experimentalcli: false
kubernetes: true
swarm: false
- option: no-resolve
value_type: bool
default_value: "false"
@ -58,17 +66,16 @@ inherited_options:
description: Kubernetes config file
deprecated: false
experimental: false
experimentalcli: true
experimentalcli: false
kubernetes: true
swarm: false
- option: namespace
- option: orchestrator
value_type: string
default_value: default
description: Kubernetes namespace to use
description: Orchestrator to use (swarm|kubernetes|all)
deprecated: false
experimental: false
experimentalcli: true
kubernetes: true
experimentalcli: false
kubernetes: false
swarm: false
examples: |-
### List the tasks that are part of a stack
@ -260,6 +267,6 @@ deprecated: false
min_api_version: "1.25"
experimental: false
experimentalcli: false
kubernetes: true
swarm: true
kubernetes: false
swarm: false

26
_data/engine-cli/docker_stack_rm.yaml
View File

@ -4,26 +4,34 @@ short: Remove one or more stacks
long: |-
Remove the stack from the swarm. This command has to be run targeting
a manager node.
usage: docker stack rm STACK [STACK...]
usage: docker stack rm [OPTIONS] STACK [STACK...]
pname: docker stack
plink: docker_stack.yaml
options:
- option: namespace
value_type: string
description: Kubernetes namespace to use
deprecated: false
experimental: false
experimentalcli: false
kubernetes: true
swarm: false
inherited_options:
- option: kubeconfig
value_type: string
description: Kubernetes config file
deprecated: false
experimental: false
experimentalcli: true
experimentalcli: false
kubernetes: true
swarm: false
- option: namespace
- option: orchestrator
value_type: string
default_value: default
description: Kubernetes namespace to use
description: Orchestrator to use (swarm|kubernetes|all)
deprecated: false
experimental: false
experimentalcli: true
kubernetes: true
experimentalcli: false
kubernetes: false
swarm: false
examples: |-
### Remove a stack
@ -65,6 +73,6 @@ deprecated: false
min_api_version: "1.25"
experimental: false
experimentalcli: false
kubernetes: true
swarm: true
kubernetes: false
swarm: false

42
_data/engine-cli/docker_stack_services.yaml
View File

@ -15,7 +15,7 @@ options:
experimental: false
experimentalcli: false
kubernetes: false
swarm: true
swarm: false
- option: format
value_type: string
description: Pretty-print services using a Go template
@ -24,6 +24,14 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: namespace
value_type: string
description: Kubernetes namespace to use
deprecated: false
experimental: false
experimentalcli: false
kubernetes: true
swarm: false
- option: quiet
shorthand: q
value_type: bool
@ -40,17 +48,16 @@ inherited_options:
description: Kubernetes config file
deprecated: false
experimental: false
experimentalcli: true
experimentalcli: false
kubernetes: true
swarm: false
- option: namespace
- option: orchestrator
value_type: string
default_value: default
description: Kubernetes namespace to use
description: Orchestrator to use (swarm|kubernetes|all)
deprecated: false
experimental: false
experimentalcli: true
kubernetes: true
experimentalcli: false
kubernetes: false
swarm: false
examples: |-
The following command shows all services in the `myapp` stack:
@ -82,8 +89,23 @@ examples: |-
The currently supported filters are:
* id / ID (`--filter id=7be5ei6sqeye`, or `--filter ID=7be5ei6sqeye`)
* name (`--filter name=myapp_web`)
* Swarm: supported
* Kubernetes: not supported
* label (`--filter label=key=value`)
* Swarm: supported
* Kubernetes: supported
* mode (`--filter mode=replicated`, or `--filter mode=global`)
* Swarm: not supported
* Kubernetes: supported
* name (`--filter name=myapp_web`)
* Swarm: supported
* Kubernetes: supported
* node (`--filter node=mynode`)
* Swarm: not supported
* Kubernetes: supported
* service (`--filter service=web`)
* Swarm: not supported
* Kubernetes: supported
### Formatting
@ -117,6 +139,6 @@ deprecated: false
min_api_version: "1.25"
experimental: false
experimentalcli: false
kubernetes: true
swarm: true
kubernetes: false
swarm: false

2
_data/engine-cli/docker_start.yaml
View File

@ -23,6 +23,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: linux
- option: checkpoint-dir
value_type: string
description: Use a custom checkpoint storage directory
@ -31,6 +32,7 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
os_type: linux
- option: detach-keys
value_type: string
description: Override the key sequence for detaching a container

2
_data/engine-cli/docker_stats.yaml
View File

@ -6,6 +6,8 @@ long: |-
If you want more detailed information about a container's resource usage, use the `/containers/(id)/stats` API endpoint.
> **Note**: On Linux, the Docker CLI reports memory usage by subtracting page cache usage from the total memory usage. The API does not perform such a calculation but rather provides the total memory usage and the amount from the page cache so that clients can use the data as needed.
> **Note**: The `PIDS` column contains the number of processes and kernel threads created by that container. Threads is the term used by Linux kernel. Other equivalent terms are "lightweight process" or "kernel task", etc. A large number in the `PIDS` column combined with a small number of processes (as reported by `ps` or `top`) may indicate that something in the container is creating many threads.
usage: docker stats [OPTIONS] [CONTAINER...]
pname: docker
plink: docker.yaml

29
_data/engine-cli/docker_swarm_init.yaml
View File

@ -48,6 +48,27 @@ options:
description: |
Address or interface to use for data path traffic (format: <ip|interface>)
deprecated: false
min_api_version: "1.31"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: default-addr-pool
value_type: ipNetSlice
default_value: '[]'
description: default address pool in CIDR format
deprecated: false
min_api_version: "1.39"
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: default-addr-pool-mask-length
value_type: uint32
default_value: "24"
description: default address pool subnet mask length
deprecated: false
min_api_version: "1.39"
experimental: false
experimentalcli: false
kubernetes: false
@ -202,6 +223,14 @@ examples: |-
If unspecified, Docker will use the same IP address or interface that is used for the
advertise address.
### `--default-addr-pool`
This flag specifies default subnet pools for global scope networks.
Format example is `--default-addr-pool 30.30.0.0/16 --default-addr-pool 40.40.0.0/16`
### `--default-addr-pool-mask-length`
This flag specifies default subnet pools mask length for default-addr-pool.
Format example is `--default-addr-pool-mask-length 24`
### `--task-history-limit`
This flag sets up task history retention limit.

1
_data/engine-cli/docker_swarm_join.yaml
View File

@ -30,6 +30,7 @@ options:
description: |
Address or interface to use for data path traffic (format: <ip|interface>)
deprecated: false
min_api_version: "1.31"
experimental: false
experimentalcli: false
kubernetes: false

12
_data/engine-cli/docker_trust_inspect.yaml
View File

@ -23,7 +23,7 @@ examples: "### Get low-level details about signatures for a single image tag\n\n
trust inspect alpine:latest\n[\n {\n \"Name\": \"alpine:latest\",\n \"SignedTags\":
[\n {\n \"SignedTag\": \"latest\",\n \"Digest\": \"d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478\",\n
\ \"Signers\": [\n \"Repo Admin\"\n ]\n }\n ],\n \"Signers\":
[],\n \"AdminstrativeKeys\": [\n {\n \"Name\": \"Repository\",\n
[],\n \"AdministrativeKeys\": [\n {\n \"Name\": \"Repository\",\n
\ \"Keys\": [\n {\n \"ID\": \"5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd\"\n
\ }\n ]\n },\n {\n \"Name\": \"Root\",\n \"Keys\":
[\n {\n \"ID\": \"a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce\"\n
@ -43,7 +43,7 @@ examples: "### Get low-level details about signatures for a single image tag\n\n
\ }\n ]\n },\n {\n \"Name\": \"carol\",\n \"Keys\":
[\n {\n \"ID\": \"d32fa8b5ca08273a2880f455fcb318da3dc80aeae1a30610815140deef8f30d9\"\n
\ },\n {\n \"ID\": \"9a8bbec6ba2af88a5fad6047d428d17e6d05dbdd03d15b4fc8a9a0e8049cd606\"\n
\ }\n ]\n }\n ],\n \"AdminstrativeKeys\": [\n {\n
\ }\n ]\n }\n ],\n \"AdministrativeKeys\": [\n {\n
\ \"Name\": \"Repository\",\n \"Keys\": [\n {\n \"ID\":
\"27df2c8187e7543345c2e0bf3a1262e0bc63a72754e9a7395eac3f747ec23a44\"\n }\n
\ ]\n },\n {\n \"Name\": \"Root\",\n \"Keys\": [\n
@ -53,7 +53,7 @@ examples: "### Get low-level details about signatures for a single image tag\n\n
docker trust inspect unsigned-img\nNo signatures or cannot access unsigned-img\n```\n\nHowever,
if other tags are signed in the same image repository,\n`docker trust inspect` reports
relevant key information:\n\n```bash\n$ docker trust inspect alpine:unsigned\n[\n
\ {\n \"Name\": \"alpine:unsigned\",\n \"Signers\": [],\n \"AdminstrativeKeys\":
\ {\n \"Name\": \"alpine:unsigned\",\n \"Signers\": [],\n \"AdministrativeKeys\":
[\n {\n \"Name\": \"Repository\",\n \"Keys\": [\n {\n
\ \"ID\": \"5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd\"\n
\ }\n ]\n },\n {\n \"Name\": \"Root\",\n \"Keys\":
@ -72,7 +72,7 @@ examples: "### Get low-level details about signatures for a single image tag\n\n
[\n \"Repo Admin\"\n ]\n },\n {\n
\ \"SignedTag\": \"latest\",\n \"Digest\": \"d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478\",\n
\ \"Signers\": [\n \"Repo Admin\"\n ]\n
\ }\n ],\n \"Signers\": [],\n \"AdminstrativeKeys\":
\ }\n ],\n \"Signers\": [],\n \"AdministrativeKeys\":
[\n {\n \"Name\": \"Repository\",\n \"Keys\":
[\n {\n \"ID\": \"5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd\"\n
\ }\n ]\n },\n {\n \"Name\":
@ -95,7 +95,7 @@ examples: "### Get low-level details about signatures for a single image tag\n\n
[\n \"Repo Admin\"\n ]\n },\n {\n
\ \"SignedTag\": \"latest\",\n \"Digest\": \"d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478\",\n
\ \"Signers\": [\n \"Repo Admin\"\n ]\n
\ }\n ],\n \"Signers\": [],\n \"AdminstrativeKeys\":
\ }\n ],\n \"Signers\": [],\n \"AdministrativeKeys\":
[\n {\n \"Name\": \"Repository\",\n \"Keys\":
[\n {\n \"ID\": \"5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd\"\n
\ }\n ]\n },\n {\n \"Name\":
@ -108,7 +108,7 @@ examples: "### Get low-level details about signatures for a single image tag\n\n
\ },\n {\n \"SignedTag\": \"signer\",\n \"Digest\":
\"a6122d79b1e74f70b5dd933b18a6d1f99329a4728011079f06b245205f158fe8\",\n \"Signers\":
[\n \"Repo Admin\"\n ]\n }\n ],\n
\ \"Signers\": [],\n \"AdminstrativeKeys\": [\n {\n \"Name\":
\ \"Signers\": [],\n \"AdministrativeKeys\": [\n {\n \"Name\":
\"Root\",\n \"Keys\": [\n {\n \"ID\":
\"8cdcdef5bd039f4ab5a029126951b5985eebf57cabdcdc4d21f5b3be8bb4ce92\"\n }\n
\ ]\n },\n {\n \"Name\": \"Repository\",\n

8
_data/engine-cli/docker_version.yaml
View File

@ -19,6 +19,14 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: kubeconfig
value_type: string
description: Kubernetes config file
deprecated: false
experimental: false
experimentalcli: false
kubernetes: true
swarm: false
examples: |-
### Default output

2
_data/toc.yaml
View File

@ -1726,6 +1726,8 @@ manuals:
section:
- title: Access Kubernetes Resources
path: /ee/ucp/kubernetes/kube-resources/
- title: Configure AWS EBS Storage for Kubernetes
path: /ee/ucp/kubernetes/configure-aws-storage/
- title: Deploy a workload
path: /ee/ucp/kubernetes/
- title: Deploy a Compose-based app

2
_includes/ee-linux-install-reuse.md
View File

@ -172,7 +172,7 @@ You only need to set up the repository once, after which you can install Docker
For example, if you want to install the 18.09 version run the following:
```bash
sudo yum-config-manager --enable docker-ee-stable-18.09.0
sudo yum-config-manager --enable docker-ee-stable-18.09
```
Docker is installed but not started. The `docker` group is created, but no users are added to the group.

2
datacenter/dtr/2.5/reference/api/main.js
View File

File diff suppressed because one or more lines are too long

26
datacenter/dtr/2.5/reference/cli/backup.md
View File

@ -16,34 +16,38 @@ docker run -i --rm docker/dtr \
## Description
This command creates a tar file with the contents of the volumes used by
DTR, and prints it. You can then use the 'restore' command to restore the data
from an existing backup.
This command creates a `tar` file with the contents of the volumes used by
DTR, and prints it. You can then use `docker/dtr restore` to restore the data
from an existing backup.
Note:
* This command only creates backups of configurations, and image metadata.
It doesn't backup users and organizations. Users and organizations can be
backed up when performing a UCP backup.
It does not back up users and organizations. Users and organizations can be
backed up during a UCP backup.
It also doesn't backup the Docker images stored in your registry.
It also doesn't back up Docker images stored in your registry.
You should implement a separate backup policy for the Docker images stored
in your registry, taking in consideration whether your DTR installation is
configured to store images on the filesystem or using a cloud provider.
in your registry, taking into consideration whether your DTR installation is
configured to store images on the filesystem or is using a cloud provider.
* This backup contains sensitive information and should be
stored securely.
* Using the `--offline-backup` flag temporarily shuts down the RethinkDB container.
Take the replica out of your load balancer to avoid downtime.
## Options
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica.To add, remove or modify DTR, you must connect to an existing healthy replica's database.. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica. To add, remove or modify a DTR replica, you must connect to an existing healthy replica's database. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--offline-backup` | $DTR_OFFLINE_BACKUP | This flag takes RethinkDB down during backup and takes a more reliable backup. If you back up DTR with this flag, RethinkDB will go down during backup. However, offline backups are guaranteed to be more consistent than online backups. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP. Download the UCP TLS CA certificate from `https://<ucp-url>/ca`, and use `--ucp-ca "$(cat ca.pem)"`. |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP. The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

16
reference/dtr/2.5/cli/emergency-repair.md → datacenter/dtr/2.5/reference/cli/emergency-repair.md
View File

@ -26,14 +26,14 @@ There are three steps you can take to recover an unhealthy DTR cluster:
2. If the majority of replicas are unhealthy, use this command to revert your
cluster to a single DTR replica.
3. If you can't repair your cluster to a single replica, you'll have to
restore from an existing backup, using the 'restore' command.
restore from an existing backup, using the `restore` command.
When you run this command, a DTR replica of your choice is repaired and
turned into the only replica in the whole DTR cluster.
The containers for all the other DTR replicas are stopped and removed. When
using the 'force' option, the volumes for these replicas are also deleted.
using the `force` option, the volumes for these replicas are also deleted.
After repairing the cluster, you should use the 'join' command to add more
After repairing the cluster, you should use the `join` command to add more
DTR replicas for high availability.
@ -42,12 +42,12 @@ DTR replicas for high availability.
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica.To add, remove or modify DTR, you must connect to an existing healthy replica's database.. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica. To add, remove or modify DTR, you must connect to an existing healthy replica's database. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--overlay-subnet` | $DTR_OVERLAY_SUBNET | The subnet used by the dtr-ol overlay network. Example: 10.0.0.0/24.For high-availalibity, DTR creates an overlay network between UCP nodes. This flag allows you to choose the subnet for that network. Make sure the subnet you choose is not used on any machine where DTR replicas are deployed. |
| `--prune` | $PRUNE | Delete the data volumes of all unhealthy replicas.With this option, the volume of the DTR replica you're restoring is preserved but the volumes for all other replicas are deleted. This has the same result as completely uninstalling DTR from those replicas.. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--overlay-subnet` | $DTR_OVERLAY_SUBNET | The subnet used by the dtr-ol overlay network. Example: `10.0.0.0/24`. For high-availability, DTR creates an overlay network between UCP nodes. This flag allows you to choose the subnet for that network. Make sure the subnet you choose is not used on any machine where DTR replicas are deployed. |
| `--prune` | $PRUNE | Delete the data volumes of all unhealthy replicas. With this option, the volume of the DTR replica you`re restoring is preserved but the volumes for all other replicas are deleted. This has the same result as completely uninstalling DTR from those replicas. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP. Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use `--ucp-ca "$(cat ca.pem)"`. |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP. The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

25
datacenter/dtr/2.5/reference/cli/index.md
View File

@ -19,17 +19,20 @@ docker run -it --rm docker/dtr \
command [command options]
```
If not specified, `docker/dtr` uses the `latest` tag by default. To work with a different version, specify it in the command. For example, `docker run -it --rm docker/dtr:2.5.5`.
## Commands
| Option | Description |
|:------------------------------------------|:---------------------------|
|[install](install)| Install Docker Trusted Registry |
|[join](join)| Add a new replica to an existing DTR cluster |
|[reconfigure](reconfigure)| Change DTR configurations |
|[remove](remove)| Remove a DTR replica from a cluster |
|[destroy](destroy)| Destroy a DTR replica's data |
|[restore](restore)| Install and restore DTR from an existing backup |
|[backup](backup)| Create a backup of DTR |
|[upgrade](upgrade)| Upgrade DTR 2.3.x cluster to this version |
|[images](images)| List all the images necessary to install DTR |
| Option | Description |
|:-------------------------------------|:------------------------------------------------|
| [install](install) | Install Docker Trusted Registry |
| [join](join) | Add a new replica to an existing DTR cluster |
| [reconfigure](reconfigure) | Change DTR configurations |
| [remove](remove) | Remove a DTR replica from a cluster |
| [destroy](destroy) | Destroy a DTR replica's data |
| [restore](restore) | Install and restore DTR from an existing backup |
| [backup](backup) | Create a backup of DTR |
| [upgrade](upgrade) | Upgrade DTR 2.4.x cluster to this version |
| [images](images) | List all the images necessary to install DTR |
| [emergency-repair](emergency-repair) | Recover DTR from loss of quorum |

46
datacenter/dtr/2.5/reference/cli/install.md
View File

@ -19,43 +19,43 @@ docker run -it --rm docker/dtr \
This command installs Docker Trusted Registry (DTR) on a node managed by
Docker Universal Control Plane (UCP).
After installing DTR, you can join additional DTR replicas using the 'join'
command.
After installing DTR, you can join additional DTR replicas using `docker/dtr join`.
Example usage:
### Example Usage
$ docker run -it --rm docker/dtr:2.4.1 install \
$ docker run -it --rm docker/dtr install \
--ucp-node <UCP_NODE_HOSTNAME> \
--ucp-insecure-tls
Note: Use --ucp-ca "$(cat ca.pem)" instead of --ucp-insecure-tls for a production deployment.
Note: Use `--ucp-ca "$(cat ca.pem)"` instead of `--ucp-insecure-tls` for a production deployment.
## Options
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--dtr-ca` | $DTR_CA | Use a PEM-encoded TLS CA certificate for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS CA certificate with --dtr-ca "$(cat ca.pem)". |
| `--dtr-cert` | $DTR_CERT | Use a PEM-encoded TLS certificate for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS certificate with --dtr-cert "$(cat ca.pem)". |
| `--dtr-external-url` | $DTR_EXTERNAL_URL | URL of the host or load balancer clients use to reach DTR.When you use this flag, users are redirected to UCP for logging in. Once authenticated they are redirected to the url you specify in this flag. If you don't use this flag, DTR is deployed without single sign-on with UCP. Users and teams are shared but users login separately into the two applications. You can enable and disable single sign-on in the DTR settings. Format https://host[:port], where port is the value you used with --replica-https-port. |
| `--dtr-key` | $DTR_KEY | Use a PEM-encoded TLS private key for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS private key with --dtr-key "$(cat ca.pem)". |
| `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Customize the volume to store Docker images.By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify a full path or volume name for DTR to store images. For high-availability, make sure all DTR replicas can read and write data on this volume. If you're using NFS, use --nfs-storage-url instead. |
| `--enable-pprof` | $DTR_PPROF | Enables pprof profiling of the server.Once DTR is deployed with this flag, you can access the pprof endpoint for the api server at /debug/pprof, and the registry endpoint at /registry_debug_pprof/debug/pprof. |
| `--dtr-ca` | $DTR_CA | Use a PEM-encoded TLS CA certificate for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS CA certificate with `--dtr-ca "$(cat ca.pem)"`. |
| `--dtr-cert` | $DTR_CERT | Use a PEM-encoded TLS certificate for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS certificate with `--dtr-cert "$(cat ca.pem)"`. |
| `--dtr-external-url` | $DTR_EXTERNAL_URL | URL of the host or load balancer clients use to reach DTR. When you use this flag, users are redirected to UCP for logging in. Once authenticated they are redirected to the URL you specify in this flag. If you don't use this flag, DTR is deployed without single sign-on with UCP. Users and teams are shared but users log in separately into the two applications. You can enable and disable single sign-on within your DTR system settings. Format `https://host[:port]`, where port is the value you used with `--replica-https-port`. |
| `--dtr-key` | $DTR_KEY | Use a PEM-encoded TLS private key for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS private key with `--dtr-key "$(cat ca.pem)"`. |
| `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Customize the volume to store Docker images. By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify a full path or volume name for DTR to store images. For high-availability, make sure all DTR replicas can read and write data on this volume. If you're using NFS, use `--nfs-storage-url` instead. |
| `--enable-pprof` | $DTR_PPROF | Enables pprof profiling of the server. Use `--enable-pprof=false` to disable it. Once DTR is deployed with this flag, you can access the `pprof` endpoint for the api server at `/debug/pprof`, and the registry endpoint at `/registry_debug_pprof/debug/pprof`. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--http-proxy` | $DTR_HTTP_PROXY | The HTTP proxy used for outgoing requests. |
| `--https-proxy` | $DTR_HTTPS_PROXY | The HTTPS proxy used for outgoing requests. |
| `--log-host` | $LOG_HOST | Where to send logs to.The endpoint to send logs to. Use this flag if you set --log-protocol to tcp or udp. |
| `--log-level` | $LOG_LEVEL | Log level for all container logs when logging to syslog. Default: INFO. |
| `--log-protocol` | $LOG_PROTOCOL | The protocol for sending logs. Default is internal.This allows to define the protocol used to send container logs to an external system. The supported protocols are tcp, udp, or internal. Use this flag with --log-host. |
| `--nfs-storage-url` | $NFS_STORAGE_URL | NFS to store Docker images. Format nfs://<ip&#124;hostname>/<mountpoint>.By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify an NFS mount for DTR to store images, using the format nfs://<ip&#124;hostname>/<mountpoint>. To use this flag, you need to install an NFS client library like nfs-common in the node where you're deploying DTR. You can test this by running showmount -e <nfs-server>. When you join new replicas, they will start using NFS so you don't need to use this flag. To reconfigure DTR to stop using NFS, leave this option empty. |
| `--no-proxy` | $DTR_NO_PROXY | List of domains the proxy should not be used for.When using --http-proxy you can use this flag to specify a list of domains that you don't want to route through the proxy. Format acme.com[, acme.org]. |
| `--overlay-subnet` | $DTR_OVERLAY_SUBNET | The subnet used by the dtr-ol overlay network. Example: 10.0.0.0/24.For high-availalibity, DTR creates an overlay network between UCP nodes. This flag allows you to choose the subnet for that network. Make sure the subnet you choose is not used on any machine where DTR replicas are deployed. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is 80.This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with --replica-https-port. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is 443.This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--replica-id` | $DTR_INSTALL_REPLICA_ID | Assign an ID to the DTR replica. Random by default. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--ucp-node` | $UCP_NODE | The hostname of the UCP node to deploy DTR. Random by default.You can find the hostnames of the nodes in the cluster in the UCP web UI, or by running 'docker node ls' on a UCP manager node.. |
| `--log-host` | $LOG_HOST | The syslog system to send logs to.The endpoint to send logs to. Use this flag if you set `--log-protocol` to `tcp` or `udp`. |
| `--log-level` | $LOG_LEVEL | Log level for all container logs when logging to syslog. Default: INFO. The supported log levels are debug, info, warn, error, or fatal. |
| `--log-protocol` | $LOG_PROTOCOL | The protocol for sending logs. Default is internal. By default, DTR internal components log information using the logger specified in the Docker daemon in the node where the DTR replica is deployed. Use this option to send DTR logs to an external syslog system. The supported values are `tcp`, `udp`, or `internal`. Internal is the default option, stopping DTR from sending logs to an external system. Use this flag with `--log-host`. |
| `--nfs-storage-url` | $NFS_STORAGE_URL | NFS to store Docker images. Format `nfs://<ip|hostname>/<mountpoint>`. By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify an NFS mount for DTR to store images, using the format `nfs://<iphostname>/<mountpoint>`. To use this flag, you need to install an NFS client library like ***nfs-common*** in your DTR node. You can test this by running `showmount -e <nfs-server>`. When you join new replicas, they will start using NFS so you don't need to use this flag. To reconfigure DTR to stop using NFS, leave this option empty: `--nfs-storage-url ""` |
| `--no-proxy` | $DTR_NO_PROXY | List of domains the proxy should not be used for. When using `--http-proxy` you can use this flag to specify a list of domains that you don't want to route through the proxy. Format `acme.com[, acme.org]`. |
| `--overlay-subnet` | $DTR_OVERLAY_SUBNET | The subnet used by the dtr-ol overlay network. Example: `10.0.0.0/24`. For high-availability, DTR creates an overlay network between UCP nodes. This flag allows you to choose the subnet for that network. Make sure the subnet you choose is not used on any machine where DTR replicas are deployed. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is `80`. This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with `--replica-https-port`. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is `443`. This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--replica-id` | $DTR_INSTALL_REPLICA_ID | Assign a 12-character hexadecimal ID to the DTR replica. Random by default. |
| `--replica-rethinkdb-cache-mb` | $RETHINKDB_CACHE_MB | The maximum amount of space in MB for RethinkDB in-memory cache used by the given replica. Default is auto. Auto is `(available_memory - 1024) / 2`. This config allows changing the RethinkDB cache usage per replica. You need to run it once per replica to change each one. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP. Download the UCP TLS CA certificate from `https://<ucp-url>/ca`, and use `--ucp-ca "$(cat ca.pem)"`. |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP. The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead. |
| `--ucp-node` | $UCP_NODE | The hostname of the UCP node to deploy DTR. Random by default. You can find the hostnames of the nodes in the cluster in the UCP web interface, or by running `docker node ls` on a UCP manager node. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

17
datacenter/dtr/2.5/reference/cli/join.md
View File

@ -22,15 +22,16 @@ For setting DTR for high-availability, create 3, 5, or 7 replicas of DTR.
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica.To add, remove or modify DTR, you must connect to an existing healthy replica's database.. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica. To add, remove or modify DTR, you must connect to an existing healthy replica's database. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is 80.This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with --replica-https-port. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is 443.This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--replica-id` | $DTR_INSTALL_REPLICA_ID | Assign an ID to the DTR replica. Random by default. |
| `--skip-network-test` | $DTR_SKIP_NETWORK_TEST | Don't test if overlay networks are working correctly between UCP nodes.For high-availalibity, DTR creates an overlay network between UCP nodes and tests that it is working when joining replicas. Don't use this option for production deployments. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--ucp-node` | $UCP_NODE | The hostname of the UCP node to deploy DTR. Random by default.You can find the hostnames of the nodes in the cluster in the UCP web UI, or by running 'docker node ls' on a UCP manager node.. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is `80`. This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with --replica-https-port. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is `443`. This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--replica-id` | $DTR_INSTALL_REPLICA_ID | Assign a 12-character hexadecimal ID to the DTR replica. Random by default. |
| `--replica-rethinkdb-cache-mb` | $RETHINKDB_CACHE_MB | The maximum amount of space in MB for RethinkDB in-memory cache used by the given replica. Default is auto. Auto is `(available_memory - 1024) / 2`. This config allows changing the RethinkDB cache usage per replica. You need to run it once per replica to change each one. |
| `--skip-network-test` | $DTR_SKIP_NETWORK_TEST | Don't test if overlay networks are working correctly between UCP nodes. For high-availability, DTR creates an overlay network between UCP nodes and tests that it is working when joining replicas. Don't use this option for production deployments. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from `https://<ucp-url>/ca`, and use `--ucp-ca "$(cat ca.pem)"`. |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP. The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead. |
| `--ucp-node` | $UCP_NODE | The hostname of the UCP node to deploy DTR. Random by default.You can find the hostnames of the nodes in the cluster in the UCP web interface, or by running `docker node ls` on a UCP manager node. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

31
datacenter/dtr/2.5/reference/cli/reconfigure.md
View File

@ -19,7 +19,7 @@ docker run -it --rm docker/dtr \
This command changes DTR configuration settings.
DTR is restarted for the new configurations to take effect. To have no down
time, configure your DTR for high-availability.
time, configure your DTR for high availability.
## Options
@ -29,23 +29,24 @@ time, configure your DTR for high-availability.
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--dtr-ca` | $DTR_CA | Use a PEM-encoded TLS CA certificate for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS CA certificate with --dtr-ca "$(cat ca.pem)". |
| `--dtr-cert` | $DTR_CERT | Use a PEM-encoded TLS certificate for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS certificate with --dtr-cert "$(cat ca.pem)". |
| `--dtr-external-url` | $DTR_EXTERNAL_URL | URL of the host or load balancer clients use to reach DTR.When you use this flag, users are redirected to UCP for logging in. Once authenticated they are redirected to the url you specify in this flag. If you don't use this flag, DTR is deployed without single sign-on with UCP. Users and teams are shared but users login separately into the two applications. You can enable and disable single sign-on in the DTR settings. Format https://host[:port], where port is the value you used with --replica-https-port. |
| `--dtr-key` | $DTR_KEY | Use a PEM-encoded TLS private key for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS private key with --dtr-key "$(cat ca.pem)". |
| `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Customize the volume to store Docker images.By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify a full path or volume name for DTR to store images. For high-availability, make sure all DTR replicas can read and write data on this volume. If you're using NFS, use --nfs-storage-url instead. |
| `--enable-pprof` | $DTR_PPROF | Enables pprof profiling of the server.Once DTR is deployed with this flag, you can access the pprof endpoint for the api server at /debug/pprof, and the registry endpoint at /registry_debug_pprof/debug/pprof. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica.To add, remove or modify DTR, you must connect to an existing healthy replica's database.. |
| `--dtr-external-url` | $DTR_EXTERNAL_URL | URL of the host or load balancer clients use to reach DTR. When you use this flag, users are redirected to UCP for logging in. Once authenticated they are redirected to the url you specify in this flag. If you don't use this flag, DTR is deployed without single sign-on with UCP. Users and teams are shared but users login separately into the two applications. You can enable and disable single sign-on in the DTR settings. Format `https://host[:port]`, where port is the value you used with `--replica-https-port`. |
| `--dtr-key` | $DTR_KEY | Use a PEM-encoded TLS private key for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS private key with `--dtr-key "$(cat ca.pem)"`. |
| `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Customize the volume to store Docker images. By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify a full path or volume name for DTR to store images. For high-availability, make sure all DTR replicas can read and write data on this volume. If you're using NFS, use `--nfs-storage-url` instead. |
| `--enable-pprof` | $DTR_PPROF | Enables pprof profiling of the server. Use `--enable-pprof=false` to disable it. Once DTR is deployed with this flag, you can access the pprof endpoint for the api server at `/debug/pprof`, and the registry endpoint at `/registry_debug_pprof/debug/pprof`. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica. To add, remove or modify DTR, you must connect to an existing healthy replica's database. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--http-proxy` | $DTR_HTTP_PROXY | The HTTP proxy used for outgoing requests. |
| `--https-proxy` | $DTR_HTTPS_PROXY | The HTTPS proxy used for outgoing requests. |
| `--log-host` | $LOG_HOST | Where to send logs to.The endpoint to send logs to. Use this flag if you set --log-protocol to tcp or udp. |
| `--log-level` | $LOG_LEVEL | Log level for all container logs when logging to syslog. Default: INFO. |
| `--log-protocol` | $LOG_PROTOCOL | The protocol for sending logs. Default is internal.This allows to define the protocol used to send container logs to an external system. The supported protocols are tcp, udp, or internal. Use this flag with --log-host. |
| `--nfs-storage-url` | $NFS_STORAGE_URL | NFS to store Docker images. Format nfs://<ip&#124;hostname>/<mountpoint>.By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify an NFS mount for DTR to store images, using the format nfs://<ip&#124;hostname>/<mountpoint>. To use this flag, you need to install an NFS client library like nfs-common in the node where you're deploying DTR. You can test this by running showmount -e <nfs-server>. When you join new replicas, they will start using NFS so you don't need to use this flag. To reconfigure DTR to stop using NFS, leave this option empty. |
| `--no-proxy` | $DTR_NO_PROXY | List of domains the proxy should not be used for.When using --http-proxy you can use this flag to specify a list of domains that you don't want to route through the proxy. Format acme.com[, acme.org]. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is 80.This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with --replica-https-port. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is 443.This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--log-host` | $LOG_HOST | The syslog system to send logs to. The endpoint to send logs to. Use this flag if you set `--log-protocol` to `tcp` or `udp`. |
| `--log-level` | $LOG_LEVEL | Log level for all container logs when logging to syslog. Default: INFO. The supported log levels are `debug`, `info`, `warn`, `error`, or `fatal`. |
| `--log-protocol` | $LOG_PROTOCOL | The protocol for sending logs. Default is internal. By default, DTR internal components log information using the logger specified in the Docker daemon in the node where the DTR replica is deployed. Use this option to send DTR logs to an external syslog system. The supported values are `tcp`, `udp`, and `internal`. Internal is the default option, stopping DTR from sending logs to an external system. Use this flag with `--log-host`. |
| `--nfs-storage-url` | $NFS_STORAGE_URL | NFS to store Docker images. Format `nfs://<ip|hostname>/<mountpoint>`. By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify an NFS mount for DTR to store images, using the format `nfs://<ip|hostname>/<mountpoint>`. To use this flag, you need to install an NFS client library like **nfs-common** in the node where you're deploying DTR. You can test this by running `showmount -e <nfs-server>`. When you join new replicas, they will start using NFS so you don't need to use this flag. To reconfigure DTR to stop using NFS, leave this option empty: `--nfs-storage-url ""` |
| `--no-proxy` | $DTR_NO_PROXY | List of domains the proxy should not be used for. When using `--http-proxy` you can use this flag to specify a list of domains that you don't want to route through the proxy. Format `acme.com[, acme.org]`. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is `80`. This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with --replica-https-port. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is `443`. This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--replica-rethinkdb-cache-mb` | $RETHINKDB_CACHE_MB | The maximum amount of space in MB for RethinkDB in-memory cache used by the given replica. Default is auto. Auto is `(available_memory - 1024) / 2`. This config allows changing the RethinkDB cache usage per replica. You need to run it once per replica to change each one. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP. Download the UCP TLS CA certificate from `https://<ucp-url>/ca`, and use `--ucp-ca "$(cat ca.pem)"`. |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP. The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

8
datacenter/dtr/2.5/reference/cli/remove.md
View File

@ -26,12 +26,12 @@ this operation.
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica.To add, remove or modify DTR, you must connect to an existing healthy replica's database.. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica. To add, remove or modify DTR, you must connect to an existing healthy replica's database. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--replica-id` | $DTR_REMOVE_REPLICA_ID | DEPRECATED Alias for --replica-ids. |
| `--replica-id` | $DTR_REMOVE_REPLICA_ID | DEPRECATED Alias for `--replica-ids`. |
| `--replica-ids` | $DTR_REMOVE_REPLICA_IDS | A comma separated list of IDs of replicas to remove from the cluster. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP. Download the UCP TLS CA certificate from `https://<ucp-url>/ca`, and use `--ucp-ca "$(cat ca.pem)"`. |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP. The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

47
datacenter/dtr/2.5/reference/cli/restore.md
View File

@ -17,14 +17,24 @@ docker run -i --rm docker/dtr \
This command performs a fresh installation of DTR, and reconfigures it
with configuration data from a tar file generated by the 'backup' command.
with configuration data from a `tar` file generated by `docker/dtr backup`.
There are three steps you can take to recover an unhealthy DTR cluster:
1. If the majority of replicas are healthy, remove the unhealthy nodes from
the cluster, and join new nodes for high availability.
2. If the majority of replicas are unhealthy, use this command to revert your
cluster to a single DTR replica.
3. If you can't repair your cluster to a single replica, you'll have to
restore from an existing backup, using the `restore` command.
This command does not restore Docker images. You should implement a separate
restore procedure for the Docker images stored in your registry, taking in
consideration whether your DTR installation is configured to store images on
the local filesystem or using a cloud provider.
After restoring, you can add more DTR replicas by using the 'join' command.
After restoring the cluster, you should use the `join` command to add more
DTR replicas for high availability.
## Options
@ -32,26 +42,27 @@ After restoring, you can add more DTR replicas by using the 'join' command.
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--dtr-ca` | $DTR_CA | Use a PEM-encoded TLS CA certificate for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS CA certificate with --dtr-ca "$(cat ca.pem)". |
| `--dtr-cert` | $DTR_CERT | Use a PEM-encoded TLS certificate for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS certificate with --dtr-cert "$(cat ca.pem)". |
| `--dtr-external-url` | $DTR_EXTERNAL_URL | URL of the host or load balancer clients use to reach DTR.When you use this flag, users are redirected to UCP for logging in. Once authenticated they are redirected to the url you specify in this flag. If you don't use this flag, DTR is deployed without single sign-on with UCP. Users and teams are shared but users login separately into the two applications. You can enable and disable single sign-on in the DTR settings. Format https://host[:port], where port is the value you used with --replica-https-port. |
| `--dtr-key` | $DTR_KEY | Use a PEM-encoded TLS private key for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS private key with --dtr-key "$(cat ca.pem)". |
| `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Customize the volume to store Docker images.By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify a full path or volume name for DTR to store images. For high-availability, make sure all DTR replicas can read and write data on this volume. If you're using NFS, use --nfs-storage-url instead. |
| `--enable-pprof` | $DTR_PPROF | Enables pprof profiling of the server.Once DTR is deployed with this flag, you can access the pprof endpoint for the api server at /debug/pprof, and the registry endpoint at /registry_debug_pprof/debug/pprof. |
| `--dtr-ca` | $DTR_CA | Use a PEM-encoded TLS CA certificate for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS CA certificate with `--dtr-ca "$(cat ca.pem)"`. |
| `--dtr-cert` | $DTR_CERT | Use a PEM-encoded TLS certificate for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS certificate with `--dtr-cert "$(cat ca.pem)"`. |
| `--dtr-external-url` | $DTR_EXTERNAL_URL | URL of the host or load balancer clients use to reach DTR. When you use this flag, users are redirected to UCP for logging in. Once authenticated they are redirected to the URL you specify in this flag. If you don't use this flag, DTR is deployed without single sign-on with UCP. Users and teams are shared but users log in separately into the two applications. You can enable and disable single sign-on within your DTR system settings. Format `https://host[:port]`, where port is the value you used with `--replica-https-port`. |
| `--dtr-key` | $DTR_KEY | Use a PEM-encoded TLS private key for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS private key with `--dtr-key "$(cat ca.pem)"`. |
| `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Customize the volume to store Docker images. By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify a full path or volume name for DTR to store images. For high-availability, make sure all DTR replicas can read and write data on this volume. If you're using NFS, use --nfs-storage-url instead. |
| `--enable-pprof` | $DTR_PPROF | Enables pprof profiling of the server. Use `--enable-pprof=false` to disable it. Once DTR is deployed with this flag, you can access the `pprof` endpoint for the api server at `/debug/pprof`, and the registry endpoint at `/registry_debug_pprof/debug/pprof`. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--http-proxy` | $DTR_HTTP_PROXY | The HTTP proxy used for outgoing requests. |
| `--https-proxy` | $DTR_HTTPS_PROXY | The HTTPS proxy used for outgoing requests. |
| `--log-host` | $LOG_HOST | Where to send logs to.The endpoint to send logs to. Use this flag if you set --log-protocol to tcp or udp. |
| `--log-level` | $LOG_LEVEL | Log level for all container logs when logging to syslog. Default: INFO. |
| `--log-protocol` | $LOG_PROTOCOL | The protocol for sending logs. Default is internal.This allows to define the protocol used to send container logs to an external system. The supported protocols are tcp, udp, or internal. Use this flag with --log-host. |
| `--nfs-storage-url` | $NFS_STORAGE_URL | NFS to store Docker images. Format nfs://<ip&#124;hostname>/<mountpoint>.By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify an NFS mount for DTR to store images, using the format nfs://<ip&#124;hostname>/<mountpoint>. To use this flag, you need to install an NFS client library like nfs-common in the node where you're deploying DTR. You can test this by running showmount -e <nfs-server>. When you join new replicas, they will start using NFS so you don't need to use this flag. To reconfigure DTR to stop using NFS, leave this option empty. |
| `--log-host` | $LOG_HOST | The syslog system to send logs to.The endpoint to send logs to. Use this flag if you set --log-protocol to tcp or udp. |
| `--log-level` | $LOG_LEVEL | Log level for all container logs when logging to syslog. Default: `INFO`. The supported log levels are `debug`, `info`, `warn`, `error`, or `fatal`. |
| `--log-protocol` | $LOG_PROTOCOL | The protocol for sending logs. Default is internal.By default, DTR internal components log information using the logger specified in the Docker daemon in the node where the DTR replica is deployed. Use this option to send DTR logs to an external syslog system. The supported values are tcp, udp, and internal. Internal is the default option, stopping DTR from sending logs to an external system. Use this flag with --log-host. |
| `--nfs-storage-url` | $NFS_STORAGE_URL | NFS to store Docker images. Format `nfs://<ip|hostname>/<mountpoint>`. By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify an NFS mount for DTR to store images, using the format `nfs://<iphostname>/<mountpoint>`. To use this flag, you need to install an NFS client library like ***nfs-common*** in your DTR node. You can test this by running `showmount -e <nfs-server>`. When you join new replicas, they will start using NFS so you don't need to use this flag. To reconfigure DTR to stop using NFS, leave this option empty: `--nfs-storage-url ""` |
| `--no-proxy` | $DTR_NO_PROXY | List of domains the proxy should not be used for.When using --http-proxy you can use this flag to specify a list of domains that you don't want to route through the proxy. Format acme.com[, acme.org]. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is 80.This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with --replica-https-port. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is 443.This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--replica-id` | $DTR_INSTALL_REPLICA_ID | Assign an ID to the DTR replica. Random by default. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--ucp-node` | $UCP_NODE | The hostname of the UCP node to deploy DTR. Random by default.You can find the hostnames of the nodes in the cluster in the UCP web UI, or by running 'docker node ls' on a UCP manager node.. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is `80`. This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with `--replica-https-port`. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is `443`. This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--replica-id` | $DTR_INSTALL_REPLICA_ID | Assign a 12-character hexadecimal ID to the DTR replica. Random by default. |
| `--replica-rethinkdb-cache-mb` | $RETHINKDB_CACHE_MB | The maximum amount of space in MB for RethinkDB in-memory cache used by the given replica. Default is auto. Auto is `(available_memory - 1024) / 2`. This config allows changing the RethinkDB cache usage per replica. You need to run it once per replica to change each one. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP. Download the UCP TLS CA certificate from `https://<ucp-url>/ca`, and use `--ucp-ca "$(cat ca.pem)"`. |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP. The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead. |
| `--ucp-node` | $UCP_NODE | The hostname of the UCP node to deploy DTR. Random by default. You can find the hostnames of the nodes in the cluster in the UCP web interface, or by running `docker node ls` on a UCP manager node. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

12
datacenter/dtr/2.5/reference/cli/upgrade.md
View File

@ -1,10 +1,10 @@
---
title: docker/dtr upgrade
description: Upgrade DTR 2.3.x cluster to this version
description: Upgrade DTR 2.4.x cluster to this version
keywords: dtr, cli, upgrade
---
Upgrade DTR 2.3.x cluster to this version
Upgrade DTR 2.4.x cluster to this version
## Usage
@ -16,7 +16,7 @@ docker run -it --rm docker/dtr \
## Description
This command upgrades DTR 2.3.x to the current version of this image.
This command upgrades DTR 2.4.x to the current version of this image.
## Options
@ -24,10 +24,10 @@ This command upgrades DTR 2.3.x to the current version of this image.
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica.To add, remove or modify DTR, you must connect to an existing healthy replica's database.. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica. To add, remove or modify DTR, you must connect to an existing healthy replica's database. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP. Download the UCP TLS CA certificate from `https://<ucp-url>/ca`, and use `--ucp-ca "$(cat ca.pem)"`. |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP. The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

2
datacenter/ucp/3.0/reference/api/index.md
View File

@ -1,7 +1,7 @@
---
description: Learn how to use the Universal Control Plane REST API
keywords: ucp, api, reference
title: Universal Control Plane 2.2 API
title: Universal Control Plane 3.0 API
---
<div class="swagger-section">

2
datacenter/ucp/3.0/reference/api/main.js
View File

File diff suppressed because one or more lines are too long

8
datacenter/ucp/3.0/reference/cli/backup.md
View File

@ -9,7 +9,7 @@ Create a backup of a UCP manager node
## Usage
```bash
docker container run --log-driver none --rm -i \
docker container run --log-driver none --rm \
--name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/ucp \
@ -22,9 +22,9 @@ This command creates a tar file with the contents of the volumes used by
this UCP manager node, and prints it. You can then use the `restore` command to
restore the data from an existing backup.
To create backups of a multi-node swarm, you only need to back up a single manager
node. The restore operation will reconstitute a new UCP installation from the
backup of any previous manager.
To create backups of a multi-node cluster, you only need to back up a single
manager node. The restore operation will reconstitute a new UCP installation
from the backup of any previous manager.
Note:

7
datacenter/ucp/3.0/reference/cli/example-config.md
View File

@ -13,10 +13,5 @@ docker container run --rm -i \
--name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/ucp \
example-config > ucp.config
example-config
```
## Description
This command emits an example configuration file for setting up UCP.
[Learn about UCP configuration files](../../guides/admin/configure/ucp-configuration-file.md).

5
datacenter/ucp/3.0/reference/cli/id.md
View File

@ -7,11 +7,14 @@ keywords: ucp, cli, id
Print the ID of UCP running on this node
## Usage
Run the UCP id command using the correct image version tag for UCP (i.e. docker/ucp:$version)
```
docker container run --rm \
--name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/ucp \
docker/ucp:$version \
id
```

2
datacenter/ucp/3.0/reference/cli/index.md
View File

@ -23,7 +23,7 @@ Additional help is available for each command with the `--help` flag.
docker container run -it --rm \
--name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
{{ page.ucp_org }}/{{ page.ucp_repo }}:{{ page.ucp_version }} \
docker/ucp \
command [command arguments]
```

80
datacenter/ucp/3.0/reference/cli/install.md
View File

@ -24,13 +24,13 @@ Docker Universal Control Plane (UCP).
When installing UCP you can customize:
* The certificates used by the UCP web server. Create a volume
named 'ucp-controller-server-certs' and copy the ca.pem, cert.pem, and key.pem
named `ucp-controller-server-certs` and copy the `ca.pem`, `cert.pem`, and `key.pem`
files to the root directory. Then run the install command with the
`--external-server-cert` flag.
* The license used by UCP, by bind-mounting the file at
'/config/docker_subscription.lic' in the tool. For example, `-v /path/to/my/config/docker_subscription.lic:/config/docker_subscription.lic`
or by specifying with '--license "$(cat license.lic)"
`/config/docker_subscription.lic` in the tool. E.g. `-v /path/to/my/config/docker_subscription.lic:/config/docker_subscription.lic`
or by specifying with `--license "$(cat license.lic)`
If you're joining more nodes to this swarm, open the following ports in your
firewall:
@ -46,37 +46,43 @@ command.
## Options
| Option | Description |
| :----------------------- | :----------------------------------------------------------------------------------------------- |
| `--debug, D` | Enable debug mode |
| `--jsonlog` | Produce json formatted output for easier parsing |
| `--interactive, i` | Run in interactive mode and prompt for configuration values |
| `--admin-username` | The UCP administrator username |
| `--admin-password` | The UCP administrator password |
| `--san` | Add subject alternative names to certificates. For example, `-san www1.acme.com --san www2.acme.com` |
| `--host-address` | The network address to advertise to other nodes. Format: IP address or network interface name |
| `--data-path-addr` | Address or interface to use for data path traffic. Format: IP address or network interface name |
| `--swarm-port` | Port for the Docker Swarm manager. Used for backwards compatibility |
| `--controller-port` | Port for the web UI and API |
| `--swarm-grpc-port` | Port for communication between nodes |
| `--dns` | Set custom DNS servers for the UCP containers |
| `--dns-opt` | Set DNS options for the UCP containers |
| `--dns-search` | Set custom DNS search domains for the UCP containers |
| `--unlock-key` | The unlock key for this swarm-mode cluster, if one exists. |
| `--existing-config` | Use the latest existing UCP config during this installation. The install fails if a config is not found. |
| `--pull` | Pull UCP images: `always`, when `missing`, or `never` |
| `--registry-username` | Username to use when pulling images |
| `--registry-password` | Password to use when pulling images |
| `--kv-timeout` | Timeout in milliseconds for the key-value store |
| `--kv-snapshot-count` | Number of changes between key-value store snapshots |
| `--swarm-experimental` | Enable Docker Swarm experimental features. Used for backwards compatibility |
| `--disable-tracking` | Disable anonymous tracking and analytics |
| `--disable-usage` | Disable anonymous usage reporting |
| `--external-server-cert` | Customize the certificates used by the UCP web server |
| `--preserve-certs` | Don't generate certificates if they already exist |
| `--binpack` | Set the Docker Swarm scheduler to binpack mode. Used for backwards compatibility |
| `--random` | Set the Docker Swarm scheduler to random mode. Used for backwards compatibility |
| `--external-service-lb` | Set the external service load balancer reported in the UI |
| `--enable-profiling` | Enable performance profiling |
| `--license` | Add a license. For example, `--license "$(cat license.lic)"` |
| `--force-insecure-tcp` | Force install to continue even with unauthenticated Docker Engine ports |
| Option | Description |
|:-------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `--debug, D` | Enable debug mode |
| `--jsonlog` | Produce json formatted output for easier parsing |
| `--interactive, i` | Run in interactive mode and prompt for configuration values |
| `--admin-username` | The UCP administrator username |
| `--admin-password` | The UCP administrator password |
| `--san` | Add subject alternative names to certificates. The `-san` option can be used multiple times, such as `--san www1.acme.com --san www2.acme.com`. |
| `--host-address` | The network address to advertise to other nodes. Format: IP address or network interface name |
| `--data-path-addr` | Address or interface to use for data path traffic. Format: IP address or network interface name |
| `--controller-port` | Port for the web UI and API |
| `--kube-apiserver-port` | Port for the Kubernetes API server (default: 6443) |
| `--swarm-port` | Port for the Docker Swarm manager. Used for backwards compatibility |
| `--swarm-grpc-port` | Port for communication between nodes |
| `--cni-installer-url` | A URL pointing to a Kubernetes YAML file to be used as an installer for the CNI plugin of the cluster. If specified, the default CNI plugin is not installed. If the URL uses the HTTPS scheme, no certificate verification is performed. |
| `--pod-cidr` | Kubernetes cluster IP pool for the pods to allocated IPs from (Default: 192.168.0.0/16) |
| `--cloud-provider` | The cloud provider for the cluster |
| `--dns` | Set custom DNS servers for the UCP containers |
| `--dns-opt` | Set DNS options for the UCP containers |
| `--dns-search` | Set custom DNS search domains for the UCP containers |
| `--unlock-key` | The unlock key for this swarm-mode cluster, if one exists. |
| `--existing-config` | Use the latest existing UCP config during this installation. The install fails if a config is not found. |
| `--force-minimums` | Force the install/upgrade even if the system doesn't meet the minimum requirements. |
| `--pull` | Pull UCP images: `always`, when `missing`, or `never` |
| `--registry-username` | Username to use when pulling images |
| `--registry-password` | Password to use when pulling images |
| `--kv-timeout` | Timeout in milliseconds for the key-value store |
| `--kv-snapshot-count` | Number of changes between key-value store snapshots |
| `--swarm-experimental` | Enable Docker Swarm experimental features. Used for backwards compatibility |
| `--disable-tracking` | Disable anonymous tracking and analytics |
| `--disable-usage` | Disable anonymous usage reporting |
| `--external-server-cert` | Use the certificates in the `ucp-controller-server-certs` volume instead of generating self-signed certs during installation |
| `--preserve-certs` | Don't generate certificates if they already exist |
| `--binpack` | Set the Docker Swarm scheduler to binpack mode. Used for backwards compatibility |
| `--random` | Set the Docker Swarm scheduler to random mode. Used for backwards compatibility |
| `--external-service-lb` | Set the external service load balancer reported in the UI |
| `--enable-profiling` | Enable performance profiling |
| `--license` | Add a license: e.g. --license "$(cat license.lic)" |
| `--force-insecure-tcp` | Force install to continue even with unauthenticated Docker Engine ports |

27
datacenter/ucp/3.0/reference/cli/restore.md
View File

@ -22,16 +22,16 @@ This command installs a new UCP cluster that is populated with the state of
a previous UCP manager node using a tar file generated by the `backup` command.
All UCP settings, users, teams and permissions will be restored from the backup
file. The Restore operation does not alter or recover any containers, networks,
volumes or services of an underlying swarm.
volumes or services of an underlying cluster.
The restore command can be performed on any manager node of an existing
swarm. If the current node does not belong in a swarm, one will be
cluster. If the current node does not belong in a cluster, one will be
initialized using the value of the `--host-address` flag. When restoring on an
existing swarm-mode cluster, no previous UCP components must be running on any
node of the cluster. This cleanup can be performed with the `uninstall-ucp`
command.
If restore is performed on a different swarm than the one
If restore is performed on a different cluster than the one
where the backup file was taken on, the Cluster Root CA of the old UCP
installation will not be restored. This will invalidate any
previously issued Admin Client Bundles and all administrator will be required
@ -53,17 +53,18 @@ Notes:
with `docker swarm init --force-new-cluster`.
* You can restore from a backup that was taken on a different manager node or
a different swarm altogether.
a different cluster altogether.
## Options
| Option | Description |
|:--------------------------|:---------------------------|
|`--debug, D`|Enable debug mode|
|`--jsonlog`|Produce json formatted output for easier parsing|
|`--interactive, i`|Run in interactive mode and prompt for configuration values|
|`--passphrase`|Decrypt the backup tar file with the provided passphrase|
|`--san`|Add subject alternative names to certificates. For example, ``--san www1.acme.com --san www2.acme.com`|
|`--host-address`|The network address to advertise to other nodes. Format: IP address or network interface name|
|`--unlock-key`|The unlock key for this swarm-mode cluster, if one exists.|
| Option | Description |
|:-------------------|:----------------------------------------------------------------------------------------------|
| `--debug, D` | Enable debug mode |
| `--jsonlog` | Produce json formatted output for easier parsing |
| `--interactive, i` | Run in interactive mode and prompt for configuration values |
| `--passphrase` | Decrypt the backup tar file with the provided passphrase |
| `--san` | Add subject alternative names to certificates (e.g. --san www1.acme.com --san www2.acme.com) |
| `--host-address` | The network address to advertise to other nodes. Format: IP address or network interface name |
| `--data-path-addr` | Address or interface to use for data path traffic |
| `--unlock-key` | The unlock key for this swarm-mode cluster, if one exists. |

8
datacenter/ucp/3.0/reference/cli/support.md
View File

@ -1,10 +1,10 @@
---
title: docker/ucp support
description: Create a support dump for this UCP node
keywords: ucp, cli, support
description: Create a support dump for UCP nodes
keywords: ucp, cli, support, support dump, troubleshooting
---
Create a support dump for this UCP node
Create a support dump for specified UCP nodes. You create a support dump to help [Docker Support](http://success.docker.com/support) understand your environment and more effectively troubleshoot issues in resolving your support case.
## Usage
@ -26,5 +26,3 @@ This command creates a support dump file for this node, and prints it to stdout.
|:--------------------------|:---------------------------|
|`--debug, D`|Enable debug mode|
|`--jsonlog`|Produce json formatted output for easier parsing|

2
datacenter/ucp/3.0/reference/cli/uninstall-ucp.md
View File

@ -24,7 +24,7 @@ your applications can continue running.
After UCP is uninstalled you can use the `docker swarm leave` and
`docker node rm` commands to remove nodes from the swarm.
Once UCP is uninstalled, you can't join nodes to the swarm unless
Once UCP is uninstalled, you won't be able to join nodes to the swarm unless
UCP is installed again.

42
datacenter/ucp/3.0/reference/cli/upgrade.md
View File

@ -18,31 +18,31 @@ Upgrade the UCP cluster
## Description
This command upgrades the UCP running on this node.
To upgrade UCP:
This command upgrades the UCP running on this cluster.
* Upgrade the Docker Engine in all nodes (optional)
* Run the upgrade command in all manager nodes
* Run the upgrade command in all worker nodes
Before performing an upgrade, you should perform a backup by using the
Before performing an upgrade, you should perform a backup by using the
[backup](backup.md) command.
After upgrading UCP in a node, go to the UCP web UI and confirm the node is
healthy, before upgrading other nodes.
After upgrading UCP, go to the UCP web UI and confirm each node is
healthy and that all nodes have been upgraded successfully.
## Options
| Option | Description |
|:--------------------------|:---------------------------|
|`--debug, D`|Enable debug mode|
|`--jsonlog`|Produce json formatted output for easier parsing|
|`--interactive, i`|Run in interactive mode and prompt for configuration values|
|`--admin-username`|The UCP administrator username|
|`--admin-password`|The UCP administrator password|
|`--pull`|Pull UCP images: `always`, when `missing`, or `never`|
|`--registry-username`|Username to use when pulling images|
|`--registry-password`|Password to use when pulling images|
|`--id`|The ID of the UCP instance to upgrade|
|`--host-address`|Override the previously configured host address with this IP or network interface|
| Option | Description |
|:----------------------|:------------------------------------------------------------------------------------------------------|
| `--debug, D` | Enable debug mode |
| `--jsonlog` | Produce json formatted output for easier parsing |
| `--interactive, i` | Run in interactive mode and prompt for configuration values |
| `--admin-username` | The UCP administrator username |
| `--admin-password` | The UCP administrator password |
| `--pull` | Pull UCP images: `always`, when `missing`, or `never` |
| `--registry-username` | Username to use when pulling images |
| `--registry-password` | Password to use when pulling images |
| `--id` | The ID of the UCP instance to upgrade |
| `--host-address` | Override the previously configured host address with this IP or network interface |
| `--force-minimums` | Force the install/upgrade even if the system does not meet the minimum requirements |
| `--pod-cidr` | Kubernetes cluster IP pool for the pods to allocated IP from (Default: 192.168.0.0/16 |
| `--nodeport-range` | Allowed port range for Kubernetes services of type NodePort (Default: 32768-35535) |
| `--cloud-provider` | The cloud provider for the cluster |
| `--cni-installer-url` | A URL pointing to a kubernetes YAML file to be used as an installer for the CNI plugin of the cluster |

2
develop/develop-images/build_enhancements.md
View File

@ -30,7 +30,7 @@ For more information on build options, see the reference guide on the [command l
Easiest way from a fresh install of docker is to set the `DOCKER_BUILDKIT=1` environment variable when invoking the `docker build` command, such as:
```
$ DOCKER_BUILD=1 docker build .
$ DOCKER_BUILDKIT=1 docker build .
```
To enable docker buildkit by default, set daemon configuration in `/etc/docker/daemon.json` feature to true and restart the daemon:

4
develop/develop-images/dockerfile_best-practices.md
View File

@ -463,8 +463,8 @@ RUN set -o pipefail && wget -O - https://some.site | wc -l > /number
```
> Not all shells support the `-o pipefail` option.
>
> In such cases (such as the `dash` shell, which is the default shell on
> Debian-based images), consider using the _exec_ form of `RUN` to explicitly
> In cases such as the `dash` shell on
> Debian-based images, consider using the _exec_ form of `RUN` to explicitly
> choose a shell that does support the `pipefail` option. For example:
>
> ```Dockerfile

2
ee/dtr/admin/upgrade.md
View File

@ -91,7 +91,7 @@ upgrade. The command is the same as for a minor upgrade.
>
> There are [important changes to the upgrade process](/ee/upgrade) that, if not correctly followed, can have impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before `18.09` to version `18.09` or greater. See [Cluster Upgrade Best Practices](/ee/upgrade.md#cluster-upgrade-best-practices) for more details. Additionally, to ensure high availability during the DTR upgrade, you can also drain the DTR replicas and move their workloads to updated workers. To do this, you can join new workers as DTR replicas to your existing cluster and then remove the old replicas. See [docker/dtr join](/reference/dtr/2.6/cli/join) and [docker/dtr remove](/reference/dtr/2.6/cli/remove) for command options and details.
When upgrading from `2.5` to `2.6`, the system will run a `metadatastoremigration` job after a successful upgrade. This involves migrating the blob links for your images which is necessary for online garbage collection. With `2.6`, you can log in to the DTR web interface and navigate to **System > Job Logs** to check the status of the `metadatastoremigration` job. See [Audit Jobs via the Web Interface](../manage-jobs/audit-jobs-via-ui/) for more details.
When upgrading from `2.5` to `2.6`, the system will run a `metadatastoremigration` job after a successful upgrade. This involves migrating the blob links for your images which is necessary for online garbage collection. With `2.6`, you can log in to the DTR web interface and navigate to **System > Job Logs** to check the status of the `metadatastoremigration` job. See [Audit Jobs via the Web Interface](/ee/dtr/admin/manage-jobs/audit-jobs-via-ui/) for more details.
![](../images/migration-warning.png){: .with-border}

BIN
ee/dtr/images/internal-promotion-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
ee/dtr/images/internal-promotion-2.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 247 KiB

After

Width:  |  Height:  |  Size: 33 KiB

BIN
ee/dtr/images/internal-promotion-3.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 338 KiB

After

Width:  |  Height:  |  Size: 107 KiB

BIN
ee/dtr/images/internal-promotion-4.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 278 KiB

After

Width:  |  Height:  |  Size: 69 KiB

BIN
ee/dtr/images/internal-promotion-5.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 39 KiB

BIN
ee/dtr/images/push-mirror-2.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 235 KiB

After

Width:  |  Height:  |  Size: 18 KiB

BIN
ee/dtr/images/push-mirror-3.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 290 KiB

After

Width:  |  Height:  |  Size: 80 KiB

BIN
ee/dtr/images/push-mirror-4.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 297 KiB

After

Width:  |  Height:  |  Size: 68 KiB

34
ee/dtr/user/promotion-policies/internal-promotion.md
View File

@ -11,7 +11,7 @@ redirect_from:
Docker Trusted Registry allows you to create image promotion pipelines based on
policies.
In this example we'll create an image promotion pipeline such that:
In this example we will create an image promotion pipeline such that:
1. Developers iterate and push their builds to the `dev/website` repository.
2. When the team creates a stable build, they make sure their image is tagged
@ -23,31 +23,30 @@ With this promotion policy, the development team doesn't need access to the
QA repositories, and the QA team doesn't need access to the development
repositories.
![promotion example](../../images/internal-promotion-1.svg)
![promotion example](../../images/internal-promotion-1.png)
## Configure your repository
Once you've [created the repository](../manage-images/index.md), navigate to
the **DTR web UI**, go to the **repository details** page, and choose
**Promotions**.
the repository page on the DTR web interface, and select the
**Promotions** tab.
![repository policies](../../images/internal-promotion-2.png){: .with-border}
Click **New promotion policy**, and define the criteria that an image needs
to meet to be promoted.
Click **New promotion policy**, and define the image promotion criteria.
DTR allows defining the following criteria:
DTR allows you to set your promotion policy based on the following image attributes:
| Name | Description |
|:----------------|:---------------------------------------------------|
| Tag name | If the tag name contains |
| Component name | If the image has a given component |
| Vulnerabilities | If the image has vulnerabilities |
| License | If the image uses an intellectual property license |
| Name | Description | Example |
|:----------------|:---------------------------------------------------| :----------------|
| Tag name | Whether the tag name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Promote to Target if Tag name ends in `stable`|
| Component name | Whether the image has a given component and the component name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Promote to Target if Component name starts with `b` |
| Vulnerabilities | Whether the image has vulnerabilities &ndash; critical, major, minor, or all &ndash; and your selected vulnerability filter is greater than or equals, greater than, equals, not equals, less than or equals, or less than your specified number | Promote to Target if Critical vulnerabilities = `3` |
| License | Whether the image uses an intellectual property license and is one of or not one of your specified words | Promote to Target if License name = `docker` |
Now you need to choose what happens to an image that meets all the criteria.
Select the **organization** and **repository** where the image is going to be
Select the target **organization** or **namespace** and **repository** where the image is going to be
pushed. You can choose to keep the image tag, or transform the tag into
something more meaningful in the destination repository, by using a tag template.
@ -59,7 +58,12 @@ timestamp of when the image was promoted.
![repository with policies](../../images/internal-promotion-3.png){: .with-border}
Everything is set up! Once the development team pushes an image that complies
with the policy, it automatically gets promoted.
with the policy, it automatically gets promoted. To confirm, select the **Promotions** tab on the `dev/website` repository.
![tag promoted](../../images/internal-promotion-5.png){: .with-border}
You can also review the newly pushed tag in the target repository by navigating to `qa/website` and selecting the **Tags** tab.
![tag promoted](../../images/internal-promotion-4.png){: .with-border}

69
ee/dtr/user/promotion-policies/push-mirror.md
View File

@ -6,46 +6,42 @@ keywords: registry, promotion, mirror
Docker Trusted Registry allows you to create mirroring policies for a repository.
When an image gets pushed to a repository and meets a certain criteria,
DTR automatically pushes it to repository in another DTR deployment or Docker
Hub.
DTR automatically pushes it to a repository in a remote Docker Trusted or Hub registry.
This not only allows you to mirror images but also allows you to create
image promotion pipelines that span multiple DTR deployments and datacenters.
In this example we'll create an image mirroring policy such that:
In this example we will create an image mirroring policy such that:
1. Developers iterate and push their builds to `dev.example.org/website/ui`, the
`website/ui` repository in the DTR deployment dedicated to development.
1. Developers iterate and push their builds to `dtr-example.com/dev/website` &endash; the
repository in the DTR deployment dedicated to development.
2. When the team creates a stable build, they make sure their image is tagged
with `-stable`.
3. When a stable build is pushed to `dev.example.org/website/ui`, it will
automatically be pushed to `qa.example.org/website/ui`, mirroring the image and
3. When a stable build is pushed to `dtr-example.com/dev/website`, it will
automatically be pushed to `qa-example.com/qa/website`, mirroring the image and
promoting it to the next stage of development.
![promotion example](../../images/push-mirror-1.svg)
With this mirroring policy, the development team doesn't need access to the
QA cluster, and the QA team doesn't need access to the development
With this mirroring policy, the development team does not need access to the
QA cluster, and the QA team does not need access to the development
cluster.
The person setting this mirroring policy needs to have permissions to push
to the destination repository.
You need to have permissions to push to the destination repository in order to set up the mirroring policy.
## Configure your repository
Once you've [created the repository](../manage-images/index.md), navigate to
the **DTR web UI**, go to the **repository details** page, and choose
**Mirrors**.
Once you have [created the repository](../manage-images/index.md), navigate to
the repository page on the web interface, and select the
**Mirrors** tab.
![create integration](../../images/push-mirror-2.png){: .with-border}
Click **New mirroring policy**, and define where the image will be pushed if
it meets the policy criteria. Make sure the account you use for the integration
has permissions to write in the destination repository.
Click **New mirror**, and define where the image will be pushed if
it meets the mirroring criteria. Make sure the account you use for the integration
has permissions to write to the remote repository. Under **Mirror direction**, choose **Push to remote registry**.
In this example we'll push the image to the `website/ui` repository of a
DTR deployment available at `qa.example.org`. We also use a service account
that was created just for mirroring images between repositories.
In this example, the image gets pushed to the `qa/website` repository of a
DTR deployment available at `qa-example.com` using a service account
that was created just for mirroring images between repositories. Note that you may use a password or access token to log in to your remote registry.
If the destination DTR deployment is using self-signed TLS certificates or
certificates issued by your own certificate authority, click
@ -58,33 +54,28 @@ Once you're done, click **Connect** to test the integration.
![test connection](../../images/push-mirror-3.png){: .with-border}
Under **Mirror direction** choose **push to remote registry**. Then specify the
policy that will trigger the image to be pushed to the external registry.
DTR allows you to set your mirroring policy based on the following image attributes:
DTR allows defining the following criteria:
| Name | Description |
|:----------------|:---------------------------------------------------|
| Tag name | If the tag name contains |
| Component name | If the image has a given component |
| Vulnerabilities | If the image has vulnerabilities |
| License | If the image uses an intellectual property license |
| Name | Description | Example |
|:----------------|:---------------------------------------------------| :----------------|
| Tag name | Whether the tag name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Copy image to remote repository if Tag name ends in `stable`|
| Component name | Whether the image has a given component and the component name equals, starts with, ends with, contains, is one of, or is not one of your specified string values | Copy image to remote repository if Component name starts with `b` |
| Vulnerabilities | Whether the image has vulnerabilities &ndash; critical, major, minor, or all &ndash; and your selected vulnerability filter is greater than or equals, greater than, equals, not equals, less than or equals, or less than your specified number | Copy image to remote repository if Critical vulnerabilities = `3` |
| License | Whether the image uses an intellectual property license and is one of or not one of your specified words | Copy image to remote repository if License name = `docker` |
Finally you can choose to keep the image tag, or transform the tag into
something more meaningful in the destination registry, by using a tag template.
something more meaningful in the remote registry by using a tag template.
![choose policy](../../images/push-mirror-4.png){: .with-border}
In this example, if an image in the `website/ui` repository is tagged with
In this example, if an image in the `dev/website` repository is tagged with
a word that ends in "stable", DTR will automatically push that image to
the DTR deployment available at `qa.example.org`. The image is pushed to the
`website/ui` repository and is tagged with the timestamp of when the image
the DTR deployment available at `qa-example.com`. The image is pushed to the
`qa/website` repository and is tagged with the timestamp of when the image
was promoted.
Everything is set up! Once the development team pushes an image that complies
with the policy, it automatically gets promoted.
![choose policy](../../images/push-mirror-5.png){: .with-border}
with the policy, it automatically gets promoted to `qa/website` in the remote trusted registry at `qa-example.com`.
## Metadata persistence

4
ee/ucp/admin/install/system-requirements.md
View File

@ -22,8 +22,8 @@ You can install UCP on-premises or on a cloud provider. Common requirements:
* 8GB of RAM for manager nodes
* 4GB of RAM for worker nodes
* 4GiB of free disk space for the root partition for manager nodes
* 500MiB of free disk space for the root partition for worker nodes
* 4GB of free disk space for the `/var` partition for manager nodes
* 500MB of free disk space for the `/var` partition for worker nodes
### Recommended production requirements

2
ee/ucp/admin/install/upgrade-offline.md
View File

@ -17,7 +17,7 @@ copy this package to the host where you upgrade UCP.
Use a computer with internet access to download the UCP package from the
following links.
{% include components/ddc_url_list_2.html product="ucp" version="3.0" %}
{% include components/ddc_url_list_2.html product="ucp" version="3.1" %}
## Download the offline package

4
ee/ucp/authorization/create-users-and-teams-manually.md
View File

@ -40,7 +40,7 @@ To use Docker EE's built-in authentication, you must [create users manually](#cr
The general flow of designing an organization with teams in UCP is:
1. Create an organization.
2. Add users or enable LDAD (for syncing users).
2. Add users or enable LDAP (for syncing users).
3. Create teams under the organization.
4. Add users to teams manually or sync with LDAP.
@ -91,4 +91,4 @@ To manually create users in UCP:
- [Synchronize teams with LDAP](create-teams-with-ldap.md)
- [Define roles with authorized API operations](define-roles.md)
- [Group and isolate cluster resources](group-resources.md)
- [Grant role-access to cluster resources](grant-permissions.md)
- [Grant role-access to cluster resources](grant-permissions.md)

BIN
ee/ucp/images/aws-ebs.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 59 KiB

133
ee/ucp/kubernetes/configure-aws-storage.md Normal file
View File

@ -0,0 +1,133 @@
---
title: Configure AWS EBS Storage for Kubernetes
description: Learn how configure AWS EBS storage for Kubernetes clusters.
keywords: UCP, Docker Enterprise, Kubernetes, storage, AWS, ELB
---
[AWS Elastic Block Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) (EBS) can be deployed with Kubernetes in Docker Enterprise 2.1 to use AWS volumes as peristent storage for applications. Before using EBS volumes, configure UCP and the AWS infrastructure for storage orchestration to function.
## Configure AWS Infrastructure for Kubernetes
Kubernetes [Cloud Providers](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) provide a method of provisioning cloud resources through Kubernetes via the `--cloud-provider` option. In AWS, this flag allows the [provisioning of EBS volumes](#) and cloud load balancers.
Configuring a cluster for AWS requires several specific configuration parameters in the infrastructure before installing UCP.
### AWS IAM Permissions
Instances must have the following [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) permissions configured to provision EBS volumes through Kubernetes PVCs.
| Master | Worker |
|------------|--------|
| ec2:DescribeInstances | ec2:DescribeInstances |
| ec2:AttachVolume | ec2:AttachVolume |
| ec2:DetachVolume | ec2:DetachVolume |
| ec2:DescribeVolumes | ec2:DescribeVolumes |
| ec2:CreateVolume | ec2:DescribeSecurityGroups |
| ec2:DeleteVolume | |
| ec2:CreateTags | |
| ec2:DescribeSecurityGroups | |
### Infrastructure Configuration
- Apply the roles and policies to Kubernetes masters and workers as indicated in the above chart.
- EC2 instances must be set to the private DNS hostname of the instance (will typically end in `.internal`)
- EC2 instances must also be labeled with the key `KubernetesCluster` with a matching value across all nodes.
### Cluster Configuration
- In addition to your existing [install flags](https://docs.docker.com/reference/ucp/3.0/cli/install/) the cloud provider flag `--cloud-provider=aws` is required at install time.
- The cloud provider can also be enabled post-install through the UCP config. The `ucp-agent` needs to be updated to propogate the new config, as described in [UCP configuration file](https://docs.docker.com/ee/ucp/admin/configure/ucp-configuration-file/#inspect-and-modify-existing-configuration).
```
[cluster_config]
...
cloud_provider = "aws"
```
## Deploy AWS EBS Volumes
After configuring UCP for the AWS cloud provider, you can create persistent volumes that deploy EBS volumes attached to hosts and mounted inside pods. The EBS volumes are provisioned dynamically such they are created, attached, destroyed along with the lifecycle of the persistent volumes. This does not require users to directly access to the AWS as you request these resources directly through Kubernetes primitives.
We recommend you use the `StorageClass` and `PersistentVolumeClaim` resources as these abstraction layers provide more portability as well as control over the storage layer across environments.
To learn more about storage concepts in Kubernetes, see [Storage - Kubernetes](https://kubernetes.io/docs/concepts/storage/).
### Creating a Storage Class
A `StorageClass` lets administrators describe “classes” of storage available in which classes map to quality-of-service levels, or backup policies, or any policies required by cluster administrators. The following `StorageClass` maps a "standard" class of storage to the `gp2` type of storage in AWS EBS.
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
reclaimPolicy: Retain
mountOptions:
- debug
```
For descriptions of AWS EBS parameters, see [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/#aws).
### Creating a Persistent Volume Claim
A `PersistentVolumeClaim` (PVC) is a claim for storage resources that are bound to a `PersistentVolume` (PV) when storage resources are granted. The following PVC makes a request for `1Gi` of storage from the `standard` storage class.
```
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: task-pv-claim
spec:
storageClassName: standard
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
```
### Deploying a Persistent Volume
The following Pod spec references the PVC `task-pv-claim` from above which references the `standard` storage class in this cluster.
```
kind: Pod
apiVersion: v1
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
```
### Inspecting and Using PVs
Once the pod is deployed, run the following `kubectl` command to verify the PV was created and bound to the PVC.
```
kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-751c006e-a00b-11e8-8007-0242ac110012 1Gi RWO Retain Bound default/task-pv-claim standard 3h
```
The AWS console shows a volume has been provisioned having a matching name with type `gp2` and a `1GiB` size.
![](../images/aws-ebs.png)

5
ee/ucp/release-notes.md
View File

@ -98,6 +98,8 @@ There are several backward-incompatible changes in the Kubernetes API that may a
* Pod Security Policies are not supported in this release. (#15105)
* The default Kubelet configuration for UCP Manager nodes is expecting 4GB of free disk space in the `/var` partition. See [System Requirements](/ee/ucp/admin/install/system-requirements) for details.
## Deprecated features
The following features are deprecated in UCP 3.1.
@ -420,7 +422,6 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
**Bug fixes**
<<<<<<< HEAD
* Core
* Resolved an issue where LDAP sync jobs terminated when processing an org admin
Search result that does not resolve to an existing user. (docker/escalation#784 #docker/escalation#888)
@ -428,7 +429,6 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
* UI
* Fixed an issue that caused "Per User Limit" to not work on Admin Settings. (docker/escalation#639)
=======
* Core
* Resolved an issue where LDAP sync jobs would crash when handling an org admin search result which does not correspond to an existing user. (docker/escalation#784 #docker/escalation#888)
* Fixed an issue that caused RethinkDB client lock contention. (docker/escalation#902 and docker/escalation#906)
@ -443,7 +443,6 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
* Security
* Fixed a critical security issue to prevent UCP from accepting certificates from
the system pool when adding client CAs to the server that requires mutual authentication.
>>>>>>> ba65aeabbb67b4cc2464497cfbe8bbccec8aacb2
## Version 2.2.12 (2018-08-09)

4
engine/reference/commandline/README.md
View File

@ -2,7 +2,7 @@
The files in this directory are stub files which include the file
`/_includes/cli.md`, which parses YAML files generated from the
[`docker/docker`](https://github.com/moby/moby) repository. The YAML files
[`docker/cli`](https://github.com/docker/cli) repository. The YAML files
are parsed into output files like
[/engine/reference/commandline/build/](/engine/reference/commandline/build/).
@ -14,7 +14,7 @@ The output files are composed from two sources:
the CLI source code in that repository.
- The **Extended Description** and **Examples** sections are pulled into the
YAML from the files in [https://github.com/moby/moby/tree/master/docs/reference/commandline](https://github.com/moby/moby/tree/master/docs/reference/commandline)
YAML from the files in [https://github.com/docker/cli/tree/master/docs/reference/commandline](https://github.com/docker/cli/tree/master/docs/reference/commandline)
Specifically, the Markdown inside the `## Description` and `## Examples`
headings are parsed. Submit corrections to the text in that repository.

17
machine/AVAILABLE_DRIVER_PLUGINS.md
View File

@ -192,6 +192,23 @@ with Docker Inc. Use 3rd party plugins at your own risk.
<a href="mailto:bo.thompson@gmail.com">bo.thompson@gmail.com</a>
</td>
</tr>
<tr>
<td>Hetzner Cloud</td>
<td>
<a href=
"https://github.com/JonasProgrammer/docker-machine-driver-hetzner">https://github.com/JonasProgrammer/docker-machine-driver-hetzner</a>
</td>
<td>
<a href="https://github.com/JonasProgrammer">JonasProgrammer</a><br>
<a href="https://github.com/monochromata">monochromata</a><br>
<a href="https://github.com/mxschmitt">mxschmitt</a>
</td>
<td>
<a href="mailto:jonass@dev.jsje.de">jonass@dev.jsje.de</a><br>
<a href="mailto:sl@monochromata.de">sl@monochromata.de</a><br>
<a href="mailto:max@schmitt.mx">max@schmitt.mx</a>
</td>
</tr>
<tr>
<td>HPE OneView</td>
<td>

16
reference/dtr/2.5/api/index.html
View File

@ -1,16 +0,0 @@
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Docker Trusted Registry API Documentation</title>
<link rel="stylesheet" type="text/css" href="./swagger-ui.css" >
</head>
<body>
<div id="swagger-ui"></div>
<script src="./swagger-ui-bundle.js"> </script>
<script src="./swagger-ui-standalone-preset.js"> </script>
<script src="./main.js"> </script>
</body>
</html>

21
reference/dtr/2.5/api/main.js
View File

File diff suppressed because one or more lines are too long

105
reference/dtr/2.5/api/swagger-ui-bundle.js
View File

File diff suppressed because one or more lines are too long

21
reference/dtr/2.5/api/swagger-ui-standalone-preset.js
View File

File diff suppressed because one or more lines are too long

5
reference/dtr/2.5/api/swagger-ui.css
View File

File diff suppressed because one or more lines are too long

54
reference/dtr/2.5/cli/backup.md
View File

@ -1,54 +0,0 @@
---
title: docker/dtr backup
description: Create a backup of DTR
keywords: dtr, cli, backup
---
Create a backup of DTR
## Usage
```bash
docker run -i --rm docker/dtr \
backup [command options] > backup.tar
```
## Description
This command creates a tar file with the contents of the volumes used by
DTR, and prints it. You can then use the 'restore' command to restore the data
from an existing backup.
Note:
* This command only creates backups of configurations, and image metadata.
It doesn't backup users and organizations. Users and organizations can be
backed up when performing a UCP backup.
It also doesn't backup the Docker images stored in your registry.
You should implement a separate backup policy for the Docker images stored
in your registry, taking in consideration whether your DTR installation is
configured to store images on the filesystem or using a cloud provider.
* This backup contains sensitive information and should be
stored securely.
* Using the '--offline-backup' flag will temporarily shut down the rethinkdb container.
You should take the replica out of your load balancer to avoid downtime.
## Options
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica.To add, remove or modify DTR, you must connect to an existing healthy replica's database.. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--offline-backup` | $DTR_OFFLINE_BACKUP | This flag takes rethinkdb down during backup and takes a more reliable backup..If you back up DTR with this flag, rethinkdb will go down during backup. However, it will be guaranteed to be consistent. With online backups there's no guarantee of consistency.. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

38
reference/dtr/2.5/cli/destroy.md
View File

@ -1,38 +0,0 @@
---
title: docker/dtr destroy
description: Destroy a DTR replica's data
keywords: dtr, cli, destroy
---
Destroy a DTR replica's data
## Usage
```bash
docker run -it --rm docker/dtr \
destroy [command options]
```
## Description
This command forcefully removes all containers and volumes associated with
a DTR replica without notifying the rest of the cluster. Use this command
on all replicas uninstall DTR.
Use the 'remove' command to gracefully scale down your DTR cluster.
## Options
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--replica-id` | $DTR_DESTROY_REPLICA_ID | The ID of the replica to destroy. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |

22
reference/dtr/2.5/cli/images.md
View File

@ -1,22 +0,0 @@
---
title: docker/dtr images
description: List all the images necessary to install DTR
keywords: dtr, cli, images
---
List all the images necessary to install DTR
## Usage
```bash
docker run -it --rm docker/dtr \
images [command options]
```
## Description
This command lists all the images necessary to install DTR.

36
reference/dtr/2.5/cli/index.md
View File

@ -1,36 +0,0 @@
---
title: docker/dtr overview
description: Learn about the commands available in the docker/dtr image.
keywords: dtr, install, uninstall, configure
---
This tool has commands to install, configure, and backup Docker
Trusted Registry (DTR). It also allows uninstalling DTR.
By default the tool runs in interactive mode. It prompts you for
the values needed.
Additional help is available for each command with the '--help' option.
## Usage
```bash
docker run -it --rm docker/dtr \
command [command options]
```
## Commands
| Option | Description |
|:-------------------------------------|:------------------------------------------------|
| [install](install) | Install Docker Trusted Registry |
| [join](join) | Add a new replica to an existing DTR cluster |
| [reconfigure](reconfigure) | Change DTR configurations |
| [remove](remove) | Remove a DTR replica from a cluster |
| [destroy](destroy) | Destroy a DTR replica's data |
| [restore](restore) | Install and restore DTR from an existing backup |
| [backup](backup) | Create a backup of DTR |
| [upgrade](upgrade) | Upgrade DTR 2.4.x cluster to this version |
| [images](images) | List all the images necessary to install DTR |
| [emergency-repair](emergency-repair) | Recover DTR from loss of quorum |

64
reference/dtr/2.5/cli/install.md
View File

@ -1,64 +0,0 @@
---
title: docker/dtr install
description: Install Docker Trusted Registry
keywords: dtr, cli, install
---
Install Docker Trusted Registry
## Usage
```bash
docker run -it --rm docker/dtr \
install [command options]
```
## Description
This command installs Docker Trusted Registry (DTR) on a node managed by
Docker Universal Control Plane (UCP).
After installing DTR, you can join additional DTR replicas using the 'join'
command.
Example usage:
$ docker run -it --rm docker/dtr:2.5.0 install \
--ucp-node <UCP_NODE_HOSTNAME> \
--ucp-insecure-tls
Note: Use --ucp-ca "$(cat ca.pem)" instead of --ucp-insecure-tls for a production deployment.
## Options
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--dtr-ca` | $DTR_CA | Use a PEM-encoded TLS CA certificate for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS CA certificate with --dtr-ca "$(cat ca.pem)". |
| `--dtr-cert` | $DTR_CERT | Use a PEM-encoded TLS certificate for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS certificate with --dtr-cert "$(cat ca.pem)". |
| `--dtr-external-url` | $DTR_EXTERNAL_URL | URL of the host or load balancer clients use to reach DTR.When you use this flag, users are redirected to UCP for logging in. Once authenticated they are redirected to the url you specify in this flag. If you don't use this flag, DTR is deployed without single sign-on with UCP. Users and teams are shared but users login separately into the two applications. You can enable and disable single sign-on in the DTR settings. Format https://host[:port], where port is the value you used with --replica-https-port. |
| `--dtr-key` | $DTR_KEY | Use a PEM-encoded TLS private key for DTR.By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS private key with --dtr-key "$(cat ca.pem)". |
| `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Customize the volume to store Docker images.By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify a full path or volume name for DTR to store images. For high-availability, make sure all DTR replicas can read and write data on this volume. If you're using NFS, use --nfs-storage-url instead. |
| `--enable-pprof` | $DTR_PPROF | Enables pprof profiling of the server; use --enable-pprof=false to disable it.Once DTR is deployed with this flag, you can access the pprof endpoint for the api server at /debug/pprof, and the registry endpoint at /registry_debug_pprof/debug/pprof. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--http-proxy` | $DTR_HTTP_PROXY | The HTTP proxy used for outgoing requests. |
| `--https-proxy` | $DTR_HTTPS_PROXY | The HTTPS proxy used for outgoing requests. |
| `--log-host` | $LOG_HOST | The syslog system to send logs to.The endpoint to send logs to. Use this flag if you set --log-protocol to tcp or udp. |
| `--log-level` | $LOG_LEVEL | Log level for all container logs when logging to syslog. Default: INFO.The supported log levels are debug, info, warn, error, or fatal.. |
| `--log-protocol` | $LOG_PROTOCOL | The protocol for sending logs. Default is internal.By default, DTR internal components log information using the logger specified in the Docker daemon in the node where the DTR replica is deployed. Use this option to send DTR logs to an external syslog system. The supported values are tcp, udp, and internal. Internal is the default option, stopping DTR from sending logs to an external system. Use this flag with --log-host. |
| `--nfs-storage-url` | $NFS_STORAGE_URL | NFS to store Docker images. Format nfs://<ip&#124;hostname>/<mountpoint>.By default DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high-availability. Use this flag to specify an NFS mount for DTR to store images, using the format nfs://<ip&#124;hostname>/<mountpoint>. To use this flag, you need to install an NFS client library like nfs-common in the node where you're deploying DTR. You can test this by running showmount -e <nfs-server>. When you join new replicas, they will start using NFS so you don't need to use this flag. To reconfigure DTR to stop using NFS, leave this option empty. |
| `--no-proxy` | $DTR_NO_PROXY | List of domains the proxy should not be used for.When using --http-proxy you can use this flag to specify a list of domains that you don't want to route through the proxy. Format acme.com[, acme.org]. |
| `--overlay-subnet` | $DTR_OVERLAY_SUBNET | The subnet used by the dtr-ol overlay network. Example: 10.0.0.0/24.For high-availalibity, DTR creates an overlay network between UCP nodes. This flag allows you to choose the subnet for that network. Make sure the subnet you choose is not used on any machine where DTR replicas are deployed. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is 80.This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with --replica-https-port. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is 443.This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--replica-id` | $DTR_INSTALL_REPLICA_ID | Assign a 12-character hexadecimal ID to the DTR replica. Random by default. |
| `--replica-rethinkdb-cache-mb` | $RETHINKDB_CACHE_MB | The maximum amount of space for rethinkdb in-memory cache use for the given replica in MB.
Default is auto. Auto is (available_memory - 1024) / 2.This config allows changing the rethinkdb cache usage per replica. You need to run it once per replica to change each one.. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--ucp-node` | $UCP_NODE | The hostname of the UCP node to deploy DTR. Random by default.You can find the hostnames of the nodes in the cluster in the UCP web UI, or by running 'docker node ls' on a UCP manager node.. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |

40
reference/dtr/2.5/cli/join.md
View File

@ -1,40 +0,0 @@
---
title: docker/dtr join
description: Add a new replica to an existing DTR cluster
keywords: dtr, cli, join
---
Add a new replica to an existing DTR cluster
## Description
This command creates a replica of an existing DTR on a node managed by
Docker Universal Control Plane (UCP).
For setting DTR for high-availability, create 3, 5, or 7 replicas of DTR.
## Options
| Option | Environment Variable | Description |
|:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------|
| `--debug` | $DEBUG | Enable debug mode for additional logs. |
| `--existing-replica-id` | $DTR_REPLICA_ID | The ID of an existing DTR replica.To add, remove or modify DTR, you must connect to an existing healthy replica's database.. |
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
| `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is 80.This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with --replica-https-port. This port can also be used for unencrypted health checks. |
| `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is 443.This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. |
| `--replica-id` | $DTR_INSTALL_REPLICA_ID | Assign a 12-character hexadecimal ID to the DTR replica. Random by default. |
| `--replica-rethinkdb-cache-mb` | $RETHINKDB_CACHE_MB | The maximum amount of space for rethinkdb in-memory cache use for the given replica in MB.
Default is auto. Auto is (available_memory - 1024) / 2.This config allows changing the rethinkdb cache usage per replica. You need to run it once per replica to change each one.. |
| `--skip-network-test` | $DTR_SKIP_NETWORK_TEST | Don't test if overlay networks are working correctly between UCP nodes.For high-availalibity, DTR creates an overlay network between UCP nodes and tests that it is working when joining replicas. Don't use this option for production deployments. |
| `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP.Download the UCP TLS CA certificate from https://<ucp-url>/ca, and use --ucp-ca "$(cat ca.pem)". |
| `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP.The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to man-in-the-middle attacks. For production deployments, use --ucp-ca "$(cat ca.pem)" instead. |
| `--ucp-node` | $UCP_NODE | The hostname of the UCP node to deploy DTR. Random by default.You can find the hostnames of the nodes in the cluster in the UCP web UI, or by running 'docker node ls' on a UCP manager node.. |
| `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. |
| `--ucp-url` | $UCP_URL | The UCP URL including domain and port. |
| `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |
| `--unsafe-join` | $DTR_UNSAFE_JOIN | Join a new replica even if the cluster is unhealthy.Joining replicas to an unhealthy DTR cluster leads to split-brain scenarios, and data loss. Don't use this option for production deployments. |

Some files were not shown because too many files have changed in this diff Show More