Inleiding: Het laatste puzzelstukje

Hallo! Dit is eindelijk het laatste deel van de lange serie. In de voorgaande delen hebben we de theorie van het automatische uitrolsysteem besproken, de kernlogica van de FastAPI-webhookserver geïmplementeerd en een stabiele bedrijfsomgeving met Systemd opgebouwd.

Vorige posts in deze serie kunnen worden bekeken via de onderstaande links.

① Waarom zelf implementeren?

② Algemene architectuur en procesontwerp

③ Instellingen van de staging-serveromgeving en basisopbouw van de FastAPI-webhookserver

④ Gedetailleerde uitrolhandler en registratie van Systemd-service

Maar er is nog één stap te gaan. Onze FastAPI-webhookserver draait momenteel alleen op poort 8000 en gebruikt geen HTTPS, wat het kwetsbaar maakt voor beveiligingsrisico's. Ook moedigt GitHub sterk aan om een openbaar domein met een HTTPS-verbinding te gebruiken.

In deze 5e aflevering zullen we de laatste puzzelstukjes in elkaar zetten om het systeem te voltooien. Laten we Nginx instellen als reverse proxy om de FastAPI-server veilig bloot te stellen aan de buitenwereld, Let's Encrypt gebruiken om gratis HTTPS toe te passen, en ten slotte de GitHub-webhook integreren om het automatische uitrolsysteem af te ronden.

Even, waarom Nginx in plaats van Apache2? Apache2 en Nginx zijn geweldige webservers die de servermarkten verdelen. Maar asynchrone webframeworks zoals FastAPI werken beter samen met Nginx. Nginx is ontworpen op basis van asynchrone evenementen, waardoor het de asynchrone prestaties van FastAPI maximaal kan benutten in omgevingen met veel gelijktijdige verbindingen. Om deze reden raadt de FastAPI-gemeenschap Nginx sterk aan als webserver voor productieomgevingen, en in deze tekst wordt Nginx als leidraad gebruikt.

Nginx-installatie en reverse proxy-instellingen

Waarom Nginx gebruiken?

  1. Reverse proxy: Applucatie-servers zoals FastAPI zijn niet bedoeld om externe verkeer direct te ontvangen. Nginx fungeert als een reverse proxy die webhookverzoeken ontvangt en veilig doorstuurt naar de FastAPI-server.

  2. Beveiliging: Nginx biedt verschillende beveiligingsinstellingen en DDoS-beschermingsfuncties.

  3. HTTPS-toepassing: De verantwoordelijkheid voor het beheren en toepassen van HTTPS-certificaten ligt bij webservers zoals Nginx.

Nginx installeren en instellen

Log in op de staging-server via SSH en installeer Nginx. Ik ga ervan uit dat de lezers die dit artikel lezen al enige ervaring en kennis van Nginx hebben, daarom sla ik gedetailleerde uitleg over de installatie, bestandsstructuur en werking over. 

sudo apt update
sudo apt install -y nginx
sudo systemctl enable nginx # automatiseert bij herstart
sudo systemctl start nginx # start nginx
sudo systemctl status nginx # Controleer of het actief is

Nu gaan we het Nginx-configuratiebestand opstellen om de verzoeken naar onze FastAPI-webhookserver door te geven. Laten we aannemen dat we een domein deployer.example.com gebruiken. Hier is een voorbeeld van de configuratie.

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

# HTTP-verzoeken omleiden naar HTTPS via 308
server {
    listen 80;
    server_name deployer.example.com;
    return 308 https://$host$request_uri;
}

