So erstellen Sie einen Dienst und führen ihn auf einem CoreOS-Cluster aus

Einer der Hauptvorteile von CoreOS ist die Möglichkeit, Dienste über einen gesamten Cluster von einem einzigen Punkt aus zu verwalten. Die CoreOS-Plattform bietet integrierte Tools, um diesen Prozess zu vereinfachen.

In diesem Handbuch wird ein typischer Arbeitsablauf für die Ausführung von Diensten auf Ihren CoreOS-Clustern beschrieben. In diesem Prozess werden einige einfache und praktische Möglichkeiten für die Interaktion mit einigen der interessantesten CoreOS-Dienstprogramme zum Einrichten einer Anwendung gezeigt.

Um mit diesem Handbuch beginnen zu können, muss ein CoreOS-Cluster mit mindestens drei Computern konfiguriert sein. Sie können unserer guide to bootstrapping a CoreOS cluster hier folgen.

In diesem Handbuch werden die drei folgenden Knoten verwendet:

Diese drei Knoten sollten unter Verwendung ihrer privaten Netzwerkschnittstelle für ihre etcd-Client-Adresse und Peer-Adresse sowie für die Flottenadresse konfiguriert werden. Diese sollten mithilfe der Cloud-Konfigurationsdatei konfiguriert werden, wie in der obigen Anleitung gezeigt.

In diesem Handbuch werden wir den grundlegenden Arbeitsablauf für die Ausführung von Diensten in einem CoreOS-Cluster erläutern. Zu Demonstrationszwecken richten wir einen einfachen Apache-Webserver ein. Wir werden das Einrichten einer Container-Service-Umgebung mit Docker behandeln und dann eine Unit-Datei im Systemstil erstellen, um den Service und seine Betriebsparameter zu beschreiben.

In einer Companion-Unit-Datei teilen wir unserem Service mit, dass er sich bei etcd registrieren soll, damit andere Services seine Details nachverfolgen können. Wir werden unsere beiden Dienste an die Flotte übergeben, wo wir die Dienste auf Maschinen in unserem gesamten Cluster starten und verwalten können.

Das erste, was wir tun müssen, um mit der Konfiguration von Diensten zu beginnen, ist die Verbindung zu einem unserer Knoten mit SSH.

Damit das Tool + fleetctl + funktioniert, mit dem wir mit benachbarten Knoten kommunizieren, müssen wir beim Verbindungsaufbau unsere SSH-Agenteninformationen übergeben.

Bevor Sie eine Verbindung über SSH herstellen, müssen Sie Ihren SSH-Agenten starten. Auf diese Weise können Sie Ihre Anmeldeinformationen an den Server weiterleiten, zu dem Sie eine Verbindung herstellen, und sich von diesem Computer an anderen Knoten anmelden. Um den Benutzeragenten auf Ihrem Computer zu starten, geben Sie Folgendes ein:

Sie können dann Ihren privaten Schlüssel zum Speicher des Agenten hinzufügen, indem Sie Folgendes eingeben:

Zu diesem Zeitpunkt sollte Ihr SSH-Agent ausgeführt werden und über Ihren privaten SSH-Schlüssel informiert sein. Im nächsten Schritt stellen Sie eine Verbindung zu einem der Knoten in Ihrem Cluster her und leiten Ihre SSH-Agenteninformationen weiter. Sie können dies tun, indem Sie das + -A + Flag verwenden:

Sobald Sie mit einem Ihrer Knoten verbunden sind, können wir unseren Service ausbauen.

Als Erstes müssen wir einen Docker-Container erstellen, in dem unser Dienst ausgeführt wird. Sie können dies auf zwei Arten tun. Sie können einen Docker-Container starten und manuell konfigurieren oder eine Docker-Datei erstellen, die die zum Erstellen des gewünschten Images erforderlichen Schritte beschreibt.

In diesem Handbuch erstellen wir ein Image mit der ersten Methode, da dies für Docker-Neulinge einfacher ist. Folgen Sie diesem Link, wenn Sie weitere Informationen zum build a Docker image benötigen aus einem Dockerfile. Unser Ziel ist es, Apache auf einem Ubuntu 14.04-Basisimage in Docker zu installieren.

Bevor Sie beginnen, müssen Sie sich bei der Docker Hub-Registrierung anmelden oder anmelden. Geben Sie dazu Folgendes ein:

Sie werden aufgefordert, einen Benutzernamen, ein Passwort und eine E-Mail-Adresse anzugeben. Wenn Sie dies zum ersten Mal tun, wird ein Konto mit den von Ihnen angegebenen Daten erstellt und eine Bestätigungs-E-Mail an die angegebene Adresse gesendet. Wenn Sie in der Vergangenheit bereits ein Konto erstellt haben, werden Sie mit den angegebenen Anmeldeinformationen angemeldet.

Um das Image zu erstellen, müssen Sie zunächst einen Docker-Container mit dem Basisimage starten, das Sie verwenden möchten. Der Befehl, den wir brauchen werden, ist:

Die Argumente, die wir oben verwendet haben, sind:

Die Basis-Image-Ebenen werden aus der Docker Hub-Online-Docker-Registrierung abgerufen und eine Bash-Sitzung gestartet. Sie werden in die resultierende Shell-Sitzung versetzt.

Von hier aus können wir mit der Erstellung unserer Serviceumgebung fortfahren. Wir möchten den Apache-Webserver installieren, daher sollten wir unseren lokalen Paketindex aktualisieren und über "+ apt +" installieren:

Nach Abschluss der Installation können wir die Standarddatei + index.html + bearbeiten:

Wenn Sie fertig sind, können Sie Ihre Bash-Sitzung wie folgt beenden:

Zurück auf Ihrem Hostcomputer müssen wir die Container-ID des Docker-Containers abrufen, den wir gerade verlassen haben. Zu diesem Zweck können wir Docker bitten, die neuesten Prozessinformationen anzuzeigen:

Die Spalte, die wir brauchen, ist "CONTAINER ID". Im obigen Beispiel wäre dies "+ cb58a2ea1f8f +". Damit Sie später denselben Container mit allen vorgenommenen Änderungen in Betrieb nehmen können, müssen Sie die Änderungen in das Repository Ihres Benutzernamens übernehmen. Sie müssen auch einen Namen für das Bild auswählen.

Für unsere Zwecke geben wir vor, dass der Benutzername "+ Benutzername " ist. Sie sollten ihn jedoch durch den Namen des Docker Hub-Kontos ersetzen, mit dem Sie sich vor einiger Zeit angemeldet haben. Wir werden unser Bild " Apache" nennen. Der Befehl zum Festschreiben der Bildänderungen lautet:

Dadurch wird das Bild gespeichert, sodass Sie den aktuellen Status des Containers abrufen können. Sie können dies überprüfen, indem Sie Folgendes eingeben:

Als Nächstes sollten Sie das Image in Docker Hub veröffentlichen, damit Ihre Knoten das Image nach Belieben herunterladen und ausführen können. Verwenden Sie dazu das folgende Befehlsformat:

Sie haben jetzt ein Container-Image mit Ihrer Apache-Instanz konfiguriert.

Nachdem wir einen Docker-Container zur Verfügung haben, können wir mit der Erstellung unserer Servicedateien beginnen.

Fleet verwaltet die Serviceplanung für den gesamten CoreOS-Cluster. Es bietet dem Benutzer eine zentralisierte Benutzeroberfläche, während die systemd init-Systeme jedes Hosts lokal bearbeitet werden, um die entsprechenden Aktionen auszuführen.

Die Dateien, die die Eigenschaften der einzelnen Dienste definieren, sind geringfügig geänderte System-Unit-Dateien. Wenn Sie in der Vergangenheit mit systemd gearbeitet haben, sind Sie mit der Syntax bestens vertraut.

Erstellen Sie zunächst eine Datei mit dem Namen "+ apache @ .service " in Ihrem Home-Verzeichnis. Das " @ " zeigt an, dass es sich um eine Vorlagendienstdatei handelt. Wir werden gleich darüber sprechen, was das bedeutet. Das CoreOS-Image wird mit dem Texteditor ` vim +` geliefert:

Um die Service-Definition zu starten, erstellen wir einen Abschnittstitel "+ [Unit] +" und richten einige Metadaten zu dieser Unit ein. Wir werden eine Beschreibung einfügen und Abhängigkeitsinformationen angeben. Da unsere Einheit ausgeführt werden muss, nachdem sowohl etcd als auch Docker verfügbar sind, müssen wir diese Anforderung definieren.

Wir müssen auch die andere Servicedatei hinzufügen, die wir als Voraussetzung erstellen werden. Diese zweite Servicedatei ist für die Aktualisierung von etcd mit Informationen zu unserem Service verantwortlich. Wenn Sie es hier anfordern, wird es beim Starten dieses Dienstes zum Starten gezwungen. Wir werden das "+% i +" später im Servicenamen erklären:

