Skip to content
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

Using FROM <image_id> doesn't work when using DOCKER_BUILDKIT=1 #2204

Open
bossmc opened this issue Jun 25, 2021 · 12 comments
Open

Using FROM <image_id> doesn't work when using DOCKER_BUILDKIT=1 #2204

bossmc opened this issue Jun 25, 2021 · 12 comments
Labels
area/feature-parity Feature parity with classic builder
Milestone

Comments

@bossmc
Copy link
Contributor

bossmc commented Jun 25, 2021

If you have a Dockerfile of the form:

FROM sha256:abcdefgxxxxxxxxxxxxxxxx
[...]

Then docker build fails but only if buildkit is in use (tested with DOCKER_BUILDKIT=1 as well as docker buildx):

$ DOCKER_BUILDKIT=0 docker build .
Sending build context to Docker daemon  7.168kB
Step 1/2 : FROM sha256:06017009f887cf12ab636d362e9c0170acac7735a1cc0ee786e720385a37d619
 ---> 06017009f887
Step 2/2 : LABEL GOODBYE="Have a nice day!"
 ---> Running in e8772594c7e4
Removing intermediate container e8772594c7e4
 ---> acc07f1c0296
Successfully built acc07f1c0296

vs

$ DOCKER_BUILDKIT=1 docker build .
[+] Building 1.1s (4/4) FINISHED                                                                                                                                                                                                             
 => [internal] load build definition from Dockerfile                                                                                                                                                                              0.0s
 => => transferring dockerfile: 33B                                                                                                                                                                                                     0.0s
 => [internal] load .dockerignore                                                                                                                                                                                                       0.0s
 => => transferring context: 2B                                                                                                                                                                                                         0.0s
 => ERROR [internal] load metadata for docker.io/library/sha256:06017009f887cf12ab636d362e9c0170acac7735a1cc0ee786e720385a37d619                                                                                                        1.0s
 => [auth] library/sha256:pull token for registry-1.docker.io                                                                                                                                                                           0.0s
------
 > [internal] load metadata for docker.io/library/sha256:06017009f887cf12ab636d362e9c0170acac7735a1cc0ee786e720385a37d619:
------
error: failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to create LLB definition: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
@bossmc
Copy link
Contributor Author

bossmc commented Jun 25, 2021

Minimal reproduction at https://github.com/bossmc/repro-buildkit-2204.

System information:

$ docker version
Client: Docker Engine - Community
 Version:           20.10.7
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        f0df350
 Built:             Wed Jun  2 11:56:40 2021
 OS/Arch:           linux/amd64
 Context:           tcp
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.7
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       b0f5bc3
  Built:            Wed Jun  2 11:54:48 2021
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.4.6
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

@thaJeztah thaJeztah added the area/feature-parity Feature parity with classic builder label Jun 25, 2021
@dautovri
Copy link

@thaJeztah Hi any updates or information about this issue?

@thaJeztah
Copy link
Member

Not that I'm aware of. Perhaps @crazy-max knows.

@crazy-max
Copy link
Member

crazy-max commented Aug 17, 2021

@dautovri BuildKit needs to resolve image config to load metadata in Dockerfile frontend. I think that's why it fails because we need a valid image reference here. cc @tonistiigi

@thaJeztah
Copy link
Member

I think in this case, the ID / sha is also not the "distribution digest", but the digest of a local image (before it's pushed to a registry). The classic builder could use those to reference images in the local image cache (not sure if BuildKit can do the same?)

@crazy-max
Copy link
Member

also not the "distribution digest"

Ah yes that's it!

@dautovri
Copy link

I think in this case, the ID / sha is also not the "distribution digest", but the digest of a local image (before it's pushed to a registry). The classic builder could use those to reference images in the local image cache (not sure if BuildKit can do the same?)

It's means we will need to make a local registry, push the image, and after that use it in FROM?

@bossmc
Copy link
Contributor Author

bossmc commented Aug 17, 2021

The build works if the local image is tagged and the build references it by the tag - that doesn't create any special registry/"distribution digest" as far as I know though.

@thaJeztah
Copy link
Member

Yes, buildkit looks to interpret sha256 as the image name and :<digest> as tag. I think there's a special case in the docker engine code (and classic builder) that checks for sha256: and [a-z0-9]{64} for ID's that are specified without sha256: prefix.

@dv-petrov
Copy link

dv-petrov commented Mar 15, 2022

buildkit looks to interpret sha256 as the image name and :<digest> as tag

Not quite. If we use shortened ID, we will get the same result.

$ export BUILD_KIT=1
$ docker pull hello-world
$ ID=$(docker create hello-world)
$ IMG=$(docker commit $ID | tail -c +8 | head -c 14)
$ echo $IMG
2e5a9d259d70a4
$ echo -e "FROM $IMG\nCMD echo $BUILD_KIT"|docker build -f - .

[+] Building 1.5s (3/3) FINISHED 
 => [internal] load build definition from Dockerfile                                                                                                                     
 => => transferring dockerfile: 67B                                                                                                                                              
 => [internal] load .dockerignore                                                                                                                                                
 => => transferring context: 2B                                                                                                                                                  
 => ERROR [internal] load metadata for docker.io/library/2e5a9d259d70a4:latest                                                                                                   
------
 > [internal] load metadata for docker.io/library/2e5a9d259d70a4:latest:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

@bossmc
Copy link
Contributor Author

bossmc commented Mar 15, 2022

That underlying behaviour is a little different - that's treating the hash as the name of an image stored on dockerhub and guessing latest as the tag (hence the expanded docker.io/library/2e5a9d259d70a4:latest). OTOH this also used to work pre-buildkit so it's effectively the same issue.

@brandonegbert
Copy link

Hi, we've come to realize that FROM <image_id> no longer works on Docker 25 without DOCKER_BUILDKIT=0. Any chance of this functionality being restored for buildkit before the legacy builder is removed?

@thompson-shaun thompson-shaun removed the area/feature-parity Feature parity with classic builder label Sep 6, 2024
@thompson-shaun thompson-shaun added the area/feature-parity Feature parity with classic builder label Sep 9, 2024
@thompson-shaun thompson-shaun added this to the v0.future milestone Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/feature-parity Feature parity with classic builder
Projects
None yet
Development

No branches or pull requests

8 participants