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

--reproducible leads to different layers in resulting image #900

Closed
ingokofler opened this issue Dec 3, 2019 · 7 comments · Fixed by #1032 or #1350
Closed

--reproducible leads to different layers in resulting image #900

ingokofler opened this issue Dec 3, 2019 · 7 comments · Fixed by #1032 or #1350
Labels
area/behavior all bugs related to kaniko behavior like running in as root kind/bug Something isn't working priority/p3 agreed that this would be good to have, but no one is available at the moment.

Comments

@ingokofler
Copy link

Actual behavior
Building an image twice using the --reproducible flag leads to different layers in the final images.

Expected behavior
Image layers should have the same hash as the content is the same and the reproducible flag was used.

To Reproduce

mkdir ctx && cd ctx
echo "Foo" >foo
echo "Fooo" >fooo
echo "Bar" >bar

cat >Dockerfile <<'EOF'
FROM gcr.io/distroless/java
USER nonroot
COPY foo* /
COPY bar /
EOF

docker run -it -e http_proxy=$http_proxy -e https_proxy=$https_proxy -e no_proxy=$no_proxy --rm -v $(pwd):/data  \
         -v ~/.docker/config.json:/kaniko/.docker/config.json \
         gcr.io/kaniko-project/executor:v0.14.0 \
              --reproducible \
              --context /data \
              --dockerfile Dockerfile \
              --destination myrepo.com/img:foo

docker run -it -e http_proxy=$http_proxy -e https_proxy=$https_proxy -e no_proxy=$no_proxy --rm -v $(pwd):/data  \
         -v ~/.docker/config.json:/kaniko/.docker/config.json \
         gcr.io/kaniko-project/executor:v0.14.0 \
              --reproducible \
              --context /data \
              --dockerfile Dockerfile \
              --destination myrepo.com/img:bar 

Layers in myrepo.com/img:foo and myrepo.com/img:bar have different hashes.

Additional Information
see steps to reproduce

also described this in in #710 - this issue is however not releated to caching

Triage Notes for the Maintainers

Description Yes/No
Please check if this a new feature you are proposing
Please check if the build works in docker but not in kaniko
Please check if this error is seen when you use --cache flag
Please check if your dockerfile is a multistage dockerfile
@dinvlad
Copy link

dinvlad commented Dec 21, 2019

Having the same issue. I ran all checks supplied by container-diff, but it didn't reveal any differences. Yet, sha256 still differs..

@cvgw cvgw added area/behavior all bugs related to kaniko behavior like running in as root kind/bug Something isn't working labels Dec 21, 2019
@ingokofler
Copy link
Author

As mentioned in #710 I have already debugged this and the different hash is resulting from the different order of the files in this tar-gz json diff layer information. I think the files listed in that JSON file need to be in a consistent order.

@cvgw cvgw added the priority/p3 agreed that this would be good to have, but no one is available at the moment. label Jan 10, 2020
@tinkerborg
Copy link
Contributor

This map in filesWithParentDirs causes that function to return files in a different order on each invocation. I refactored it a bit to preserve order, and now my layers remain consistent, but only with a warm cache. The initial image built w/ cold cache differs.

@ingokofler
Copy link
Author

ingokofler commented Jan 31, 2020

Why is this influenced by caching? I had a look on the code - I am not a Go expert but do those maps preserve order? Wouldn't it be sufficient to just sort the resulting array of files in lexicographical order?

@hlubek
Copy link
Contributor

hlubek commented Jul 15, 2020

There is still a case that leads to different layers that I observed today in one of our builds:

  • If files are deleted between layers, the deleted files will be iterated over a map (unstable) and collected in a slice
  • The whiteouts that are written to the tar are thus not stable and result in a tar file with different order (but same contents)

The code should be quite easy to fix by adding sorting for the whiteouts.

@androidkh
Copy link

Issue is still present. More over, when using --reproducible option and destination gcr - it creates an images with different sha256 digests and created date of Jan 1, 1 that is not really good.

@hrobertson
Copy link

@androidkh tracked by #2005

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/behavior all bugs related to kaniko behavior like running in as root kind/bug Something isn't working priority/p3 agreed that this would be good to have, but no one is available at the moment.
Projects
None yet
7 participants