thaJeztah
Repos
321
Followers
1257
Following
32

Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

64150
16744

An open and reliable container runtime

12152
2294

The Docker CLI

3642
1464

Automated nginx proxy for Docker containers using docker-gen

4
0

Automated build for pgAdmin4 Docker image

219
52

A toolkit for orchestrating distributed systems at any scale. It includes primitives for node discovery, raft-based consensus, task scheduling and more.

2876
559

Events

Merge pull request #3795 from thaJeztah/ignore_stubs_in_aliases

fix broken alias check is buildx is installed as alias for builder

cli-plugins/manager: add IsPluginCommand(() utility

This makes it more convenient to check if a command is a plugin-stub

Signed-off-by: Sebastiaan van Stijn github@gone.nl

Created at 5 hours ago
push

fix broken alias check is buildx is installed as alias for builder

Commit cbec75e2f3f5afd3334db693829a6b150612076c updated runDocker() to load plugin-stubs before processAliases() was executed. As a result, plugin stubs were considered as "builtin commands", causing the alias verification to fail;

Without alias installed:

docker version
Client:
 Version:           22.06.0-beta.0-140-g3dad26ca2.m
 API version:       1.42
 Go version:        go1.19.1
 Git commit:        3dad26ca2
 Built:             Wed Sep 28 22:36:09 2022
 OS/Arch:           darwin/arm64
 Context:           default
...

After running docker buildx install;

./build/docker buildx install

cat ~/.docker/config.json
{
    "aliases": {
        "builder": "buildx"
    }
}

./build/docker version
not allowed to alias with builtin "buildx" as target

This patch moves loading the stubs after the call to processAliases(), so that verification passes. As an extra precaution, the processAliases() function is also updated to exclude plugin-stub commands.

Note that cbec75e2f3f5afd3334db693829a6b150612076c also introduced a performance regression, which may be related to the early loading of plugins (and creating stubs); it looks like various other code locations may also be loading plugins, for example tryPluginRun() calls pluginmanager.PluginRunCommand(), which also traverses plugin directories.

We should look under what circumstances the plugin stub-commands are actually needed, and make sure that they're only created in those situations.

Signed-off-by: Sebastiaan van Stijn github@gone.nl

Merge pull request #3795 from thaJeztah/ignore_stubs_in_aliases

fix broken alias check is buildx is installed as alias for builder

Created at 5 hours ago
delete branch
thaJeztah delete branch ignore_stubs_in_aliases
Created at 5 hours ago
closed issue
[master / 22.06] docker buildx install breaks alias check

Description

Not sure when this broke (did not yet do a bisect), but I noticed that if the ~/.docker/config.json contains an alias for builder (which happens after running docker buildx install), the CLI is broken;

docker version
not allowed to alias with builtin "buildx" as target

Reproduce

make -f docker.Makefile binary

Without alias installed:

rm ~/.docker/config.json
./build/docker version
Client:
 Version:           22.06.0-beta.0-140-g3dad26ca2.m
 API version:       1.42
 Go version:        go1.19.1
 Git commit:        3dad26ca2
 Built:             Wed Sep 28 22:36:09 2022
 OS/Arch:           darwin/arm64
 Context:           default
...

After running docker buildx install;

./build/docker buildx install

cat ~/.docker/config.json
{
	"auths": {},
	"aliases": {
		"builder": "buildx"
	}
}

./build/docker version
not allowed to alias with builtin "buildx" as target

The error occurs in this part of the code inside processAliases(); https://github.com/docker/cli/blob/c780f7c4abaf67034ecfaa0611e03695cf9e4a3e/cmd/docker/aliases.go#L29-L31

Because the cmd.Find("buildx")) returns a cmd. From a quick test the cmd it finds may be the "stub" command we create for plugins; when disabling the buildx plugin (renaming the file), the problem goes away;

mv /usr/local/lib/docker/cli-plugins/docker-buildx /usr/local/lib/docker/cli-plugins/docker-buildx-disabled
 
