TOC

SaltStack-Infrastruktur: Salt-Status für Nginx-Webserver erstellen

Einführung

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 die Fähigkeiten unseres Salt-Masterservers durch das Einrichten erweitert der DigitalOcean-Anbieter für "+ salt-cloud +". Wir haben die Dateien erstellt, die es uns ermöglichen, neue Server für jede unserer Umgebungen hochzufahren. In diesem Artikel werden wir mit der Konfigurationsverwaltung beginnen, indem wir Salt-Statusdateien für Nginx erstellen. Nginx wird auf unseren Webserverknoten in allen drei Umgebungen verwendet, um Webanforderungen zu bearbeiten.

Erstellen Sie die Haupt-Nginx-Statusdatei

Salt übernimmt das Konfigurationsmanagement über sein Statussystem. Im einfachsten Fall werden diese von Dateien gesteuert, die sich im Dateiserver-Stammverzeichnis von Salt befinden (das wir als "+ / srv / salt +" konfiguriert haben). Um unsere Nginx-Konfiguration zu starten, erstellen wir an dieser Stelle ein Verzeichnis, das für die Software, die wir konfigurieren, spezifisch ist:

sudo mkdir /srv/salt/nginx

Statusdateien haben das Suffix "+ .sls ". Eine " init.sls " - Datei in einem Verzeichnis fungiert als Hauptkonfigurationsdatei für diesen bestimmten Salt-Status oder diese bestimmte Formel. Wir verweisen auf den Namen des übergeordneten Verzeichnisses, um die in der zugehörigen Datei " init.sls +" enthaltene Funktionalität auszuführen.

In diesem Sinne erstellen und öffnen Sie zunächst eine + init.sls + - Datei in diesem Verzeichnis:

sudo nano /srv/salt/nginx/init.sls

Die Nginx-Paket- und Servicestatus

