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.
Related
[Edit: It looks like my specific question is how to push a multi-stage Docker build to Heroku]
I'm trying to set up a NLP server using the spacy-api-docker Github repository.
The project README lists a base image (jgontrum/spacyapi:base_v2) with no included language models as well an English language model image (jgontrum/spacyapi:en_v2) which is what I'm looking for.
When I pull and run the English language image the localhost API works perfectly, but when I try to build an image from the cloned Github repository the main Dockerfile seems to only build the base model (which is useless), and when I follow the steps listed in this heroku docker documentation and this other third party tutorial to push the container to Github it only seems to use that base Dockerfile - I can get the api running but it's useless with no models.
The repository also has a bunch of shorter language-specific Dockerfiles in a subfolder which I'm guessing need to be specified in some way? Just sticking the english Dockerfile after the main Dockerfile didn't work, at any rate.
My guess is that I might have to:
a. figure out how to push an image from Docker hub to Heroku without
a repository (the only image that's worked completely I pulled
directly from docker)
b. figure out how to make a repository from a
pulled image, which I can then make into a Heroku project with heroku
create
c. figure out how to specify the :en_v2 part when I build to
Heroku from the repository (is that a Docker tag? does it somehow
specify which additional Dockerfile to use?)
d. look into multi-stage Docker builds
I'm new to programming and have been banging my head against this for a while now, so would be very grateful for any pointers (and please pardon any terms I've used poorly, my vocabulary is pretty basic for this stuff).
Thanks!
What I can help you is just show sample code if just you wanna know how to setup multistage build and how to build.
I'm also using multistage build on Docker because several containers are required on this system and just show you related source code as below.
multistage build on Dockerfile
https://github.com/hiromaily/go-goa/blob/master/docker/Dockerfile.multistage.heroku
how to deploy to Heroku from travis-ci in my case
https://github.com/hiromaily/go-goa/blob/master/.travis.yml
I didn't read carefully, so if I miss that point, please ignore me.
I want to keep the images that I used in my docker hub account while maintaining reference to the pulled image. Something like when you fork a project in github.
Currently I have tried jwilder/nginx-proxy image. Now that I am satisfied with it, I committed the working container to username/nginx-proxy image and push it.
The problem with this approach is it is like a fresh image and it doesn't show the layer from jwilder/nginx-proxy. No documentation or even Dockerfile.
If you push the image, there is no reference to the original, that behavior is normal. You can put that reference or link using your "repo info".
The Dockerfile is only shown if you did an automated build linking your github or bitbucket account and the push is automatically done based on the Dockerfile of your project.
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.
I know that Docker hub is there but it allows only for 1 private repository. Can I put these images on Github/Bitbucket?
In general you don't want to use version control on large binary images (like videos or compiled files) as git and such was intended for 'source control', emphasis on the source. Technically, here's nothing preventing you from doing so and putting the docker image files into git (outside the limits of the service you're using).
One major issue you'll have is git/bitubucket have no integration with Docker as neither provide the Docker Registry api needed for a docker host to be able to pull down the images as needed. This means you'll need to manually pull down out of the version control system holding the image files if you want to use it.
If you're going to do that, why not just use S3 or something like that?
If you really want 'version control' on your images (which docker hub does not do...) you'd need to look at something like: https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/
Finally, docker hub only allows one FREE private repo. You can pay for more.
So the way to go is:
Create a repository on Github or Bitbucket
Commit and push your Dockerfile (with config files if necessary)
Create an automated build on Docker Hub which uses the Github / Bitbucket repo as source.
In case you need it all private you can self-host a git service like Gitlab or GOGS and of course you can also selfhost a docker registry service for the images.
Yes, since Sept. 2020.
See "Introducing GitHub Container Registry" from Kayla Ngan:
Since releasing GitHub Packages last year (May 2019), hundreds of millions of packages have been downloaded from GitHub, with Docker as the second most popular ecosystem in Packages behind npm.
Available today as a public beta, GitHub Container Registry improves how we handle containers within GitHub Packages.
With the new capabilities introduced today, you can better enforce access policies, encourage usage of a standard base image, and promote innersourcing through easier sharing across the organization.
Our users have asked for anonymous access for public container images, similar to how we enable anonymous access to public repositories of source code today.
Anonymous access is available with GitHub Container Registry today, and we’ve gotten things started today by publishing a public image of our own super-linter.
GitHub Container Registry is free for public images.
With GitHub Actions, publishing to GitHub Container Registry is easy. Actions automatically suggests workflows based for you based on your work, and we’ve updated the “Publish Docker Container” workflow template to make publishing straightforward.
GitHub is in the process of releasing something similar to ECR or Docker Hub. At the time of writing this, it's in Alpha phase and you can request access.
From GitHub:
"GitHub Package Registry is a software package hosting service, similar to npmjs.org, rubygems.org, or hub.docker.com, that allows you to host your packages and code in one place. You can host software packages privately or publicly and use them as dependencies in your projects."
https://help.github.com/en/articles/about-github-package-registry
I guess you are saying about docker images. You can setup your own private registry which will contain the docker images. If you are not pushing only dockerfiles, but are interested in pushing the whole image, then pushing the images as a whole to github is a very bad idea. Consider a case you have 600 MB of docker image, pushing it to github is like putting 600 MB of data to a github repo, and if you keep on pushing more images there, it will get terribly bad.
Also, docker registry does the intelligent mapping of storing only a single copy of a layer (this layer can be referenced by multiple images). If you use github, you are not going to use this use-case. You will end up storing multiple copies of large files which is really really bad.
I would definitely suggest you to go with a private docker registry rather than going with github.
If there is a real need of putting docker image to github/bitbucket you can try to save it into archive (by using https://docs.docker.com/engine/reference/commandline/save/) and commit/push it to your repository.
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.