TOC

So verwalten Sie Ihren CoreOS-Cluster mit Fleet und Fleetctl

Einführung

CoreOS bietet eine hervorragende Umgebung für die Verwaltung von Docker-Containern in Umgebungen mit mehreren Servern. Eine der wichtigsten Komponenten zur Vereinfachung dieses Cluster-Managements ist ein Dienst namens * fleet *.

Mit Fleet können Benutzer Docker-Container als Services für ihren gesamten Cluster verwalten. Es fungiert als Schnittstelle und Abstraktionsebene für das systemd init-System jedes Clustermitglieds. Benutzer können Einschränkungen festlegen, die sich auf die Bedingungen auswirken, unter denen ein Dienst ausgeführt wird. Auf diese Weise können Administratoren festlegen, wie ihre Infrastruktur aussehen soll, indem sie bestimmten Anwendungen anweisen, auf demselben oder auf separaten Hosts basierend auf den angegebenen Kriterien ausgeführt zu werden.

In diesem Handbuch werden wir Flotte und das Dienstprogramm + fleetctl + untersuchen, mit dem Sie den Dämon steuern können.

Voraussetzungen

Um diesem Handbuch folgen zu können, sollte ein CoreOS-Cluster verfügbar sein.

Der in diesem Handbuch verwendete Cluster kann in unserem Handbuch unter how to erstellt werden CoreOS-Cluster auf DigitalOcean erstellen. Wir gehen davon aus, dass Sie die in diesem Handbuch beschriebene Cluster-Konfiguration haben.

Der konfigurierte Cluster verfügt über drei Knoten. Sie sind so konfiguriert, dass sie über die private Netzwerkschnittstelle miteinander kommunizieren. Die öffentliche Schnittstelle ist auf jedem dieser Knoten zum Ausführen öffentlicher Dienste verfügbar. Die Knotennamen sind:

  • Coreos-1

  • Coreos-2

  • Coreos-3

Wenn Sie Ihren Cluster bereit haben, erfahren Sie mehr über die Flotte.

Arbeiten mit Service Unit-Dateien

Bevor wir uns mit dem Tool + fleetctl + befassen, sollten wir uns ein wenig mit Service-Unit-Dateien befassen.

Unit-Dateien werden vom Init-System "+ systemd " verwendet, um jeden verfügbaren Service zu beschreiben, die zu seiner Verwaltung erforderlichen Befehle zu definieren und Abhängigkeitsinformationen festzulegen, um sicherzustellen, dass sich das System beim Start jedes Services in einem funktionsfähigen Zustand befindet. Der Daemon ` fleet ` baut auf ` systemd ` auf, um Services clusterweit zu verwalten. Aus diesem Grund werden leicht modifizierte Versionen der Standard-Unit-Dateien ` systemd +` verwendet.

Um einen detaillierten Einblick in die Dateien von + fleet + zu erhalten, folgen Sie unseren https://www.digitalocean.com/community/tutorials/how-to-create-flexible-services-for-a-coreos-cluster-with -fleet-unit-files [deep dive] zum thema. In diesem Handbuch geben wir nur einen groben Überblick über das Format dieser Dateien. Wir werden auch eine Beispiel-Unit-Datei bereitstellen, mit der Sie sich über + fleetctl + informieren können.

Dateiabschnitte der Flotteneinheit

Die grundlegenden Abschnitte, die die meisten Unit-Dateien enthalten, sind:

  • * Einheit *: In diesem Abschnitt werden allgemeine Informationen zur Einheit bereitgestellt, die nicht vom „Typ“ der Einheit abhängig sind. Dies umfasst Metadateninformationen und Abhängigkeitsinformationen. Dies wird hauptsächlich in + Flotte + verwendet, um Beschreibungen bereitzustellen und diese Einheiten in Verbindung mit anderen Serviceeinheiten zu setzen.

  • * Unit Type Section *: Der Daemon + fleet + kann Einheiten verschiedener Typen aufnehmen, einschließlich:

  • Bedienung

  • Steckdose

  • Gerät

  • Montieren

  • Automount

  • Timer

  • Path

