distroless
1.0.0
“分心”圖像僅包含您的應用程序及其運行時依賴性。它們不包含您期望在標準Linux發行版中找到的包裝管理人員，外殼或任何其他程序。
有關更多信息，請參閱此演講（視頻）。
自2023年3月以來，分散圖像使用OCI清單，如果您看到錯誤引用application/vnd.oci.image.manifest.v1+json或application/vnd.oci.image.index.v1+json ，請更新容器工具（Docker，docker，docker，docker，docker，docker，docker，docker ,，吉布等最新。
將運行時容器中的內容限制為應用程序所需的內容是Google和其他技術巨頭使用的最佳實踐，這些實踐已多年使用。它改善了掃描儀（例如CVE）的噪音，並減輕了將出處建立的負擔到您所需要的。
分散圖像很小。最小的分散圖像， gcr.io/distroless/static-debian12 distroless/static-debian12，約為2 MIB。這大約是alpine大小（〜5 MIB）的50％，不到debian （124 MIB）的2％。
這些圖像是使用Bazel構建的，但也可以通過其他Docker Image Build Tooling使用。
當前由Distrools Project發布和更新以下圖像（有關支持時間表，請參見Support_policy）
| 圖像 | 標籤 | 建築後綴 |
|---|---|---|
| gcr.io/distroless/static-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，ARM，S390X，PPC64LE |
| gcr.io/distroless/base-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，ARM，S390X，PPC64LE |
| gcr.io/distroless/base-nossl-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，ARM，S390X，PPC64LE |
| gcr.io/distroless/cc-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，ARM，S390X，PPC64LE |
| gcr.io/distroless/python3-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64 |
| gcr.io/distroless/java-base-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，S390X，PPC64LE |
| gcr.io/distroless/java17-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，S390X，PPC64LE |
| gcr.io/distroless/java21-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，PPC64LE |
| gcr.io/distroless/nodejs18-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，ARM，S390X，PPC64LE |
| gcr.io/distroless/nodejs20-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，ARM，S390X，PPC64LE |
| gcr.io/distroless/nodejs22-debian12 | 最新的，非根本，調試，調試非根管 | AMD64，ARM64，ARM，S390X，PPC64LE |
這些圖像是指帶有所有受支持體系結構的圖像索引。可以使用標籤上的附加架構gcr.io/distroless/static-debian12:latest-amd64直接引用體系結構的特定圖像
任何其他標籤都被視為棄用，不再更新
所有乾擾圖像均由Cosign簽名，上面鍵（無鑰匙） - 這是從2023年11月開始的唯一支持的機制。我們建議我們在構建圖像之前驗證您使用的任何干擾圖像。您可以使用以下方式驗證任何干擾圖像的無鑰匙簽名
cosign verify $IMAGE_NAME --certificate-oidc-issuer https://accounts.google.com --certificate-identity [email protected]
請注意，默認情況下，分散圖像不包含外殼。這意味著必須以vector形式指定DockerFile ENTRYPOINT命令，以避免使用Shell的容器運行時。
這有效：
ENTRYPOINT ["myapp"]
但這無效：
ENTRYPOINT "myapp"
由於相同的原因，如果將入口點設置為空向量，則應以vector形式指定CMD命令（請參見下面的示例）。請注意，默認情況下，靜態，鹼基和CC圖像具有空的矢量入口點。包含語言運行時的圖像具有特定語言的默認值（請參見：Java，Nodejs，Python3）。
Docker多階段構建可以輕鬆使用分散圖像。請按照以下步驟開始：
為您的應用程序堆棧選擇正確的基本圖像。
編寫一個多階段Docker文件。注意：這需要Docker 17.05或更高。
基本想法是，您將有一個階段來構建應用程序工件，並將其插入您的運行時分散圖像中。如果您想了解更多信息，請查看有關多階段構建的文檔。
這是一個快速的示例：
# Start by building the application.
FROM golang:1.18 as build
WORKDIR /go/src/app
COPY . .
RUN go mod download
RUN CGO_ENABLED=0 go build -o /go/bin/app
# Now copy it into our base image.
FROM gcr.io/distroless/static-debian12
COPY --from=build /go/bin/app /
CMD [ "/app" ]您可以在此處找到其他示例：
要運行任何示例，請轉到語言目錄並運行
docker build -t myapp .
docker run -t myapp
運行node.js express app node-express並公開容器的端口：
npm install # Install express and its transitive dependencies
docker build -t myexpressapp . # Normal build command
docker run -p 3000:3000 -t myexpressapp
這應該將Express申請暴露於您的本地主機：3000
有關如何使用Bazel生成容器圖像的完整文檔，請參見Bazel-Contrib/Rules_oci存儲庫。
有關如何使用基於GO的Debian軟件包管理器（Current）生成Bazel配置的文檔和示例，請參見./debian_package_manager，以獲取文檔和有關如何使用Bazel軟件包管理器規則（未在此存儲庫中使用）的文檔和示例，請參見。 /package_manager
示例可以在示例目錄中的此存儲庫中找到。
我們有一些示例有關如何在 /示例目錄中運行一些常見應用程序堆棧的示例。請參閱此處的：
有關如何完成圖像中一些常見任務的示例，請參見此處：
有關這些圖像的構建和釋放的更多信息，請參見此處。
分散圖像基於Debian 12（Bookworm）。圖像用Debian版本後綴（例如-debian12 ）明確標記。當前，指定沒有分發圖像的圖像將選擇-debian12圖像，但這將來會更改為較新版本的Debian。明確引用發行版，以防止在下一個Debian版本發佈時進行破壞構建。
Distrooss跟踪上游Debian版本，使用GitHub操作在更新時自動生成拉請請求。
分散圖像是最小的，缺乏貝殼訪問。 :debug映像提供了一個繁忙的盒外殼輸入。
例如：
cd examples/python3/
編輯Dockerfile將最終圖像更改為:debug ：
FROM gcr.io/distroless/python3-debian12:debug
COPY . /app
WORKDIR /app
CMD [ "hello.py" , "/etc" ]然後使用Shell入口點構建和啟動：
$ docker build -t my_debug_image .
$ docker run --entrypoint=sh -ti my_debug_image
/app # ls
BUILD Dockerfile hello.py
注意：如果您正在使用的圖像已經具有標籤，例如
gcr.io/distroless/java17-debian12:nonroot，請使用標籤debug-<existing tag>，例如gcr.io/distroless/java17-debian12:debug-nonroot。
注意：基本圖像中沒有安裝LDD，因為它是Shell腳本，您可以將其複製或下載。
如果您的項目使用乾擾，請發送PR在此處添加您的項目！