Zunächst erstellen wir einen Status mit dem Bezeichner "+ nginx ". Dies wird als eindeutiger Name für diesen bestimmten Zustand innerhalb des Salzzustandssystems dienen. Da wir das Attribut "name" für unsere Statusmodule nicht einschließen, dient es auch als Ziel für die Installation (für die Funktion " pkg.installed ") und den ausgeführten Dienst (für den Dienst "") .running + `Funktion).

Wir möchten, dass Nginx unter bestimmten Bedingungen automatisch neu geladen wird: wenn das Paket aktualisiert wird, wenn die Hauptkonfigurationsdatei geändert wurde oder wenn die Standard-Serverblockdatei geändert wird. Wir können Salt anweisen, den Nginx-Dienst neu zu starten, wenn folgende Bedingungen auftreten:

/srv/salt/nginx/init.sls

nginx:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: nginx
     - file: /etc/nginx/nginx.conf
     - file: /etc/nginx/sites-available/default

Die Tasten "+ pkg: " und " file: " unter der Taste " watch: " stehen für die Zustandsmodule, die den zu überwachenden Ressourcen zugeordnet sind. Die Ressource " pkg " wird im ersten Teil derselben Definition behandelt. Als nächstes müssen wir die Zustände erstellen, die mit den ' file'-Ressourcen übereinstimmen.

Der Status der Nginx-Konfigurationsdatei

Wir können mit der Datei + / etc / nginx / nginx.conf + beginnen. Wir möchten dies zu einer verwalteten Datei machen. In der Salt-Terminologie bedeutet dies nur, dass wir den Inhalt der Datei auf dem Master-Server definieren und ihn zu jedem Diener hochladen, der ihn benötigt. Wir werden eher typische Berechtigungen und Eigentumsrechte für die Datei festlegen. Die Quelle verweist auf einen Speicherort auf dem Salt-Dateiserver (unsere aktuelle Datei befindet sich ebenfalls in dieser Struktur). Wir werden diesen Pfad und diese Datei in Kürze erstellen:

/srv/salt/nginx/init.sls

nginx:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: nginx
     - file: /etc/nginx/nginx.conf
     - file: /etc/nginx/sites-available/default

Wir möchten auch den Inhalt der Datei + / etc / nginx / sites-available / default + kontrollieren. Dies definiert den Serverblock, der steuert, wie unsere Inhalte bereitgestellt werden. Der Zustandsblock ist dem letzten ziemlich ähnlich. Der Hauptunterschied besteht darin, dass diese Datei eine Jinja-Vorlage ist.

Mithilfe von Jinja-Vorlagen kann Salt einige Inhalte der Datei mit spezifischen Informationen zu den Minions anpassen, in denen sie abgelegt werden. Dies bedeutet, dass wir Informationen von jedem Host abrufen und eine geeignete, angepasste Version der Datei für jeden unserer Webserver erstellen können. Wir weisen darauf hin, dass diese Datei Jinja mit der Option + template + verwendet. Wir werden auch das Suffix "+ .jinja +" in der Quelldatei verwenden, damit wir auf einen Blick erkennen können, dass die Datei eine Vorlage ist:

/srv/salt/nginx/init.sls

. . .

/etc/nginx/nginx.conf:
 file.managed:
   - source: salt://nginx/files/etc/nginx/nginx.conf
   - user: root
   - group: root
   - mode: 640

Wir haben unsere Standard-Server-Blockdatei geplant, um sie in das Verzeichnis "+ sites-available " auf den Minion-Hosts zu stellen. Wir müssen die Datei jedoch noch mit dem Verzeichnis " sites-enabled " verknüpfen, um sie zu aktivieren. Wir können das mit der Funktion ` file.symlink ` machen. Wir müssen nur den ursprünglichen Dateispeicherort als " Ziel" angeben. Wir müssen diese Datei auch "anfordern", damit dieser Status erst ausgeführt wird, nachdem der vorherige Status erfolgreich abgeschlossen wurde:

/srv/salt/nginx/init.sls

. . .

/etc/nginx/sites-available/default:
 file.managed:
   - source: salt://nginx/files/etc/nginx/sites-available/default.jinja
   - template: jinja
   - user: root
   - group: root
   - mode: 640

Der Status für unseren Standard-Site-Inhalt

Wir haben unseren Nginx Installations- und Konfigurationsstatus geschrieben. Jetzt müssen wir nur noch einen Status für unsere Datei "+ index.html" erstellen, der den eigentlichen Inhalt für unsere Site darstellt.

Dieser Status verwendet genau dasselbe Format wie unser vorheriger Vorlagenstatus. Die einzigen Unterschiede sind der Bezeichner, die Quelle und der Berechtigungsmodus für diese Datei:

/srv/salt/nginx/init.sls

. . .

/etc/nginx/sites-enabled/default:
 file.symlink:
   - target: /etc/nginx/sites-available/default
   - require:
     - file: /etc/nginx/sites-available/default

Wenn Sie fertig sind, speichern und schließen Sie diese Datei. Momentan sind wir mit den aktuellen Nginx-Statusinformationen fertig.

Installieren Sie Nginx und übertragen Sie die Originaldateien auf den Salt Master

Wir haben unsere Haupt-Nginx Salt-Statusdatei erstellt. Einige der von uns erstellten Statusangaben beziehen sich jedoch auf den Dateiserver des Salt Masters, die noch nicht vorhanden sind.

Da unsere Dateien weitgehend mit den Standarddateien übereinstimmen, die mit dem Nginx-Paket von Ubuntu installiert wurden, ist es für uns am einfachsten, mit den Dateien dieses Pakets zu beginnen. Die Webserver einer unserer Umgebungen bieten den perfekten Ort für die Installation von Nginx, damit wir die erforderlichen Dateien abrufen können.

Wenn Sie noch keine Ihrer Umgebungen hochgefahren haben, wählen Sie eine Ihrer Umgebungszuordnungsdateien aus, die Sie bereitstellen möchten. Wir werden die Stage-Umgebung in dieser Serie verwenden, da es sich um die kleinste Umgebung handelt, in der alle Servertypen vorhanden sind, die wir benötigen.

sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map

Sobald Ihre Server in Betrieb sind, wählen Sie einen Ihrer Webserver aus, auf dem Nginx installiert werden soll. Wir werden zum jetzigen Zeitpunkt nur das Ausführungsmodul "+ pkg +" verwenden, da unsere Status noch nicht voll funktionsfähig sind:

sudo salt stage-www1 pkg.install nginx

Bei der Einrichtung unserer Salt Master-Konfiguration haben wir die Option "+ file_recv +" aktiviert. Auf diese Weise können wir Minions auffordern, bestimmte Dateien wieder an den Master zu senden. Wir können dies verwenden, um die Standardversionen der Dateien abzurufen, die wir verwalten werden:

sudo salt stage-www1 cp.push /etc/nginx/nginx.conf
sudo salt stage-www1 cp.push /etc/nginx/sites-available/default
sudo salt stage-www1 cp.push /usr/share/nginx/html/index.html

Diese Dateien sollten nun auf dem Master verfügbar sein. Der Pfad zu diesen Dateien wird im Verzeichnis + / var / cache / salt / master / minion // files in erstellt. In unserem Fall wäre die Diener-ID "+ stage-www1 +". Wir können die Verzeichnisse unter diesem Speicherort, der die Dateipfade auf dem Minion darstellt, in unser Salt-Statusverzeichnis kopieren, indem wir Folgendes eingeben:

sudo cp -r /var/cache/salt/master/minions/stage-www1/files /srv/salt/nginx

Wenn Sie sich den Inhalt Ihres Statusverzeichnisses ansehen, sehen Sie ein neues Verzeichnis mit dem Namen "files". Unterhalb dieses Verzeichnisses befinden sich die relevanten Verzeichnisse im Dateisystem des Minions und die drei Dateien, die wir kopiert haben:

find /srv/salt/nginx -printf "%P\n"
Outputfiles
files/usr
files/usr/share
files/usr/share/nginx
files/usr/share/nginx/html
files/usr/share/nginx/html/index.html
files/etc
files/etc/nginx
files/etc/nginx/sites-available
files/etc/nginx/sites-available/default
files/etc/nginx/nginx.conf
init.sls

Dies ist, wo alle unsere verwalteten Dateien beibehalten werden. Dies richtet sich nach dem Quellspeicherort, den wir in unserer Nginx-Statusdatei festgelegt haben.

Da wir jetzt alle Dateien haben, die wir vom Minion ziehen müssen, auf dem Nginx installiert war, können wir den Minion zerstören und neu erstellen. Dadurch wird sichergestellt, dass unsere Statusdateien später auf einem sauberen Server getestet werden können. Zerstöre den Nginx-Diener:

sudo salt-cloud -d stage-www1

Nachdem wir auf den Ablauf des Ereignisses gewartet haben, können wir den Minion wieder aufbauen.

In der Regel verwenden wir hierfür die Kartendatei. Da wir jedoch nur einen einzelnen Server neu erstellen, ist es eigentlich vorzuziehen, das "+ stage-web " - Profil direkt zu verwenden. Wir können dann die Salt-Ausführungsfunktion " cloud.profile " anstelle von " salt-cloud " verwenden, wodurch wir das " - async " -Flag hinzufügen können. Grundsätzlich können wir so unseren " stage-www1 +" - Server im Hintergrund neu erstellen, während wir weiterarbeiten. In diesem Befehl müssen wir unseren Salt-Master als Ziel angeben, da dies der Server mit den Cloud-Profilen ist, die wir benötigen:

sudo salt --async  cloud.profile stage-web stage-www1

Während unser + stage-www1 + - Knoten im Hintergrund wiederhergestellt wird, können wir fortfahren.

Konfigurieren Sie die Datei /etc/nginx/nginx.conf

Schauen wir uns zuerst die Hauptkonfigurationsdatei von Nginx an, die auf unseren Minions unter "+ / etc / nginx / nginx.conf " abgelegt wird. Diesen Pfad finden wir im Verzeichnis ` files in` ohne das Nginx-Statusverzeichnis:

cd /srv/salt/nginx/files/etc/nginx

Momentan werden wir diese Datei nicht ändern, aber wir können uns jetzt einen Gefallen tun und das Original sichern:

sudo cp nginx.conf nginx.conf.orig

Dies gibt uns einen guten Anhaltspunkt für Anpassungen, die wir möglicherweise in Zukunft vornehmen werden. Wir können Änderungen, die wir vorgenommen haben, schnell erkennen, indem wir Folgendes eingeben:

diff nginx.conf nginx.conf.orig

Wenn wir in Zukunft feststellen, dass wir die Konfiguration von Nginx in unseren verschiedenen Umgebungen anpassen müssen (z. B. möchten wir "+ worker_processes +" möglicherweise später mit der Anzahl der CPUs auf unseren Produktionsservern abgleichen), möchten wir möglicherweise zu wechseln Verwenden einer Vorlagendatei. Wir brauchen dies im Moment nicht, daher werden unsere Änderungen als Nicht-Vorlagendatei fest codiert.

Wie bereits erwähnt, sind derzeit keine Änderungen erforderlich. Lass uns weitermachen.

Konfigurieren Sie die Vorlage / etc / nginx / sites-available / default

Als Nächstes werfen wir einen Blick auf unsere Standard-Serverblockvorlage. Das Original finden wir in diesem Verzeichnis:

cd /srv/salt/nginx/files/etc/nginx/sites-available

Auch hier sollten wir das Original an einen Sicherungsort kopieren, falls wir es später benötigen:

sudo cp default default.orig

Wir können die Datei dann umbenennen, sodass sie die Erweiterung "+ .jinja +" hat. Dies wird uns visuell daran erinnern, dass diese Datei eine Vorlage und keine selbst verwendbare Datei ist:

sudo mv default default.jinja

Jetzt können wir die Vorlagendatei öffnen, um einige Änderungen vorzunehmen:

sudo nano default.jinja

Ganz oben in der Datei müssen wir anfangen, die Vorlagenfunktionen von Jinja zu nutzen. Unser Standard-Serverblock muss unterschiedliche Dateien rendern, je nachdem, ob sich der Webserver hinter einem Load Balancer befindet.

Wenn Verbindungen über einen Load Balancer empfangen werden, soll der Datenverkehr unseres Webservers auf die private Schnittstelle beschränkt werden. Wenn wir uns jedoch in der Entwicklungsumgebung befinden, verfügen wir nicht über einen Load Balancer. Daher möchten wir die Bereitstellung über die öffentliche Schnittstelle durchführen. Wir können diese Unterscheidung mit Jinja schaffen.

Wir erstellen eine Variable mit dem Namen "+ interface ", die die Schnittstelle enthalten soll, deren Adresse wir haben wollen. Wir testen, ob die Umgebung des Minions auf "dev" eingestellt ist. In diesem Fall verwenden wir die Schnittstelle " eth0 ". Andernfalls setzen wir es auf " eth1 ", die private Schnittstelle des Servers. Wir verwenden dann die Ausführungsmodulfunktion " grains.get ", um die mit der ausgewählten Schnittstelle verknüpfte Adresse abzurufen und diese als Wert für die Variable " addr +" zu verwenden. Wir werden dies ganz oben in die Datei einfügen:

/srv/salt/nginx/files/etc/nginx/sites-available/default.jinja

{%- set interface = 'eth0' if salt['grains.get']('env') == 'dev' else 'eth1' -%}
{%- set addr = salt['network.interface_ip'](interface) -%}
# You may add here your
# server {
#       ...
# }

. . .

Als nächstes können wir den weiter unten in der Datei gesperrten "+ Server" bearbeiten. Wir können die Variable + addr + verwenden, die wir oben in den Direktiven + listen + und + server_name + gesetzt haben. Wir haben die IPv6- und Standardserverteile entfernt, um die Funktionen dieses Blocks einzuschränken:

/srv/salt/nginx/files/etc/nginx/sites-available/default.jinja

{%- set interface = 'eth0' if salt['grains.get']('env') == 'dev' else 'eth1' -%}
{%- set addr = salt['network.interface_ip'](interface) -%}

. . .

server {
   listen :80;

   root /usr/share/nginx/html;
   index index.html index.htm;

   server_name ;

   location / {
       try_files $uri $uri/ =404;
   }
}

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

Konfigurieren Sie die Vorlage /usr/share/nginx/html/index.html

Wir können jetzt zur Datei "+ index.html" übergehen. Wechseln Sie in das Verzeichnis auf dem Salt-Master, das die Datei enthält:

cd /srv/salt/nginx/files/usr/share/nginx/html

Im Inneren müssen wir mit dem gleichen Verfahren beginnen, das wir beim letzten Mal verwendet haben. Wir sollten eine Kopie der Originaldatei für Prüf- und Sicherungszwecke speichern. Wir sollten die Datei dann umbenennen, um anzuzeigen, dass dies eine Vorlage ist:

sudo cp index.html index.html.orig
sudo mv index.html index.html.jinja

Öffnen Sie die Vorlagendatei, damit wir die erforderlichen Änderungen vornehmen können:

sudo nano index.html.jinja

Oben legen wir mit Jinja eine weitere Variable fest. Wir werden die Ausführungsmodulfunktion "+ grains.get " verwenden, um den Hostnamen des Minions zu ermitteln. Wir speichern dies in der Variablen " host +":

{% set host = salt['grains.get']('host') -%}
<!DOCTYPE html>
<html>

. . .

Dieser Wert wird dann in der gesamten Datei verwendet, damit wir leicht feststellen können, welcher Webserver unsere Anforderungen erfüllt. Ändern Sie zuerst den Wert + <title> +:

{% set host = salt['grains.get']('host') -%}
<!DOCTYPE html>
<html>
<head>
<title>Welcome </title>
. . .

Ändern wir den Nachrichtentext wie folgt:

. . .

<body>
<h1>Welcome to nginx!</h1>




</body>
</html>

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

Testen der Nginx-Statusdatei

Wir haben jetzt unsere Nginx-Konfiguration abgeschlossen. Wir können bestimmte Aspekte des Staates testen, um sicherzustellen, dass es richtig funktioniert.

Zunächst können wir mit der Ausführungsmodulfunktion + state.show_sls + anzeigen, wie Salt unsere Nginx-Statusdatei interpretiert. Wir können unseren "+ stage-www1 +" - Server als Ziel verwenden. Auf dem Server wird zu diesem Zeitpunkt jedoch nichts ausgeführt:

sudo salt stage-www1 state.show_sls nginx

Sie sollten eine Ausgabe erhalten, die ungefähr so ​​aussieht:

Outputstage-www1:
   ----------
   /etc/nginx/nginx.conf:
       ----------
       __env__:
           base
       __sls__:
           nginx
       file:
           |_
             ----------
             source:
                 salt://nginx/files/etc/nginx/nginx.conf
           |_
             ----------
             user:
                 root
           |_
             ----------
             group:
                 root
           |_
             ----------
             mode:
                 640
           - managed
           |_
             ----------
             order:
                 10002

. . .

Es rendert hauptsächlich die Informationen aus unserer Datei + / srv / salt / nginx / init.sls + mit einigen interessanten Ergänzungen. Stellen Sie sicher, dass keine Interpretationsfehler vorliegen, bei denen Salt nicht wusste, wie Befehle gelesen werden. Die „Bestellung“ jedes Stücks ist ein weiterer guter Artikel, den Sie überprüfen sollten. Dies bestimmt, wann jeder einzelne Status in der Datei ausgeführt wird. Der erste Status hat die Bestellnummer „10000“. Jeder weitere Staat zählt von dort hoch. Beachten Sie, dass sich das + env + von dem + env + unterscheidet, das wir mithilfe von Körnern festlegen. Wir verwenden in diesem Handbuch nicht das Umgebungskonzept von Salt.

Als nächstes können wir einen Probelauf zum Anwenden unserer Statusdatei durchführen. Wir können dies mit der Funktion "+ state.apply " mit der Option " test = True +" tun. Der Befehl sieht folgendermaßen aus:

sudo salt stage-www1 state.apply nginx test=True

Dies zeigt Ihnen die Änderungen, die vorgenommen werden, wenn die Option + test = True + entfernt wird. Stellen Sie sicher, dass die Änderungen sinnvoll sind und Salt alle Ihre Dateien korrekt interpretieren kann. Das Feld "Kommentar" ist besonders wichtig, da es Probleme aufzeigen kann, selbst wenn Salt den Status nicht als fehlgeschlagen markiert hat.

Wenn im Probelauf keine Probleme aufgetreten sind, können Sie versuchen, den Status auf alle verfügbaren Webserver anzuwenden, indem Sie Folgendes eingeben:

sudo salt -G 'role:webserver' state.apply nginx

Wenn Sie den Nginx-Status auf Ihre Staging- oder Produktions-Webserver angewendet haben, möchten Sie deren interne IP-Adressen erhalten. Die Seiten werden nicht über die öffentliche Schnittstelle verfügbar sein:

sudo salt-call mine.get 'role:webserver' internal_ip expr_form=grain
Outputlocal:
   ----------
   stage-www1:

   stage-www2:

Wenn Sie andererseits Ihren Entwicklungswebserver hochgefahren und den Nginx-Status angewendet haben, möchten Sie die externe Adresse abrufen, da:

sudo salt-call mine.get 'role:webserver' external_ip expr_form=grain

Sie können Ihre Server mit + curl + testen:

curl

Sie sollten die Seite "+ index.html" sehen, die wir geändert haben:

Output<!DOCTYPE html>
<html>
<head>
<title>Welcome from </title>
<style>
   body {
       width: 35em;
       margin: 0 auto;
       font-family: Tahoma, Verdana, Arial, sans-serif;
   }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>Hello!  This is being served from:</p>

<h2></h2>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Wie Sie sehen, wurde der Hostname des Minions in die Datei eingefügt, als die Jinja gerendert wurde. Unser Nginx-Status ist jetzt abgeschlossen.

Fazit

Sie sollten jetzt einen voll funktionsfähigen Nginx-Status haben. Auf diese Weise können Sie jede Salt-gesteuerte Maschine schnell und einfach in einen Webserver mit Ihren Spezifikationen verwandeln. Wir werden dies als Teil unserer Strategie für ein umfassenderes Infrastrukturmanagement verwenden, um die Webserver in unseren Umgebungen einfach zu konstruieren.

In der nächsten Anleitung next werden wir fortfahren und den Status für die Load Balancer erstellen das wird den Verkehr vor unseren Webservern leiten. Wir werden einige der gleichen Techniken verwenden, die wir in diesem Handbuch verwendet haben, um unsere Load Balancer flexibel zu gestalten.

Related