Wenn der Typ über bestimmte Optionen verfügt, ist ein Abschnitt des zugeordneten Typs zulässig. Der Abschnittstyp "+ Service " ist bei weitem der häufigste. In diesem Abschnitt werden typspezifische Attribute definiert. Bei " Service +" - Einheiten müssen in der Regel die Start- und Stoppbefehle sowie die Start- und Stoppbefehle vor und nach dem Start definiert werden, die möglicherweise zugehörige Aktionen ausführen.

  • * X-Fleet *: In diesem Bereich werden flottenspezifische Konfigurationsoptionen bereitgestellt. Dies bedeutet hauptsächlich, dass Sie festlegen können, dass ein Dienst auf der Grundlage von Kriterien wie Computer-ID, derzeit ausgeführten Diensten, Metadateninformationen usw. auf bestimmte Weise geplant werden muss oder nicht.

Das allgemeine Format einer Unit-Datei lautet:

[Unit]



[Service]



[X-Fleet]

Beispiel für eine Service Unit-Datei

Um mit diesem Tutorial zu beginnen, stellen wir Ihnen eine Unit-Datei zur Verfügung. Dies ist als Beispiel der CoreOS-Schnellstartseite entnommen. Geben Sie auf einem Ihrer CoreOS-Computer Folgendes ein:

vim hello.service

Geben Sie im Inneren unsere Beispielservicedatei ein:

[Unit]
Description=My Service
After=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill hello
ExecStartPre=-/usr/bin/docker rm hello
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop=/usr/bin/docker stop hello

Lassen Sie uns kurz überlegen, was dies bewirkt.

Im Abschnitt "+ [Einheit] " wird eine Beschreibung festgelegt, und wir teilen " systemd " mit, dass dieser Dienst nur ausgeführt werden kann, nachdem die Einheit " docker.service +" gestartet wurde. Dies liegt daran, dass unser Gerät auf Docker angewiesen ist, um zu funktionieren.

Im Abschnitt "+ [Dienst] " deaktivieren wir das Startzeitlimit und richten dann einige Aktionen ein, die vor dem Starten des Dienstes ausgeführt werden sollen. Das ` ExecStartPre ` wird vor der Hauptaktion ` ExecStart ` ausgeführt. Wenn diese mit " = - +" aufgerufen werden, bedeutet dies, dass die Aktion fehlschlagen kann und sich nicht auf die Beendigung des Dienstes auswirkt. Dies ist erforderlich, da durch unsere Vorbereitungsaktionen alle zuvor ausgeführten Dienste, die möglicherweise ausgeführt wurden, im Grunde genommen heruntergefahren werden. Dies schlägt fehl, wenn keine gefunden werden und wir nicht möchten, dass unser Dienst nicht mehr startet, da dies nur eine Bereinigungsprozedur ist.

Die letzte Aktion vor dem Start ruft das Basisimage der Busybox auf, mit dem unsere Befehle ausgeführt werden. Da dies erforderlich ist, wird die Syntax "+ = - +" nicht verwendet. Wir starten dann einen Container mit diesem Bild mit einer Endlosschleife, die einmal pro Sekunde „Hallo Welt“ ausgibt. Die Stop-Aktion stoppt einfach diesen Container.

Dies ist gerade genug, um Sie zum Laufen zu bringen. Weitere Informationen zum Entwickeln von Flottendateien finden Sie unter https://www.digitalocean.com/community/tutorials/how-to-create-flexible-services-for-a-coreos-cluster-with-fleet- Einheitendateien [unser Leitfaden für Flotteneinheitendateien].

Grundlegende Befehle zur Maschinenverwaltung

Als erstes werden wir Ihnen das Dienstprogramm + fleetctl + vorstellen. Als Cluster-Administrator ist dieses Tool Ihre Hauptschnittstelle für die Verwaltung Ihrer Maschinenflotte. Ein Großteil der Syntax wurde von + systemctl +, dem Management-Tool von systemd, übernommen.

