MariaDB- und Docker-Anwendungsfälle, Teil 1

Einige der häufigsten Fragen unserer Benutzer beziehen sich auf die MariaDB-Unterstützung in Docker und insbesondere darauf, wie sie in bestimmten Entwicklungs- oder Produktionsbereitstellungen verwendet werden kann. Diese Artikelserie versucht, einige Docker- und MariaDB-Anwendungsfälle abzudecken.

Warum Docker für MariaDB wählen?

• Docker-Container können zum Testen, Bereitstellen und Freigeben von Anwendungen in jeder Umgebung verwendet werden.
• Docker-Bereitstellungen lassen sich einfach automatisieren, Bereitstellungsumgebungen erstellen und diese problemlos in Staging und Produktion reproduzieren.
• Docker ist leichtgewichtige Virtualisierung. Hypervisoren werden nicht benötigt und ein MariaDB-Docker-Container sollte genauso gut funktionieren wie eine normale MariaDB-Installation ohne nennenswerten Overhead.
• Docker ist agnostisch – sobald Sie Docker auf Ihrem Betriebssystem installiert haben, sind die Anweisungen zum Ausführen von Containern genau gleich, egal ob Sie CentOS, Debian oder Ubuntu oder sogar Mac OS X und Windows ausführen.

Einige wichtige Punkte zu Docker-Containern

• Docker-Container sind unveränderlich. Sie können nach dem Start nicht einfach geändert werden (es sei denn, Sie fügen sie hinzu und zerstören alles).
• Standardmäßig und aus den oben genannten Gründen sind Daten nicht persistent. Docker schafft Abhilfe mit Datenvolumina. Der MariaDB-Container verwendet ein Volume, um Daten aufzubewahren (dazu später mehr).

Zustand von MariaDB in Docker

MariaDB wurde in Docker seit einigen Jahren immer sehr gut unterstützt, dank vieler Bemühungen des Docker-Teams und der Community. Bis heute unterstützt Docker alle drei MariaDB-Releases:5.5, 10.0 und 10.1. Der MariaDB-Docker-Container hat folgende Besonderheiten:

• Das MariaDB-Root-Passwort kann über Umgebungsvariablen festgelegt oder generiert werden.
• Ein neuer Benutzer und eine leere Datenbank können auf die gleiche Weise wie oben erstellt werden.
• Die Instanz hat standardmäßig ein persistentes /var/lib/mysql-Datenvolumen, das Sie Docker intern verwalten lassen oder in ein Verzeichnis Ihrer Wahl einhängen können.
• Die Containerinstanz kann auf einem bestehenden Datenvolumen (z. B. einem Backup) gemountet werden.
• Netzwerkports können an beliebige Ports auf der Hostseite gebunden werden.
• Die MariaDB-Wissensdatenbank enthält einen ausführlichen Dokumentationsartikel zu Docker. Lies es!

Docker-Anwendungsfall Nr. 1:Mandantenfähigkeit

Ein häufiger Anwendungsfall für MariaDB und Docker ist die Ausführung mehrerer Instanzen von MariaDB auf denselben physischen Hosts. Es gibt bereits Lösungen wie MySQL Sandbox und andere, aber keine davon bietet die Flexibilität, Benutzerfreundlichkeit und Leistung, die Docker bietet.

Um unseren Standpunkt zu veranschaulichen, starten wir drei verschiedene Instanzen von MariaDB, von denen jede eine andere Hauptversion ausführt:

docker run -d -p 3301:3306 -v ~/mdbdata/mdb55:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=admin --name mdb55 mariadb:5.5
docker run -d -p 3302:3306 -v ~/mdbdata/mdb10:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=admin --name mdb10 mariadb:10.0
docker run -d -p 3303:3306 -v ~/mdbdata/mdb11:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=admin --name mdb11 mariadb:10.1

Docker zieht automatisch die offiziellen Mariadb-Images aus dem Repository und startet sie. Jetzt können wir einfach eine Verbindung zu einer dieser Instanzen herstellen, indem wir den bereitgestellten Port und das Passwort verwenden:

$ mysql -u root -padmin -h 127.0.0.1 -P3302
Welcome to the MariaDB monitor.  Commands end with ; or g.
Your MariaDB connection id is 2
Server version: 10.0.22-MariaDB-1~jessie mariadb.org binary distribution Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others. Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

Beachten Sie, dass jede unserer Instanzen ein persistentes Datenvolumen verwendet, das sich unter ~/mdbdata befindet Verzeichnis – Docker erstellt diesen Verzeichnisbaum automatisch für uns.

