Mit der Docker- ONBUILDAnweisung können Sie Trigger innerhalb eines Bildes einrichten. Ihre Trigger werden später ausgeführt, wenn das Bild als Basis für ein anderes verwendet wird. Sie werden Teil des neuen Downstream-Image-Kontexts und sind keine Dateisystemschichten in Ihrer anfänglichen docker build.

Hinzufügen von ONBUILD-Triggern

ONBUILDist eine Anweisung, die Sie in Ihre Dockerfiles schreiben. Es ist einzigartig, da es eine andere Anweisung als Argument akzeptiert . Sie können einen beliebigen Dockerfile-Vorgang angeben, z. B. COPYoder RUN, und ihn während eines Downstream-Image-Builds ausführen lassen.

ONBUILD RUN Beispielbefehl

Dieses Beispiel example-commandwird zum Zeitpunkt der Erstellung im untergeordneten Image ausgeführt. Hier ist ein weiterer Fall, in dem eine Datei aus dem Build-Kontext des Downstream-Images in das Dateisystem kopiert wird:

ONBUILD-KOPIE „assets.json /app/assets.json“.

ONBUILDAnweisungen haben keinerlei Auswirkung auf das Image, das von der Docker-Datei erzeugt wird, in der sie definiert sind. Das Erstellen der obigen Docker-Datei würde nicht ausgeführt example-commandoder assets.jsonin das Image aufgenommen:

# Enthält keine zusätzlichen Anweisungen docker build -t base-image:latest .

Die Trigger werden verwendet, wenn Sie eine weitere Docker-Datei schreiben, die die erste als Basis verwendet:

FROM base-image:neueste RUN my-binary
docker build -t Downstream-Image:latest .

Das Erstellen dieser Docker-Datei wird ausgeführt example-command, hineinkopiert assets.jsonund schließlich ausgeführt my-binary. Die ONBUILDTrigger werden immer zuerst ausgeführt, unmittelbar nach der FROMAnweisung im Downstream-Dockerfile.

Wie erkennt Docker Trigger?

ONBUILDwirkt sich nicht auf das Dateisystem des Basiscontainers aus, aber Docker weiß immer noch, dass Trigger vorhanden sind, wenn Sie ein Downstream-Image erstellen. Der Erstellungsprozess verfolgt die gefundenen ONBUILDAnweisungen und zeichnet sie in den Metadaten des Bildes auf. Docker untersucht die Metadaten der Bilder, auf die in einer FROMAnweisung verwiesen wird. Wenn das benannte Image Trigger in seinen Metadaten enthält, werden diese Trigger-Anweisungen effektiv am Anfang der Downstream-Dockerfile eingefügt, bevor der Build beginnt. Trigger werden tatsächlich als Teil der FROMPhase des Builds ausgeführt. Sie werden in der Reihenfolge ausgeführt, in der sie in das Upstream-Dockerfile geschrieben wurden. Wenn eine ONBUILDAnweisung fehlschlägt, bricht Docker den Build ab und es sieht so aus, als wäre die FROMPhase die Ursache gewesen.

Einschränkungen

Sie können jede Dockerfile-Anweisung als Argument für einen ONBUILDTrigger verwenden, mit drei Ausnahmen:

  • ONBUILD FROM– Dies ist nicht zulässig, da es das für den Build verwendete Basisimage überschreiben würde. Jedes Dockerfile muss von einer einzigen Basis erben.
  • ONBUILD MAINTAINER– Die MAINTAINERAnweisung ist veraltet und sollte nicht verwendet werden; Angaben zur Urheberschaft werden am besten als Label geliefert. Die LABELAnleitung ist kompatibel mit ONBUILD.
  • ONBUILD ONBUILD– Das Verketten von ONBUILDAnweisungen wird nicht unterstützt. Alle Trigger werden im Image unmittelbar nach Ihrem Dockerfile ausgeführt. Sie können keine Trigger definieren, die in „Enkel“-Images zwei oder mehr Ebenen unterhalb der definierenden Dockerfile ausgeführt werden sollen.