Zunächst können wir eine Liste aller Cluster-Mitglieder abrufen, indem wir Folgendes eingeben:

fleetctl list-machines
MACHINE     IP      METADATA
14ffe4c3... 10.132.249.212  -
1af37f7c... 10.132.249.206  -
9e389e93... 10.132.248.177  -

Wie Sie sehen, wird jede Ihrer Maschinen hier als verfügbar aufgeführt. Wenn sich jedes Mitglied mithilfe der Cloud-Konfigurationsdatei bootet, generiert es eine eindeutige Rechner-ID, anhand derer jeder Knoten identifiziert wird. Dies wird in eine Datei unter + / etc / machine-id geschrieben.

Standardmäßig verwendet die Flotte die öffentliche IPv4-Adresse des Geräts für die Kommunikation mit anderen Mitgliedern. In unserer Cloud-Konfigurationsdatei haben wir Flotte jedoch angewiesen, unsere privaten Schnittstellen für die Kommunikation zu verwenden. Dies sind die IP-Adressen, die in der obigen Ausgabe angezeigt werden.

Die Spalte „METADATA“ ist im obigen Beispiel derzeit leer. Wir hätten jedoch beliebige Schlüssel-Wert-Paare unter dem Attribut "+ Metadaten +" für die Flotte in der Cloud-Konfiguration hinzufügen können. Das könnte so aussehen:

#cloud-config
. . .
coreos:
 fleet:
   public-ip: $private_ipv4
   metadata: region=europe,public_ip=$public_ipv4

Wenn Sie dies in Ihrer Cloud-Konfiguration so einstellen, dass alle Ihre Computer gebootet werden, sieht Ihre Ausgabe ungefähr so ​​aus:

MACHINE     IP      METADATA
14ffe4c3... 10.132.249.212  public_ip=104.131.36.200,region=europe
1af37f7c... 10.132.249.206  public_ip=104.131.15.192,region=europe
9e389e93... 10.132.248.177  public_ip=104.131.15.192,region=europe

Diese zusätzlichen Daten sind nützlich, um Informationen über einen Knoten aus Managementsicht schnell abzurufen. Sie können jedoch auch in Dienstdefinitionen verwendet werden, um bestimmte Hosts als Ziel festzulegen.

Um eine Verbindung zu einem bestimmten Computer innerhalb des Clusters herzustellen, können Sie den Befehl + fleetctl ssh + verwenden. Auf diese Weise können Sie ein Gerät, mit dem eine Verbindung hergestellt werden soll, anhand seiner Geräte-ID oder anhand des mit einem angegebenen Gerätenamen verknüpften Geräts identifizieren.

Wenn Sie beispielsweise eine Unit mit dem Namen "+ nginx.service +" haben, können Sie eine Verbindung zu einem beliebigen Host herstellen, auf dem dieser Service ausgeführt wird, indem Sie Folgendes eingeben:

fleetctl ssh nginx

Sie werden auf dem zugeordneten Host in eine Shell-Sitzung versetzt. Sie können auch einen einzelnen Befehl auf einem Remote-Host ausführen, genau wie bei der Ausführung mit der normalen ausführbaren Datei "+ ssh ". Um beispielsweise die Werte der Variablen " COREOS_PRIVATE_IPV4 " und " COREOS_PUBLIC_IPV4 " abzurufen, die CoreOS in einer Datei mit dem Namen " / etc / environment +" festlegt (basierend auf den Parametern der Cloud-Konfiguration und den verfügbaren Netzwerkschnittstellen), du kannst Tippen:

fleetctl ssh nginx cat /etc/environment
COREOS_PRIVATE_IPV4=10.132.249.212
COREOS_PUBLIC_IPV4=104.131.29.80

Service-Management

Die meisten anderen Befehle, die über + fleetctl + verfügbar sind, basieren auf dem Service-Management.

Starten eines Dienstes

