Erstellen flexibler Dienste für einen CoreOS-Cluster mit Flotteneinheitendateien

CoreOS-Installationen nutzen eine Reihe von Tools, um die Verwaltung von Clustering- und Docker-Diensten zu vereinfachen. Während "+ etcd " für die Verknüpfung der einzelnen Knoten und die Bereitstellung eines Bereichs für globale Daten zuständig ist, besteht der größte Teil der eigentlichen Dienstverwaltungs- und Verwaltungsaufgaben darin, mit dem Daemon " fleet +" zu arbeiten.

In einem previous guide gingen wir auf die grundlegende Verwendung von Befehl + fleetctl + zum Manipulieren der Dienste und Cluster-Mitglieder. In diesem Handbuch haben wir kurz auf die Einheitendateien eingegangen, die die Flotte zur Definition von Diensten verwendet. Dies waren jedoch vereinfachte Beispiele für die Bereitstellung eines funktionierenden Dienstes zum Erlernen von + fleetctl +.

In diesem Handbuch werden wir uns eingehend mit den "+ Flotte +" - Einheitendateien befassen, um zu erfahren, wie sie erstellt werden, und um einige Techniken zu erlernen, mit denen Ihre Dienste in der Produktion robuster werden.

Um dieses Tutorial abzuschließen, wird davon ausgegangen, dass Sie einen CoreOS-Cluster konfiguriert haben, wie in unserer https://www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on beschrieben -digitalocean [Clustering-Anleitung]. So haben Sie drei Server mit dem Namen:

Obwohl sich der größte Teil dieses Lernprogramms auf die Erstellung von Einheitendateien konzentriert, werden diese Computer später verwendet, um die Auswirkungen bestimmter Anweisungen auf die Zeitplanung zu veranschaulichen.

Wir gehen auch davon aus, dass Sie unseren Leitfaden unter how to use-your-coreos-clusters gelesen haben fleetctl. Sie sollten über gute Kenntnisse von "+ fleetctl +" verfügen, damit Sie diese Einheitendateien mit dem Cluster senden und verwenden können.

Wenn Sie diese Anforderungen erfüllt haben, fahren Sie mit dem Rest des Handbuchs fort.

Da der Service-Management-Aspekt von "+ fleet " hauptsächlich vom " systemd " init-System jedes lokalen Systems abhängt, werden " systemd +" Unit-Dateien zum Definieren von Services verwendet.

Während Services mit Abstand der gebräuchlichste mit CoreOS konfigurierte Einheitentyp sind, können tatsächlich andere Einheitentypen definiert werden. Dies ist eine Untergruppe derjenigen, die für konventionelle Unit-Dateien ("+ systemd ") verfügbar sind. Jeder dieser Typen wird durch den Typ identifiziert, der als Dateisuffix verwendet wird, wie z. B. " example.service +":

Obwohl diese Optionen alle verfügbar sind, werden Serviceeinheiten am häufigsten verwendet. In diesem Handbuch werden nur die Konfigurationen der Wartungseinheiten erläutert.

Unit-Dateien sind einfache Textdateien, die mit einem Punkt und einem der oben genannten Suffixe enden. Im Inneren sind sie nach Abschnitten gegliedert. Für + Flotte + haben die meisten Einheitendateien das folgende allgemeine Format:

Die Abschnittsüberschriften und alles andere in einer Unit-Datei unterscheidet zwischen Groß- und Kleinschreibung. Der Abschnitt "+ [Einheit] +" wird verwendet, um allgemeine Informationen zu einer Einheit zu definieren. Optionen, die für alle Einheitentypen gelten, werden in der Regel hier platziert.

Der Abschnitt "+ [Service] +" wird verwendet, um Anweisungen festzulegen, die für Serviceeinheiten spezifisch sind. Die meisten (aber nicht alle) der oben genannten Einheitentypen verfügen über zugeordnete Abschnitte für spezifische Informationen zum Einheitentyp. Weitere Informationen finden Sie in der Manpage generic systemd unit file, die Links zu den verschiedenen Einheitentypen enthält.

Der Abschnitt "+ [X-Fleet] " wird verwendet, um die Planungsanforderungen für die Einheit zur Verwendung mit " Flotte +" festzulegen. In diesem Abschnitt können Sie festlegen, dass bestimmte Bedingungen erfüllt sein müssen, damit eine Einheit auf einem Host geplant werden kann.

