Introduction : L'importance du CI/CD et du déploiement automatique

Le déploiement automatique, c'est-à-dire le CI/CD (Intégration Continue / Livraison Continue), est devenu un incontournable pour un flux de développement efficace. Si le processus de construction, de test et de déploiement est automatisé chaque fois que vous poussez du code sur GitHub, vous pouvez considérablement augmenter la productivité des développeurs.

Il existe plusieurs méthodes pour mettre en œuvre ce déploiement automatique, mais les deux principales sont l'utilisation des GitHub Actions fournies par GitHub et la mise en œuvre de la logique de déploiement en utilisant la fonction Webhook de GitHub.

Pourquoi doit-on implémenter un Webhook soi-même au lieu d'utiliser GitHub Actions ?

Le chat GitHub lançant un avion en papier Webhook à Tux

Les GitHub Actions sont sans aucun doute un outil CI/CD puissant et pratique. Vous pouvez définir des flux de travail complexes en quelques lignes dans un fichier YAML et automatiser de nombreux processus tels que la construction, le test et le déploiement via divers marchés d'actions. Dans la plupart des projets, il est indéniable que GitHub Actions est un excellent choix.

Cependant, GitHub Actions n'est pas toujours le meilleur choix. En particulier, si vous êtes un développeur dans l'une des situations suivantes, mettre en œuvre un Webhook GitHub peut être beaucoup plus attrayant.

  • Développeurs individuels ou petites équipes soucieux des coûts : GitHub Actions est presque illimité et gratuit pour les dépôts publics, mais les dépôts privés facturent si vous dépassez un certain quota gratuit (minutes et stockage). Si vous souhaitez complètement éviter toute possibilité de coûts imprévus, la mise en œuvre par vous-même est la solution.

  • Développeurs utilisant un serveur de mise en scène autohébergé (comme un Raspberry Pi 5) : Si vous possédez déjà un serveur physique (y compris un VPS ou une instance cloud), il est plus efficace d'exploiter au maximum les ressources de votre propre serveur sans nécessairement emprunter un environnement virtuel (Runner) de GitHub. Recevoir et déployer le code directement sur votre serveur est plus économique et optimisé en termes d'utilisation des ressources.

  • Développeurs souhaitant un contrôle total et une liberté sur la logique de déploiement : Bien que GitHub Actions utilise des workflows et des actions standardisées, en mettant en œuvre un webhook personnalisé, vous pouvez concevoir et contrôler chaque aspect de votre script de déploiement selon vos besoins. Cela présente des avantages lorsque vous avez besoin de logiques personnalisées complexes spécifiques à certains environnements ou d'une intégration parfaite avec un pipeline existant.

Dans cette série, nous allons aborder en détail comment implémenter la logique de déploiement directement sur mon serveur en utilisant GitHub Webhook. Nous nous adresserons aux développeurs Python et, plus particulièrement, nous allons utiliser le cadre web simple mais puissant FastAPI pour construire le point de terminaison Webhook. Bien que le DRF (Django REST Framework) soit également un excellent choix, étant donné que la logique de gestion des requêtes Webhook est très légère, je pense que FastAPI est la meilleure option. Il n'est pas nécessaire de conduire une voiture de sport juste pour faire des courses au supermarché ; une petite voiture est suffisante.

Éléments de base nécessaires pour construire un système de déploiement automatique

