remove references to EOL distros and images (#22674)

- replace some examples using EOL alpine versions
- replace some examples using EOL ubuntu versions

<!--Delete sections as needed -->

## Description

<!-- Tell us what you did and why -->

## Related issues or tickets

<!-- Related issues, pull requests, or Jira tickets -->

## Reviews

<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->

- [ ] Technical review
- [ ] Editorial review
- [ ] Product review

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn 2025-05-21 08:52:04 +02:00 committed by GitHub
parent 21a5f64c7f
commit 196062f3a1
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
8 changed files with 27 additions and 27 deletions

View File

@ -41,7 +41,7 @@ COPY . .
RUN go build -o /app .
# Final lightweight stage
FROM alpine:3.17 AS final
FROM alpine:3.21 AS final
# Copy the compiled binary from the builder stage
COPY --from=builder /app /bin/app
@ -63,7 +63,7 @@ The Dockerfile consists of two stages:
2. **Final stage**: This stage uses the official Alpine image as the base and copies the compiled binary from the build stage. It also exposes the application's port and runs the application.
You use the `alpine:3.17` image as the base image for the final stage. You copy the compiled binary from the build stage to the final image. You expose the application's port using the `EXPOSE` instruction and run the application using the `CMD` instruction.
You use the `alpine:3.21` image as the base image for the final stage. You copy the compiled binary from the build stage to the final image. You expose the application's port using the `EXPOSE` instruction and run the application using the `CMD` instruction.
Apart from the multi-stage build, the Dockerfile also follows best practices such as using the official images, setting the working directory, and copying only the necessary files to the final image. You can further optimize the Dockerfile by other best practices.

View File

@ -102,17 +102,17 @@ which you can also use to build Ubuntu images.
For example, to create an Ubuntu base image:
```dockerfile
$ sudo debootstrap focal focal > /dev/null
$ sudo tar -C focal -c . | docker import - focal
$ sudo debootstrap noble noble > /dev/null
$ sudo tar -C noble -c . | docker import - noble
sha256:81ec9a55a92a5618161f68ae691d092bf14d700129093158297b3d01593f4ee3
$ docker run focal cat /etc/lsb-release
$ docker run noble cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04 LTS"
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.2 LTS"
```
There are more example scripts for creating base images in

View File

@ -192,15 +192,15 @@ image. This is useful because it lets publishers update tags to point to
newer versions of an image. And as an image consumer, it means you
automatically get the new version when you re-build your image.
For example, if you specify `FROM alpine:3.19` in your Dockerfile, `3.19`
resolves to the latest patch version for `3.19`.
For example, if you specify `FROM alpine:3.21` in your Dockerfile, `3.21`
resolves to the latest patch version for `3.21`.
```dockerfile
# syntax=docker/dockerfile:1
FROM alpine:3.19
FROM alpine:3.21
```
At one point in time, the `3.19` tag might point to version 3.19.1 of the
At one point in time, the `3.21` tag might point to version 3.21.1 of the
image. If you rebuild the image 3 months later, the same tag might point to a
different version, such as 3.19.4. This publishing workflow is best practice,
and most publishers use this tagging strategy, but it isn't enforced.
@ -213,16 +213,16 @@ To fully secure your supply chain integrity, you can pin the image version to a
specific digest. By pinning your images to a digest, you're guaranteed to
always use the same image version, even if a publisher replaces the tag with a
new image. For example, the following Dockerfile pins the Alpine image to the
same tag as earlier, `3.19`, but this time with a digest reference as well.
same tag as earlier, `3.21`, but this time with a digest reference as well.
```dockerfile
# syntax=docker/dockerfile:1
FROM alpine:3.19@sha256:13b7e62e8df80264dbb747995705a986aa530415763a6c58f84a3ca8af9a5bcd
FROM alpine:3.21@sha256:a8560b36e8b8210634f77d9f7f9efd7ffa463e380b75e2e74aff4511df3ef88c
```
With this Dockerfile, even if the publisher updates the `3.19` tag, your builds
With this Dockerfile, even if the publisher updates the `3.21` tag, your builds
would still use the pinned image version:
`13b7e62e8df80264dbb747995705a986aa530415763a6c58f84a3ca8af9a5bcd`.
`a8560b36e8b8210634f77d9f7f9efd7ffa463e380b75e2e74aff4511df3ef88c`.
While this helps you avoid unexpected changes, it's also more tedious to have
to look up and include the image digest for base image versions manually each

File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 40 KiB

View File

@ -175,7 +175,7 @@ extract the full source code of the Dockerfile used to build the image:
```console
$ docker buildx imagetools inspect <namespace>/<image>:<version> \
--format '{{ range (index .Provenance.SLSA.metadata "https://mobyproject.org/buildkit@v1#metadata").source.infos }}{{ if eq .filename "Dockerfile" }}{{ .data }}{{ end }}{{ end }}' | base64 -d
FROM ubuntu:20.04
FROM ubuntu:24.04
RUN apt-get update
...
```

View File

@ -39,7 +39,7 @@ For more information on these properties, see the [Compose Deploy Specification]
```yaml
services:
test:
image: nvidia/cuda:12.3.1-base-ubuntu20.04
image: nvidia/cuda:12.9.0-base-ubuntu22.04
command: nvidia-smi
deploy:
resources:

View File

@ -137,7 +137,7 @@ 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
`bullseye`, and `trixie`) or adjectives (such as `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

View File

@ -30,15 +30,15 @@ output of the `docker images` command to only print `alpine` images.
```console
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu 20.04 33a5cc25d22c 36 minutes ago 101MB
ubuntu 18.04 152dc042452c 36 minutes ago 88.1MB
alpine 3.16 a8cbb8c69ee7 40 minutes ago 8.67MB
ubuntu 24.04 33a5cc25d22c 36 minutes ago 101MB
ubuntu 22.04 152dc042452c 36 minutes ago 88.1MB
alpine 3.21 a8cbb8c69ee7 40 minutes ago 8.67MB
alpine latest 7144f7bab3d4 40 minutes ago 11.7MB
busybox uclibc 3e516f71d880 48 minutes ago 2.4MB
busybox glibc 7338d0c72c65 48 minutes ago 6.09MB
$ docker images --filter reference=alpine
REPOSITORY TAG IMAGE ID CREATED SIZE
alpine 3.16 a8cbb8c69ee7 40 minutes ago 8.67MB
alpine 3.21 a8cbb8c69ee7 40 minutes ago 8.67MB
alpine latest 7144f7bab3d4 40 minutes ago 11.7MB
```
@ -58,9 +58,9 @@ following example shows how to print all images that match `alpine:latest` or
```console
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu 20.04 33a5cc25d22c 2 hours ago 101MB
ubuntu 18.04 152dc042452c 2 hours ago 88.1MB
alpine 3.16 a8cbb8c69ee7 2 hours ago 8.67MB
ubuntu 24.04 33a5cc25d22c 2 hours ago 101MB
ubuntu 22.04 152dc042452c 2 hours ago 88.1MB
alpine 3.21 a8cbb8c69ee7 2 hours ago 8.67MB
alpine latest 7144f7bab3d4 2 hours ago 11.7MB
busybox uclibc 3e516f71d880 2 hours ago 2.4MB
busybox glibc 7338d0c72c65 2 hours ago 6.09MB