In diesem Abschnitt beginnen wir mit einer Variante der Unit-Datei, die in unserer https://www.digitalocean.com/community/tutorials/how-to-create-and-run-a-service-on-a-coreos beschrieben ist -cluster [grundlegende Anleitung zum Ausführen von Diensten unter CoreOS]. Die Datei heißt + apache.1.service + und sieht folgendermaßen aus:

Wir beginnen mit dem Abschnitt "+ [Unit] ". Hier besteht die Grundidee darin, die Einheit zu beschreiben und die Abhängigkeitsinformationen festzulegen. Wir beginnen mit einer Reihe von Anforderungen. Für dieses Beispiel haben wir harte Anforderungen verwendet. Wenn wir wollten, dass " fleet " versucht, zusätzliche Dienste zu starten, aber nicht bei einem Fehler beendet wird, hätten wir stattdessen die Direktive " Wants +" verwenden können.

Anschließend listen wir explizit die Reihenfolge der Anforderungen auf. Dies ist wichtig, damit die erforderlichen Dienste verfügbar sind, wenn sie benötigt werden. Es ist auch die Art und Weise, wie wir automatisch den Sidekick-Ankündigungsdienst starten, den wir bauen werden.

Für den Abschnitt "+ [Service] +" deaktivieren wir das Zeitlimit für den Start des Dienstes. Wenn ein Dienst zum ersten Mal auf einem Host ausgeführt wird, muss der Container aus der Docker-Registrierung abgerufen werden, was für das Startzeitlimit gilt. Die Standardeinstellung ist 90 Sekunden, was normalerweise ausreicht. Bei komplexeren Containern kann dies jedoch länger dauern.

Wir setzen dann den Killmode auf none. Dies wird verwendet, weil der normale Kill-Modus (Kontrollgruppe) manchmal dazu führt, dass Container-Entfernungsbefehle fehlschlagen (insbesondere, wenn die Docker-Option + - rm + versucht). Dies kann beim nächsten Neustart zu Problemen führen.

Wir ziehen die Umgebungsdatei ein, damit wir Zugriff auf die Umgebungsvariablen "+ COREOS_PUBLIC_IPV4 " und, falls das private Netzwerk während der Erstellung aktiviert war, auf die Umgebungsvariablen " COREOS_PRIVATE_IPV4 +" haben. Diese sind sehr nützlich, um Docker-Container so zu konfigurieren, dass sie die Informationen ihres jeweiligen Hosts verwenden.

Die Zeilen + ExecStartPre + werden verwendet, um Reste von vorherigen Läufen zu entfernen, um sicherzustellen, dass die Ausführungsumgebung sauber ist. Wir verwenden in den ersten beiden Fällen "+ = - ", um anzugeben, dass " systemd +" ignoriert und fortgesetzt werden soll, wenn diese Befehle fehlschlagen. Aus diesem Grund versucht Docker, frühere Container zu töten und zu entfernen, macht sich jedoch keine Sorgen, wenn keine gefunden werden. Der letzte Pre-Start wird verwendet, um sicherzustellen, dass die aktuellste Version des Containers ausgeführt wird.

Der eigentliche Startbefehl startet den Docker-Container und bindet ihn an die öffentliche IPv4-Schnittstelle des Host-Computers. Dadurch werden die Informationen in der Umgebungsdatei verwendet, und das Wechseln von Schnittstellen und Ports ist kein Problem. Der Prozess wird im Vordergrund ausgeführt, da der Container beendet wird, wenn der ausgeführte Prozess endet. Der Befehl stop versucht, den Container ordnungsgemäß zu stoppen.

Der Abschnitt "+ [X-Fleet] " enthält eine einfache Bedingung, die " fleet +" zwingt, den Dienst auf einer Maschine zu planen, auf der noch kein anderer Apache-Dienst ausgeführt wird. Auf diese Weise können Sie einen Dienst auf einfache Weise hoch verfügbar machen, indem Sie doppelte Dienste zwingen, auf separaten Computern zu starten.

Jetzt, da wir eine gute Vorstellung davon haben, was beim Aufbau eines Hauptdienstes zu beachten ist, können wir anfangen, uns mit einem herkömmlichen "Sidekick" -Dienst zu befassen. Diese Sidekick-Dienste sind einem Hauptdienst zugeordnet und werden als externer Punkt zum Registrieren von Diensten bei "+ etcd +" verwendet.

