So verwenden Sie Docker zum Bereitstellen von Front-End-Anwendungen

Docker erfreut sich immer größerer Beliebtheit. Es kann die Umgebung leicht und flexibel isolieren, die Kapazität erweitern und das Betriebs- und Wartungsmanagement vereinfachen. Darüber hinaus ist es für Entwickler bequemer, zu entwickeln, zu testen und bereitzustellen.
Das Wichtigste ist, dass Sie, wenn Sie mit einem unbekannten Projekt konfrontiert sind, der Docker-Datei folgen und es schnell lokal zum Laufen bringen können, ohne auch nur die Dokumentation lesen zu müssen (die Dokumentation ist möglicherweise nicht vollständig und möglicherweise nicht korrekt).

Das Konzept von DevOps wird heutzutage sehr betont. Ich habe die fünf großen Worte „DevOps“ auf meinen Computer-Desktop gelegt und den ganzen Tag damit verbracht, sie zu studieren. Plötzlich dämmerte mir, dass DevOps bedeutet, eine Docker-Datei zu schreiben, um eine Anwendung auszuführen (nur ein Scherz).

Hier stellen wir vor, wie man Docker zum Bereitstellen von Front-End-Anwendungen verwendet. Eine tausend Meilen lange Reise beginnt mit einem einzigen Schritt. Schritt bedeutet, es erst einmal zum Laufen zu bringen.

Erstmal laufen lassen

Lassen Sie uns zunächst kurz einen typischen Bereitstellungsprozess für Front-End-Anwendungen vorstellen.

1. npm install, Abhängigkeiten installieren
2. npm run: Erstellen, Kompilieren, Verpacken, Generieren statischer Ressourcen
3. Bereitstellen statischer Ressourcen

Nach der Einführung des Bereitstellungsprozesses schreiben Sie einfach eine Docker-Datei

VON Knoten: alpin

# Stellt die Produktionsumgebung ENV PROJECT_ENV production dar
ARBEITSVERZEICHNIS /code
HINZUFÜGEN ./Code
RUN npm install && npm run build && npm install -g http-server
AUSSETZEN 80

CMD http-server ./public -p 80

Jetzt läuft der Front-End-Dienst. Anschließend können Sie die weiteren Phasen der Bereitstellung abschließen. Im Allgemeinen handelt es sich bei der folgenden Arbeit um Betrieb und Wartung, es ist jedoch immer eine gute Idee, die Grenzen Ihres Wissens zu erweitern.

• Verwenden Sie nginx oder traefik als Reverse-Proxy
• Verwenden Sie Kubernetes oder Compose zur Orchestrierung.
• Verwenden Sie gitlab ci oder drone ci für CI/CD

Derzeit gibt es zwei Probleme mit dem Image, die dazu führen, dass jede Bereitstellung zu lange dauert und einer schnellen Auslieferung des Produkts nicht förderlich ist.

• Der Aufbau des Images dauert zu lange
• Die Größe des erstellten Images ist zu groß, 1G+

Beginnen Sie mit Abhängigkeiten und devDependencies

Lu Xiaofeng hat einmal gesagt, dass für einen Front-End-Programmierer mindestens zwei Stunden verschwendet seien, wenn er acht Stunden am Tag arbeite. Eine Stunde für die NPM-Installation und eine weitere Stunde für den NPM-Run-Build.

Wenn Sie bei jeder Bereitstellung den Download nutzloser Pakete reduzieren können, können Sie viel Zeit beim Erstellen von Images sparen. Codestil-Testmodule wie eslint, mocha, chai usw. können in devDependencies platziert werden. Verwenden Sie npm install --production, um das Paket in einer Produktionsumgebung zu installieren.

Informationen zum Unterschied zwischen den beiden finden Sie im Dokument https://docs.npmjs.com/files/package.json.html#dependencies.

VON Knoten: alpin

ENV PROJECT_ENV Produktion
ARBEITSVERZEICHNIS /code
HINZUFÜGEN ./Code
RUN npm install --production und npm run build und npm install -g http-server
AUSSETZEN 80

CMD http-server ./public -p 80

Es scheint etwas schneller zu sein.

Uns ist aufgefallen, dass package.json im Vergleich zu den Quelldateien des Projekts relativ stabil ist. Wenn kein neues Installationspaket zum Herunterladen vorhanden ist, muss das Paket beim erneuten Erstellen des Images nicht erneut installiert werden. Sie können bei der npm-Installation die Hälfte der Zeit sparen.

Bild-Caching nutzen

