mirror of https://github.com/docker/docs.git
trusted-content: restructure doi section
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
This commit is contained in:
David Karlsson
parent
4b74397d7a
commit
c09ec313e2
|
|
@ -114,6 +114,7 @@ Wasm
|
|||
Windows
|
||||
Zsh
|
||||
[Bb]uildx
|
||||
[Cc]odenames?
|
||||
[Cc]ompose
|
||||
[Dd]istros
|
||||
[Ff]ilepaths?
|
||||
|
|
@ -129,6 +130,7 @@ Zsh
|
|||
[Ss]andbox(ed)?
|
||||
[Ss]wappable
|
||||
[Ss]warm
|
||||
[Tt]oolchains?
|
||||
[Vv]irtualize
|
||||
[Ww]alkthrough
|
||||
cgroup
|
||||
|
|
@ -138,8 +140,8 @@ deserialization
|
|||
deserialize
|
||||
dockerignore
|
||||
firewalld
|
||||
g?libc
|
||||
gRPC
|
||||
glibc
|
||||
inotify
|
||||
iptables
|
||||
kubectl
|
||||
|
|
|
|||
|
|
@ -111,4 +111,4 @@ There are lots of resources available to help you write your `Dockerfile`.
|
|||
* There's a [complete guide to all the instructions](../../reference/dockerfile.md) available for use in a `Dockerfile` in the reference section.
|
||||
* To help you write a clear, readable, maintainable `Dockerfile`, we've also
|
||||
written a [Dockerfile best practices guide](../../develop/develop-images/dockerfile_best-practices.md).
|
||||
* If your goal is to create a new Docker Official Image, read [Docker Official Images](../../trusted-content/official-images.md).
|
||||
* If your goal is to create a new Docker Official Image, read [Docker Official Images](../../trusted-content/official-images/_index.md).
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ deleting files, are written to this writable container layer.
|
|||
|
||||
* [Dockerfile reference](../../reference/dockerfile.md)
|
||||
* [More about Automated builds](../../docker-hub/builds/index.md)
|
||||
* [Guidelines for creating Docker Official Images](../../trusted-content/official-images.md)
|
||||
* [Guidelines for creating Docker Official Images](../../trusted-content/official-images/_index.md)
|
||||
* [Best practices to containerize Node.js web applications with Docker](https://snyk.io/blog/10-best-practices-to-containerize-nodejs-web-applications-with-docker)
|
||||
* [More about base images](../../build/building/base-images.md)
|
||||
* [More on image layers and how Docker builds and stores images](../../storage/storagedriver/index.md).
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ image. When choosing an image, ensure it's built from a trusted source and keep
|
|||
it small.
|
||||
|
||||
Docker Hub has more than 8.3 million repositories. Some of these images are
|
||||
[Official Images](../trusted-content/official-images.md), which are published by
|
||||
[Official Images](../trusted-content/official-images/_index.md), which are published by
|
||||
Docker as a curated set of Docker open source and drop-in solution repositories.
|
||||
Docker also offers images that are published by
|
||||
[Verified Publishers](../trusted-content/dvp-program.md). These high-quality images
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ In the previous example, you can see two example results, `centos` and `ansible/
|
|||
The second result shows that it comes from the public repository of a user,
|
||||
named `ansible/`, while the first result, `centos`, doesn't explicitly list a
|
||||
repository which means that it comes from the top-level namespace for
|
||||
[Docker Official Images](../../../trusted-content/official-images.md).
|
||||
[Docker Official Images](../../trusted-content/official-images/_index.md).
|
||||
The `/` character separates a user's repository from the image name.
|
||||
|
||||
Once you've found the image you want, you can download it with `docker pull <imagename>`:
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ If you are using affected versions of runc, BuildKit, Moby, or Docker Desktop, m
|
|||
|
||||
If you are unable to update to an unaffected version promptly, follow these best practices to mitigate risk:
|
||||
|
||||
* Only use trusted Docker images (such as [Docker Official Images](../trusted-content/official-images.md)).
|
||||
* Only use trusted Docker images (such as [Docker Official Images](../trusted-content/official-images/_index.md)).
|
||||
* Don’t build Docker images from untrusted sources or untrusted Dockerfiles.
|
||||
* If you are a Docker Business customer using Docker Desktop and unable to update to v4.27.1, make sure to enable [Hardened Docker Desktop](../desktop/hardened-desktop/_index.md) features such as:
|
||||
* [Enhanced Container Isolation](../desktop/hardened-desktop/enhanced-container-isolation/_index.md), which mitigates the impact of CVE-2024-21626 in the case of running containers from malicious images.
|
||||
|
|
@ -116,7 +116,7 @@ the Text4Shell CVE in the vulnerability report. For detailed instructions, see [
|
|||
|
||||
### Docker Official Images impacted by CVE-2022-42889
|
||||
|
||||
A number of [Docker Official Images](../trusted-content/official-images.md) contain the vulnerable versions of
|
||||
A number of [Docker Official Images](../trusted-content/official-images/_index.md) contain the vulnerable versions of
|
||||
Apache Commons Text. The following lists Docker Official Images that
|
||||
may contain the vulnerable versions of Apache Commons Text:
|
||||
|
||||
|
|
@ -169,7 +169,7 @@ Log4j 2 CVE in the vulnerability report. For detailed instructions, see [Scan im
|
|||
|
||||
_Last updated December 2021_
|
||||
|
||||
A number of [Docker Official Images](../trusted-content/official-images.md) contain the vulnerable versions of
|
||||
A number of [Docker Official Images](../trusted-content/official-images/_index.md) contain the vulnerable versions of
|
||||
Log4j 2 CVE-2021-44228. The following table lists Docker Official Images that
|
||||
may contained the vulnerable versions of Log4j 2. We updated Log4j 2 in these images to the latest version. Some of these images may not be
|
||||
vulnerable for other reasons. We recommend that you also review the guidelines published on the upstream websites.
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
|
|
@ -1,95 +0,0 @@
|
|||
---
|
||||
description: Guidelines for Official Images on Docker Hub
|
||||
keywords: Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs,
|
||||
official,image, documentation
|
||||
title: Docker Official Images
|
||||
aliases:
|
||||
- /docker-hub/official_repos/
|
||||
- /docker-hub/official_images/
|
||||
---
|
||||
|
||||
The [Docker Official Images](https://hub.docker.com/search?q=&type=image&image_filter=official) are a
|
||||
curated set of Docker repositories hosted on Docker Hub.
|
||||
|
||||
These images provide essential base repositories that serve as the starting point for the majority of users.
|
||||
|
||||
These include operating systems such as [Ubuntu](https://hub.docker.com/_/ubuntu/) and [Alpine](https://hub.docker.com/_/alpine/), programming languages such as [Python](https://hub.docker.com/_/python) and [Node](https://hub.docker.com/_/node), and other essential tools such as [Redis](https://hub.docker.com/_/redis) and [MySQL](https://hub.docker.com/_/mysql).
|
||||
|
||||
The images are some of the [most secure images](https://www.docker.com/blog/enhancing-security-and-transparency-with-docker-official-images/) on Docker Hub. This is particularly important as Docker Official Images are some of the most popular on Docker Hub. Typically, Docker Official images have few or no vulnerabilities.
|
||||
|
||||
The images exemplify [`Dockerfile` best practices](/engine/userguide/eng-image/dockerfile_best-practices/) and provide clear documentation to serve as a reference for other `Dockerfile` authors.
|
||||
|
||||
Images that are part of this program have a special badge on Docker Hub making it easier for you to identify projects that are official Docker images.
|
||||
|
||||
|
||||
|
||||
## When to use Docker Official Images
|
||||
|
||||
If you are new to Docker, it's recommended you use the Docker Official Images in your
|
||||
projects. These images have clear documentation, promote best practices,
|
||||
and are designed for the most common use cases. Advanced users can
|
||||
review Docker Official Images as part of your `Dockerfile` learning process.
|
||||
|
||||
A common rationale for diverging from Docker Official Images is to optimize for
|
||||
image size. For instance, many of the programming language stack images contain
|
||||
a complete build toolchain to support installation of modules that depend on
|
||||
optimized code. An advanced user could build a custom image with just the
|
||||
necessary pre-compiled libraries to save space.
|
||||
|
||||
A number of language stacks such as
|
||||
[Python](https://hub.docker.com/_/python/) and
|
||||
[Ruby](https://hub.docker.com/_/ruby/) have `-slim` tag variants
|
||||
designed to fill the need for optimization. Even when these "slim" variants are
|
||||
insufficient, it's still recommended to inherit from an Official Image
|
||||
base OS image to leverage the ongoing maintenance work, rather than duplicating
|
||||
these efforts.
|
||||
|
||||
## Submitting feedback for Docker Official Images
|
||||
|
||||
All Docker Official Images contain a **User Feedback** section in their
|
||||
documentation which covers the details for that specific repository. In most
|
||||
cases, the GitHub repository which contains the Dockerfiles for an Official
|
||||
Repository also has an active issue tracker. General feedback and support
|
||||
questions should be directed to `#docker-library` on [Libera.Chat IRC](https://libera.chat).
|
||||
|
||||
## For content publishers
|
||||
|
||||
Docker, Inc. sponsors a dedicated team that's responsible for reviewing and
|
||||
publishing all content in Docker Official Images. This team works in
|
||||
collaboration with upstream software maintainers, security experts, and the
|
||||
broader Docker community.
|
||||
|
||||
While it's preferable to have upstream software authors maintaining their
|
||||
Docker Official Images, this isn't a strict requirement. Creating
|
||||
and maintaining images for Docker Official Images is a collaborative process. It takes
|
||||
place openly on GitHub where participation is encouraged. Anyone can provide
|
||||
feedback, contribute code, suggest process changes, or even propose a new
|
||||
Official Image.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Docker Official Images are an intellectual property of Docker.
|
||||
|
||||
### Creating a Docker Official Image
|
||||
|
||||
From a high level, an Official Image starts out as a proposal in the form
|
||||
of a set of GitHub pull requests. The following GitHub repositories detail the proposal requirements:
|
||||
|
||||
- [docker-library/official-images](https://github.com/docker-library/official-images)
|
||||
- [docker-library/docs](https://github.com/docker-library/docs)
|
||||
|
||||
The Docker Official Images team, with help from community contributors, formally
|
||||
review each proposal and provide feedback to the author. This initial review
|
||||
process may require a bit of back-and-forth before the proposal is accepted.
|
||||
|
||||
There are subjective considerations during the review process. These
|
||||
subjective concerns boil down to the basic question: "is this image generally
|
||||
useful?" For example, the [Python](https://hub.docker.com/_/python/)
|
||||
Docker Official Image is "generally useful" to the larger Python developer
|
||||
community, whereas an obscure text adventure game written in Python last week is
|
||||
not.
|
||||
|
||||
Once a new proposal is accepted, the author is responsible for keeping
|
||||
their images up-to-date and responding to user feedback. The Official
|
||||
Repositories team becomes responsible for publishing the images and
|
||||
documentation on Docker Hub. Updates to the Docker Official Image follow the same pull request process, though with less review. The Docker Official Images team ultimately acts as a gatekeeper for all changes, which helps mitigate the risk of quality and security issues from being introduced.
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
---
|
||||
description: Overview of Docker Official Images
|
||||
keywords: Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs,
|
||||
official,image, documentation
|
||||
title: Docker Official Images
|
||||
aliases:
|
||||
- /docker-hub/official_repos/
|
||||
- /docker-hub/official_images/
|
||||
---
|
||||
|
||||
The [Docker Official Images](https://hub.docker.com/search?q=&type=image&image_filter=official)
|
||||
are a curated set of Docker repositories hosted on Docker Hub.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Use of Docker Official Images is subject to [Docker's Terms of Service](https://www.docker.com/legal/docker-terms-service/).
|
||||
|
||||
These images provide essential base repositories that serve as the starting
|
||||
point for the majority of users.
|
||||
|
||||
These include operating systems such as
|
||||
[Ubuntu](https://hub.docker.com/_/ubuntu/) and
|
||||
[Alpine](https://hub.docker.com/_/alpine/), programming language runtimes such as
|
||||
[Python](https://hub.docker.com/_/python) and
|
||||
[Node](https://hub.docker.com/_/node), and other essential tools such as
|
||||
[memcached](https://hub.docker.com/_/memcached) and
|
||||
[MySQL](https://hub.docker.com/_/mysql).
|
||||
|
||||
The images are some of the [most secure images](https://www.docker.com/blog/enhancing-security-and-transparency-with-docker-official-images/)
|
||||
on Docker Hub. This is particularly important as Docker Official Images are
|
||||
some of the most popular on Docker Hub. Typically, Docker Official images have
|
||||
few or no packages containing CVEs.
|
||||
|
||||
The images exemplify [`Dockerfile` best practices](../../develop/develop-images/dockerfile_best-practices.md)
|
||||
and provide clear documentation to serve as a reference for other `Dockerfile` authors.
|
||||
|
||||
Images that are part of this program have a special badge on Docker Hub making
|
||||
it easier for you to identify projects that are part of Docker Official Images.
|
||||
|
||||
|
||||
|
||||
## In this section
|
||||
|
||||
{{% sectionlinks %}}
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
---
|
||||
title: Contributing to Docker Official Images
|
||||
description: |
|
||||
This article describes how Docker Official Images are created,
|
||||
and how you can contribute or leave feedback.
|
||||
keywords: docker official images, doi, contributing, upstream, open source
|
||||
---
|
||||
|
||||
Docker, Inc. sponsors a dedicated team that's responsible for reviewing and
|
||||
publishing all content in Docker Official Images. This team works in
|
||||
collaboration with upstream software maintainers, security experts, and the
|
||||
broader Docker community.
|
||||
|
||||
While it's preferable to have upstream software authors maintaining their
|
||||
Docker Official Images, this isn't a strict requirement. Creating
|
||||
and maintaining images for Docker Official Images is a collaborative process.
|
||||
It takes place [openly on GitHub](https://github.com/docker-library/official-images)
|
||||
where participation is encouraged. Anyone can provide feedback, contribute
|
||||
code, suggest process changes, or even propose a new Official Image.
|
||||
|
||||
## Creating a Docker Official Image
|
||||
|
||||
From a high level, an Official Image starts out as a proposal in the form
|
||||
of a set of GitHub pull requests. The following GitHub repositories detail the proposal requirements:
|
||||
|
||||
- [Docker Official Images repository on GitHub](https://github.com/docker-library/official-images#readme)
|
||||
- [Documentation for Docker Official Images](https://github.com/docker-library/docs#readme)
|
||||
|
||||
The Docker Official Images team, with help from community contributors, formally
|
||||
review each proposal and provide feedback to the author. This initial review
|
||||
process can be lengthy, often requiring a bit of back-and-forth before the proposal is accepted.
|
||||
|
||||
There are subjective considerations during the review process. These
|
||||
subjective concerns boil down to the basic question: "is this image generally
|
||||
useful?" For example, the [Python](https://hub.docker.com/_/python/)
|
||||
Docker Official Image is "generally useful" to the larger Python developer
|
||||
community, whereas an obscure text adventure game written in Python last week is
|
||||
not.
|
||||
|
||||
Once a new proposal is accepted, the author is responsible for keeping their
|
||||
images and documentation up-to-date and responding to user feedback. Docker is
|
||||
responsible for building and publishing the images on Docker Hub. Updates to
|
||||
Docker Official Images follow the same pull request process as for new images,
|
||||
although the review process for updates is more streamlined. The Docker Official
|
||||
Images team ultimately acts as a gatekeeper for all changes, which helps
|
||||
ensures consistency, quality, and security.
|
||||
|
||||
## Submitting feedback for Docker Official Images
|
||||
|
||||
All Docker Official Images contain a **User Feedback** section in their
|
||||
documentation which covers the details for that specific repository. In most
|
||||
cases, the GitHub repository which contains the Dockerfiles for an Official
|
||||
Image also has an active issue tracker.
|
||||
|
||||
General feedback and support questions about Docker Official Images
|
||||
should be directed to the `#general` channel in the [Docker Community Slack](https://dockr.ly/comm-slack).
|
||||
|
||||
If you're a maintainer or contributor to Docker Official Images and you're
|
||||
looking for help or advice, use the `#docker-library` channel on [Libera.Chat IRC](https://libera.chat).
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
title: Using Docker Official Images
|
||||
description: |
|
||||
Learn about building applications with Docker Official images
|
||||
and how to interpret the tag names they use.
|
||||
keywords: docker official images, doi, tags, slim, feedback, troubleshooting
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Docker recommends you use the Docker Official Images in your projects.
|
||||
These images have clear documentation, promote best practices, and are regularly updated.
|
||||
Docker Official Images support most common use cases, making them perfect for new Docker users.
|
||||
Advanced users can benefit from more specialized image variants as well as review Docker Official Images as part of your `Dockerfile` learning process.
|
||||
|
||||
## Tags
|
||||
|
||||
The repository description for each Docker Official Image contains a
|
||||
**Supported tags and respective Dockerfile links** section that lists all the
|
||||
current tags with links to the Dockerfiles that created the image with those
|
||||
tags. The purpose of this section is to show what image variants are available.
|
||||
|
||||
|
||||
|
||||
Tags listed on the same line all refer to the same underlying image. Multiple
|
||||
tags can point to the same image. For example, in the previous screenshot taken
|
||||
from the `ubuntu` Docker Official Images repository, the tags `24.04`,
|
||||
`noble-20240225`, `noble`, and `devel` all refer to the same image.
|
||||
|
||||
The `latest` tag for a Docker Official Image is often optimized for ease of use
|
||||
and includes a wide variety of useful software, such as developer and build tools.
|
||||
By tagging an image as `latest`, the image maintainers are essentially suggesting
|
||||
that image be used as the default. In other words, if you do not know what tag to
|
||||
use or are unfamiliar with the underlying software, you should probably start with
|
||||
the `latest` image. As your understanding of the software and image variants advances,
|
||||
you may find other image variants better suit your needs.
|
||||
|
||||
## Slim images
|
||||
|
||||
A number of language stacks such as
|
||||
[Node.js](https://hub.docker.com/_/node/),
|
||||
[Python](https://hub.docker.com/_/python/), and
|
||||
[Ruby](https://hub.docker.com/_/ruby/) have `slim` tag variants
|
||||
designed to provide a lightweight, production-ready base image
|
||||
with fewer packages.
|
||||
|
||||
A typical consumption pattern for `slim`
|
||||
images is as the base image for the final stage of a
|
||||
[multi-staged build](https://docs.docker.com/build/building/multi-stage/).
|
||||
For example, you build your application in the first stage of the build
|
||||
using the `latest` variant and then copy your application into the final
|
||||
stage based upon the `slim` variant. Here is an example `Dockerfile`.
|
||||
|
||||
```dockerfile
|
||||
FROM node:latest AS build
|
||||
WORKDIR /app
|
||||
COPY package.json package-lock.json ./
|
||||
RUN npm ci
|
||||
COPY . ./
|
||||
FROM node:slim
|
||||
WORKDIR /app
|
||||
COPY --from=build /app /app
|
||||
CMD ["node", "app.js"]
|
||||
```
|
||||
|
||||
## Alpine images
|
||||
|
||||
Many Docker Official Images repositories also offer `alpine` variants. These
|
||||
images are built on top of the [Alpine Linux](https://www.alpinelinux.org/)
|
||||
distribution rather than Debian or Ubuntu. Alpine Linux is focused on providing
|
||||
a small, simple, and secure base for container images, and Docker Official
|
||||
Images `alpine` variants typically aim to install only necessary packages. As a
|
||||
result, Docker Official Images `alpine` variants are typically even smaller
|
||||
than `slim` variants.
|
||||
|
||||
The main caveat to note is that Alpine Linux uses [musl libc](https://musl.libc.org/)
|
||||
instead of [glibc](https://www.gnu.org/software/libc/). Additionally, to
|
||||
minimize image size, it's uncommon for Alpine-based images to include tools
|
||||
such as Git or Bash by default. Depending on the depth of libc requirements or
|
||||
assumptions in your programs, you may find yourself running into issues due to
|
||||
missing libraries or tools.
|
||||
|
||||
When you use Alpine images as a base, consider the following options in order
|
||||
to make your program compatible with Alpine Linux and musl:
|
||||
|
||||
- Compile your program against musl libc
|
||||
- Statically link glibc libraries into your program
|
||||
- Avoid C dependencies altogether (for example, build Go programs without CGO)
|
||||
- Add the software you need yourself in your Dockerfile.
|
||||
|
||||
Refer to the `alpine` image [description](https://hub.docker.com/_/alpine) on
|
||||
Docker Hub for examples on how to install packages if you are unfamiliar.
|
||||
|
||||
## Codenames
|
||||
|
||||
Tags with words that look like Toy Story characters (for example, `bookworm`,
|
||||
`bullseye`, and `trixie`) or adjectives (such as `focal`, `jammy`, and
|
||||
`noble`), indicate the codename of the Linux distribution they use as a base
|
||||
image. Debian release codenames are [based on Toy Story characters](https://en.wikipedia.org/wiki/Debian_version_history#Naming_convention),
|
||||
and Ubuntu's take the form of "Adjective Animal". For example, the
|
||||
codename for Ubuntu 24.04 is "Noble Numbat".
|
||||
|
||||
Linux distribution indicators are helpful because many Docker Official Images
|
||||
provide variants built upon multiple underlying distribution versions (for
|
||||
example, `postgres:bookworm` and `postgres:bullseye`).
|
||||
|
||||
## Other tags
|
||||
|
||||
Docker Official Images tags may contain other hints to the purpose of
|
||||
their image variant in addition to those described here. Often these
|
||||
tag variants are explained in the Docker Official Images repository
|
||||
documentation. Reading through the “How to use this image” and
|
||||
“Image Variants” sections will help you to understand how to use these
|
||||
variants.
|
||||
|
|
@ -2208,8 +2208,14 @@ Manuals:
|
|||
section:
|
||||
- path: /trusted-content/
|
||||
title: Overview
|
||||
- path: /trusted-content/official-images/
|
||||
title: Docker Official images
|
||||
- sectiontitle: Docker Official Images
|
||||
section:
|
||||
- path: /trusted-content/official-images/
|
||||
title: Overview
|
||||
- path: /trusted-content/official-images/using/
|
||||
title: Using official images
|
||||
- path: /trusted-content/official-images/contributing/
|
||||
title: Contributing
|
||||
- path: /trusted-content/dvp-program/
|
||||
title: Docker Verified Publisher Program
|
||||
- path: /trusted-content/dsos-program/
|
||||
|
|
|
|||
Loading…
Reference in New Issue