Gängige Methoden zur Optimierung der Docker-Imagegröße

Die Docker-Images, die wir normalerweise erstellen, sind normalerweise groß und beanspruchen viel Speicherplatz. Bei der groß angelegten Bereitstellung von Containern werden auch wertvolle Bandbreitenressourcen verschwendet. In diesem Artikel werden verschiedene gängige Methoden zur Optimierung der Größe von Docker-Images vorgestellt. Hier verwenden wir zur Veranschaulichung das Redis-Image auf dem offiziellen Docker Hub.

Manuelle Verwaltung

Die Methode, die uns direkt einfällt, besteht darin, die offizielle Dockerfile-Datei des Redis-Images direkt zu ändern, die nach der Ausführung des Containers nicht benötigten Komponenten manuell zu löschen und dann ein neues Image neu zu erstellen. Diese Methode ist theoretisch möglich, jedoch fehleranfällig und der Effekt ist nicht besonders offensichtlich. Das Hauptproblem besteht darin, dass es nicht in Echtzeit mit dem offiziellen Mirror synchronisiert werden kann.

Mehrstufige Builds

Docker bietet seit Version 17.05 eine mehrstufige Build-Funktion, um dieses Problem zu lösen. Dieser Ansatz wird erreicht, indem die Zwischenschicht verworfen und die Zwischenschicht verwendet wird, um Informationen darüber bereitzustellen, wie das endgültige Image und sein Inhalt erstellt werden. Nur die für die containerisierte Anwendung erforderlichen Komponenten müssen beibehalten werden. Die Implementierung auf höherer Ebene sieht wie folgt aus:

• Verwenden Sie einige Bilder als Grundlage für den Aufbau
• Führen Sie den Befehl wie gewohnt aus, um Ihre Anwendung zu erstellen
• Kopieren Sie die erforderlichen Artefakte in ein separates Image
  

Distroless

Nachdem Google stark auf Containerisierungstechnologie, insbesondere Docker, gesetzt hat, ist sich das Unternehmen seit langem der Nachteile der Verwendung aufgeblähter Images bewusst. Deshalb haben sie ihre eigene Lösung für dieses Problem bereitgestellt, nämlich Distroless-Images. Anders als bei typischen Linux-Basisimages (die eine Menge Software bündeln) enthält das endgültige Image beim Dockerisieren Ihrer Anwendung auf Distroless nur die Anwendung und ihre Laufzeitabhängigkeiten. Standardsoftware, die in den meisten Linux-Distributionen enthalten ist, wie Paketmanager und sogar Shells, wird ausgeschlossen. Um das Distroless-Image von Google zu verwenden, müssen Sie den oben erwähnten mehrstufigen Build wie folgt verwenden:

VON redis:latest AS build 
ARG TIME_ZONE 
RUN mkdir -p /opt/etc && \ 
 cp -a --parents /lib/x86_64-linux-gnu/libm.so.* /opt && \ 
 cp -a --parents /lib/x86_64-linux-gnu/libdl.so.* /opt && \ 
 cp -a --parents /lib/x86_64-linux-gnu/libpthread.so.* /opt && \ 
 cp -a --parents /lib/x86_64-linux-gnu/libc.so.* /opt && \ 
 cp -a --parents /usr/local/bin/redis-server /opt && \ 
 cp -a --parents /usr/local/bin/redis-sentinel /opt && \ 
 cp /usr/share/zoneinfo/${TIME_ZONE:-UTC} /opt/etc/localtime 
 
VON gcr.io/distroless/base 
KOPIEREN --from=build /opt / 
VOLUME /Daten 
ARBEITSVERZEICHNIS /data 
EINSTIEGSPUNKT ["Redis-Server"]

Verwenden Sie redis:latest als Basisimage, behalten Sie einige erforderliche Binärdateien (Redis-Server-Binärdatei und alle zugehörigen Abhängigkeiten) und verwenden Sie dann das Distroless-Image als Grundlage für das endgültige zu erstellende Image. Kopieren Sie den Inhalt des Opt-Verzeichnisses in das Image-Verzeichnis.

Anschließend müssen wir nur noch das Image neu aufbauen:

$ docker build -t redis:distroless .$ docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEredis distroless 7d50bd873bea vor 15 Sekunden 28,2 MBredis latest 1319b1eaa0b7 vor 3 Tagen 104 MB

Wir können sehen, dass die Bildgröße von 104 MB auf 28,2 MB reduziert wurde, was die Bildgröße erheblich verringert.

