Wie man hochverfügbare persistente Docker-Dienste mit CoreOS und Consul einsetzt

Die Bereitstellung von Hochverfügbarkeit für zustandslose Anwendungen ist ziemlich trivial, wie in den vorangegangenen Blogbeiträgen Eine hochverfügbare Docker Container Plattform und Rolling Upgrade von Docker-Anwendungen mit CoreOS und Consul gezeigt wurde. Aber wie funktioniert das, wenn Sie einen persistenten Dienst wie Redis haben? In diesem Blog-Beitrag zeigen wir Ihnen, wie ein persistenter Dienst wie Redis auf den Rechnern im Cluster verschoben werden kann, während der Status erhalten bleibt. Der Schlüssel dazu ist die Bereitstellung einer Fleet-Mount-Konfiguration im Cluster und die Einbindung des Speichers in den Docker-Container mit den persistenten Daten.

Zur Unterstützung der Persistenz haben wir unserer Plattformarchitektur ein NAS in Form von drei unabhängigen NFS-Servern hinzugefügt, die als unser NAS-Speicher fungieren, wie in der Abbildung unten dargestellt. Die Anwendungen werden nach wie vor im CoreOS-Cluster als Docker-Container bereitgestellt. Selbst unsere Redis-Instanz wird in einem Docker-Container ausgeführt. Unsere Anwendung wird mit den folgenden drei Fleet-Unit-Dateien konfiguriert:

• app-hellodb@.service - die Template-Unit-Datei für die Webanwendung
• redis.service - die Unit-Datei des Redis-Servers
• mnt-data.mount - die Unit-Datei für das erforderliche Einhängen des Redis-Servers.

Die Unit-Datei des Redis-Servers ist die interessanteste, denn sie ist unser Persistenzdienst. Im Unit-Abschnitt der Datei erklärt er zunächst, dass er einen Mount für '/mnt/data' benötigt, auf dem er seine Daten persistieren wird. [code] [Unit] Beschreibung=app-redis Requires=mnt-data.mount After=mnt-data.mount RequiresMountsFor=/mnt/data [/code] In der Startklausel des redis-Dienstes wird ein bestimmtes Unterverzeichnis von /mnt/data in den Container eingehängt. [code] ... ExecStart=/usr/bin/docker run --rm --name app-redis [/code] -v /mnt/data/app-redis-data:/data -p 6379:6379 redis ... Die Unit-Datei mnt-data.mount ist recht einfach: Sie definiert eine NFS-Einhängung mit der Option 'noauto', die angibt, dass das Gerät beim Booten automatisch eingehängt werden soll. Die Unit-Datei hat die Option 'Global=true', so dass die Einhängung auf alle Knoten im Cluster verteilt wird. Die Einbindung wird nur aktiviert, wenn eine andere Einheit sie anfordert. [code] [Mount] What=172.17.8.200:/mnt/default/data Where=/mnt/data Type=nfs Options=vers=3,sec=sys,noauto [X-Fleet] Global=true [/code] Bitte beachten Sie, dass die NFS-Einhängung die Systemsicherheit (sec=sys) festlegt und das Protokoll NFS Version 3 verwendet, um alle Arten von Fehlern im Zusammenhang mit Unstimmigkeiten bei Benutzer- und Gruppennamen zwischen dem Client und dem Server zu vermeiden.

Die Bewerbung vorbereiten

Um die Ausfallsicherung in Aktion zu sehen, müssen Sie die Plattform starten und die Anwendung einsetzen: [bash] git clone https://github.com/mvanholsteijn/coreos-container-platform-as-a-service.git cd coreos-container-platform-as-a-service/vagrant vagrant up ./is_platform_ready.sh [/bash] Damit werden 3 NFS-Server und unser 3-Knoten-CoreOS-Cluster gestartet. Danach können Sie die Anwendung bereitstellen, indem Sie zunächst die Mount-Unit-Datei einreichen: [bash] export FLEETCTL_TUNNEL=127.0.0.1:2222 cd ../fleet-units/app fleetctl load mnt-data.mount [/bash] Start des Redis-Dienstes: [bash] fleetctl start app-redis.service [/bash] und schließlich das Starten einer Reihe von Instanzen der Anwendung: [bash] fleetctl submit app-hellodb@.service fleetctl load app-hellodb@{1..3}.service fleetctl start app-hellodb@{1..3}.service [/bash] Sie können überprüfen, ob alles läuft, indem Sie den Befehl fleetctl list-units eingeben. Es sollte in etwa Folgendes angezeigt werden: [bash] fleetctl list-units UNIT MACHINE ACTIVE SUB app-hellodb@1.service 8f7472a6.../172.17.8.102 active running app-hellodb@2.service b44a7261.../172.17.8.103 active running app-hellodb@3.service 2c19d884.../172.17.8.101 active running app-redis.service 2c19d884.../172.17.8.101 active running mnt-data.mount 2c19d884.../172.17.8.101 active mounted mnt-data.mount 8f7472a6.../172.17.8.102 inactive dead mnt-data.mount b44a7261.../172.17.8.103 inaktiv tot [/bash] Wie Sie sehen können, laufen drei app-hellodb-Instanzen und der redis-Dienst läuft auf 172.17.8.101, dem einzigen Rechner, auf dem /mnt/data eingehängt ist. Auf den anderen beiden Rechnern hat dieser Mount den Status 'dead', was eine unfreundliche Bezeichnung für 'stopped' ist. Jetzt können Sie auf die app-hellodb zugreifen. [bash] yes 'curl hellodb.127.0.0.1.xip.io:8080; echo ' | head -10 | bash .. Hallo Welt! Ich wurde schon 20 Mal gesehen. Hallo Welt! Ich wurde schon 21 Mal gesehen. Hallo Welt! Ich wurde 22 Mal gesehen. Hallo Welt! Ich wurde 23 Mal gesehen. Hallo Welt! Ich wurde schon 24 Mal gesehen. Hallo Welt! Ich wurde schon 25 Mal gesehen.Hallo Welt! Ich wurde schon 26 Mal gesehen. Hallo Welt! Ich wurde 27 Mal gesehen. Hallo Welt! Ich wurde schon 28 Mal gesehen. Hallo Welt! Ich wurde 29 Mal gesehen. [/bash]

