Introduction : assembler la dernière pièce du puzzle

Bonjour ! Voici enfin le dernier chapitre de cette longue série. Dans les quatre parties précédentes, nous avons examiné la théorie du système de déploiement automatique, mis en œuvre la logique principale du serveur webhook FastAPI et établi un environnement opérationnel stable à l'aide de Systemd.

Les posts précédents de cette série peuvent être consultés via les liens ci-dessous.

① Pourquoi le mettre en œuvre soi-même ?

② Conception de l'architecture entière et des processus

③ Configuration de l'environnement du serveur de pré-production et construction de base du serveur webhook FastAPI

④ Détails du gestionnaire de déploiement et enregistrement du service Systemd

Cependant, il reste encore une étape. Actuellement, notre serveur webhook FastAPI fonctionne seulement sur le port 8000 et ne utilise pas HTTPS, ce qui le rend vulnérable aux attaques. De plus, GitHub recommande fortement d'utiliser un domaine public avec une connexion HTTPS.

Dans cette cinquième partie, nous allons assembler les dernières pièces du puzzle pour compléter le système. Nous allons configurer Nginx comme un proxy inverse pour exposer en toute sécurité le serveur FastAPI à l'extérieur, appliquer HTTPS gratuit via Let's Encrypt, puis finalement, intégrer le webhook GitHub pour compléter le système de déploiement automatique.

Attendez, pourquoi Nginx et pas Apache2 ? Apache2 et Nginx sont d'excellents serveurs web qui se partagent le marché des programmes serveur. Cependant, des frameworks web asynchrones comme FastAPI s'accordent mieux avec Nginx. Nginx est conçu sur la base d'événements asynchrones, ce qui permet d'exploiter au maximum les performances asynchrones de FastAPI dans un environnement avec une forte affluence de connexions. C'est pourquoi la communauté FastAPI recommande vivement Nginx comme serveur web en production, et cet article s'explique principalement autour de Nginx.

Installation et configuration de Nginx comme proxy inverse

Pourquoi devriez-vous utiliser Nginx ?

  1. Proxy inverse : Des serveurs d'applications comme FastAPI ne sont pas conçus pour recevoir le trafic externe directement. Nginx joue le rôle d'un proxy inverse en réceptionnant les requêtes webhook et en les transmettant en toute sécurité au serveur FastAPI.

  2. Sécurité : Nginx offre diverses configurations de sécurité ainsi que des fonctionnalités de défense contre les attaques DDoS.

  3. Application de HTTPS : La gestion et l'application des certificats HTTPS sont des tâches assignées aux serveurs web comme Nginx.

Installation et configuration de Nginx

Connectez-vous à votre serveur de pré-production via SSH et installez Nginx. Nous supposons que vous avez déjà une certaine expérience et des connaissances sur Nginx, donc nous omettrons les détails sur la méthode d'installation, la structure de fichiers et les principes de fonctionnement de Nginx. 

sudo apt update
sudo apt install -y nginx
sudo systemctl enable nginx # démarrer automatiquement au redémarrage
sudo systemctl start nginx # Démarrer Nginx
sudo systemctl status nginx # Vérifier l'état actif

Maintenant, nous allons rédiger le fichier de configuration Nginx pour rediriger les demandes vers notre serveur webhook FastAPI. Supposons que nous utilisons le domaine deployer.example.com. Voici un exemple de configuration.

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

# Redirection des requêtes HTTP vers HTTPS avec un code 308
server {
    listen 80;
    server_name deployer.example.com;
    return 308 https://$host$request_uri;
}

