Gibt es Nachteile bei der Verwendung eines Deb-Pakets, als wäre es ein Container zum Bereitstellen einer Anwendung?

Mein Team versucht derzeit zu entscheiden, ob wir unsere Nodejs-App als Deb-Paket bereitstellen sollen, anstatt zu versuchen, sie in einem Container wie Docker auszuführen.

Diese Idee kam mir, als ich diesen Blog hier las , der einige gute Argumente für die Verwendung eines Deb-Pakets für eine bereits vorhandene Python-Anwendung liefert. Der Hauptpunkt dieses Blogs, der uns anspricht, ist das Problem der Aufrechterhaltung des Docker-Ökosystems (Port-Sharing, Berechtigungen, Hosting von Docker Images usw.).

Es scheint, als ob "dep-packages as the original containers" für kleine Services sehr sinnvoll sind, bei denen Portkonflikte keine Rolle spielen und bei denen alle Abhängigkeiten in einer virtuellen Umgebung verwaltet werden.

Mein Bauch sagt mir jedoch, dass Deb-Pakete, wenn sie gut zusammenpassen, häufiger wären und Docker als sprachspezifischere Lösung beworben würden. Gibt es irgendwelche Nachteile bei der Verwendung von Deb-Paketen zur Bereitstellung unserer Dienste, anstatt ein vollständiges System wie Docker zu verwenden?

Erstens, während Docker wird manchmal gesehen und als verwendet Ad - hoc - Verpackungssystem, es löst tatsächlich ein ganz anderes Problem: Docker ist über laufende Programme. Das Docker System ermöglicht beschreiben Dienste, die werden können skaliert nach Belieben und zu steuern , Schwärme von Containern. Debian-Pakete dienen zur Installation von Programmen und können Abhängigkeiten zwischen Softwareversionen verarbeiten. Docker sicherlich nicht als absteigendes Paketierungssystem zu qualifizieren: Jedes "Paket" kann nur eine Abhängigkeit haben, das System hat keine "rekursive Build" -Option und unterstützt keine komplexen Versionsbeschränkungen!

Eine mögliche Antwort wäre, dass Sie, wenn Sie bereit sind, ein Debian-Paket für Ihre Anwendung zu schreiben , Docker auch verwenden können , um Ihre Anwendung bereitzustellen. Dies kann mit einem Konfigurationsskript erreicht werden, apt_setup.shdas so aussehen würde

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

und a Dockerfilenach dem Vorbild von

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(In Ihrer speziellen Situation apt_setup.shwäre dies komplizierter, wenn Sie die Nodesource- Repositorys und einige Hilfspakete wie apt-transport-https hinzufügen würden .)

Es ist also wirklich möglich, Debian-Pakete und Docker gleichzeitig zu verwenden.

Mein Bauch […] sagt mir, dass Deb-Pakete, wenn sie gut zusammenpassen, häufiger wären

Dies ist ein korrektes Problem, das uns dazu bringt, uns zu fragen, warum Docker als Ad-hoc- Verpackungssystem beliebt ist, obwohl dies nicht beabsichtigt ist. (Siehe oben.)

Das "offizielle" Paketierungssystem einer bestimmten Distribution ist unter anderem nur eine Möglichkeit, Software in einer bestimmten Computerumgebung zu installieren. Es sind viele andere Quellen verfügbar, wie z. B. community-spezifische Paketmanager wie npm oder opam, Portbäume wie pkgsrc und die Distribution von einfachem Quellcode. Aus dieser Perspektive ist der Erfolg von Docker als Ad-hoc- Verpackungssystem leicht zu verstehen :

• Docker- Spezifikationen sind einem Shell-Skript sehr ähnlich, und unabhängig von der Quelle, von der es stammt, installieren wir Software mithilfe der Shell.

• Docker verfügt über einen integrierten (kostenpflichtigen) Service für das Hosten von Artefakten, den Docker Hub .

Was ist nun die Stärke von Debian-Paketen gegenüber Docker-Images als Paketsystem? Die enge Kontrolle über Abhängigkeiten bei der Installation. (Die Möglichkeit zum Upgrade und Downgrade ist ebenfalls vorhanden, hat jedoch keine praktische Bedeutung, wenn das unveränderliche Servermuster implementiert wird.) Dies führt zu

Fazit

Wenn Sie nur ein einziges Produkt in einer einzigen Version bereitstellen (was typisch für SaaS ist), sind Ihre Versionsverwaltungsanforderungen sehr einfach, und die Verwendung von Docker als Ad-hoc- Paketmanager sollte keine schwerwiegenden Nachteile haben. Sobald Sie mit mehreren Versionen eines einzelnen Produkts oder mehrerer Produkte arbeiten, steigt die Komplexität des zu lösenden Versionsbeschränkungsproblems und Sie benötigen dafür ein geeignetes Tool, bei dem es sich möglicherweise um Debian-Pakete oder ein Konfigurationsverwaltungssystem handelt Mischsoftware unterschiedlicher Herkunft.

Ja, es gibt Nachteile.

