Introduction : il est important de comprendre l'ensemble du tableau

Bonjour ! Dans la première partie, nous avons exploré les raisons de vouloir construire un système de déploiement automatique avec GitHub Webhook et les préparatifs nécessaires. Dans cette deuxième partie, avant d'aborder la mise en œuvre du code, nous allons prendre le temps de concevoir l'architecture globale et le processus de notre système de déploiement automatique.

Les environnements de développement peuvent varier d'un individu à l'autre. Certains d'entre vous peuvent utiliser un Raspberry Pi, d'autres un VPS cloud, et la structure du projet à déployer peut être différente également. Dans cet environnement varié, il est crucial de construire un système flexible et de résoudre soi-même les problèmes qui peuvent survenir, en comprenant non seulement le code détaillé mais aussi le flux général et le contexte.

Dans cet article, prenons le temps de visualiser le grand tableau du système que nous allons créer et de bien comprendre le rôle de chaque composant.

Flux du système de déploiement automatique

Workflow de déploiement automatique : aperçu général du flux

Le système de déploiement automatique que nous allons mettre en place fonctionne par une série de processus.

  1. Changements de code et Git Push sur la machine locale : Le développeur modifie le code dans un environnement local et pousse les modifications vers une branche spécifique du dépôt GitHub (ex. : main ou develop).

  2. Événement Webhook déclenché dans le dépôt GitHub : Lorsqu'un événement push est détecté, le dépôt GitHub envoie une requête HTTP POST à une URL spécifiée par le biais du Webhook configuré au préalable.

  3. Transmission de la requête vers le point d'extrémité Webhook du serveur de staging : La requête Webhook envoyée par GitHub pointe vers une URL spécifique de notre serveur de staging (ex. : https://deployer.example.com/webhook). Cette requête contient plusieurs données dans le payload, comme les informations de commit poussées et la liste des fichiers modifiés.

  4. Réception de la requête Webhook par le service FastAPI du serveur de staging : Notre application FastAPI exécutée sur le serveur de staging reçoit cette requête Webhook. C'est à partir de ce moment que le rôle du service FastAPI commence.

Rôle clé du service Webhook FastAPI

Le service Webhook que nous allons implémenter avec FastAPI ne se limite pas à recevoir la requête, il va également remplir les fonctions importantes suivantes.

Réception et traitement initial du Webhook

Notre application FastAPI fournit un point d'extrémité (ex. : /webhook) capable de recevoir des requêtes HTTP POST envoyées par GitHub. Ce point d'extrémité analyse les en-têtes HTTP et le corps de la requête (Payload) pour extraire les informations nécessaires.

Vérification du Secret

La sécurité est primordiale dans un système de déploiement automatique. Le Webhook GitHub fournit une valeur Secret dans l'en-tête X-Hub-Signature-256 qui permet de vérifier l'intégrité de la requête. Notre service FastAPI devra inclure une logique pour vérifier si la requête envoyée par GitHub est valide et si elle n'a pas été altérée en cours de route. Si cette vérification échoue, la requête est immédiatement rejetée pour bloquer tout accès non autorisé.

Réponse immédiate et tâches d'arrière-plan

Si GitHub ne reçoit pas de réponse dans un certain délai (généralement 10 secondes) après l'envoi de la requête, cela est considéré comme un timeout, entraînant une nouvelle tentative ou un échec d'enregistrement. Toutefois, le processus de déploiement réel (Git Pull, build/restart Docker, etc.) peut prendre plus de temps.

Par conséquent, notre service FastAPI va, dès qu'il reçoit la requête Webhook, terminer le traitement initial comme la vérification du Secret, et envoyer immédiatement une réponse 200 OK à GitHub. Ensuite, la logique de déploiement sera conçue pour être exécutée de manière asynchrone en arrière-plan à l'aide de la fonctionnalité BackgroundTasks de FastAPI. Cela nous permet d'éviter les problèmes de timeout de GitHub tout en exécutant de manière fiable les tâches de déploiement.

Détails de la logique du gestionnaire de déploiement

Le gestionnaire de déploiement exécuté en arrière-plan effectuera les tâches clés suivantes.

Gestion de plusieurs projets : lecture du chemin de dépôt

Nous concevons notre service Webhook FastAPI pour traiter automatiquement le déploiement de plusieurs dépôts GitHub (projets) avec une seule instance. Pour ce faire, nous mapperons les chemins de dépôt GitHub de chaque projet et les chemins locaux où ils seront déployés, en utilisant des variables d'environnement ou des fichiers de configuration. Après avoir vérifié quel dépôt a déclenché l'événement dans le payload Webhook, le gestionnaire se déplacera vers le chemin correspondant et effectuera le déploiement.

Configuration personnalisée par projet : analyse du fichier .env (optionnelle)

Chaque projet peut avoir des variables d'environnement ou des paramètres uniques nécessaires pour le build ou le déploiement. Par exemple, des balises d'image Docker spécifiques, des options de build, des commandes de redémarrage de service, etc. Pour gérer cela efficacement, nous implémenterons une analyse des valeurs nécessaires dans le fichier .env de chaque projet situé au chemin du dépôt local, afin de pouvoir les utiliser dans la logique de déploiement. Cela sera d'une grande aide pour créer une logique de déploiement flexible et personnalisée.