# Traitement des requêtes HTTPS
server {
    listen 443 ssl;
    server_name deployer.example.com;

    # Définir le chemin des certificats SSL
    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;
    }
}

  • Configuration du port HTTP 80 : Le bloc listen 80 avec server_name comme deployer.example.com redirige toutes les requêtes HTTP entrantes de façon permanente vers HTTPS via la commande return 308 https://$host$request_uri;.

  • Configuration du port HTTPS 443 : Le bloc listen 443 ssl; traite les requêtes HTTPS.

  • ssl_certificate & ssl_certificate_key : Supposons que le certificat a déjà été obtenu via Let's Encrypt. Ce bloc définit le chemin des fichiers de certificat SSL et de clé. Ce chemin est automatiquement généré lorsque certbot délivre le certificat.

  • Bloc location / : Configure le proxy inverse pour transmettre les requêtes converties en HTTPS à notre serveur FastAPI (http://127.0.0.1:8000).

Après avoir redémarré Nginx avec ce fichier de configuration, toutes les requêtes webhook seront maintenant traitées de manière sécurisée via HTTPS. 

# Lien symbolique vers le fichier de configuration dans le répertoire sites-enabled
sudo ln -s /etc/nginx/sites-available/deployer.example.com /etc/nginx/sites-enabled/

# Vérification des erreurs de syntaxe du fichier de configuration Nginx.
sudo nginx -t

# Redémarrage de Nginx pour appliquer les modifications.
sudo systemctl restart nginx

Application de HTTPS (Let's Encrypt + Certbot)

GitHub recommande fortement d'utiliser HTTPS pour des raisons de sécurité. Let's Encrypt est une autorité de certification à but non lucratif qui permet à quiconque d'obtenir gratuitement un certificat SSL/TLS, et Certbot est un excellent outil pour automatiser la délivrance et le renouvellement des certificats. Ici, nous allons omettre la méthode d'installation.

Une fois cela effectué avec succès, essayez d'accéder à https://deployer.example.com dans votre navigateur pour voir la documentation de l'API de FastAPI (.../docs) ou l'endroit (/). Si vous voyez le message Webhook server is running!, cela signifie que Nginx et la configuration HTTPS ont été correctement mises en place.

Intégration finale et test de GitHub Webhook

Maintenant que tout est prêt, intégrons le système de déploiement automatique que nous avons construit avec le dépôt GitHub.

  1. Accéder au dépôt GitHub : Accédez au dépôt GitHub du projet pour appliquer le déploiement automatique.

  2. Configurer les Webhooks : Dans le menu supérieur, cliquez sur Settings -> Dans le menu de gauche, cliquez sur Webhooks.

  3. Ajouter un webhook : Cliquez sur le bouton Add webhook et entrez les informations suivantes.

    • Payload URL : Entrez l'adresse du serveur webhook avec Nginx et HTTPS appliqués. (ex : https://deployer.example.com/webhook)

    • Content type : Sélectionnez application/json.

    • Secret : Copiez et collez avec précision la valeur de GITHUB_WEBHOOK_SECRET que vous avez définie dans le fichier ~/projects/webhook_server/.env à la troisième partie.

    • Quels événements voudriez-vous déclencher ce webhook ? : Sélectionnez Just the push event.

    • Actif : Assurez-vous que la case est cochée.

  4. Sauvegarder : Cliquez sur le bouton Add webhook pour enregistrer le webhook.

Capture d'écran de la configuration GitHub Webhook

Une fois le webhook enregistré avec succès, une coche verte apparaîtra dans la section Recent Deliveries, confirmant que la requête de test a été envoyée avec succès.

Passons maintenant au test final.

  1. Modifier le code localement : Modifiez légèrement le code du projet, effectuez un commit et poussez-le.

  2. Vérification de l'état :

    • Vérifiez sur la page de configuration du webhook GitHub dans Recent Deliveries si le webhook a réussi (coche verte) pour le push que vous avez effectué.

    • Connectez-vous via SSH au serveur de pré-production et vérifiez les logs en temps réel avec la commande sudo journalctl -u github-webhook-deployer.service -f. Si vous voyez des messages comme Git pull successful, Deployment task finished, vous avez réussi.

    • Vérifiez l'état du conteneur Docker déployé pour confirmer que le dernier code est bien en place.

Conclusion : Système de déploiement automatique complet !

Félicitations ! Vous avez réussi à établir un pipeline CI/CD complet allant de l'environnement de développement local à GitHub, en passant par votre serveur de pré-production construit en interne.

Grâce à cette série, nous avons réussi à :

  • Comprendre pourquoi il est nécessaire de construire un système de déploiement automatique basé sur un webhook.

  • Concevoir et mettre en œuvre l'architecture du serveur webhook avec FastAPI.

  • Apprendre à faire fonctionner un service de manière stable avec Systemd.

  • Renforcer la sécurité grâce à la configuration de Nginx et de HTTPS.

  • Enfin, automatiser tous les processus en intégrant GitHub.

Désormais, au moment où vous poussez votre code, le serveur mettra automatiquement à jour le dernier code sans votre intervention. Basé sur ce système, envisagez d'ajouter des logiques de déploiement plus complexes ou d'intégrer des fonctionnalités d'alerte, à votre manière.

Merci d'avoir partagé ce long voyage avec nous !