Willkommen zur Reise zum Aufbau eines hochverfügbaren verteilten Key-Value Stores. In diesem Projekt werden wir einen etcd-Cluster innerhalb von Podman-Containern auf AWS EC2-Instanzen aufbauen. etcd ist ein Open-Source, verteilter Key-Value Store, der für die sichere Verwaltung von Konfigurationsdaten in verteilten Systemen entwickelt wurde. Unter Verwendung des Raft-Konsensus-Protokolls gewährleistet es konsistente Daten über mehrere Maschinen hinweg. etcd ist eine der wichtigsten Komponenten für Konfigurationsmanagement und Leader-Wahl beim Aufbau zuverlässiger und hochverfügbarer Anwendungen.
Voraussetzungen
Wenn Sie Ansible und AWS CLI bereits installiert und konfiguriert haben, können Sie diese Schritte überspringen und direkt zum nächsten Abschnitt gehen.
Falls nicht, besuchen Sie bitte die Seite Bereitstellung von AWS-Ressourcen mit Ansible. Dort finden Sie die Schritte zur Installation und Konfiguration von Ansible und AWS CLI auf Ihrem lokalen Rechner.
Arbeiten mit Fedora CoreOS
Als Basis-Image verwenden wir Fedora CoreOS. Fedora CoreOS ist ein sich automatisch aktualisierendes, minimales, container-fokussiertes Betriebssystem. Ein großer Vorteil von Fedora CoreOS ist, dass es mit Docker und Podman vorinstalliert kommt. Es ist also perfekt für die Ausführung containerisierter Anwendungen wie unserem etcd-Dienst, den wir in einem Container ausführen werden. In Fedora CoreOS gibt es eine Datei namens Ignition-Datei, die als Benutzerdaten-Spezifikation unserer EC2-Instanzen angehängt werden kann. Diese Datei wird verwendet, um die Instanz während des Boot-Prozesses zu konfigurieren. Die Struktur der Datei ist jedoch etwas komplex. Daher empfiehlt Fedora die Verwendung von Butane zur Generierung der Ignition-Datei. Butane ist eine besser lesbare Version der Ignition-Datei von Fedora CoreOS. Die Struktur der Datei ist die gleiche wie bei einer YAML-Datei. Sie ist also leichter zu lesen und zu verstehen. Lassen Sie uns einen genaueren Blick darauf werfen, wie die Butane-Datei strukturiert ist und welche Art von Konfiguration wir damit vornehmen können.
Die User-Konfiguration
Wir können einen oder mehrere Benutzer unter passwd.users erstellen. In diesem Fall haben wir einen Benutzer namens etcd-user erstellt. Wir können auch den Public Key des Benutzers angeben. Der Public Key wird verwendet, um sich über SSH mit der Instanz zu verbinden. Der Benutzer ist keinen anderen Gruppen zugeordnet. Es handelt sich also um einen normalen (oder sollte ich sagen, rootlosen) Benutzer. Standardmäßig hat Fedora CoreOS uns einen Root-Benutzer namens core zur Verfügung gestellt. Wir werden jedoch den Root-Benutzer nicht für die Ausführung unseres etcd-Dienstes verwenden, um die Sicherheit des Systems zu erhöhen.
Die Speicherspezifikation
Wir können auch die Dateien angeben, die wir auf die Instanz kopieren möchten. In diesem Fall kopieren wir das etcd-Root-CA-Zertifikat und dessen Schlüssel, die Konfigurationsdatei für die etcd-Zertifikatsgenerierung, die Discovery-URL und das Skript zur Generierung des Client-Zertifikats auf die Instanz. Die Dateien werden in den angegebenen Pfad innerhalb der Instanz kopiert. Wir können auch die Dateiberechtigungen mit dem Attribut mode festlegen. Weitere Details zu den Shell-Skripten zur Generierung der Zertifikate finden Sie in unserem Github-Repository.
Die systemd-Unit
Der letzte Teil der Butane-Datei ist der systemd-Abschnitt. Hier können wir die systemd-Units angeben, die wir in der Instanz ausführen möchten. In diesem Fall führen wir den etcd-Service aus. Das Attribut name wird verwendet, um den Namen der systemd-Unit anzugeben. Das Attribut enabled gibt an, ob die Unit beim Booten aktiviert werden soll oder nicht. Das Attribut contents wird verwendet, um den Inhalt der systemd-Unit anzugeben. Das Attribut Requires dient dazu, die Units anzugeben, die vom etcd-Service benötigt werden. Das Attribut After wird verwendet, um die Units anzugeben, die vor dem etcd-Service gestartet werden sollen. Wir haben eine Unit namens setup-network-environment.service. Sie führt ein Skript zur Einrichtung der Netzwerkumgebung aus. Die setup-network-environment.service wurde von Kelsey Hightower bereitgestellt und der Quellcode ist hier zu finden. Was es tut, ist, dass es eine Datei namens network-environment erstellt, die die IP-Adresse der EC2-Instanz enthält, die für unseren etcd-Service verwendet wird. Nun lassen Sie uns einen genaueren Blick auf den etcd.service werfen.
Unter [Service] sehen wir, dass User auf etcd-user und EnvironmentFile auf /etc/network-environment gesetzt ist. Das bedeutet, dass der Service als etcd-user ausgeführt wird und die Umgebungsvariablen aus der Datei /etc/network-environment gelesen werden. Das ExecStartPre erstellt ein Verzeichnis namens etcd-data im Home-Verzeichnis des etcd-users. Dies ist das Verzeichnis, das in das /etcd-data-Verzeichnis innerhalb des Containers gemountet wird, wo die etcd-Daten gespeichert werden. Das ExecStart führt den etcd-Service innerhalb eines Podman-Containers aus.
Es gibt mehrere Flags, die in ExecStart verwendet werden, aber ich werde einige erwähnen, die interessant zu wissen sein könnten. Wir haben das Root-CA-Zertifikat, das Client-Zertifikat und dessen Schlüssel, die vom Shell-Skript generiert wurden, mit den Flags –trusted-ca-file, –cert-file und –key-file angegeben. Wir verwenden auch die gleichen Flags, aber mit dem Präfix –peer. Die Zertifikate werden verwendet, um sicherzustellen, dass die etcd-Nodes sicher miteinander und mit den Clients über HTTPS kommunizieren können. Beachten Sie, dass wir das Flag –initial-cluster nicht verwenden, da wir die Discovery-URL zum Bootstrapping des Clusters verwenden. Das Flag –discovery wird verwendet, um die Discovery-URL anzugeben. Es ist eine erstaunliche Funktion von etcd, die den Prozess des Bootstrappings eines neuen Clusters vereinfacht. Die etcd-Nodes können dem Cluster automatisch beitreten, indem sie die Discovery-URL verwenden. Daher müssen wir die IP-Adresse der anderen Nodes nicht im Voraus kennen. Das ExecStop entfernt den etcd-Container, nachdem der etcd-Service gestoppt wurde.
Kompilieren der Butane-Datei
Nachdem wir nun ein besseres Verständnis der Butane-Datei haben, lassen Sie uns die Datei erstellen. Wir erstellen eine Datei namens etcd-cluster.yaml und fügen den Inhalt der Butane-Datei hinein. Dann können wir die Butane-Datei mit dem folgenden Befehl in eine Ignition-Datei (.ign) kompilieren:
Die Ignition-Datei wird im selben Verzeichnis wie die Butane-Datei erstellt. Jetzt können wir die Ignition-Datei als Benutzerdaten-Spezifikation für unsere EC2-Instanzen verwenden.
Starten des etcd Service auf EC2-Instanzen
Sie können das Ansible Playbook aus dem vorherigen Blogpost verwenden, um die EC2-Instanzen bereitzustellen. Allerdings müssen wir einige Änderungen an der Create EC2 instances-Task vornehmen. Hier ist die aktualisierte Task:
Wir haben das Attribut user_data hinzugefügt und es auf die Ignition-Datei gesetzt. Es wird unsere Ignition-Datei nehmen und die von uns zuvor spezifizierte Konfiguration während des Boot-Prozesses ausführen. Jetzt können wir das Playbook ausführen, um die EC2-Instanzen bereitzustellen.
Überprüfen des etcd-Clusters
Lassen Sie die Maschine eine Weile laufen, bis sich der Status der Instanzen zu running ändert. Dann können wir uns mit folgendem Befehl per SSH in eine der Instanzen einloggen:
Da wir uns als Nicht-Root-Benutzer einloggen, können wir den sudo-Befehl nicht ausführen, um die Service-Unit zu überprüfen. Wir können jedoch verifizieren, dass der etcd-Service läuft, indem wir den Status des etcd-Containers oder die Logs des Containers überprüfen. Das können wir mit folgendem Befehl tun:
Die Ausgabe sollte in etwa so aussehen:
Nachdem wir verifiziert haben, dass der etcd-Service-Container läuft, können wir die Mitglieder des Clusters überprüfen, indem wir den folgenden Befehl ausführen:
Die Ausgabe sollte in etwa so aussehen:
Wir nehmen die Adressen in der Spalte CLIENT ADDRS und speichern sie in einer Variable namens ENDPOINTS. Das können wir mit folgendem Befehl tun:
Dann können wir den Status überprüfen und einen Health-Check des etcd-Clusters vornehmen, indem wir den folgenden Befehl ausführen:
Die Ausgabe sollte in etwa so aussehen:
Damit können wir sehen, dass der etcd-Cluster läuft und einsatzbereit ist.
Zusammenfassung
Herzlichen Glückwunsch zum erfolgreichen Aufbau eines hochverfügbaren etcd-Clusters auf AWS unter Verwendung von Ansible, Fedora CoreOS und Podman! Sie haben gelernt, wie man EC2-Instanzen mit benutzerdefinierten Ignition-Dateien erstellt und konfiguriert, etcd in Containern ausführt und die Zuverlässigkeit Ihres verteilten Key-Value Stores sicherstellt. Vielen Dank, dass Sie mich auf dieser Reise zum Aufbau eines hochverfügbaren etcd-Clusters auf AWS begleitet haben. Denken Sie daran, dass Lernen und Erkunden kontinuierliche Prozesse sind und sich die technologische Landschaft ständig weiterentwickelt. Bleiben Sie dran für weitere spannende Projekte!
Links
Farouq Abdurrahman ist Praktikant bei der Proventa AG und studiert Informatik. Sein Schwerpunkt liegt auf Cloud Computing. Er hat großes Interesse an der Digitalen Transformation und Cloud Computing. Aktuell beschäftigt er sich mit PostgreSQL Datenbanken in der Cloud.