Cette page a une évaluation moyenne de %r sur un maximum de 5 étoiles. Au total, %t évaluations sont disponibles.
Temps de lecture 4 minutes Temps de lecture 4 minutes
Créé le 29.03.2021

GitOps – avec pull requests dans la production

GitOps facilite la gestion des applications dans un environnement de conteneurs. Christian Bürgi, Architecture Owner dans le système Acquiring de PostFinance, explique comment et pourquoi GitOps est utilisé dans l’un de ses secteurs d’activité.

Malgré l’existence de plateformes telles que Kubernetes, qui répliquent l'orchestration des conteneurs, il n’est pas toujours simple de fournir et de gérer des applications conteneurisées exécutées sur des systèmes de clusters ou dans le cloud. GitOps est une solution qui vise à utiliser les expériences et les outils issus du travail des développeurs pour la gestion des applications. Elle est régie par quatre principes de base:

  • Description déclarative: les ressources sont décrites dans un langage formel et dans leur état souhaité.
  • Automatisation: la mise en œuvre des descriptions issues du dépôt dans l’environnement d’exécution doit être intégralement automatisée. Elle doit pouvoir être reproduite et générer le même résultat même si elle est exécutée à plusieurs reprises.
  • «Single Source of Truth»: un état du système doit être décrit de manière globale et univoque. Une seule source est applicable pour récapituler l’état général du système.
  • Réconciliation: les agents de logiciels comparent l’état réel du système à l’état souhaité. Des actions adéquates sont lancées dès que des divergences apparaissent.

 

GitOps en tant que modèle d’exploitation pour Kubernetes

Le schéma présente le modèle d’exploitation GitOps, au sein duquel l’état souhaité d’un système est décrit dans un dépôt Git comme «Single Source of Truth» (source unique de vérité). Toutes les modifications sont effectuées au niveau des branches, puis examinées et fusionnées par le biais d’une pull request. Un opérateur GitOps synchronise cet état de manière automatisée sur le cluster Kubernetes et compare en permanence l’état réel de ce dernier avec le dépôt Git.
Dans le modèle d’exploitation GitOps, l’état souhaité d’un système est décrit dans un dépôt Git comme «Single Source of Truth». Toutes les modifications sont effectuées au niveau des branches, puis examinées et fusionnées par le biais d’une pull request. Un opérateur GitOps synchronise cet état de manière automatisée sur le cluster Kubernetes et compare en permanence l’état réel de ce dernier avec le dépôt Git.

Pour garantir l’exploitation d’un système logiciels, il est impératif de mettre en place une chaîne de livraison permettant non seulement de livrer les versions des logiciels, mais aussi d’adapter les configurations. Ainsi, une connexion entre la Continuous Delivery (CD) et le déploiement effectif ainsi que l’exploitation de l’application est établie. L’approche de Kubernetes consiste à décrire les ressources de manière déclarative. Pour ce faire, on décrit l’état de l’application en marche (par  ex. 3 instances de l’application X dans la version Y avec 2 CPU et 500 MB RAM) et Kubernetes veille à ce que les composants correspondants soient lancés. Ainsi, Kubernetes obéit déjà aux deux premiers principes de base de GitOps.

Comme le nom laisse entendre, c’est la gestion des versions de Git qui est utilisée dans GitOps en tant que «Single Source of Truth». Ainsi, l’état du système souhaité est automatiquement déposé dans un endroit qui lui est dédié de manière transparente, traçable et versionnée. Grâce à cette traçabilité, il est possible de suivre les modifications, ce qui rend trivial tout retour à une ancienne version. Le fait que le concept des branches permette d'examiner les modifications au moyen de pull requests est également un avantage considérable de Git. Ainsi, les erreurs peuvent être repérées avant de toucher le système effectif.

Le quatrième principe de base (et le plus essentiel) de GitOps consiste à comparer l’état de l’exécution sur le cluster de Kubernetes à l’état souhaité dans le dépôt Git. Pour ce faire, on utilise ce que l’on appelle un opérateur GitOps. Il s’agit d’un composant logiciel spécialisé qui est installé sur Kubernetes et qui assume ces tâches de manière automatisée. PostFinance utilise l’outil «Argo CD» à cet effet.

Avantages de GitOps

  • Augmentation de la productivité: l’automatisation systématique permet au développeur/à l’exploitation de se concentrer sur la configuration essentielle. Le déroulement automatique optimise les délais d’exécution.
  • Shared Tooling: avec Git, le développeur et l’exploitation utilisent ensemble un outil très éprouvé.
  • Stabilité et fiabilité: toutes les modifications sont traçables. Les réinitialisations deviennent triviales et, en cas de sinistre, une récupération complète peut être effectuée en peu de temps grâce à une description déclarative.
  • Cohérence et standardisation: GitOps est un modèle d’exploitation et standardise le processus de déploiement.

Raisons pour lesquelles nous utilisons GitOps au sein du service IT pour le domaine du commerce numérique

Au sein du service IT de PostFinance, nous avons instauré le premier grand cas d’utilisation de GitOps pour le domaine du commerce numérique car, ayant migré sur la plateforme Kubernetes («on-premise»), nous avions besoin d’une solution pour exploiter de manière optimale nos systèmes à disponibilité maximale. Nous avons opté pour GitOps, encore relativement récent, car il devient un standard dans le déploiement d’applications sur de tels clusters. Depuis l’automne dernier, nous travaillons intégralement sur cette pile dans le commerce numérique.

Depuis mars 2020, nous gérons nos workloads Kubernetes via GitOps. Les expériences faites durant cette période sont toutes positives. D’une part, nous apprécions la facilité avec laquelle nous pouvons déployer de nouveaux workloads (fonctionnalités, services, etc.) sur le système. Le processus simplifie énormément l’exécution continue et rapide des modifications. D’autre part, nous pouvons compter sur des systèmes fiables, et ce malgré ce flux de modifications. La recherche d’écarts de configuration entre les divers environnements se cantonne à la configuration dans le dépôt Git. La réconciliation de l’opérateur nous aide à garder le contrôle sur les systèmes en permanence en détectant les états indésirables et en les résolvant de manière standardisée.

Enfin, nous sommes soumis à des régulations strictes dans le domaine du commerce numérique en ce qui concerne la traçabilité et la séparation des fonctions («Segregation of Duties»). Grâce à GitOps, nous sommes parvenus à concilier toutes ces prescriptions avec les réflexions DevOps. Aujourd’hui, les changements productifs ne sont pour nous rien de plus que de simples pull requests qui arrivent directement et automatiquement en production après les phases d’examen et de fusion.

À propos

Christian Bürgi est Architecture Owner dans le système Acquiring de PostFinance. Actuellement, il est surtout actif dans les domaines Observability, Shift Left et DevOps. Il s’occupe également de projets logiciels actuels et de l’architecture dans le domaine du commerce numérique. Il a grandement contribué à l’utilisation de GitOps dans son environnement.

Cette page a une évaluation moyenne de %r sur un maximum de 5 étoiles. Au total, %t évaluations sont disponibles.
Vous pouvez évaluer la page en attribuant 1 à 5 étoiles, les 5 étoiles constituant la meilleure note.
Merci pour l’évaluation
Évaluer l’article

Ceci pourrait également vous intéresser