vendor: github.com/moby/moby/api v1.52.0, moby/client v0.1.0

[thaJeztah]

• depends on Create github.com/moby/moby/api and github.com/moby/moby/client module moby/moby#50280
• depends on vendor: github.com/docker/docker master (v29.0-dev) cli#6193
• depends on vendor github.com/spf13/pflag v1.0.10, github.com/spf13/cobra v1.10.1 #3429

[crazy-max]

Looks like we keep this module only for the namesgenerator package:

buildx/store/util.go

Line 8 in c1fbb49

"github.com/docker/docker/pkg/namesgenerator"

Seems it has moved to an internal package since v29: https://github.com/moby/moby/tree/master/internal/namesgenerator which relates to this opened PR #3354

@thaJeztah I wonder if this package could be moved to client/pkg like you have done for pkg/stringid in moby/moby#50504 so we avoid multiple implementation and fragmentation across projects?

[thaJeztah]

I wonder if this package could be moved to client/pkg like you have done for pkg/stringid in moby/moby#50504 so we avoid multiple implementation and fragmentation across projects?

No, this package was never meant to be used by any client; it's a fallback for the daemon if a name is omitted. There's been various conversations to consider removing it entirely (possibly using plain GUIDs or PERHAPS adding an option for users to provide a prefix, which could work for buildx)

I think we should look if buildx needs to generate a name at all, but if it does, I think it should actually use its own naming scheme instead of the same scheme as the docker daemon uses for generated names; I think the current approach is to some extend even more confusing, because these names don't directly correlate with container names, only builder names;

If I see it correctly, the current approach is for buildx to generate a name, and as part of that check if there's no builders that have that name;

docker buildx create
charming_nash

However, it (by default) does not create an actual container at that point, it only defines a builder "template" for container(s) to be created, but it does show an "inactive" instance;

docker buildx ls
NAME/NODE            DRIVER/ENDPOINT     STATUS     BUILDKIT   PLATFORMS
charming_nash        docker-container
 \_ charming_nash0    \_ desktop-linux   inactive
...

But that instance doesn't exist yet, so .. it's not really "inactive"; it doesn't exist yet;

docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

This part is already slightly confusing, because it shows the name of a builder instance that doesn't exist (and buildx doesn't allow picking an instance, or is that the --builder option on docker buildx use?);

docker buildx use charming_nash0
ERROR: failed to find instance "charming_nash0": open /Users/thajeztah/.docker/buildx/instances/charming_nash0: no such file or directory

Using the builder;

docker buildx use --builder charming_nash0 charming_nash

or is that the --builder option on docker buildx use?

Setting the --builder option doesn't show the charming_nash0 to be the one I picked, so .. maybe not?

docker buildx ls
NAME/NODE            DRIVER/ENDPOINT     STATUS     BUILDKIT   PLATFORMS
charming_nash*       docker-container
 \_ charming_nash0    \_ desktop-linux   inactive
...

No container created up until this point;

docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

When building, the container is bootstrapped;

echo 'FROM alpine' | docker buildx build --quiet -
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load

And now a container IS created, but it doesn't use the naming scheme as-is, but an additional prefix;

docker ps -a
CONTAINER ID   IMAGE                           COMMAND                  CREATED          STATUS          PORTS     NAMES
e816a30f4fc8   moby/buildkit:buildx-stable-1   "buildkitd --allow-i…"   21 seconds ago   Up 21 seconds             buildx_buildkit_charming_nash0

This also means that there's a TOCTOU issue here as well; with these names being predictable, I can create a container with the expected to be used name;

docker buildx create
lucid_hypatia

docker run -d --name buildx_buildkit_lucid_hypatia0 nginx:alpine
37084e0cf8c4cdf5272699274db4fe2b8d1e3ff76796c99f544f8a3240e8e51e

docker buildx use --builder lucid_hypatia0 lucid_hypatia

