SaltStack-Infrastruktur: Erstellen von Salt-Status für HAProxy Load Balancer

SaltStack oder Salt ist ein leistungsstarkes Remote-Ausführungs- und Konfigurationsverwaltungssystem, mit dem die Infrastruktur auf einfache Weise strukturiert und wiederholbar verwaltet werden kann. In dieser Serie werden wir eine Methode zum Verwalten Ihrer Entwicklungs-, Staging- und Produktionsumgebungen anhand einer Salt-Bereitstellung demonstrieren. Wir werden das Salt-Status-System verwenden, um wiederholbare Aktionen zu schreiben und anzuwenden. Auf diese Weise können wir jede unserer Umgebungen zerstören, in der Gewissheit, dass wir sie zu einem späteren Zeitpunkt problemlos in identischem Zustand wieder online stellen können.

In unserem previous guide haben wir einen Salt-Status für unsere Webserver erstellt, die und installiert haben Nginx konfiguriert. In diesem Handbuch werden Zustände für den Load Balancer konfiguriert, der in unseren Staging- und Produktionsumgebungen vor unseren Webservern installiert wird. Unsere Load Balancer müssen mit den Webserveradressen konfiguriert werden, um den Datenverkehr korrekt weiterzuleiten.

Lass uns anfangen.

Unsere Load Balancer verwenden HAProxy, um den Datenverkehr für unsere Anwendung auf alle verfügbaren Webserver in der Umgebung zu verteilen. Wie bei der Nginx-Statusdatei erstellen wir ein Verzeichnis für diesen Status im Verzeichnis "+ / srv / salt +":

Wir werden den Namen "+ init.sls +" für unsere Hauptzustandsdatei innerhalb dieses Verzeichnisses verwenden, damit wir durch den Verzeichnisnamen auf den Zustand verweisen können:

Im Inneren können wir dasselbe Muster verwenden, das wir für Nginx verwendet haben, um das Paket "+ haproxy " zu installieren und sicherzustellen, dass es ausgeführt wird. Wir werden sicherstellen, dass der Dienst neu geladen wird, wenn Änderungen am Paket oder an der Datei " / etc / default / haproxy " oder der Datei " / etc / haproxy / haproxy.cfg +" vorgenommen werden. Seien Sie auch hier sehr vorsichtig mit dem Abstand, um YAML-Fehler zu vermeiden:

/srv/salt/haproxy/init.sls

Wir müssen beide Dateien verwalten, die der Dienst + haproxy + überwacht. Wir können Zustände für jeden erstellen.

Die Datei + / etc / haproxy / haproxy.cfg + ist eine Vorlage. Diese Datei muss Informationen über die Umgebung abrufen, um die Liste der Webserver aufzufüllen, an die der Datenverkehr weitergeleitet werden soll. Unsere Webserver haben nicht bei jeder Erstellung die gleichen IP-Adressen. Wir müssen die Liste jedes Mal dynamisch erstellen, wenn dieser Status angewendet wird.

Die + / etc / default / haproxy + Datei ist nur eine reguläre Datei. Wir verwalten es, weil wir sicherstellen möchten, dass HAProxy beim Booten gestartet wird. Dies sind jedoch keine dynamischen Informationen, sodass wir keine Vorlage erstellen müssen:

/srv/salt/haproxy/init.sls

Dies ist eigentlich alles, was wir für die Statusdatei selbst benötigen. Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Wir verwenden die gleiche Technik wie bei Nginx, um die grundlegenden HAProxy-Dateien zu erhalten, die wir benötigen. Wir werden das Paket auf einem Minion installieren und dann den Server anweisen, die Dateien wieder auf den Master zu übertragen.

Verwenden wir den "+ stage-lb +" - Server, da dies sowieso das endgültige Ziel für dieses Paket ist. Wenn Ihre Staging-Computer noch nicht in Betrieb sind, geben Sie Folgendes ein:

Sobald Ihre Server verfügbar sind, können Sie das "+ haproxy " - Paket auf dem " stage-lb +" - Server installieren, indem Sie Folgendes eingeben:

Sobald die Installation abgeschlossen ist, können wir den Minion anweisen, die beiden benötigten Dateien auf den Master-Server zu übertragen:

Die relevanten Teile des Minion-Dateisystems werden im Verzeichnis + / var / cache / salt / master / minions // files + neu erstellt. In diesem Fall lautet die Minion-ID "+ stage-lb +". Kopieren Sie die gesamte Minion-Dateistruktur in unser HAProxy-Statusverzeichnis:

Wir können die Dateistruktur sehen, indem wir Folgendes eingeben:

Nachdem wir die Dateien vom Minion haben, können wir den Load Balancing Server zerstören:

Anschließend können wir den Server im Hintergrund neu erstellen, sodass wir später einen sauberen Plan haben, um unsere endgültigen Tests und Bestätigungen durchzuführen. Verwenden Sie diesen Befehl, um auf Ihren Salt-Masterserver zuzugreifen, da dieser Zugriff auf die relevanten Cloud-Dateien hat:

Während der Wiederherstellung des Servers können wir fortfahren und die erforderlichen Änderungen an den von uns verwalteten HAProxy-Dateien vornehmen.

Wir können mit der Datei + / etc / default / haproxy + beginnen. Wechseln Sie in unserem HAProxy-Statusverzeichnis auf dem Salt-Master in das Verzeichnis, in dem sich die Standarddatei befindet:

Kopieren Sie die Datei nach + haproxy.orig +, damit wir die Datei so erhalten können, wie sie ursprünglich gepackt war:

Öffnen Sie nun die Datei zum Bearbeiten:

Ändern Sie "+ AKTIVIERT +" in "1". Dadurch wird Ubuntus Init-System Upstart angewiesen, den HAProxy-Dienst zu starten, wenn der Server startet:

/ srv / salt / haproxy / files / etc / default / haproxy

Dies ist die einzige Änderung, die wir vornehmen müssen. Speichern und schließen Sie die Datei.

Als nächstes arbeiten wir an der HAProxy-Hauptkonfigurationsdatei. Wechseln Sie in das entsprechende Verzeichnis auf dem Salt-Masterserver:

Kopieren Sie die Konfiguration erneut, um den ursprünglichen Status zu speichern:

Benennen Sie die Datei dann um, um anzuzeigen, dass es sich um eine Jinja-Vorlagendatei handelt:

Öffnen Sie die Vorlagendatei in Ihrem Texteditor:

Am Anfang der Datei können wir eine Jinja-Variable setzen. Wir müssen die Umgebung, in der der Load Balancer arbeitet, mit der Ausführungsfunktion + network.interface_ip + erfassen. Wir werden dies später verwenden, um die Serverliste mit den Webservern aus derselben Umgebung zu füllen:

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

Fahren Sie mit dem Abschnitt "Standardeinstellungen" der Datei fort. Wir müssen den "" Modus auf "tcp" und die erste "" Option auf "tcplog" ändern:

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

Am Ende der Datei müssen wir unsere aktuelle Konfiguration erstellen. Wir müssen einen Abschnitt "Frontend" erstellen, in dem beschrieben wird, wie HAProxy Verbindungen akzeptiert. Wir werden diesen Abschnitt als "www" bezeichnen.

Wir möchten dies an die öffentliche IP-Adresse des Servers binden. Wir können dies mit der Ausführungsmodulfunktion + network.interface_ip + mit dem Argument + eth0 + erfassen. Webanfragen werden an Port 80 eingehen. Das zu übergebende Standard-Backend können wir mit der Option + default_backend + festlegen. Wir werden unser Backend + nginx_pool + aufrufen:

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

Als nächstes müssen wir das + nginx_pool + Backend hinzufügen. Wir werden das herkömmliche Round-Robin-Balancing-Modell verwenden und den Modus wieder auf "tcp" setzen.

