DevOps Self-Service Centric GitHub Actions Workflow Orchestration | de Wenqi Glantz

DevOps Self-Service Centric GitHub Actions Workflow Orchestration | de Wenqi Glantz | janvier 2023

Comment orchestrer les workflows GitHub Actions pilotés par l’immuabilité des images

L’adoption de GitHub Actions a augmenté ces dernières années. Selon une enquête de The Software House pour l’état du frontend, GitHub Actions occupe le devant de la scène dans les outils CI/CD, avec plus de 56 % en 2022 contre 35 % en 2020. Cela montre que davantage de développeurs sont passés à GitHub Actions comme outil CI/CD à leur époque. aujourd’hui.

Source des images : https://tsh.io/state-of-frontend/

Guidés par l’architecture de pipeline en libre-service DevOps, nous avons exploré la structure du projet Terraform et ses modules réutilisables dans notre article précédent. Cet article explique comment orchestrer les pipelines d’applications avec GitHub Actions. Nous allons nous concentrer sur le rectangle en surbrillance rouge dans le diagramme ci-dessous.

Flux de travail réutilisable des actions GitHub

Dans la pratique centrée sur le libre-service de DevOps, la réutilisabilité est essentielle. Tout comme les modules Terraform réutilisables, nous pouvons avoir des flux de travail GitHub Actions réutilisables dans nos pipelines CI/CD d’application.

Du point de vue avec/sans état, les workflows réutilisables sont sans état. Les flux de travail appelant de nombreuses applications différentes peuvent appeler un flux de travail réutilisable.

J’ai publié il y a quelques mois un article intitulé A Deep Dive into GitHub Actions’ Reusable Workflows, dans lequel j’ai exploré les étapes détaillées pour rendre un workflow GitHub Actions réutilisable, comment appeler un workflow réutilisable et comment transmettre des paramètres d’entrée et des secrets à le workflow réutilisable. Un exemple de code a été partagé dans cet article, et il est répertorié au bas de cet article. Je vous recommande fortement de consulter cet article si vous êtes nouveau dans le flux de travail réutilisable de GitHub Actions.

Une fois que vous aurez commencé à utiliser des flux de travail réutilisables dans vos projets, vous ne regarderez plus en arrière, car les flux de travail réutilisables vous font gagner beaucoup de temps et d’efforts pour déployer les flux de travail CI/CD de vos applications et éliminer les problèmes de maintenance.

L’immuabilité des images de conteneurs fait référence à la création et à l’utilisation d’images de conteneurs qui ne peuvent pas être modifiées après leur création. Une fois qu’une image est construite et poussée dans un registre, elle ne doit pas être modifiée. Au lieu de cela, une nouvelle image doit être créée avec les modifications souhaitées et déployée.

Le principal avantage de l’immuabilité de l’image de conteneur est sa prévisibilité. Lorsque l’immuabilité des images est appliquée, vous pouvez être sûr que votre application se comporte comme prévu dans des environnements tels que la mise en scène et la production. L’immuabilité de l’image vous offre également la tranquillité d’esprit de revenir à une balise d’image précédente en cas d’erreur, car vous savez que la balise d’image précédente est immuable et n’a pas été altérée par les versions après sa publication. Dans l’ensemble, l’immuabilité contribue à assurer la cohérence, la sécurité et la reproductibilité des images de conteneurs.

Le déclenchement de CI avant chaque CD pour chaque environnement ne garantit pas l’immuabilité de l’image. Pourquoi? Chaque CI peut produire une image différente même si vous n’avez pas modifié votre code source. Si vous avez des mises à niveau de dépendance et une fusion automatique automatisées par des outils tels que GitHub dependabot, votre code source varie en fonction du moment où vos dernières mises à niveau de dépendance ont eu lieu. Pour cette raison, l’image construite il y a une semaine et l’image construite aujourd’hui pourraient être deux images différentes malgré l’absence de modifications manuelles du code entre les deux.

Pour renforcer l’immuabilité de l’image, nous devons séparer le CI du CD, en les transformant en deux workflows isolés. CI construit et pousse l’image vers ECR, et CD doit être suffisamment intelligent pour savoir exactement quelle balise d’image utiliser pour extraire cette image immuable. Les équipes qui avaient l’habitude d’utiliser l’horodatage de la date ou Git SHA dans le cadre de la balise d’image sont désormais confrontées à un dilemme : comment savoir quelle balise d’image utiliser lorsque vous déclenchez le CD ? Vous pouvez essayer de tracer votre journal de débogage de flux de travail CI pour déterminer quelle balise d’image a été publiée sur ECR, mais cela va à l’encontre de l’objectif de l’automatisation. Tout effort manuel dans ce flux n’est pas une solution souhaitable.

En fin de compte, cela se résume à : comment vous assurez-vous que votre balise d’image est immuable ?

Continuez à lire pour le découvrir.

Supposons que vous développiez une application Spring Boot en utilisant Maven comme outil de construction, et que votre application sera déployée dans trois environnements : développement, staging et prod. L’automatisation de Maven Release est la clé pour maintenir l’immuabilité de l’image du conteneur. Examinons de plus près le fonctionnement de Maven Release.

Les détails de ce tableau sont expliqués ci-dessous — schéma de l’auteur

Le diagramme ci-dessus devrait être assez explicite. Maven Release automatise la publication des balises et fait passer la version pom à la prochaine version de développement. Si vous exprimez le flux de publication Maven ci-dessus dans un flux de travail réutilisable GitHub Actions, vous aurez l’exemple de flux de travail de publication suivant.