Verwendung von Salt Cloud Map-Dateien zum Bereitstellen von App-Servern und eines Nginx-Reverse-Proxy

Einführung

Sie haben Ihre App geschrieben und müssen sie nun bereitstellen. Sie könnten eine Produktionsumgebung erstellen und Ihre App auf einer VM einrichten, aber wie skalieren Sie sie, wenn sie populär wird? Wie rollen Sie neue Versionen aus? Was ist mit dem Lastenausgleich? Und vor allem, wie können Sie sicher sein, dass die Konfiguration korrekt ist? All dies können wir automatisieren, um uns viel Zeit zu sparen.

In diesem Lernprogramm erfahren Sie, wie Sie Ihre Anwendung in einer Salt Cloud-Zuordnungsdatei definieren. Dazu gehört auch die Verwendung benutzerdefinierter Salt-Körner, um Ihren Servern Rollen zuzuweisen und einen Reverse-Proxy dynamisch zu konfigurieren.

Am Ende dieses Tutorials verfügen Sie über zwei grundlegende App-Server, einen Nginx-Reverse-Proxy mit einer dynamisch erstellten Konfiguration und die Möglichkeit, Ihre Anwendung in Minuten zu skalieren.

Voraussetzungen

Um diesem Tutorial zu folgen, benötigen Sie:

  • Ein CentOS 7-Tröpfchen mit 1 GB. Alle Befehle in diesem Lernprogramm werden als root ausgeführt, sodass Sie keinen sudo-Benutzer ohne root erstellen müssen.

  • Ein SSH-Schlüssel im Droplet für den Benutzer * root * (d. H. ein neues Schlüsselpaar, das auf dem Droplet erstellt wurde). Fügen Sie diesen SSH-Schlüssel in das DigitalOcean-Bedienfeld ein, damit Sie sich über das Master-Droplet bei anderen DigitalOcean-Droplets anmelden können. Anweisungen dazu finden Sie im How To Use SSH Keys with DigitalOcean Droplets -Tutorial. + Notieren Sie sich den Namen, den Sie der Taste im DigitalOcean-Bedienfeld zugewiesen haben. In diesem Tutorial verwenden wir den Namen. Sie sollten sich auch den Speicherort des privaten Schlüssels notieren. Standardmäßig ist es "+ / root / .ssh / id_rsa +".

  • Ein persönliches Zugriffstoken, das Sie erstellen können, indem Sie den Anweisungen in diesem Schritt von https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generate folgen -a-personal-access-token [Verwendung der DigitalOcean-APIv2]. Stellen Sie sicher, dass der Bereich zum Lesen und Schreiben festgelegt ist.

Schritt 1 - Installation von Salt und Salt Cloud

Zum Starten muss Salt Cloud auf Ihrem Server installiert und konfiguriert sein. In diesem Tutorial verwenden wir nur das Salt-Bootstrap-Skript.

Ätzen Sie zuerst das Salt-Bootstrap-Skript, um Salt zu installieren.

wget -O install_salt.sh https://bootstrap.saltstack.com

Führen Sie das Salt-Bootstrap-Skript aus. Wir benutzen das + -M + Flag, um auch + salt-master + zu installieren.

sh install_salt.sh -M

Während die Salt Cloud-Codebasis in das Kernprojekt Salt integriert wurde, ist sie für CentOS immer noch separat verpackt. Glücklicherweise hat das Skript "+ install_salt " die Repos für uns konfiguriert, sodass wir " salt-cloud +" einfach mit yum installieren können:

yum install salt-cloud

Jetzt können wir die Version von Salt Cloud überprüfen, um eine erfolgreiche Installation zu bestätigen:

salt-cloud --version

Sie sollten die Ausgabe so sehen:

Ausgabe in Salzwolkenversion

salt-cloud 2015.5.3 (Lithium)

Beachten Sie, dass sich Salt in einem rollierenden Release-Zyklus befindet, sodass Ihre Version möglicherweise geringfügig von der obigen Version abweicht.

Schritt 2 - Salt Cloud konfigurieren

In diesem Abschnitt konfigurieren wir Salt Cloud für die Verbindung mit DigitalOcean und definieren einige Profile für unsere Droplets.

