Ist Docker für meinen Anwendungsfall geeignet?

Mein Unternehmen hat ein System, das wir verkaufen und das im Grunde aus einem Mini-Computer "Smartbox" besteht, auf dem Ubuntu 12.04 ausgeführt wird. In dieser Box wird eine Django-Anwendung sowie eine Reihe von damit verbundenen Upstart-Prozessen ausgeführt. Sonst nicht viel. Wir haben Tausende dieser Kisten auf dem Feld. Wir verwalten die Paketabhängigkeiten, die Prozessregistrierung usw. über ein Deb-Paket mit unterschiedlichem Erfolg.

Wir brauchen eine Möglichkeit, Updates effizient und zuverlässig an unsere Benutzer im Außendienst zu senden. Wir brauchen auch etwas, dass wir uns beim Upgrade des Betriebssystems (wie Sie sehen, sind wir für ein Ubuntu-Upgrade überfällig) relativ sicher fühlen können, wenn unsere Pakete "einfach funktionieren".

Ich weiß nicht viel über Docker, aber als ich zum ersten Mal von unserem Problem hörte (ich bin neu eingestellt), war Docker mein erster Gedanke. Aber je mehr ich darüber nachdachte, desto eher hatte ich das Gefühl, dass dies nicht der Fall ist, da wir mit diesen Boxen das Betriebssystem steuern, das einen großen Teil des Wertversprechens von Docker ausmacht. Wenn wir also WISSEN, dass unsere Boxen immer Ubuntu sind und wir im Grunde nur eine Django-App und einige Prozesse ausführen müssen, ist Docker dann besser als ein Deb-Paket?

TL; DR: Docker vs deb-Pakete für eine verteilte Appliance, die immer Ubuntu ausführt, sodass die Plattformunabhängigkeit nicht so wichtig ist.

Ich bin mir nicht zu 100% sicher, ob ich das mit der Frage verstehe, aber es hört sich so an, als würde die Docker-Lösung von einer (physischen?) Appliance mit einem Betriebssystem und einer darauf installierten App zu einer Appliance mit einem Betriebssystem und wechseln Docker darauf, indem Sie einen einzelnen Container mit Ihrer App ausführen. Das macht ein Update des Betriebssystems auf dem Host nicht überflüssig und erhöht die Komplexität (und die Anzahl der Updates, mit denen Sie fertig werden müssen, da Docker und das Betriebssystem weiterhin gepatcht bleiben müssen ) soweit die in der Frage genannten spezifischen Bereiche betroffen sind.

Wenn Sie jedoch von einer virtuellen Appliance zu einem Docker-Container wechseln möchten, könnte dies möglicherweise Abhilfe schaffen, fügt Docker jedoch auch als Abhängigkeit für Ihr Produkt hinzu. Sie schließen jeden, der Docker nicht verwendet und es nicht zu seinem Stapel hinzufügen möchte, nur um Ihr Produkt zu verwenden. Sie können diejenigen, die Docker nicht verwenden, weiterhin unterstützen, indem Sie die (jetzt "ältere") virtuelle Appliance wie zuvor ausliefern. Jetzt haben Sie jedoch nur die Arbeitslast verdoppelt, da Sie stattdessen zwei Distributionen unterstützen müssen einer.

Ich habe lange mit Docker gearbeitet. Die Plattformunabhängigkeit ist nett, aber ich halte Docker nicht für besonders nützlich.

In erster Linie erhalten Sie Wiederholbarkeit. Sie können ein Dockerfile erstellen, in einem Container auf Ihrem Entwicklercomputer debuggen, Tests auf einem Continuous Integration Server und dann in Ihrem Endprodukt ausführen und wissen, dass es sich in all diesen Umgebungen gleich verhält. Nicht zu vergessen eine Abhängigkeit, die ein Entwickler auf seinem Computer installiert hatte. Außerdem müssen Ihre Entwickler Ubuntu nicht an ihrem Schreibtisch verwenden. Wichtig um uns Arch Linux User bei Laune zu halten :-)

Zweitens können für Ihr Upgrade-Szenario mehrere Versionen gleichzeitig auf einen Computer übertragen werden. Wenn Sie eine docker pull myapp:2.0Weile 1.0laufen, können Sie 2.0extrem schnell zu wechseln. Viel schneller als bei einem vollständigen Betriebssystem-Upgrade. Wenn Sie einen Orchestrator mit mehreren Instanzen von Microservices verwenden, können Sie sogar Upgrades durchführen, die den Dienst überhaupt nicht unterbrechen.