Das Starten eines Dienstes erfordert einige Schritte. Die Servicedatei muss in "+ Flotte " hochgeladen werden, damit sie das Gerät erkennt. Es muss dann auf einem bestimmten Computer außerhalb des Clusters geplant werden. Es kann dann gestartet werden. Es gibt Befehle für jeden von diesen mit ` fleetctl +`, wobei die Befehle, die für die letzteren Stufen verantwortlich sind, bei Bedarf auch die ersteren ausführen.

Sie können den Befehl "+ submit " verwenden, um Ihre Einheitendatei an " fleet " zu senden. Dies bewirkt einfach, dass ` fleet +` den Dateiinhalt in den Speicher liest und für weitere Aktionen zur Verfügung stellt.

fleetctl submit hello.service

Ihre + hello.service + Datei ist jetzt + fleet + bekannt. Um die gesendeten Unit-Dateien anzuzeigen, können Sie Folgendes eingeben:

fleetctl list-unit-files
UNIT        HASH    DSTATE      STATE       TMACHINE
hello.service   0d1c468 inactive    inactive    -

Wie Sie sehen, ist die Unit-Datei vorhanden, wurde jedoch auf keinem Host eingeplant oder gestartet.

Um den Inhalt einer Unit-Datei zu sehen, von der + fleet + weiß, können Sie Folgendes eingeben:

fleetctl cat hello.service
[Unit]
Description=My Service
After=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill hello
ExecStartPre=-/usr/bin/docker rm hello
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop=/usr/bin/docker stop hello

Auf diese Weise können Sie die aktuelle Datei anzeigen, die + fleet + kennt.

  • Hinweis *: Der Befehl submit ist idempotent, was bedeutet, dass + fleet + die In-Memory-Unit-Datei nicht aktualisiert, wenn Sie sie erneut senden. Wenn Sie Ihre Gerätedatei aktualisieren müssen, müssen Sie sie vollständig entfernen und erneut senden. Wir werden uns später damit befassen.

Sobald Ihr Gerät übermittelt wurde, ist der nächste Schritt, es auf einem Computer zu planen. Bei der Planung der Einheit muss die "+ Flotte " - Engine die Einheit untersuchen, um die beste Maschine im Cluster zu bestimmen, an die die Einheit übergeben werden soll. Dies hängt von den Bedingungen im Abschnitt " [X-Fleet] " der Einheit sowie vom aktuellen Arbeitsvolumen der einzelnen Maschinen im Cluster ab. Wenn die Einheit eingeplant wurde, wurde sie an die bestimmte Maschine übergeben und in die lokale Instanz " systemd +" geladen.

Verwenden Sie den Befehl + load +, um die Einheit zu laden und zu planen:

fleetctl load hello.service
Unit hello.service loaded on 14ffe4c3.../10.132.249.212

Wenn Sie Ihr Gerät zuvor nicht manuell geladen haben, wird es im Rahmen dieses Vorgangs automatisch geladen, indem Sie im aktuellen Verzeichnis nach dem entsprechenden Dateinamen suchen.

Wenn wir nun unsere Unit-Dateien überprüfen, können wir feststellen, dass sie geladen wurden. Wir können sogar sehen, auf welcher Maschine es geplant ist:

fleetctl list-unit-files
UNIT        HASH    DSTATE  STATE   TMACHINE
hello.service   0d1c468 loaded  loaded  14ffe4c3.../10.132.249.212

Dies ist auch unsere erste Gelegenheit, den Befehl + list-units + auszuprobieren. Dieser Befehl wird verwendet, um laufende oder geplante Einheiten und deren Status anzuzeigen:

fleetctl list-units
UNIT        MACHINE             ACTIVE      SUB
hello.service   14ffe4c3.../10.132.249.212  inactive    dead

Um eine Einheit tatsächlich zu starten, können Sie den Befehl + start + verwenden. Dies startet die Einheit auf der Maschine, in die sie geladen wurde, indem die in der Einheitendatei definierten Startbefehle ausgeführt werden:

fleetctl start hello.service
Unit hello.service launched on 14ffe4c3.../10.132.249.212

