[BUG] using a local image fails silently for a local target built on the wrong platform, even with --verbose

rsegal commented 6 months ago

Description

Current behavior:

Running docker compose create and docker compose --verbose create silently fail to use a local image, and then loudly fail downstream when it can't pull that image;

✘ db Error        context canceled                                                                                                0.4s 
✘ <service 2> Error pull access denied for <service 1>, repository does not exist or may require 'docker lo...                  0.4s

even though both <service 1> and <service 2> are built images that I can see with docker image ls. However, when I force compose to use local images with docker compose create --pull never, it reports the root cause:

Error response from daemon: image with reference <service 1> was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64

And in fact the service blocks specified platform:linux/arm64 while I was trying to build on linux/amd64. Removing those lines allowed the build to succeed.

Expected behavior:

When running with the --verbose flag, the platform error is printed regardless of whether --pull never is specified. Running without --verbose could print the error without --pull never but probably doesn't.

Steps To Reproduce

On a MBP 2015 running Monterey
Have a docker compose file specifying two services, where one depends on the other
Have the depended-on service specify an incompatible platform, such as linux/arm64 (instead of your linux/amd64)
Build both images and then verify that they were created (say, with docker image ls)
docker compose create
docker compose --verbose create
docker compose create --pull never
Observe that steps 4, 5, and 6 all fail, but steps 4 and 5 do not report the root cause error while step 6 does.

Compose Version

Docker Compose version v2.27.0-desktop.2
Docker Compose version v2.27.0-desktop.2

Docker Environment

Client:
 Version:    26.1.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0-desktop.1
    Path:     /Users/raphaelsegal/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.27.0-desktop.2
    Path:     /Users/raphaelsegal/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.29
    Path:     /Users/raphaelsegal/.docker/cli-plugins/docker-debug
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     /Users/raphaelsegal/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.23
    Path:     /Users/raphaelsegal/.docker/cli-plugins/docker-extension
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.4
    Path:     /Users/raphaelsegal/.docker/cli-plugins/docker-feedback
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.1.0
    Path:     /Users/raphaelsegal/.docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/raphaelsegal/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.8.0
    Path:     /Users/raphaelsegal/.docker/cli-plugins/docker-scout

Server:
 Containers: 2
  Running: 2
  Paused: 0
  Stopped: 0
 Images: 2
 Server Version: 26.1.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e377cd56a71523140ca6ae87e30244719194a521
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.6.26-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 7.656GiB
 Name: docker-desktop
 ID: 85b7bd42-e472-4468-a632-96bb6520d474
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/raphaelsegal/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: daemon is not using the default seccomp profile

Anything else?

No response

idsulik commented 5 months ago

Hello @rsegal, is it right steps to reproduce it?

Dockerfile1: FROM alpine

Dockerfile2: FROM --platform=linux/amd64 alpine

services:
  one:
    build:
      context: .
      dockerfile: Dockerfile1
    depends_on:
      - two
  two:
    build:
      context: .
      dockerfile: Dockerfile2

docker compose create:

! two The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

second execution gives no error

rsegal commented 5 months ago

In my case the FROM invocations didn't specify the platform. (They were FROM mysql:8 and FROM wordpress:php7.4 for completeness.)

Rather, platform was specified in the docker compose file; both services had the argument platform: linux/arm64.

My inference is that my computer (being an old MBP) built the two images individually for itself, linux/amd64. Then in the docker compose call, because it explicitly was looking for a different platform it never considered those locally built images.

docker / compose