Nous commencerons la mise en œuvre réelle dans le prochain épisode. Dans cet épisode, je vais résumer les éléments à préparer à l'avance pour un déroulement fluide.

  1. Dépôt GitHub :

    • Vous aurez besoin d'un dépôt GitHub qui contient un projet Python sur lequel vous souhaitez appliquer le déploiement automatique. (Les dépôts publics et privés sont tous deux acceptables.)

    • Le déploiement commencera chaque fois que vous pousserez du code vers ce dépôt.

  2. Serveur de mise en scène (Self-hosted Server) :

    • Un serveur réel où le déploiement aura lieu est nécessaire. Un Raspberry Pi 5, un VPS privé, ou une instance cloud (comme AWS EC2 ou GCP Compute Engine) fonctionnent tous bien.

    • Il doit être accessible de l'extérieur (GitHub) via une adresse IP publique ou un domaine. (Faites attention aux réglages du pare-feu.)

    • Nous recommandons un système d'exploitation basé sur Ubuntu Server ou un environnement Linux similaire.

    • Installation de Docker : Docker doit être préalablement installé sur le serveur pour permettre à l'application déployée d'être construite ou exécutée dans un conteneur Docker.

  3. Environnement de développement Python :

    • Python 3.8 ou version supérieure doit être installé sur le serveur de mise en scène. (Utilisation d'un environnement virtuel recommandée)

  4. Git :

    • Git doit être installé sur le serveur de mise en scène. Il sera utilisé pour récupérer le code le plus récent du dépôt GitHub avec la commande git pull.

  5. FastAPI et Uvicorn :

    • Vous aurez besoin de FastAPI, le cadre de mise en œuvre d'un point de terminaison Webhook Python, et Uvicorn, un serveur ASGI. Nous aborderons l'installation et la configuration de base dans l'épisode suivant.

  6. Clé SSH :

    • Pour accéder en toute sécurité au dépôt GitHub et récupérer le code, une configuration de clé SSH est nécessaire sur le serveur de mise en scène. La majorité d'entre vous devrait déjà avoir enregistré une clé SSH sur son compte. (Si ce n'est pas le cas, veuillez l'enregistrer sur GitHub. L'utilisation d'une Deploy key est généralement recommandée.)

  7. Compréhension d'un serveur web (Nginx ou Apache2) et de la configuration de domaine/HTTPS :

    • Il est généralement recommandé que GitHub Webhook communique via HTTPS pour un transfert sécurisé. Il est donc fortement recommandé de préparer à l'avance un sous-domaine comme deployer.example.com pour recevoir le webhook, et d'obtenir et d'appliquer un certificat HTTPS (par exemple, un certificat gratuit via Let's Encrypt).

    • Il est peu probable que quelqu'un expose directement une application FastAPI au port forwarding sur le routeur ISP de l'internet, mais pour ceux qui pourraient, je le mentionne ici. Il est courant et sécuritaire de configurer la demande de webhook pour qu'elle soit transmise à l'application FastAPI en utilisant un serveur web comme Nginx ou Apache2 comme proxy inverse. Veuillez connecter votre application via un programme serveur. Une compréhension de base et de l'expérience en configuration de ce genre de système sera un grand atout.

  8. Compréhension des services Systemd (optionnel mais recommandé) :

    • Ce serveur Webhook FastAPI doit rester en fonctionnement en permanence sur le serveur de mise en scène. Pour cela, il est recommandé de s'enregistrer dans le Service Systemd pour démarrer automatiquement au redémarrage du serveur et faciliter la gestion du service (démarrage/arrêt/redémarrage).

    • Remarque : Construire une logique de déploiement complexe nécessitant d'exécuter des commandes git ou docker directement à l'intérieur d'un conteneur Docker ne correspond pas à l'objectif de conception des conteneurs et nécessite des configurations complexes comme docker-in-docker ou docker-out-of-docker, qui ne sont pas sécurisées non plus. Si Git et Docker sont déjà installés sur le serveur, il est beaucoup plus efficace et simple de faire fonctionner le serveur Webhook FastAPI comme Service Systemd et d'utiliser directement les commandes git et docker dans votre script de déploiement. Cette série se concentrera sur cette approche.

Maintenant que tous les préparatifs sont terminés. Dans le prochain épisode, nous allons construire un point de terminaison Webhook FastAPI sur le serveur de mise en scène préparé, configurer GitHub Webhook et détailler le processus pour réussir le premier déploiement automatique. Restez à l'écoute !