docker buildx ls
NAME/NODE            DRIVER/ENDPOINT     STATUS    BUILDKIT   PLATFORMS
lucid_hypatia*       docker-container
 \_ lucid_hypatia0    \_ desktop-linux   error
...
Failed to get status for lucid_hypatia (lucid_hypatia0): listing workers: failed to list workers: Unavailable: connection error: desc = "error reading server preface: http2: frame too large"


echo 'FROM alpine' | docker buildx build --quiet -
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
ERROR: failed to build: listing workers for Build: failed to list workers: Unavailable: connection error: desc = "error reading server preface: http2: frame too large"

Based on the above;

• The names-generator (which was designed for the daemon to generate container names) is used by buildx for builder names
• ☝️ normally this generator would be used by the daemon if no container-name was provided, so that it can generate a name on the daemon side (and make sure there's no conflicts)
• 👉 but for buildx, a name is reserved client side ahead of time (with the expectation that the name will be available the moment it will create one)
• ❓ should it? Or should docker buildx ls show that no instances exist (yet)?
• ☝️ at the time it does create a container, it uses its own naming scheme (using the buildx_buildkit_ prefix, and a <number> suffix)

Some possible alternatives;

Use labels and/or annotations instead of depending on the name.

I think in general, the reason for these names are for buildx to be able to correlate containers with its builders. This is similar to docker compose, which also needs to do this, and historically used the container name for this purpose. Instead of using the name, buildx can use labels or annotations (although we currently lack many options for filtering on annotations).

The intent for these containers is to be managed by buildx, and not manually by the user, so for users, the name shouldn't really matter; ideally we should even put these in their own (containerd) namespace, so that they don't show up among user-created containers, but we don't currently expose containerd namespaces (which we should work on).

For fun, I checked what would happen with a container that happened to be named following buildx's naming scheme, and it looks like 💥 buildx happily removes my container;

docker buildx create
silly_chatelet

docker run -d --name buildx_buildkit_silly_chatelet0 nginx:alpine
90290ff3b5c85ed2724769384facc628b46404c36e246e8f26dd3b1d10fe4f03

docker ps
CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS     NAMES
90290ff3b5c8   nginx:alpine   "/docker-entrypoint.…"   13 seconds ago   Up 12 seconds   80/tcp    buildx_buildkit_silly_chatelet0

docker buildx rm silly_chatelet
silly_chatelet removed

docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

Using labels and/or annotations to identify if a container is a container managed by / created by buildx would also avoid the above.

Alternative ideas

docker buildx create without a name could base the name of the builder on the context used for it; this could even mean showing instances underneath the context, so instead of this;

docker buildx ls
NAME/NODE              DRIVER/ENDPOINT     STATUS     BUILDKIT   PLATFORMS
lucid_hypatia*         docker-container
 \_ lucid_hypatia0      \_ desktop-linux   error
silly_chatelet         docker-container
 \_ silly_chatelet0     \_ desktop-linux   inactive
strange_bardeen        docker-container
 \_ strange_bardeen0    \_ desktop-linux   inactive
default                docker
 \_ default             \_ default         running    v0.25.1    linux/amd64 (+2), linux/arm64, linux/ppc64le, linux/s390x, (2 more)
desktop-linux          docker
 \_ desktop-linux       \_ desktop-linux   running    v0.25.1    linux/amd64 (+2), linux/arm64, linux/ppc64le, linux/s390x, (2 more)

We may have something like this (just a really quick write-up without giving it much thought);

docker buildx ls
CONTEXT/INSTANCE       DRIVER             STATUS     BUILDKIT   PLATFORMS
desktop-linux *         
 \_ desktop-linux      docker             running    v0.25.1    linux/amd64 (+2), linux/arm64, linux/ppc64le, linux/s390x, (2 more)
 \_ desktop-linux0     docker-container   error
 \_ desktop-linux1     docker-container   inactive

I'm not 100% sure what the exact use-cases are for multiple builders per context; I could see this being to namespace builds, but (see my earlier comment), perhaps that's something we should look into in a wider scope to namespace objects (containers, volumes, builders, networks).