Architecture de pipeline en libre-service DevOps et sa règle 3–2–1 | de Wenqi Glantz | janvier 2023

Une vue d’ensemble de l’architecture de haut niveau du pipeline en libre-service

Que vous l’appeliez libre-service DevOps, démocratisation de DevOps ou ingénierie de plate-forme, l’objectif est le même : donner aux développeurs plus d’accès, de contrôle et de propriété sur les pipelines pour augmenter la productivité.

Appelons-le « libre-service DevOps » dans cet article pour être cohérent dans nos termes.

Pourquoi un changement radical de mentalité ? Commençons par explorer notre architecture de pipeline en libre-service à un niveau élevé.

Le diagramme ci-dessous illustre une architecture de pipeline générique en libre-service basée sur une règle 3–2–1 (un terme que j’ai inventé en dessinant le diagramme) : Trois types de code source. Deux types de canalisations. Une colle d’intégration de pipeline. Je mentionne le mot « générique » principalement parce qu’il existe de nombreuses variantes de l’architecture du pipeline en fonction des types de charges de travail. Cette conception de pipeline générique est plus adaptée à l’architecture des microservices, pas aux charges de travail sans serveur. L’architecture de pipeline sans serveur devrait être encore plus simple.

Plongeons-nous pour voir ce qu’implique exactement cette règle 3–2–1.

Les trois types de code source suivants résideront dans le même référentiel GitHub pour votre microservice.

• Code Terraform : oui, nous avons du code Terraform résidant dans les référentiels d’applications. Ceci est peut-être le plus difficile à accepter pour certains, car nous avons l’habitude de centraliser le code Terraform dans un référentiel DevOps particulier, aucun développeur n’y étant autorisé. Désormais, avec le libre-service DevOps, nous abandonnons partiellement le code Terraform aux développeurs dans les dépôts d’application. Pourquoi partiellement ? car nous conservons les modules réutilisables Terraform dans un dépôt centralisé. Plus d’informations sur les modules réutilisables Terraform et la structure du projet Terraform dans une future histoire.
• Code source du projet : il s’agit de notre bon vieux code source pour notre application, que ce soit Java, Node.js, Python ou d’autres langages de programmation.
• Code de workflow GitHub Actions : pour ceux qui connaissent GitHub Actions, ce n’est pas une surprise, car les fichiers yml du workflow d’actions doivent résider dans le .github/workflows répertoire à la racine de notre application.

• Pipeline d’infrastructure : IaC avec Terraform. Choisir Terraform ici est principalement dû à sa nature cloud-agnostic et open source. Un flux de travail GitHub Actions Terraform peut lancer le pipeline d’infrastructure pour provisionner des ressources cloud telles que des services dans AWS.
• Pipelines d’application : nos pipelines d’application CI/CD, lancés par les workflows GitHub Actions. Ce sont les pipelines pour créer, tester, analyser et déployer nos applications dans nos fournisseurs de cloud.

• Comment lier les pipelines d’infrastructure aux pipelines d’applications pour les faire fonctionner ensemble de manière transparente ? Nous avons besoin d’une colle pour intégrer ces deux types de pipelines. Et cette colle est l’automatisation de la création de secrets GitHub. Une fois le provisionnement de l’infrastructure réussi, nous pouvons utiliser Terraform pour automatiser la création de secrets GitHub en appelant le fournisseur GitHub. Remarquez les flèches à double extrémité pour le pipeline d’infrastructure dans le diagramme ci-dessus, car les sorties Terraform pour les secrets sont automatiquement insérées dans GitHub. Cela élimine la création manuelle de secrets et permet aux pipelines d’application de lancer CI/CD pour l’environnement GitHub spécifié avec les secrets associés à cet environnement GitHub particulier fourni par Terraform via le pipeline d’infrastructure. Ceci accomplit l’intégration de pointe de bout en bout de ces deux types de pipelines.

Nous approfondirons les structures de projet pour Terraform, ses modules réutilisables et l’orchestration du flux de travail GitHub Actions dans les futures histoires. Pour l’instant, prenons un aperçu de haut niveau de ce à quoi ressemblent les deux types de pipelines, de ce qu’ils font et des étapes détaillées impliquées.

Compte tenu de sa nature cloud-agnostique et open source, Terraform est l’outil de notre choix pour construire notre infrastructure en tant que code (IaC).

Flux de travail Terraform GitHub Actions

Voici un aperçu de haut niveau de ce à quoi ressemble notre workflow Terraform GitHub Actions :

Noter: Le diagramme ne décrit pas les flux alternatifs, comme pour terraform destroy. Vous pouvez toujours ajouter des flux alternatifs selon les exigences de votre pipeline.

Nos pipelines d’applications sont développés à l’aide de GitHub Actions. Vous trouverez ci-dessous un aperçu de haut niveau des deux pipelines typiques (CI et CD pour les microservices). Ce ne sont que des exemples. Vos workflows peuvent contenir différentes étapes selon la nature de vos applications.

Flux de travail des actions GitHub du microservice CI

Flux de travail des actions GitHub du CD Microservice

Voici quelques points clés à souligner :

• Le code Terraform et le code de workflow GitHub Actions résident dans le référentiel GitHub de l’application.
• Le code Terraform de l’application appelle les modules réutilisables Terraform, qui résident dans un référentiel GitHub centralisé.
• Le pipeline d’infrastructure peut être lancé soit par un déclencheur manuel, soit par la création/fusion PR du code Terraform à l’aide du workflow GitHub Actions Terraform pour provisionner les ressources cloud.
• Une fois le provisionnement de l’infrastructure réussi, Terraform automatise la création de secrets GitHub en appelant le fournisseur GitHub. Remarquez les flèches à double extrémité pour le pipeline d’infrastructure dans le diagramme ci-dessus lorsque les sorties Terraform pour les secrets sont automatiquement insérées dans GitHub. Cela élimine la création manuelle de secrets.
• Lors de la création/fusion PR du code d’application, ou du déclenchement manuel, les pipelines d’application sont déclenchés par les flux de travail GitHub Actions pour CI et CD pour créer, tester, analyser et déployer notre application dans le cloud.

Le libre-service DevOps a gagné du terrain ces dernières années, principalement en raison de la tendance croissante à l’architecture cloud native. Cet article s’est concentré sur la conception globale du pipeline en libre-service et les principaux ingrédients du libre-service DevOps. La règle 3–2–1 décrit l’architecture globale d’une pratique DevOps en libre-service. J’espère que vous trouverez cette histoire utile.

Bon codage !