Previously, `version: "3"` was equivalent to `version: "3.0"`, which
caused confusion for many users, as they expected it to be "3.x".
docker-compose and docker compose (v2) have adopted the compose-spec
(https://compose-spec.io), which no longer has a version field in
the compose file, and always picks the "latest" supported version.
This changes how `docker stack` interprets "major" version numbers
specified in compose-files:
When only the major version ("3") is specified, it is now equivalent
to "3.x" (latest supported v3 schema).
Compose-files that specify both major and minor version (e.g. "3.0"
or "3.1") continue to use the existing behavior; validation is down-
graded to the specified version and will produce an error if options
are used that are not supported in that schema version. This allows
users to locally verify that a composse-file does not use options
that are not supported in the intended deployment environment (for
example if the deploy environment only supports older versions of
the schema).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Remove various tests and utilities related to testing kubernetes support
Also removing the Kubernetes and DefaultStackOrchestrator from CreateOptions
and UpdateOptions, instead updating the flags to not be bound to a variable.
This might break some consumers of those options, but given that they've become
non-functional, that's probably ok (otherwise they may ignore the deprecation
warning and end up with non-functional code).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Removes the --kubeconfig flag, and the corresponding ExportOptions.Kubeconfig,
as well as special handling for kubeconfig export, as it's no longer used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The compose spec (https://compose-spec.io) defines the version to be optional,
and implementations of the spec to check for supported attributes instead.
While this change does not switch the `docker stack` implementation to use the
compose-spec, it makes it function more similar. Previously, omitting a version
number would either produce an error (as the field was required), or switched
the handling to assume it was version 1.0 (which is deprecated).
With this change, compose files without a version number will be handled as
the latest version supported by `docker stack` (currently 3.10). This allows
users that work with docker-compose or docker compose (v2) to deploy their
compose file, without having to re-add a version number. Fields that are
not supported by stackes (schema 3.10) will still produce an error.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adding a copy of the 3.9 schema, with only the version-string changed.
This makes it easier to find changes since 3.9, which are added after
this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With this change:
echo 'FROM busybox' | DOCKER_BUILDKIT=1 docker build -
ERROR: BuildKit is enabled but the buildx component is missing or broken.
Install the buildx component to build images with BuildKit:
https://docs.docker.com/go/buildx/
echo 'FROM busybox' | docker build -
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
Install the buildx component to build images with BuildKit:
https://docs.docker.com/go/buildx/
Sending build context to Docker daemon 2.048kB
...
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>
Sebastiaan van Stijn
Sebastiaan van Stijn
CrazyMax
Nicolas De Loof
John Howard