Docker/Image/Erstellung

Image-Erstellung

Bewährte Praktiken für die Image-Erstellung

Image-Schichtung

Mit dem Befehl docker image history können Sie den Befehl sehen, mit dem jede Schicht innerhalb eines Images erstellt wurde.# Verwenden Sie den Befehl docker image history, um die Schichten in dem von Ihnen erstellten Getting-Started-Image anzuzeigen

docker image history getting-started

Sie sollten eine Ausgabe erhalten, die in etwa wie die folgende aussieht.* IMAGE CREATED CREATED BY GRÖSSE KOMMENTAR

a78a40cbf866 vor 18 Sekunden /bin/sh -c #(nop) CMD ["node" "src/index.j... 0B

f1d1808565d6 vor 19 Sekunden /bin/sh -c yarn install --production 85.4MB

a2c054d14948 Vor 36 Sekunden /bin/sh -c #(nop) COPY dir:5dc710ad87c789593... 198kB

9577ae713121 vor 37 Sekunden /bin/sh -c #(nop) WORKDIR /app 0B

b95baba1cfdb vor 13 Tagen /bin/sh -c #(nop) CMD ["node"] 0B

<fehlt> vor 13 Tagen /bin/sh -c #(nop) ENTRYPOINT ["docker-entry... 0B

<fehlt> Vor 13 Tagen /bin/sh -c #(nop) COPY file:238737301d473041... 116B

<fehlt> vor 13 Tagen /bin/sh -c apk add --no-cache --virtual .bui... 5.35MB

<fehlt> vor 13 Tagen /bin/sh -c #(nop) ENV YARN_VERSION=1.21.1 0B

<Fehlt> Vor 13 Tagen /bin/sh -c addgroup -g 1000 node && addu... 74.3MB

<fehlt> Vor 13 Tagen /bin/sh -c #(nop) ENV NODE_VERSION=12.14.1 0B

<fehlt> Vor 13 Tagen /bin/sh -c #(nop) CMD ["/bin/sh"] 0B

<fehlt> vor 13 Tagen /bin/sh -c #(nop) ADD file:e69d441d729412d24... 5.59MB

Jede der Zeilen steht für eine Ebene im Bild. Die Anzeige hier zeigt die Basis am unteren Rand und die neueste Ebene am oberen Rand. Auf diese Weise können Sie auch schnell die Größe der einzelnen Ebenen erkennen, was bei der Diagnose großer Bilder hilfreich ist.* Sie werden feststellen, dass einige der Zeilen abgeschnitten sind. Wenn Sie das --no-trunc-Flag hinzufügen, erhalten Sie die vollständige Ausgabe

1. docker image history --no-trunc getting-started

Layer-Caching

Nachdem Sie nun die Schichtung in Aktion gesehen haben, gibt es eine wichtige Lektion zu lernen, die dazu beiträgt, die Erstellungszeiten für Ihre Container-Abbilder zu verkürzen. Sobald sich eine Schicht ändert, müssen alle nachgelagerten Schichten ebenfalls neu erstellt werden

Sehen Sie sich das folgende Dockerfile an, das Sie für die Getting Started App erstellt haben

# syntax=docker/dockerfile:1

FROM node:lts-alpine

WORKDIR /app

COPY .

RUN yarn install --production

CMD ["node", "src/index.js"]

Wenn Sie sich die Ausgabe der Image-Historie ansehen, sehen Sie, dass jeder Befehl im Dockerfile zu einer neuen Ebene im Image wird. Sie erinnern sich vielleicht daran, dass bei einer Änderung am Image die Garn-Abhängigkeiten neu installiert werden mussten. Es ist nicht sehr sinnvoll, bei jedem Build die gleichen Abhängigkeiten mitzuschleppen

Um dies zu beheben, müssen Sie Ihr Dockerfile umstrukturieren, um das Zwischenspeichern der Abhängigkeiten zu unterstützen. Bei Node-basierten Anwendungen werden diese Abhängigkeiten in der package.json-Datei definiert. Sie können zuerst nur diese Datei hineinkopieren, die Abhängigkeiten installieren und dann alles andere hineinkopieren. Dann erstellen Sie die Garn-Abhängigkeiten nur dann neu, wenn es eine Änderung in der package.json gibt.# Aktualisieren Sie die Dockerdatei, um zuerst die package.json zu kopieren, die Abhängigkeiten zu installieren und dann alles andere hineinzukopieren

• # syntax=docker/dockerfile:1

FROM node:lts-alpine

WORKDIR /app

COPY package.json yarn.lock ./

RUN yarn install --production

COPY .

CMD ["node", "src/index.js"]* Erstellen Sie ein neues Image mit docker build

docker build -t getting-started

Sie sollten eine Ausgabe wie die folgende sehen.* [+] Bauen 16.1s (10/10) BEENDET

=> [intern] Build-Definition aus Dockerfile laden

=> Übertragen des Dockerfiles: 175B

=> [internal] load .dockerignore

=> Übertragen von Kontext: 2B

=> [intern] lade Metadaten für docker.io/library/node:lts-alpine