Alle Befehle sind genauso definiert wie ihre reguläre Verwendung. Wenn Sie einen gewöhnlichen Schritt in Ihr Dockerfile schreiben und ihm dann das Präfix voranstellen, ONBUILDwird er aus dem normalen Build-Flow herausbewegt und stattdessen zu einem nachgelagerten Build-Trigger.

Wann sind ONBUILD-Trigger nützlich?

ONBUILDwird am häufigsten in Utility-Images verwendet, die Aufgaben wie die Codekompilierung automatisieren. Diese Art von Verfahren erfordert im Allgemeinen die Ausführung mehrerer Schritte in einer bestimmten Reihenfolge, wobei Abhängigkeiten wie Ihr Quellcode an einer bestimmten Stelle hinzugefügt werden. Stellen Sie sich ein Kompilierungs-Image vor, das in einem Verzeichnis nach Quellcode sucht und dann einen Befehl ausführt, um es zu erstellen. Sie können nicht einfach COPYund RUNinnerhalb der Docker-Datei dieses Bildes, da die Quelle des Endbenutzers nicht im Build-Kontext Ihres Bildes vorhanden wäre. Mit ONBUILDkönnen Sie eine Boilerplate Dockerfile bereitstellen, die Ihre Benutzer erweitern können, docker buildohne die allgemeine Funktionalität neu zu erfinden:

ENV BUILD_ENV=Produktion Führen Sie init-build.sh aus ONBUILD COPY /src /build ONBUILD RUN compile.sh --destination=/bin

Dieses Beispiel zeigt, wie ein Builder-Image eine vorkonfigurierte Kompilierungsumgebung bereitstellen könnte. Bei Verwendung als Basisimage wird Code automatisch aus dem nachgelagerten Buildkontext kompiliert. Dieses Bild könnte mit der kompilierten Ausgabe /bininnerhalb seiner eigenen Dockerfile-Phasen interagieren.

Zusammenfassung

ONBUILDAnweisungen in Dockerfiles geben Ihnen die Möglichkeit, Trigger als Teil eines Downstream-Builds auszuführen. ONBUILDAbgesehen von einigen Einschränkungen können Sie jede andere Dockerfile-Anweisung als Trigger verwenden. Mit ONBUILDkönnen Sie generische Docker-Images bereitstellen, die wiederverwendbare Funktionssätze definieren. Dies ist effizienter, als Benutzer den Text von Beispiel-Dockerfiles wörtlich kopieren zu lassen und dann ihre eigenen Anweisungen unten hinzuzufügen. Sie können das Basisimage weiterhin ändern und aktualisieren, ohne dass Ihre Benutzer eingreifen müssen. ONBUILDDie Übernahme reduziert Wiederholungen und erleichtert erweiterbare Docker-Basisimages . ONBUILDAnweisungen sind eine Überlegung wert, wenn Sie ein Boilerplate-Dockerfile erstellen, das von Endbenutzern angepasst werden muss, bevor die endgültige Containerumgebung als vollständig betrachtet wird. WEITER LESEN

  • › So wechseln Sie Apple Watch Faces automatisch
  • › So synchronisieren Sie Farbeinstellungen zwischen Adobe-Apps
  • › So entsperren Sie Facebook
  • › So fügen Sie einem Dokument unter Windows und Mac das Copyright-Symbol hinzu
  • › So nehmen Sie Audio auf einem Android-Telefon auf
  • › So nutzen Sie Ihr Auto während eines Stromausfalls als Notstromquelle

Vorschlag: TRIGGER Dockerfile-Anweisung

Dies ist ein Vorschlag, die ONBUILDDockerfile-Anweisung in einen flexiblen Mechanismus zu verallgemeinern TRIGGER.

Rational

