The Docker daemon provides a versioned API for backward compatibility with old
clients. Docker clients can perform API-version negotiation to select the most
recent API version supported by the daemon (downgrading to and older version of
the API when necessary). API version negotiation was introduced in Docker v1.12.0
(API 1.24), and clients before that used a fixed API version.
Docker Engine versions through v25.0 provide support for all [API versions](https://docs.docker.com/engine/api/#api-version-matrix)
included in stable releases for a given platform. For Docker daemons on Linux,
the earliest supported API version is 1.12 (corresponding with Docker Engine
v1.0.0), whereas for Docker daemons on Windows, the earliest supported API
version is 1.24 (corresponding with Docker Engine v1.12.0).
Support for legacy API versions (providing old API versions on current versions
of the Docker Engine) is primarily intended to provide compatibility with recent,
but still supported versions of the client, which is a common scenario (the Docker
daemon may be updated to the latest release, but not all clients may be up-to-date
or vice versa). Support for API versions before that (API versions provided by
EOL versions of the Docker Daemon) is provided on a "best effort" basis.
Use of old API versions is very rare, and support for legacy API versions
involves significant complexity (Docker 1.0.0 having been released 10 years ago).
Because of this, we'll start deprecating support for legacy API versions.
Docker Engine v25.0 by default disables API version older than 1.24 (aligning
the minimum supported API version between Linux and Windows daemons). When
connecting with a client that uses an API version version older than 1.24,
the daemon returns an error. The following example configures the docker
CLI to use API version 1.23, which produces an error:
DOCKER_API_VERSION=1.23 docker version
Error response from daemon: client version 1.23 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version
An environment variable (`DOCKER_MIN_API_VERSION`) is introduced that allows
re-enabling older API versions in the daemon. This environment variable must
be set in the daemon's environment (for example, through a [systemd override
file](https://docs.docker.com/config/daemon/systemd/)), and the specified
API version must be supported by the daemon (`1.12` or higher on Linux, or
`1.24` or higher on Windows).
Support for API versions lower than `1.24` will be permanently removed in Docker
Engine v26, and the minimum supported API version will be incrementally raised
in releases following that.
We do not recommend depending on the `DOCKER_MIN_API_VERSION` environment
variable other than for exceptional cases where it's not possible to update
old clients, and those clients must be supported.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Using this option on the daemon will now produce an error (flag will
be removed entirely in v26.0).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Related to https://github.com/moby/moby/pull/46853
Co-Authored-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
This driver has been deprecated and removed because the service
is no longer operational. Update the deprecated features docs to
mention it's been fully removed in Docker v25.0.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The service has been discontinued on November 15, 2022:
> Dear Logentries user,
>
> We have identified you as the owner of, or collaborator of, a Logentries
> account.
>
> The Logentries service will be discontinued on November 15th, 2022. This
> means that your Logentries account access will be removed and all your
> log data will be permanently deleted on this date.
>
> Next Steps
> If you are interested in an alternative Rapid7 log management solution,
> InsightOps will be available for purchase through December 16th, 2022.
> Please note, there is no support to migrate your existing Logentries
> account to InsightOps.
>
> Thank you for being a valued user of Logentries.
>
> Thank you,
> Rapid7 Customer Success
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 304c100ed2 updated the deprecation
status for these options, but forgot to update the status in the table.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 5d6612798a updated the deprecation
status for devicemapper to "removed", but forgot to update the status
in the table.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The IsAutomated field is being deprecated by Docker Hub's search API and
will always be "false" in future.
This patch:
- Deprecates the field and the related "is-automated" filter
- Removes the "AUTOMATED" column from the default output of "docker search"
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit de8b696ed6 removed the patch
releases from the deprecation doc, but when we switched to the
SemVer(ish) format for v23.0, we accidentally added them back.
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).
Commit b83bc67136 (v23.0.0, but backported to
v20.10) added a warning if no "current" config file was found but a legacy
file was, and if the CLI would fall back to using the deprecated file.
Commit ee218fa89e removed support for the
legacy file, but kept a warning in place if a legacy file was in place,
and now ignored.
This patch removes the warning as well, fully deprecating the legacy
`~/.dockercfg` file.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
Sebastiaan van Stijn
Albin Kerouanton
Paweł Gronowski
Sebastiaan van Stijn
Nicolas De Loof
CrazyMax
Dmitriy Fishman
Mathieu Champlon