Hinweis: Unter Linux können wir das Tool ldd verwenden, um die Abhängigkeiten zu finden, die eine angegebene Binärdatei benötigt, z. B. $ ldd $(which redis-server).

Die Verwendung von Distroless-Images zur Reduzierung der Größe von Docker-Images ist eine sehr effektive Methode, hat aber auch einen offensichtlichen Nachteil: Im endgültigen Image ist kein Shell-Programm enthalten, was das Debuggen von Docker-Containern sehr schwierig macht. Dies verringert natürlich auch das Risiko von Anwendungsangriffen und macht die Anwendung sicherer. Wenn wir die Anwendung in einem Kubernetes-Cluster bereitstellen, können wir Tools wie kubectl-debug verwenden, um das Debuggen der Anwendung zu unterstützen.

Alpine Linux

Eine weitere gängige Möglichkeit besteht darin, ein Anwendungsimage auf Basis von Alpine Linux zu erstellen. Dabei handelt es sich um eine Distribution, die sich besonders für die Erstellung minimaler Docker-Images eignet. Apline Linux verwendet die kleinere C-Bibliothek musl anstelle von glibc und verknüpft sie statisch. Dies bedeutet, dass für musl kompilierte Programme zu verschiebbaren Binärdateien werden, wodurch die Notwendigkeit der Einbindung gemeinsam genutzter Objekte entfällt und die Größe des Images erheblich reduziert werden kann.

Das redis:alpine-Image ist etwa 30 MB groß. Der Nachteil ist, dass musl normalerweise nicht so gut funktioniert wie glibc. Natürlich gibt es noch einen weiteren Vorteil. Im Vergleich zu den oben genannten Distroless ist Alpine eine ausgereifte Linux-Distribution, die grundlegenden Shell-Zugriff bietet und so das Debuggen von Docker-Containeranwendungen erleichtert. Sie können auf Docker Hub auch Alpine-Versionen fast aller gängigen Software finden, beispielsweise Redis, Nginx, MySQL usw.

GNU Guix

Schließlich können wir GNU Guix verwenden, ein vielseitiges Paketverwaltungstool, das über eine Funktion zum Erstellen von Docker-Images verfügt. Guix unterscheidet zwischen den Laufzeitabhängigkeiten eines Pakets und seinen Build-Abhängigkeiten. Ein mit Guix erstelltes Docker-Image enthält daher genau wie der Distroless-Ansatz nur explizit angegebene Programme und deren Laufzeitabhängigkeiten. Aber anders als bei distroless, wo Sie die Laufzeitabhängigkeiten des Programms selbst prüfen müssen (und natürlich ein Dockerfile schreiben müssen), müssen Sie bei Guix nur einen einzigen Befehl ausführen: $ guix pack -f docker redis .

Das mit dem obigen Befehl erstellte Redis-Image ist etwa 70 MB groß, was eine erhebliche Verkleinerung gegenüber dem Originalimage darstellt. Obwohl es etwas größer ist als die mit den Methoden „distroless“ und „Alpine“ erstellten Images, bietet die Verwendung von Guinx einige weitere Vorteile. Wenn Ihr endgültiges Image beispielsweise eine Shell zum Debuggen wie Alpine enthalten soll, müssen Sie diese nur beim Verpacken von Guxi angeben: $ guix pack -f docker redis bash . Wenn Sie andere Software einbinden möchten, können Sie diese später hinzufügen.

Dank der Funktionen von Guix sind Paketerstellungen zu 100 % wiederverwendbar. Daher können wir unserer CI/CD-Pipeline Guix-Unterstützung hinzufügen und den Erstellungsprozess sehr reibungslos gestalten.

Manche Leute finden Guix vielleicht cool, möchten aber kein weiteres Tool herunterladen und installieren, nur um ein kleineres Docker-Image zu erstellen. Außerdem funktioniert Guix nur unter Linux. Viele Entwickler sind immer noch MacOS-Benutzer, daher ist die Konfiguration von Guix mühsam. Tatsächlich müssen Sie sich darüber keine Gedanken machen. Guix selbst hat auch ein Docker-Image auf dem Docker Hub, daher ist die Verwendung nicht zu kompliziert. Sie müssen nur den einfachen Befehl $ docker run guix verwenden.

Neben Guix ist es erwähnenswert, dass es ein Paketverwaltungstool namens Nix gibt, und alles, was zu Guix erwähnt wurde, ist in gleicher Weise für Nix gültig und anwendbar.

Oben sind die Details der gängigen Methoden zur Optimierung der Größe von Docker-Images aufgeführt. Weitere Informationen zur Optimierung der Größe von Docker-Images finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!