Einleitung: Die Bedeutung von CI/CD und automatischer Bereitstellung

Automatische Bereitstellung, also CI/CD (Continuous Integration/Continuous Delivery), ist mittlerweile zu einer Notwendigkeit und nicht mehr zu einer Wahl geworden, um effiziente Entwicklungsabläufe zu erreichen. Wenn der Ablauf von Build-Test-Bereitstellung automatisch erfolgt, kann die Produktivität der Entwickler erheblich gesteigert werden.

Es gibt mehrere Möglichkeiten, solche automatischen Bereitstellungen zu implementieren, wobei die bekanntesten die Nutzung von GitHub Actions und die eigene Implementierung der Bereitstellungslogik über die Webhook-Funktion von GitHub sind.

Warum sollte man Webhook selbst implementieren statt GitHub Actions zu verwenden?

GitHub Kätzchen wirft ein Webhook-Papierflugzeug zu Tux

GitHub Actions ist zweifellos ein mächtiges und benutzerfreundliches CI/CD-Tool. Komplexe Workflows können mit wenigen Zeilen YAML-Dateien definiert und viele Prozesse wie Build, Testen und Bereitstellung über verschiedene Action-Marktplätze automatisiert werden. In den meisten Projekten ist GitHub Actions eine hervorragende Wahl.

Allerdings ist GitHub Actions nicht in allen Fällen die beste Wahl. Besonders für Entwickler in folgenden Situationen könnte die Implementierung über GitHub Webhook viel attraktiver sein.

  • Kostensensitive individuelle Entwickler oder kleine Teams: GitHub Actions ist für öffentliche Repositories nahezu unbegrenzt kostenlos, aber für private Repositories fallen Gebühren an, wenn die kostenlose Nutzung (Minuten und Speicher) überschritten wird. Wenn man unerwartete Kosten vermeiden möchte, ist die Eigenimplementierung die Lösung.

  • Entwickler, die einen eigenen Staging-Server wie Raspberry Pi 5 betreiben: Wenn Sie bereits einen physischen Server (einschließlich VPS oder Cloud-Instanzen) besitzen, ist es effizienter, die Ressourcen Ihres eigenen Servers zu nutzen, statt die virtuelle Umgebung (Runner) von GitHub auszuleihen. Es ist kosteneffizient, den Code direkt von Ihrem Server zu empfangen und bereitzustellen.

  • Entwickler, die vollständige Kontrolle und Freiheit über die Bereitstellungslogik wünschen: GitHub Actions verwendet standardisierte Workflows und Aktionen, während Sie bei der direkten Implementierung von Webhooks jedes Detail Ihres Bereitstellungsskripts nach Belieben gestalten und steuern können. Dies ist besonders vorteilhaft, wenn komplexe benutzerdefinierte Logik erforderlich ist, die auf bestimmte Umgebungen abgestimmt ist, oder wenn eine nahtlose Integration mit bereits bestehenden Pipelines erforderlich ist.

In dieser Serie werden wir speziell für diese Zielgruppe detailliert erläutern, wie man die Bereitstellungslogik auf dem eigenen Server mithilfe von GitHub Webhook implementiert. Wir richten uns an Python-Entwickler und werden in erster Linie das einfache, aber leistungsstarke Web-Framework FastAPI verwenden, um den Webhook-Endpunkt zu erstellen. DRF (Django REST Framework) ist auch eine ausgezeichnete Wahl, aber da wir hier eine sehr leichte Logik zur Verarbeitung der Webhook-Anfragen benötigen, glauben wir, dass FastAPI die beste Wahl ist. Man muss für den Einkauf im Supermarkt nicht unbedingt einen Sportwagen nehmen; ein Kleinwagen reicht völlig aus.

Vorbereitungen für den Aufbau eines automatischen Bereitstellungssystems

Die eigentliche Implementierung beginnt in der nächsten Folge. In dieser Folge habe ich eine Liste von Dingen zusammengestellt, die im Voraus vorbereitet werden müssen, um einen reibungslosen Ablauf zu gewährleisten.

  1. GitHub-Repository:

    • Sie benötigen ein GitHub-Repository, das Ihr Python-Projekt enthält, für das Sie die automatische Bereitstellung implementieren möchten. (Sowohl öffentlich als auch privat)

    • Die Bereitstellung wird jedes Mal gestartet, wenn Sie Code in dieses Repository pushen.

  2. Staging-Server (Eigene Server):

    • Sie benötigen einen Server, auf dem die tatsächliche Bereitstellung erfolgen soll. Raspberry Pi 5, persönlicher VPS (Virtual Private Server) oder Cloud-Instanzen (wie AWS EC2, GCP Compute Engine usw.) sind alle geeignet.

    • Er muss über eine öffentliche IP-Adresse oder Domain erreichbar sein, sodass externe Zugriffe (von GitHub) möglich sind. (Achten Sie auf die Firewall-Einstellungen.)

    • Ein Betriebssystem wie Ubuntu Server wird empfohlen, um eine Linux-Umgebung zu bieten.

    • Docker-Installation: Docker sollte installiert sein, damit die bereitgestellten Anwendungen im Docker-Container erstellt oder ausgeführt werden können.

  3. Python-Entwicklungsumgebung:

    • Auf dem Staging-Server sollte Python Version 3.8 oder höher installiert sein. (Verwendung von virtuellen Umgebungen empfohlen)

  4. Git:

    • Git muss auf dem Staging-Server installiert sein. Es wird verwendet, um den neuesten Code aus dem GitHub-Repository mit dem Befehl git pull abzurufen.

  5. FastAPI und Uvicorn:

    • Es werden FastAPI, ein Framework zur Implementierung des Python Webhook-Endpunkts, und Uvicorn, ein ASGI-Server, benötigt. In der nächsten Folge werden wir die Installation und die Grundeinstellungen behandeln.

  6. SSH-Schlüssel:

    • Um sicher auf das GitHub-Repository zuzugreifen und den Code abzurufen, sind Einstellungen für den SSH-Schlüssel auf dem Staging-Server erforderlich. In den meisten Fällen sollte der SSH-Schlüssel bereits in Ihrem Konto registriert sein. (Falls noch nicht registriert, bitte bei GitHub registrieren. Normalerweise wird der Deploy key verwendet.)

  7. Verständnis von Webservern (Nginx oder Apache2) und Domain-/HTTPS-Einstellungen:

    • GitHub Webhook empfiehlt normalerweise sichere Kommunikation über HTTPS. Daher wird dringend empfohlen, eine Subdomain, wie deployer.example.com, im Voraus vorzubereiten und ein HTTPS-Zertifikat (z. B. ein kostenloses Zertifikat von Let's Encrypt) dafür zu beantragen.

    • Ich gehe davon aus, dass niemand auf die Idee kommt, die FastAPI-Anwendung direkt über Port-Forwarding an den Router des Internetanbieters anzuschließen. Falls doch, möchte ich klarstellen, dass es sicherer und üblicher ist, einen Webserver wie Nginx oder Apache2 als Reverse Proxy zu verwenden, um Webhook-Anfragen an die FastAPI-Anwendung weiterzuleiten. Stellen Sie sicher, dass Sie immer einen Server benutzen, um den Reverse Proxy zu betreiben. Grundlegendes Verständnis und Erfahrung mit dieser Konfiguration sind sehr hilfreich.

  8. Verständnis des Systemd-Service (optional, aber empfohlen):

    • Dieser FastAPI Webhook-Server sollte immer aktiv und auf dem Staging-Server ausgeführt werden. Um dies zu erreichen, wird empfohlen, ihn als Systemd-Service zu registrieren, damit er beim Neustart des Servers automatisch gestartet wird und die Verwaltung des Services (Start/Stop/Neustart) einfach ist.

    • Hinweis: Das Ausführen komplexer Bereitstellungslogiken, bei denen die git oder docker Befehle direkt in einem Docker-Container ausgeführt werden sollen, entspricht nicht den Zielen der Containereinsatz und erfordert eine komplizierte Einrichtung wie docker-in-docker oder docker-out-of-docker, was nicht sicher ist. Wenn git und docker bereits auf dem Server installiert sind, ist es viel effizienter und einfacher, den FastAPI Webhook-Server mit Systemd Service auszuführen und die git und docker Befehle des Systems im Bereitstellungsskript direkt zu nutzen. In dieser Serie werden wir uns auf diese Methode konzentrieren.

Jetzt sind alle Vorbereitungen getroffen. In der nächsten Folge werden wir den FastAPI Webhook-Endpunkt auf dem vorbereiteten Staging-Server einrichten und den GitHub Webhook konfigurieren, um den ersten automatischen Deployment-Prozess erfolgreich abzuschließen. Seien Sie gespannt!