Wir sollten noch einmal die + list-unit-files überprüfen:

fleetctl list-unit-files
UNIT        HASH    DSTATE      STATE       TMACHINE
hello.service   0d1c468 launched    launched    14ffe4c3.../10.132.249.212

In der obigen Ausgabe können wir sehen, dass der Dienst gestartet wurde. Die Spalte "+ ZUSTAND" zeigt den "gewünschten Zustand" an und "+ ZUSTAND" zeigt den tatsächlichen Zustand an. Wenn diese beiden übereinstimmen, bedeutet dies normalerweise, dass die Aktion erfolgreich war.

Wir sollten uns auch noch einmal + list-units + ansehen:

fleetctl list-units
UNIT        MACHINE             ACTIVE  SUB
hello.service   14ffe4c3.../10.132.249.212  active  running

Dies gibt uns Auskunft über den Zustand "+ systemd ". Es wird direkt vom lokalen Dämon abgerufen, um ein besseres Bild davon zu erhalten, wie das lokale System den Dienststatus sieht. Die Spalte " ACTIVE " ist ein verallgemeinerter Zustand der Einheit, während " SUB +" eine einfachere Beschreibung ist.

Beenden eines Dienstes

Jeder der obigen Befehle verfügt über einen Begleitbefehl, der den Status umkehrt.

Um beispielsweise die Ausführung eines Dienstes zu stoppen, verwenden Sie den Befehl + stop +. Dadurch führt die Instanz "+ systemd +" der lokalen Maschine die in der Einheit definierten Stoppbefehle aus:

fleetctl stop hello.service
Unit hello.service loaded on 14ffe4c3.../10.132.249.212

Wie Sie sehen, wurde der Dienst wieder in den Status "+ geladen " versetzt. Dies bedeutet, dass es noch im ` systemd +` der Maschine geladen ist, aber gerade nicht läuft. Das können wir hier bestätigen:

fleetctl list-unit-files
UNIT        HASH    DSTATE  STATE   TMACHINE
hello.service   0d1c468 loaded  loaded  14ffe4c3.../10.132.249.212

Um die Einheit aus dem System dieses Computers zu entfernen, sie jedoch in "+ Flotte " verfügbar zu halten, können Sie die Einheit " entladen +". Wenn das Gerät gerade aktiv ist, wird es vor dem Entladen angehalten:

fleetctl unload hello.service

Wenn wir den Status überprüfen, können wir sehen, dass er jetzt als inaktiv markiert ist. Es ist auch kein Zielcomputer aufgeführt:

fleetctl list-unit-files
UNIT        HASH    DSTATE      STATE       TMACHINE
hello.service   0d1c468 inactive    inactive    -

Wenn wir die Einheit vollständig aus der Flotte entfernen wollen, können wir den Befehl "+ destroy " verwenden. Dies stoppt und entlädt die Einheit, falls erforderlich, und entfernt sie dann aus " Flotte +":

fleetctl destroy hello.service

Wenn Sie eine Einheitendatei ändern, müssen Sie die aktuelle Einheit in "+ Flotte +" zerstören, bevor Sie sie senden / erneut starten.

Gerätestatus abrufen

Sie haben bereits einige Methoden zum Abrufen von Informationen zum Status von Einheiten kennengelernt.

Zum Beispiel haben wir behandelt, wie "+ liste-einheiten +" alle Einheiten auflistet, die derzeit auf einer Maschine geplant sind:

fleetctl list-units
UNIT        MACHINE             ACTIVE  SUB
hello.service   14ffe4c3.../10.132.249.212  active  running

Die + list-unit-files + liefert eine Liste von all units, von denen + fleet + weiß. Es gibt auch Auskunft über den gewünschten und aktuellen Zustand:

fleetctl list-unit-files
UNIT        HASH    DSTATE      STATE       TMACHINE
hello.service   0d1c468 launched    launched    14ffe4c3.../10.132.249.212

