-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] docker-compose build pulls image from registry instead of local #9939
Comments
Build from local using docker compose has been broken for a while now, did you find any workarounds? I'm using |
Also getting this issue on v2.12.2 |
Confirm this works in v2.10 but v2.11 it's broken |
Workaround: |
buildkit indeed allows to run builds in parallel, but doesn't manage dependencies between builds when one service image relies on another service image to be built before and available in local image cache (docker/buildx#447). Closing as a duplicate for #8538 |
Could someone reopen this? This is different from #8538 in my case. This recently started failing with |
Yea, this is definitely not a dupe of 8538, needs to be reopened and looked at |
Could you maybe setup a minimal reproduction example to help us investigate this bug ? |
Dockerfile.dev
Dockerfile
docker-compose.yml ---
version: '3'
services:
web:
build:
context: .
ports:
- 8503:8503
|
Huh, looking at that I see buildx that I hadn't noticed before. If I remove that, it is working as expected... |
Did you remove it by running |
I ran a few commands, not sure which did it |
I can't reproduce this bug with provided example 🧐
|
Could you please run |
I consider this as serious issue any ETA ? |
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 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 |
I hit this bug as well. I did a Git bisect and the first "bad" commit is 8b1b708. I'll see if I can create a minimal reproduction recipe. |
Okay, it's just this: $ cat docker-compose.yml
services:
bazquux:
build:
context: .
$ cat Dockerfile
FROM foobar
$ docker image pull busybox:musl
musl: Pulling from library/busybox
e96e863613a1: Pull complete
Digest: sha256:e7dc28a9c45363cb558fd4a03bc65a21b602a4fd744d48a4002790ea2c988178
Status: Downloaded newer image for busybox:musl
docker.io/library/busybox:musl
$ docker image tag busybox:musl foobar
$ docker buildx create --use
nifty_carver
$ docker compose build
[+] Building 4.5s (4/4) FINISHED
=> [internal] booting buildkit 2.8s
=> => pulling image moby/buildkit:buildx-stable-1 1.7s
=> => creating container buildx_buildkit_nifty_carver0 1.1s
=> [internal] load .dockerignore 0.2s
=> => transferring context: 2B 0.0s
=> [internal] load build definition from Dockerfile 0.2s
=> => transferring dockerfile: 49B 0.0s
=> ERROR [internal] load metadata for docker.io/library/foobar:latest 1.2s
------
> [internal] load metadata for docker.io/library/foobar:latest:
------
failed to solve: foobar: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed The EDIT: added some missing commands |
…n of CVAT There seems to be a bug somewhere in the Docker ecosystem (it's probably either Docker Compose, Docker Buildx or BuildKit) that causes `docker compose build` to ignore base images that are already present in the system, and instead fetch them from Docker Hub, if there's a custom Buildx builder configured. There's a bug report here: <docker/compose#9939>. This bug means that when the build pipeline builds the `cvat_ci` image, it's based on the latest release of `cvat/server` from Docker Hub instead of the version that we just built. Consequently, we run the unit tests against that release instead of the development version. Fortunately, we don't actually need to set up a Buildx builder in most jobs (including the `unit_testing` job), so just don't do that. Also, use `cvat/server:local` as the base image in `Dockerfile.ci`. This will prevent a similar bug from reoccurring in the future, since the `local` tag should never be uploaded to Docker Hub.
…n of CVAT (#5612) There seems to be a bug somewhere in the Docker ecosystem (it's probably either Docker Compose, Docker Buildx or BuildKit) that causes `docker compose build` to ignore base images that are already present in the system, and instead fetch them from Docker Hub, if there's a custom Buildx builder configured. There's a bug report here: <docker/compose#9939>. This bug means that when the build pipeline builds the `cvat_ci` image, it's based on the latest release of `cvat/server` from Docker Hub instead of the version that we just built. Consequently, we run the unit tests against that release instead of the development version. Fortunately, we don't actually need to set up a Buildx builder in most jobs (including the `unit_testing` job), so just don't do that. Also, use `cvat/server:local` as the base image in `Dockerfile.ci`. This will prevent a similar bug from reoccurring in the future, since the `local` tag should never be uploaded to Docker Hub.
…n of CVAT (#5612) There seems to be a bug somewhere in the Docker ecosystem (it's probably either Docker Compose, Docker Buildx or BuildKit) that causes `docker compose build` to ignore base images that are already present in the system, and instead fetch them from Docker Hub, if there's a custom Buildx builder configured. There's a bug report here: <docker/compose#9939>. This bug means that when the build pipeline builds the `cvat_ci` image, it's based on the latest release of `cvat/server` from Docker Hub instead of the version that we just built. Consequently, we run the unit tests against that release instead of the development version. Fortunately, we don't actually need to set up a Buildx builder in most jobs (including the `unit_testing` job), so just don't do that. Also, use `cvat/server:local` as the base image in `Dockerfile.ci`. This will prevent a similar bug from reoccurring in the future, since the `local` tag should never be uploaded to Docker Hub.
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:
Before the 'fix',
After the 'fix',
It seems the |
|
…n of CVAT (cvat-ai#5612) There seems to be a bug somewhere in the Docker ecosystem (it's probably either Docker Compose, Docker Buildx or BuildKit) that causes `docker compose build` to ignore base images that are already present in the system, and instead fetch them from Docker Hub, if there's a custom Buildx builder configured. There's a bug report here: <docker/compose#9939>. This bug means that when the build pipeline builds the `cvat_ci` image, it's based on the latest release of `cvat/server` from Docker Hub instead of the version that we just built. Consequently, we run the unit tests against that release instead of the development version. Fortunately, we don't actually need to set up a Buildx builder in most jobs (including the `unit_testing` job), so just don't do that. Also, use `cvat/server:local` as the base image in `Dockerfile.ci`. This will prevent a similar bug from reoccurring in the future, since the `local` tag should never be uploaded to Docker Hub.
The same happened to me yesterday. |
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. |
@ndeloof I don't disagree that this is not (!) compose-related - however i would like to see a more elaborate answer here as how to fix this problem! I have no clue how and why this happens in my environment - let alone how to prevent it from happening (again) |
@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 |
You may be running into the issue that the image in your local registry is a different architecture than your system ( |
Sticking with the example
while
Which matches this discusstion in buildx: |
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 Environment
Anything else?
No response
The text was updated successfully, but these errors were encountered: