Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

🥑 Language focused docker images, minus the operating system.

License

NotificationsYou must be signed in to change notification settings

GoogleContainerTools/distroless

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

CI Build Status

"Distroless" images contain only your application and its runtime dependencies.They do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution.

For more information, see thistalk (video).

Since March 2023, Distroless images use oci manifests, if you see errors referencingapplication/vnd.oci.image.manifest.v1+jsonorapplication/vnd.oci.image.index.v1+json, update your container tooling (docker, jib, etc) to latest.

Why should I use distroless images?

Restricting what's in your runtime container to precisely what's necessary for your app is a best practice employed by Googleand other tech giants that have used containers in production for many years.It improves the signal to noise of scanners (e.g. CVE) and reduces the burden of establishing provenance to just what you need.

Distroless images arevery small.The smallest distroless image,gcr.io/distroless/static-debian12, is around 2 MiB.That's about 50% of the size ofalpine (~5 MiB), and less than 2% of the size ofdebian (124 MiB).

How do I use distroless images?

These images are built usingbazel, but they can also be used through other Docker image build tooling.

What images are available?

The following images are currently published and updated by the distroless project (seeSUPPORT_POLICY.md for support timelines)

These images refer to image indexes with references to all supported architectures. Architecture specific images can be directly referenced using an additional architecture suffix on the tag, likegcr.io/distroless/static-debian12:latest-amd64

Any other tags are considered deprecated and are no longer updated

Debian 12

ImageTagsArchitecture Suffixes
gcr.io/distroless/static-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/base-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/base-nossl-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/cc-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/python3-debian12latest, nonroot, debug, debug-nonrootamd64, arm64
gcr.io/distroless/java-base-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, s390x, ppc64le
gcr.io/distroless/java17-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, s390x, ppc64le
gcr.io/distroless/java21-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, s390x, ppc64le
gcr.io/distroless/nodejs20-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/nodejs22-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/nodejs24-debian12latest, nonroot, debug, debug-nonrootamd64, arm64, s390x, ppc64le

Debian 13

Debian 13 distroless images use the debianUsrMerge scheme. If you userules_distroless to add packages to an image, setmergedusr = True inapt.install.

ImageTagsArchitecture Suffixes
gcr.io/distroless/static-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/base-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/base-nossl-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/cc-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/java-base-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, s390x, ppc64le
gcr.io/distroless/java21-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, s390x, ppc64le
gcr.io/distroless/java25-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, s390x, ppc64le
gcr.io/distroless/nodejs20-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/nodejs22-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/nodejs24-debian13latest, nonroot, debug, debug-nonrootamd64, arm64, s390x, ppc64le

Why is distroless still usinggcr.io instead ofpkg.dev?

Distroless's serving infrastructure has moved to artifact registry but we still use thegcr.io domain. Users will get the benefits of the newer infrastructure without changing their builds.

How do I verify distroless images?

All distroless images are signed bycosign with ephemeral keys (keyless) -- this is the only supported mechanism starting November 2023.We recommend verifying any distroless image you use before building your image. You can verify the keyless signature of any distroless image with:

cosign verify$IMAGE_NAME --certificate-oidc-issuer https://accounts.google.com --certificate-identity keyless@distroless.iam.gserviceaccount.com

Entrypoints

Note that distroless images by default do not contain a shell.That means the DockerfileENTRYPOINT command, when defined, must be specified invector form, to avoid the container runtime prefixing with a shell.

This works:

ENTRYPOINT ["myapp"]

But this does not work:

ENTRYPOINT"myapp"

For the same reasons, if the entrypoint is set to the empty vector, the CMD command should be specified invector form (see examples below).Note that by default static, base and cc images have the empty vector entrypoint. Images with an included language runtime have a language specific default (see:java,nodejs,python3).

Docker

Docker multi-stage builds make using distroless images easy.Follow these steps to get started:

  • Pick the right base image for your application stack.

  • Write a multi-stage docker file.Note: This requires Docker 17.05 or higher.

    The basic idea is that you'll have one stage to build your application artifacts, and insert them into your runtime distroless image.If you'd like to learn more, please see the documentation onmulti-stage builds.

Examples with Docker

Here's a quick example for go:

# Start by building the application.FROM golang:1.18 as buildWORKDIR /go/src/appCOPY . .RUN go mod downloadRUN CGO_ENABLED=0 go build -o /go/bin/app# Now copy it into our base image.FROM gcr.io/distroless/static-debian12COPY --from=build /go/bin/app /CMD ["/app"]

You can find other examples here:

To run any example, go to the directory for the language and run:

docker build -t myapp.docker run -t myapp

To run theNode.js Express example app and expose the container's ports:

npm install# Install express and its transitive dependenciesdocker build -t myexpressapp.# Normal build commanddocker run -p 3000:3000 -t myexpressapp

This should expose the Express application to yourlocalhost:3000

Bazel

For full documentation on how to use bazel to generate Container images, see thebazel-contrib/rules_oci repository.

For documentation and example on how to create custom container images, see theGoogleContainerTools/rules_distroless repository.

Examples can be found in theGoogleContainerTools/rules_distroless repository.

Examples with Bazel

We have some examples on how to run some common application stacks in the /examples directory.See here for:

See here for examples on how to complete some common tasks in your image:

See here for more information on how these images arebuilt and released.

Base Operating System

Distroless images are based on Debian 12 (bookworm). Images are explicitly tagged with Debian version suffixes (e.g.-debian12). Specifying an image without the distribution will currently select-debian12 images, but that will change in the future to a newer version of Debian. It can be useful to reference the distribution explicitly, to prevent breaking builds when the next Debian version is released.

Operating System Updates for Security Fixes and CVEs

Distroless tracks the upstream Debian releases, usingGithub actions to automatically generate a pull request when there are updates.

Debug Images

Distroless images are minimal and lack shell access. The:debug image set for each language provides a busybox shell to enter.

For example:

cd examples/python3/

edit theDockerfile to change the final image to:debug:

FROM gcr.io/distroless/python3-debian12:debugCOPY . /appWORKDIR /appCMD ["hello.py","/etc"]

then build and launch with a shell entrypoint:

docker build -t my_debug_image.
$ docker run --entrypoint=sh -ti my_debug_image/app# lsBUILD       Dockerfile  hello.py

Note: If the image you are using already has a tag, for examplegcr.io/distroless/java17-debian12:nonroot, use the tagdebug-<existing tag> instead, for examplegcr.io/distroless/java17-debian12:debug-nonroot.

Note:ldd is not installed in the base image as it's a shell script, you can copy it in or download it.

Who uses Distroless?

If your project uses Distroless, send a PR to add your project here!

Community Discussion

About

🥑 Language focused docker images, minus the operating system.

Topics

Resources

License

Contributing

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

[8]ページ先頭

©2009-2025 Movatter.jp