official images
1.0.0
Die offiziellen Docker-Bilder sind kuratierte Bilder, die auf Docker Hub gehostet werden. Die wichtigsten Grundsätze sind:
Konzentrieren Sie sich auf freie und Open-Source-Software
Unterstützt mehrere Architekturen
Veranschaulichen Sie Best Practices Dockerfile
Aktive Neuerstellung für Updates und Sicherheitsfixes
Halten Sie sich an die Empfehlungen der Vorgesetzten
Fügen Sie bei Bedarf ein minimales Lebensqualitätsverhalten für die Containerumgebung hinzu
Einen guten allgemeinen Überblick über das Programm finden Sie in der Docker-Dokumentation.
Im Wesentlichen sind wir bestrebt, die Empfehlungen der Upstream-Anbieter hinsichtlich der beabsichtigten Nutzung ihrer Software zu berücksichtigen. Viele Bilder werden in Zusammenarbeit mit dem jeweiligen Upstream-Projekt gepflegt, wenn sie nicht direkt von diesem gepflegt werden. Darüber hinaus möchten wir die Best Practices für Dockerfiles veranschaulichen, um als Referenz bei der Erstellung oder Ableitung eigener Images daraus zu dienen.
(Wenn Sie ein Vertreter eines Upstreams sind, für den es ein Image gibt, und sich engagieren möchten, lesen Sie bitte den Abschnitt „Maintainership“ unten!)
Einige Images wurden für andere Architekturen portiert und viele davon werden offiziell unterstützt (in unterschiedlichem Maße).
arm32v6 ): https://hub.docker.com/u/arm32v6/arm32v7 ): https://hub.docker.com/u/arm32v7/arm64v8 ): https://hub.docker.com/u/arm64v8/amd64 ): https://hub.docker.com/u/amd64/windows-amd64 ): https://hub.docker.com/u/winamd64/arm32v5 ): https://hub.docker.com/u/arm32v5/ppc64le ): https://hub.docker.com/u/ppc64le/s390x ): https://hub.docker.com/u/s390x/mips64le ): https://hub.docker.com/u/mips64le/riscv64 ): https://hub.docker.com/u/riscv64/i386 ): https://hub.docker.com/u/i386/ Ab dem 12.09.2017 sind diese anderen Architekturen über „Manifestlisten“ (in der OCI-Image-Spezifikation auch „Indizes“ genannt) in die nicht-präfixierten Images eingebunden, so dass beispielsweise docker run hello-world sollte Läuft unverändert auf allen unterstützten Plattformen.
Wenn Sie neugierig sind, wie diese aufgebaut sind, gehen Sie zu https://doi-janky.infosiftr.net/job/multiarch/, um sich das Baugerüst anzusehen.
Empfehlungen zum Hinzufügen weiterer Architekturen zu einem offiziellen Image finden Sie im Abschnitt „Multi-Arch“ weiter unten.
Ja! Wir verfügen über ein spezielles FAQ-Repository, in dem wir versuchen, andere häufig gestellte Fragen (sowohl zum Programm als auch zu unseren Praktiken) zu sammeln.
Vielen Dank für Ihr Interesse am offiziellen Docker-Image-Projekt! Wir bemühen uns, diese Anweisungen so einfach und unkompliziert wie möglich zu gestalten, aber wenn Sie sich verlaufen haben, zögern Sie nicht, uns im Libera.Chat IRC im Kanal #docker-library aufzusuchen oder hier ein GitHub-Issue zu erstellen.
Machen Sie sich unbedingt mit den offiziellen Repositories auf Docker Hub und den Best Practices zum Schreiben von Docker-Dateien in der Docker-Dokumentation vertraut. Diese bilden die Grundlage für den Überprüfungsprozess, der von den offiziellen Bildbetreuern durchgeführt wird. Wenn Sie möchten, dass der Überprüfungsprozess reibungsloser verläuft, stellen Sie bitte sicher, dass Ihre Dockerfile alle dort und unten genannten Punkte einhalten, bevor Sie eine Pull-Anfrage einreichen.
Außerdem werden die Hub-Beschreibungen für diese Bilder derzeit separat im Repository docker-library/docs gespeichert, in dessen Datei README.md mehr darüber erläutert wird, wie es strukturiert ist und wie man dazu beitragen kann. Bitte seien Sie bereit, dort auch eine PR einzureichen, bis Ihr Bild hier akzeptiert wird.
Da die offiziellen Images als Lerntools für Docker-Neulinge und als Basisimages für fortgeschrittene Benutzer zum Erstellen ihrer Produktionsversionen dienen sollen, überprüfen wir jede vorgeschlagene Dockerfile um sicherzustellen, dass sie einem Mindeststandard für Qualität und Wartbarkeit entspricht. Während einige dieser Standards schwer zu definieren sind (aufgrund der Subjektivität), wird hier so viel wie möglich definiert, wobei gegebenenfalls auch die „Best Practices“ eingehalten werden.
Eine Checkliste, die von den Betreuern während der Überprüfung verwendet werden kann, finden Sie in NEW-IMAGE-CHECKLIST.md .
Versionsfehler und Sicherheitskorrekturen sollten rechtzeitig behoben werden.
Wenn Sie den Upstream nicht repräsentieren und der Upstream an der Pflege des Images interessiert ist, sollten Schritte unternommen werden, um einen reibungslosen Übergang der Image-Betreuerschaft zum Upstream sicherzustellen.
Für Upstreams, die daran interessiert sind, die Betreuerschaft für ein bestehendes Repository zu übernehmen, besteht der erste Schritt darin, sich am bestehenden Repository zu beteiligen. Kommentare zu Problemen abzugeben, Änderungen vorzuschlagen und sich innerhalb der „Bild-Community“ bekannt zu machen (auch wenn diese „Community“ nur der aktuelle Betreuer ist) sind alles wichtige Ausgangspunkte, um sicherzustellen, dass der Übergang für bestehende Mitwirkende und Benutzer keine Überraschungen darstellt.
Wenn Sie ein vorhandenes Repository übernehmen, stellen Sie bitte sicher, dass der gesamte Git-Verlauf des ursprünglichen Repositorys im neuen, vom Upstream verwalteten Repository erhalten bleibt, um sicherzustellen, dass der Überprüfungsprozess während des Übergangs nicht ins Stocken gerät. Dies lässt sich am einfachsten erreichen, indem man das neue aus dem vorhandenen Repository forkt, kann aber auch dadurch erreicht werden, dass man die Commits direkt vom Original abruft und sie in das neue Repository schiebt (z. B. git fetch https://github.com/jsmith/example.git master . git fetch https://github.com/jsmith/example.git master , git rebase FETCH_HEAD , git push -f ). Auf GitHub besteht eine Alternative darin, den Besitz des Git-Repositorys zu verschieben. Dies kann erreicht werden, ohne einer Gruppe Administratorzugriff auf das Repository des anderen Eigentümers zu gewähren:
Die Neuerstellung derselben Dockerfile sollte dazu führen, dass dieselbe Version des Images gepackt wird, auch wenn der zweite Build mehrere Versionen später erfolgt, oder der Build sollte völlig fehlschlagen, sodass eine versehentliche Neuerstellung einer Dockerfile mit dem Tag 0.1.0 nicht endet up enthält 0.2.3 . Wenn Sie beispielsweise apt verwenden, um das Hauptprogramm für das Image zu installieren, achten Sie darauf, es an eine bestimmte Version anzuheften (z. B. ... apt-get install -y my-package=0.1.0 ... ). Für abhängige Pakete, die von apt installiert werden, ist es normalerweise nicht erforderlich, sie einer Version zuzuordnen.
Es können keine offiziellen Bilder von inoffiziellen Bildern abgeleitet werden oder von ihnen abhängen (was den Nicht-Bild scratch und die absichtlich begrenzten Ausnahmen erlaubt, die in .external-pins gepinnt sind – siehe auch .external-pins/list.sh ).
Alle offiziellen Bilder sollten eine einheitliche Schnittstelle bieten. Ein Anfänger sollte in der Lage sein docker run official-image bash (oder sh ) über Docker auszuführen, ohne sich mit --entrypoint auskennen zu müssen. Für fortgeschrittene Benutzer ist es auch hilfreich, den Einstiegspunkt zu nutzen, sodass sie docker run official-image --arg1 --arg2 können, ohne die auszuführende Binärdatei angeben zu müssen.
Wenn der Startvorgang keine Argumente benötigt, verwenden Sie einfach CMD :
CMD [ "irb" ] Wenn beim Start eine Initialisierung durchgeführt werden muss, z. B. das Erstellen der anfänglichen Datenbank, verwenden Sie einen ENTRYPOINT zusammen mit CMD :
ENTRYPOINT [ "/docker-entrypoint.sh" ]
CMD [ "postgres" ] Stellen Sie sicher, dass docker run official-image bash (oder sh ) auch funktioniert. Am einfachsten ist es, nach dem erwarteten Befehl zu suchen. Wenn es sich um etwas anderes handelt, exec "$@" (führen Sie alles aus, was übergeben wurde, und behalten Sie dabei die Escape-Argumente bei).
#! /bin/sh
set -e
# this if will check if the first argument is a flag
# but only works if all arguments require a hyphenated flag
# -v; -SL; -f arg; etc will work, but not arg1 arg2
if [ " $# " -eq 0 ] || [ " ${1 # -} " != " $1 " ] ; then
set -- mongod " $@ "
fi
# check for the expected command
if [ " $1 " = ' mongod ' ] ; then
# init db stuff....
# use gosu (or su-exec) to drop to a non-root user
exec gosu mongod " $@ "
fi
# else default to run whatever the user wanted like "bash" or "sh"
exec " $@ " Wenn das Image nur die ausführbare Hauptdatei und ihre verknüpften Bibliotheken enthält (d. h. keine Shell), ist es in Ordnung, die ausführbare Datei als ENTRYPOINT zu verwenden, da dies das Einzige ist, was ausgeführt werden kann:
ENTRYPOINT [ "fully-static-binary" ]
CMD [ "--help" ] Der häufigste Indikator dafür, ob dies angemessen ist, ist, dass die Image- Dockerfile bei scratch beginnt ( FROM scratch ).
Versuchen Sie, die Dockerfile leicht verständlich/lesbar zu machen. Der Kürze halber könnte es verlockend sein, komplizierte Initialisierungsdetails in ein eigenständiges Skript zu packen und lediglich einen RUN Befehl in die Dockerfile einzufügen. Dies führt jedoch dazu, dass die resultierende Dockerfile übermäßig undurchsichtig ist und es unwahrscheinlich ist, dass solche Dockerfile Dateien die Prüfung bestehen. Stattdessen wird empfohlen, alle Befehle zur Initialisierung als entsprechende RUN oder ENV -Befehlskombinationen in die Dockerfile einzufügen. Um gute Beispiele zu finden, schauen Sie sich die aktuellen offiziellen Bilder an.
Einige Beispiele zum Zeitpunkt des Schreibens:
Gemäß den Docker-Richtlinien wird dringend empfohlen, dass das resultierende Image nur ein Problem pro Container darstellt. Im Wesentlichen bedeutet dies nur einen Prozess pro Container, sodass kein vollständiges Init-System erforderlich ist. Es gibt zwei Situationen, in denen ein init-ähnlicher Prozess für den Container hilfreich wäre. Das erste ist die Signalverarbeitung. Wenn der gestartete Prozess SIGTERM beim Beenden nicht verarbeitet, wird er nicht beendet, da er PID 1 im Container ist (siehe „HINWEIS“ am Ende des Abschnitts „Vordergrund“ in den Docker-Dokumenten). Die zweite Situation wäre das Ernten von Zombies. Wenn der Prozess untergeordnete Prozesse erzeugt und diese nicht ordnungsgemäß erntet, führt dies zu einer vollständigen Prozesstabelle, was dazu führen kann, dass das gesamte System keine neuen Prozesse erzeugt. Für beide Anliegen empfehlen wir tini. Es ist unglaublich klein, hat minimale externe Abhängigkeiten, erfüllt jede dieser Rollen und übernimmt nur die notwendigen Teile des Erntens und der Signalweiterleitung.
Stellen Sie sicher, dass Sie tini je nach Bedarf in CMD oder ENTRYPOINT verwenden.
Am besten installieren Sie tini aus einem von der Distribution bereitgestellten Paket (z. B. apt-get install tini ). Wenn tini in Ihrer Distribution nicht verfügbar oder zu alt ist, finden Sie hier einen Ausschnitt einer Dockerfile den Sie in tini hinzufügen können:
# Install tini for signal processing and zombie killing
ENV TINI_VERSION v0.18.0
ENV TINI_SIGN_KEY 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7
RUN set -eux;
wget -O /usr/local/bin/tini "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini" ;
wget -O /usr/local/bin/tini.asc "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini.asc" ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$TINI_SIGN_KEY" ;
gpg --batch --verify /usr/local/bin/tini.asc /usr/local/bin/tini;
command -v gpgconf && gpgconf --kill all || :;
rm -r "$GNUPGHOME" /usr/local/bin/tini.asc;
chmod +x /usr/local/bin/tini;
tini --versionDies ist ein Punkt, an dem die Erfahrung auf dem Weg zur Erleuchtung letztendlich die Dokumentation übertrumpft, aber die folgenden Tipps könnten hilfreich sein:
Vermeiden Sie nach Möglichkeit COPY / ADD , seien Sie jedoch bei Bedarf so spezifisch wie möglich (z. B. COPY one-file.sh /somewhere/ anstelle von COPY . /somewhere ).
Der Grund dafür liegt darin, dass der Cache für COPY -Anweisungen Datei mtime Änderungen als Cache-Bust betrachtet, was das Cache-Verhalten von COPY manchmal unvorhersehbar machen kann, insbesondere wenn .git Teil dessen ist, was COPY ed werden muss (zum Beispiel).
Stellen Sie sicher, dass Zeilen, bei denen es weniger wahrscheinlich ist, dass sie sich ändern, vor Zeilen stehen, bei denen es wahrscheinlicher ist, dass sie sich ändern (mit der Einschränkung, dass jede Zeile ein Bild erzeugen sollte, das auch ohne Annahmen über spätere Zeilen erfolgreich ausgeführt werden kann).
Beispielsweise sollte die Zeile, die die Softwareversionsnummer ( ENV MYSOFTWARE_VERSION 4.2 ) enthält, nach einer Zeile stehen, die die .list Datei des APT-Repositorys einrichtet ( RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list ).
Die Dockerfile sollte so geschrieben werden, dass sie Abfangangriffe während des Builds abschwächt. Unsere Anforderungen konzentrieren sich auf drei Hauptziele: Überprüfung der Quelle, Überprüfung des Autors und Überprüfung des Inhalts; Dies wird jeweils durch Folgendes erreicht: Verwendung von https, wo möglich; Importieren von PGP-Schlüsseln mit dem vollständigen Fingerabdruck in die Dockerfile , um Signaturen zu überprüfen; Einbetten von Prüfsummen direkt in das Dockerfile . Wenn möglich, sollten alle drei verwendet werden. Wenn keine Signatur veröffentlicht wird, können nur https und eine eingebettete Prüfsumme verwendet werden. Als letzten Ausweg ist nur eine eingebettete Prüfsumme akzeptabel, wenn auf der Website kein https verfügbar und keine Signatur verfügbar ist.
Der Zweck der Empfehlung der Verwendung von https zum Herunterladen benötigter Artefakte besteht darin, sicherzustellen, dass der Download von einer vertrauenswürdigen Quelle erfolgt, was das Abfangen außerdem erheblich erschwert.
Der Zweck der Empfehlung der PGP-Signaturüberprüfung besteht darin, sicherzustellen, dass nur ein autorisierter Benutzer das bestimmte Artefakt veröffentlicht hat. Wenn möglich, verwenden Sie beim Importieren von PGP-Schlüsseln bitte den Dienst keys.openpgp.org (andernfalls bevorzugen Sie keyserver.ubuntu.com ). Siehe auch den FAQ-Bereich zu Schlüsseln und Verifizierung.
Der Zweck der Empfehlung einer Prüfsummenüberprüfung besteht darin, zu überprüfen, ob das Artefakt den Erwartungen entspricht. Dadurch wird sichergestellt, dass sich bei Änderungen des Remote-Inhalts auch die Docker-Datei ändert und ein natürlicher docker build Cache-Bust bereitgestellt wird. Als Bonus wird dadurch auch verhindert, dass versehentlich neuere Artefakte als erwartet auf schlecht versionierte Dateien heruntergeladen werden.
Nachfolgend einige Beispiele:
Bevorzugt : Download über https, vollständiger Fingerabdruckimport des PGP-Schlüssels und asc Verifizierung, eingebettete Prüfsumme verifiziert.
ENV PYTHON_DOWNLOAD_SHA512 (sha512-value-here)
RUN set -eux;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz" -o python.tar.xz;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz.asc" -o python.tar.xz.asc;
export GNUPGHOME= "$(mktemp -d)" ;
# gpg: key F73C700D: public key "Larry Hastings <[email protected]>" imported
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 97FC712E4C024BBEA48A61ED3A5CA953F73C700D;
gpg --batch --verify python.tar.xz.asc python.tar.xz;
rm -r "$GNUPGHOME" python.tar.xz.asc;
echo "$PYTHON_DOWNLOAD_SHA512 *python.tar.xz" | sha512sum --strict --check;
# installAlternativ : vollständiger Schlüssel-Fingerabdruck, der in apt importiert wird, wodurch Signaturen und Prüfsummen überprüft werden, wenn Pakete heruntergeladen und installiert werden.
RUN set -eux;
key= 'A4A9406876FCBD3C456770C88C718D3B5072E1F5' ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$key" ;
gpg --batch --armor --export "$key" > /etc/apt/trusted.gpg.d/mysql.gpg.asc;
gpgconf --kill all;
rm -rf "$GNUPGHOME" ;
apt-key list > /dev/null
RUN set -eux;
echo "deb http://repo.mysql.com/apt/debian/ bookworm mysql-${MYSQL_MAJOR}" > /etc/apt/sources.list.d/mysql.list;
apt-get update;
apt-get install -y mysql-community-client= "${MYSQL_VERSION}" mysql-community-server-core= "${MYSQL_VERSION}" ;
rm -rf /var/lib/apt/lists/*;
# ... (Nebenbei bemerkt, rm -rf /var/lib/apt/lists/* ist ungefähr das Gegenteil von apt-get update – es stellt sicher, dass die Ebene nicht die zusätzlichen ~8 MB an APT-Paketlistendaten enthält, und erzwingt die entsprechende Verwendung apt-get update .)
Weniger sichere Alternative : Betten Sie die Prüfsumme in die Dockerfile ein.
ENV RUBY_DOWNLOAD_SHA256 (sha256-value-here)
RUN set -eux;
curl -fL -o ruby.tar.gz "https://cache.ruby-lang.org/pub/ruby/$RUBY_MAJOR/ruby-$RUBY_VERSION.tar.gz" ;
echo "$RUBY_DOWNLOAD_SHA256 *ruby.tar.gz" | sha256sum --strict --check;
# installHinweis: Die Verwendung von SHA1 oder MD5 sollte als „Prüfsumme des letzten Auswegs“ betrachtet werden, da beide im Allgemeinen als unsicher gelten:
Inakzeptabel : Laden Sie die Datei ohne Überprüfung über http(s) herunter.
RUN curl -fL "https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz" | tar ...
# install Standardmäßig werden Docker-Container mit reduzierten Berechtigungen ausgeführt: Linux-Funktionen auf der Whitelist, Kontrollgruppen und ein Standard-Seccomp-Profil (1.10+ mit Host-Unterstützung). Software, die in einem Container ausgeführt wird, erfordert möglicherweise zusätzliche Berechtigungen, um ordnungsgemäß zu funktionieren, und es gibt eine Reihe von Befehlszeilenoptionen zum Anpassen der Containerausführung. Weitere Informationen finden Sie docker run Referenz und in Seccomp für Docker.
Offizielle Repositories, die zusätzliche Berechtigungen erfordern, sollten den Mindestsatz an Befehlszeilenoptionen angeben, damit die Software funktioniert. Sie können dennoch abgelehnt werden, wenn dies zu erheblichen Portabilitäts- oder Sicherheitsproblemen führt. Im Allgemeinen ist --privileged nicht zulässig, aber eine Kombination der Optionen --cap-add und --device kann akzeptabel sein. Darüber hinaus kann --volume schwierig sein, da es viele Speicherorte im Host-Dateisystem gibt, die Portabilitäts-/Sicherheitsprobleme mit sich bringen (z. B. X11-Socket).
Für Image-Updates, die einen Sicherheitsupdate darstellen, empfehlen wir einige Dinge, um sicherzustellen, dass Ihr Update so schnell wie möglich zusammengeführt, erstellt und veröffentlicht wird:
[email protected] , um uns eine Vorwarnung und einen Zeitvoranschlag zu geben (damit wir die Zeit für das eingehende Update angemessen einplanen können).[security] in den Titel Ihrer Pull-Anfrage ein (z. B. [security] Update FooBar to 1.2.5, 1.3.7, 2.0.1 ). Jedes Repo kann mehrere Architekturen für alle Tags angeben. Wenn keine Architektur angegeben ist, werden Images unter Linux auf amd64 (auch bekannt als x86-64) erstellt. Um mehr oder andere Architekturen anzugeben, verwenden Sie das Feld Architectures (durch Kommas getrennte Liste, Leerzeichen werden entfernt). Gültige Architekturen finden Sie in der Datei oci-platform.go von Bashbrew:
amd64arm32v6arm32v7arm64v8i386mips64leppc64leriscv64s390xwindows-amd64 Die Architectures eines bestimmten Tags müssen eine strikte Teilmenge der Architectures des Tags sein, von dem es FROM .
Bilder müssen über eine einzelne Dockerfile pro Eintrag in der Bibliotheksdatei verfügen, die für mehrere Architekturen verwendet werden kann. Das bedeutet, dass jede unterstützte Architektur die gleiche FROM Zeile hat (z. B. FROM debian:bookworm ). Beispiele für Bibliotheksdateien, die eine Dockerfile pro Eintrag verwenden, finden Sie unter golang , docker , haproxy und php Sehen Sie sich auch die jeweiligen Git-Repos an, zum Beispiel Dockerfile s.
Wenn verschiedene Teile der Docker-Datei nur in der einen oder anderen Architektur vorkommen, verwenden Sie den Kontrollfluss (z. B. if / case ) zusammen mit dpkg --print-architecture oder apk -print-arch , um die Userspace-Architektur zu erkennen. Verwenden Sie uname nur zur Architekturerkennung, wenn genauere Tools nicht installiert werden können. Siehe Golang für ein Beispiel, bei dem einige Architekturen die Erstellung von Binärdateien aus den Upstream-Quellpaketen erfordern und andere lediglich die Binärversion herunterladen.
Für Basis-Images wie debian ist eine andere Dockerfile und ein anderer Build-Kontext erforderlich, um architekturspezifische Binärdateien ADD zu können. Dies ist eine gültige Ausnahme vom oben Gesagten. Da diese Bilder dieselben Tags verwenden, müssen sie sich im selben Eintrag befinden. Verwenden Sie die architekturspezifischen Felder für GitRepo , GitFetch , GitCommit und Directory . Dabei handelt es sich um die Architektur, verkettet mit Bindestrich ( - ) und dem Feld (z. B. arm32v7-GitCommit ). Jede Architektur, die kein architekturspezifisches Feld hat, verwendet das Standardfeld (z. B. „kein arm32v7-Directory bedeutet, dass für arm32v7 Directory verwendet wird). Beispiele finden Sie in den debian oder ubuntu Dateien in der Bibliothek. Das Folgende ist ein Beispiel für hello-world :
Maintainers: Tianon Gravi <[email protected]> (@tianon),
Joseph Ferguson <[email protected]> (@yosifkit)
GitRepo: https://github.com/docker-library/hello-world.git
GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Tags: latest
Architectures: amd64, arm32v5, arm32v7, arm64v8, ppc64le, s390x
# all the same commit; easy for us to generate this way since they could be different
amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
amd64-Directory: amd64/hello-world
arm32v5-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v5-Directory: arm32v5/hello-world
arm32v7-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v7-Directory: arm32v7/hello-world
arm64v8-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm64v8-Directory: arm64v8/hello-world
ppc64le-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
ppc64le-Directory: ppc64le/hello-world
s390x-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
s390x-Directory: s390x/hello-world
Tags: nanoserver
Architectures: windows-amd64
# if there is only one architecture, you can use the unprefixed fields
Directory: amd64/hello-world/nanoserver
# or use the prefixed versions
windows-amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Constraints: nanoserver
Weitere Informationen zum Format der Bibliotheksdatei finden Sie im Abschnitt zum Anweisungsformat.
Der Vorschlag eines neuen offiziellen Erscheinungsbildes sollte nicht auf die leichte Schulter genommen werden. Wir erwarten und verlangen die Verpflichtung, Ihr Image zu pflegen (einschließlich und insbesondere rechtzeitiger Aktualisierungen, wie oben erwähnt).
Bei den Bibliotheksdefinitionsdateien handelt es sich um reine Textdateien, die sich im Verzeichnis library/ “ des Repositorys official-images befinden. Jede Bibliotheksdatei steuert den aktuellen „unterstützten“ Satz von Bild-Tags, die in der Docker Hub-Beschreibung angezeigt werden. Tags, die aus einer Bibliotheksdatei entfernt werden, werden nicht aus dem Docker Hub entfernt, sodass alte Versionen weiterhin zur Verwendung verfügbar sind, aber nicht vom Upstream oder dem Betreuer des offiziellen Images gepflegt werden. Tags in der Bibliotheksdatei werden nur durch eine Aktualisierung dieser Bibliotheksdatei oder als Ergebnis der Aktualisierung ihres Basis-Images erstellt (d. h. ein Image FROM debian:bookworm würde neu erstellt, wenn debian:bookworm erstellt wird). Wenn für eine Basis Aktualisierungen vorliegen, wird nur der Inhalt der Bibliotheksdatei neu erstellt.
Angesichts dieser Richtlinie lohnt es sich, einige Fälle zu klären: Backfill-Versionen, Release-Kandidaten und Continuous-Integration-Builds. Wenn ein neues Repository vorgeschlagen wird, ist es üblich, einige ältere, nicht unterstützte Versionen in den ersten Pull-Request aufzunehmen, mit der Vereinbarung, diese direkt nach der Annahme zu entfernen. Verwechseln Sie dies nicht mit einem umfassenden historischen Archiv, das nicht beabsichtigt ist. Ein weiterer häufiger Fall, in dem der Begriff „unterstützt“ etwas überdehnt wird, betrifft Release Candidates. Ein Release Candidate ist eigentlich nur eine Namenskonvention für Veröffentlichungen mit voraussichtlich kürzerer Lebensdauer, daher sind sie völlig akzeptabel und werden empfohlen. Im Gegensatz zu einem Release-Kandidaten sind Continuous-Integration-Builds mit einem vollständig automatisierten Release-Zyklus auf der Grundlage von Code-Commits oder einem regelmäßigen Zeitplan nicht geeignet.
Es wird dringend empfohlen, einige der vorhandenen library/ Dateiinhalte (und den Verlauf, um ein Gefühl dafür zu bekommen, wie sie sich im Laufe der Zeit ändern) zu durchsuchen, bevor Sie eine neue erstellen, um sich mit den vorherrschenden Konventionen vertraut zu machen und den Überprüfungsprozess weiter zu optimieren (so). dass wir uns auf den Inhalt statt auf esoterische Formatierung oder Tag-Nutzung/Benennung konzentrieren können).
Der Dateiname einer Definitionsdatei bestimmt den Namen des Image-Repositorys, das sie auf dem Docker Hub erstellt. Beispielsweise erstellt die Datei library/ubuntu Tags im ubuntu -Repository.
Die Tags eines Repositorys sollten die Versionen oder Variationen des Upstreams widerspiegeln. Beispielsweise ist Ubuntu 14.04 auch als Ubuntu Trusty Tahr bekannt, oft jedoch einfach als Ubuntu Trusty (insbesondere in der Verwendung), sodass ubuntu:14.04 (Versionsnummer) und ubuntu:trusty (Versionsname) geeignete Aliase für denselben Bildinhalt sind. In Docker ist das latest Tag ein Sonderfall, die Bezeichnung ist jedoch etwas irreführend. latest ist eigentlich das „default“-Tag. Wenn man docker run xyz ausführt, interpretiert Docker dies als docker run xyz:latest . Vor diesem Hintergrund enthält kein anderes Tag jemals die Zeichenfolge latest , da von Benutzern nicht erwartet oder ermutigt wird, sie tatsächlich einzugeben (dh xyz:latest sollte eigentlich einfach als xyz verwendet werden). Anders ausgedrückt: Ein Alias für die „höchste Version der 2.2-Serie von XYZ“ sollte xyz:2.2 und nicht xyz:2.2-latest lauten. Wenn es eine Alpine-Variante von xyz:latest gibt, sollte diese ebenfalls als xyz:alpine bezeichnet werden, nicht als xyz:alpine-latest oder xyz:latest-alpine .
Es wird dringend empfohlen, den Versionsnummern-Tags Aliase zu geben, die es dem Benutzer erleichtern, auf der „aktuellsten“ Version einer bestimmten Serie zu bleiben. Angesichts der derzeit unterstützten XYZ-Softwareversionen 2.3.7 und 2.2.4 wären die vorgeschlagenen Aliase beispielsweise Tags: 2.3.7, 2.3, 2, latest bzw. Tags: 2.2.4, 2.2 . In diesem Beispiel kann der Benutzer xyz:2.2 verwenden, um problemlos die neueste Patch-Version der 2.2-Serie zu verwenden, oder xyz:2 , wenn weniger Granularität erforderlich ist (Python ist ein gutes Beispiel dafür, wo dies am offensichtlichsten nützlich ist – python:2 . und python:3 sind sehr unterschiedlich und können als das latest Tag für jeden der Hauptveröffentlichungstitel von Python betrachtet werden.
Wie oben beschrieben, ist latest wirklich „Standard“, sodass das Bild, für das es ein Alias ist, widerspiegeln sollte, welche Version oder Variation der Software Benutzer verwenden sollten, wenn sie nicht wissen, welche Version sie verwenden, oder es ihnen egal ist. Am Beispiel von Ubuntu verweist ubuntu:latest auf die neueste LTS-Version, da diese von der Mehrheit der Benutzer verwendet werden sollte, wenn sie wissen, dass sie Ubuntu möchten, aber nicht wissen oder sich nicht darum kümmern, welche Version sie verwenden wird (insbesondere, wenn man bedenkt, dass es die sein wird). "stabilste" und am besten unterstützte Version zu einem bestimmten Zeitpunkt).
Das Manifestdateiformat basiert offiziell auf RFC 2822 und sollte daher denjenigen bekannt sein, die bereits mit den „Headern“ vieler beliebter Internetprotokolle/-formate wie HTTP oder E-Mail vertraut sind.
Die primären Ergänzungen sind von der Art und Weise inspiriert, wie Debian üblicherweise 2822 verwendet – nämlich Zeilen, die mit # beginnen, werden ignoriert und „Einträge“ werden durch eine Leerzeile getrennt.
Der erste Eintrag sind die „globalen“ Metadaten für das Bild. Das einzige erforderliche Feld im globalen Eintrag ist Maintainers , dessen Wert durch Kommas im Format Name <email> (@github) oder Name (@github) getrennt ist. Jedes im globalen Eintrag angegebene Feld gilt als Standard für die übrigen Einträge und kann in einem einzelnen Eintrag überschrieben werden.
# this is a comment and will be ignored
Maintainers: John Smith <[email protected]> (@example-jsmith),
Anne Smith <[email protected]> (@example-asmith)
GitRepo: https://github.com/example/docker-example.git
GitCommit: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# this is also a comment, and will also be ignored
Tags: 1.2.3, 1.2, 1, latest
Directory: 1
Tags: 2.0-rc1, 2.0-rc, 2-rc, rc
GitRepo: https://github.com/example/docker-example-rc.git
GitFetch: refs/heads/2.0-pre-release
GitCommit: beefdeadbeefdeadbeefdeadbeefdeadbeefdead
Directory: 2
File: Dockerfile-to-use
Bashbrew ruft beim angegebenen Commit ( GitCommit ) Code aus dem Git-Repository ( GitRepo ) ab. Wenn der referenzierte Commit nicht vom Fetching- master des zugehörigen GitRepo verfügbar ist, muss ein Wert für GitFetch angegeben werden, um Bashbrew mitzuteilen, welchen Ref abgerufen werden soll, um den erforderlichen Commit zu erhalten.
Das erstellte Image wird mit <manifest-filename>:<tag> versehen (d. h. library/golang mit einem Tags Wert von 1.6, 1, latest erstellt die Tags „ golang:1.6 , golang:1 “ und „ golang:latest “).
Wenn Directory vorhanden ist, sucht Bashbrew optional nach der Dockerfile im angegebenen Unterverzeichnis statt im Stammverzeichnis (und Directory wird als „Kontext“ für den Build anstelle der obersten Ebene des Repositorys verwendet). Wenn File vorhanden ist, wird der angegebene Dateiname anstelle von Dockerfile verwendet.
Weitere Informationen zum Angeben eines anderen GitRepo , GitFetch , GitCommit oder Directory für eine bestimmte Architektur finden Sie im Abschnitt „Multi-Arch“.
library/ . Sein Name ist der Name Ihres Repositorys auf dem Hub. Bashbrew ( bashbrew ) ist ein Tool zum Klonen, Erstellen, Markieren und Übertragen der offiziellen Docker-Images. Weitere Informationen finden Sie in der Bashbrew- README .
