Actualités

AWS Re:Invent : Re:Cap sur GitOps

AWS Re:Invent Agyla.cloud
14 décembre, 2020

Le AWS Re:Invent, 3 semaines de conférences online proposées par AWS sur des thématiques techniques autour du Cloud. L’occasion de découvrir les nouveaux enjeux, les nouveaux outils mais aussi les bonnes pratiques à adopter dans un environnement Cloud.

Dans cet article, un de nos consultants Agyla.cloud résume les annoncent autour de la session « Up-level your AWS infrastructure automation with GitOps« , présentée par Brendan O’Leary, Sr. Developer Evangelist et William Chia, Sr. Product Marketing Manager Cloud Native & GitOps.

Un grand merci pour ce partage de connaisances !

…..

Optimisez l’automatisation de votre infrastructure AWS avec GitOps

  1. C’est quoi GitOps ? :

GitOps est un moyen d’implémenter le déploiement continu pour les applications cloud natives. Il se concentre sur une expérience centrée sur les développeurs lors de l’exploitation d’une infrastructure, en utilisant des outils que les développeurs connaissent déjà, notamment Git et les outils de déploiement continu.

L’idée principale de GitOps est d’avoir un référentiel Git qui contient toujours des descriptions déclaratives de l’infrastructure actuellement souhaitée dans l’environnement de production et un processus automatisé pour que l’environnement de production corresponde à l’état décrit dans le référentiel. Si vous souhaitez déployer une nouvelle application ou mettre à jour une application existante, il vous suffit de mettre à jour le référentiel.

Le processus automatisé gère tout le reste. C’est comme avoir un régulateur de vitesse pour gérer vos applications en production.

Comment les équipes mettent-elles GitOps en pratique?

GitOps n’est pas un produit, un plugin ou une plate-forme unique. GitOps est un framework qui aide les équipes à gérer l’infrastructure informatique via des processus qu’elles utilisent déjà dans le développement d’applications. Pour mettre GitOps en pratique, il a besoin de trois composants de base:

@AWSre:Invent

IaC – GitOps utilise un référentiel Git comme source unique de vérité pour les définitions d’infrastructure. Git est un système de contrôle de version open source qui suit les modifications de gestion de code, et un référentiel Git est un dossier .git dans un projet qui suit toutes les modifications apportées aux fichiers d’un projet au fil du temps. L’infrastructure en tant que code (IaC) est la pratique consistant à conserver toute la configuration de l’infrastructure sous forme de code. L’état souhaité réel peut ou non être stocké sous forme de code (par exemple, nombre de répliques, de pods).

MR – GitOps utilise des demandes de merge (MR) comme mécanisme de changement pour toutes les mises à jour de l’infrastructure. Le MR est l’endroit où les équipes peuvent collaborer via des examens et des commentaires et où les approbations formelles ont lieu. Un merge est validée dans votre branche principale (ou trunk) et sert de journal des modifications pour l’audit et le dépannage.

CI / CD – GitOps automatise les mises à jour de l’infrastructure à l’aide d’un flux de travail Git avec intégration continue et livraison continue (CI / CD). Lors de lu merge d’un nouveau code, le pipeline CI / CD applique la modification de l’environnement. Toute dérive de configuration, telle que des modifications manuelles ou des erreurs, est écrasée par l’automatisation GitOps afin que l’environnement converge vers l’état souhaité défini dans Git. GitLab utilise des pipelines CI / CD pour gérer et implémenter l’automatisation GitOps, mais d’autres formes d’automatisation telles que les opérateurs de définitions peuvent également être utilisées.

  1. Comment GitOps fonctionne?

Il existe deux modèles pour implémenter Gitops :

Modèle en push

Le modèle en push fonctionne avec les outils classiques de CI/CD (Jenkins, GitLab Travis, Circle-CI, Spinnaker…). Les codes applicatifs et ceux de l’infrastructure sont versionnés dans des repositories git distincts.

Le déploiement d’une nouvelle version de l’application se déroule de façon suivante :

  • La présence d’un nouveau commit déclenche le pipeline de build.
  • Le pipeline de build lance toutes les tests (unitaires, intégrations, etc.).
  • Le succès des tests lance le build d’un nouveau conteneur.
  • Le pipeline de build se termine avec la modification du repository de l’environnement, en mettant à jour la version de l’application.
  • Cette modification va déclencher le pipeline de déploiement pour remplacer l’ancienne image par la nouvelle.
