Docker Hub - pull fake image - docker

I trying to play a bit with the Sigstore's cosign tool.
The tool is signing the image and then uploading the signature to the same repository.
So if I have a tag - tool:latest and I sign it, the tool creates a new tag named - <digest_of_latest>.sig
I want to somehow download that tag's data, but if I try to docker pull - I get an error that docker cannot load the image (which is right, this is not real image).
is there a way to download the raw data file from the docker hub repository ?

Related

Check for new docker image version without pull

I know Watchtower (https://github.com/v2tec/watchtower), but would like to understand if there is a way that I check for docker image updates without pull (downloading it)
I seems that if I ie. use docker pull pihole:latest it download the image, no matter if it the newest or already on my device.
I would like to get the digest or image id from the docker hub, so I can compare it with my local image id

.NetCore Api Docker Image is not working when pulled from DockerHub

Created a .net core (3.1) API which depends on MongoDB and created a docker image for this project (which is working fine in my system). I am pushing this image to a private repository.
When pulling the image from another system/host/machine, The image is not working and giving error exited with code 0
I am very new to Docker and not finding how to pull the image to a new system and start using it.
Below are the steps I did.
Using Docker-Compose.yml to create supported images.
these are the images created in my system.
Commands I am using to tag the image and push
docker tag 9aa28f48b025 myusername/reponame
docker push myusername/reponame
Commands I am using to pull in another system.
docker login -- (using credentials)
docker pull myusername/reponame
Is my understanding of reusing images wrong? Any reference or suggestion will be a great help

Docker image layer verification

I need to know about offline usage of a registry for docker images.
When a docker image is pulled from the official microsoft site, adjusted, and then pushed to a registry, is it the complete image or are layers missing?
When other hosts pull the image from the registry, which might be used offline, will the client host need an internet connection nonetheless to pull missing/secret layers from the microsoft server? (or is it a full image that was pulled from microsoft and later pushed to the registry?)
What about signatures? Will those get updated automatically for each layer, when the image gets adjusted, applications stored within, etc., so that there are no verification errors when other clients pull the adjusted image from the local registry?
When you build an image from another image docker download the base image locally to your computer you can even save it as a file.
When you push an image to local registry it pushed the complete image including the base image it was built from.
When someone will try to pull the new image from your local registry they won't be needing internet access.

Pulling Docker Images - Manifest not found

I'm trying to download a tagged docker image
docker pull clkao/postgres-plv8:10-2
and, in a compose file,
postgres:
image: clkao/postgres-plv8:10-2
But receive a manifest not found exception.
Unless I'm mistaken, that tag exists in Docker Hub, however I notice that it doesn't appear on the tags list.
Am I doing something wrong? Or is this perhaps an issue with Docker Hub or the way that repo has been set up?
If it isn't 'my fault', what's a recommendation to move forward? Create my own Dockerfile perhaps?
You might also try
docker pull -a <image>.
The -a will pull all versions of that image, which at least lets you know what is there.
(This is less useful if you really need a specific version, but helped me when I tried to pull an image that for some reason did not have a 'latest' tag.)
Edit: This is actually a really bad idea, since it will pull down the entire history, which for many repositories could be many GB. Better to go look at the repository site and see what tag you want. Note to self: don't post answers when you are tired. :-(
You get the error message because there exist no tag with "10-2".
You can try to figure out why and contact the repository owner or you can try to build your own one.
I just got over this "manifest for / not found: manifest unknown: The named manifest is not known to the registry."
Using
docker login <repo>
Check the docker's image also not only that the tag exists, I was trying to run Flyway version 5.0.1 for an image flyway/flyway which version did not exist, it existed only in version flyway/flyway:latest it seems, whereas 5.0.1 existed and I pulled it but in/from a different repository name, with repository name boxfuse/flyway.
for the error message 'docker manifest unknown'
When you use docker pull, without a tag, it will default to the tag :latest. Make sure that when we are building a image add tag latest or we can access the image by the tag name after image name with colon
I think you are trying to tag your image as v8.10.2. Make sure while tagging image locally you use same tag which you want to pull in future. So steps will be like below:
docker build -t clkao/postgres-pl:v8.10.2 .
docker push clkao/postgres-pl:v8.10.2
docker pull clkao/postgres-pl:v8.10.2
If this is from Git via docker.pkg.github.com then you need to switch to use ghcr.io. The former is deprecated and does not support the manifest endpoint so some docker clients, when they attempt to download various resources, fail with this error message. If you instead publish your image to ghcr (Github Container Repository), the docker image pulling process should complete successfully.
cd <dir with Dockerfile in it>
docker build -f Dockerfile -t ghcr.io/<org_id>/<project_id>:<version> .
docker push ghcr.io/<org_id>/<project_id>:<version>
More info here: https://docs.github.com/en/packages/working-with-a-github-packages-registry/migrating-to-the-container-registry-from-the-docker-registry
Note: The Container registry is currently in public beta and subject
to change. During the beta, storage and bandwidth are free. To use the
Container registry, you must enable the feature preview. For more
information, see "Introduction to GitHub Packages" and "Enabling
improved container support with the Container registry."

How to prevent docker images on docker hub from being overwritten?

Is there any way to prevent images being uploaded to docker hub with the same tags as existing images? Our use case is as follows.
We deploy to production with a docker-compose file with the tags of images as version numbers. In order to support roll-back to previous environments and idempotent deployment it is necessary that a certain tagged docker image always refer to the same image.
However, docker hub allows images to be uploaded with the same tags as existing images (they override the old image). This completely breaks the idea of versioning your images.
We currently have work-arounds which involve our build scripts pulling all versions of an image and looking through the tags to check that an overwrite will not happen etc. but it feels like there has to be a better way.
If docker hub does not support this, is there a way to do docker deployment without docker hub?
The tag system has no way of preventing images been overwritten; you have to come up with your own processes to handle this (and h3nrik's answer is an example of this).
However, you could use the digest instead. In the new v2 of the registry, all images are given a checksum, known as a digest. If an image or any of its base layers change, the digest will change. So if you pull by digest, you can be absolutely certain that the contents of that image haven't changed over time and that the image hasn't been tampered with.
Pulling by digest looks like:
docker pull debian#sha256:f43366bc755696485050ce14e1429c481b6f0ca04505c4a3093dfdb4fafb899e
You should get the digest when you do a docker push.
Now, I agree that pulling by digest is a bit unwieldy, so you may want to set up a system that simply tracks digest and tag and can verify that the image hasn't changed.
In the future, this situation is likely to improve, with tools like Notary for signing images. Also, you may want to look at using labels to store metadata such as git hash or build number.
Assuming you have a local build system to build your Docker images: you could include the build number from your local build job in your tag. With that you assure your requirement:
... it is necessary that a certain tagged docker image always refer to the same image.
When your local build automatically pushes to docker hub it is assured that each push pushes an image with a unique tag.

Resources