Wenn Sie ein Microservices-Modell verwenden, stellt Docker auch Sandboxes bereit, mit denen die Anzahl der Schäden begrenzt werden kann, die Angreifer im Falle eines Exploits anrichten können. Anstatt die Kontrolle über eine gesamte Maschine zu erlangen, erlangen sie nur die Kontrolle über einen Container.

Der Hauptnachteil ist, dass Sie das Host-Betriebssystem und eine Art Orchestrierung benötigen. Dafür gibt es viele Möglichkeiten, aber unterschätzen Sie nicht den Arbeitsaufwand, der erforderlich ist, um eine zu evaluieren, sie einzurichten und aufrechtzuerhalten.

Während es einige winzige überlappende Regionen gibt, lösen Docker und die Debian-Verpackungssysteme im Wesentlichen zwei sehr unterschiedliche Probleme :

• Das Debian-Paketierungssystem ist so aufgebaut, dass Software auf einem Host installiert und so einfach wie möglich aktualisiert werden kann. Es ist in der Lage, komplexe Abhängigkeits- und Einschränkungsmuster zwischen Softwarekomponenten zu verarbeiten, z. B. "Software X Version A erfordert Software Y mit Version B oder neuer" oder "Software X sollte niemals mit Software Z Version C installiert werden".

• Das Docker-System dient zur einfachen Beschreibung und Bereitstellung von Diensten, insbesondere von Mikrodiensten, möglicherweise auf mehreren Hosts - z. B. einem Docker-Schwarm oder einem Kubernetes-Cluster.

Diese beiden Probleme sind im Wesentlichen orthogonal, was bedeutet, dass bei dem zu lösenden Bereitstellungsproblem eines von beiden oder möglicherweise keines von beiden als Teil der Lösung verwendet werden kann. Wenn Sie beide verwenden, wird das Debian-Paket bei der Erstellung des Docker-Images verwendet, und Ihre Docker-Datei (die Rezepte, die zur Erstellung des Docker-Images verwendet werden, das das in einem Container ausgeführte „virtualisierte System“ beschreibt) würde Ihr Debian-Repository im Wesentlichen im registrieren Quellen des Debian-Verpackungssystems und installieren Sie Ihr Paket.

In diesem Sinne scheint es mir, dass Sie wirklich danach suchen, das unveränderliche Servermuster zu implementieren. Die jüngste Entwicklung der Cloud-Technologien ermöglichte ein Software-Upgrade nicht durch Verwendung des klassischen Software-Upgrade-Systems von einem Softwarepaket-System (wie dem Debian-Paketierungssystem), sondern durch einfaches Ersetzen des vollständigen Servers auf einmal. (Einige Personen taten dies vor dieser Entwicklung, indem sie drei Betriebssysteme auf einem Server hatten, zwei, die abwechselnd zum Ausführen der Appliance verwendet wurden, und ein Mini-Betriebssystem, das für den Austausch der Appliance vorgesehen war. Obwohl dies nicht allzu komplex ist, scheint dies immer ein Problem geblieben zu sein Nische.) Diese Technik kann für Sie von Interesse sein, da der endgültige Status des Servers von der „Upgrade-Historie“ des Servers abhängt, insbesondere wenn in der Software Fehler auftreten Upgrade-Prozess. Diese Heterogenität ist schlecht,

Wir haben Tausende dieser Kisten auf dem Feld. Wir verwalten die Paketabhängigkeiten, die Prozessregistrierung usw. über ein Deb-Paket mit unterschiedlichem Erfolg.

könnte sich darauf beziehen. Das unveränderliche Servermuster beseitigt diese Fehlerquelle, indem der Begriff „Upgrade-Verlauf“ im Wesentlichen aus dem Problem entfernt wird.

Nun gibt es verschiedene Möglichkeiten, das unveränderliche Servermuster zu implementieren. Zwei beliebte Möglichkeiten sind die Verwendung von Docker-Images und Images oder die Verwendung von "Master-Instanz-Images" von Ihrem Cloud-Anbieter (diese werden in AWS als AMIs und in Google Compute Engine nur als benutzerdefinierte Images bezeichnet). . Ihr Anwendungsfall verbietet die Verwendung von Cloud-basierten Techniken. Ich gehe daher davon aus, dass Docker-Images die einzige in Frage kommende Option sind. (Zur Vervollständigung ist es durchaus möglich, andere Ansätze zu verwenden, beispielsweise Virtual Box oder eine ähnliche Virtualisierungslösung als Alternative zu Docker.)