# Behandeling van HTTPS-verzoeken
server {
    listen 443 ssl;
    server_name deployer.example.com;

    # Stel de SSL-certificaatpaden in
    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;
    }
}

  • Instelling HTTP-poort 80: De listen 80-blok met de server_name deployer.example.com leidt alle inkomende HTTP-verzoeken permanent om naar HTTPS via return 308 https://$host$request_uri; commando.

  • Instelling HTTPS-poort 443: De listen 443 ssl; blok behandelt HTTPS-verzoeken.

  • ssl_certificate & ssl_certificate_key: Dit is geschreven met de veronderstelling dat het certificaat al via Let's Encrypt is verstrekt. In deze blok definiëren we de paden voor het reeds verkregen SSL-certificaat en sleutel. Deze paden worden automatisch aangemaakt wanneer certbot het certificaat verstrekt.

  • location / blok: Dit stelt de reverse proxy-instellingen in om de verzoeken die naar HTTPS zijn omgezet door te geven aan onze FastAPI-server (http://127.0.0.1:8000).

Na het herstarten van Nginx met dit configuratiebestand, worden nu alle webhookverzoeken veilig verwerkt via HTTPS. 

# Maak een symbolische link van het configuratiebestand naar de sites-enabled-directory
sudo ln -s /etc/nginx/sites-available/deployer.example.com /etc/nginx/sites-enabled/

# Controleer op syntaxfouten in het Nginx-configuratiebestand.
sudo nginx -t

# Herstart Nginx om de wijzigingen door te voeren.
sudo systemctl restart nginx

HTTPS toepassen (Let's Encrypt + Certbot)

GitHub-webhooks bevelen sterk HTTPS-communicatie aan om beveiligingsredenen. Let's Encrypt is een non-profit certificeringsinstantie die gratis SSL/TLS-certificaten aan iedereen verstrekt, en Certbot is een geweldig hulpmiddel voor het automatiseren van het aanvragen en vernieuwen van certificaten. Hier zal ik de installatieprocedure overslaan.

Als het succesvol is afgerond, kun je in je browser https://deployer.example.com openen en toegang krijgen tot de API-documentatie van FastAPI (.../docs) of de / endpoint. Als je de boodschap Webhook server is running! ziet, is de Nginx- en HTTPS-configuratie succesvol afgerond.

Laatste koppeling en test van GitHub-webhook

Nu zijn alle voorbereidingen getroffen. Laten we de automatische uitrolsystemen koppelen aan onze GitHub-repository.

  1. Toegang tot de GitHub-repository: Ga naar de GitHub-repo van het project waarop je automatische uitrol wilt toepassen.

  2. Webhookinstellingen: Klik in het bovenste menu op Settings -> Klik op Webhooks in het linker menu.

  3. Webhook toevoegen: Klik op de Add webhook knop en voer de volgende informatie in.

    • Payload URL: Voer het adres van de webhookserver met Nginx en HTTPS in. (Bijv. https://deployer.example.com/webhook)

    • Inhoudstype: Kies application/json.

    • Secret: Kopieer nauwkeurig de waarde van GITHUB_WEBHOOK_SECRET die je in deel 3 in het ~/projects/webhook_server/.env bestand hebt ingesteld.

    • Welke gebeurtenissen moeten deze webhook activeren?: Kies Just the push event.

    • Actief: Controleer of het selectievakje is ingeschakeld.

  4. Opslaan: Klik op de Add webhook knop om de webhook op te slaan.

Screenshot van GitHub Webhook-instellingen

Als de webhook correct is geregistreerd, verschijnt er een groen vinkje in het Recent Deliveries sectie, wat bevestigt dat het testverzoek succesvol is verzonden.

Laten we nu de laatste test uitvoeren.

  1. Wijzigingen aan de code lokaal: Wijzig een beetje van de code van het project en maak een commit en push naar Git.

  2. Controleer de status:

    • Controleer in de Recent Deliveries pagina van de GitHub-webhook of de net verzonden push succesvol was (groen vinkje).

    • Log via SSH in op de staging server en controleer de realtime logs met het commando sudo journalctl -u github-webhook-deployer.service -f. Als je berichten zoals Git pull successful en Deployment task finished ziet, is het succesvol.

    • Controleer de status van de uitgerolde Docker-containers om te verifiëren of de laatste code is toegepast.

Afronding: Automatisch uitrolsysteem voltooid!

Gefeliciteerd! Je hebt met succes een volledige CI/CD-pijpleiding gebouwd die van de lokale ontwikkelomgeving naar GitHub en naar de zelfgebouwde staging-server loopt.

In deze serie hebben we het volgende bereikt.

  • We hebben begrepen waarom we een webhook-gebaseerd automatisch uitrolsysteem zelf moeten bouwen.

  • We hebben de architectuur van de webhookserver met FastAPI ontworpen en geïmplementeerd.

  • We hebben geleerd hoe we diensten stabiel kunnen draaien met Systemd.

  • We hebben de beveiliging versterkt door Nginx en HTTPS-instellingen toe te passen.

  • Uiteindelijk hebben we alles geautomatiseerd door integratie met GitHub.

Nu, op het moment dat je de code pusht, zal de server automatisch de laatste code toegewezen krijgen zonder dat je er enige moeite voor hoeft te doen. Voel je vrij om ingewikkeldere uitrollogica toe te voegen of meldingsfunctionaliteit te integreren op basis van dit systeem.

Bedankt dat je deze lange reis met me hebt gedeeld!