Für ADD kann der Cache verwendet werden, wenn sich der hinzuzufügende Inhalt nicht geändert hat. Es ist eine gute Idee, package.json von den Quelldateien zu trennen und in das Image zu schreiben. Derzeit, wenn es kein neues Installationspaket-Update gibt, können Sie die Hälfte der Zeit sparen

VON Knoten: alpin

ENV PROJECT_ENV Produktion

# http-Server kann auch den Cache verwenden, wenn er sich nicht ändert RUN npm install -g http-server

ARBEITSVERZEICHNIS /code

HINZUFÜGEN von package.json /code
Führen Sie den Befehl npm install --production aus.

HINZUFÜGEN ./Code
AUSFÜHREN npm run build
AUSSETZEN 80

CMD http-server ./public -p 80

Es gibt weitere Details zur Verwendung des Cache, die besondere Aufmerksamkeit erfordern, wie z. B. der Cache von RUN git clone <repo>

Siehe die offizielle Dokumentation https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache

Mehrstufige Builds

Dank Caching sind die Bildaufbauzeiten jetzt viel schneller. Allerdings ist die Größe des Images immer noch zu groß, was die Zeit jeder Bereitstellung verlängert. Berücksichtigen Sie den Prozess jeder CI-Bereitstellung.

1. Erstellen von Images auf einem Build-Server
2. Übertragen Sie das Image auf den Image-Repository-Server.
3. Ziehen Sie das Image auf den Produktionsserver und starten Sie den Container

Eine große Bildgröße führt offensichtlich zu einer geringen Übertragungseffizienz und erhöht die Verzögerung bei jeder Bereitstellung.

Selbst wenn sich der Build-Server und der Produktionsserver auf demselben Knoten befinden, gibt es kein Verzögerungsproblem. Durch die Reduzierung der Bildgröße kann auch Speicherplatz gespart werden

Was die übermäßige Größe des Bildes betrifft, ist ein großer Teil davon auf die berüchtigte Größe der Node_Module zurückzuführen.

Aber letztendlich brauchen wir nur den Inhalt im öffentlichen Ordner. Die Quelldateien und Dateien unter node_modules beanspruchen zu viel Platz und sind unnötig, was zu Verschwendung führt.
An diesem Punkt können Sie den mehrstufigen Build von Docker verwenden, um nur die kompilierten Dateien zu extrahieren

Siehe die offizielle Dokumentation https://docs.docker.com/develop/develop-images/multistage-build/

VON node:alpine als Builder

ENV PROJECT_ENV Produktion

# http-Server ändert sich nicht und kann auch Cache WORKDIR /code verwenden

HINZUFÜGEN von package.json /code
Führen Sie den Befehl npm install --production aus.

HINZUFÜGEN ./Code
AUSFÜHREN npm run build

# Wählen Sie ein kleineres Basis-Image VON nginx:alpine
KOPIEREN --from=builder /code/public /usr/share/nginx/html

Zu diesem Zeitpunkt ist die Bildgröße von 1G+ auf 50M+ gestiegen

CDN verwenden

Bei der Analyse der Bildgröße von über 50 M ist das Bild nginx:alpine 16 M groß und die restlichen 40 M sind statische Ressourcen.

Wenn Sie statische Ressourcen auf CDN hochladen, müssen Sie sie nicht in das Bild einfügen. In diesem Fall wird die Bildgröße auf unter 20 MB begrenzt.

Statische Ressourcen können in zwei Teile eingeteilt werden:

• /static, solche Dateien verweisen direkt auf den Stammpfad im Projekt, werden beim Verpacken nach /public kopiert und müssen in das Image aufgenommen werden
• /build, solche Dateien müssen erforderlich sein, werden von webpack gepackt und mit Hash-Werten versehen, und die Ressourcenadresse kann über publicPath geändert werden. Solche Dateien können auf CDN hochgeladen und dauerhaft zwischengespeichert werden, ohne dass sie gespiegelt werden müssen.

VON node:alpine als Builder

ENV PROJECT_ENV Produktion

# http-Server ändert sich nicht und kann auch Cache WORKDIR /code verwenden

HINZUFÜGEN von package.json /code
Führen Sie den Befehl npm install --production aus.

HINZUFÜGEN ./Code
# npm run uploadCdn ist eine Skriptdatei, die statische Ressourcen auf das CDN hochlädt. RUN npm run build && npm run uploadCdn


# Wählen Sie ein kleineres Basis-Image VON nginx:alpine
KOPIEREN --from=builder code/public/index.html code/public/favicon.ico /usr/share/nginx/html/
KOPIEREN --from=Builder-Code/öffentlich/statisch /usr/share/nginx/html/statisch

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.