ONBUILDist ein sehr einfacher Mechanismus, der die offiziellen und andere beliebte Basis-Images (ab)verwendet:
https://registry.hub.docker.com/u/_/golang
https://registry.hub.docker.com/u/ google/golang-runtime/
https://registry.hub.docker.com/u/_/node
https://registry.hub.docker.com/u/google/nodejs-runtime

Es ermöglicht Benutzern, ihre Anwendung mit sehr wenigen Anweisungen in ihrer Docker-Datei einfach zu docken :

Die ONBUILDAnweisungen werden automatisch aus dem übergeordneten Bild direkt nach der eingefügt FROM.

Wenn Sie also eine Basis haben mit:

ONBUILD ADD package.json /app/ ONBUILD RUN npm install ONBUILD ADD . /app/ 

und ein Kinderbild mit

Es wird zu führen

FROM base ADD package.json /app/ RUN npm install ADD . /app/ 

Wenn Sie jedoch ein untergeordnetes Bild haben mit:

FROM base RUN apt-get install -yq fortunes 

Daraus ergibt sich:

FROM base ADD package.json /app/ RUN npm install ADD . /app/ RUN apt-get install -yq fortunes 

Dadurch wird die Ebene w / apt-get installjedes Mal, wenn Sie eine Datei in Ihrem Kontext ändern, aus dem Cache ungültig gemacht.

Vorschlag

Mit der Anweisung können Sie Anweisungen von einem übergeordneten Bild TRIGGERauslösen .Dockerfile

Wenn ein übergeordnetes Bild definiert:

ONBUILD ADD package.json /app/ ONBUILD RUN npm install ONBUILD ADD . /app/ 

Ein untergeordnetes Bild kann entscheiden, wo die ONBUILDAnweisungen ausgelöst werden sollen mit:

FROM BASE RUN apt-get install fortunes TRIGGER ONBUILD RUN fortune -m perl 

Ergebnis:

RUN apt-get install fortunes ADD package.json /app/ RUN npm install ADD . /app/ RUN fortune -m perl 

Der Standardwert wäre immer noch TRIGGER ONBUILDkurz nach FROM, wenn keine anderen TRIGGER ONBUILDAnweisungen in der Dockerdatei gefunden werden.

Zweimal laufen TRIGGER ONBUILDsollte(?) verboten sein.

Anhang

(#vielleicht #später #eines Tages)

Der Mechanismus könnte dann erweitert werden, um das Auslösen aller im übergeordneten Bild annotierten Dockerfile-Anweisungen zu ermöglichen.

Siehe das überkomplizierte Beispiel unten:

Base:

@SECURE RUN apt-get update && apt-get install -yq bash @NPM ADD package.json /app @NPM RUN npm install @BOWER ADD bower.json /app @BOWER RUN bower install @GULP RUN gulp test @GULP RUN gulp build 

Kind:

FROM base IMPORT SECURE, NPM, BOWER, GULP TRIGGER SECURE RUN apt-get install fortunes TRIGGER NPM RUN curl some/file TRIGGER BOWER ADD . /app TRIGGER GULP  

Ergebnis:

FROM base RUN apt-get update && apt-get install -yq bash RUN apt-get install fortunes ADD package.json /app RUN npm install RUN curl some/file ADD bower.json /app RUN bower install ADD . /app RUN gulp test RUN gulp build 

Klassisch ONBUILDwäre dann ein Sonderfall der allgemeineren TRIGGERFunktionalität und das nachgeschaltete Bild könnte Klassisch ONBUILDmit einem leeren Opt-out IMPORT.

IMPORTDie eingegebenen Anweisungen würden an der entsprechenden TRIGGER-Stelle oder danach eingefügt, FROMwenn sie nicht explizit ausgelöst werden.

Änderungsprotokoll

  • 20.12. Tippfehler behoben, Syntax aktualisiert, @discordianfish- IMPORTVorschlag hinzugefügt.


Leave a comment

Your email address will not be published. Required fields are marked *