Modèle en push @AWSReinvent

Lorsque l’on apporte une modification du repository de l’infrastructure, seul le pipeline de déploiement sera déclenché pour appliquer les nouvelles modifications. 

Dans cette approche, nous ne pouvons détecter s’il existe une divergence automatiquement entre le git et l’infrastructure. Il faut ajouter du monitoring pour pouvoir détecter cette différence et réagir pour réduire cet écart.

Modèle en pull

Le modèle en pull fonctionne avec les outils classiques de CI (Jenkins, GitLab Travis, Circle-CI…) et des outils modernes de CD (ArgoCD, Flux, JenkinsX…).

Les codes applicatifs et d’infrastructure sont versionnés dans des repositories git distincts.

Le déploiement d’une nouvelle version de l’application se déroule de façon suivante:

  • La présence d’un nouveau commit déclenche la pipeline de build.
  • Le pipeline de build lance tous les tests (unitaires, integrations, etc.).
  • Le succès des tests lance le build d’un nouveau conteneur.
  • Le pipeline de build se termine avec la modification de l’environnement, en mettant à jour la version de l’application.
  • L’opérateur détecte un écart entre le repo git et l’environnement.
  • L’opérateur applique un patch pour éliminer cet écart. Il va chercher cette image du registry et la déployer.
modèle en pull @AWSReinvent

Le pipeline de déploiement peut être déclenché par un écart entre l’état souhaité et l’état actuel : cela peut provenir d’un nouveau commit dans le repository de l’environnement ou d’une modification accidentelle dans l’environnement.

S’il y a eu des modifications opérées manuellement, l’opérateur va remettre en conformité avec celui décrit dans Git. Ainsi, nous sommes assurés qu’il n’y a pas eu de modification manuelle et que l’infrastructure reste auditable via Git. Ce qui offre un avantage non négligeable par rapport au modèle en push.

Pourquoi utiliser GitOps?

Déployez plus rapidement plus souvent

Chaque technologie de déploiement continu promet de rendre le déploiement plus rapide et vous permet de déployer plus souvent. La particularité de GitOps est que vous n’avez pas besoin de changer d’outil pour déployer votre application. De toute façon, tout se passe dans le système de contrôle de version que vous utilisez pour développer l’application.

Récupération d’erreur simple et rapide

Avec GitOps, vous avez un historique complet de l’évolution de votre environnement au fil du temps. Cela rend la récupération d’erreur aussi simple que d’émettre un retour git et de surveiller la restauration de votre environnement.

Gestion plus simple des informations d’identification

GitOps vous permet de gérer complètement les déploiements depuis l’intérieur de votre environnement. Pour cela, votre environnement n’a besoin que d’accéder à votre référentiel et à votre registre d’images. Vous n’êtes pas obligé de donner à vos développeurs un accès direct à l’environnement.

Déploiements auto-documentés

Avec GitOps, chaque modification de n’importe quel environnement doit se faire via le référentiel. Vous pouvez toujours consulter la branche principale et obtenir une description complète de ce qui est déployé et où, ainsi que l’historique complet de chaque modification apportée au système.

Partage des connaissances dans les équipes

L’utilisation de Git pour stocker des descriptions complètes de votre infrastructure déployée permet à tous les membres de votre équipe de vérifier son évolution au fil du temps. Avec d’excellents messages de validation, tout le monde peut reproduire le processus de réflexion de l’évolution de l’infrastructure et trouver facilement des exemples de mise en place de nouveaux systèmes.

Demo : comment utiliser l’infrastructure comme code pour gérer les conteneurs sur AWS

La démonstration de la session montre comment utiliser l’infrastructure comme code pour gérer les conteneurs sur AWS.

Liens utiles pour plus de renseignements :

https://about.gitlab.com/topics/gitops/

https://virtual.awsevents.com/media/1_ql8om2k2

https://gitlab.com/chia-gitops-demo

A bientôt pour de nouvelles actualités !