compose: [BUG] docker-compose build pulls image from registry instead of local
Description
I have built a local image before pushing to my registry (registry:5000/logopk/httpd:latest). It contains a new apache module that I build in the Dockerfile.
Now I have a second image that builds from this image.
That build succeeds (pulling from registry:5000) but the container fails as the module can’t be found (it is not in the registry yet).
Problem also exists if the registry is offline - the build fails as the image can’t be pulled.
When I revert to 2.9.0 this works as expected.
Steps To Reproduce
see above
Compose Version
docker-compose 2.12.0 from homebrew
Docker Environment
Client: Docker Engine - Community
Version: 20.10.20
API version: 1.41
Go version: go1.19.2
Git commit: 9fdeb9c3de
Built: Tue Oct 18 17:43:24 2022
OS/Arch: darwin/arm64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.20
API version: 1.41 (minimum version 1.12)
Go version: go1.18.7
Git commit: 03df974
Built: Tue Oct 18 18:18:16 2022
OS/Arch: linux/arm64
Experimental: true
containerd:
Version: 1.6.8
GitCommit: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Anything else?
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 24
Commits related to this issue
- Fix a CI issue that causes unit tests to run against the wrong version of CVAT There seems to be a bug somewhere in the Docker ecosystem (it's probably either Docker Compose, Docker Buildx or BuildKi... — committed to SpecLad/cvat by SpecLad a year ago
- Fix a CI issue that causes unit tests to run against the wrong version of CVAT (#5612) There seems to be a bug somewhere in the Docker ecosystem (it's probably either Docker Compose, Docker Buildx o... — committed to opencv/cvat by SpecLad a year ago
- Fix a CI issue that causes unit tests to run against the wrong version of CVAT (#5612) There seems to be a bug somewhere in the Docker ecosystem (it's probably either Docker Compose, Docker Buildx o... — committed to opencv/cvat by SpecLad a year ago
- Fix a CI issue that causes unit tests to run against the wrong version of CVAT (#5612) There seems to be a bug somewhere in the Docker ecosystem (it's probably either Docker Compose, Docker Buildx o... — committed to retailnext/cvat by SpecLad a year ago
I hit this problem as well, whereas colleagues did not have the problem when building the same project.
I ‘fixed’ it by doing the following:
moby/buildkit:buildx-stable-1
container if it’s runningdocker buildx rm --all-inactive
docker compose build
docker
driver by default, given that I randocker buildx create --driver docker --use default
before but it failed with the errorERROR: additional instances of driver "docker" cannot be created
even thoughdocker buildx inspect
did not show anydocker
driverdocker compose build
Before the ‘fix’,
docker buildx inspect
showed (I already stopped the container)After the ‘fix’,
docker buildx inspect
showsIt seems the
docker-container
driver does not use the local image repository, whereas thedocker
driver does. I don’t know what causes this, or what determines whetherdocker-container
ordocker
driver is used for buildx, but this is what I observed…Dockerfile.dev
Dockerfile
docker-compose.yml
docker build -t ubuntu-updated -f Dockerfile.dev .
to build the local filedocker compose build
to pull from the newly created image that is tagged with theFROM
name. and you get the error:@logopk better ask docker/buildx for recommendations on using a docker-container builder and caching built images. Docker Compose is just a third-party user of such features and I can’t tell you about the best approach
Use of a docker-container builder involved builder is “isolated” from docker engine and as such can’t rely on previously pulled image or built image exported to engine. I’m closing this issue as not related to Docker Compose
The same happened to me yesterday. I was using a docker-container builder, and it failed to detect and use the local image from the cache, built on the same run. Now back to the default builder and it works, local image is detected as expected, and not pulled from remote. This should be a bug?
I spent about 4 hours today struggling with this same thing.
Similar to babyhuey, I have a base image that I was making changes to in parallel with a child image. Given that they are separate projects, they are not in the same compose file.
I build the base image so it is in my Docker Desktop for Mac (M1) list of images.
If I
docker build
the child image it works. If Idocker compose
(v2) to build the child image it bypasses the local cache and always looks for the image in Docker Hub.Setting the environment variables to disable Build Kit did not work for me. I reverted my Docker Desktop configuration to use Compose V1 and am able to successfully
docker-compose
(v1) to build the child image. Note that after this change,docker compose
(v2) fails in the same way as before.I ran a few commands, not sure which did it
docker buildx uninstall
andmv ~/.docker/buildx ~
Could you maybe setup a minimal reproduction example to help us investigate this bug ?