Inleiding: Het belang van CI/CD en automatische deploy

Automatisch deployen voor een efficiënte ontwikkelworkflow, oftewel CI/CD (Continuous Integration/Continuous Delivery), wordt steeds meer een noodzaak in plaats van een optie. Wanneer code naar GitHub wordt gepusht, kan het build-test-deploy proces automatisch plaatsvinden, wat de ontwikkelingsproductiviteit aanzienlijk verhoogt.

Er zijn verschillende manieren om deze automatische deploy te implementeren, waaronder het gebruik van de GitHub Actions die GitHub zelf aanbiedt en het direct implementeren van de deploylogica met behulp van de Webhook functie van GitHub.

Waarom zelf een Webhook implementeren in plaats van GitHub Actions?

Het GitHub-katje dat een Webhook-papieren vliegtuigje naar Tux laat vliegen

GitHub Actions is ongetwijfeld een krachtige en handige CI/CD-tool. Complexe workflows kunnen in een paar regels YAML worden gedefinieerd en diverse acties op de marketplace maken het mogelijk om processen zoals builden, testen en deployen te automatiseren. Het is moeilijk te ontkennen dat GitHub Actions een geweldige optie is voor de meeste projecten.

Echter, GitHub Actions is niet altijd de optimale keuze. Vooral in de volgende situaties kan het zelf implementeren met GitHub Webhook veel aantrekkelijker zijn.

  • Kostengevoelige individuele ontwikkelaars of kleine teams: GitHub Actions is vrijwel onbeperkt gratis voor openbare repositories, maar voor privé repositories zijn er kosten verbonden zodra je de gratis hoeveelheid (minuten en opslag) overschrijdt. Als je onverwachte kosten volledig wilt vermijden, is zelf implementeren de beste optie.

  • Ontwikkelaars die een eigen staging server zoals een Raspberry Pi 5 beheren: Als je al een fysieke server (inclusief VPS en cloudinstantie) hebt, is het efficiënter om de bronnen van je eigen server te gebruiken in plaats van een virtuele omgeving (Runner) van GitHub te huren. Direct code ontvangen en deployen op je eigen server is kosteneffectief en voordelig voor het gebruik van bronnen.

  • Ontwikkelaars die volledige controle en vrijheid willen over de deploylogica: GitHub Actions gebruikt gestandaardiseerde workflows en acties, maar door zelf webhooks te implementeren kun je elk aspect van het deployscript ontwerpen en beheren zoals je wilt. Dit heeft voordelen als je complexe, op specifieke omgevingen afgestemde logica of een perfecte integratie met bestaande pipelines nodig hebt.

In deze serie zullen we specifiek voor deze mensen gedetailleerd behandelen hoe je met behulp van GitHub Webhook jouw server direct kunt implementeren. We richten ons op Python-ontwikkelaars en zullen een eenvoudig maar krachtig webframework, FastAPI, gebruiken om de Webhook-endpoint op te zetten. Hoewel DRF (Django REST Framework) ook een uitstekende keuze is, denk ik dat FastAPI de optimale keuze is omdat de logica voor het verwerken van Webhook-aanvragen zeer licht is. Je hoeft niet met een sportauto naar de supermarkt te rijden voor boodschappen; een compacte auto is voldoende.

Basisbenodigdheden voor het bouwen van een automatisch deploysysteem

De daadwerkelijke implementatie begint in het volgende deel. In dit deel worden de zaken die je ter voorbereiding moet regelen op een rijtje gezet.

  1. GitHub-repository:

    • Je hebt een GitHub-repository nodig met het Python-project waarvoor je automatisch wilt deployen. (Zowel openbaar als privé is toegestaan)

    • De deploy wordt gestart telkens wanneer er code naar deze repository wordt gepusht.

  2. Staging server (Zelf-gehosteerde server):

    • Je hebt een server nodig waarop de daadwerkelijke deploy zal plaatsvinden. Een Raspberry Pi 5, persoonlijke VPS (virtuele privéserver) of cloudinstantie (zoals AWS EC2 of GCP Compute Engine) zijn allemaal goed.

    • De server moet toegankelijk zijn van buitenaf (GitHub) via een publiek IP-adres of domein. (Let op de firewall-instellingen.)

    • Het besturingssysteem dat wordt aanbevolen is een Linux-omgeving zoals Ubuntu Server.

    • Docker-installatie: Zorg ervoor dat Docker vooraf op de server is geïnstalleerd, zodat de te deployen applicatie kan worden gebouwd of uitgevoerd in een Docker-container.

  3. Python-ontwikkelomgeving:

    • Op de staging server moet Python versie 3.8 of hoger zijn geïnstalleerd. (Het gebruik van een virtuele omgeving wordt aanbevolen.)

  4. Git:

    • Op de staging server moet Git zijn geïnstalleerd. Dit wordt gebruikt om de nieuwste code van de GitHub-repository op te halen met het git pull commando.

  5. FastAPI en Uvicorn:

    • Je hebt FastAPI, het framework voor de implementatie van de Python-webhook-endpoint, en Uvicorn, de ASGI-server, nodig. In het volgende deel zullen we de installatie en basisconfiguratie behandelen.

  6. SSH-sleutel:

    • Voor veilige toegang tot de GitHub-repository om code op te halen op de staging server, is SSH-sleutelconfiguratie nodig. De meeste mensen zullen al een SSH-sleutel aan hun account geregistreerd hebben. (Als je dat nog niet hebt gedaan, registreer het dan op GitHub. Het gebruik van een Deploy key is gebruikelijk.)

  7. Inzicht in webservers (Nginx of Apache2) en domein/HTTPS-instellingen:

    • GitHub Webhook raadt vaak veilige communicatie via HTTPS aan. Het is sterk aanbevolen om vooraf een subdomein zoals deployer.example.com voor de webhook klaar te hebben en een HTTPS-certificaat (bijvoorbeeld een gratis certificaat van Let's Encrypt) voor dat domein te verkrijgen en toe te passen.

    • Ik neem aan dat niemand de FastAPI-applicatie direct met port forwarding van de router van de internetprovider verbinden, maar voor het geval dat: het is gebruikelijk en veiliger om een webserver zoals Nginx of Apache2 als reverse proxy te gebruiken om webhook-verzoeken naar de FastAPI-applicatie te sturen. Zorg ervoor dat je een serverprogramma gebruikt voor de reverse proxy. Inzicht in basisconfiguratie en ervaring zijn erg nuttig.

  8. Inzicht in Systemd Service (aanbevolen, maar optioneel):

    • Deze FastAPI-webhookserver moet altijd op de staging server draaien. Het wordt aanbevolen om het als Systemd Service te registreren, zodat het automatisch start bij herstart van de server en het beheer (starten/stoppen/herstarten) eenvoudiger wordt.

    • Opmerking: Het direct uitvoeren van git of docker commando's binnen een Docker-container om complexe deploylogica samen te stellen, is niet in overeenstemming met het doel van containerontwerp en vereist complexe configuraties zoals docker-in-docker of docker-out-of-docker wat niet veilig is. Als git en docker al op de server zijn geïnstalleerd, is het veel efficiënter en eenvoudiger om de FastAPI-webhookserver licht op te zetten als Systemd Service en de git en docker commando's van het systeem in het deployscript direct te benutten. Deze serie zal zich rondom deze aanpak concentreren.

Nu zijn we er klaar voor. In het volgende deel zullen we de FastAPI-webhook-endpoint op de voorbereide staging server opzetten en GitHub Webhook configureren om het eerste automatische deployment succesvol uit te voeren. Blijf nieuwsgierig!