Wenn Sie die unveränderliche Servermustertechnik verwenden, stellen Sie ein neues Artefakt (das Docker-Image) vor, das Ihren Server darstellt, und dieses Artefakt kann auch getestet werden. Außerdem ist es sehr einfach, ein Setup zu erhalten, das Ihre Produktionseinstellungen - abgesehen von der Servicebelastung - genau wiedergibt.

Wenn Sie nun das von Ihnen beschriebene konkrete Problem betrachten möchten, nehmen wir an, dass die Implementierung des Musters für unveränderliche Server mit Docker tatsächlich Ihren Wünschen entspricht. Da das Docker-System und das Debian-Paketierungssystem sich nicht gegenseitig ausschließen, sondern ergänzen (vgl. Einführung), müssen wir uns noch mit der Frage befassen, ob Sie ein Debian-Paket für Ihre Software vorbereiten sollen.

Die Relevanz der Verwendung eines Debian-Pakets zur Installation Ihrer Software (im Docker-Image oder auf einem Host) liegt in der Komplexität des zu lösenden Versionsproblems. Wenn Sie mehrere Versionen Ihrer Software gleichzeitig ausführen, gelegentlich ein Downgrade durchführen müssen und komplexe Versionsanforderungen haben, die Sie sorgfältig dokumentieren müssen, ist ein Debian-Paket ein Muss. Andernfalls kann dieser Schritt übersprungen werden. Da Sie jedoch bereits Anstrengungen unternommen haben, diese Pakete zu erstellen und bereitzustellen, ist es nicht wirklich sinnvoll, Ihre Arbeit aufzugeben. Ich würde daher vorschlagen, weiterhin Ihre Debian-Pakete zu produzieren.

Docker hört sich für mich vernünftig an, da Sie Änderungen am internen Container vornehmen und testen und dann, abhängig von Ihrem Freigabeprozess, die Container immer neu starten: Neueste oder etwas Ähnliches, was ein getestetes Upgrade ermöglichen würde.

Überlegungen, mit denen Sie sich befassen müssten, schließen Datenspeicherung ein, da Container Änderungen beim Neustart nicht beibehalten, sodass Sie ein Datenvolumen wünschen würden. Es gibt wahrscheinlich noch viel mehr Überlegungen, die Sie anstellen müssen, wenn Sie sich einmal damit befasst haben. Das System, mit dem ich zurzeit arbeite (alle Docker-basiert), befindet sich seit über einem Jahr in der Entwicklung und wir finden immer noch Bereiche, in denen wir Änderungen am Container, an den Konfigurationen usw. vornehmen müssen.

Im Großen und Ganzen bietet Docker sowohl Entwicklern als auch Betriebspersonal viele Vorteile. Ich verwende Docker für einige meiner Anwendungen und finde es ein sehr zuverlässiger und robuster Ansatz.

Mein Problem bei der Übernahme von Docker ist, dass ich nicht höre, dass Sie die richtigen Fragen stellen, und dass Sie möglicherweise Ihr Leben komplizierter gestalten könnten, ohne auf Ihre wichtigsten Anforderungen einzugehen.

Die erste Frage, die Sie stellen sollten (Sie sagten, dass Sie neu sind), ist, wie Aktualisierungen des Betriebssystems und der Anwendung jetzt gehandhabt werden. Funktioniert die aktuelle Methodik für Sie (Ihr Unternehmen)? Was funktioniert gut? Was könnte verbessert werden? Können Sie auf Ihren Zielcomputern vor Ort eine Prüfung der physischen Konfiguration durchführen, um sicherzustellen, dass sie über die richtigen Betriebssystem-Patches, -Anwendungen und -Unberechtigten verfügen?

Ich liebe Docker, aber ich würde nicht auf den Docker-Zug springen, ohne vorher zu prüfen, wo Sie sich gerade befinden, einschließlich dessen, was gut funktioniert und was verbessert werden muss.

Ich denke, es könnte eine gute Option sein (weitere Tests sind erforderlich)

Sie können eine URL mit allen Tags / Versionen des von Ihnen erstellten Containers angeben, und die Clients lesen diese URL, um festzustellen, ob es eine neue Version des Containers gibt.

Sie können persönliche Dateien / Einstellungen lokal speichern und Sie werden diese Informationen bei Upgrades nie verlieren und Sie werden sicherstellen, dass das, was Sie gemacht und getestet haben, für alle auf die gleiche Weise funktioniert.

Sogar Sie könnten den Benutzern die Möglichkeit geben, aus den verfügbaren Versionen auszuwählen, die sie verwenden möchten (wenn Sie diese Möglichkeit geben möchten).

Es wird so aussehen, als würde "" nur ein Paket aktualisiert "" und nur eine neue Version des Containers abgerufen, viel besser als mit Debian-Paketen;)