Mise en place d'une CI/CD sur ECS Fargate avec GitOps
La solution d'orchestration retenue par le client est AWS ECS Fargate. Cette solution est nettement moins sophistiquée que Kubernetes mais elle présente l'avantage d'être simple à mettre en oeuvre et de ne nécessiter quasiment aucune maintenance. Cependant contrairement à Kubernetes il n'existe pas un écosystème d'outils comme ArgoCD permettant de faire du GitOps facilement.
La solution retenue a été de mettre en place une approche GitOps. GitOps est une approche "déclarative" de la gestion de l'infrastructure. Contrairement à ce qui se faisait historiquement avec Jenkins où on poussait une version après l'autre vers la production. GitOps propose de "décrire" l'ensemble des versions qu'on veut voir déployées sur le système. On utilise pour ça un repo Git contenant une description de l'ensemble des versions d'application à déployer. Un système externe va automatiquement analyser le contenu du repo Git à chaque nouveau commit et sera responsable de s'assurer que les versions déployées correspondent à celles décrites dans le repo. Dans l'écosystème Kubernetes c'est ArgoCD qui peut jouer ce rôle d'agent. Le principale avantage de cette approche est qu'il n'y a qu'une seule source de vérité : le repo Git contient à chaque instant l'état souhaité du système. Grâce à cette source de vérité il est plus facile de comprendre d'où vient le problème en cas d'échec d'un déploiement.
Comme Kubernetes est nativement "déclaratif" la mise en place de GitOps est relativement plus simple. C'est malheureusement moins le cas avec Elastic Container Service qui a une approche beaucoup plus "impérative". Tout déploiement dans ECS implique la création au préalable d'une tâche (Task). Une tâche contient la liste des conteneurs Docker à déployer ainsi que leurs configurations. Une tâche présente l'avantage d'être strictement immutable (elle ne peut jamais être modifiée une fois qu'elle a été créée). Le repo GitOps va donc au final uniquement contenir une liste de version de tâches à déployer. La seule "difficulté" par rapport à Kubernetes est qu'il faut mettre en place un mécanisme au niveau de chaque application pour qu'à chaque build d'une image Docker une Task correspondante soit crée dans le cluster ECS.
L'utilisation des Github Actions permet de faire ça de façon assez simple : à chaque merge ou commit un build Docker se déclenche et va pousser une nouvelle version de l'image dans un registry Docker. Une fois l'image poussée une nouvelle tâche sera crée dans le cluster ECS (via AWS CLI). Github Actions pourra ensuite commiter sur une branche "staging" du repo GitOps l'id de la tâche nouvellement créée
Un système de branche sur le repo GitPops permet de décrire l'état des différents environnments (staging, dev, prod) faire un déploiement revient à faire une pull-request sur de la branche staging sur la branche prod. L'action de déploiement à proprement parler se fait via une Github actions qui va déployer les ids de tâches qu'il trouve dans le repo sur le cluster ECS via AWS CLI.
L'approche GitOps permet d'avoir une visibilité très claire de l'état cible du système passé et présent. L'immutabilité apporté par Git permet d'avoir une vision indiscutable des différentes évolutions. Quoique moins performante en terme de vitesse de déploiement que des solutions comme ArgoCD + Kubernetes le temps de release reste de l'ordre de quelques minutes ce qui est acceptable
© 2025 Veskleg Conseil - Entreprise Individuelle domiciliée au 35 rue Jean Delalande, 35400 Saint-Malo, enregistrée au RCS de Saint-Malo sous le numéro 988 516 860
Version: 1.4.0