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>
This commit fixes spelling mistakes (typos) at a few places in the codebase.
Signed-off-by: Amey Shrivastava <72866602+AmeyShrivastava@users.noreply.github.com>
The DefaultStopSignal const has been deprecated, because the daemon already
handles a default value. The current code did not actually send the default
value unless the flag was set, which also made the flag description incorrect,
because in that case, the _daemon's_ default would be used, which could
potentially be different as was specified here.
This patch removes the default value from the flag, leaving it to the daemon
to set a default.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Locking was removed in https://github.com/docker/cli/pull/3025 which
allows for parallel calls to config.Load to modify global state.
The consequence in this case is innocuous, but it does trigger a
`DATA RACE` exception when tests run with `-race` option.
Signed-off-by: coryb <cbennett@netflix.com>
This allows us to drop the `//go:generate` and use of the github.com/mjibson/esc
utility.
worth noting that Go's native "embed" does not compress files. We could compress
these files as part of a build / validate step (which would add some complexity
when updating these files) if this is a concern, but not sure if the additional
complexity is warranted.
Comparing before/after sizes (see below);
macOS: 54125840 - 54005264 = 120576 (+120.58 kB)
Linux: 52393231 - 52277701 = 115530 (+115.53 kB)
Before:
ls -l build/
total 208736
lrwxr-xr-x 1 sebastiaan staff 19 Aug 15 09:36 docker@ -> docker-linux-amd64
-rwxr-xr-x 1 sebastiaan staff 54005264 Aug 15 09:35 docker-darwin-amd64*
-rwxr-xr-x 1 sebastiaan staff 52277701 Aug 15 09:36 docker-linux-amd64*
After:
ls -l build/
total 208960
lrwxr-xr-x 1 sebastiaan staff 18 Aug 15 09:32 docker@ -> docker-linux-amd64
-rwxr-xr-x 1 sebastiaan staff 54125840 Aug 15 09:31 docker-darwin-amd64*
-rwxr-xr-x 1 sebastiaan staff 52393231 Aug 15 09:32 docker-linux-amd64*
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 73aef6edfe
modified archive.ReplaceFileTarWrapper to set the Name field in the tar header,
if the field was not set.
That change exposed an issue in how a Dockerfile from stdin was sent to the daemon.
When attempting to build using a build-context, and a Dockerfile from stdin, the
following happened:
```bash
mkdir build-stdin && cd build-stdin && echo hello > hello.txt
DOCKER_BUILDKIT=0 docker build --no-cache -t foo -f- . <<'EOF'
FROM alpine
COPY . .
EOF
Sending build context to Docker daemon 2.607kB
Error response from daemon: dockerfile parse error line 1: unknown instruction: .DOCKERIGNORE
```
Removing the `-t foo`, oddly lead to a different failure:
```bash
DOCKER_BUILDKIT=0 docker build --no-cache -f- . <<'EOF'
FROM alpine
COPY . .
EOF
Sending build context to Docker daemon 2.581kB
Error response from daemon: Cannot locate specified Dockerfile: .dockerfile.701d0d71fb1497d6a7ce
```
From the above, it looks like the tar headers got mangled, causing (in the first
case) the daemon to use the build-context tar as a plain-text file, and therefore
parsing it as Dockerfile, and in the second case, causing it to not being able to
find the Dockerfile in the context.
I noticed that both TarModifierFuncs were using the same `hdrTmpl` struct, which
looks to caused them to step on each other's toes. Changing them to each initialize
their own struct made the issue go away.
After this change:
```bash
DOCKER_BUILDKIT=0 docker build --no-cache -t foo -f- . <<'EOF'
FROM alpine
COPY . .
EOF
Sending build context to Docker daemon 2.607kB
Step 1/2 : FROM alpine
---> d4ff818577bc
Step 2/2 : COPY . .
---> 556f745e6938
Successfully built 556f745e6938
Successfully tagged foo:latest
DOCKER_BUILDKIT=0 docker build --no-cache -f- . <<'EOF'
FROM alpine
COPY . .
EOF
Sending build context to Docker daemon 2.607kB
Step 1/2 : FROM alpine
---> d4ff818577bc
Step 2/2 : COPY . .
---> aaaee43bec5e
Successfully built aaaee43bec5e
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This warning will be moved to the daemon-side, similar to how it returns
other warnings. There's work in progress to change the name of the default
profile, so we may need to backport this change to prevent existing clients
from printing an incorrect warning if they're connecting to a newer daemon.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's the only use of this function, and it's better to check that
the client actually sends the header.
This also simplifies some asserts, and makes sure that "actual" and "expected"
are in the correct order.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Golang uses a `sync.Once` when determining the proxy to use. This means
that it's not possible to test the proxy configuration in unit tests,
because the proxy configuration will be "fixated" the first time Golang
detects the proxy configuration.
This patch changes TestNewAPIClientFromFlagsWithHttpProxyEnv to an e2e
test so that we can verify the CLI picks up the proxy configuration.
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>
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.
When linting on Go 1.16:
cli/context/docker/load.go:69:6: SA1019: x509.IsEncryptedPEMBlock is deprecated: 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. (staticcheck)
if x509.IsEncryptedPEMBlock(pemBlock) {
^
cli/context/docker/load.go:70:20: SA1019: x509.DecryptPEMBlock is deprecated: 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. (staticcheck)
keyBytes, err = x509.DecryptPEMBlock(pemBlock, []byte(c.TLSPassword))
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Support for ALL_PROXY as default build-arg was added recently in
buildkit and the classic builder.
This patch adds the `ALL_PROXY` environment variable to the list of
configurable proxy variables, and updates the documentation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Errors always need to go to stderr.
This also fixes a test in moby/moby's integration-cli which is checking
to see if errors connecting to the daemon are output on stderr.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The docker info output contains both "local" and "remote" (daemon-side) information.
The API endpoint to collect daemon information (`/info`) is known to be "heavy",
and (depending on what information is needed) not needed.
This patch checks if the template (`--format`) used requires information from the
daemon, and if not, omits making an API request.
This will improve performance if (for example), the current "context" is requested
from `docker info` or if only plugin information is requested.
Before:
time docker info --format '{{range .ClientInfo.Plugins}}Plugin: {{.Name}}, {{end}}'
Plugin: buildx, Plugin: compose, Plugin: scan,
________________________________________________________
Executed in 301.91 millis fish external
usr time 168.64 millis 82.00 micros 168.56 millis
sys time 113.72 millis 811.00 micros 112.91 millis
time docker info --format '{{json .ClientInfo.Plugins}}'
time docker info --format '{{.ClientInfo.Context}}'
default
________________________________________________________
Executed in 334.38 millis fish external
usr time 177.23 millis 93.00 micros 177.13 millis
sys time 124.90 millis 927.00 micros 123.97 millis
docker context use remote-ssh-daemon
time docker info --format '{{.ClientInfo.Context}}'
remote-ssh-daemon
________________________________________________________
Executed in 1.22 secs fish external
usr time 116.93 millis 110.00 micros 116.82 millis
sys time 144.36 millis 887.00 micros 143.47 millis
And daemon logs:
Jul 06 12:42:12 remote-ssh-daemon dockerd[14377]: time="2021-07-06T12:42:12.139529947Z" level=debug msg="Calling HEAD /_ping"
Jul 06 12:42:12 remote-ssh-daemon dockerd[14377]: time="2021-07-06T12:42:12.140772052Z" level=debug msg="Calling HEAD /_ping"
Jul 06 12:42:12 remote-ssh-daemon dockerd[14377]: time="2021-07-06T12:42:12.163832016Z" level=debug msg="Calling GET /v1.41/info"
After:
time ./build/docker info --format '{{range .ClientInfo.Plugins}}Plugin: {{.Name}}, {{end}}'
Plugin: buildx, Plugin: compose, Plugin: scan,
________________________________________________________
Executed in 139.84 millis fish external
usr time 76.53 millis 62.00 micros 76.46 millis
sys time 69.25 millis 723.00 micros 68.53 millis
time ./build/docker info --format '{{.ClientInfo.Context}}'
default
________________________________________________________
Executed in 136.94 millis fish external
usr time 74.61 millis 74.00 micros 74.54 millis
sys time 65.77 millis 858.00 micros 64.91 millis
docker context use remote-ssh-daemon
time ./build/docker info --format '{{.ClientInfo.Context}}'
remote-ssh-daemon
________________________________________________________
Executed in 1.02 secs fish external
usr time 74.25 millis 76.00 micros 74.17 millis
sys time 65.09 millis 643.00 micros 64.44 millis
And daemon logs:
Jul 06 12:42:55 remote-ssh-daemon dockerd[14377]: time="2021-07-06T12:42:55.313654687Z" level=debug msg="Calling HEAD /_ping"
Jul 06 12:42:55 remote-ssh-daemon dockerd[14377]: time="2021-07-06T12:42:55.314811624Z" level=debug msg="Calling HEAD /_ping"
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 330a003533
introduced "synchronous" service update and rollback, using progress bars to show
current status for each task.
As part of that change, progress bars were "reversed" when doing a rollback, to
indicate that status was rolled back to a previous state.
Reversing direction is somewhat confusing, as progress bars now return to their
"initial" state to indicate it was "completed"; for an "automatic" rollback, this
may be somewhat clear (progress bars "move to the right", then "roll back" if the
update failed), but when doing a manual rollback, it feels counter-intuitive
(rolling back is the _expected_ outcome).
This patch removes the code to reverse the direction of progress-bars, and makes
progress-bars always move from left ("start") to right ("finished").
Before this patch
----------------------------------------
1. create a service with automatic rollback on failure
$ docker service create --update-failure-action=rollback --name foo --tty --replicas=5 nginx:alpine
9xi1w3mv5sqtyexsuh78qg0cb
overall progress: 5 out of 5 tasks
1/5: running [==================================================>]
2/5: running [==================================================>]
3/5: running [==================================================>]
4/5: running [==================================================>]
5/5: running [==================================================>]
verify: Waiting 2 seconds to verify that tasks are stable...
2. update the service, making it fail after 3 seconds
$ docker service update --entrypoint="/bin/sh -c 'sleep 3; exit 1'" foo
overall progress: rolling back update: 2 out of 5 tasks
1/5: running [==================================================>]
2/5: running [==================================================>]
3/5: starting [============================================> ]
4/5: running [==================================================>]
5/5: running [==================================================>]
3. Once the service starts failing, automatic rollback is started; progress-bars now move in the reverse direction;
overall progress: rolling back update: 3 out of 5 tasks
1/5: ready [===========> ]
2/5: ready [===========> ]
3/5: running [> ]
4/5: running [> ]
5/5: running [> ]
4. When the rollback is completed, the progressbars are at the "start" to indicate they completed;
overall progress: rolling back update: 5 out of 5 tasks
1/5: running [> ]
2/5: running [> ]
3/5: running [> ]
4/5: running [> ]
5/5: running [> ]
rollback: update rolled back due to failure or early termination of task bndiu8a998agr8s6sjlg9tnrw
verify: Service converged
After this patch
----------------------------------------
Progress bars always go from left to right; also in a rollback situation;
After updating to the "faulty" entrypoint, task are deployed:
$ docker service update --entrypoint="/bin/sh -c 'sleep 3; exit 1'" foo
foo
overall progress: 1 out of 5 tasks
1/5:
2/5: running [==================================================>]
3/5: ready [======================================> ]
4/5:
5/5:
Once tasks start failing, rollback is started, and presented the same as a regular
update; progress bars go from left to right;
overall progress: rolling back update: 3 out of 5 tasks
1/5: ready [======================================> ]
2/5: starting [============================================> ]
3/5: running [==================================================>]
4/5: running [==================================================>]
5/5: running [==================================================>]
rollback: update rolled back due to failure or early termination of task c11dxd7ud3d5pq8g45qkb4rjx
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This extends #2929 to Darwin as well as Linux.
Running the example in https://github.com/golang/go/issues/37942
I see lots of:
```
dave@m1 sigurg % uname -ms
Darwin arm64
dave@m1 sigurg % go run main.go
received urgent I/O condition: 2021-05-21 16:03:03.482211 +0100 BST m=+0.014553751
received urgent I/O condition: 2021-05-21 16:03:03.507171 +0100 BST m=+0.039514459
```
Signed-off-by: David Scott <dave@recoil.org>
The kernel memory limit is deprecated in Docker 20.10.0,
and its support was removed in runc v1.0.0-rc94.
So, this warning can be safely removed.
Relevant: b8ca7de823
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
- use var/const blocks when declaring a list of variables
- use const where possible
TestCheckKubernetesConfigurationRaiseAnErrorOnInvalidValue:
- use keys when assigning values
- make sure test is dereferenced in the loop
- use subtests
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Some tests were using domain names that were intended to be "fake", but are
actually registered domain names (such as mycorp.com).
Even though we were not actually making connections to these domains, it's
better to use domains that are designated for testing/examples in RFC2606:
https://tools.ietf.org/html/rfc2606
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
New solution is not hardcoded to amd64 but integrates
with the cross toolchain and support creating arm binaries.
Go has been updated so that ASLR works
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Relates to the deprecation, added in 3c0a167ed5
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.
This patch adds a deprecation warning, which is printed if the CLI falls back
to using the deprecated ~/.dockercfg file.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We refactorted `ForwardAllSignals` so it blocks but did not update the
call in `start` to call it in a goroutine.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Commit fff164c22e modified ForwardAllSignals to
take `SIGURG` signals into account, which can be generated by the Go runtime
on Go 1.14 and up as an interrupt to support pre-emptable system calls on Linux.
With the updated code, the signal (`s`) would sometimes be `nil`, causing spurious
(but otherwise harmless) warnings to be printed;
Unsupported signal: <nil>. Discarding.
To debug this issue, I patched v20.10.4 to handle `nil`, and added a debug line
to print the signal in all cases;
```patch
diff --git a/cli/command/container/signals.go b/cli/command/container/signals.go
index 06e4d9eb6..0cb53ef06 100644
--- a/cli/command/container/signals.go
+++ b/cli/command/container/signals.go
@@ -22,8 +22,9 @@ func ForwardAllSignals(ctx context.Context, cli command.Cli, cid string, sigc <-
case <-ctx.Done():
return
}
+ fmt.Fprintf(cli.Err(), "Signal: %v\n", s)
if s == signal.SIGCHLD || s == signal.SIGPIPE {
```
When running a cross-compiled macOS binary with Go 1.13 (`make -f docker.Makefile binary-osx`):
# regular "docker run" (note that the `<nil>` signal only happens "sometimes"):
./build/docker run --rm alpine/git clone https://github.com/docker/getting-started.git
Cloning into 'getting-started'...
Signal: <nil>
# when cancelling with CTRL-C:
./build/docker run --rm alpine/git clone https://github.com/docker/getting-started.git
^CSignal: interrupt
Cloning into 'getting-started'...
error: could not lock config file /git/getting-started/.git/config: No such file or directory
fatal: could not set 'core.repositoryformatversion' to '0'
Signal: <nil>
Signal: <nil>
When running a macOS binary built with Go 1.15 (`DISABLE_WARN_OUTSIDE_CONTAINER=1 make binary`):
# regular "docker run" (note that the `<nil>` signal only happens "sometimes"):
# this is the same as on Go 1.13
./build/docker run --rm alpine/git clone https://github.com/docker/getting-started.git
Cloning into 'getting-started'...
Signal: <nil>
# when cancelling with CTRL-C:
./build/docker run --rm alpine/git clone https://github.com/docker/getting-started.git
Cloning into 'getting-started'...
^CSignal: interrupt
Signal: urgent I/O condition
Signal: urgent I/O condition
fatal: --stdin requires a git repository
fatal: index-pack failed
Signal: <nil>
Signal: <nil>
This patch checks if the channel is closed, and removes the warning (to prevent warnings if new
signals are added that are not in our known list of signals)
We should also consider updating `notfiyAllSignals()`, which currently forwards
_all_ signals (`signal.Notify(sigc)` without passing a list of signals), and
instead pass it "all signals _minus_ the signals we don't want forwarded":
35f023a7c2/cli/command/container/signals.go (L55)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On Windows, the os/exec.{Command,CommandContext,LookPath} functions
resolve command names that have neither path separators nor file extension
(e.g., "git") by first looking in the current working directory before
looking in the PATH environment variable.
Go maintainers intended to match cmd.exe's historical behavior.
However, this is pretty much never the intended behavior and as an abundance of precaution
this patch prevents that when executing commands.
Example of commands that docker.exe may execute: `git`, `docker-buildx` (or other cli plugin), `docker-credential-wincred`, `docker`.
Note that this was prompted by the [Go 1.15.7 security fixes](https://blog.golang.org/path-security), but unlike in `go.exe`,
the windows path lookups in docker are not in a code path allowing remote code execution, thus there is no security impact on docker.
Signed-off-by: Tibor Vass <tibor@docker.com>
Prior to this change, progressbars would sometimes be hidden, and the function
would return early. In addition, the direction of the progressbars would sometimes
be "incrementing" (similar to "docker service update"), and sometimes be "decrementing"
(to indicate a "rollback" is being performed).
This fix makes sure that we always proceed with the "verifying" step, and now
prints a message _after_ the verifying stage was completed;
$ docker service rollback foo
foo
overall progress: rolling back update: 5 out of 5 tasks
1/5: running [> ]
2/5: starting [===========> ]
3/5: starting [===========> ]
4/5: running [> ]
5/5: running [> ]
verify: Service converged
rollback: rollback completed
$ docker service rollback foo
foo
overall progress: rolling back update: 1 out of 1 tasks
1/1: running [> ]
verify: Service converged
rollback: rollback completed
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Sebastiaan van Stijn
Sebastiaan van Stijn
CrazyMax
Nicolas De Loof
John Howard
Amey Shrivastava
Silvin Lubecki
Mathieu Champlon
Samuel Karp
coryb
Alex Couture-Beil
Brian Goff
David Scott
Akihiro Suda
Maximillian Fan Xavier
Tonis Tiigi
Chris Crone
Tibor Vass