compose icon indicating copy to clipboard operation
compose copied to clipboard

images built with older Docker CE version are invalid

Open podlesh opened this issue 3 years ago • 1 comments

Description

This might be considered just a documentation issue: the image-building feature (docker compose build or docker compose up --build) does not work correctly with older version(s) of the docker itself.

There is, however, no documented "compatibility" matrix publicly available and there is no warning about this limitation. In particular: Docker Compose 2.5.0 requires Docker CE 20.10.13 and does not correctly work with Docker CE 19.03.6-ce.

And so far, not even a bug report. Hopefully this one will be useful for anyone who runs into this issue.

Steps to reproduce the issue:

  1. have docker-compose.yml with at least one service having build defined; the Dockerfile contains ENTRYPOINT, CMD and WORKDIR directives
  2. docker compose build
  3. docker compose up

Describe the results you received:

Container fails with Error response from daemon: No command specified. docker inspect of the image confirms that both Entrypoint and Cmd are, indeed null. Also, the WorkingDir has the default value of "/", despite the different value in WORKDIR directive being present in the Dockerfile.

It's obvious that ENTRYPOINT, CMD and WORKDIR directives in the Dockerfile are completely ignored.

Describe the results you expected:

The build should either

  • either correctly handle the Dockerfile as it is, producing a valid image just like docker build would
  • or fail with an error message

Output of docker compose version:

Docker Compose version v2.5.0

Output of docker info:

docker-compose 2.5.0 does not work correctly with:

Client:
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc., v2.5.0)

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 179
 Server Version: 19.03.6-ce
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 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: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ff48f57fc83a8c44cf4ad5d672424a98ba37ded6
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.14.173-137.229.amzn2.x86_64
 Operating System: Amazon Linux 2
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 7.69GiB
 Name: ip-172-31-8-163.eu-central-1.compute.internal
 ID: ODR2:A5EY:DE6B:7HEI:CWMD:SEZF:OWY3:7X4Q:JDA6:5V7E:B2GN:TIGS
 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

With this version, everything works correctly:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc., v2.5.0)

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 179
 Server Version: 20.10.13
 Storage Driver: overlay2
  Backing Filesystem: xfs
  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: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ff48f57fc83a8c44cf4ad5d672424a98ba37ded6
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.14.173-137.229.amzn2.x86_64
 Operating System: Amazon Linux 2
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 7.69GiB
 Name: ip-172-31-8-163.eu-central-1.compute.internal
 ID: ODR2:A5EY:DE6B:7HEI:CWMD:SEZF:OWY3:7X4Q:JDA6:5V7E:B2GN:TIGS
 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:

podlesh avatar May 10 '22 14:05 podlesh

Same issue here

joeangel avatar Aug 02 '22 01:08 joeangel

don't you have the same error when image is built using recent docker CLI as docker build ... with engine 19.03? that's weird anyway, as those image attributes are all defined in the Dockerfile, and syntax hasn't changed, so I can't see any reason an older engine would not be able to parse it and build the expected image.

ndeloof avatar Dec 16 '22 13:12 ndeloof

Closing as reporter didn't provided the requested informations

ndeloof avatar May 11 '23 09:05 ndeloof

There is, of course, no such issue with docker build and never was. That would be pretty hard to miss...

podlesh avatar May 11 '23 09:05 podlesh

right, you just answered. Wasn't obvious you don't have the same issue with plain docker build. I can't reproduce this issue, so hard to diagnose:

$ docker run -d --privileged -e DOCKER_TLS_CERTDIR='' -p 2375:2375 docker:19.03-dind
$ export DOCKER_HOST=tcp://localhost:2375
$ cat Dockerfile
FROM alpine
CMD echo hello
$ cat compose.yaml 
services:
  server:
    build: .
$ docker compose build
[+] Building 3.5s (6/6) FINISHED                                                
...
 => => naming to docker.io/library/test-server  
$ docker inspect truc-server -f '{{.Config.Cmd}}'
[/bin/sh -c echo hello]

ndeloof avatar May 11 '23 09:05 ndeloof

Have you tried using the classic builder by running DOCKER_BUILDKIT=0 docker compose build just in case this issue is related to buildkit being used by default with compose ?

ndeloof avatar May 11 '23 09:05 ndeloof

No, I haven't tried that. Unfortunately, I don't have any installation to try it again :-(

But my money would be on buildkit too. It does, after all, contain others and much more serious bugs.

podlesh avatar May 11 '23 13:05 podlesh

Did you maybe used a public AMI I could use to try replicate this issue ?

ndeloof avatar May 11 '23 13:05 ndeloof

No, definitely not a public one, and now I cannot find any system to reproduce it either. I suppose you would have to close it as a "cannot reproduce".

At least anyone who googles this issue finds the solution (ie upgrade the docker engine).

podlesh avatar May 15 '23 16:05 podlesh

let's close this issue. If anyone comes into the same issue, feel free to comment or open a follow-up issue

ndeloof avatar May 15 '23 17:05 ndeloof