Diese Datei, auf die in der Hauptgerätedatei verwiesen wurde, heißt "+ apache-discovery.1.service +" und sieht folgendermaßen aus:

Wir starten den Sidekick-Service auf die gleiche Weise wie den Hauptservice. Wir beschreiben den Zweck der Einheit, bevor wir zu den Abhängigkeitsinformationen und der Ordnungslogik übergehen.

Das erste neue Element hier ist die Direktive + BindsTo = +. Diese Anweisung veranlasst dieses Gerät, den an das aufgelistete Gerät gesendeten Befehlen zum Starten, Stoppen und Neustarten zu folgen. Grundsätzlich bedeutet dies, dass wir beide Einheiten verwalten können, indem wir die Haupteinheit manipulieren, sobald beide in "+ Flotte +" geladen sind. Dies ist ein Einwegmechanismus, sodass die Steuerung des Sidekicks keine Auswirkungen auf die Haupteinheit hat.

Für den Abschnitt "+ [Service] " beziehen wir wieder die Datei " / etc / environment ", da wir die darin enthaltenen Variablen benötigen. Die Direktive " ExecStart = " ist in diesem Fall im Grunde ein kurzes " bash +" - Skript. Es wird versucht, über die Schnittstelle und den Port, die verfügbar gemacht wurden, eine Verbindung zu den Hauptdiensten herzustellen.

Bei erfolgreicher Verbindung wird mit dem Befehl "+ etcdctl " ein Schlüssel für die öffentliche IP-Adresse des Host-Computers in " / services / apache " in " etcd " festgelegt. Der Wert dieses Objekts ist ein JSON-Objekt, das Informationen zum Service enthält. Der Schlüssel ist so eingestellt, dass er in 30 Sekunden abläuft. Wenn dieses Gerät unerwartet ausfällt, bleiben veraltete Serviceinformationen nicht in " etcd +" erhalten. Wenn die Verbindung fehlschlägt, wird der Schlüssel sofort entfernt, da nicht überprüft werden kann, ob der Dienst verfügbar ist.

Diese Schleife enthält einen 20-Sekunden-Schlafbefehl. Dies bedeutet, dass dieses Gerät alle 20 Sekunden (vor dem Timeout der Taste "+ etcd +" von 30 Sekunden) erneut prüft, ob die Haupteinheit verfügbar ist, und den Schlüssel zurücksetzt. Dies aktualisiert im Grunde die TTL auf dem Schlüssel, so dass sie für weitere 30 Sekunden als gültig angesehen wird.

Der Stoppbefehl führt in diesem Fall lediglich zu einem manuellen Entfernen des Schlüssels. Dadurch wird die Serviceregistrierung entfernt, wenn der Stoppbefehl des Hauptgeräts aufgrund der Direktive "+ BindsTo = +" auf dieses Gerät gespiegelt wird.

Für den Abschnitt "+ [X-Fleet] " müssen wir sicherstellen, dass dieses Gerät auf demselben Server wie das Hauptgerät gestartet wird. Dies ermöglicht es dem Gerät zwar nicht, die Verfügbarkeit des Dienstes für Remotecomputer zu melden, es ist jedoch wichtig, dass die Direktive ` BindsTo = +` korrekt funktioniert.

Während sich + fleet + Unit-Dateien größtenteils nicht von herkömmlichen + systemd + Unit-Dateien unterscheiden, gibt es einige zusätzliche Funktionen und Fallstricke.

Der offensichtlichste Unterschied ist die Hinzufügung eines Abschnitts mit dem Namen "+ [X-Fleet] ", der verwendet werden kann, um " Flotte +" zu steuern, wie Planungsentscheidungen getroffen werden sollen. Die verfügbaren Optionen sind:

Diese zusätzlichen Anweisungen geben einem Administrator mehr Flexibilität und Befugnis bei der Festlegung, wie Dienste auf den verfügbaren Computern ausgeführt werden sollen. Diese werden ausgewertet, bevor sie während der Phase "+ fleetctl load " an die Instanz " systemd +" einer bestimmten Maschine übergeben werden.

Dies bringt uns zum nächsten Punkt, auf den wir achten müssen, wenn wir mit verwandten Einheiten in + fleet + arbeiten. Das Dienstprogramm "+ fleetctl " bewertet keine Abhängigkeitsanforderungen außerhalb des Abschnitts " [X-Fleet] " der Einheitendatei. Dies führt zu interessanten Problemen bei der Arbeit mit Companion Units in ` fleet +`.