Danach müssen wir die Liste der Back-End-Webserver aus unserer Umgebung füllen. Wir können dies mit einer for-Schleife in Jinja tun. Wir können die Ausführungsmodulfunktion + mine.get + verwenden, um den Wert der Funktion + internal_ip + mine abzurufen. Wir werden die Webserverrolle und die Umgebung anpassen. Das + ~ env + verkettet den Wert der + env + Variablen, die wir zuvor auf die vorhergehende Übereinstimmungszeichenfolge gesetzt haben.

Die Ergebnisse dieser Suche werden in den Variablen "+ server " und " addr +" für jede Iteration der Schleife gespeichert. Innerhalb der Schleife werden die Serverdetails mithilfe dieser Schleifenvariablen hinzugefügt. Das Endergebnis sieht so aus:

/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Unser Lastausgleichsstatus ist ziemlich einfach, aber vollständig. Jetzt können wir mit dem Testen fortfahren.

Verwenden Sie zunächst "+ state.show_sls +", um die Reihenfolge der Dateien anzuzeigen:

Anhand der Reihenfolge in den verschiedenen "Reihenfolge" -Werten in der Ausgabe können wir erkennen, dass das Paket installiert wird, der Dienst gestartet wird und dann die beiden Dateien angewendet werden. Das haben wir erwartet. Die Dateiänderungen lösen aufgrund der von uns konfigurierten Einstellung "watch" ein erneutes Laden des Dienstes aus.

Als Nächstes können wir die Statusanwendung trocken ausführen. Dadurch werden einige (aber nicht alle) Fehler abgefangen, die dazu führen, dass der Status beim Ausführen fehlschlägt:

Überprüfen Sie, ob alle Zustände bestanden hätten. Scrollen Sie nach oben, unabhängig von der Fehleranzahl unten oder der Ausgabe, und sehen Sie sich die Kommentarzeile für jeden Status an. Manchmal enthält dies zusätzliche Informationen zu potenziellen Problemen, obwohl der Test als erfolgreich markiert wurde.

Nachdem Sie alle Probleme behoben haben, die während der Testbefehle aufgetreten sind, können Sie Ihren Status auf Ihre Load Balancer-Server anwenden. Stellen Sie sicher, dass die Back-End-Nginx-Webserver aktiv und konfiguriert sind, bevor Sie den Status anwenden:

Wenn Ihre Webserver ausgeführt werden, wenden Sie den Status "+ haproxy +" an:

Sie sollten nun in der Lage sein, über die öffentliche IP-Adresse Ihres Load Balancers auf einen Ihrer beiden Backend-Webserver zuzugreifen. Mit diesem Befehl können Sie die öffentliche IP-Adresse Ihres Load Balancers anzeigen:

Wenn Sie den Browser verwenden, sieht er ungefähr so ​​aus:

image: https://assets.digitalocean.com/articles/saltstack_haproxy/example_page.png [Seite zum Lastenausgleich]

Es ist einfacher zu sehen, wie der Load Balancer mit + curl + den Datenverkehr zwischen den Backend-Servern weiterleitet:

Wenn Sie den Befehl einige Male erneut eingeben, sollte er zwischen Ihren beiden Servern wechseln:

Wie Sie sehen, hat sich der Server, der die Anfrage bearbeitet, geändert, was bedeutet, dass unser Load Balancer ordnungsgemäß funktioniert.

Zu diesem Zeitpunkt verfügen wir über einen funktionierenden HAProxy-Status, der auf unsere Load Balancer-Maschinen angewendet werden kann. Dies kann verwendet werden, um den eingehenden Datenverkehr für unsere Anwendung auf alle Back-End-Nginx-Server aufzuteilen. Wir können unsere Load Balancer leicht zerstören und sie dann basierend auf den verfügbaren Webservern neu erstellen.

In der next guide werden wir uns darauf konzentrieren, MySQL als Backend zum Laufen zu bringen Datenbanksystem. Auf diese Weise werden Anwendungsdaten in unseren verschiedenen Umgebungen gespeichert.