buildx
buildx copied to clipboard
docker
ls: add format, quiet and no-trunc opts
Fixes #325 Fixes #380 Fixes #764
Adds filter, format and no-trunc options for ls command:
$ docker buildx ls
NAME/NODE DRIVER/ENDPOINT STATUS BUILDKIT PLATFORMS
builder docker-container
\_ builder0 \_ unix:///var/run/docker.sock running 7615120 linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le,…
\_ mac-mini-m1 \_ tcp://mac-mini-m1.home.foo.com:2376 stopped linux/arm64*
builder2* docker-container
\_ builder20 \_ unix:///var/run/docker.sock running 7615120 linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le,…
remote-builder remote
\_ remote-builder0 \_ docker-container://buildx_buildkit_dk-remote-builder0 inactive
\_ aws_graviton2 \_ tcp://10.0.0.1:1234 running darwin/arm64*, linux/arm64*, linux/arm/v5*, linux/arm/v6*, linux/arm/v7*, windows/arm64*
\_ linuxone_s390x \_ tcp://10.0.0.2:1234 running linux/s390x*
default docker
\_ default \_ default running 20.10.21 linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386,…
desktop-linux docker
\_ desktop-linux \_ desktop-linux error
desktop-windows docker
\_ desktop-windows \_ desktop-windows error
docker1903 docker
\_ docker1903 \_ docker1903 running 19.03.15 linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386,…
docker2010 docker
\_ docker2010 \_ docker2010 running 20.10.21 linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386,…
Failed to get status for desktop-linux (desktop-linux): protocol not available
Failed to get status for desktop-windows (desktop-windows): protocol not available
$ docker buildx ls --no-trunc
NAME/NODE DRIVER/ENDPOINT STATUS BUILDKIT PLATFORMS
builder docker-container
\_ builder0 \_ unix:///var/run/docker.sock running 7615120 linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
\_ mac-mini-m1 \_ tcp://mac-mini-m1.home.foo.com:2376 stopped linux/arm64*
builder2* docker-container
\_ builder20 \_ unix:///var/run/docker.sock running 7615120 linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
remote-builder remote
\_ remote-builder0 \_ docker-container://buildx_buildkit_dk-remote-builder0 inactive
\_ aws_graviton2 \_ tcp://10.0.0.1:1234 running darwin/arm64*, linux/arm64*, linux/arm/v5*, linux/arm/v6*, linux/arm/v7*, windows/arm64*
\_ linuxone_s390x \_ tcp://10.0.0.2:1234 running linux/s390x*
default docker
\_ default \_ default running 20.10.21 linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
desktop-linux docker
\_ desktop-linux \_ desktop-linux error
desktop-windows docker
\_ desktop-windows \_ desktop-windows error
docker1903 docker
\_ docker1903 \_ docker1903 running 19.03.15 linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
docker2010 docker
\_ docker2010 \_ docker2010 running 20.10.21 linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
Failed to get status for desktop-linux (desktop-linux): protocol not available
Failed to get status for desktop-windows (desktop-windows): protocol not available
$ docker buildx ls --quiet
builder
builder2
remote-builder
default
desktop-linux
desktop-windows
docker1903
docker2010
$ docker buildx ls --format json
{"Name":"builder","Driver":"docker-container","Dynamic":false,"Nodes":[{"Name":"builder0","Endpoint":"unix:///var/run/docker.sock","Platforms":["linux/amd64","linux/amd64/v2","linux/amd64/v3","linux/arm64","linux/riscv64","linux/ppc64le","linux/s390x","linux/386","linux/mips64le","linux/mips64","linux/arm/v7","linux/arm/v6"],"Flags":["--debug","--allow-insecure-entitlement","security.insecure","--allow-insecure-entitlement","network.host"],"DriverOpts":{"env.BUILDKIT_STEP_LOG_MAX_SIZE":"10485760","env.BUILDKIT_STEP_LOG_MAX_SPEED":"10485760","env.JAEGER_TRACE":"localhost:6831","image":"moby/buildkit:master","network":"host"},"Status":"running","Version":"7615120"},{"Name":"mac-mini-m1","Endpoint":"tcp://mac-mini-m1.home.foo.com:2376","DriverOpts":{"image":"moby/buildkit:master"},"Status":"stopped"}]}
{"Name":"builder2","Driver":"docker-container","Dynamic":false,"Nodes":[{"Name":"builder20","Endpoint":"unix:///var/run/docker.sock","Platforms":["linux/amd64","linux/amd64/v2","linux/amd64/v3","linux/arm64","linux/riscv64","linux/ppc64le","linux/s390x","linux/386","linux/mips64le","linux/mips64","linux/arm/v7","linux/arm/v6"],"Flags":["--debug","--allow-insecure-entitlement","security.insecure","--allow-insecure-entitlement","network.host"],"DriverOpts":{"env.BUILDKIT_STEP_LOG_MAX_SIZE":"10485760","env.BUILDKIT_STEP_LOG_MAX_SPEED":"10485760","env.JAEGER_TRACE":"localhost:6831","image":"moby/buildkit:master","network":"host"},"Status":"running","Version":"7615120"}]}
{"Name":"remote-builder","Driver":"remote","Dynamic":false,"Nodes":[{"Name":"remote-builder0","Endpoint":"docker-container://buildx_buildkit_dk-remote-builder0","Status":"inactive"},{"Name":"aws_graviton2","Endpoint":"tcp://10.0.0.2:1234","Platforms":["linux/arm64","linux/arm/v7","linux/arm/v6"],"DriverOpts":{"cacert":"/home/crazy/.certs/aws_graviton2/ca.pem","cert":"/home/crazy/.certs/aws_graviton2/cert.pem","key":"/home/crazy/.certs/aws_graviton2/key.pem"},"Status":"running"},{"Name":"linuxone_s390x","Endpoint":"tcp://10.0.0.1:1234","Platforms":["linux/s390x"],"DriverOpts":{"cacert":"/home/crazy/.certs/linuxone_s390x/ca.pem","cert":"/home/crazy/.certs/linuxone_s390x/cert.pem","key":"/home/crazy/.certs/linuxone_s390x/key.pem"},"Status":"running"}]}
{"Name":"default","Driver":"docker","Dynamic":false,"Nodes":[{"Name":"default","Endpoint":"default","Platforms":["linux/amd64","linux/arm64","linux/riscv64","linux/ppc64le","linux/s390x","linux/386","linux/arm/v7","linux/arm/v6"],"Status":"running","Version":"20.10.21"}]}
{"Name":"desktop-linux","Driver":"docker","Dynamic":false,"Nodes":[{"Name":"desktop-linux","Endpoint":"desktop-linux","Status":"error","Err":"protocol not available"}]}
{"Name":"desktop-windows","Driver":"docker","Dynamic":false,"Nodes":[{"Name":"desktop-windows","Endpoint":"desktop-windows","Status":"error","Err":"protocol not available"}]}
{"Name":"docker1903","Driver":"docker","Dynamic":false,"Nodes":[{"Name":"docker1903","Endpoint":"docker1903","Platforms":["linux/amd64","linux/arm64","linux/riscv64","linux/ppc64le","linux/s390x","linux/386","linux/arm/v7","linux/arm/v6"],"Status":"running","Version":"19.03.15"}]}
{"Name":"docker2010","Driver":"docker","Dynamic":false,"Nodes":[{"Name":"docker2010","Endpoint":"docker2010","Platforms":["linux/amd64","linux/arm64","linux/riscv64","linux/ppc64le","linux/s390x","linux/386","linux/arm/v7","linux/arm/v6"],"Status":"running","Version":"20.10.21"}]}
$ docker buildx ls --format raw
name: builder
driver: docker-container
nodes:
name: builder0
endpoint: unix:///var/run/docker.sock
status: running
buildkit: v0.10.6
platforms: linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
name: mac-mini-m1
endpoint: tcp://mac-mini-m1.home.foo.com:2376
status: running
buildkit: v0.10.6
platforms: linux/arm64*, linux/amd64, linux/amd64/v2, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
name: builder2*
driver: docker-container
nodes:
name: builder20
endpoint: unix:///var/run/docker.sock
status: running
buildkit: v0.10.6
platforms: linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
name: remote-builder
driver: remote
nodes:
name: remote-builder0
endpoint: docker-container://buildx_buildkit_dk-remote-builder0
status: inactive
name: aws_graviton2
endpoint: tcp://10.0.0.1:1234
status: running
platforms: darwin/arm64*, linux/arm64*, linux/arm/v5*, linux/arm/v6*, linux/arm/v7*, windows/arm64*
name: linuxone_s390x
endpoint: tcp://10.0.0.2:1234
status: running
platforms: linux/s390x*
name: default
driver: docker
nodes:
name: default
endpoint: default
status: running
buildkit: 20.10.21
platforms: linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
name: desktop-linux
error: protocol not available
name: desktop-windows
error: protocol not available
name: docker1903
driver: docker
nodes:
name: docker1903
endpoint: docker1903
status: running
buildkit: 19.03.15
platforms: linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
name: docker2010
driver: docker
nodes:
name: docker2010
endpoint: docker2010
status: running
buildkit: 20.10.21
platforms: linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
I'll try to have a closer look, but some quick thoughts
For the table format (default), errors are now displayed below the table to avoid a messy output as suggested by @thaJeztah in #764.
Hm.. yes, so I suggested that indeed. I think my initial thought there was that the problem in the current output was that the error message took the place of the STATUS column, so the STATUS columnn either had a "known" status, or contained an error message; the WARN[0020] commandConn.CloseWrite: commandconn: failed to wait: signal: killed lines definitely felt out of place though.
Looking at your example output, I'm now wondering if (instead) it would make sense to add an ERROR column; this would still allop the error to be grouped with the builder, but the STATUS column to show more useful information.
Similar to docker stack ps;
docker service create --name foobar nginx:alpine
docker service ps foobar
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
a9b0sgzs04ej foobar.1 nginx:alpine docker-desktop Running Running 11 seconds ago
docker service create --name failing --detach busybox sh -c 'sleep 2; exit 1'
docker service ps failing
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
jskpciju2hpw failing.1 busybox:latest docker-desktop Ready Ready 1 second ago
mfl1c0dr88wf \_ failing.1 busybox:latest docker-desktop Shutdown Failed 1 second ago "task: non-zero exit (1)"
wmg9tn7w6btk \_ failing.1 busybox:latest docker-desktop Shutdown Failed 9 seconds ago "task: non-zero exit (1)"
I think docker stack ps by default truncates output (to keep a shorter line length), so to view the full error message, the --no-trunc option may be needed in some cases.
A progress output has also been added but we could hide it if you prefer.
Yes, I'm a bit on the fence on that one. That said, "it's tricky" docker service ps is of course handled server-side, which allows it to keep state, and present the current results without delay, whereas docker buildx ls will have to connect to all builders every time it's called.
Something "in between" would be to have a way to stay "attached" (like docker stats); print all builders, and refresh their status once we get those results, but that may feel a bit foreign as well (compared to other ps / ls commands).
Overall, I'm wondering if we could find some middle-ground where docker buildx ls / docker builder ls would provide a quick overview of the builders that are defined (perhaps skipping actually checking status), as currently a single offline builder blocks / slows down the output, which makes it quite cumbersome to use.
I'm also looking if we can format the output more so that the "essential" information can be presented as "one row per builder", instead of the staggered (multiple lines per builder) output, which makes it hard to see "at a glance" what nodes I have, and to find the information.
Currently we have;
NameNodeDriverEndpointStatusPlatforms- (
Error)
Of those;
Name,Driver, and (possibly)Platformsare useful information (althoughPlatformscan get wieldy easily).Statuswill be useful, but is the tricky one (see discussion above)- I'm a bit on the fence on
NodeandEndpoint; I guess the information is specifically useful if a builder uses multiple nodes, but may not always be needed to get a quick overview? Depending on how builders are used, giving a sensible name to your nodes would help. Perhaps we need a--verboseoption to expand builders to include the nodes that are part of it.
For the raw output; do we need some header to indicate that it's a list of nodes? Something like;
./bin/build/docker-buildx ls --format raw
name: default *
driver: docker
nodes:
name: default
endpoint: default
status: running
buildkit: 22.06.0-beta.0-902-g2708be0db4.m
platforms: linux/arm64, linux/amd64, linux/amd64/v2, linux/riscv64, linux/ppc64le, linux/s390x, linux/mips64le, linux/mips64
name: desktop-linux
driver: docker
nodes:
name: desktop-linux
endpoint: desktop-linux
status: running
buildkit: 22.06.0-beta.0-902-g2708be0db4.m
platforms: linux/arm64, linux/amd64, linux/amd64/v2, linux/riscv64, linux/ppc64le, linux/s390x, linux/mips64le, linux/mips64
For buildx ls, we should follow similar conventions to buildx inspect. i.e. the following should be the same:
$ docker buildx inspect desktop-linux
Name: desktop-linux
Driver: docker
Nodes:
Name: desktop-linux
Endpoint: desktop-linux
Status: running
Buildkit: 20.10.21
Platforms: linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
$ buildx ls --format raw
...
name: desktop-linux
driver: docker
name: desktop-linux
endpoint: desktop-linux
status: running
buildkit: 20.10.21
platforms: linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
I think we should stick to the title-case naming of inspect, and follow the status-quo there. However, I think maybe we could indent the Nodes of inspect, and keep the nodes key as suggested by @thaJeztah here.
buildx ls should also take at least one argument (ideally, arbitrary), which should do the job of filtering, similar to how docker image ls operates:
$ docker image ls registry
REPOSITORY TAG IMAGE ID CREATED SIZE
registry 2 81c944c2288b 4 weeks ago 24.1MB
I think this makes buildx inspect X = buildx ls X --raw? I think it's fine to have inspect as an effective alias (even if they're implemented slightly differently under the hood) for this.
Slightly unrelated, since this has been an issue for a while - how do we determine the size of the table? The produced table is quite large, and now that we're shortening the list of platforms, I was wondering if maybe we could consider setting the default size of the table to the width of the terminal window if that info is accessible? It can be kinda frustrating to view in smaller terminals as is, though it's mostly a separate issue, since it has been like this for a while.
For
buildx ls, we should follow similar conventions tobuildx inspect. i.e. the following should be the same:
I think it should be the other way around to be consistent with docker/cli like:
$ docker image ls --format raw
repository: buildkit-tests
tag: latest
image_id: 86c59caf767c
created_at: 2022-12-13 07:58:20 +0100 CET
virtual_size: 1.65GB
repository: <none>
tag: <none>
image_id: d57078eda7ec
created_at: 2022-12-13 07:53:45 +0100 CET
virtual_size: 1.65GB
repository: <none>
tag: <none>
image_id: fdc8939962ce
created_at: 2022-12-13 07:47:31 +0100 CET
virtual_size: 1.65GB
I want to also add the same flags for the inspect command so we can get rid of this: https://github.com/docker/setup-buildx-action/blob/39a1a82492fd1ad19af19d61b5f748e4cb6cd1af/src/buildx.ts#L111-L182 :sweat_smile:
buildx lsshould also take at least one argument (ideally, arbitrary), which should do the job of filtering, similar to howdocker image lsoperates:
sgtm for a follow-up as well
Slightly unrelated, since this has been an issue for a while - how do we determine the size of the table? The produced table is quite large, and now that we're shortening the list of platforms, I was wondering if maybe we could consider setting the default size of the table to the width of the terminal window if that info is accessible? It can be kinda frustrating to view in smaller terminals as is, though it's mostly a separate issue, since it has been like this for a while.
Depends if docker/cli provides this, I'm not sure.
Slightly unrelated, since this has been an issue for a while - how do we determine the size of the table?
I'm still a bit on the fence how relevant showing all platforms is in the default presentation?
- Do we know how it's used?
- Should it default to show the default (native) platform only?
- ^^ and only show the emulated platforms on
inspect?
In general, for the "overview" I (personally) feel like it's "just to get a quick list of builders", so that I can
- "pick" one (
docker builder use/docker buildx use) - have a quick overview of builders that may need to be updated (seeing an older version in the ~
VERSION~BUILDKITcolumn - manage them (
docker builder rm/docker buildx rmetc.).
Within that context, perhaps "native" platform is relevant (I want to use a native arm64 builder), but emulated platforms may be less relevant (but we could add a --filter platform=.... option if I want to make a selection of builders that can support a specific platform).
Is there any alternative to this for getting buildx ls results in a parseable format? It looks like this isn't going to available any time soon.
superseded by:
- https://github.com/docker/buildx/pull/1787
- https://github.com/docker/buildx/pull/2138