The Dockerfile `ENV` instruction allows values to be set using either `ENV name=value`
or `ENV name value`. The latter (`ENV name value`) form can be ambiguous, for example,
the following defines a single env-variable (`ONE`) with value `"TWO= THREE=world"`,
but may have intended to be setting three env-vars:
ENV ONE TWO= THREE=world
This format also does not allow setting multiple environment-variables in a single
`ENV` line in the Dockerfile.
Use of the `ENV name value` syntax is discouraged, and may be removed in a future
release. Users are encouraged to update their Dockerfiles to use the `ENV name=value`
syntax, for example:
ENV ONE="" TWO="" THREE="world"
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `ENV key value` form can be ambiguous, for example, the following defines
a single env-variable (`ONE`) with value `"TWO= THREE=world"`:
ENV ONE TWO= THREE=world
While we cannot deprecate/remove that syntax (as it would break existing
Dockerfiles), we should reduce exposure of the format in our examples.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When creating and updating services, we need to avoid unneeded service churn.
The interaction of separate lists to "add" and "drop" capabilities, a special
("ALL") capability, as well as a "relaxed" format for accepted capabilities
(case-insensitive, `CAP_` prefix optional) make this rather involved.
This patch updates how we handle `--cap-add` / `--cap-drop` when _creating_ as
well as _updating_, with the following rules/assumptions applied:
- both existing (service spec) and new (values passed through flags or in
the compose-file) are normalized and de-duplicated before use.
- the special "ALL" capability is equivalent to "all capabilities" and taken
into account when normalizing capabilities. Combining "ALL" capabilities
and other capabilities is therefore equivalent to just specifying "ALL".
- adding capabilities takes precedence over dropping, which means that if
a capability is both set to be "dropped" and to be "added", it is removed
from the list to "drop".
- the final lists should be sorted and normalized to reduce service churn
- no validation of capabilities is handled by the client. Validation is
delegated to the daemon/server.
When deploying a service using a docker-compose file, the docker-compose file
is *mostly* handled as being "declarative". However, many of the issues outlined
above also apply to compose-files, so similar handling is applied to compose
files as well to prevent service churn.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The docker CLI up until v1.7.0 used the `~/.dockercfg` file to store credentials
after authenticating to a registry (`docker login`). Docker v1.7.0 replaced this
file with a new CLI configuration file, located in `~/.docker/config.json`. When
implementing the new configuration file, the old file (and file-format) was kept
as a fall-back, to assist existing users with migrating to the new file.
Given that the old file format encourages insecure storage of credentials
(credentials are stored unencrypted), and that no version of the CLI since
Docker v1.7.0 has created this file, the file is marked deprecated, and support
for this file will be removed in a future release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The output format was changed to combine tag and name in a single
column, but this change was never reflected in the docs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This reflects a Moby change to add documentation around
disabling a new feature -- to use pgzip to decompress
layers, rather than the built-in go gzip.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This creates a new section of environment variables in the CLI docs
which documents environment variables that can both be used on dockerd
and on docker cli.
In addition, it moves some of the environment variable documentation
from the docker cli documentation to the dockerd documentation, as
these environment variables are dockerd-specific.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Engine API docs are not available in this GitHub repository,
so linking to the docs.docker.com website instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- replace the "none" code-hint with "console"
- some changes in the "experimental" instructions
- reformat some notes
- reformat / re-indent JSON output to use 2 spaces (for consistency)
- split JSON outputs to separate code-block so that it can be highlighted
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds the currently selected "docker context" to the output
of "docker version", which allows users to see which context
is selected to produce the version output, and can be used (for
example), to set the prompt to the currently selected context:
(in `~/.bashrc`):
```bash
function docker_context_prompt() {
PS1="context: $(docker version --format='{{.Client.Context}}')> "
}
PROMPT_COMMAND=docker_context_prompt
```
After reloading the `~/.bashrc`, the prompt now shows the currently selected
`docker context`:
```bash
$ source ~/.bashrc
context: default> docker context create --docker host=unix:///var/run/docker.sock my-context
my-context
Successfully created context "my-context"
context: default> docker context use my-context
my-context
Current context is now "my-context"
context: my-context> docker context use default
default
Current context is now "default"
context: default>
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Using `/var/run/docker.sock` as docker host is invalid, and causes
an error, so adding `unix://` to it.
In addition, we document the name of the context to go after the
options, so change the order in the examples.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Tibor Vass
Sebastiaan van Stijn
Albin Kerouanton
Sebastiaan van Stijn
horpto
eyherabh
Tonis Tiigi
Akihiro Suda
Brian Wieder
Silvin Lubecki
dito
Saswat Bhattacharya
Sargun Dhillon
Justin Cormack
Simon Heimberg
devisions
Silvin Lubecki