Mise à jour du code : exécution de git pull

C'est l'étape la plus basique. Nous utiliserons le module subprocess pour exécuter la commande git pull origin <branch_name> dans le dépôt local paraudissant le dernier code du dépôt GitHub.

Décision de reconstruction de l'image Docker : utilisation de git diff

Pour les projets basés sur Docker, si seulement le code a été modifié, docker compose up -d sera suffisant. Mais si des fichiers comme Dockerfile ou requirements.txt (pour les projets Python) qui affectent la build de l'image ont été modifiés, il est nécessaire de reconstruire l'image.

Nous allons utiliser la commande git diff pour déterminer s'il y a des changements dans le Dockerfile ou d'autres fichiers de build entre le dernier commit poussé et l'ancien. Si des changements sont détectés, nous exécuterons docker compose up -d --build, sinon, nous exécuterons simplement docker compose up -d pour éviter les reconstructions d'images inutiles et réduire le temps de déploiement.

Exécution de Docker Compose : utilisation du module subprocess

Après avoir récupéré le dernier code et décidé de la reconstruction d'image, nous utiliserons le module subprocess pour exécuter les commandes docker compose up -d ou docker compose up -d --build afin de mettre à jour les conteneurs Docker et redémarrer les services.

Journalisation : enregistrement de tout le processus

Tous les aspects du processus de déploiement (réception du Webhook, validation, résultats de Git Pull, logs de build/restart Docker, etc.) devront être enregistrés en détail. Cela est essentiel pour identifier les causes en cas de problème et pour le débogage. Nous implémenterons une journalisation dans un fichier en utilisant le module logging de Python.

Stratégie de déploiement et d'exploitation du service FastAPI

Le service Webhook FastAPI que nous allons implémenter doit fonctionner de manière stable et continue sur le serveur de staging.

Importance de l'utilisation du service Systemd

Nous recommandons fortement d'exécuter l'application FastAPI en tant que service Systemd plutôt que de la lancer directement dans un conteneur Docker. Voici pourquoi :

  • Efficacité des ressources : Il est très probable que le serveur de staging ait déjà installé des outils nécessaires au déploiement comme git, docker, docker-compose. Créer le service Webhook FastAPI dans un conteneur Docker, et y installer à nouveau git ou docker pour contrôler le démon docker du système, augmente inutilement la taille du conteneur et crée des problèmes de configuration compliqués et de sécurité, comme docker-in-docker ou docker-out-of-docker.

  • Gestion simplifiée : Systemd est le standard de gestion des services dans les systèmes Linux. Enregistrer l'application FastAPI en tant que service Systemd permet un démarrage automatique au démarrage du serveur, une vérification de l'état du service, et une gestion simplifiée des redémarrages/arrêts à un niveau OS.

  • Utilisation des ressources système : En utilisant Systemd pour exécuter l'application FastAPI, l'application peut appeler directement les commandes git et docker installées sur le système pour effectuer les tâches de déploiement, utilisant ainsi les ressources existantes du système de manière optimale.

Dans la prochaine partie, nous expliquerons en détail comment enregistrer et gérer l'application FastAPI en tant que service Systemd.

Reverse proxy et HTTPS via Nginx/Apache2

Comme souligné dans la première partie, exposer directement l'application FastAPI à Internet est très risqué sur le plan de la sécurité. Nous allons donc utiliser un serveur web tel que Nginx ou Apache2 comme reverse proxy pour transmettre en toute sécurité les requêtes Webhook à l'application FastAPI.

En outre, GitHub Webhook recommande fortement l'utilisation de la communication HTTPS, donc nous devons préparer un sous-domaine dédié comme deployer.example.com et obtenir un certificat HTTPS via Let's Encrypt pour l'appliquer au serveur web. Cela garantira que toutes les communications externes sont cryptées et renforcera la sécurité.

Surveillance et débogage

Pour vérifier si le système de déploiement automatique fonctionne correctement et identifier les causes des problèmes qui peuvent survenir, nous utiliserons les deux méthodes suivantes.

  • Fichiers de journalisation du service FastAPI : Le service FastAPI que nous mettrons en œuvre enregistrera chaque étape du processus de déploiement dans son propre fichier journal. En examinant ce fichier, nous pourrons déterminer le succès du déploiement, les messages d'erreur survenant, etc.

  • Systemd journalctl : Étant donné que nous gérons le service FastAPI avec Systemd, nous pouvons vérifier et analyser en temps réel la sortie standard et les logs d'erreur du service en utilisant la commande journalctl -u your-fastapi-service.service.

Conclusion : aperçu du prochain article

Dans cette deuxième partie, nous avons examiné l'architecture générale du système de déploiement automatique utilisant GitHub Webhook, le rôle clé du service FastAPI, ainsi que les stratégies de déploiement et d'exploitation. J'espère que vous avez pu visualiser le grand tableau.

Dans la prochaine partie, nous nous pencherons sur la rédaction du code du service Webhook FastAPI basé sur les conceptions d'aujourd'hui, la configuration de GitHub Webhook et l'enregistrement en tant que service Systemd. Restez à l'écoute !

Série de création de mon système de déploiement automatique avec GitHub Webhook

Partie 1 - Pourquoi implémenter nous-mêmes ?