5

I'm doing the following:

docker build -t gcr.io/projid/imgname:333 -t gcr.io/projid/imgname:latest .

docker login -u _json_key -p "$(cat /secrets/service-account.json)" https://gcr.io

docker push gcr.io/projid/imgname:333

docker push gcr.io/projid/imgname:latest

Output of 1st push command:

Pushing to google container registry ...
The push refers to a repository [gcr.io/projid/imgname]
24af4f7c7118: Preparing
17b0972980d8: Preparing
6d6a6425aacb: Preparing
809c8c0dd73c: Preparing
e8d45b8ab3ca: Preparing
e8fa134cb7b8: Preparing
7cbcbac42c44: Preparing
e8fa134cb7b8: Waiting
7cbcbac42c44: Waiting
809c8c0dd73c: Layer already exists
e8d45b8ab3ca: Layer already exists
7cbcbac42c44: Layer already exists
e8fa134cb7b8: Layer already exists
17b0972980d8: Pushed
24af4f7c7118: Pushed
6d6a6425aacb: Pushed
333: digest: sha256:dae8cf914ba49928e6f0a34f6740802403813e6d10aa1c1d448a62ce9bb69066 size: 1779

Output of 2nd push command:

Pushing to google container registry ...
The push refers to a repository [gcr.io/projid/imgname]
24af4f7c7118: Preparing
17b0972980d8: Preparing
6d6a6425aacb: Preparing
809c8c0dd73c: Preparing
e8d45b8ab3ca: Preparing
e8fa134cb7b8: Preparing
7cbcbac42c44: Preparing
e8fa134cb7b8: Waiting
7cbcbac42c44: Waiting
e8d45b8ab3ca: Layer already exists
809c8c0dd73c: Layer already exists
24af4f7c7118: Layer already exists
17b0972980d8: Layer already exists
6d6a6425aacb: Layer already exists
7cbcbac42c44: Layer already exists
e8fa134cb7b8: Layer already exists
latest: digest: sha256:4f57375919829982741d095f8917306fe0c1410e115d030179bae4b8e4299c30 size: 1742

Question: Why the same image with two tags results in two different images in google container registry?

  • 1
    This looks like a bug in gcr.io to me, perhaps a race condition or a nonstandard way to compute the manifest digest. The layers are the same, meta data should be identical, so both tags should receive the same RepoDigests. Just to double check, the values of projid and imgname are identical, only the portion after the colon vary, correct? – BMitch May 4 '17 at 3:19
  • 1
    I found that I could avoid different image hashes in gcr.io by using gcloud container images add-tag to add tags to images. – David Sep 7 '17 at 23:28
  • Same problem here. Even doing docker push image:t1, docker push image:t1 image:t2 i.e. explicitly push the exact same image tagged t1 to tag t2, results in tag t1 and tag t2 on different images. Generally repeating the same operation again fixes things. – Raman Aug 7 at 4:35
1

With saying two different images are you referring to two different digest values?

SHA stands for Secure Hash Algorithm and it is a family of cryptographic hash functions and SHA-256 algorithm generates an almost-unique, fixed size 256-bit (32-byte) hash. Since the image tag is also being used to calculate the digest, the value of digest will be changed significantly even only one bit of the tag changes. In cryptography, this called avalanche effect and you can read more about it in here.

enter image description here

| improve this answer | |
1

You are certainly pushing two image tags. I suggest building with a single tag, then adding the second one and pushing the image tags one by one. If the second one adds a new digest is a GCR bug. I have ran into this bug and solved by deleting the repository so it gets re-created at the next push. In my configuration the Docker version was also a factor. Version 17.04.0-ce, build 4845c56 would trigger the extra digest while version 17.03.1-ce, build c6d412e would work fine.

| improve this answer | |
0

One thing to check is to compare the manifests of the two images. For example:

docker manifest inspect <image>

or

skopeo inspect --raw docker://image

If you diff the JSON output of those commands between the two images that should be the same but are not, it might give you some insight into the underlying problem.

For example, in my case, it turns out that it was a bug in my image build tool (buildah, via podman), in which two of the image layers had an incorrect media type of application/vnd.docker.image.rootfs.diff.tar.gzip, when in fact the correct media type was application/vnd.docker.image.rootfs.diff.tar.

Furthermore, podman was (helpfully?) correcting the media type when it pushed the same image with a different tag, so the container registry was actually ending up with the tags on two different "images".

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.