Konfigurieren der DigitalOcean-Provider-Datei

In Salt Cloud definieren Sie unter Provider-Dateien, wo die neuen VMs erstellt werden. Provider werden im Verzeichnis + / etc / salt / cloud.providers.d + definiert

Erstellen und öffnen Sie eine DigitalOcean-Provider-Datei mit + nano + oder Ihrem bevorzugten Texteditor.

nano /etc/salt/cloud.providers.d/digital_ocean.conf

Fügen Sie den folgenden Text ein und ersetzen Sie die Variablen durch Ihre - nämlich die Server-IP und das Zugriffstoken sowie den SSH-Schlüsselnamen und die Datei, falls Sie sie angepasst haben.

/etc/salt/cloud.providers.d/digital_ocean.conf

### /etc/salt/cloud.providers.d/digital_ocean.conf ###
######################################################
do:
 provider: digital_ocean
 minion:
   master:

 # DigitalOcean Access Token
 personal_access_token:

 # This is the name of your SSH key in your Digital Ocean account
 # as it appears in the control panel.
 ssh_key_name:

 # This is the path on disk to the private key for your Digital Ocean account
 ssh_key_file:

Sie müssen die Berechtigungen für Ihre SSH-Schlüsseldatei sperren. Andernfalls wird SSH die Verwendung verweigern. Angenommen, Sie befinden sich am Standardspeicherort "+ / root / .ssh / id_rsa +".

chmod 600 /root/.ssh/id_rsa

Konfigurieren der Profile für bereitstellbare Server

In Salt Cloud sind profiles einzelne VM-Beschreibungen, die an einen Anbieter gebunden sind (z. “Eine 512 MB Ubuntu VM auf DigitalOcean”). Diese sind im Verzeichnis + / etc / salt / cloud.profiles.d + definiert.

Erstellen und öffnen Sie eine Profildatei.

nano /etc/salt/cloud.profiles.d/digital_ocean.conf

Fügen Sie Folgendes in die Datei ein. Keine Änderung ist notwendig:

/etc/salt/cloud.profiles.d/digital_ocean.conf

### /etc/salt/cloud.profiles.d/digital_ocean.conf ###
#####################################################

ubuntu_512MB_ny3:
 provider: do
 image: ubuntu-14-04-x64
 size: 512MB
 location: nyc3
 private_networking: True

ubuntu_1GB_ny3:
 provider: do
 image: ubuntu-14-04-x64
 size: 1GB
 location: nyc3
 private_networking: True

Speichern und schließen Sie die Datei. Diese Datei definiert zwei Profile:

  • Eine Ubuntu 14.04-VM mit 512 MB Arbeitsspeicher, die in der Region New York 3 bereitgestellt wird.

  • Eine Ubuntu 14.04-VM mit 1 GB Arbeitsspeicher, die in der Region New York 3 bereitgestellt wird.

Wenn Sie ein anderes Bild als Ubuntu 14.04 verwenden möchten, können Sie Salt Cloud verwenden, um alle verfügbaren Bildnamen auf DigitalOcean mit dem folgenden Befehl aufzulisten:

salt-cloud --list-images do

Daraufhin werden alle Standard-DigitalOcean-Bilder sowie benutzerdefinierte Bilder angezeigt, die Sie mit dem Snapshot-Tool in Ihrem Konto gespeichert haben. Sie können den Bildnamen oder die Region, die wir in der Provider-Datei verwendet haben, durch einen anderen Bildnamen aus dieser Liste ersetzen. Stellen Sie in diesem Fall sicher, dass Sie das Feld aus dieser Ausgabe in der Einstellung in der Profildatei verwenden.

Testen Sie Ihre Konfiguration mit einer kurzen Abfrage.

salt-cloud -Q

Sie sollten ungefähr Folgendes sehen.

Beispiel Salzwolke -Q Ausgabe

[INFO    ] salt-cloud starting
do:
   ----------
   digital_ocean:
       ----------
       centos-salt:
           ----------
           id:
               2806501
           image_id:
               6372108
           public_ips:
               192.241.247.229
           size_id:
               63
           state:
               active

