Haben Sie sich jemals gefragt, welches Docker-Image als Ausführungsumgebung für Ihre Python-Anwendung ausgewählt werden soll? Ich entschied mich eher dafür, mich auf das offizielle Bild zu beschränken, nachdem ich mir jedes Mal Sorgen gemacht hatte, und beschloss, hier einen Vergleich anzustellen. Ich hoffe, es wird für alle hilfreich sein.
Bei der Auswahl eines Bildes gibt es meiner Meinung nach folgende Perspektiven.
| Perspektive | Inhalt |
|---|---|
| Stabilität | Es ist schwierig, es für eine lange Zeit zu verwenden, wenn sich die Dateistruktur und der Inhalt häufig ändern, sodass eine gewisse Stabilität erforderlich ist.(Ich glaube nicht, dass es viel gibt)。 Daher möchte ich ein Bild verwenden, das dem offiziellen nahe kommt. |
| Bildgröße | Die Größe des Bildes kann am quantitativsten bewertet werden. Je kleiner das ist, desto besser. |
| Sicherheitsupdates | Sicherheitsupdates variieren je nach Betriebssystemverteilung, Sie müssen jedoch wissen, wie lange sie unterstützt werden. |
| Ist Python installiert? | Sie können es selbst installieren, aber es spart Ihnen Zeit und Bauzeit, wenn es von Anfang an installiert wird. |
Es ist sehr stabil, da Sie die Stabilität und den Supportzeitraum von Sicherheitsupdates mithilfe einer Standarddistribution überprüfen können. Es enthält jedoch auch viele gängige Pakete, die zum Ausführen von Python-Anwendungen nicht benötigt werden, und die Bildgröße ist in der Regel groß. Sie müssen auch die neueste Version von Python selbst installieren.
Wenn Sie das Bild verkleinern möchten, ist Alpine-Linux möglicherweise der erste Kandidat. Laut dem unten verlinkten Artikel scheint die Verwendung von Alpin jedoch letztendlich verschiedene Probleme zu verursachen, wie z. B. eine erhöhte Bildkapazität und eine längere Bauzeit. Using Alpine can make Python Docker builds 50× slower
Das Folgende ist eine Zusammenfassung des im Artikel erwähnten Inhalts.
Daher hat alpine eine kleine Bildgröße, bleibt jedoch als Python-Ausführungsumgebung ungewiss.
Wenn Sie Python mit Docker verwenden, verwenden meines Erachtens viele Leute dieses Bild. Die Arten von Tags sind ungefähr wie folgt.
| Bildtyp | Das neueste vorherige Tag(2020/Stand 03) | Größe | Bemerkungen |
|---|---|---|---|
| alpine | 3.8.1-alpine3.11 | 109MB | Es gibt hier auch ein Bild von Alpine, das jedoch aufgrund der oben genannten Nachteile nicht empfohlen wird. |
| buster | 3.8.1-buster | 933MB | Dieses Bild basiert auf Buster, der neuesten Version von Debian. Es ist nicht leicht, da viele Basispakete installiert sind, aber es ist eine gute Wahl für den allgemeinen Gebrauch. |
| buster-slim | 3.8.1-slim-buster | 193MB | Dies ist eine Version, in der das gemeinsame Paket im Debian-Image weggelassen und die Image-Größe entsprechend reduziert wird. Wenn Sie nur Python-Anwendungen verwenden, scheint dies kein Problem zu sein. |
Wenn Sie die Tags vergleichen, sehen Sie, dass es zusätzlich zum Debian-Hauptbild eine schlanke Version gibt. Dies ist ein Image, das auf die Ausführung von Python spezialisiert ist, und es scheint, dass viele andere Funktionen entfernt wurden. In einem Hinweis auf der Python-Docker-Seite heißt es: "Verwenden Sie slim, wenn Sie strenge Einschränkungen für die Bildgröße nur für die Python-Ausführung haben. Andernfalls empfehlen wir das Standardbild." Die Auswahl hängt davon ab, wie weit Sie im Container laufen möchten.
Aus den obigen Ergebnissen kamen wir zu dem Schluss, dass Docker Image, das zum einfachen Ausführen von Python-Anwendungen geeignet ist, Debian Buster slim ist. Die Bildgröße beträgt 198 MB, was ziemlich kompakt ist.
Recommended Posts