Nachdem wir das getan haben, wollen wir uns mit den erweiterten Funktionen von Docker befassen. Docker unterstützt Linux-Kontrollgruppen (cgroups), die verwendet werden können, um die Ressourcennutzung zu begrenzen, zu erfassen oder zu isolieren. Nehmen wir an, wir möchten unsere MariaDB 10.1-Instanz (mit dem Namen mdb11 ) eine höhere CPU-Priorität als die beiden anderen Instanzen haben. In diesem Fall können wir die CPU-Anteile von mdb10 verringern und mdb55 . Jede Instanz hat standardmäßig maximal 1024 CPU-Anteile, also erstellen wir unser mdb55 neu und mdb10 Container mit jeweils 512 CPU-Shares.

In der Präambel haben wir gesagt, dass Docker-Container unveränderlich sind. Wenn wir die Parameter unserer Container ändern möchten, müssen wir sie entfernen. Dies ist kein Problem, da wir persistente Datenvolumen in ~/mdbdata definiert haben, sodass die tatsächlichen Inhalte unserer Datenbank bestehen bleiben, wenn wir die Container neu erstellen.

docker rm -f mdb55 mdb10
docker run -d -p 3301:3306 --cpu-shares=512 -v ~/mdbdata/mdb55:/var/lib/mysql --name mdb55 mariadb:5.5
docker run -d -p 3302:3306 --cpu-shares=512 -v ~/mdbdata/mdb10:/var/lib/mysql --name mdb10 mariadb:10.0

Wir haben die beiden MariaDB-Instanzen mit jeweils 512 CPU-Anteilen neu erstellt. Dies ist jedoch ein weiches Limit und wird nur durchgesetzt, wenn Prozesse um CPU-Zyklen konkurrieren. Wenn die anderen Instanzen im Leerlauf sind, kann jede Instanz bis zu 100 % aller CPUs verwenden. In der Praxis bedeutet dies, dass bei gleichzeitiger Nutzung der CPU durch alle drei Instanzen jeder der beiden ersten Container mit jeweils 512 Shares (mdb55 und mdb10 ) kann bis zu 25 % aller CPUs verwenden, während der dritte Container mit 1024 Freigaben bis zu 50 % aller CPUs verwenden kann.

Eine andere Option besteht darin, die Instanz an einen bestimmten CPU-Kern zu binden, also erstellen wir die Container neu und tun das:

docker rm -f mdb55 mdb10 mdb11
docker run -d -p 3301:3306 --cpuset-cpus=0 -v ~/mdbdata/mdb55:/var/lib/mysql --name mdb55 mariadb:5.5
docker run -d -p 3302:3306 --cpuset-cpus=1 -v ~/mdbdata/mdb10:/var/lib/mysql --name mdb10 mariadb:10.0
docker run -d -p 3303:3306 --cpuset-cpus=2-3 -v ~/mdbdata/mdb10:/var/lib/mysql --name mdb11 mariadb:10.1

Im obigen Beispiel sind bei einem 4-CPU-Core-System meine Container mdb55 und mdb10 laufen jeweils auf einem separaten, einzelnen CPU-Kern, während mdb11 werden beide verbleibenden Kerne.

Wir können auch steuern, wie unsere Container auf Festplatten- und Speicherressourcen zugreifen, was auf einem ausgelasteten System definitiv nützlich ist – Sie möchten beispielsweise keine außer Kontrolle geratene Entwicklungsabfrage, die die gesamte Festplatte Ihrer Lasttestinstanzen verwendet. Während Speicherbegrenzungen einfach sind, funktionieren Block-IO-Anteile auf ähnliche Weise wie CPU-Anteile, außer dass der Standard-Block-IO-Anteil 500 in einem Bereich von 10 bis 1000 beträgt.

Beschränken wir unsere beiden ersten Container auf 512 MB Arbeitsspeicher und 250 Block-E/A-Freigaben:

docker rm -f mdb55 mdb10
docker run -d -p 3301:3306 --blkio-weight=250 --memory=512M -v ~/mdbdata/mdb55:/var/lib/mysql --name mdb55 mariadb:5.5
docker run -d -p 3302:3306 --blkio-weight=250 --memory=512M  -v ~/mdbdata/mdb10:/var/lib/mysql --name mdb10 mariadb:10.0

Wenn die drei Instanzen um IO konkurrieren, wird jeder der beiden ersten Container auf 25 % der verfügbaren IO-Kapazität begrenzt, während der dritte Container auf die verbleibende Kapazität begrenzt wird, z. 50 %.

Docker-Laufzeitbeschränkungen haben noch viel mehr zu bieten als das, worüber wir hier in diesem Artikel gesprochen haben. Bitte lesen Sie die ausführliche Docker-Ausführungsreferenz, um mehr über alle möglichen Optionen zu erfahren.