Description
relates to:
While discussing changes / designs for the CLI to improve output for docker image inspect (and to look at designs for a potential docker image info command), I noticed that the image inspect output contains various fields that don't seem to be related to the image itself. Some of these are "known" as they were (are) used by the classic builder (such as ContainerConfig); however, it looks like the Config field has the same issue, and holds the Container config.
Container field; only used by classic builder, and holds the ID of the container that was used to produce the image
|
// Container is the ID of the container that was used to create the image. |
|
// |
|
// Depending on how the image was created, this field may be empty. |
|
Container string |
ContainerConfig field; only used by classic builder, and holds the config of the container that was used to produce the image
|
// ContainerConfig is an optional field containing the configuration of the |
|
// container that was last committed when creating the image. |
|
// |
|
// Previous versions of Docker builder used this field to store build cache, |
|
// and it is not in active use anymore. |
|
ContainerConfig *container.Config |
Config field; this one needs to be looked at
Looking at Config, we are using container.Config, which seems to be a superset of what should actually be part of the image.
Here's examples of images built with BuildKit and the classic builder;
docker buildx imagetools inspect --raw moby/moby-bin@sha256:f8ae01a0e08159551e946cae5dad31675cfc47d29d3a851504ccf8adad8da3e4 | jq .config
{
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"WorkingDir": "/",
"Labels": {
"org.opencontainers.image.created": "2023-11-13T11:22:54.120Z",
"org.opencontainers.image.description": "The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems",
"org.opencontainers.image.licenses": "Apache-2.0",
"org.opencontainers.image.revision": "34e923e3e31be229c6ad72005416134fc2a1fcfe",
"org.opencontainers.image.source": "https://github.com/moby/moby",
"org.opencontainers.image.title": "moby",
"org.opencontainers.image.url": "https://github.com/moby/moby",
"org.opencontainers.image.version": "master"
},
"OnBuild": null
}docker buildx imagetools inspect --raw docker.io/library/busybox:latest@sha256:a416a98b71e224a31ee99cff8e16063554498227d2b696152a9c3e0aa65e5824 | jq .config
{
"Hostname": "",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"sh"
],
"Image": "sha256:919de79e94ce464098cec8a4796f27aa2d0c93985e27f6a157c8bbb557568013",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"OnBuild": null,
"Labels": null
}Note that various fields are stored in the image, but are not part of an image's config, but only to be used at runtime (set by a container), so are likely ignored when running the image, such as;
AttachStdinAttachStdoutAttachStderrTtyOpenStdinStdinOnce
Some fields are also confusing, such as Image (see some tickets linked above), and WorkingDir looks to be inconsistent (BuildKit defaults to "/", whereas classic builder uses "" as default).
We should define a type separate from container.Config for this purpose, and remove fields that should not be persisted in the image. We may have to check what parts are used by the classic builder though.
Description
relates to:
While discussing changes / designs for the CLI to improve output for
docker image inspect(and to look at designs for a potentialdocker image infocommand), I noticed that the image inspect output contains various fields that don't seem to be related to the image itself. Some of these are "known" as they were (are) used by the classic builder (such asContainerConfig); however, it looks like theConfigfield has the same issue, and holds the Container config.Containerfield; only used by classic builder, and holds the ID of the container that was used to produce the imagemoby/api/types/types.go
Lines 77 to 80 in 34e923e
ContainerConfigfield; only used by classic builder, and holds the config of the container that was used to produce the imagemoby/api/types/types.go
Lines 82 to 87 in 34e923e
Configfield; this one needs to be looked atmoby/api/types/types.go
Line 97 in 34e923e
Looking at
Config, we are usingcontainer.Config, which seems to be a superset of what should actually be part of the image.Here's examples of images built with BuildKit and the classic builder;
Note that various fields are stored in the image, but are not part of an image's config, but only to be used at runtime (set by a container), so are likely ignored when running the image, such as;
AttachStdinAttachStdoutAttachStderrTtyOpenStdinStdinOnceSome fields are also confusing, such as
Image(see some tickets linked above), andWorkingDirlooks to be inconsistent (BuildKit defaults to"/", whereas classic builder uses""as default).We should define a type separate from
container.Configfor this purpose, and remove fields that should not be persisted in the image. We may have to check what parts are used by the classic builder though.