10 articles tagués avec « CI/CD »

Un hôte unique qui fait tourner une vingtaine de services Docker Compose, un dépôt Git qui contient un dossier par stack : la question du déploiement se pose dès la deuxième modification. Se connecter en SSH, faire un git pull, relancer docker compose up -d dans le bon dossier fonctionne, mais l'opération est manuelle, oubliable et non tracée. Cet article décrit un workflow GitHub Actions qui déploie, à chaque push sur la branche principale, uniquement les stacks modifiées, sans orchestrateur et sans agent installé sur l'hôte.

Un fichier Compose qui référence une vingtaine d'images vieillit sans bruit : nouvelles versions, correctifs de sécurité, changements de comportement, rien dans le dépôt ne le signale. Vérifier les registres à la main ne tient pas dans la durée ; utiliser latest rend les mises à jour invisibles et non reproductibles. Renovate automatise cette veille : il analyse le dépôt, interroge les registres et ouvre une pull request par mise à jour disponible, que la CI valide avant fusion manuelle ou automatique.

Déployer une application web (un frontend, un backend, une base de données) enchaîne toujours les mêmes étapes : construire les images, les publier, provisionner l'infrastructure, déployer sur le cluster. Automatiser cet enchaînement du git push à l'application en ligne est l'objet d'un pipeline CI/CD. Cet article décrit une telle chaîne, bâtie avec GitHub Actions, Terraform et Helm sur AWS EKS.

GitHub Container Registry (GHCR) est le registry d'images Docker intégré à GitHub. Il stocke les images au même endroit que le code source, partage la gestion des accès avec les dépôts GitHub, et s'intègre nativement dans les workflows GitHub Actions via le token GITHUB_TOKEN.

Quand une séquence de steps se répète dans plusieurs workflows (checkout + setup + build, ou authentification + push Docker), la factoriser dans une action évite la duplication et centralise la maintenance. Une correction ou une mise à jour s'applique à tous les workflows consommateurs sans toucher chacun individuellement.

Quand plusieurs dépôts partagent la même stack technique, chacun maintient souvent une copie quasi-identique de ses workflows CI/CD. Une modification (nouvelle version d'un outil, changement de runner, ajout d'une étape de sécurité) doit être répercutée manuellement dans chaque dépôt. Un dépôt centralisé de workflows mutualisés résout ce problème : les dépôts consommateurs appellent les workflows du dépôt central, qui devient le seul point de maintenance.

Sans automatisation, livrer du code en production est un processus manuel : un développeur fusionne une branche, lance les tests à la main, construit l'image Docker, se connecte au serveur, déploie. Chaque étape est une occasion d'oublier quelque chose, de sauter un test, ou de déployer une version qui n'a pas été vérifiée. À mesure que l'équipe et le rythme de livraison augmentent, ce processus ne tient plus.

Un runner auto-hébergé classique est une machine fixe qui exécute les jobs séquentiellement. Si dix workflows se déclenchent simultanément, neuf attendent. Actions Runner Controller (ARC) est un opérateur Kubernetes qui provisionne des pods runner à la demande (un pod par job) et les supprime à la fin de l'exécution. La capacité s'adapte automatiquement à la charge.

Les runners hébergés par GitHub (ubuntu-latest) sont éphémères, gérés par GitHub, et consomment le quota de minutes de l'organisation. Les runners auto-hébergés tournent sur des machines contrôlées (serveur on-premise, VM cloud, Raspberry Pi) et n'ont pas de quota. Ils donnent accès à des ressources locales : réseau privé, GPU, caches persistants, outils propriétaires.

Un workflow GitHub Actions est un fichier YAML placé dans .github/workflows/. Il orchestre des jobs qui s'exécutent sur des runners en réponse à des événements. Comprendre les primitives disponibles (matrix, container, artefacts, conditions) permet de construire des pipelines maintenables sans duplication.