distroless
1.0.0
"Denkende" Bilder enthalten nur Ihre Anwendung und ihre Laufzeitabhängigkeiten. Sie enthalten keine Paketmanager, Shells oder andere Programme, die Sie in einer Standard -Linux -Verteilung erwarten würden.
Weitere Informationen finden Sie in diesem Vortrag (Video).
Seit März 2023 verwenden entzündliche Bilder OCI -Manifests. Wenn Sie Fehler auf application/vnd.oci.image.manifest.v1+json oder application/vnd.oci.image.index.v1+json verweisen, aktualisieren Sie Ihre Container -Tools (Docker, Docker, Jib usw.) bis neulich.
Die Einschränkung dessen, was in Ihrem Laufzeitcontainer ist, auf genau das, was für Ihre App erforderlich ist, ist eine bewährte Verfahren, die von Google und anderen Tech -Riesen verwendet wird, die seit vielen Jahren Container in der Produktion verwendet. Es verbessert das Signal für das Rauschen von Scannern (z. B. CVE) und verringert die Belastung, die Herkunft auf das zu etablieren, was Sie brauchen.
Distanzierte Bilder sind sehr klein . Das kleinste, entzündliche Bild, gcr.io/distroless/static-debian12 , liegt bei 2 MIB. Das sind etwa 50% der Größe von alpine (~ 5 MIB) und weniger als 2% der Größe von debian (124 MIB).
Diese Bilder werden mit Basel erstellt, können aber auch über andere Docker -Image -Build -Werkzeuge verwendet werden.
Die folgenden Bilder werden derzeit vom entscheidenden Projekt veröffentlicht und aktualisiert (siehe Support_Policy für Support -Timelines)
| Bild | Tags | Architektur -Suffixe |
|---|---|---|
| gcr.io/distroless/static-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, Arm, S390X, PPC64LE |
| gcr.io/distroless/base-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, Arm, S390X, PPC64LE |
| gcr.io/distroless/base-nosl-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, Arm, S390X, PPC64LE |
| gcr.io/distroless/cc-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, Arm, S390X, PPC64LE |
| gcr.io/distroless/python3-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64 |
| gcr.io/distroless/java-base-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, S390X, PPC64LE |
| gcr.io/distroless/java17-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, S390X, PPC64LE |
| gcr.io/distroless/java21-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, PPC64LE |
| gcr.io/distroless/nodejs18-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, Arm, S390X, PPC64LE |
| gcr.io/distroless/nodejs20-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, Arm, S390X, PPC64LE |
| gcr.io/distroless/nodejs22-debian12 | Neueste, Nonroot, Debug, Debugg-Nonroot | AMD64, ARM64, Arm, S390X, PPC64LE |
Diese Bilder beziehen sich auf Bildindizes mit Verweisen auf alle unterstützten Architekturen. Architekturspezifische Bilder können direkt unter Verwendung eines zusätzlichen Architektursuffix auf dem Tag wie gcr.io/distroless/static-debian12:latest-amd64 referenziert werden
Alle anderen Tags gelten als veraltet und werden nicht mehr aktualisiert
Alle entzündlichen Bilder werden von CoSIGN mit Hercurtasten (schlüssig) unterschrieben - dies ist der einzige unterstützte Mechanismus ab November 2023. Wir empfehlen, ein entscheidendes Bild zu überprüfen, das Sie verwenden, bevor Sie Ihr Bild erstellen. Mit:
cosign verify $IMAGE_NAME --certificate-oidc-issuer https://accounts.google.com --certificate-identity [email protected]
Beachten Sie, dass standardmäßige entscheidende Bilder keine Shell enthalten. Das bedeutet, dass der Befehl docerfile ENTRYPOINT , wenn er definiert ist, in vector angegeben werden, um das Vorfixieren des Container -Laufzeit mit einer Shell zu vermeiden.
Das funktioniert:
ENTRYPOINT ["myapp"]
Aber das funktioniert nicht:
ENTRYPOINT "myapp"
Aus den gleichen Gründen sollte der CMD -Befehl in vector angegeben werden, wenn der Einstiegspunkt auf den leeren Vektor eingestellt ist (siehe Beispiele unten). Beachten Sie, dass statische, Basis- und CC -Bilder standardmäßig den leeren Vektoreintragspunkt haben. Bilder mit einer eingeschlossenen Sprachlaufzeit haben einen sprachspezifischen Standard (siehe: Java, NodeJS, Python3).
Multi-Stufe-Builds der Docker machen die Verwendung von entfaltenden Bildern einfach. Befolgen Sie diese Schritte, um loszulegen:
Wählen Sie das richtige Basisbild für Ihren Anwendungsstapel.
Schreiben Sie eine mehrstufige Docker-Datei. Hinweis: Dies erfordert Docker 17.05 oder höher.
Die grundlegende Idee ist, dass Sie eine Phase haben, um Ihre Anwendungsartefakte zu erstellen und sie in Ihr unmittelbares Laufzeit -Bild einzufügen. Wenn Sie mehr erfahren möchten, finden Sie in der Dokumentation zu mehrstufigen Builds.
Hier ist ein kurzes Beispiel für Go:
# 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" ]Hier finden Sie andere Beispiele:
Um ein beliebiges Beispiel auszuführen, gehen Sie zum Verzeichnis für die Sprache und laufen Sie aus
docker build -t myapp .
docker run -t myapp
So führen Sie den Node.js Express-App-Knoten-Express aus und legen Sie die Ports des Containers frei:
npm install # Install express and its transitive dependencies
docker build -t myexpressapp . # Normal build command
docker run -p 3000:3000 -t myexpressapp
Dies sollte die ausdrückliche Anwendung Ihrem Localhost aussetzen: 3000
Eine vollständige Dokumentation zur Verwendung von Bazel zum Generieren von Containerbildern finden Sie im Repository von Basel-Contrib/Rules_oci.
Unter Dokumentation und Beispiel für die Verwendung des GO-basierten Debian Package Managers (Current) zum Generieren von Bazel-Konfiguration siehe. /package_manager
Beispiele finden Sie in diesem Repository im Beispielverzeichnis.
Wir haben einige Beispiele dafür, wie einige gemeinsame Anwendungsstapel im Verzeichnis /Beispiele ausgeführt werden können. Siehe hier für:
Beispiele finden Sie hier, wie Sie einige gemeinsame Aufgaben in Ihrem Bild erledigen können:
Weitere Informationen darüber finden Sie, wie diese Bilder erstellt und veröffentlicht werden.
Distrosollose Bilder basieren auf Debian 12 (Bücherwurm). Die Bilder werden explizit mit Debian -Versionsuffixen (z. B. -debian12 ) getaggt. Wenn Sie ein Bild ohne die Verteilung angeben, werden derzeit -debian12 -Bilder ausgewählt, die sich jedoch in Zukunft zu einer neueren Version von Debian ändern. Es kann nützlich sein, die Verteilung explizit zu verweisen, um Breaking -Builds zu verhindern, wenn die nächste Debian -Version veröffentlicht wird.
Discouness verfolgt die vorgelagerten Debian -Releases mit GitHub -Aktionen, um automatisch eine Pull -Anforderung zu generieren, wenn Aktualisierungen vorliegen.
Entscheidende Bilder sind minimal und fehlen Shell Access. Der :debug -Bildsatz für jede Sprache bietet eine beliebte Box -Shell zum Eingeben.
Zum Beispiel:
cd examples/python3/
Bearbeiten Sie die Dockerfile , um das endgültige Bild zu ändern in :debug ::
FROM gcr.io/distroless/python3-debian12:debug
COPY . /app
WORKDIR /app
CMD [ "hello.py" , "/etc" ]Erstellen und starten Sie dann mit einem Shell -Einstiegspunkt:
$ docker build -t my_debug_image .
$ docker run --entrypoint=sh -ti my_debug_image
/app # ls
BUILD Dockerfile hello.py
HINWEIS: Wenn das Bild, das Sie verwenden, bereits ein Tag enthält, zum Beispiel
gcr.io/distroless/java17-debian12:nonroot, verwenden Sie das Tagdebug-<existing tag>Stattdessen, beispielsweisegcr.io/distroless/java17-debian12:debug-nonroot.
Hinweis: LDD ist nicht im Basisbild installiert, da es sich um ein Shell -Skript handelt. Sie können es kopieren oder herunterladen.
Wenn Ihr Projekt entblößt verwendet, senden Sie ein PR, um Ihr Projekt hier hinzuzufügen!
