I am just curious is there any way to pass message in docker push or any docker command which can be seen in docker hub like git commit -m "...".
I want to maintain an docker image which can be used with specific versions of application code so I have to write small message for each version of container about supported code version.
No, you could link your dockerhub repository with github, create release on github per tag and explain changes.
i.e.
Rancher server: https://hub.docker.com/r/rancher/rancher/tags & https://github.com/rancher/rancher/releases
Related
I have damaged my working docker image by pushing and overwriting by a faulty docker image on hub.docker.com. How can I revert the last push?
There is no revert option that I'm aware of. If you have a good copy of your image somewhere, you can repush that to the registry. To avoid this issue in the future, follow one or more of these steps:
Avoid using the latest tag and give each build a unique tag.
Use a reproducible build process with a Dockerfile that is saved in version control which uses specific versions for all dependencies. This allows you to checkout a previous state of the Dockerfile to rerun a previous build.
Maintain a private registry of your own for your images and any dependencies you have on other images. Make sure to maintain those dependencies (updating periodically) and backup your registry.
You can use the Advanced Image Management page in docker hub to copy the digest of the good image, pull it to your system, overwrite the tag, then push back. Use these commands:
docker image pull myname/example#sha256:1234
docker tag myname/example#sha256:1234 myname/example:mytag
docker push myname/example:mytag
Assuming myname/example#sha256:1234 is your copied digest of the good image from docker hub, myname/example:mytag is what you want to tag the image as.
I am quite newbie in docker, and I am trying to find the way to tell version for a docker hub tagged image.
For instance, the jenkins/jenkins:lts-latest image, listed here https://hub.docker.com/r/jenkins/jenkins/tags/, what image version does actually aliase? And how can I infer the correspondent dockerfile/branch in jenkins repo?
I tried with docker search but I couldn't. I tried also to find a clue in the official Jenkins github dockerfile repo: https://github.com/jenkinsci/docker, but I don't see any bindung tag or anything that gives me a hint on the source of the image
Another example, I have a Kubernetes cluster, and when I check my Nexus pod, I see likewise that the image is defined as sonatype/nexus3:latest.
In this case at least I have the imageID: docker-pullable://sonatype/nexus3#sha256:434a2564aa64646464afaf.. but once again I don't know how to map it to the actual version of the software
For the repo you asked, the answer is No.
When setup repo on dockerhub, there are two kinds of options for user to choose as follows:
1) Create Repository:
In this way, dockerhub just create a repo for user, and user need to build his own image on local server, tag it, and push it to dockerhub.
When user push his image to dockerhub, no additional information about the source version will be appended, so can't get any source map from dockerhub.
jenkins/jenkins, just this kind of repo.
2) Create Automated Build
In this way, dockerhub will fetch the code from github or bitbucket, and build the image on its cloud infrastructure, so it will know exactly what source commit is for current docker image.
jenkins/jnlp-slave, just this kind of repo.
Then, you can click its Build Details on the web page, click into one link, e.g. 3.26-1-alpine, you will see log mentioned 0a0239228bf2fd26d2458a91dd507e3c564bc7d0 is the source commit.
To sum up, for the repo you mentioned in the question, they are not Automated Build, so you cannot get the map for the image & source code, but if you happen to find a repo in dockerhub which is Automated Build later & want to know the map, then you can.
As long as I understand your question, you are trying to tag the docker image exact with same version as of your software version. For that I use to create image tag:
$ export VERSION="2.31-b19"
$ docker tag "<user>/<image>:${VERSION}" "<docker_hub_user>/<repo>:latest"
If this is not the case. Please explain your use case a bit more so that we can provide you a better workaround.
I would like to publish docker images tagged with both semantic versions (like version 1.0) and also build numbers (like build 3). Operationally this might come about in the following way:
docker build -t my-project:1.0-1
# make minor changes to docker file
docker build -t my-project:1.0-2
# make minor changes to docker file
docker build -t my-project:1.0-3
# release new version of project
docker build -t my-project:1.1-1
I would expect some users to pin to particular build numbers
docker pull my-project:1.0-2
While other users would just ask for "the lastest of version 1.0"
docker pull my-project:1.0
Does this work? Is there a better way to accomplish this goal?
Yes, this works. A tag is just a friendly name attached to an image ID. Any given image can have as many tags as you would realistically want.
docker tag myproject my-project:1.0-2
docker tag myproject my-project:1.0
Then, if you docker images and find these tags, you'll see that the IMAGE ID for both tags is the same. Keep in mind you'd want to push both tagged images to your repository.
Looking at a couple of popular Docker Hub repos for inspiration:
ruby, python, postgres
Docker Hub builds a Syncthing image for me from this source repo.
I tagged the latest commit v0.13.5, but Docker built it twice: once for latest and once for v0.13.5.
Why? Shouldn't it be able to figure out the source is the same? Am I just doing something dumb in my Dockerfile, breaking caching? Is there some way I need to hint to Docker Hub that this should really be two images with the same checksum but different tags?
I'm thinking of the two Docker image tags latest and v0.13.5 like two git tags both pointing to the same commit. Shouldn't Docker Hub work that way too? If someone tries to pull latest they'd pull exactly the same image tagged v0.13.5? I know how to pull/re-tag/push, but again, seems like there just must be some way to get Docker Hub to do this automatically.
Build settings:
With a little magic, Docker Hub can do this! Pablo Chico de Guzmán helped me out.
Steps:
add a file called hooks/post_push
make hooks/post_push executable, commit and push
delete the "Branch" build, but leave the "Tag" build in place
Now, any tags I push (e.g. git push --tags) fire off an automated build, and the same image is also given the latest tag.
Here's the change I had to make so the most recent "vX.Y"-tagged meonkeys/syncthing image is also tagged latest.
Latest is just “the last build/tag that ran without a specific tag/version specified”.
If you push a tagged image it does not replace the current image tagged with latest. If you push tagged images only, latest tag is not added.
Automated Builds on Docker Hub is adding the latest tag automatically for the master branch.
Is there a way to clone a Dockerfile from GitLab with the docker command?
I want to use the feature that allow pull and commit.
I am not sure if I have understand well but these pull and commit update the Dockerfile from the git repositories ? Or is it only locally in the next images ?
If not, is there a way to get all the change you made from the previous image made by the Dockerfile into another Dockerfile ?
I know you can clone with Git directly, but like for npm, you can also use Git url like git+https:// or git+ssh://
The pull/commit commands affect the related image and operate directly against your configured registry, which is the official Docker Hub Registry unless configured otherwise. Perhaps some confusion may arise from the registry's support for Automated Builds, where the registry is directly bound to a repository and rebuilds the image every time the targeted repository branch changes.
If you wish to reuse someone's Docker image, the best approach is to simply reference it via the FROM instruction in your Dockerfile and effectively fork the image. While it's certainly possible to clone the original source repository and continue editing the Dockerfile contained therein, you usually do not want to go down that path.
So if there exists such a foo/bar image you want to continue building upon, the best, most direct approach to do so is to create your own Dockerfile, inherit the image by setting it as a base for your succeeding instructions via FROM foo/bar and possibly pushing your baz/bar image back into the registry if you want it to be publicly available for others to re-base upon.