Dies bedeutet, dass Salt Cloud mit Ihrem DigitalOcean-Konto spricht und Sie zwei grundlegende Profile konfiguriert haben.

Schritt Drei - Schreiben einer einfachen Kartendatei

Eine Zuordnungsdatei ist eine YAML-Datei, in der die Profile und die Anzahl der Server aufgeführt sind, die Sie erstellen möchten. Wir beginnen mit einer einfachen Kartendatei und bauen im nächsten Abschnitt darauf auf.

Nehmen wir an, Sie möchten mit den oben genannten Profilen zwei 1-GB-App-Server mit einem einzigen 512-MB-Reverse-Proxy-Server betreiben. Wir erstellen eine Map-Datei mit dem Namen "+ / etc / salt / cloud.maps.d / do-app-with-proxy.map +" und definieren die App.

Erstellen Sie zuerst die Datei:

nano /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Fügen Sie den folgenden Text ein. Keine Änderung ist notwendig:

/etc/salt/cloud.maps.d/do-app-with-rproxy.map

### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ####
######################################################
ubuntu_512MB_ny3:
 - nginx-rproxy

ubuntu_1GB_ny3:
 - appserver-01
 - appserver-02

Das ist es! Das ist ungefähr so ​​einfach wie bei einer Kartendatei. Fahren Sie fort und stellen Sie diese Server bereit mit:

salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Wenn der Befehl beendet ist, bestätigen Sie den Erfolg mit einem kurzen Ping:

salt '*' test.ping

Sie sollten Folgendes sehen:

[label salt '*' test.ping
appserver-01:
   True
appserver-02:
   True
nginx-rproxy:
   True

Sobald Sie die VMs erfolgreich in Ihrer Map-Datei erstellt haben, ist das Löschen genauso einfach:

salt-cloud -d -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Verwenden Sie diesen Befehl jedoch mit Vorsicht! Es werden alle in dieser Zuordnungsdatei angegebenen VMs gelöscht.

Vierter Schritt - Eine realistischere Kartendatei schreiben

Diese Zuordnungsdatei funktionierte einwandfrei, aber selbst ein Shell-Skript konnte eine Reihe von VMs hochfahren. Wir müssen den Footprint unserer Anwendung definieren. Kehren wir zu unserer Kartendatei zurück und fügen ein paar weitere Dinge hinzu. Öffnen Sie die Kartendatei erneut.

nano /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Löschen Sie den vorherigen Inhalt der Datei und fügen Sie Folgendes ein. Es sind keine Änderungen erforderlich:

/etc/salt/cloud.maps.d/do-app-with-proxy.map

### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ###
#####################################################
ubuntu_512MB_ny3:
 - nginx-rproxy:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: rproxy
ubuntu_1GB_ny3:
 - appserver-01:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: appserver
 - appserver-02:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: appserver

Jetzt kommen wir voran! Es sieht nach viel aus, aber wir haben nur zwei Dinge hinzugefügt. Lassen Sie uns die beiden Zusätze durchgehen: den Abschnitt "+ mine_functions " und den Abschnitt " grains +".

Wir haben Salt Cloud angewiesen, die Salt Minion-Konfiguration für diese VMs zu ändern und einige benutzerdefinierte grains hinzuzufügen. Insbesondere geben die Körner der Reverse-Proxy-VM die Rolle "+ rproxy " und den App-Servern die Rolle " appserver +". Dies ist nützlich, wenn der Reverse-Proxy dynamisch konfiguriert werden muss.

Das + mine_functions + wird auch zur Salt Minion-Konfiguration hinzugefügt. Es weist den Minion an, die auf * eth0 * angegebene IP-Adresse an den Salt Master zurückzusenden, um sie in der Salt mine zu speichern. Dies bedeutet, dass der Salt Master die IP des neu erstellten Droplets automatisch erkennt, ohne dass wir sie konfigurieren müssen. Wir werden dies im nächsten Teil verwenden.

Fünfter Schritt - Reverse Proxy definieren

Wir haben jetzt eine gemeinsame Aufgabe vor uns: Installieren Sie den Reverse-Proxy-Webserver und konfigurieren Sie ihn. In diesem Lernprogramm wird Nginx als Reverse-Proxy verwendet.

Schreiben des Nginx Salt State

Es ist Zeit, uns die Hände schmutzig zu machen und ein paar Salzzustände zu schreiben. Legen Sie zunächst den Standardspeicherort für den Salt-Statusbaum fest:

mkdir /srv/salt

Navigiere in dieses Verzeichnis und erstelle ein weiteres Verzeichnis nur für nginx:

cd /srv/salt
mkdir /srv/salt/nginx

Gehen Sie in dieses Verzeichnis und erstellen Sie mit Ihrem bevorzugten Editor eine neue Datei mit dem Namen "+ rproxy.sls +":

cd /srv/salt/nginx
nano /srv/salt/nginx/rproxy.sls

Fügen Sie Folgendes in diese Datei ein. Es sind keine Änderungen erforderlich:

/srv/salt/nginx/rproxy.sls

### /srv/salt/nginx/rproxy.sls ###
##################################

### Install Nginx and configure it as a reverse proxy, pulling the IPs of
### the app servers from the Salt Mine.

nginx-rproxy:
 # Install Nginx
 pkg:
   - installed
   - name: nginx
 # Place a customized Nginx config file
 file:
   - managed
   - source: salt://nginx/files/awesome-app.conf.jin
   - name: /etc/nginx/conf.d/awesome-app.conf
   - template: jinja
   - require:
     - pkg: nginx-rproxy
 # Ensure Nginx is always running.
 # Restart Nginx if the config file changes.
 service:
   - running
   - enable: True
   - name: nginx
   - require:
     - pkg: nginx-rproxy
   - watch:
     - file: nginx-rproxy
 # Restart Nginx for the initial installation.
 cmd:
   - run
   - name: service nginx restart
   - require:
     - file: nginx-rproxy

Dieser Zustand bewirkt Folgendes:

  • Installiert Nginx.

  • Platziert unsere benutzerdefinierte Konfigurationsdatei in "+ / etc / nginx / conf.d / awesome-app.conf +".

  • Stellt sicher, dass Nginx ausgeführt wird.

Unser Salt-Status installiert einfach Nginx und legt eine Konfigurationsdatei ab. der wirklich interessante inhalt ist in der config.

Schreiben der Nginx Reverse Proxy-Konfigurationsdatei

Erstellen wir ein weiteres Verzeichnis für unsere Konfigurationsdatei:

mkdir /srv/salt/nginx/files
cd /srv/salt/nginx/files

Und öffne die Konfigurationsdatei:

nano /srv/salt/nginx/files/awesome-app.conf.jin

Fügen Sie Folgendes in die Konfigurationsdatei ein. Es sind keine Änderungen erforderlich, es sei denn, Sie verwenden kein privates Netzwerk. Ändern Sie in diesem Fall das "+ 1 " in " 0 +", wie in der folgenden Zeile angegeben:

/srv/salt/nginx/files/awesome-app.conf.jin

### /srv/salt/nginx/files/awesome-app.conf.jin ###
##################################################

### Configuration file for Nginx to act as a
### reverse proxy for an app farm.

# Define the app servers that we're in front of.
upstream awesome-app {
   {% for server, addrs in salt['mine.get']('roles:appserver', 'network.ip_addrs', expr_form='grain').items() %}
   server {{ addrs[0] }}:1337;
   {% endfor %}
}

# Forward all port 80 http traffic to our app farm, defined above as 'awesome-app'.
server {
   listen       80;
   server_name  {{ salt['network.ip_addrs']()[] }};  #
                                                      #     DigitalOcean's private networking.

   access_log  /var/log/nginx/awesome-app.access.log;
   error_log  /var/log/nginx/awesome-app.error.log;

   ## forward request to awesome-app ##
   location / {
    proxy_pass  http://awesome-app;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Wir verwenden die Erweiterung "+ .jin +", um uns mitzuteilen, dass die Datei Jinja templating enthält. Mit Jinja-Vorlagen können wir eine kleine Menge Logik in unsere Textdateien einfügen, um dynamisch Konfigurationsdetails zu generieren.

Diese Konfigurationsdatei weist Nginx an, den gesamten HTTP-Verkehr für Port 80 zu übernehmen und an unsere App-Farm weiterzuleiten. Es besteht aus zwei Teilen: einem Upstream (unsere App-Farm) und der Konfiguration, die als Proxy zwischen dem Benutzer und unserer App-Farm fungiert.

Reden wir über den Upstream. Ein normaler Upstream ohne Vorlage gibt eine Sammlung von IPs an. Wir wissen jedoch nicht, wie die IP-Adressen unserer Minions lauten werden, bis sie existieren, und wir bearbeiten die Konfigurationsdateien nicht manuell. (Sonst gibt es keinen Grund, Salt zu verwenden!)

Erinnern Sie sich an die "+ mine_function +" - Zeilen in unserer Kartendatei? Die Schergen geben dem Salzmeister ihre IPs, um sie für eine solche Gelegenheit aufzubewahren. Schauen wir uns diese Jinja-Linie etwas genauer an:

Jinja-Auszug

{% for server, addrs in salt['mine.get']('roles:appserver', 'network.ip_addrs', expr_form='grain').items() %}

Dies ist eine for-Schleife in Jinja, die eine beliebige Salt-Funktion ausführt. In diesem Fall wird http://docs.saltstack.com/de/latest/ref/modules/all/salt.modules.mine.html#salt.modules.mine.get [+ mine.get +] ausgeführt. Die Parameter sind:

  • + role: appserver + - Dies besagt, dass nur die Details von den Schergen abgerufen werden sollen, die die Rolle "appserver" haben.

  • + network.ip_addrs + - Dies sind die Daten, die wir aus der Mine holen wollen. Dies haben wir auch in unserer Map-Datei festgelegt.

  • + expr_form = 'grain' + - Dies sagt Salt, dass wir unsere Schergen basierend auf ihren Körnern als Ziel haben. Weitere Informationen zum Matching nach Getreide finden Sie unter the Saltstack targeting doc.

Nach dieser Schleife enthält die Variable "+ {{addrs}} " eine Liste von IP-Adressen (auch wenn es sich nur um eine Adresse handelt). Da es sich um eine Liste handelt, müssen wir das erste Element mit " [0] +" greifen.

Das ist der Upstream. Wie für den Servernamen:

server_name  {{ salt['network.ip_addrs']()[0] }};

Dies ist der gleiche Trick wie der Aufruf der Salzmine (in Jinja eine Salzfunktion aufrufen). Es ist nur einfacher. Es ruft http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.network.html#salt.modules.network.ip_addrs [+ network.ip_addrs +] auf und übernimmt das erste Element der zurückgegebenen Liste. Auf diese Weise müssen wir unsere Datei auch nicht manuell bearbeiten.

Schritt Sechs - Definieren der App-Farm

Ein Reverse-Proxy bedeutet nicht viel, wenn keine App dahintersteckt. Erstellen wir eine kleine Node.js-Anwendung, die nur die IP des Servers meldet, auf dem sie sich befindet (damit wir bestätigen können, dass wir beide Computer erreichen).

Erstelle ein neues Verzeichnis mit dem Namen "+ awesome-app +" und verschiebe es dorthin.

mkdir -p /srv/salt/awesome-app
cd /srv/salt/awesome-app

Erstellen Sie eine neue App-Statusdatei mit dem Namen "+ app.sls +".

nano /srv/salt/awesome-app/app.sls

Fügen Sie Folgendes in die Datei ein. Keine Änderung ist notwendig:

/srv/salt/awesome-app/app.sls

### /srv/salt/awesome-app/app.sls ###
#####################################

### Install Nodejs and start a simple
### web application that reports the server IP.

install-app:
 # Install prerequisites
 pkg:
   - installed
   - names:
     - node
     - npm
     - nodejs-legacy  # workaround for Debian systems
 # Place our Node code
 file:
   - managed
   - source: salt://awesome-app/files/app.js
   - name: /root/app.js
 # Install the package called 'forever'
 cmd:
   - run
   - name: npm install forever -g
   - require:
     - pkg: install-app

run-app:
 # Use 'forever' to start the server
 cmd:
   - run
   - name: forever start app.js
   - cwd: /root

Diese Statusdatei führt Folgendes aus:

  • Installieren Sie die Pakete + nodejs,` + npm` und + nodejs-legacy.

  • Fügt die JavaScript-Datei hinzu, die unsere einfache App sein wird.

  • Verwendet NPM zur Installation von https://www.npmjs.org/package/forever [+ Forever +].

  • Führt die App aus.

Erstellen Sie nun den (kleinen) App-Code:

mkdir /srv/salt/awesome-app/files
cd /srv/salt/awesome-app/files

Erstellen Sie die Datei:

nano /srv/salt/awesome-app/files/app.js

Legen Sie das Folgende hinein. Es sind keine Änderungen erforderlich:

/srv/salt/awesome-app/files/app.js

/* /srv/salt/awesome-app/files/app.js

  A simple Node.js web application that
  reports the server's IP.
  Shamefully stolen from StackOverflow:
  http://stackoverflow.com/questions/10750303/how-can-i-get-the-local-ip-address-in-node-js
*/

var os = require('os');
var http = require('http');

http.createServer(function (req, res) {
 var interfaces = os.networkInterfaces();
 var addresses = [];
 for (k in interfaces) {
     for (k2 in interfaces[k]) {
         var address = interfaces[k][k2];
         if (address.family == 'IPv4' && !address.internal) {
             addresses.push(address.address)
         }
     }
 }

 res.writeHead(200, {'Content-Type': 'text/plain'});
 res.end(JSON.stringify(addresses));
}).listen(1337, '0.0.0.0');
console.log('Server listening on port 1337');

Dies ist ein einfacher Node.js-Server, der eines tut: Er akzeptiert HTTP-Anforderungen an Port 1337 und antwortet mit den IP-Adressen des Servers.

Zu diesem Zeitpunkt sollten Sie eine Dateistruktur haben, die wie folgt aussieht:

Dateistruktur

/srv/salt
        ├── awesome-app
        │   ├── app.sls
        │   └── files
        │       └── app.js
        └── nginx
            ├── rproxy.sls
            └── files
                └── awesome-app.conf.jin

Schritt Sieben - Bereitstellen der Anwendung

Jetzt müssen Sie nur noch die Anwendung bereitstellen.

Stellen Sie die Server mit Salt Cloud bereit

Führen Sie den gleichen Bereitstellungsbefehl aus, der jetzt alle von uns vorgenommenen Konfigurationen verwendet.

salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Warten Sie, bis Salt Cloud abgeschlossen ist. dies wird eine Weile dauern. Bestätigen Sie nach der Rückkehr die erfolgreiche Bereitstellung, indem Sie einen Ping-Befehl an die App-Server senden:

salt -G 'roles:appserver' test.ping

Das solltest du sehen:

App-Server-Ping-Ausgabe

appserver-02:
   True
appserver-01:
   True

Pingen Sie den Reverse-Proxy:

salt -G 'roles:rproxy' test.ping

Das solltest du sehen:

Reverse-Proxy-Ping-Ausgabe

nginx-rproxy:
   True

Sobald Sie Ihre VMs haben, ist es Zeit, sie zum Arbeiten zu bringen.

Erstellen Sie die Anwendung

Setzen Sie als Nächstes die Salt-Befehle ab, um die App-Farm und den Reverse-Proxy automatisch zu erstellen.

Erstellen Sie die App-Farm:

salt -G 'roles:appserver' state.sls awesome-app.app

Es wird eine angemessene Menge an Output geben, aber es sollte mit Folgendem enden:

Summary
------------
Succeeded: 6 (changed=6)
Failed:    0
------------
Total states run:     6

Erstellen Sie den Reverse-Proxy:

salt -G 'roles:rproxy' state.sls nginx.rproxy

Es wird wieder eine Menge Output geben, der mit folgendem endet:

Summary
------------
Succeeded: 4 (changed=4)
Failed:    0
------------
Total states run:     4

Also, was ist gerade hier passiert?

Der erste Befehl (der mit den App-Servern) nahm den Salt-Status an, den wir zuvor geschrieben haben, und führte ihn auf den beiden App-Servern aus. Dies führte zu zwei Computern mit identischen Konfigurationen, auf denen identische Codeversionen ausgeführt wurden.

Der zweite Befehl (der Reverse-Proxy) führte den Salt-Status aus, den wir für Nginx geschrieben haben. Es installierte Nginx und die Konfigurationsdatei und füllte die IPs unserer App-Farm dynamisch in die Konfigurationsdatei ein.

Sobald diese Salt-Läufe abgeschlossen sind, können Sie die erfolgreiche Bereitstellung testen. Finden Sie die IP Ihres Reverse-Proxy:

salt -G 'roles:rproxy' network.ip_addrs

Sie erhalten möglicherweise zwei IP-Adressen zurück, wenn Sie ein privates Netzwerk für Ihr Droplet verwenden.

Stecken Sie die öffentliche IP in Ihren Browser und besuchen Sie die Webseite! Klicken Sie einige Male auf Aktualisieren, um zu bestätigen, dass Nginx tatsächlich zwischen den beiden von Ihnen erstellten App-Servern Proxies ausführt. Die IP-Adressen sollten sich ändern und bestätigen, dass Sie tatsächlich eine Verbindung zu mehr als einem App-Server herstellen.

Wenn Sie trotz Aktualisierung dieselbe IP-Adresse erhalten, liegt dies wahrscheinlich am Browser-Caching. Sie können stattdessen versuchen, mit + curl + zu zeigen, dass Nginx unter Ihren App-Servern einen Proxy-Server verwendet. Führen Sie diesen Befehl mehrmals aus und beobachten Sie die Ausgabe:

curl http://

Wir können dies ein paar Schritte weiter gehen und die Anwendungsbereitstellung vollständig über OverState automatisieren. Auf diese Weise können wir einen einzigen Befehl erstellen, mit dem wir Salt anweisen, zuerst die App-Server zu erstellen, bevor wir den Reverse-Proxy erstellen, um die Reihenfolge unseres Erstellungsprozesses zu gewährleisten.

Schritt acht - Skalieren (optional)

Mit Salt können Sie den Build-Prozess automatisieren. Mit Salt Cloud und Kartendateien können Sie Ihre Bereitstellung auf einfache Weise skalieren. Wenn Sie Ihrer Bereitstellung weitere App-Server hinzufügen möchten (z. B. zwei weitere), aktualisieren Sie Ihre Zuordnungsdatei folgendermaßen:

/etc/salt/cloud.maps.d/do-app-with-proxy.map

### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ###
#####################################################
ubuntu_512MB_ny3:
 - nginx-rproxy:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: rproxy
ubuntu_1GB_ny3:
- appserver-01:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver
- appserver-02:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver
- appserver-03:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver
- appserver-04:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver

Nach dieser Aktualisierung würden Sie den Befehl und die beiden Befehle aus Schritt 6 erneut ausführen:

salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map
salt -G 'roles:appserver' state.sls awesome-app.app
salt -G 'roles:rproxy' state.sls nginx.rproxy

Die vorhandenen Server wären von der wiederholten Ausführung von Salt nicht betroffen, die neuen Server würden gemäß Spezifikation erstellt, und die Nginx-Konfiguration würde aktualisiert, um den Datenverkehr an die neuen App-Server weiterzuleiten.

Fazit

Das Bereitstellen einer App, die nur die IP des Servers meldet, ist nicht sehr nützlich. Glücklicherweise ist dieser Ansatz nicht auf Node.js Anwendungen beschränkt. Salt ist es egal, in welcher Sprache Ihre App geschrieben ist.

Wenn Sie dieses Framework für die Bereitstellung Ihrer eigenen App verwenden möchten, müssen Sie lediglich die Aufgabe der Installation Ihrer App auf einem Server automatisieren (entweder über ein Skript oder mit Salt-Status) und unser Beispiel durch Ihre eigene Automatisierung ersetzen.

So wie Salt Prozesse in Ihren Droplets automatisiert, automatisiert Salt Cloud Prozesse in Ihrer Cloud. Genießen!