GitOps : les infrastructures automatisées expliquées

GitOps est un concept qui gère des infrastructures et des applications via une approche déclarative et qui les contrôle à l’aide de Git. Son but est d’assurer un traitement automatisé qui permette de gagner du temps et garantisse une collaboration sûre des équipes individuelles d’un dépôt à l’autre.

Dans le domaine du développement logiciel, l’automatisation est importante. C’est l’une des raisons pour lesquelles DevOps a acquis une telle popularité. L’idée sous-jacente est celle de l’« infrastructure en tant que Code » (IaC), dont l’intention est de mapper les infrastructures et configurations d’un système informatique de manière à les rendre reproductibles. GitOps est une extension logique de cette approche. Depuis 2017, le logiciel open source Git contrôle le processus complet d’une application, de son administration à son développement logiciel final, en tant que « source unique de vérité ». À cette fin, GitOps définit un état cible et, si nécessaire, ajuste l’infrastructure jusqu’à ce que cet état soit atteint.

Weaveworks dévoile un ensemble de bonnes pratiques quant à l’unification des méthodes de supervision des conteneurs. Ces dernières sont valables pour Kubernetes et pour d’autres technologies qui reposent sur le Cloud, ce qui les rend plus faciles à gérer. Git est fondé sur un système de gestion des versions développé par Linus Torvald en 2005. Ceci permet à différentes équipes de collaborer sur un projet en parallèle. Les changements ne sont adoptés qu’après une coordination conjointe et les anciens statuts sont préservés. Les développeurs peuvent travailler simultanément sur différents aspects et fusionner ces derniers à l’arrivée. Vous pourrez accéder à un tutoriel Git complet dans notre Digital Guide.

Avec GitOps, on commence par décrire l’état cible d’un système de manière déclarative. Les changements sont apportés conformément au principe de Git via des pull requests. Lorsque ces dernières sont menées à bien, elles modifient le dépôt Git. Or, lorsqu’un pull request est effectué dans un environnement comprenant GitOps, l’opérateur active, capture le commit et requiert l’état actuel via Git. Il est ensuite comparé à l’état désiré dans le dépôt. Une fois les changements ratifiés, ils sont fusionnés à l’état antérieur et appliqués directement à l’infrastructure en live. Ceci rend le traitement à la fois plus rapide et plus fluide, tout en assurant la stabilité et la fiabilité du système.

Du fait de principes clairement définis et immuables, les flux d’activité de GitOps s’avèrent relativement fiables. Ceci affecte les systèmes déclaratifs qui sont habitués à d’autres systèmes Cloud Native. La description déclarative garantit le fait que le système dans sa totalité puisse être traité en tant que code et versionné, ce qui contribue à la sécurité et la stabilité du système complet, dans la mesure où toute déviation de la version Git peut être détectée et signalée immédiatement. De plus, les clés SSH assurent la possibilité de toujours pouvoir tracer l’origine d’un code. Du fait des déclarations antérieures, les changements peuvent être automatisés et les possibles sources d’erreurs détectées et corrigées à un stade précoce.

L’approche fondamentale de DevOps a toujours été la fusion du développement et de l’exécution pour simplifier les flux d’activité. Comme les équipes collaborent étroitement, cela tend à améliorer le produit final et permet que des changements soient apportés plus vite et avec plus de précision. GitOps s’approprie cette approche et l’applique de manière cohérente à la partie exécution (opérations). GitOps se focalise entièrement sur Git, tandis que DevOps et DevSecOps sont des idées plus fondamentales visant à susciter la collaboration entre des domaines jusqu’alors séparés en s’appuyant sur des pipelines CI et CD. Néanmoins, ces deux approches peuvent être combinées.

À la différence de la distribution continue et de l’intégration continue, GitOps tire toutes les informations nécessaires directement de Git conformément au principe du « pull », et ce sans déploiement via un serveur CI. Ceci peut être utilisé avec GitOps mais n’est désormais responsable que de la phase de développement et de test. Apprenez-en plus sur la Continuous Integration vs. Continuous Delivery vs. Continuous Deployment dans notre Digital Guide.

Du fait de sa polyvalence, Kubernetes constitue sans nul doute la plateforme la plus importante pour gérer des applications basées sur des conteneurs. Kubernetes fonctionne de manière déclarative et considère l’état-cible d’un système, ce qui en fait une bonne option pour travailler avec GitOps et pour faire office d’opérateur. Néanmoins, pour des raisons de sécurité et pour bénéficier d’un meilleur aperçu, le code source et la configuration doivent être séparés. L’état effectif peut alors être stocké au sein d’un dépôt Git séparé. Pour éviter tout accès non autorisé et de possibles erreurs, des outils de synchronisation appropriés devront être utilisés.

Il existe désormais un vaste choix d’outils pour GitOps, lesquels visent à simplifier et améliorer l’automatisation. On y retrouve des outils pour travailler avec Kubernetes en tant qu’opérateurs pour l’implémentation de GitOps. L’opérateur (ou contrôleur personnalisé) est Flux. ArgoCD et Fleet en sont des alternatives. Parmi les outils-clés pour améliorer la sécurité, on trouve SOPS de Mozilla et Sealed Secrets de Bitnami. Cluster API ou Fleet conviennent parfaitement à une utilisation conjointe avec des clusters Kubernetes. Dans l’ensemble, le marché est relativement étendu, de sorte qu’il existe un outil adapté à chaque application ou presque.

Pour découvrir si GitOps convient à vos objectifs, jetez un œil à ces points positifs et négatifs.

• La productivité : l’automatisation garantit le fait que les changements soient effectués en un temps réduit. Cela permet aux développeurs de travailler plus efficacement.
• La sécurité et la stabilité : les vérifications précises ont pour effet que les erreurs sont détectées rapidement et corrigées automatiquement. Ceci contribue à une sécurité et une stabilité accrues. Grâce aux rollbacks résilients, il est beaucoup plus facile de rétablir les états précédents et l’approche « pull » évite des complications non souhaitées.
• L’unité : les flux d’activité sont standardisés via GitOps. Ceci conduit à une collaboration à la fois meilleure et plus facile et permet aux nouveaux employés de se lancer plus rapidement.

• La séparation du CI et du CD : du fait de la stricte séparation du CI et du CD dans l’approche GitOps, il peut être difficile de réaliser des tests post-déploiement.
• Vision d’ensemble : lorsque l’on travaille avec de multiples environnements, GitOps peut laisser un peu perplexe. La multiplicité des dépôts et des configurations peut ajouter à cette confusion.