Buildx doesn't respect insecure registries #2226
Comments
|
The actual error message you're seeing doesn't seem to be an HTTPS error: It looks like somehow it doesn't connect to your registry at all? Can you |
|
The problem is its trying to use HTTPS, even tho its in insecure registries. |
Sure, that's possible there could be a bug here, but that's not what the error you've shared shows. #1642 is about I'm unsure as to why the resolution for images should be different here, any ideas @crazy-max @thaJeztah? Given this is buildkit-in-docker. |
|
Indeed, its not exactly the same. |
|
I think I saw a discussion somewhere where BuildKit initialises a client with either http or https, and because of that would not work with combinations (registry itself using http, but blobs downloaded through https and/or vice-versa). I wonder if that's related here. |
|
cc @vvoland who did some work on this recently as well: |
|
Related discussion for my previous comment; |
|
Don't you need a toml file to configure builder instances to make insecure repos work with buildkit and buildx? And [registry."example.registry.com"]
insecure = true Or am I missing the point here? That's what I've been doing for contacting insecure registries for over a year now. The setting in |
|
Well, it worked until 25.x.y with buildx (which I guess is built on top of buildkit). |
|
Are you sure that in |
|
Oh yeah. By default it is buildx. We did not modify docker in any way (apart from the insecure registries in daemon.json). |
|
Hi, Any updates? Its blocking our second upgrade schedule for our jenkins'. |
|
v0.13.1 fail use http registry. My flow shown as below buildx-config.toml Buildx keep requesting https, in the end locking to old version with |
|
Is there any update with this issue ? we are being blocked by this exact issue and currently only working with the workaround |
|
@martadinata666, I have exactly same issues with exactly same commands in my ubuntu server, which blocks our CI/CD pipeline in Jenkins. :( However, it works in my mac with M2 chip. Ubuntu Docker version: # docker version
Client: Docker Engine - Community
Version: 26.0.2
API version: 1.45
Go version: go1.21.9
Git commit: 3c863ff
Built: Thu Apr 18 16:27:07 2024
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 26.0.2
API version: 1.45 (minimum version 1.24)
Go version: go1.21.9
Git commit: 7cef0d9
Built: Thu Apr 18 16:27:07 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.31
GitCommit: e377cd56a71523140ca6ae87e30244719194a521
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0# docker buildx version
github.com/docker/buildx v0.14.0 171fcbeMac Docker version: # docker version
Client:
Cloud integration: v1.0.35+desktop.13
Version: 26.0.0
API version: 1.45
Go version: go1.21.8
Git commit: 2ae903e
Built: Wed Mar 20 15:14:46 2024
OS/Arch: darwin/arm64
Context: desktop-linux
Server: Docker Desktop 4.29.0 (145265)
Engine:
Version: 26.0.0
API version: 1.45 (minimum version 1.24)
Go version: go1.21.8
Git commit: 8b79278
Built: Wed Mar 20 15:18:02 2024
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.6.28
GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0# docker buildx version
github.com/docker/buildx v0.13.1-desktop.1 2368b2ee41873b948cb607251cec573ed00f00f9 |
|
Maybe i need to add more info to my deployment as well |
|
Same problem on a fresh install of Docker 26.1.2 in an VM with Oracle Linux 8.9. I can manually pull the same image without problem. The workaround for now is using "export DOCKER_BUILDKIT=0". docker builder version Example of a docker compose setup: |
|
I have been pulling my hair for a day now trying to understand how this actually works, because it is fairly schizofrenic. So adding an http mirror into daemon.json, will cause most of the "normal" docker commands to actually use that mirror as is (namely, use http). However, this also makes buildkit use that mirror, but instead call it via https (WTF?). Not only that, it will then wait for a timeout on EVERY request (30-60 seconds, even more WTF) before moving onto calling the docker hub registry directly, making it seemingly "work" but completely defunct because pulling the image takes forever. Just getting metadata takes 90 seconds for me. The only way I managed to get it to work, is to declare a NEW builder with a NEW config that configures the mirror as a repository with This also seem to have been an ongoing issue for the past 6 years or so (when trying to follow the various issues filed for this), where to me, since it obviously uses the mirror configuration from daemon.json (and knows about it), why wouldn't it also respect the http scheme like the rest of the docker tooling? What is this https enforcement actually trying to enforce? |
|
Should be fixed by moby/buildkit#4975 and can be tested with https://github.com/moby/buildkit/releases/tag/v0.14.0-rc1 |
|
I'm pretty curious, as to why it still fails. Would you like me to upgrade something? |
|
#Step1 # craete buildx config file on your local machine [registry."http://114.67.223.128:5080"] #Step2 create builder with the config file specified You can try to fix the http request problem by specify --config param .It works for me . |
|
Hi, This is still not solved, can you please reopen it? |
|
it nearly works for me ,but another error occurred: (base) [root@registry multi-platform]# sudo docker buildx build --platform linux/amd64 -t multi-platform:latest --load .
[+] Building 0.1s (4/4) FINISHED
=> [internal] load .dockerignore 0.0s
......
------
Dockerfile:1
--------------------
1 | >>> FROM registry.example.com/gobuildx:0.3.0
2 |
3 | RUN uname -m > /arch
--------------------
ERROR: failed to solve: registry.example.com/gobuildx:0.3.0: failed to fetch schema1 manifest: httpReadSeeker: failed open: content at http://registry.example.com/v2/ci/gobuildx/manifests/sha256:bc7f061f847f88ffc11b2a50f30d30b1d382574db1a6fc287e49bd2a80ec2d70 not found: not found
|
|
I don't know how this issue can be resolved, yet still persist and no resolution given. |
|
Is threre any updates with this? I still on this issue with buildx 0.18.2. |
Out of all of the issues that come up with Insecure Registries, this is the only solution that has helped me. Do people seriously not use insecure registries? How is this issue not resolved for years on linux, but "just works" on Docker for Windows? |
|
Opened #2968 to have an active issue. |
Contributing guidelines
I've found a bug and checked that ...
Description
Using the buildx plugin the insecure registries are not working after the latest update.
By default it tries HTTPS (443).
Issue visible on multiple systems.
Expected behaviour
Use port 80
Actual behaviour
Uses port 443
Buildx version
github.com/docker/buildx v0.12.1 30feaa1
Docker info
Builders list
Configuration
Build logs
Additional info
Insecure registry is set properly in /etc/docker/daemon.json:
The text was updated successfully, but these errors were encountered: