TOC

So verwenden Sie Blue-Green-Bereitstellungen, um Software sicher freizugeben

Einführung

Moderne Entwicklungspraktiken unterscheiden häufig zwischen dem Bereitstellen und Freigeben von Software. Bei der Bereitstellung wird der neue Code auf die Server übertragen. Das Freigeben ist der Schritt, bei dem der neue Code Produktionsdaten empfängt.

Die blaugrüne Bereitstellung ist eine Strategie zum Bereitstellen und Freigeben von Software. Zur Vereinfachung der Diskussion müssen zwei separate produktionsfähige Umgebungen mit den Spitznamen Blau und Grün verwaltet werden. In diesem Handbuch wird erläutert, wie Sie blaugrüne Bereitstellungen auf DigitalOcean verwenden können, um die Umstellung Ihrer Benutzer auf eine neue Version Ihrer Software zu vereinfachen.

Voraussetzungen

Um dieses Handbuch zu vervollständigen, benötigen Sie zwei Ubuntu 14.04-Server, die in einer Umgebung bereitgestellt werden, in der Sie IP-Adressen problemlos zwischen Hosts verschieben können. Auf DigitalOcean kann Floating IPs diese Funktionalität bereitstellen. Diese Server repräsentieren zwei parallele Umgebungen, die alternativ für die Bereitstellung und Produktion verwendet werden. Sie können diese Server beliebig anrufen, in diesem Handbuch werden sie jedoch als "blau" und "grün" bezeichnet.

Auf jedem dieser Server sollte ein Benutzer ohne Rootberechtigung mit "+ sudo +" für Verwaltungsfunktionen konfiguriert sein. Sie können diese Benutzer konfigurieren, indem Sie unserer https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04[Ubuntu 14.04 Anleitung zur Ersteinrichtung des Servers folgen.

Was ist eine blau-grüne Bereitstellung?

Das Grundkonzept für die blaugrüne Bereitstellung, eine Technik, die von Martin Fowler unter this post populär gemacht wurde, besteht darin, dass zwei Umgebungen verwendet werden, von denen jede für Ihre Anwendung in der Produktion geeignet ist , sind erhalten. Diese beiden Umgebungen sollten nahezu identisch sein. Konventionell werden diese als blaue und grüne Umgebung bezeichnet.

Es ist immer nur eine dieser Umgebungen aktiv und empfängt gleichzeitig Produktionsdaten. Vor den Web-Endpunkten für diese Umgebungen (entweder Webserver oder Load Balancer) leitet ein Router oder ein anderer Mechanismus zur Verkehrssteuerung den gesamten Produktionsverkehr an die derzeit aktive Umgebung weiter.

Wenn eine neue Version geplant ist, wird sie in der nicht aktiven Umgebung bereitgestellt. Bei blaugrünen Bereitstellungen fungiert die nicht aktive Umgebung als endgültige Staging-Umgebung. Es spiegelt die Produktionsumgebung sehr genau wider und kann für abschließende Tests verwendet werden, bevor entschieden wird, Änderungen live zu übertragen.

Sobald Sie Ihre Bereitstellung intern getestet und Vertrauen in ihre Robustheit gewonnen haben, können Sie die neue Version schnell und einfach freigeben, indem Sie den Routing-Mechanismus anpassen. Grundsätzlich schalten Sie den Schalter auf der Verkehrsleitebene um, sodass der gesamte Produktionsverkehr auf Ihre neue Softwareversion umgestellt wird. Die zuvor aktive Umgebung wird inaktiv und Ihre vorherige Staging-Umgebung wird zu Ihrer neuen Produktionsumgebung.

Zu diesem Zeitpunkt ist Ihre vorherige Softwareversion nicht aktiv, aber immer noch verfügbar. Wenn Ihre neu aktive Bereitstellung schwerwiegende Probleme aufweist, müssen Sie lediglich den Routing-Mechanismus erneut ändern, um zur vorherigen Version zurückzukehren.

Beispielszenario

Um dieses allgemeine Konzept zu demonstrieren, werden zwei Serverumgebungen eingerichtet. Auf jedem wird ein Webserver installiert. Beachten Sie, dass der Webserver in diesem Beispiel einen gesamten Anwendungsstapel darstellt, der einen Lastenausgleich, mehrere Webserver und verteilte oder replizierte Datenbanken im Backend umfassen kann. In diesem Handbuch wird ein Webserver verwendet, da dieser die kleinste Umgebung darstellt, die dieses Versionsmuster demonstrieren kann.

Wir werden anfangen, eine "App" auf unserem lokalen Computer zu entwickeln. In Wirklichkeit ist dies nur eine Seite "+ index.html", die wir auf unseren Servern bereitstellen können. Wir konfigurieren eine https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks#using-git-hooks-to-deploy- an einen separaten Produktionsserver [+ git + post receive hook] auf jedem unserer Server, sodass wir die Bereitstellung einfach durch Ausgabe eines + git push + durchführen können. Wir werden die erste Version unserer Anwendung auf beiden Servern bereitstellen.

In diesem Handbuch wird DigitalOcean Floating IP address als Routing-Mechanismus verwendet. Floating IPs bieten einen einfachen Mechanismus zum Übertragen von Datenverkehr von einem Server auf einen anderen. Wir werden eine Floating-IP erstellen und auf unseren grünen Server verweisen, um diese als unsere anfängliche Produktionsmaschine festzulegen.

Wir werden dann unsere Anwendung modifizieren und auf unserem blauen Server bereitstellen. Der Produktionsdatenverkehr wird zu diesem Zeitpunkt weiterhin vom unveränderten grünen Server aus bedient. Anschließend können wir den blauen Server testen, um sicherzustellen, dass unsere Bereitstellung erfolgreich war und keine Fehler aufgetreten sind. Wenn wir fertig sind, können wir die Floating IP auf die neue Version des Codes verschieben, indem wir die Floating IP-Adresse dem blauen Server neu zuweisen.

Erstellen Sie eine lokale Anwendung

Wir beginnen mit der Erstellung unserer "Anwendung". Wie oben erwähnt, handelt es sich hierbei eigentlich nur um eine Indexseite, die von unseren Webservern angezeigt werden kann. Es ermöglicht uns, verschiedene „Versionen“ der App zu demonstrieren, ohne den Aufwand für die eigentliche Entwicklung.

Installieren Sie auf Ihrem lokalen System (oder auf einem anderen Droplet) https://git-scm.com/downloads [+ git +] mit der von Ihrer Plattform bevorzugten Methode. Wenn auf Ihrem lokalen Computer Ubuntu ausgeführt wird, können Sie installieren, indem Sie Folgendes eingeben:

sudo apt-get update
sudo apt-get install git

Wir müssen einige Konfigurationseinstellungen vornehmen, um ein Commit für ein "+ git +" - Repository durchzuführen. Wir werden unseren Namen und unsere E-Mail-Adresse festlegen, indem wir Folgendes eingeben:

git config --global user.name ""
git config --global user.email ""

Mit unserem Konfigurationssatz können wir ein Verzeichnis für unsere neue Anwendung erstellen und in dieses verschieben:

mkdir ~/sample_app
cd ~/sample_app

Initialisieren Sie ein Git-Repository in unserem Anwendungsverzeichnis, indem Sie Folgendes eingeben:

git init

Erstellen Sie nun die Datei "+ index.html", die Ihre Anwendung darstellt:

nano index.html

Im Inneren geben wir nur die Versionsnummer unserer Anwendung an. Auf diese Weise können wir leicht feststellen, welche Version unserer App auf jedem Server installiert ist:

~ / sample_app / index.html

App v1

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

Abschließend können wir die Datei "+ index.html" zum Staging-Bereich "+ git" hinzufügen und dann Folgendes festschreiben:

git add .
git commit -m "initializing repository with version 1"

Da unsere Datei festgeschrieben ist, werden wir die Anwendungsentwicklung auf unserem lokalen Computer vorübergehend stoppen und uns auf die Einrichtung unserer blauen und grünen Webserver konzentrieren.

Konfigurieren Sie die blauen und grünen Webserver

Als Nächstes arbeiten wir daran, unsere grüne und blaue Umgebung mit funktionsfähigen Webservern einzurichten. Wir werden Apache in diesem Handbuch verwenden. Melden Sie sich bei Ihren Servern mit Ihrem Benutzer "+ sudo +" an, um zu beginnen.

Note

Wir können Apache einfach mit + apt + installieren. Aktualisieren Sie den lokalen Paketindex und installieren Sie die Webserver-Software, indem Sie Folgendes eingeben:

sudo apt-get update
sudo apt-get install apache2

Dies sollte Apache auf beiden Webservern installieren und starten.

Als Nächstes sollten wir einen Bereitstellungsbenutzer erstellen und konfigurieren. Dieser Benutzer hat Zugriff auf das Apache-Webstammverzeichnis und besitzt das nackte "+ git" -Repository, in das wir unsere App verschieben.

Erstellen Sie einen "+ deploy +" - Benutzer, indem Sie Folgendes eingeben:

sudo adduser --disabled-password deploy

Dadurch wird ein neuer Benutzer mit deaktivierter Kennwortauthentifizierung erstellt.

Wir geben diesem neuen Benutzer das Eigentumsrecht an Apaches Standardwebstamm. Dies befindet sich unter "+ / var / www / html". Ändern Sie den Eigentümer dieses Verzeichnisses, indem Sie Folgendes eingeben:

sudo chown -R : /var/www/html

Dies ist alles, was wir für unsere einfache Bereitstellung benötigen, bei der nur Dateien in das Web-Stammverzeichnis verschoben werden.

Note

Einrichten der Git-Bereitstellung auf den grünen und blauen Webservern

Nachdem wir Apache installiert und einen Benutzer für die Ausführung der Bereitstellung konfiguriert haben, können wir ein nacktes "+ git " - Repository konfigurieren, in das unsere Anwendung verschoben werden soll. Wir können dann einen " post-receive +" - Hook einrichten, der automatisch die neueste Version unseres Master-Zweigs bereitstellt, wenn wir ihn auf unsere Server übertragen.

Note

Beginnen Sie mit der Installation von "+ git +" auf beiden Servern:

sudo apt-get install git

Als nächstes müssen wir uns als unser Benutzer "+ deploy " anmelden. Wir können das mit ` sudo +` machen, indem wir Folgendes eingeben:

sudo su - deploy

Erstellen Sie in unserem Benutzerverzeichnis "+ deploy +" ein Verzeichnis für unsere Beispielanwendung, genau wie wir es auf unserem lokalen Computer getan haben. Nach der Erstellung in das Verzeichnis verschieben:

mkdir ~/sample_app
cd ~/sample_app

Wir werden in diesem Verzeichnis ein "+ git " - Repo initialisieren, wie wir es auf unserem lokalen System getan haben. Auf unseren Servern wird jedoch die Option " - Bare " hinzugefügt. Dadurch wird ein " git " - Repository ohne Arbeitsverzeichnis erstellt. Stattdessen wird der Inhalt, der normalerweise in einem " .git +" - Verzeichnis versteckt ist, in den Hauptordner gestellt:

git init --bare

Wir werden als nächstes einen + post-receive + Hook einrichten. Dies ist nur ein Skript, das Ihre Änderungen nach einem "+ git push" bereitstellt. Weitere Informationen zu dieser Bereitstellungsstrategie finden Sie unter https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks#using-git- Hooks für die Bereitstellung auf einem separaten Produktionsserver [diese Anleitung]. Wir sollten dieses Skript in das + hooks + Verzeichnis unseres Repos stellen. Erstellen und öffnen Sie die Datei, indem Sie Folgendes eingeben:

nano hooks/post-receive

Fügen Sie im Inneren das folgende Bereitstellungsskript ein. Dies ist im Grunde das gleiche Skript, das im oben verlinkten Artikel beschrieben ist. Wir verwenden eine "+ GIT_DIR " - Variable, um unser " git " - Repo auf dem Server anzuzeigen, die " WORK_TREE " - Variable, um unseren Apache-Dokumentenstamm anzugeben, und " HOSTNAME ", um den Hostnamen unseres Servers für Fortschrittsmeldungen abzurufen. Dieses Skript stellt alle Änderungen in der Verzweigung " master +" im Webverzeichnis bereit. Im folgenden Skript sollten keine Änderungen erforderlich sein:

/ home / deploy / sample_app / hooks / post-receive

#!/bin/bash

GIT_DIR=/home/deploy/sample_app
WORK_TREE=/var/www/html
HOSTNAME=$(hostname)

while read oldrev newrev ref
do
   if [[ $ref =~ .*/master$ ]];
   then
       echo "Master ref received.  Deploying master branch to $HOSTNAME..."
       git --work-tree=$WORK_TREE --git-dir=$GIT_DIR checkout -f
       echo "Git hooks deploy complete."
   else
       echo "Ref $ref successfully received.  Doing nothing: only the master branch may be deployed on this server."
   fi
done

Wenn Sie von diesem Handbuch abweichen und komplexere Bereitstellungsschritte benötigen, fügen Sie diese der Klausel "+ then " im obigen Skript hinzu. Stellen Sie sicher, dass alle Schritte, für die erhöhte Berechtigungen in diesem Abschnitt erforderlich sind, den Befehl ` sudo ` verwenden. Stellen Sie außerdem sicher, dass alle Befehle, die hier " sudo " verwenden, der " sudoers +" - Datei hinzugefügt werden, wie am Ende des letzten Abschnitts angegeben.

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

Ändern Sie die Berechtigungen für den Hook "+ post-receive ", damit " git +" ihn zum richtigen Zeitpunkt ausführen kann:

chmod +x hooks/post-receive

Konfigurieren Sie den SSH-Schlüsselzugriff auf den blauen und grünen Servern

Als nächstes werden wir SSH-Schlüssel so konfigurieren, dass "+ git +" Änderungen auf unsere Webserver pushen kann, ohne nach einem Passwort zu fragen.

Erstellen oder Anzeigen Ihres öffentlichen Schlüssels auf Ihrem Entwicklungscomputer

Überprüfen Sie auf Ihrem * lokalen oder Entwicklungscomputer *, ob Sie bereits einen SSH-Schlüssel konfiguriert haben, indem Sie Folgendes eingeben:

cat ~/.ssh/id_rsa.pub

Wenn Sie bereits über ein SSH-Schlüsselpaar verfügen, sollte Folgendes angezeigt werden:

Outputssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDilFdzkgBcSKdh6tx5pLf+HH6Pv7z7jRZ7cSo6lQvecWOOgGl/wHCVZWx1ULvrF7VgJpgugLwxYsFh3E39sm1+7zeAlRxhFrbWvATwpAEwh5m0+48LTmvXCnJ8/om+GfmAwplmzGk/DNs5trVeagG62Css0rypdoNuLrVdCVKUXGXbO6KnpOsBqoM2HvZKtQ8j1gx+1UUnvK9LYes+ZzC2XZZeBh2dGABe7HNnd8+6e1f2ZjPEKAEV2fPJGAGaAQOnzSKJkUt/B9PdKFbCjnnG1sT0kQoxMRIAiqfR7wa7PUQCM5Orm5S92OTNcnRr8bWVjN18bWCyXkpxxWbIvVU/ user@devel

Wenn der Befehl korrekt ausgeführt wird, kopieren Sie den gesamten angezeigten Text. Wir werden dies im nächsten Abschnitt verwenden. Sie können jetzt sicher dorthin springen.

Wenn Sie * keine * SSH-Schlüssel auf Ihrem lokalen Computer haben, sehen Sie wahrscheinlich einen Fehler, der so aussieht:

Outputcat: /home/user/.ssh/id_rsa.pub: No such file or directory

In diesem Fall können Sie ein neues öffentliches und privates Schlüsselpaar erstellen, indem Sie Folgendes eingeben:

ssh-keygen

Drücken Sie bei allen Eingabeaufforderungen die EINGABETASTE, um die Standardwerte zu akzeptieren. Wenn die Schlüssel erstellt wurden, geben Sie den Befehl + cat + erneut ein, um den neuen öffentlichen Schlüssel anzuzeigen:

cat ~/.ssh/id_rsa.pub

Dies sollte diesmal korrekt ausgeführt werden. Kopieren Sie die angezeigten Zeilen, um sie im nächsten Abschnitt zu verwenden.

Fügen Sie dem Bereitstellungsbenutzer auf den grünen und blauen Servern Ihren öffentlichen SSH-Schlüssel hinzu

Zurück auf Ihren grünen und blauen Servern, werden wir Ihr Konto auf unserem lokalen oder Entwicklungscomputer autorisieren, um eine Verbindung zu unseren "+ deploy" -Benutzern herzustellen.

Erstellen Sie als Benutzer "+ deploy " ein " ~ / .ssh " -Verzeichnis. Öffne eine Datei mit dem Namen " authorized_keys +":

mkdir ~/.ssh
nano ~/.ssh/authorized_keys

Fügen Sie in diese Datei die Ausgabe ein, die Sie von Ihrem lokalen Computer kopiert haben:

~ / .ssh / authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDilFdzkgBcSKdh6tx5pLf+HH6Pv7z7jRZ7cSo6lQvecWOOgGl/wHCVZWx1ULvrF7VgJpgugLwxYsFh3E39sm1+7zeAlRxhFrbWvATwpAEwh5m0+48LTmvXCnJ8/om+GfmAwplmzGk/DNs5trVeagG62Css0rypdoNuLrVdCVKUXGXbO6KnpOsBqoM2HvZKtQ8j1gx+1UUnvK9LYes+ZzC2XZZeBh2dGABe7HNnd8+6e1f2ZjPEKAEV2fPJGAGaAQOnzSKJkUt/B9PdKFbCjnnG1sT0kQoxMRIAiqfR7wa7PUQCM5Orm5S92OTNcnRr8bWVjN18bWCyXkpxxWbIvVU/ user@devel

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

Sperren Sie als Nächstes die Berechtigungen, damit SSH die von Ihnen erstellte Datei verwenden kann:

chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

Konfigurieren Sie Git Remotes auf dem lokalen Entwicklungscomputer

Nachdem wir den SSH-Schlüsselzugriff auf unsere Webserver konfiguriert und unser Anwendungsverzeichnis auf jedem Server eingerichtet haben, können wir unsere blauen und grünen Server als Remotes in unserem lokalen App-Repository hinzufügen.

Wechseln Sie auf Ihrem lokalen Computer zurück in Ihr Anwendungsverzeichnis:

cd ~/sample_app

Fügen Sie Remote-Referenzen hinzu, damit "+ git +" Änderungen auf Ihre grünen und blauen Webserver übertragen kann:

git remote add blue deploy@:sample_app
git remote add green deploy@:sample_app

Wir sollten nun in der Lage sein, unsere App auf beide Server zu übertragen. Probieren Sie es aus, indem Sie Version 1 unserer Anwendung auf beide Server übertragen.

git push blue master
git push green master

Möglicherweise müssen Sie bei der ersten Bereitstellung den Schlüsselfingerabdruck jedes Servers akzeptieren. Sie sollten eine Ausgabe sehen, die ungefähr so ​​aussieht:

OutputThe authenticity of host '111.111.111.111 (111.111.111.111)' can't be established.
ECDSA key fingerprint is 30:a1:2c:8b:ec:98:a3:3c:7f:4a:db:46:2b:96:b5:06.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added '111.111.111.111' (ECDSA) to the list of known hosts.
Counting objects: 3, done.
Writing objects: 100% (3/3), 246 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Master ref received.  Deploying master branch to blue...
remote: Git hooks deploy complete.
To [email protected]:sample_app
* [new branch]      master -> master

Wie Sie sehen können, enthalten die Zeilen, die mit "remote:" beginnen, die "+ echo " - Anweisungen vom " post-receive +" - Hook auf unserem Server. Denken Sie daran, Ihre App auf beide Server zu übertragen.

Wir können testen, ob die anfängliche Bereitstellung unserer App mit curl erfolgreich war:

curl
curl

Für beide Aufrufe sollte die Antwort wie folgt lauten:

OutputApp v1

Dies zeigt an, dass unser Bereitstellungsskript ordnungsgemäß funktioniert.

Festlegen einer Floating-IP-Adresse zum Weiterleiten des Datenverkehrs

Nachdem wir die erste Version unserer Anwendung bereitgestellt haben, können wir eine Floating-IP-Adresse erstellen und diese zunächst auf unseren „grünen“ Server verweisen.

Klicken Sie in der DigitalOcean-Systemsteuerung auf die Registerkarte "Netzwerk" und dann auf den Menüpunkt "Floating IPs". Wählen Sie im angezeigten Menü Ihren grünen Server aus und klicken Sie auf die Schaltfläche "Floating IP zuweisen":

image: https://assets.digitalocean.com/articles/blue_green_deployment/create_ip.png [DigitalOcean erstellt Floating IP]

Nach ein paar Sekunden sollte die IP Ihrem grünen Server zugewiesen werden:

image: https: //assets.digitalocean.com/articles/blue_green_deployment/assigned_ip.png [DigitalOcean Floating IP zugewiesen]

Sie können diese IP-Adresse jetzt als primären Einstiegspunkt in die Bereitstellung Ihrer Produktionsanwendung verwenden. Wenn Sie einen Domainnamen für Ihre Web-App einrichten möchten, verweisen Sie die Domain auf diese Floating-IP-Adresse.

Testen Sie, ob Ihre Anwendung über die Floating-IP-Adresse erreichbar ist, indem Sie Folgendes eingeben:

curl

Sie sollten Version 1 Ihrer Anwendung sehen:

OutputApp v1

Der grüne Server liefert derzeit diese Antwort.

Üben der blaugrünen Bereitstellung

Nachdem unsere Konfiguration abgeschlossen ist, können wir demonstrieren, wie die blaugrüne Bereitstellung in der Praxis funktioniert. Derzeit verweist unsere Floating IP-Adresse auf unseren grünen Server. Wie bereits erwähnt, stellt die Floating-IP-Adresse den Produktionsverkehr dar und ist der Ort, an dem wir den Domain-Namen unserer Anwendung anhängen würden.

Anwendungsänderungen vornehmen

Auf Ihrem lokalen Computer oder Entwicklungscomputer können wir einige Änderungen an unserer Anwendung vornehmen. Öffnen Sie die Indexdatei:

cd ~/sample_app
nano index.html

Nehmen Sie eine einfache, sichtbare Änderung an unserer Anwendung vor, indem Sie die Versionsnummer erhöhen:

~ / sample_app / index.html

App v2

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

Fügen Sie die Datei zum Staging-Bereich "+ git +" hinzu und bestätigen Sie Ihre Änderungen, indem Sie Folgendes eingeben:

git add .
git commit -m "Application version 2"

Push in die nicht aktive Umgebung

Als Nächstes können wir unsere neuen Änderungen in unserer nicht aktiven Umgebung vornehmen. Dies gibt uns die Möglichkeit, unsere Bereitstellung zu testen, ohne dass sich dies auf unseren Produktionsserver auswirkt.

Da unsere Floating-IP-Adresse derzeit auf unsere grüne Umgebung verweist, stellen wir sie auf unserem blauen Server bereit. Übertragen Sie die neuen Änderungen in die blaue Umgebung, indem Sie Folgendes auf Ihrem lokalen Entwicklungscomputer eingeben:

git push blue master

Wenn wir unsere * Floating IP-Adresse * besuchen, sollten wir feststellen, dass Version 1 unserer Anwendung noch bedient wird:

curl
OutputApp v1

Wenn wir jedoch die reguläre IP-Adresse unseres * blauen Servers * überprüfen, können wir Version 2 unserer Anwendung testen:

curl
OutputApp v2

Das erwarten wir und wollen wir. Wir können jetzt unsere blaue Serverumgebung durch beliebige interne Tests ausführen, die wir benötigen. Währenddessen wird der grüne Server weiterhin unseren Produktionsverkehr bedienen.

Umdrehen der Produktion in die neue Umgebung

Sobald Sie die neueste Version Ihrer Anwendung getestet haben und sicher sind, dass sie erwartungsgemäß funktioniert, können wir den Produktionsdatenverkehr auf den blauen Server umstellen.

Am einfachsten ist es, das DigitalOcean-Bedienfeld aufzurufen. Klicken Sie auf die Registerkarte "Netzwerk" und wählen Sie den Navigationspunkt "Floating IPs". In der Liste "Floating IPs" sollten Sie Ihre Floating IP sehen, die derzeit auf den grünen Server zeigt:

image: https://assets.digitalocean.com/articles/blue_green_deployment/assigned_ip.png [DigitalOcean Floating IP zugewiesen]

Bevor wir umschalten, starten Sie in einem Ihrer Terminalfenster eine "+ while" -Schleife, damit wir wiederholte Anfragen über die Floating-IP-Adresse stellen können. Auf diese Weise können wir den Übergang unserer Produktionsanwendungsversion von Version 1 zu Version 2 sofort sehen:

while true; do curl ; sleep 2; done

Es sollte beginnen, die Ergebnisse der Webanfragen auszugeben:

OutputApp v1
App v1
App v1
App v1

Um den Switch zu aktivieren und die neue Version Ihrer Software freizugeben, klicken Sie auf die blaue Schaltfläche auf der rechten Seite der Floating IP-Zuweisung, um die IP-Adresse neu zuzuweisen. Wählen Sie Ihren blauen Server:

image: https://assets.digitalocean.com/articles/blue_green_deployment/reassign_ip.png [IP-Adresse von DigitalOcean neu zuweisen]

In wenigen Sekunden wird Ihre Floating IP Ihrem blauen Server neu zugewiesen. In Ihrem Terminalfenster sollte die Umstellung offensichtlich sein:

OutputApp v1
App v1
App v2
App v2

Stoppen Sie die "+ while +" - Schleife, indem Sie "STRG-C" drücken.

Ihr Produktionsdatenverkehr wird jetzt an die neue Version Ihrer Anwendung weitergeleitet. Ihr vorheriger Produktionsserver, der grüne Server, ist jetzt sowohl als Rollback-Computer als auch als nächster Staging-Bereich eingerichtet.

Wenn Sie nach der Umstellung des Datenverkehrs auf die neue Anwendungsversion ein Problem feststellen, können Sie mit dieser Freigabestrategie schnell und problemlos auf die vorherige Version zurücksetzen. Um dies zu tun, kehren Sie einfach den Vorgang um und verweisen Sie Ihre Floating-IP-Adresse zurück auf den grünen Server.

Umgang mit Datenbank-Updates

Das oben beschriebene Szenario wurde vereinfacht, um sich auf die Bereitstellungs- und Freigabestrategie selbst zu konzentrieren. Wir haben uns jedoch nicht mit komplexeren, sondern mit gängigen Setups befasst, z. B. mit Datenbanken.

Es gibt verschiedene Strategien, mit denen Sie die persistenten Daten zwischen Ihren beiden Umgebungen verarbeiten können.

Es ist möglich, für jede Ihrer Umgebungen eine separate Datenbank zu verwalten. Diese Strategie würde jedoch erfordern, dass Sie die Daten in der Produktionsdatenbank in die inaktive Datenbank replizieren und Transaktionen in den Momenten stoppen, in denen Sie einen Wechsel einleiten. Grundsätzlich würde eine Live-Datenbankmigration sowie einige Momente der Ausfallzeit bei jeder Bereitstellung erforderlich sein. Dies kann schnell sehr zeitaufwändig und fehleranfällig werden.

Eine bessere Alternative ist normalerweise die gemeinsame Nutzung eines einzelnen Datenbanksystems zwischen der grünen und der blauen Umgebung. Der Anwendungscode kann mithilfe der blau-grünen Freigabestrategie geändert werden, während die Datenbank selbst von beiden Umgebungen verwendet wird.

Bei diesem Ansatz geht es hauptsächlich darum, wie Updates bereitgestellt und freigegeben werden, die nicht abwärtskompatible Datenbankmigrationen enthalten. Wenn wir eine neue Version für das Staging bereitstellen, die die Datenbank auf eine Weise erweitert oder verändert, die mit der aktuellen Produktionsbereitstellung nicht funktioniert, wird unsere Anwendung beschädigt.

Um dies zu verhindern, ist es häufig am besten, die Migrationen getrennt von den Codebasisbereitstellungen und nach Bedarf schrittweise bereitzustellen. Dieser geänderte Prozess wird manchmal als blue-turquoise-green deployment bezeichnet. Grundsätzlich hängt es von der Bereitstellung einer Zwischenversion Ihres Anwendungscodes ab, die sowohl die alte als auch die neue Version Ihrer Datenbank verarbeiten kann.

Der Code der Zwischenanwendung ist fast identisch mit der älteren Version, verfügt jedoch über eine zusätzliche Logik, die ihn auf die neuen Datenstrukturen vorbereitet, die nach der Migration vorhanden sein werden. Dies wird häufig dadurch erreicht, dass die Migrationen so konstruiert werden, dass sie vollständig neue Datenstrukturen erzeugen, anstatt vorhandene zu ändern. Auf diese Weise können Sie die alte Datenstruktur beibehalten, beispielsweise eine Tabelle, und eine neue erstellen, die die wichtigsten Änderungen enthält.

Das Intermediate Turquoise Deployment wird als erster Schritt im Migrationsprozess bereitgestellt. Diese Bereitstellung liest zunächst aus der alten Tabelle und schreibt in diese, prüft jedoch, ob die neue Struktur vorhanden ist. Als Nächstes wird die Migration selbst ausgeführt und neben der alten Version die neue Version der Datenstruktur erstellt. Die türkisfarbene Bereitstellungslogik sollte so konfiguriert sein, dass erkannt wird, dass die neue Struktur vorhanden ist, und Änderungen an der alten Struktur und der neuen Struktur geschrieben werden. Es wird vorerst weiter aus der alten Struktur gelesen.

Zu diesem Zeitpunkt werden alle neuen Aktivitäten in beiden Datenstrukturen aufgezeichnet. Sie können die neue Struktur mit den Daten aus der alten Struktur füllen und sie auf dem Weg dahin transformieren, um die Bedingungen der neuen Struktur zu erfüllen. Wenn dies abgeschlossen ist, sollten alle Ihre Datensätze an beiden Standorten vorhanden sein. Um den Übergang fortzusetzen, schreibt die nächste Anwendungsbereitstellung möglicherweise weiterhin in beide Strukturen, liest jedoch möglicherweise aus der neuen Struktur. Nachdem bestätigt wurde, dass alles reibungslos funktioniert, werden bei einer anderen Bereitstellung möglicherweise Schreibvorgänge von der alten Struktur abgeschnitten und die alte Struktur wird möglicherweise gelöscht.

Dieser Prozess kann auf den ersten Blick ziemlich kompliziert erscheinen, in der Praxis ist er jedoch in der Regel nicht zu aufwändig. Die Hauptarbeit besteht darin, ein Sicherheitsnetz zu bauen, das sowohl das Erbe als auch die neuen Strukturen vorübergehend nutzt. Auf diese Weise haben Sie Zeit, Ihre Migrationen vor dem Festschreiben eingehend zu testen, und können jederzeit ein Rollback auf die vorherige Arbeitsversion Ihrer Datenstruktur durchführen. Ein Beispiel dafür, wie diese Datenmigration stattfinden könnte, finden Sie unter these slides von Mike Brittain bei Etsy.

Fazit

Zwar gibt es viele andere Strategien, mit denen Sie die Bereitstellung von der eigentlichen Version Ihres neuen Codes trennen können, die blaugrüne Bereitstellung ist jedoch ein recht einfacher Mechanismus, der sich schnell implementieren lässt. Es bietet eine gute Staging-Umgebung, die die Produktionsumgebung vollständig widerspiegelt, und bietet nach einer Veröffentlichung sofortige Rollback-Möglichkeiten, wenn die Dinge nicht wie erwartet liefen.

Related