Redis Fail-over in Aktion

Um das Failover in Aktion zu sehen, starten Sie einen Monitor auf einem Rechner, auf dem Redis nicht läuft. In unserem Fall der Rechner, auf dem app-hellodb@1 läuft. [bash] vagrant ssh -c "yes 'curl --max-time 2 hellodb.127.0.0.1.xip.io; sleep 1 ' | bash" app-hellodb@1.service [/bash] Starten Sie nun die Redis-Maschine neu: [bash] vagrant ssh -c "sudo shutdown -r now" app-redis.service [/bash] Nachdem Sie den Rechner, auf dem Redis läuft, neu gestartet haben, sollte die Ausgabe etwa so aussehen: [bash] ... Hallo Welt! Ich wurde schon 1442 Mal gesehen. Hallo Welt! Ich wurde schon 1443 Mal gesehen. Hallo Welt! Ich wurde 1444 Mal gesehen. Hallo Welt! Ich kann Ihnen nicht sagen, wie oft ich gesehen wurde. (Fehler 111 beim Verbinden mit redis:6379. Verbindung abgelehnt.) curl: (28) Operation timed out after 2004 milliseconds with 0 out of -1 bytes received curl: (28) Operation timed out after 2007 milliseconds with 0 out of -1 bytes received Hallo Welt! Ich wurde schon 1445 Mal gesehen. Hello World! Ich wurde 1446 Mal gesehen. curl: (28) Operation timed out after 2004 milliseconds with 0 out of -1 bytes received curl: (28) Operation timed out after 2004 milliseconds with 0 out of -1 bytes received Hello World! Ich wurde bereits 1447 Mal gesehen. Hello World! Ich wurde schon 1448 Mal gesehen. ... [/bash] Beachten Sie, dass sich die Verteilung Ihrer Einheiten nach dem Neustart geändert hat. [bash] fleetctl list-units ... UNIT MACHINE ACTIVE SUB app-hellodb@1.service 3376bf5c.../172.17.8.103 active running app-hellodb@2.service ff0e7fd5.../172.17.8.102 active running app-hellodb@3.service 3376bf5c.../172.17.8.103 aktiv läuft app-redis.service ff0e7fd5.../172.17.8.102 aktiv läuft mnt-data.mount 309daa5a.../172.17.8.101 inaktiv tot mnt-data.mount 3376bf5c.../172.17.8.103 inaktiv tot mnt-data.mount ff0e7fd5.../172.17.8.102 aktiv montiert [/bash]

Fazit

Damit haben wir die Grundlage für eine wirklich unveränderliche Infrastruktur geschaffen: Der gesamte CoreOS-Cluster einschließlich der Anwendung kann zerstört werden und eine völlig identische Umgebung kann innerhalb weniger Minuten wiederhergestellt werden!

• Sobald Sie einen zuverlässigen externen persistenten Speicher haben, kann CoreOS Ihnen helfen, persistente Dienste genauso einfach zu migrieren wie zustandslose Dienste. Wir haben uns aus Gründen der Benutzerfreundlichkeit für einen NFS-Server entschieden, aber nichts hindert Sie daran, andere Arten von Speichersystemen für Ihre Anwendung zu verwenden.
• Consul zeichnet sich durch eine schnelle und dynamische Erkennung von Diensten aus. So kann der Redis-Dienst auf einen anderen Rechner migriert werden und die Anwendungsinstanzen können die neue Adresse des Redis-Dienstes durch eine einfache DNS-Abfrage finden!