Compose V2 container `Image` attribute is inconsistent with V1 and prevents Watchtower

[amarcu5]

Description

Compose V2 beta 6

The Image attribute of images started by docker compose is a hash in V2, but is the image name on V1. Although similar to #1972, this is important as it currently prevents Watchtower (containrrr/watchtower#1019) and other auto container update systems from working.

Steps to reproduce the issue:

1. docker compose up the following Compose file:

version: "3.9"

services:
  nginx:
    image: nginx

2. Inspect the container.
3. Notice that the Image attribute is a sha256 hash.

Describe the results you received:
"Image": "sha256:08b152afcfae220e9709f00767054b824361c742ea03a9fe936271ba520a0a4b"

Describe the results you expected:
"Image": "nginx"

Output of docker version:

Docker version 20.10.7, build f0df350

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
  compose: Docker Compose (Docker Inc., v2.0.0-beta.6)
  scan: Docker Scan (Docker Inc., v0.8.0)

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 20.10.7
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  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: e25210fe30a0a703442421b0f60afac609f950a3
 runc version: v1.0.1-0-g4144b63
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-77-generic
 Operating System: Ubuntu 20.04.2 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 981.3MiB
 Name: X
 ID: X
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 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.):
DigitalOcean droplet

[ndeloof]

compose.v2 indeed updates service images to resolved local image ID, and does this both for pulled and built images, to ensure we detect containers which have to be recreated after an image update. Maybe we should introduce some lifecycle metadata to the service so that we don't rely on image ID for this purpose. Need to check the legacy docker-compose codebase to understand how it address this need.

relevant code: https://github.com/docker/compose-cli/blob/main/pkg/compose/build.go

[ndeloof]

internally tracked as https://docker.atlassian.net/browse/IL-490

[bwateratmsft]

I've noticed this as well affecting the Docker extension for VSCode (though not in a serious way). We use that field as the image name label which is the default for containers; in compose projects this looks rather unwieldy.

(In this case all three containers are from image alpine:latest)

[mat007]

Re-opening as we’ve reverted the PR (it was merged by mistake as it didn’t pass all the tests).