`Image` attribute of images built locally by `docker compose` is a checksum in V2

[antoineco]

Description

Compose V2 beta 6

The Image attribute of images built locally by docker compose is a checksum in V2, but it is <stack name>-<service name>:latest on V1.

By "built locally" I mean via a build directive such as

  logstash:
    build:
      context: logstash/

What used to be "Image": "docker-elk_logstash" (where "docker-elk" is the stack name, and "logstash" the service name), is now the sha256 checksum of the generated image.

If that is expected, could you please confirm this behavior will remain stable in the future?

Steps to reproduce the issue:

1. up the following Compose file locally
2. Inspect one of the 3 running containers.
3. Notice that the Image attribute is a sha256 checksum

Describe the results you received:

"Image": "<a long checksum>"

Describe the results you expected:

"Image": "docker-elk_logstash"

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Cloud integration: 1.0.17
 Version:           20.10.6+azure
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        370c28948e3c12dce3d1df60b6f184990618553f
 Built:             Fri Apr  9 17:01:36 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.6+azure
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8728dd246c3ab53105434eef8ffe997b6fd14dc6
  Built:            Fri Apr  9 22:06:18 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.6+azure
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:

Output of docker context show:

default

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., 0.5.1+azure)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 16
 Server Version: 20.10.6+azure
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc version: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 init version:
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.8.0-1033-azure
 Operating System: Ubuntu 20.04.2 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 6.791GiB
 Name: fv-az246-706
 ID: 2AHL:VS5Y:FHVP:G5QA:R65P:TYUO:TK4L:YHNR:YZAY:BOMQ:TCBV:H3Y2
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: githubactions
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS ECS, Azure ACI, local, etc.):

[ndeloof]

build command, ran as part of compose up, does indeed update the model with the exact image ID resulting from building from project sources, to enforce we run the desired image.
I would consider this to be an "implementation detail", could you please clarify your use-case for this?

[antoineco]

@ndeloof I don't have a specific use-case in mind, I just have a custom Kibana dashboard which started showing empty results for the query docker.image:"docker-elk_logstash" after updating to V2 (based on metrics populated by Metricbeat).

I can of course do that better using a more appropriate attribute (the container name, a label, ...). I'm mostly interested in knowing whether it is safe to assume the semantic of Image will remain stable in V2, so that I can update my dashboard accordingly.

[ndeloof]

you indeed should rely on explicit labels then.
I can't guarantee setting image as built ID will be a stable internal approach

[antoineco]

For posterity, this ended up being fixed in #2038, which means the image attribute is again compatible with Compose V1 since the v2.0.0-rc.2 release (thanks!)