Als Nächstes müssen wir dem System mitteilen, was beim Starten oder Stoppen dieses Geräts geschehen muss. Wir tun dies im Abschnitt "+ [Service] +", da wir einen Service konfigurieren.

Das erste, was wir tun möchten, ist das Deaktivieren des Zeitlimits für den Dienststart. Da es sich bei unseren Diensten um Docker-Container handelt, muss das Image beim ersten Start auf jedem Host von den Docker Hub-Servern heruntergeladen werden, was möglicherweise zu einer längeren Startzeit als gewöhnlich bei der ersten Ausführung führt.

Wir wollen den "+ KillMode +" auf "none" setzen, damit systemd unserem "stop" -Befehl erlaubt, den Docker-Prozess abzubrechen. Wenn wir dies weglassen, wird systemd denken, dass der Docker-Prozess fehlgeschlagen ist, wenn wir unseren Stop-Befehl aufrufen.

Wir werden auch sicherstellen wollen, dass unsere Umwelt sauber ist, bevor wir mit unserem Service beginnen. Dies ist besonders wichtig, da wir unsere Dienste nach Namen referenzieren und Docker nur die Ausführung eines einzelnen Containers mit jedem eindeutigen Namen zulässt.

Wir müssen alle übrig gebliebenen Container mit dem Namen töten, den wir verwenden möchten, und sie dann entfernen. An diesem Punkt ziehen wir auch das Image von Docker Hub herunter. Wir möchten auch die Datei "+ / etc / environment +" als Quelle verwenden. Dies umfasst Variablen wie die öffentlichen und privaten IP-Adressen des Hosts, auf dem der Dienst ausgeführt wird:

Die Syntax "+ = - " für die ersten beiden Zeilen " ExecStartPre +" zeigt an, dass diese Vorbereitungszeilen fehlschlagen können und die Unit-Datei weiterhin ausgeführt wird. Da diese Befehle nur erfolgreich sind, wenn ein Container mit diesem Namen vorhanden ist, schlagen sie fehl, wenn kein Container gefunden wird.

Möglicherweise haben Sie das Suffix "+% i +" am Ende der Apache-Containernamen in den obigen Anweisungen bemerkt. Die von uns erstellte Servicedatei ist eine template unit file. Dies bedeutet, dass die Flotte beim Ausführen der Datei einige Informationen automatisch durch die entsprechenden Werte ersetzt. Lesen Sie die Informationen unter dem angegebenen Link, um mehr zu erfahren.

In unserem Fall wird das "% i +" an einer beliebigen Stelle in der Datei durch den Teil des Namens der Servicedatei rechts vom " @ " vor dem " .service " - Suffix ersetzt. Unsere Datei heißt allerdings einfach " apache @ .service +".

Obwohl wir die Datei mit "+ apache @ .service " an " fleetctl " senden, laden wir sie beim Laden als " apache @ .service +", wobei "PORT_NUM" der gewünschte Port ist um diesen Server zu starten. Wir werden unseren Service basierend auf dem Port, auf dem er ausgeführt wird, kennzeichnen, damit wir sie leicht unterscheiden können.

Als nächstes müssen wir den eigentlichen Docker-Container starten:

Wir rufen den konventionellen Befehl + docker run + auf und übergeben ihm einige Parameter. Wir übergeben ihm den Namen in demselben Format, das wir oben verwendet haben. Wir werden auch einen Port von unserem Docker-Container für die öffentliche Schnittstelle unseres Host-Computers freigeben. Die Portnummer des Host-Rechners wird aus der Variablen "+% i +" entnommen, mit der wir den Port tatsächlich angeben können.

Wir verwenden die Variable "+ COREOS_PUBLIC_IPV4 +" (aus der von uns bereitgestellten Umgebungsdatei), um die Host-Schnittstelle, an die wir binden möchten, explizit anzugeben. Wir könnten dies weglassen, aber es ermöglicht uns später eine einfache Änderung, wenn wir dies in eine private Schnittstelle ändern möchten (wenn wir zum Beispiel einen Lastenausgleich durchführen).

Wir verweisen auf den Docker-Container, den wir zuvor in Docker Hub hochgeladen haben. Schließlich rufen wir den Befehl auf, der unseren Apache-Dienst in der Container-Umgebung startet. Da Docker-Container heruntergefahren werden, sobald der ihnen erteilte Befehl beendet wird, möchten wir unseren Dienst im Vordergrund anstatt als Daemon ausführen. Dadurch kann unser Container weiter ausgeführt werden, anstatt zu beenden, sobald ein untergeordneter Prozess erfolgreich gestartet wurde.

Als Nächstes müssen wir den Befehl angeben, der aufgerufen werden soll, wenn der Dienst beendet werden muss. Wir werden einfach den Container stoppen. Die Container-Bereinigung wird bei jedem Neustart durchgeführt.

Wir möchten auch einen Abschnitt mit dem Namen "+ [X-Fleet] +" hinzufügen. Dieser Abschnitt wurde speziell entwickelt, um der Flotte Anweisungen zum Planen des Service zu geben. Hier können Sie Einschränkungen hinzufügen, damit Ihr Dienst in bestimmten Vereinbarungen in Bezug auf andere Dienste oder Maschinenzustände ausgeführt werden muss oder nicht.

Wir möchten, dass unser Service nur auf Hosts ausgeführt wird, auf denen noch kein Apache-Webserver ausgeführt wird, da dies eine einfache Möglichkeit darstellt, hochverfügbare Services zu erstellen. Wir werden einen Platzhalter verwenden, um alle Apache-Service-Dateien abzufangen, die wir ausgeführt haben könnten:

Damit sind wir mit unserer Apache Server Unit-Datei fertig. Wir werden jetzt eine Begleitservice-Datei erstellen, um den Service bei etcd zu registrieren.

Um den aktuellen Status der auf dem Cluster gestarteten Dienste aufzuzeichnen, möchten wir einige Einträge in etcd schreiben. Dies wird als Registrieren bei etcd bezeichnet.

Zu diesem Zweck starten wir einen minimalen Companion-Service, der etcd aktualisieren kann, um festzustellen, wann der Server für den Datenverkehr verfügbar ist.

Die neue Service-Datei heißt "+ apache-discovery @ .service +". Öffne es jetzt:

Wir beginnen mit dem Abschnitt "+ [Unit] ", genau wie zuvor. Wir werden den Zweck des Dienstes beschreiben und dann eine Direktive namens " BindsTo +" erstellen.

Die Direktive "+ BindsTo +" identifiziert eine Abhängigkeit, nach der dieser Dienst nach Statusinformationen sucht. Wenn der aufgelistete Dienst gestoppt wird, stoppt auch die Einheit, die wir gerade schreiben. Wir werden dies verwenden, damit bei einem unerwarteten Ausfall unserer Web-Server-Einheit dieser Service etcd aktualisiert, um diese Informationen wiederzugeben. Dies behebt das potenzielle Problem, dass veraltete Informationen in etcd vorhanden sind, die fälschlicherweise von anderen Diensten verwendet werden könnten:

Für den Abschnitt "+ [Service] +" möchten wir die Umgebungsdatei erneut mit den IP-Adressinformationen des Hosts versehen.

Für den eigentlichen Startbefehl wollen wir eine einfache Endlosschleife ausführen. Innerhalb der Schleife verwenden wir den Befehl "+ etcdctl ", der zum Ändern von etcd-Werten verwendet wird, um einen Schlüssel im etcd-Speicher unter " / announce / services / apache% i " festzulegen. Das "% i " wird durch den Abschnitt des Dienstnamens ersetzt, den wir zwischen dem " @ " und dem " .service +" - Suffix laden. Dies ist wiederum die Portnummer des Apache-Dienstes.

Der Wert dieses Schlüssels wird auf die öffentliche IP-Adresse des Knotens und die Portnummer festgelegt. Wir werden auch eine Ablaufzeit von 60 Sekunden für den Wert festlegen, damit der Schlüssel entfernt wird, wenn der Dienst irgendwie ausfällt. Wir werden dann 45 Sekunden schlafen. Dies führt zu einer Überlappung mit dem Ablaufdatum, sodass der TTL-Wert (Time-to-Live) immer aktualisiert wird, bevor das Timeout erreicht wird.

Zum Beenden entfernen wir einfach den Schlüssel mit demselben Dienstprogramm "+ etcdctl +" und markieren den Dienst als nicht verfügbar:

Als letztes müssen wir eine Bedingung hinzufügen, um sicherzustellen, dass dieser Dienst auf demselben Host wie der Webserver gestartet wird, auf dem er berichtet. Dadurch wird sichergestellt, dass sich die etcd-Informationen bei einem Ausfall des Hosts entsprechend ändern:

Sie haben jetzt Ihren Sidekick-Service, der den aktuellen Status Ihres Apache-Servers in etcd aufzeichnet.

Sie haben jetzt zwei Dienstvorlagen. Wir können diese direkt in + fleetctl + einreichen, damit unser Cluster über sie Bescheid weiß:

Sie sollten in der Lage sein, Ihre neuen Servicedateien anzuzeigen, indem Sie Folgendes eingeben:

Die Vorlagen sind jetzt in unserem clusterweiten Init-System vorhanden.

Da wir Vorlagen verwenden, die von der Planung auf bestimmten Hosts abhängen, müssen wir die Dateien als Nächstes laden. Auf diese Weise können wir den neuen Namen für diese Dateien mit der Portnummer angeben. Dies ist, wenn + fleetctl + den Abschnitt + [X-Fleet] + ansieht, um die Planungsanforderungen zu ermitteln.

Da wir keinen Lastenausgleich durchführen, wird unser Webserver nur auf Port 80 ausgeführt. Wir können jeden Service laden, indem wir das zwischen dem + @ + und dem + .service + Suffix angeben:

Sie sollten Informationen darüber erhalten, auf welchem ​​Host in Ihrem Cluster der Dienst geladen wird:

Wie Sie sehen, wurden diese Dienste beide auf demselben Computer geladen, wie wir es angegeben haben. Da unsere Service-Datei "+ apache-discovery" an unseren Apache-Service gebunden ist, können wir einfach den Brief starten, um unsere beiden Services einzuleiten:

Wenn Sie nun fragen, welche Einheiten in unserem Cluster ausgeführt werden, sollten wir Folgendes sehen:

Es scheint, dass unser Webserver in Betrieb ist. In unserer Servicedatei haben wir Docker angewiesen, sich an die öffentliche IP-Adresse des Hostservers zu binden, aber die mit + fleetctl + angezeigte IP-Adresse ist die private Adresse (da wir bei der Erstellung dieses Beispiels in der Cloud-Konfiguration + $ private_ipv4 + übergeben haben) Cluster).

Wir haben jedoch die öffentliche IP-Adresse und die Portnummer bei etcd registriert. Um den Wert zu erhalten, können Sie das Dienstprogramm + etcdctl + verwenden, um die von uns festgelegten Werte abzufragen. Wenn Sie sich erinnern, lauteten die von uns festgelegten Schlüssel "+ / announced / services / apache". Geben Sie zum Abrufen der Serverdetails Folgendes ein:

Wenn wir diese Seite in unserem Webbrowser besuchen, sollten wir die sehr einfache Seite sehen, die wir erstellt haben:

image: https://assets.digitalocean.com/articles/coreos_basic/web_page.png [CoreOS-Basiswebseite]

Unser Service wurde erfolgreich implementiert. Versuchen wir, eine andere Instanz über einen anderen Port zu laden. Es ist zu erwarten, dass der Webserver und der zugehörige Sidekick-Container auf demselben Host geplant werden. Aufgrund unserer Einschränkung in unserer Apache-Servicedatei sollten wir jedoch davon ausgehen, dass sich dieser Host von dem Host, der unseren Port 80-Service bedient, unterscheidet.

Laden Sie einen Dienst auf, der auf Port 9999 ausgeführt wird:

Wir können sehen, dass beide neuen Services auf demselben neuen Host geplant wurden. Starten Sie den Webserver:

Jetzt können wir die öffentliche IP-Adresse dieses neuen Hosts abrufen:

Wenn wir die angegebene Adresse und Portnummer besuchen, sollten wir einen anderen Webserver sehen:

image: https://assets.digitalocean.com/articles/coreos_basic/web_page.png [CoreOS-Basiswebseite]

Wir haben jetzt zwei Webserver in unserem Cluster bereitgestellt.

Wenn Sie einen Webserver anhalten, sollte auch der Sidekick-Container anhalten:

Sie können auch überprüfen, ob der etcd-Schlüssel entfernt wurde:

Dies scheint genau wie erwartet zu funktionieren.

Wenn Sie diesem Handbuch folgen, sollten Sie mit einigen der gebräuchlichen Vorgehensweisen bei der Arbeit mit den CoreOS-Komponenten vertraut sein.

Wir haben unseren eigenen Docker-Container mit dem Dienst erstellt, den wir ausführen wollten, und wir haben eine Flotten-Unit-Datei erstellt, um CoreOS mitzuteilen, wie unser Container verwaltet werden soll. Wir haben einen Sidekick-Service implementiert, um unseren etcd-Datenspeicher mit Statusinformationen zu unserem Webserver auf dem neuesten Stand zu halten. Wir haben unsere Services mit fleetctl verwaltet und Services auf verschiedenen Hosts geplant.

In späteren Handbüchern werden wir weiterhin einige der Bereiche untersuchen, die wir in diesem Artikel kurz angesprochen haben.