Aus welchen Gründen sollte Docker nicht für Datenbanken verwendet werden?

Ich habe eine Diskussion mit einem Freund über Anwendungsfälle für Docker . Einer im Team möchte Docker für alles verwenden - wie eine Art universeller Unix-Prozess-Wrapper. Der andere ist der Ansicht, dass Docker nur für zustandslose Anwendungen wie Microservices und AWS Lambda- Apps verwendet werden sollte.

Für beide haben wir Proof of Concepts entwickelt. In unserem Docker-Cluster befindet sich ein freigegebenes Laufwerk, das beim Bereitstellen des Docker-Hosts bereitgestellt wird. Wenn eine Datenbank in einem Container bereitgestellt wird, wird lediglich ein Volume auf dem freigegebenen Laufwerk bereitgestellt.

Mein Freund hält immer noch an seiner Position fest, obwohl ihm die gegenteiligen Beweise gezeigt wurden. (Er argumentiert auch, dass Docker unnötiges Risiko hinzufügt, indem er dem Stapel Komplexität hinzufügt .)

Ich versuche zuzuhören und seinen Standpunkt zu verstehen, sowohl in einem Akt des Einfühlungsvermögens, als auch um besser mit ihm zu argumentieren. (Wir verstehen uns alle recht gut - das ist also eine Mischung aus Scherz und ernsthafter Diskussion).

Art der Frage hinter der Frage ist: Sind Datenbanken Rinder ? Dieser Kommentar legt nahe, dass eine gute Strategie zum automatischen Sichern und Abrufen Ihrer Datenbank nicht von einem Viehserver zu unterscheiden ist.

Meine Frage ist: Aus welchen Gründen sollte Docker nicht für Datenbanken verwendet werden?

EDIT: Leute haben mich gebeten, meine Terminologie zu klären. Ich ging davon aus, dass sich die Datenbankanwendung im Container und der Speicher im Volume befindet. Was ich meinte, war, dass sich das RDBMS im Container befindet und der Datenbankspeicher im Volume.

Einige Kommentatoren haben vorgeschlagen, dass die Docker-Volume-Treiber nicht sehr gut mit Datenbank-Schreibvorgängen funktionieren. (Oder etwas in diesem Sinne). Könnten Sie das bitte näher erläutern?

Wenn Leute über das Ausführen einer Datenbank in Docker sprechen, wollen sie die Daten nicht in einem Container speichern. Sie sprechen über ein Docker-Image mit der DB-Software und das Mounten der Daten als Volume (Bind-Volume, kein Containervolume).

Volumes sind ein wesentlicher Bestandteil von Docker und nicht etwas, das abgeflacht oder einfach nur angeheftet ist. Docker ist nicht nur für staatenlose (Mikro-) Dienste gedacht.

Wie auch immer, ich kann keinen technischen Grund finden, eine Datenbank in einem Docker nicht zu betreiben. Daher werde ich leider die andere Seite des Arguments auswählen und Ihnen möglicherweise nicht die Antwort geben, nach der Sie suchen.

(Ich verwende Oracle als Beispiel, weil ich damit vertraut bin, sowohl als Bare-Metal-Version als auch als Docker-Version, und weil es ein berüchtigtes Biest ist, wenn man die Standardeinstellungen überschreitet.)

• Wenn Sie die DB-Software selbst in einen Container packen, erhalten Sie die üblichen Vorteile: Sie haben überall die gleiche Version, vermeiden Probleme mit Abhängigkeiten und gemeinsam genutzten Bibliotheken und können dieselbe DB auf Entwickler-Laptops oder an jedem Ort, an dem Sie sie benötigen, auslagern.
• Es ist ein Kinderspiel , es überall zum Laufen zu bringen. Aktualisieren ist trivial und so weiter. Es gelten alle Docker-Vorteile. Es gibt ein Oracle-Image auf Dockerhub, mit dem Sie eine funktionierende Datenbank in ein oder drei Minuten (und natürlich auch für die anderen) hochfahren können.
• Die Benutzer haben Leistungstests durchgeführt und keine E / A-Unterschiede zwischen Volumes und Bare Metal festgestellt ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https: // stackoverflow) .com / questions / 21889053 / was-ist-die-Laufzeit-Leistung-Kosten-eines-Docker-Containers ).
• Unter der Haube sieht es sowieso nicht so aus, als würde Docker alle I / O-Vorgänge abfangen. Kreativ wird es nur mit Standard-Linux-Tools (Bind-Mounts in diesem Fall, Mangeln der internen Kerneltabellen, die Docker-Fu überhaupt ermöglichen).
• Das bedeutet natürlich nicht, dass Sie zwei Instanzen der Datenbank ausführen und sie nur mit denselben Dateien arbeiten lassen können, aber das impliziert niemand. Docker bietet Ihnen nicht den automatischen gleichzeitigen und magisch rennfreien Zugriff auf Volumes und hat dies auch nie so getan. Der Rest der Vorteile bleibt bestehen. Wenn Ihre Datenbank selbst solche Konflikte nicht erkennt, sollten Sie dem Image ein CMD-Skript bereitstellen, das das Hochfahren eines zweiten Containers verweigert, wenn das Volume bereits verwendet wird.
• Sie müssen etwas vorsichtiger sein, wenn Sie den Container hoch- und runterfahren (so wie Sie einen Bare-Metal-DB-Server nicht einfach ausschalten würden), aber das sollte durchaus handhabbar sein.