=> [internal] load build context

=> Übertragen des Kontextes: 53.37MB

=> [1/5] FROM docker.io/library/node:lts-alpine

=> CACHED [2/5] WORKDIR /app

=> [3/5] COPY package.json yarn.lock ./

=> [4/5] RUN yarn install --production

=> [5/5] COPY .

=> exportieren nach image

=> Exportieren von Schichten

=> Schreiben des Images sha256:d6f819013566c54c50124ed94d5e66c452325327217f4f04399b45f94e37d25

=> => Umbenennung in docker.io/library/getting-started* Nehmen Sie nun eine Änderung an der Datei src/static/index.html vor. Ändern Sie zum Beispiel den <title> in "The Awesome Todo App"

• Erstellen Sie nun das Docker-Image mit docker build -t getting-started . erneut. Diesmal sollte die Ausgabe ein wenig anders aussehen

1. [+] Bauen 1.2s (10/10) BEENDET

=> [intern] lade Build-Definition aus Dockerfile

=> Übertragen des Dockerfiles: 37B

=> [internal] load .dockerignore

=> Übertragen von Kontext: 2B

=> [intern] lade Metadaten für docker.io/library/node:lts-alpine

=> [internal] load build context

=> Übertragen des Kontextes: 450.43kB

=> [1/5] FROM docker.io/library/node:lts-alpine

=> CACHED [2/5] WORKDIR /app

=> CACHED [3/5] COPY package.json yarn.lock ./

=> CACHED [4/5] RUN yarn install --production

=> [5/5] COPY .

=> exportieren nach image

=> Exportieren von Schichten

=> Schreiben des Images sha256:91790c87bcb096a83c2bd4eb512bc8b134c757cda0bdee4038187f98148e2eda

=> Benennung in docker.io/library/getting-started

Zunächst einmal sollten Sie feststellen, dass die Erstellung viel schneller war. Und Sie werden sehen, dass mehrere Schritte zuvor zwischengespeicherte Ebenen verwenden. Das Pushen und Ziehen dieses Bildes und die Aktualisierungen werden ebenfalls viel schneller sein

Mehrstufige Builds

Mehrstufige Builds sind ein unglaublich leistungsfähiges Werkzeug, um ein Bild in mehreren Stufen zu erstellen. Sie bieten mehrere Vorteile

• Trennung von Build-Abhängigkeiten und Laufzeit-Abhängigkeiten
• Verringern Sie die Gesamtgröße des Images, indem Sie nur das ausliefern, was Ihre Anwendung zum Laufen braucht

Beispiel Maven/Tomcat

Wenn Sie Java-basierte Anwendungen erstellen, benötigen Sie ein JDK, um den Quellcode in Java-Bytecode zu kompilieren. In der Produktion wird dieses JDK jedoch nicht benötigt. Möglicherweise verwenden Sie auch Tools wie Maven oder Gradle, um die Anwendung zu erstellen. Auch diese werden in Ihrem endgültigen Image nicht benötigt. Mehrstufige Builds helfen

# syntax=docker/dockerfile:1

FROM maven AS build

WORKDIR /app

COPY .

RUN mvn paket

FROM tomcat

COPY --from=build /app/target/file.war /usr/local/tomcat/webapps

In diesem Beispiel verwenden Sie eine Stufe (genannt build), um den eigentlichen Java-Build mit Maven durchzuführen. In der zweiten Phase (beginnend mit FROM tomcat) kopieren Sie die Dateien aus der build-Phase hinein. Das endgültige Bild ist nur die letzte Stufe, die erstellt wird, was mit dem Flag --target überschrieben werden kann

React-Beispiel

Bei der Erstellung von React-Anwendungen benötigen Sie eine Node-Umgebung, um den JS-Code (typischerweise JSX), SASS-Stylesheets und mehr in statisches HTML, JS und CSS zu kompilieren. Wenn Sie kein serverseitiges Rendering durchführen, benötigen Sie nicht einmal eine Node-Umgebung für Ihren Produktions-Build. Sie können die statischen Ressourcen in einem statischen Nginx-Container ausliefern

# syntax=docker/dockerfile:1

FROM node:lts AS build

WORKDIR /app

COPY paket* yarn.lock ./

RUN yarn install

COPY public ./public

COPY src ./src

RUN yarn run build

FROM nginx:alpine

COPY --from=build /app/build /usr/share/nginx/html

Im vorherigen Dockerfile-Beispiel wird das node:lts-Image verwendet, um den Build durchzuführen (Maximierung der Zwischenspeicherung von Schichten), und dann wird die Ausgabe in einen nginx-Container kopiert

Zusammenfassung

In diesem Abschnitt haben Sie einige Best Practices für die Image-Erstellung kennengelernt, darunter Layer-Caching und mehrstufige Builds

Verwandte Informationen

• Dockerfile-Referenz
• Bewährte Verfahren für Dockerfile

Nächste Schritte

Im nächsten Abschnitt erfahren Sie mehr über zusätzliche Ressourcen, die Sie nutzen können, um weiter über Container zu lernen.