Qu’est-ce que GitOps ? C’est l’introduction technique que vous cherchiez

Approche systémique Il n’est pas difficile de donner l’impression que la création et le déploiement de systèmes natifs du cloud deviennent rapidement un problème résolu, GitOps fournissant la feuille de route.

L’approche tourne autour de l’idée de configuration-as-code : rendre tous les états de configuration déclaratifs (par exemple, spécifiés dans les chartes Helm et les modèles Terraform) ; stocker ces fichiers dans un dépôt de code (par exemple, GitHub) ; puis traiter ce référentiel comme la seule source de vérité pour la création et le déploiement d’un système cloud natif. Peu importe si vous corrigez un fichier Python ou mettez à jour un fichier de configuration, le référentiel déclenche un pipeline CI/CD entièrement automatisé.

Ayant construit des systèmes cloud natifs à l’aide de ce modèle (par exemple, voir Aether, un cloud périphérique compatible 5G), la puissance de ce modèle GitOps est claire : il fournit une approche directe du problème épineux de la gestion de l’état de la configuration. Mais comme toute solution apparemment simple, il y a plus à l’histoire. Comme d’autres l’ont souligné, GitOps n’est pas une solution miracle.

D’après notre expérience, il y a au moins trois considérations qui nous amènent à cette conclusion. Tout repose sur la question de savoir si tout l’état nécessaire au fonctionnement d’un système cloud natif peut être géré entièrement avec un mécanisme basé sur un référentiel.

La première considération est que nous devons reconnaître la différence entre les personnes qui développent des logiciels et celles qui construisent et exploitent des systèmes utilisant ces logiciels. DevOps (dans sa formulation la plus simple) implique qu’il ne devrait y avoir aucune distinction. Dans la pratique, les développeurs sont souvent très éloignés des opérateurs, ou plus précisément, ils sont très éloignés des décisions de conception sur la façon dont les autres finiront par utiliser leur logiciel. Par exemple, un logiciel est généralement implémenté avec un ensemble particulier de cas d’utilisation à l’esprit, mais il est ensuite intégré à d’autres logiciels pour créer des applications cloud entièrement nouvelles qui ont leur propre ensemble d’abstractions et de fonctionnalités et, par conséquent, leur propre collection d’états de configuration. . (C’est vrai pour Aether, où le Software Defined Mobile Core a été initialement mis en œuvre pour une utilisation dans les réseaux cellulaires mondiaux, mais est en train d’être réutilisé pour prendre en charge la 4G/5G privée dans les entreprises.)

S’il est vrai qu’un tel état pourrait être géré dans son propre référentiel Git, l’idée de la gestion de la configuration par pull request est trop simpliste. Il existe à la fois des variables de bas niveau (centrées sur la mise en œuvre) et de haut niveau (centrées sur l’application) ; en d’autres termes, il est courant d’avoir une ou plusieurs couches d’abstraction s’exécutant sur le logiciel de base. À la limite, il peut même s’agir d’un utilisateur final (par exemple, un utilisateur d’entreprise dans Aether) qui souhaite modifier cet état, ce qui implique qu’un contrôle d’accès précis est probablement une exigence. Rien de tout cela ne disqualifie GitOps en tant que moyen de gérer un tel état, mais cela soulève la possibilité que tous les états ne soient pas créés égaux – qu’il existe une gamme de variables d’état de configuration accessibles à différents moments par différentes personnes avec différents ensembles de compétences, et plus important encore, nécessitant différents niveaux de privilège.

Intégrer dans tous les composants l’hypothèse qu’ils ne sont pas la source faisant autorité pour les paramètres de configuration qu’ils utilisent est un bon point de départ

La deuxième considération concerne l’origine de l’état de configuration. Par exemple, considérons les adresses attribuées aux serveurs assemblés dans un cluster, qui peuvent provenir du système d’inventaire d’une organisation. Ou comme dans le cas d’un service 5G comme Aether, il existe des identifiants uniques attribués aux appareils mobiles qui sont gérés dans une base de données mondiale d’abonnés. En général, les systèmes doivent souvent faire face à de multiples sources d’état de configuration, parfois externes, et savoir quelle copie fait autorité et quelle copie est dérivée est intrinsèquement problématique. Il n’y a pas une seule bonne réponse, mais des situations comme celle-ci soulèvent la possibilité que la copie faisant autorité de l’état de configuration doive être conservée indépendamment de toute utilisation unique de cet état. Intégrer dans tous les composants l’hypothèse qu’ils sont pas la source faisant autorité pour tous les paramètres de configuration qu’ils utilisent, c’est un bon point de départ. L’idée d’une « source unique de vérité », bien qu’attrayante, manque une partie de la complexité que nous trouvons dans les déploiements réels.