Für genauere Informationen zu einer Einheit, die gestartet wurde, gibt es einige andere Befehle. Der Befehl "+ status " gibt das Ergebnis " systemctl status +" für den Dienst auf dem Host zurück, auf dem die Einheit ausgeführt wird:

fleetctl status hello.service
● hello.service - My Service
  Loaded: loaded (/run/fleet/units/hello.service; linked-runtime)
  Active: active (running) since Mon 2014-09-08 21:51:22 UTC; 3min 57s ago
 Process: 7630 ExecStartPre=/usr/bin/docker pull busybox (code=exited, status=0/SUCCESS)
 Process: 7618 ExecStartPre=/usr/bin/docker rm hello (code=exited, status=0/SUCCESS)
 Process: 7609 ExecStartPre=/usr/bin/docker kill hello (code=exited, status=0/SUCCESS)
Main PID: 7638 (docker)
  CGroup: /system.slice/hello.service
          └─7638 /usr/bin/docker run --name hello busybox /bin/sh -c while true; do echo Hello World; sleep 1; done

Sep 08 21:55:11 coreos-3 docker[7638]: Hello World
Sep 08 21:55:12 coreos-3 docker[7638]: Hello World
Sep 08 21:55:13 coreos-3 docker[7638]: Hello World
Sep 08 21:55:14 coreos-3 docker[7638]: Hello World
Sep 08 21:55:15 coreos-3 docker[7638]: Hello World
Sep 08 21:55:16 coreos-3 docker[7638]: Hello World
Sep 08 21:55:17 coreos-3 docker[7638]: Hello World
Sep 08 21:55:18 coreos-3 docker[7638]: Hello World
Sep 08 21:55:19 coreos-3 docker[7638]: Hello World
Sep 08 21:55:20 coreos-3 docker[7638]: Hello World

Wie Sie sehen, können wir endlich überprüfen, ob die Leistung unserer Einheit produziert wird.

Wenn Sie auch den Journaleintrag für den Dienst anzeigen möchten, der auf dem zugeordneten Computer verfügbar ist, können Sie den Befehl + journal + verwenden:

fleetctl journal hello.service
-- Logs begin at Mon 2014-09-08 14:22:14 UTC, end at Mon 2014-09-08 21:55:47 UTC. --
Sep 08 21:55:38 coreos-3 docker[7638]: Hello World
Sep 08 21:55:39 coreos-3 docker[7638]: Hello World
Sep 08 21:55:40 coreos-3 docker[7638]: Hello World
Sep 08 21:55:41 coreos-3 docker[7638]: Hello World
Sep 08 21:55:42 coreos-3 docker[7638]: Hello World
Sep 08 21:55:43 coreos-3 docker[7638]: Hello World
Sep 08 21:55:44 coreos-3 docker[7638]: Hello World
Sep 08 21:55:45 coreos-3 docker[7638]: Hello World
Sep 08 21:55:46 coreos-3 docker[7638]: Hello World
Sep 08 21:55:47 coreos-3 docker[7638]: Hello World

Standardmäßig werden die letzten 10 Zeilen angezeigt. Sie können dies anpassen, indem Sie den Parameter "+ - lines +" wie folgt hinzufügen:

fleetctl journal --lines 20 hello.service

Sie können auch den Parameter "+ -f " verwenden, der für "follow" steht. Dies verhält sich ähnlich wie " tail -f +", da weiterhin die neuesten Protokolleinträge zurückgegeben werden:

fleetctl journal -f hello.service

Fazit

Indem Sie lernen, wie Sie + fleet + und + fleetctl + effektiv einsetzen, können Sie Ihren CoreOS-Cluster auf einfache Weise steuern. Ihre Services und Container können problemlos auf verschiedene Maschinen umgestellt werden.

In einem späteren Handbuch werden wir uns eingehender mit https://www.digitalocean.com/community/tutorials/how-to-create-flexible-services-for-a-coreos-cluster-with-fleet-unit befassen -files [wie man Flotteneinheitendateien erstellt]. Auf diese Weise können Sie flexible und leistungsstarke Dienste erstellen, die die CoreOS-Architektur nutzen.

Related