The `oom-score-adjust` option was added to prevent the daemon from being
OOM-killed before other processes. This option was mostly added as a
convenience, as running the daemon as a systemd unit was not yet common.
Having the daemon set its own limits is not best-practice, and something
better handled by the process-manager starting the daemon.
Docker v20.10 and newer no longer adjust the daemon's OOM score by default,
instead setting the OOM-score to the systemd unit (OOMScoreAdjust) that's
shipped with the packages.
Users currently depending on this feature are recommended to adjust the
daemon's OOM score using systemd or through other means, when starting
the daemon.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
As a stepping-stone towards switching to go modules, we're switching the
versioning scheme to be SemVer(ish) instead of CalVer. Note that this
currently still is `+incompatible` version, as changing to a version > 1
requires the module to be renamed, but changes in that area will arrive
in a future release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 955c1f881a
(v17.12.0) replaced detection of support for multiple lowerdirs (as required by
overlay2) to not depend on the kernel version. The `overlay2.override_kernel_check`
was still used to print a warning that older kernel versions may not have full
support.
After this, e226aea280
(v20.10, but backported to v19.03.7) removed uses of the option altogether.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These options were soft-deprecated in Docker 17.05, and at the time
considered to not be removed. However, with the move towards containerd
snapshotters, having these options around adds additional complexity to
handle fallbacks for deprecated (and hidden) flags, so completing the
deprecation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Configuration (enabling/disabling) of Experimental client features
was deprecated in Docker 19.03, and removed in 20.10. Experimental
CLI features are now always enabled. In Docker 20.10, the Experimental
field in `docker version` was kept (but always true).
This patch removes the field from the output (both "pretty" output
and the JSON struct).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
My IDE's linter kept complaining:
> For compatibility reasons all table rows should have borders (pipe
> symbols) at the start and at the end.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `~/.dockercfg` file was replaced by `~/.docker/config.json` in 2015
(github.com/docker/docker/commit/18c9b6c6455f116ae59cde8544413b3d7d294a5e),
but the CLI still falls back to checking if this file exists if no current
(`~/.docker/config.json`) file was found.
Given that no version of the CLI since Docker v1.7.0 has created this file,
and if such a file exists, it means someone hasn't re-authenticated for
5 years, it's probably safe to remove this fallback.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Explicitly mention flags and environment variables that were removed, to
make the deprecation more discoverable.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- expand a bit on what's happening
- clarify start of deprecation of the classic builder
- show examples of error and warning
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
> Legacy PEM encryption as specified in RFC 1423 is insecure by design. Since
> it does not authenticate the ciphertext, it is vulnerable to padding oracle
> attacks that can let an attacker recover the plaintext
From https://go-review.googlesource.com/c/go/+/264159
> It's unfortunate that we don't implement PKCS#8 encryption so we can't
> recommend an alternative but PEM encryption is so broken that it's worth
> deprecating outright.
This feature allowed using an encrypted private key with a supplied password,
but did not provide additional security as the encryption is known to be broken,
and the key is sitting next to the password in the filesystem. Users are recommended
to decrypt the private key, and store it un-encrypted to continue using it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This replaces the use of bash where suitable, to allow easier copy/pasting
of shell examples without copying the prompt or process output.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
> Legacy PEM encryption as specified in RFC 1423 is insecure by design. Since
> it does not authenticate the ciphertext, it is vulnerable to padding oracle
> attacks that can let an attacker recover the plaintext
From https://go-review.googlesource.com/c/go/+/264159
> It's unfortunate that we don't implement PKCS#8 encryption so we can't
> recommend an alternative but PEM encryption is so broken that it's worth
> deprecating outright.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These options were deprecated and removed in the Linux kernel v5.0 and up in;
- f382fb0bce
- fb5772cbfe
- 23aa16489c
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker Engine v20.10 and up includes optimizations to verify if images in the
local image cache need updating before pulling, preventing the Docker Engine
from making unnecessary API requests. These optimizations require the container
image registry to conform to the Open Container Initiative Distribution Specification
(https://github.com/opencontainers/distribution-spec).
While most registries conform to the specification, we encountered some registries
to be non-compliant, resulting in `docker pull` to fail.
As a temporary solution, Docker Engine v20.10 includes a fallback mechanism to
allow `docker pull` to be functional when using a non-compliant registry. A
warning message is printed in this situation:
WARNING Failed to pull manifest by the resolved digest. This registry does not
appear to conform to the distribution registry specification; falling back to
pull by tag. This fallback is DEPRECATED, and will be removed in a future
release.
The fallback is added to allow users to either migrate their images to a compliant
registry, or for these registries to become compliant.
Note that this fallback only addresses failures on `docker pull`. Other commands,
such as `docker stack deploy`, or pulling images with `containerd` will continue
to fail.
Given that other functionality is still broken with these registries, we consider
this fallback a _temporary_ solution, and will remove the fallback in an upcoming
major release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker v17.07 introduced an experimental `--stream` flag on `docker build` which
allowed the build-context to be incrementally sent to the daemon, instead of
unconditionally sending the whole build-context.
This functionality has been reimplemented as part of BuildKit, which uses streaming
by default and the `--stream` option will be ignored when using the classic builder,
printing a deprecation warning instead.
Users that want to use this feature are encouraged to enable BuildKit by setting
the `DOCKER_BUILDKIT=1` environment variable or through the daemon or CLI configuration
files.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The experimental feature to run Linux containers on Windows (LCOW) was introduced
as a technical preview in Docker 17.09. While many enhancements were made after
its introduction, the feature never reached completeness, and development has
now stopped in favor of running docker natively on Linux in WSL2.
Developers that need to run Linux workloads on a Windows host are encouraged
to use Docker Desktop with WSL2 instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Some deprecations are ammended during a major (YY.MM) release, to
inform users as early as possible about deprecations. Removing the
minor version from this overview clarifies that features are
marked deprecated during which major release's lifecycle.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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 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>
Sebastiaan van Stijn
Paweł Gronowski
Sebastiaan van Stijn
Nicolas De Loof
CrazyMax
Dmitriy Fishman
Mathieu Champlon
Akihiro Suda