Mit einem .deb-Paket können Sie nicht zwei Versionen derselben Anwendung auf demselben Host haben. Sie müssen sich auf die verfügbaren Distributionspakete verlassen. Wenn sich Ihre App beispielsweise auf nodejs stützt, bleiben Sie entweder bei der Distributionsversion hängen oder müssen Ihre eigenen installieren.

Wenn Sie nun mehrere Anwendungen auf demselben Host hosten möchten, werden Sie sehr schnell auf eine Pinnwand stoßen, wenn sie von derselben Sache abhängen (lassen Sie uns die Nodejs hier behalten), und zwar in zwei verschiedenen Versionen.

Das Hauptziel von Docker besteht darin, jede Anwendung vom Hostsystem und anderen Anwendungen auf demselben Host zu isolieren. Für diese Isolation gibt es zwei Gründe: 1. Um eine Beeinträchtigung der App zu vermeiden, um den Host zu übernehmen oder eine andere Anwendung zu beeinträchtigen Abhängigkeit.

Ein Debian (oder RedHat) -Paket zum Installieren von Anwendungen hat sich bewährt, wenn es korrekt ausgeführt wurde. Pakete werden zum Bereitstellen von Anwendungen verwendet, die selten geändert werden. Debian-Pakete beinhalten einen gewissen Aufwand, wie Versionsverwaltung, Abhängigkeitsverwaltung, Skripte vor und nach der Installation usw.

In vielen Fällen erfordert ein Upgrade von einer älteren Version auf eine neue Version das sorgfältige Schreiben von Skripten, die Beachtung von Details in der Version usw., da es schwierig ist, den vorhandenen Status zu ändern. Es wäre viel einfacher, den gegenwärtigen Zustand durch einen neuen Zustand zu ersetzen, ohne irgendetwas zu verändern.

Sobald Sie sich entschieden haben, Ihre Konfiguration oder Abhängigkeiten oder Anwendung bei jeder Bereitstellung vollständig zu ersetzen, weil dies einfacher und weniger fehleranfällig ist. Die meisten Organisationen (früher) wechseln zu einer völlig neuen VM oder Cloud-Instanz. Dies bedeutet, dass die Installation des Pakets auf einem "sauberen" Server erfolgt und das Mutieren der Dateien und der Konfiguration auf dem Server kein Problem mehr darstellt.

Diejenigen Entwickler, die Pakete erstellt haben und den Irrtum und die Komplexität von Mutationen nicht verstanden haben, hatten infolgedessen einige Schwierigkeiten.

Das Ersetzen von VMs ist nicht optimal, wenn Sie lediglich eine Anwendung ersetzen müssen. Daher wurden als Antwort Lightweight-Container eingeführt. Mit Docker (oder einem anderen LWC) können Sie die Benutzerbasis einschließlich aller Abhängigkeiten ersetzen, ohne den Server selbst zu ersetzen. Sie können auch mehrere Versionen derselben Anwendung mit unterschiedlichen Abhängigkeiten auf demselben Server hosten und den eingehenden Netzwerkverkehr nur beim Upgrade umschalten. Neben dem Wiedereinschalten des Netzwerkverkehrs in den Rollback-Modus (blau-grün) war dies bei der Verwaltung von Bereitstellungen über Pakete bemerkenswert schwierig.

Container bieten eine Möglichkeit, den gesamten Anwendungscode, die Abhängigkeiten und die Konfiguration in einem Image zusammenzufassen. Dieses Image verfügt über mehrere Eigenschaften, die es wesentlich besser machen als herkömmliche Betriebssystempakete. Beispielsweise verfügt es über Tags, die die Versionsverwaltung ermöglichen, aber auch über Ebenen, mit denen Platz gespart werden kann. Mithilfe einer Registrierung können diese Images auf einfache Weise an Server und Entwicklungsumgebungen gesendet werden. Und diese Images können als Container in jeder Umgebung und auf jedem Server fast identisch ausgeführt werden. Dies umfasst sowohl den Laptop des Entwicklers als auch die Produktionsumgebung. Wieder etwas, das mit VMs und / oder mit paketbasierten Versionen der Software viel schwieriger zu tun war. Wenn dasselbe Image auf dem Laptop des Entwicklers getestet wird und in der Produktion dieselben Bits und Bytes verwendet werden, werden viele "

Apropos Image-Verpackung von Docker, nicht die Container-Laufzeit, es gibt ein paar Kleinigkeiten. Das Größte ist, dass ein Docker-Image eher einer Chroot ähnelt, was bedeutet, dass Sie nicht versehentlich vom gemeinsam genutzten Systemstatus abhängig sind, da jede verwendete Datei explizit in das Image aufgenommen werden muss, während ein Systempaket möglicherweise dynamische Links aufnimmt, die Sie nicht haben erwarten oder auf andere Weise mehr mit anderen Paketen verflochten zu bekommen. Dies kann dazu führen, dass komplexe C-Abhängigkeiten ohne Ihr Wissen geladen werden, z. B. OpenSSL. Durch die Verwendung von deb-Paketen werden außerdem keine gemeinsam genutzten Bits im Speichersystem von say Docker de-dupliziert. Für einige mag dies eine gute Sache sein, eine bessere E / A-Leistung und weniger sich bewegende Teile, für andere mag es ein Problem sein.