diff --git a/content/guides/go-prometheus-monitoring/containerize.md b/content/guides/go-prometheus-monitoring/containerize.md index a0a1a7401c2e..a628c380618f 100644 --- a/content/guides/go-prometheus-monitoring/containerize.md +++ b/content/guides/go-prometheus-monitoring/containerize.md @@ -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. diff --git a/content/manuals/build/building/base-images.md b/content/manuals/build/building/base-images.md index 2e11b0ba540b..0c057046454b 100644 --- a/content/manuals/build/building/base-images.md +++ b/content/manuals/build/building/base-images.md @@ -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 diff --git a/content/manuals/build/building/best-practices.md b/content/manuals/build/building/best-practices.md index eb308bcf862a..c351630ac372 100644 --- a/content/manuals/build/building/best-practices.md +++ b/content/manuals/build/building/best-practices.md @@ -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 diff --git a/content/manuals/build/images/build-variables.svg b/content/manuals/build/images/build-variables.svg index 13197975fb1c..07dab5f2d326 100644 --- a/content/manuals/build/images/build-variables.svg +++ b/content/manuals/build/images/build-variables.svg @@ -1,3 +1,3 @@ - Global scope# Build arguments declared here are in the global scopeARG GLOBAL_ARG="global default value"ARG VERSION="3.19"# You can't declare environment variables in the global scopeENV GLOBAL_ENV=false# GLOBAL_ARG was not redeclared in this stageRUN echo $GLOBAL_ARG# LOCAL_ARG was declared in stage-aRUN echo $LOCAL_ARGstage-bFROM --platform=$BUILDPLATFORM alpine:${VERSION} as stage-bstage-a# FROM-lines belong to the global scope and have access to global ARGsFROM alpine:${VERSION} as stage-a# Redeclaring GLOBAL_ARG without a value inherits the global defaultARG GLOBAL_ARGRUN echo $GLOBAL_ARG# ARG here this scope creates a local argumentARG LOCAL_ARG="local arg in stage-a"# Set an environment variable in this scopeENV LOCAL_ENV=true# Set an environment variable to the value of a build argumentENV MY_VAR=$LOCAL_ARGstage-c# New stage based on "stage-a"FROM stage-a AS stage-c# Arguments and variables are inherited from parent stagesRUN echo $LOCAL_ARGRUN echo $LOCAL_ENV<- prints an empty string<- prints an empty string<- prints "global default value"<- prints "local arg in stage-a"<- prints "true"ARG TARGETPLATFORM# You must redeclare pre-defined arguments to use them in a stageRUN echo $TARGETPLATFORM<- prints os/arch/variant of --platform# Pre-defined multi-platform arguments like $BUILDPLATFORM are global + Global scope# Build arguments declared here are in the global scopeARG GLOBAL_ARG="global default value"ARG VERSION="3.21"# You can't declare environment variables in the global scopeENV GLOBAL_ENV=false# GLOBAL_ARG was not redeclared in this stageRUN echo $GLOBAL_ARG# LOCAL_ARG was declared in stage-aRUN echo $LOCAL_ARGstage-bFROM --platform=$BUILDPLATFORM alpine:${VERSION} as stage-bstage-a# FROM-lines belong to the global scope and have access to global ARGsFROM alpine:${VERSION} as stage-a# Redeclaring GLOBAL_ARG without a value inherits the global defaultARG GLOBAL_ARGRUN echo $GLOBAL_ARG# ARG here this scope creates a local argumentARG LOCAL_ARG="local arg in stage-a"# Set an environment variable in this scopeENV LOCAL_ENV=true# Set an environment variable to the value of a build argumentENV MY_VAR=$LOCAL_ARGstage-c# New stage based on "stage-a"FROM stage-a AS stage-c# Arguments and variables are inherited from parent stagesRUN echo $LOCAL_ARGRUN echo $LOCAL_ENV<- prints an empty string<- prints an empty string<- prints "global default value"<- prints "local arg in stage-a"<- prints "true"ARG TARGETPLATFORM# You must redeclare pre-defined arguments to use them in a stageRUN echo $TARGETPLATFORM<- prints os/arch/variant of --platform# Pre-defined multi-platform arguments like $BUILDPLATFORM are global diff --git a/content/manuals/build/metadata/attestations/slsa-provenance.md b/content/manuals/build/metadata/attestations/slsa-provenance.md index 2ed24019bef4..5da2b8617aef 100644 --- a/content/manuals/build/metadata/attestations/slsa-provenance.md +++ b/content/manuals/build/metadata/attestations/slsa-provenance.md @@ -175,7 +175,7 @@ extract the full source code of the Dockerfile used to build the image: ```console $ docker buildx imagetools inspect /: \ --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 ... ``` diff --git a/content/manuals/compose/how-tos/gpu-support.md b/content/manuals/compose/how-tos/gpu-support.md index 0d5c6b7b4d08..a9b0bb899f10 100644 --- a/content/manuals/compose/how-tos/gpu-support.md +++ b/content/manuals/compose/how-tos/gpu-support.md @@ -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: diff --git a/content/manuals/docker-hub/image-library/trusted-content.md b/content/manuals/docker-hub/image-library/trusted-content.md index 518ccfce6dbb..1150abc46f83 100644 --- a/content/manuals/docker-hub/image-library/trusted-content.md +++ b/content/manuals/docker-hub/image-library/trusted-content.md @@ -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 diff --git a/content/manuals/engine/cli/filter.md b/content/manuals/engine/cli/filter.md index e51fb633470f..9549f8a34b5d 100644 --- a/content/manuals/engine/cli/filter.md +++ b/content/manuals/engine/cli/filter.md @@ -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