In einem , den ich vor einem Monat geschrieben habe, habe ich darüber gesprochen, wie Sie Ihre Python-Webanwendung kontinuierlich in einer Produktionsumgebung (oder vor der Entwicklung/Staging) bereitstellen. Artikel Informationen zum Bereitstellen Ihrer Anwendung in einer anderen Sprache finden Sie im vorherigen Artikel. Stellen Sie einfach sicher, dass Sie die Workflow-Datei ändern. Ich wurde kürzlich damit beauftragt, einen Microservice (mit Python und FastAPI) zu erstellen, um zwei Stimmen abzugleichen und einen Vorhersagewert zu geben, ob beide übereinstimmen oder nicht. Die Beteiligten hatten eine Funktion zum Entsperren per Sprachbefehl gefordert. Wir hatten ein technisches Meeting und ich bin aufgestanden, um die Aufgabe zu übernehmen (oder mein Vorgesetzter hat sich für mich eingesetzt, haha). Es war eine interessante Aufgabe, da ich noch nie zuvor mit einem ML-Modell gearbeitet (trainiert oder so) habe. Ich habe eine Woche gebraucht, um den Code zu entwerfen, zu erstellen und an eine AWS EC2-Instanz zu senden. Ich bin ein großer Fan von CI/CD, daher habe ich das verwendet, womit ich mich am wohlsten fühlte: GitHub Actions. Eine Woche später ... wurden Änderungen angefordert und ich wollte eine neue [Bereitstellungs-]Technik ausprobieren, die ich erforscht hatte. Ich wollte, dass die Docker-Microservice-Anwendung ordnungsgemäß auf der AWS EC2-Instanz läuft, damit es bei der erneuten Bereitstellung nicht zu Ausfallzeiten kommt. Und ich hatte den perfekten Trick im Ärmel. Dieser Trick ist: . die Blau-Grün-Technik Laut AWS-Whitepaper zu Blue/Green-Bereitstellungen handelt es sich um eine Bereitstellungsstrategie, bei der Sie zwei separate, aber identische Umgebungen erstellen. In einer Umgebung (blau) wird die aktuelle Anwendungsversion ausgeführt und in einer Umgebung (grün) wird die neue Anwendungsversion ausgeführt. Die Verwendung einer Blau/Grün-Bereitstellungsstrategie erhöht die Anwendungsverfügbarkeit und verringert das Bereitstellungsrisiko, indem der Rollback-Prozess vereinfacht wird, wenn eine Bereitstellung fehlschlägt. Sobald die Tests in der grünen Umgebung abgeschlossen sind, wird der Live-Anwendungsverkehr an die grüne Umgebung weitergeleitet und die blaue Umgebung wird nicht mehr unterstützt. Einfach ausgedrückt ist die Blau/Grün-Bereitstellungstechnik eine Möglichkeit, Ausfallzeiten und Risiken zu reduzieren, indem zwei identische Produktionsumgebungen ausgeführt werden. Wenn Sie zum ersten Mal eine solche Bereitstellungstechnik hören, gibt es absolut nichts zu befürchten. Ich werde Ihnen detaillierte Schritte geben, die Ihnen dabei helfen, eine blau-grüne Bereitstellung zu erreichen. Wir werden als Beispiel ein imaginäres Produkt verwenden, da ich aus NDA-Gründen die Bereitstellungsschritte nicht mit dem Produkt durchlaufen möchte, das ich für mein Unternehmen erstellt habe. Haha. Kommen wir gleich zu den Schritten: Erstellen Sie zunächst ein neues Docker-Image mit Ihrem aktualisierten Code und kennzeichnen Sie es mit einer neuen Versionsnummer. $ docker build -t myexample:v2 . Dadurch wird ein neues Docker-Image mit dem Tag unter Verwendung der im aktuellen Verzeichnis erstellt. myexample:v2 Dockerfile Dabei der Name des neu erstellten Docker-Images. In meinem Fall war es der Name des ML-Projekts. Beispiel: myexample:v2 docker build -t companyx-servicename-backend:v2 Starten Sie einen neuen Docker-Container mit dem neuen Image, aber machen Sie ihn noch nicht der Außenwelt zugänglich. $ docker run -d --name myexample-v2 myexample:v2 Dadurch wird ein neuer Docker-Container mit dem Namen aus dem -Image gestartet. myexample-v2 myexample:v2 Warten Sie, bis der neue Container gestartet und initialisiert ist, und stellen Sie sicher, dass er ordnungsgemäß funktioniert. $ docker logs myexample-v2 Verwenden Sie den Befehl docker logs, um die Protokolle des neuen Containers zu überprüfen, um sicherzustellen, dass er ordnungsgemäß gestartet und initialisiert wurde. Verwenden Sie einen Reverse-Proxy wie NGINX, um den Datenverkehr sowohl an den alten als auch an den neuen Container weiterzuleiten. Konfigurieren Sie Ihren Reverse-Proxy so, dass er auf Anfragen wartet und diese sowohl an den alten als auch an den neuen Container weiterleitet. Dadurch können Sie den Datenverkehr schrittweise auf den neuen Container verlagern. Hier ist ein Beispiel für eine NGINX-Konfiguration, die zwei Container weiterleitet: upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } } Diese Konfiguration richtet eine Upstream-Gruppe namens myexample mit zwei Servern ein: und . Das Schlüsselwort wird verwendet, um den zweiten Server als Backup zu markieren. Die Direktive wird verwendet, um Anfragen an die Upstream-Gruppe weiterzuleiten. myexample-v1 myexample-v2 backup proxy_pass myexample Stellen Sie sicher, dass Sie die Reverse-Proxy-Konfiguration aktualisieren, um den Namen und Port Ihrer Anwendung widerzuspiegeln. Verlagern Sie den Datenverkehr schrittweise vom alten Container auf den neuen Container, indem Sie die Reverse-Proxy-Konfiguration anpassen. Um den Datenverkehr auf den neuen Container zu verlagern, passen Sie die Reverse-Proxy-Konfiguration an, um dem neuen Container mehr Gewicht zu verleihen. Dies kann durch Entfernen des Schlüsselworts „backup“ aus der Serveranweisung erreicht werden: upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } } Dies führt dazu, dass NGINX mehr Anfragen an den Container sendet. Überwachen Sie Ihre Anwendung und passen Sie die Konfiguration nach Bedarf an, bis der gesamte Datenverkehr in den neuen Container fließt. myexample-v2 Sobald der gesamte Verkehr zum neuen Container fließt, können Sie den alten Container sicher anhalten und entfernen. $ docker stop myexample-v1 $ docker rm myexample-v1 Dadurch wird der alte Container angehalten und entfernt, wodurch Ressourcen auf dem Server freigegeben werden. Abschluss Wenn Ihre Anwendung auf einer relationalen Datenbank basiert, kann die Blau-Grün-Bereitstellungsstrategie dazu führen, dass bei Aktualisierungen Inkonsistenzen zwischen der blauen und der grünen Datenbank auftreten. Um ein Höchstmaß an Datenintegrität zu gewährleisten, wird empfohlen, eine einheitliche Datenbank einzurichten, die sowohl mit früheren als auch mit zukünftigen Versionen kompatibel ist. Ich bin neu in dieser Technik und weiß offensichtlich nicht viel darüber. Aber ich werde weiterhin etwas über die Kompromisse und andere Techniken lernen, die besser funktionieren. Hast du ein oder zwei Tricks im Ärmel, die du gerne mit mir teilen würdest? Ich werde es schätzen. Lass es mich haben (im Kommentarbereich). Oh, oh. Vergessen Sie nicht, meinen langweiligen Newsletter zu abonnieren. Ich habe seit dem ersten Quartal eine Menge gelernt und werde sie bald teilen. Ciao.
