The Docker Official Images are curated images hosted on Docker Hub. The main tenets are:
Focus on Free and Open-Source Software
Support multiple architectures
Exemplify Dockerfile best practices
Actively rebuild for updates and security fixes
Adhere to upstream recommendations
Add minimal quality-of-life behavior for the container environment where fit
See Docker's documentation for a good high-level overview of the program.
In essence we strive to heed upstream's recommendations on how they intend for their software to be consumed. Many images are maintained in collaboration with the relevant upstream project if not maintained directly by them. Additionally we aim to exemplify the best practices for Dockerfiles to serve as a reference when making or deriving your own images from them.
(If you are a representative of an upstream for which there exists an image and you would like to get involved, please see the Maintainership section below!)
Some images have been ported for other architectures, and many of these are officially supported (to various degrees).
arm32v6): https://hub.docker.com/u/arm32v6/arm32v7): https://hub.docker.com/u/arm32v7/arm64v8): https://hub.docker.com/u/arm64v8/amd64): https://hub.docker.com/u/amd64/windows-amd64): https://hub.docker.com/u/winamd64/arm32v5): https://hub.docker.com/u/arm32v5/ppc64le): https://hub.docker.com/u/ppc64le/s390x): https://hub.docker.com/u/s390x/riscv64): https://hub.docker.com/u/riscv64/i386): https://hub.docker.com/u/i386/These other architectures are included under the non-prefixed images via OCI "image indexes", such that, for example, docker run hello-world should run as-is on all supported platforms.
If you're curious about how these are built, head over to our FAQ entry to see an explanation of the process or visit meta-scripts to see the build process source files.
See the multi-arch section below for recommendations in adding more architectures to an official image.
Yes! We have a dedicated FAQ repository where we try to collect other common questions (both about the program and about our practices).
Thank you for your interest in the Docker official images project! We strive to make these instructions as simple and straightforward as possible, but if you find yourself lost, don't hesitate to seek us out on Libera.Chat IRC in channel #docker-library or by creating a GitHub issue here.
Be sure to familiarize yourself with Official Repositories on Docker Hub and the Best practices for writing Dockerfiles in the Docker documentation. These will be the foundation of the review process performed by the official images maintainers. If you'd like the review process to go more smoothly, please ensure that your Dockerfiles adhere to all the points mentioned there, as well as below, before submitting a pull request.
Also, the Hub descriptions for these images are currently stored separately in the docker-library/docs repository, whose README.md file explains more about how it's structured and how to contribute to it. Please be prepared to submit a PR there as well, pending acceptance of your image here.
Because the official images are intended to be learning tools for those new to Docker as well as the base images for advanced users to build their production releases, we review each proposed Dockerfile to ensure that it meets a minimum standard for quality and maintainability. While some of that standard is hard to define (due to subjectivity), as much as possible is defined here, while also adhering to the "Best Practices" where appropriate.
A checklist which may be used by the maintainers during review can be found in NEW-IMAGE-CHECKLIST.md.
Version bumps and security fixes should be attended to in a timely manner.
If you do not represent upstream and upstream becomes interested in maintaining the image, steps should be taken to ensure a smooth transition of image maintainership over to upstream.
For upstreams interested in taking over maintainership of an existing repository, the first step is to get involved in the existing repository. Making comments on issues, proposing changes, and making yourself known within the "image community" (even if that "community" is just the current maintainer) are all important places to start to ensure that the transition is unsurprising to existing contributors and users.
When taking over an existing repository, please ensure that the entire Git history of the original repository is kept in the new upstream-maintained repository to make sure the review process isn't stalled during the transition. This is most easily accomplished by forking the new from the existing repository, but can also be accomplished by fetching the commits directly from the original and pushing them into the new repo (ie, git fetch https://github.com/jsmith/example.git master, git rebase FETCH_HEAD, git push -f). On GitHub, an alternative is to move ownership of the git repository. This can be accomplished without giving either group admin access to the other owner's repository:
Rebuilding the same Dockerfile should result in the same version of the image being packaged, even if the second build happens several versions later, or the build should fail outright, such that an inadvertent rebuild of a Dockerfile tagged as 0.1.0 doesn't end up containing 0.2.3. For example, if using apt to install the main program for the image, be sure to pin it to a specific version (ex: ... apt-get install -y my-package=0.1.0 ...). For dependent packages installed by apt there is not usually a need to pin them to a version.
No official images can be derived from, or depend on, non-official images (allowing the non-image scratch and the intentionally limited exceptions pinned in .external-pins -- see also .external-pins/list.sh).
All official images should provide a consistent interface. A beginning user should be able to docker run official-image bash (or sh) without needing to learn about --entrypoint. It is also nice for advanced users to take advantage of entrypoint, so that they can docker run official-image --arg1 --arg2 without having to specify the binary to execute.
If the startup process does not need arguments, just use CMD:
Dockerfile
CMD ["irb"]
If there is initialization that needs to be done on start, like creating the initial database, use an ENTRYPOINT along with CMD:
Dockerfile
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["postgres"]
Ensure that docker run official-image bash (or sh) works too. The easiest way is to check for the expected command and if it is something else, just exec "$@" (run whatever was passed, properly keeping the arguments escaped).
```sh
set -e
if [ "$#" -eq 0 ] || [ "${1#-}" != "$1" ]; then set -- mongod "$
| 日期 | 榜单 | 排名 | 周期新增 | 总 STAR |
|---|