La troisième considération est la fréquence à laquelle cet état change et, par conséquent, déclenche potentiellement le redémarrage ou peut-être même le redéploiement d’un ensemble de conteneurs. Cela a certainement du sens pour les paramètres de configuration « définis une fois », mais qu’en est-il des variables de contrôle « réglables à l’exécution » ? Quel est le moyen le plus économique de mettre à jour les paramètres système susceptibles de changer fréquemment ? Encore une fois, cela soulève la possibilité que tous les états ne soient pas créés égaux et qu’il existe un continuum de variables d’état de configuration.

Ces trois considérations indiquent la distinction entre l’état de configuration au moment de la construction et l’état de contrôle à l’exécution. Nous soulignons, cependant, que la question de savoir comment gérer un tel État n’a pas une seule réponse correcte ; tracer une ligne nette entre « configuration » et « contrôle » est notoirement difficile. Le mécanisme basé sur les dépôts défendu par GitOps et les alternatives de contrôle d’exécution offrent de la valeur, et il s’agit de savoir laquelle correspond le mieux à une information donnée qui doit être conservée pour qu’un cloud fonctionne correctement.

État d’exécution vs état de configuration

L’état de configuration est raisonnablement bien défini, mais qu’entendons-nous par état d’exécution ? En général, l’état d’exécution est plus dynamique. Si nous prenons l’exemple de Kubernetes, la configuration est déclarée dans un fichier YAML, mais l’état d’exécution est géré par des contrôleurs qui doivent répondre rapidement à des événements tels que la défaillance d’un pod. Personne n’imagine que le lancement d’un nouveau pod après un échec serait géré par une requête d’extraction GitOps ; mais le fichier YAML pour déclarer le nombre de pods à exécuter est un exemple d’état de configuration qui s’intègre bien dans le framework GitOps. Dans cet exemple, la distinction entre configuration et état d’exécution est assez évidente, mais en pratique, il peut s’agir davantage d’un continuum.

Le maintien de l’état d’exécution nécessite un mécanisme de contrôle approprié (comme dans l’exemple précédent). Nous construisons un tel mécanisme de contrôle pour Aether (décrit ici), et sans entrer dans les détails, l’idée centrale est de tirer parti d’un micro-service de configuration de périphérique réseau, reciblé sur des périphériques virtuels (alias, services logiciels). De tels mécanismes ont plusieurs propriétés intéressantes : (1) ils utilisent YANG comme langage de spécification déclarative, et sont donc livrés avec un riche ensemble d’outils pour définir et manipuler des modèles de données ; (2) ils prennent en charge la gestion des versions, de sorte que les changements d’état peuvent être annulés en avant et en arrière ; (3) ils sont agnostiques quant à la façon dont les données sont rendues persistantes, mais sont généralement associés à un magasin clé/valeur natif du cloud ; et (4) ils prennent en charge les contrôles d’accès basés sur les rôles (RBAC), de sorte que différents principaux peuvent bénéficier d’une visibilité et d’un contrôle différents sur les paramètres de contrôle/configuration.

En plus d’être conçue pour gérer un état de contrôle d’exécution plus dynamique, l’API de contrôle qui peut être générée automatiquement à partir du modèle de données YANG a offert deux avantages dans notre environnement : (1) RBAC aide à prendre en charge le principe du moindre privilège, et (2) il offre la possibilité de mettre en œuvre une validation précoce des paramètres et des contrôles de sécurité (ce qui permet de détecter les erreurs plus près de l’utilisateur et de générer des messages d’erreur plus significatifs). Les modèles de données efficaces se sont avérés inestimables, un sujet sur lequel nous reviendrons à l’avenir.

Existe-t-il donc un seul meilleur mécanisme ? Il est presque certain que les deux sont nécessaires, décidés au cas par cas : le contrôle d’exécution maintient l’état d’autorité pour certains paramètres et les dépôts de code maintiennent l’état d’autorité pour d’autres paramètres. Nous avons juste besoin de savoir clairement qui est lequel, afin que chaque composant backend sache à quel « chemin de configuration » il doit répondre. Y a-t-il un gros point à retenir de tout cela ? Seulement que personne n’a dit que la gestion de l’État allait être facile, et il faut se méfier de quiconque prétend le contraire ! ®