Einleitung: Das letzte Puzzlestück zusammenfügen

Hallo! Endlich ist der letzte Teil dieser langen Serie da. In den letzten 4 Teilen haben wir mit den Theorien eines automatischen Bereitstellungssystems begonnen, die Kernlogik des FastAPI Webhook-Servers implementiert und eine stabile Betriebsumgebung mit einem Systemd-Dienst aufgebaut.

Die vorherigen Beiträge dieser Serie können über die folgenden Links aufgerufen werden.

① Warum selbst implementieren?

② Gesamtarchitektur und Prozessdesign

③ Einrichtung der Staging-Serverumgebung und grundlegender Aufbau des FastAPI Webhook-Servers

④ Details zu Verteilungshandlern und Registrierung des Systemd-Dienstes

Doch es bleibt noch ein Schritt übrig. Derzeit läuft unser FastAPI Webhook-Server nur auf Port 8000 und nutzt kein HTTPS, was Sicherheitsrisiken birgt. Außerdem empfiehlt GitHub dringend, öffentliche Domains mit HTTPS zu verbinden.

In diesem 5. Teil werden wir die letzten Puzzlestücke zusammenfügen, indem wir Nginx als Reverse Proxy einrichten, um den FastAPI-Server sicher nach außen zu exponieren, dann kostenloses HTTPS über Let's Encrypt anwenden und schließlich GitHub Webhooks integrieren, um das automatische Bereitstellungssystem zu vervollständigen.

Moment, warum Nginx und nicht Apache2? Apache2 und Nginx sind hervorragende Webserver, die sich den Server-Anwendungsmarkt teilen. Aber asynchrone Web-Frameworks wie FastAPI funktionieren besser mit Nginx. Nginx ist asynchron und ereignisorientiert konzipiert, was die asynchrone Leistung von FastAPI in Umgebungen mit hohen gleichzeitigen Verbindungen maximieren kann. Aus diesem Grund empfiehlt die FastAPI-Community Nginx als Webserver für Produktionsumgebungen und dieser Artikel erklärt alles im Kontext von Nginx.

Nginx installieren und Reverse Proxy einrichten

Warum sollte man Nginx verwenden?

  1. Reverse Proxy: Anwendungserver wie FastAPI sind nicht dafür gedacht, externen Datenverkehr direkt zu empfangen. Nginx fungiert als Reverse Proxy, der Webhook-Anfragen empfängt und sicher an den FastAPI-Server weiterleitet.

  2. Sicherheit: Nginx bietet verschiedene Sicherheitskonfigurationen und DDoS-Schutzfunktionen.

  3. HTTPS-Anwendung: Die Verwaltung und Anwendung von HTTPS-Zertifikaten obliegt Webservern wie Nginx.

Nginx installieren und konfigurieren

Greifen Sie über SSH auf den Staging-Server zu, um Nginx zu installieren. Ich gehe davon aus, dass die Leser dieses Artikels bereits über ein gewisses Maß an Erfahrung und Wissen mit Nginx verfügen, sodass ich detaillierte Erklärungen zur Installationsmethode, Dateistruktur oder Funktionsweise hier weglassen werde.

sudo apt update
sudo apt install -y nginx
sudo systemctl enable nginx # beim Neustart automatisch starten
sudo systemctl start nginx # Nginx starten
sudo systemctl status nginx # Aktuellen Status überprüfen

Jetzt erstellen wir die Nginx-Konfigurationsdatei, um Anfragen an unseren FastAPI Webhook-Server weiterzuleiten. Angenommen, wir verwenden die Domain deployer.example.com. Hier ist ein Beispiel der Konfiguration.

#/etc/nginx/sites-available/deployer.example.com

# HTTP-Anfragen auf HTTPS 308 umleiten
server {
    listen 80;
    server_name deployer.example.com;
    return 308 https://$host$request_uri;
}

# Verarbeitung von HTTPS-Anfragen
server {
    listen 443 ssl;
    server_name deployer.example.com;

    # Pfad des SSL-Zertifikats festlegen
    ssl_certificate /etc/letsencrypt/live/deployer.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/deployer.example.com/privkey.pem;
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 5m;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect off;
    }
}

  • Einstellungen für Port 80 (HTTP): Der Block listen 80 mit server_name gleich deployer.example.com leitet alle eingehenden HTTP-Anfragen permanent über den Befehl return 308 https://$host$request_uri; auf HTTPS um.

  • Einstellungen für Port 443 (HTTPS): Der Block listen 443 ssl; behandelt HTTPS-Anfragen.

  • ssl_certificate & ssl_certificate_key: Dies wird angenommen, dass es bereits über Let's Encrypt beantragt wurde. In diesem Block geben wir den Pfad zum erhaltenen SSL-Zertifikat und zur Schlüsseldatei an. Dieser Pfad wird automatisch erstellt, wenn certbot das Zertifikat ausstellt.

  • location / Block: Dieser konfiguriert einen Reverse Proxy, um HTTPS-Anfragen an unseren FastAPI-Server (http://127.0.0.1:8000) weiterzuleiten.

Wenn Sie Nginx mit dieser Konfigurationsdatei neu starten, werden alle Webhook-Anfragen sicher über HTTPS verarbeitet.

# Erstellt einen symbolischen Link zur Konfigurationsdatei im Verzeichnis sites-enabled
sudo ln -s /etc/nginx/sites-available/deployer.example.com /etc/nginx/sites-enabled/

# Überprüfen Sie die Nginx-Konfigurationsdatei auf Syntaxfehler.
sudo nginx -t

# Starten Sie Nginx neu, um die Änderungen anzuwenden.
sudo systemctl restart nginx

HTTPS-Anwendung (Let's Encrypt + Certbot)

GitHub Webhooks empfehlen aus Sicherheitsgründen dringend die Verwendung von HTTPS. Let's Encrypt ist eine gemeinnützige Zertifizierungsstelle, die es jedem ermöglicht, kostenlos SSL/TLS-Zertifikate zu beziehen, und Certbot ist ein hervorragendes Tool zur Automatisierung der Ausstellung und Erneuerung von Zertifikaten. Hier werde ich die Installationsmethode weglassen.

Wenn alles erfolgreich abgeschlossen ist, besuchen Sie https://deployer.example.com in Ihrem Browser, um auf die API-Dokumentation von FastAPI (.../docs) oder den / Endpunkt zuzugreifen. Wenn Sie die Nachricht Webhook server is running! sehen, wurde die Nginx- und HTTPS-Konfiguration erfolgreich abgeschlossen.

Letzte Integration und Test des GitHub Webhooks

Jetzt sind alle Vorbereitungen abgeschlossen. Lassen Sie uns das von uns aufgebaute automatische Bereitstellungssystem mit dem GitHub-Repository verbinden.

  1. Zugriff auf das GitHub-Repository: Navigieren Sie zum GitHub-Repository des Projekts, auf das die automatische Bereitstellung angewendet werden soll.

  2. Webhook-Einstellung: Klicken Sie im oberen Menü auf Settings -> Klicken Sie im linken Menü auf Webhooks.

  3. Webhook hinzufügen: Klicken Sie auf die Schaltfläche Add webhook und geben Sie die folgenden Informationen ein.

    • Payload URL: Geben Sie die Adresse des Webhook-Servers mit Nginx und HTTPS ein. (z.B. https://deployer.example.com/webhook)

    • Content type: Wählen Sie application/json.

    • Secret: Kopieren Sie den Wert des GITHUB_WEBHOOK_SECRET, den Sie im 3. Teil in der ~/projects/webhook_server/.env-Datei festgelegt haben, genau und fügen Sie ihn ein.

    • Welche Ereignisse möchten Sie auslösen, um diesen Webhook zu aktivieren?: Wählen Sie Just the push event.

    • Aktiv: Überprüfen Sie, ob das Kästchen aktiviert ist.

  4. Speichern: Klicken Sie auf die Schaltfläche Add webhook, um den Webhook zu speichern.

GitHub Webhook Einstellungs-Screenshot

Wenn der Webhook erfolgreich registriert ist, sehen Sie im Abschnitt Recent Deliveries ein grünes Häkchen, welches bestätigt, dass die Testanfrage erfolgreich gesendet wurde.

Lassen Sie uns nun einen letzten Test durchführen.

  1. Änderung des Codes lokal: Ändern Sie den Code des Projekts, machen Sie einen Commit in Git und pushen Sie es.

  2. Überprüfen des Status:

    • Überprüfen Sie in der Seite der Webhook-Einstellungen auf GitHub im Recent Deliveries, ob der kürzlich gesendete Push erfolgreich war (grünes Häkchen).

    • Greifen Sie per SSH auf den Staging-Server zu und überprüfen Sie die Echtzeitprotokolle mit dem Befehl sudo journalctl -u github-webhook-deployer.service -f. Wenn Sie Nachrichten wie Git pull successful, Deployment task finished sehen, war es ein Erfolg.

    • Überprüfen Sie den Status des bereitgestellten Docker-Containers, um zu validieren, dass der neueste Code erfolgreich angewendet wurde.

Abschluss: Automatisches Bereitstellungssystem vollständig!

Herzlichen Glückwunsch! Sie haben erfolgreich eine vollständige CI/CD-Pipeline von der lokalen Entwicklungsumgebung über GitHub bis hin zu Ihrem selbst aufgebauten Staging-Server aufgebaut.

In dieser Serie haben wir Folgendes getan:

  • Wir haben verstanden, warum es notwendig ist, ein selbstgestaltetes Webhook-basiertes automatisches Bereitstellungssystem aufzubauen.

  • Wir haben die Architektur des Webhook-Servers mit FastAPI entworfen und implementiert.

  • Wir haben gelernt, wie man Dienste stabil mit Systemd betreibt.

  • Wir haben die Sicherheit mit Nginx und HTTPS-Einstellungen verbessert.

  • Und zuletzt haben wir alles automatisiert, indem wir mit GitHub verbunden haben.

Jetzt wird Ihr Server automatisch den neuesten Code widerspiegeln, ohne dass Sie eingreifen müssen, sobald Sie Code pushen. Nutzen Sie dieses System, um komplexere Bereitstellungslogik hinzuzufügen oder Benachrichtigungsfunktionen zu integrieren und entwickeln Sie es nach Ihren Wünschen weiter.

Vielen Dank, dass Sie diesen langen Weg mit uns gegangen sind!