./build/docker version
Client:
 Version:           22.06.0-beta.0-140-g3dad26ca2.m
 API version:       1.42
 Go version:        go1.19.1
 Git commit:        3dad26ca2
 Built:             Wed Sep 28 22:36:09 2022
 OS/Arch:           darwin/arm64
 Context:           default
...

Expected behavior

No response

docker version

current master (built from https://github.com/docker/cli/commit/3dad26ca2d418092b8c4e01b03d0455d583bec86)

Client:
 Version:           22.06.0-beta.0-140-g3dad26ca2.m
 API version:       1.42
 Go version:        go1.19.1
 Git commit:        3dad26ca2
 Built:             Wed Sep 28 22:36:09 2022
 OS/Arch:           darwin/arm64
 Context:           default

docker info

not relevant

Additional Info

No response

Created at 5 hours ago
pull request closed
fix broken alias check is buildx is installed as alias for builder
  • fixes https://github.com/docker/cli/issues/3789
  • relates to https://github.com/docker/cli/pull/3429
  • relates to https://github.com/docker/cli/issues/3621

Commit cbec75e2f3f5afd3334db693829a6b150612076c (https://github.com/docker/cli/pull/3429) updated runDocker() to load plugin-stubs before processAliases() was executed. As a result, plugin stubs were considered as "builtin commands", causing the alias verification to fail;

Without alias installed:

docker version
Client:
 Version:           22.06.0-beta.0-140-g3dad26ca2.m
 API version:       1.42
 Go version:        go1.19.1
 Git commit:        3dad26ca2
 Built:             Wed Sep 28 22:36:09 2022
 OS/Arch:           darwin/arm64
 Context:           default
...

After running docker buildx install;

./build/docker buildx install

cat ~/.docker/config.json
{
    "aliases": {
        "builder": "buildx"
    }
}

./build/docker version
not allowed to alias with builtin "buildx" as target

This patch moves loading the stubs after the call to processAliases(), so that verification passes. As an extra precaution, the processAliases() function is also updated to exclude plugin-stub commands.

Note that cbec75e2f3f5afd3334db693829a6b150612076c (https://github.com/docker/cli/pull/3429) also introduced a performance regression (https://github.com/docker/cli/issues/3621), which may be related to the early loading of plugins (and creating stubs); it looks like various other code locations may also be loading plugins, for example tryPluginRun() calls pluginmanager.PluginRunCommand(), which also traverses plugin directories.

We should look under what circumstances the plugin stub-commands are actually needed, and make sure that they're only created in those situations.

- A picture of a cute animal (not mandatory but encouraged)

Created at 5 hours ago
issue comment
fix broken alias check is buildx is installed as alias for builder

thx; let me bring this one in 👍

Created at 5 hours ago
issue comment
build fails on buildkit '#syntax' directive in Fedora guest (mount /tmp/buildkit-metadata1419535027:/run/config/buildkit/metadata (via /proc/self/fd/6), flags: 0x1021: operation not permitted) #1401

What version of runc do you have installed? I recall there were some fixes around mounts in runc v1.1.4 (not sure if relevant).

Created at 5 hours ago
pull request opened
cli-plugins/manager: add IsPluginCommand(() utility
  • follow-up to https://github.com/docker/cli/pull/3795

This makes it more convenient to check if a command is a plugin-stub

- A picture of a cute animal (not mandatory but encouraged)

Created at 8 hours ago
create branch
thaJeztah create branch add_is_plugincommand_utility
Created at 8 hours ago

fix broken alias check is buildx is installed as alias for builder

Commit cbec75e2f3f5afd3334db693829a6b150612076c updated runDocker() to load plugin-stubs before processAliases() was executed. As a result, plugin stubs were considered as "builtin commands", causing the alias verification to fail;

Without alias installed:

docker version
Client:
 Version:           22.06.0-beta.0-140-g3dad26ca2.m
 API version:       1.42
 Go version:        go1.19.1
 Git commit:        3dad26ca2
 Built:             Wed Sep 28 22:36:09 2022
 OS/Arch:           darwin/arm64
 Context:           default
...

After running docker buildx install;

./build/docker buildx install

cat ~/.docker/config.json
{
    "aliases": {
        "builder": "buildx"
    }
}

./build/docker version
not allowed to alias with builtin "buildx" as target

This patch moves loading the stubs after the call to processAliases(), so that verification passes. As an extra precaution, the processAliases() function is also updated to exclude plugin-stub commands.

Note that cbec75e2f3f5afd3334db693829a6b150612076c also introduced a performance regression, which may be related to the early loading of plugins (and creating stubs); it looks like various other code locations may also be loading plugins, for example tryPluginRun() calls pluginmanager.PluginRunCommand(), which also traverses plugin directories.

We should look under what circumstances the plugin stub-commands are actually needed, and make sure that they're only created in those situations.

Signed-off-by: Sebastiaan van Stijn github@gone.nl

Created at 8 hours ago
issue comment
[master / 22.06] docker buildx install breaks alias check

opened https://github.com/docker/cli/pull/3795 with the "easy" fix

Created at 8 hours ago
pull request opened
fix broken alias check is buildx is installed as alias for builder
  • fixes https://github.com/docker/cli/issues/3789
  • relates to https://github.com/docker/cli/pull/3429
  • relates to https://github.com/docker/cli/issues/3621

Commit cbec75e2f3f5afd3334db693829a6b150612076c (https://github.com/docker/cli/pull/3429) updated runDocker() to load plugin-stubs before processAliases() was executed. As a result, plugin stubs were considered as "builtin commands", causing the alias verification to fail;

Without alias installed:

docker version
Client:
 Version:           22.06.0-beta.0-140-g3dad26ca2.m
 API version:       1.42
 Go version:        go1.19.1
 Git commit:        3dad26ca2
 Built:             Wed Sep 28 22:36:09 2022
 OS/Arch:           darwin/arm64
 Context:           default
...

After running docker buildx install;

./build/docker buildx install

cat ~/.docker/config.json
{
    "aliases": {
        "builder": "buildx"
    }
}

./build/docker version
not allowed to alias with builtin "buildx" as target

This patch moves loading the stubs after the call to processAliases(), so that verification passes. As an extra precaution, the processAliases() function is also updated to exclude plugin-stub commands.

Note that cbec75e2f3f5afd3334db693829a6b150612076c (https://github.com/docker/cli/pull/3429) also introduced a performance regression (https://github.com/docker/cli/issues/3621), which may be related to the early loading of plugins (and creating stubs); it looks like various other code locations may also be loading plugins, for example tryPluginRun() calls pluginmanager.PluginRunCommand(), which also traverses plugin directories.

We should look under what circumstances the plugin stub-commands are actually needed, and make sure that they're only created in those situations.

- A picture of a cute animal (not mandatory but encouraged)

Created at 8 hours ago
create branch
thaJeztah create branch ignore_stubs_in_aliases
Created at 8 hours ago
pull request opened
format code with gofumpt
  • follow-up to https://github.com/docker/cli/pull/3790
Created at 9 hours ago
create branch
thaJeztah create branch use_gofumpt
Created at 9 hours ago
push

docker-rootless-setuptools.sh: use context after install

Signed-off-by: Mathieu PATUREL mathieu.paturel@gmail.com (cherry picked from commit 7c17ad873596de0c9fe7e09f28d229b482386f13) Signed-off-by: Sebastiaan van Stijn github@gone.nl

contrib: make dockerd-rootless-setuptool.sh more robust

The docker CLI currently doesn't handle situations where the current context (as defined in ~/.docker/config.json) is invalid or doesn't exist. As loading (and checking) the context happens during initialization of the CLI, this prevents docker context commands from being used, which makes it complicated to fix the situation. For example, running docker context use <correct context> would fail, which makes it not possible to update the ~/.docker/config.json, unless doing so manually.

For example, given the following ~/.docker/config.json:

{
        "currentContext": "nosuchcontext"
}

All of the commands below fail:

docker context inspect rootless
Current context "nosuchcontext" is not found on the file system, please check your config file at /Users/thajeztah/.docker/config.json

docker context rm --force rootless
Current context "nosuchcontext" is not found on the file system, please check your config file at /Users/thajeztah/.docker/config.json

docker context use default
Current context "nosuchcontext" is not found on the file system, please check your config file at /Users/thajeztah/.docker/config.json

While these things should be fixed, this patch updates the script to switch the context using the --context flag; this flag is taken into account when initializing the CLI, so that having an invalid context configured won't block docker context commands from being executed. Given that all context commands are local operations, "any" context can be used (it doesn't need to make a connection with the daemon).

With this patch, those commands can now be run (and won't fail for the wrong reason);

 docker --context=default context inspect -f "{{.Name}}" rootless
rootless

docker --context=default context inspect -f "{{.Name}}" rootless-doesnt-exist
context "rootless-doesnt-exist" does not exist

One other issue may also cause things to fail during uninstall; trying to remove a context that doesn't exist will fail (even with the -f / --force option set);

docker --context=default context rm blablabla
Error: context "blablabla": not found

While this is "ok" in most circumstances, it also means that (potentially) the current context is not reset to "default", so this patch adds an explicit docker context use, as well as unsetting the DOCKER_HOST and DOCKER_CONTEXT environment variables.

Signed-off-by: Sebastiaan van Stijn github@gone.nl (cherry picked from commit e2114731e729043a5897ebc741b33544e4c30ca4) Signed-off-by: Sebastiaan van Stijn github@gone.nl

Merge pull request #44218 from thaJeztah/20.10_backport_more_robust_rootless

[20.10 backport] docker-rootless-setuptools.sh fixes

Created at 9 hours ago
delete branch
thaJeztah delete branch 20.10_backport_more_robust_rootless
Created at 9 hours ago
pull request closed
[20.10 backport] docker-rootless-setuptools.sh fixes
  • backport of https://github.com/moby/moby/pull/43061
  • backport of https://github.com/moby/moby/pull/44213
  • relates to https://github.com/docker/docker.github.io/pull/14727
  • fixes https://github.com/moby/moby/issues/43020

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

Created at 9 hours ago
issue comment
[master / 22.06] docker buildx install breaks alias check

I have an easy fix for this, but I think it's a partial fix (looking at better fixes that may also help with the performance regression)

Might push the "easy fix" first and fix the rest later

Created at 11 hours ago
delete branch
thaJeztah delete branch multi_arch
Created at 13 hours ago
pull request closed
make image multi-arch

so that I can run it on my m1

Created at 13 hours ago

make image multi-arch

Signed-off-by: Sebastiaan van Stijn github@gone.nl

Merge pull request #1 from thaJeztah/multi_arch

make image multi-arch

Created at 13 hours ago
pull request opened
make image multi-arch

so that I can run it on my m1

Created at 13 hours ago
create branch
thaJeztah create branch multi_arch
Created at 13 hours ago

cli/compose: remove redundant reflection from tests

Signed-off-by: Sebastiaan van Stijn github@gone.nl

Merge pull request #3792 from thaJeztah/compose_tests

cli/compose: remove redundant reflection from tests

Created at 14 hours ago
push

contrib: make dockerd-rootless-setuptool.sh more robust

The docker CLI currently doesn't handle situations where the current context (as defined in ~/.docker/config.json) is invalid or doesn't exist. As loading (and checking) the context happens during initialization of the CLI, this prevents docker context commands from being used, which makes it complicated to fix the situation. For example, running docker context use <correct context> would fail, which makes it not possible to update the ~/.docker/config.json, unless doing so manually.

For example, given the following ~/.docker/config.json:

{
        "currentContext": "nosuchcontext"
}

All of the commands below fail:

docker context inspect rootless
Current context "nosuchcontext" is not found on the file system, please check your config file at /Users/thajeztah/.docker/config.json

docker context rm --force rootless
Current context "nosuchcontext" is not found on the file system, please check your config file at /Users/thajeztah/.docker/config.json

docker context use default
Current context "nosuchcontext" is not found on the file system, please check your config file at /Users/thajeztah/.docker/config.json

While these things should be fixed, this patch updates the script to switch the context using the --context flag; this flag is taken into account when initializing the CLI, so that having an invalid context configured won't block docker context commands from being executed. Given that all context commands are local operations, "any" context can be used (it doesn't need to make a connection with the daemon).

With this patch, those commands can now be run (and won't fail for the wrong reason);

 docker --context=default context inspect -f "{{.Name}}" rootless
rootless

docker --context=default context inspect -f "{{.Name}}" rootless-doesnt-exist
context "rootless-doesnt-exist" does not exist

One other issue may also cause things to fail during uninstall; trying to remove a context that doesn't exist will fail (even with the -f / --force option set);

docker --context=default context rm blablabla
Error: context "blablabla": not found

While this is "ok" in most circumstances, it also means that (potentially) the current context is not reset to "default", so this patch adds an explicit docker context use, as well as unsetting the DOCKER_HOST and DOCKER_CONTEXT environment variables.

Signed-off-by: Sebastiaan van Stijn github@gone.nl (cherry picked from commit e2114731e729043a5897ebc741b33544e4c30ca4) Signed-off-by: Sebastiaan van Stijn github@gone.nl

Merge pull request #44217 from thaJeztah/22.06_backport_more_robust_rootless

[22.06 backport] contrib: make dockerd-rootless-setuptool.sh more robust

Created at 14 hours ago
delete branch
thaJeztah delete branch 22.06_backport_more_robust_rootless
Created at 14 hours ago
pull request closed
[22.06 backport] contrib: make dockerd-rootless-setuptool.sh more robust
  • backport of https://github.com/moby/moby/pull/44213
  • relates to https://github.com/docker/docker.github.io/pull/14727

The docker CLI currently doesn't handle situations where the current context (as defined in ~/.docker/config.json) is invalid or doesn't exist. As loading (and checking) the context happens during initialization of the CLI, this prevents docker context commands from being used, which makes it complicated to fix the situation. For example, running docker context use <correct context> would fail, which makes it not possible to update the ~/.docker/config.json, unless doing so manually.

For example, given the following ~/.docker/config.json:

{
        "currentContext": "nosuchcontext"
}

All of the commands below fail:

docker context inspect rootless
Current context "nosuchcontext" is not found on the file system, please check your config file at /Users/thajeztah/.docker/config.json

docker context rm --force rootless
Current context "nosuchcontext" is not found on the file system, please check your config file at /Users/thajeztah/.docker/config.json

docker context use default
Current context "nosuchcontext" is not found on the file system, please check your config file at /Users/thajeztah/.docker/config.json

While these things should be fixed, this patch updates the script to switch the context using the --context flag; this flag is taken into account when initializing the CLI, so that having an invalid context configured won't block docker context commands from being executed. Given that all context commands are local operations, "any" context can be used (it doesn't need to make a connection with the daemon).

With this patch, those commands can now be run (and won't fail for the wrong reason);

 docker --context=default context inspect -f "{{.Name}}" rootless
rootless

docker --context=default context inspect -f "{{.Name}}" rootless-doesnt-exist
context "rootless-doesnt-exist" does not exist

One other issue may also cause things to fail during uninstall; trying to remove a context that doesn't exist will fail (even with the -f / --force option set);

docker --context=default context rm blablabla
Error: context "blablabla": not found

While this is "ok" in most circumstances, it also means that (potentially) the current context is not reset to "default", so this patch adds an explicit docker context use, as well as unsetting the DOCKER_HOST and DOCKER_CONTEXT environment variables.

Signed-off-by: Sebastiaan van Stijn github@gone.nl (cherry picked from commit e2114731e729043a5897ebc741b33544e4c30ca4) Signed-off-by: Sebastiaan van Stijn github@gone.nl

- What I did

- How I did it

- How to verify it

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

Created at 14 hours ago