Abhängig von den Umständen kann es gute Gründe geben, dies nicht zu tun:

• Oracle (das Unternehmen) zum Beispiel wird Sie sicherlich nicht unterstützen, wenn Sie sein RDBMS in einem Docker-Container ausführen. Aber vielleicht verwenden Sie nur dockerisierte Oracle RDBMS-Images für Ihre Entwickler und die Testumgebung, für die Sie auf keinen Fall deren Unterstützung benötigen und die Sie für einen Bare-Metal-Produktionsserver reservieren. (Vergessen Sie aber nicht, Ihre Lizenzen zu bezahlen ...).
• Wenn die Mitarbeiter mit Docker nicht vertraut sind, ist es möglicherweise einfacher, aus Versehen alles zu töten, Ihre Datendateien zu zerstören usw.
• Wenn Sie bereits große dedizierte Metall-DB-Maschinen haben, die über einen sehr schnellen dedizierten SAN-Speicher verfügen und ohnehin nichts anderes ausführen, ist Docker nicht sinnvoll, um diese zu containerisieren , da Sie dort niemals nur einen anderen Server hochfahren werden sind 100 GB oder sogar TB Daten. Schließlich ist ein RDBMS wie Oracle für die Produktion in Bezug auf Replikation, Datenintegrität, Failover ohne Ausfallzeiten usw. weit fortgeschritten. Beachten Sie, dass dieses Argument nur sagt , „Sie nicht brauchen Ihre RDBMS containerize“. Es heißt nicht "Sie sollten es nicht tun" - vielleicht möchten Sie es tun, weil Sie Datenbanksoftware-Upgrades über Container oder aus einem anderen Grund, den Sie sich vorstellen können, bereitstellen möchten.

Hier bitteschön. Mit allen Mitteln tun dockerize Ihre DB, zumindest für Ihre Entwickler (die ewig dankbar sein wird) und Ihre Testumgebungen. Bei der Produktion kommt es auf den Geschmack an, und dort würde ich auch die Lösung vorziehen, die am besten zu den spezialisierten DBA / Ops passt - wenn sie über jahrzehntelange Erfahrung in der Arbeit mit Bare-Metal-DB-Servern verfügen, dann vertrauen Sie ihnen auf jeden Fall so weitermachen. Wenn Sie jedoch ein Startup sind, das die gesamte IT in der Cloud hat, ist ein Docker-Container nur eine weitere Zwiebel im Gesamtbild.

Ich habe ausführlich darüber geschrieben, aber hier ist die Zusammenfassung:

• Es muss gelöst werden, wie verhindert werden kann, dass das Gehirn geteilt wird (indem mehr als ein Masterknoten gewählt wird). Nichtbeachtung kann katastrophal sein

• Es gibt keine produktionsfertigen Shared Storage-Lösungen, mit denen Datenbanken auf einer Instanz heruntergefahren und auf einer anderen hochgefahren werden können, ohne dass all Ihre Daten verloren gehen.

Wenn Sie sagen, dass die Daten in einen Docker-Container eingebunden sind, ist es nicht korrekter zu sagen, dass die "Datenbank" in den Docker-Container eingebunden ist? Wenn Sie Ihre Daten außerhalb des Containers beibehalten, tun Sie das "Richtige", indem Sie Ihre Datenbank nicht in einen Container stellen.

Sicher, fahren Sie in die Stadt und legen Sie ein DBMS in einen Container, damit es die Daten verwaltet, die Sie draußen speichern. Ich persönlich denke, das ist einfach gutes Design, weil es eine klare Trennung zwischen Logik und Daten gewährleistet. Aber sobald Sie Ihre Daten in einen Container legen, spielen Sie möglicherweise mit dem Feuer.

Obwohl die Fahrer von Containerlagern einen langen Weg zurückgelegt haben, bin ich persönlich noch nicht bereit, meine Daten in einem Container festzuhalten.