GitOps est génial, n’est-ce pas ? Qu’est-ce que c’est, je vous entends demander. En termes simples, de nos jours, où toute infrastructure peut être virtualisée, GitOps consiste à gérer des informations sur ce à quoi cela doit ressembler (écrit sous forme de fichier texte), parallèlement à l’application qui va s’y exécuter. Accrochez-vous à ce mot « gérer ».
Le concept d’infrastructure en tant que code géré de la même manière que le code logiciel est peut-être simple, mais ses conséquences sont puissantes. D’où GitOps, le terme inventé par Alexis Richardson, PDG et co-fondateur de Weaveworks : « git » étant le référentiel de code de choix pour les applications natives du cloud, et « ops » parce que, eh bien, tout n’est pas tout à ce sujet ces jours-ci ?
La propre solution de flux de travail GitOps de Weaveworks, FluxCD, vient de sortir de l’usine d’incubateur qu’est la Cloud Native Computing Foundation (CNCF) – pas une mince affaire compte tenu des cerceaux par lesquels il aura dû sauter. “Nous avions des auditeurs de sécurité partout dans le code”, a déclaré Alexis lorsque je l’ai rencontré à ce sujet.
FluxCD n’est pas le seul enfant sur le bloc : ArgoCD par exemple, dirigé par des équipes d’Intuit, Codefresh, et d’autres, a également obtenu l’obtention du diplôme CNCF. Deux solutions concurrentes ne posent aucun problème : elles fonctionnent de manière différente et conviennent à différents cas d’utilisation.
Et qu’en est-il de ces puissantes conséquences ? Bien. Le moteur du travail GitOps est le besoin clair et présent de gérer les données de configuration dans des environnements d’application massivement distribués et potentiellement hautement modifiables. Dans l’espace de plus en plus conteneurisé des applications natives du cloud, ce même pilote a engendré l’existence de moteurs d’orchestration tels que DockerSwarm et Kubernetes, ainsi que le besoin d’outils d’observabilité dans le cloud – c’est-à-dire comment diable identifions-nous un problème lorsque nous ne le faisons pas même savoir où tourne notre logiciel ?
Dans l’espace natif du cloud, cela signifie généralement que toutes les applications qui ont atteint leurs objectifs de livraison à grande échelle – des exemples de repères qui suivent l’architecture Netflix – doivent rester au courant de la façon dont elles déploient leur logiciel, puis comment elles le gèrent en même temps. escalader. Faites-le et vous pourrez réaliser de grandes choses.
Par exemple, la manifestation des trois est vitale pour des scénarios tels que les communications de machine à machine et les voitures sans conducteur. Dans l’espace des télécommunications, où la dernière génération de sans fil (5G) est native du cloud par conception, la capacité de fournir des mises à jour logicielles et de configuration en parallèle et à grande échelle ne devient possible qu’en adoptant des principes tels que GitOps. « Vous pouvez mettre à jour quarante mille tours de télécommunication sans les toucher. Cela ne serait tout simplement pas possible autrement », remarque Alexis, se référant à Weaveworks Partenariat avec Deutsche Telekom.
GitOps est soigné. Cependant, il y a beaucoup à déballer dans l’expression « gérer les données de configuration » du cinquième paragraphe ci-dessus : il ne s’agit pas uniquement de se déplacer de gauche à droite, de la conception de l’application/de l’infrastructure au déploiement, puis aux opérations. Ce qui me tient à cœur, et quelque chose sur lequel j’ai déjà écrit est un problème au cœur de tout ce qui concerne DevOps – que, dans notre volonté d’innover rapidement, nous avons sacrifié notre capacité à gérer ce que nous avons créé.
Cette incapacité à fermer la boucle infinie DevOps peut être assimilée à un tuyau d’incendie crachant des données de trace, des rapports d’incidents, des mesures de l’expérience utilisateur, etc., inondant le côté développement de la maison de bribes d’informations sans aucune véritable hiérarchisation ou contrôle. C’est un gâchis, ce qui signifie souvent (on me dit, de manière anecdotique) que les développeurs ne savent pas sur quoi travailler ensuite en termes de correctifs, alors ils continuent de faire ce qu’ils allaient faire de toute façon, comme de nouvelles fonctionnalités.
Ailleurs, j’ai parlé de l’écart de gouvernance entre la stratégie d’innovation (« Créons des éléments natifs du cloud ») et la livraison. C’est la raison pour laquelle je me suis très tôt attaché à la gestion de la chaîne de valeur comme moyen de renforcer la visibilité sur l’ensemble du pipeline ; c’est aussi pourquoi j’avais hâte d’en savoir plus sur l’évolution d’Atlassian vers l’espace de gestion des services informatiques.
GitOps résout le problème de gouvernance, pas en ajoutant des tableaux de bord et des contrôles – du moins, pas par eux-mêmes. Au contraire, un principe fondamental de GitOps est que les informations de configuration sont poussées de la même manière que le code et ne sont ensuite pas altérées après le déploiement, à moins qu’elles ne puissent être aidées.
Ces deux concepts sont inscrits au cœur de l’outillage GitOps, sinon ce sont juste des choses qui, je parie, ont l’air bien sur un tableau blanc. Du Ouvrir GitOps site, l’ensemble complet des principes est le suivant :
1. Déclaratif – un système doit être documenté à l’avance par des déclarations déclarées plutôt que d’avoir à distinguer le système de sa configuration d’exécution
2. Versionné et immuable – il s’agit de stocker ces déclarations d’infrastructure avec le code d’application, dans un référentiel contrôlé par version tel que git.
3. Tiré automatiquement – maintenant, nous parlons de la façon dont le système souhaité est toujours construit en fonction de sa configuration déclarée plutôt qu’en bricolant.
4. Réconcilié en continu. C’est le bit le plus cool et le plus important – si vous allez modifier la configuration d’exécution, l’outillage devrait détecter le changement et déclencher un correctif.
Des outils tels que FluxCD et ArgoCD édictent ces principes. Fascinant, ils travaillent avec le fait que les ingénieurs ne voudront pas ralentir la façon dont ils construisent des choses, ils imposent simplement le fait que vous ne pouvez pas le modifier une fois que c’est fait – et si vous le faites, une alerte sera déclenchée . Cela peut provoquer un refus de la part des personnes qui souhaitent apporter des modifications au système en cours d’exécution, plutôt que de changer la source de vérité, explique Alexis. “Les gens disent qu’il y a une latence élevée, souvent ils n’ont pas bien configuré leur système.”
Je fais valoir ce point aussi clairement et directement que possible, à cause des dangers de (puis-je l’appeler) lavage GitOps. Le simple fait de respecter les deux premiers principes ci-dessus, ou simplement de stocker des informations d’infrastructure en tant que code dans git, ne signifie pas que GitOps est en cours. Soit il s’agit d’une boucle fermée avec une identification et une réconciliation des écarts de configuration pilotées par des alertes, soit il s’agit simplement d’un autre pipeline.
Il ne s’agit pas non plus simplement de principes, mais d’avantages. Ce point plus tôt sur le déploiement de mises à jour sur quarante mille tours de télécommunication ? Cela n’est possible que si les sources de friction du déploiement sont minimisées ou supprimées complètement et si l’environnement résultant peut être géré de manière opérationnelle sur la base d’une compréhension aussi claire que possible de ce à quoi il ressemble. « Il n’y a pas d’autre modèle d’exploitation qui évolue vraiment », remarque Alexis, et il a raison.
En fin de compte, cela va au cœur de ce que signifie être agile dans le monde numérique. L’agilité ne consiste pas à contrôler le chaos ou à casser des choses sans jamais vraiment les créer : elle réussit avec des méthodes de travail et des outils d’accompagnement qui s’alignent sur les besoins d’innovation à grande échelle. Oui, GitOps est génial, mais seulement si toutes ses facettes sont adoptées en gros – GitOps lite n’est pas du tout GitOps.