Dies bedeutet, dass das Tool "+ fleetctl +" zwar den erforderlichen Schritt unternimmt, um die Zieleinheit in den gewünschten Zustand zu versetzen, und den Vorgang des Übergebens, Ladens und Startens nach Bedarf basierend auf dem gegebenen Befehl durchläuft, dies jedoch nicht für die Abhängigkeiten der Einheit.

Wenn Sie also sowohl Ihre Haupt- als auch Ihre Sidekick-Einheit übermittelt, aber nicht geladen haben, geben Sie "+ fleetctl start main.service " ein und versuchen dann, die " main.service " - Einheit zu starten. Da jedoch die Einheit " sidekick.service " noch nicht geladen ist und " fleetctl " die Abhängigkeitsinformationen nicht auswertet, um die Abhängigkeitseinheiten durch den Lade- und Startvorgang zu bringen, schlägt die Einheit " main.service " fehl . Dies liegt daran, dass, sobald die Instanz " systemd " der Maschine die Einheit " main.service " verarbeitet, sie " sidekick.service " nicht finden kann, wenn _it_ die Abhängigkeiten auswertet. Die Einheit " sidekick.service +" wurde nie in die Maschine geladen.

Um diese Situation beim Umgang mit Companion Units zu vermeiden, können Sie die Dienste gleichzeitig manuell starten, ohne sich auf die Anweisung + BindsTo = + zu verlassen, die den Sidekick in einen aktiven Zustand versetzt:

Eine andere Möglichkeit besteht darin, sicherzustellen, dass die Sidekick-Einheit mindestens geladen ist, wenn die Haupteinheit ausgeführt wird. In der Ladephase wird eine Maschine ausgewählt und die Unit-Datei an die lokale Instanz "+ systemd " übergeben. Dies stellt sicher, dass die Abhängigkeiten erfüllt sind und dass die Direktive ` BindsTo = +` korrekt ausgeführt werden kann, um die zweite Unit aufzurufen:

Denken Sie daran, falls Ihre verbundenen Einheiten nicht korrekt auf Ihre Befehle + fleetctl + reagieren.

Eines der leistungsstärksten Konzepte bei der Arbeit mit "+ fleet +" sind Einheitenvorlagen.

Einheitenvorlagen basieren auf einer Funktion von "+ systemd +", die "Instanzen" genannt wird. Hierbei handelt es sich um instanziierte Einheiten, die zur Laufzeit durch Verarbeitung einer Vorlageneinheitendatei erstellt werden. Die Vorlagendatei ist größtenteils einer normalen Unit-Datei sehr ähnlich, mit ein paar kleinen Änderungen. Diese sind jedoch bei richtiger Anwendung äußerst leistungsfähig.

Vorlagendateien können durch das "+ @ +" in ihrem Dateinamen identifiziert werden. Während ein herkömmlicher Dienst diese Form annimmt:

Eine Vorlagendatei kann folgendermaßen aussehen:

Wenn eine Einheit aus einer Vorlage instanziiert wird, wird ihre Instanzkennung zwischen dem Suffix "+ @ " und " .service +" eingefügt. Diese ID ist eine eindeutige Zeichenfolge, die vom Administrator ausgewählt wird:

Auf den Namen der Basiseinheit kann in der Einheitendatei mit dem Bezeichner "% p +" zugegriffen werden. Ebenso kann mit `% i +` auf die angegebene Instanzkennung zugegriffen werden.

Sie sollten zu diesem Zeitpunkt ein gutes Verständnis dafür haben, wie Unit-Dateien für "+ fleet " erstellt werden. Indem Sie einige der in Gerätedateien verfügbaren dynamischen Funktionen nutzen, können Sie sicherstellen, dass Ihre Dienste gleichmäßig verteilt sind, in der Nähe ihrer Abhängigkeiten und nützliche Informationen mit " etcd +" registrieren.

In einem later guide wird das Konfigurieren erläutert Ihre Container, um die Informationen zu verwenden, die Sie bei + etcd + registrieren. Dies kann Ihre Services dabei unterstützen, ein funktionierendes Wissen über Ihre tatsächliche Bereitstellungsumgebung aufzubauen, um Anforderungen an die entsprechenden Container im Backend weiterzuleiten.