{"id":35941,"date":"2019-10-31T22:07:41","date_gmt":"2019-10-31T19:07:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-zhe-takoe-gitops\/"},"modified":"2019-10-31T22:07:41","modified_gmt":"2019-10-31T19:07:41","slug":"chto-zhe-takoe-gitops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-zhe-takoe-gitops","title":{"rendered":"Qu'est-ce que GitOps ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Note de traduction.<\/b>Apr\u00e8s une r\u00e9cente publication <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/456754\/\">mat\u00e9riau<\/a><\/noindex> sur les m\u00e9thodes pull et push en GitOps, nous avons constat\u00e9 un int\u00e9r\u00eat pour ce mod\u00e8le dans son ensemble, cependant, il y a eu peu de publications en russe \u00e0 ce sujet (il n'y en a tout simplement pas sur Habr). Nous sommes donc heureux de vous proposer la traduction d'un autre article \u2014 bien qu'il date d\u00e9j\u00e0 d'un an ! \u2014 de l'entreprise Weaveworks, dont le dirigeant a invent\u00e9 le terme \u00ab GitOps \u00bb. Le texte explique l'essence de l'approche et les principales diff\u00e9rences par rapport aux mod\u00e8les existants.<\/i><\/p>\n<p>\nIl y a un an, nous avons publi\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-operations-by-pull-request\">une introduction \u00e0 GitOps.<\/a><\/noindex>\u00c0 l'\u00e9poque, nous avons expliqu\u00e9 comment l'\u00e9quipe de Weaveworks a lanc\u00e9 un SaaS enti\u00e8rement bas\u00e9 sur Kubernetes et a d\u00e9velopp\u00e9 un ensemble de meilleures pratiques prescriptives pour le d\u00e9ploiement, la gestion et la surveillance dans un environnement cloud native.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>L'article a \u00e9t\u00e9 populaire. D'autres personnes ont commenc\u00e9 \u00e0 parler de GitOps et \u00e0 publier de nouveaux outils pour <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/hasura\/gitkube\">git push<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/dzone.com\/articles\/weaveworks-gitops-developer-toolkit-part-one-skaff\">le d\u00e9veloppement<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/storing-secure-sealed-secrets-using-gitops\">des secrets<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.alexellis.io\/introducing-openfaas-cloud\/\">des fonctions<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/jenkins.io\/blog\/2018\/03\/19\/introducing-jenkins-x\/\">l'int\u00e9gration continue<\/a><\/noindex> etc. De nombreuses publications et cas d'utilisation de GitOps sont apparus sur notre site. Mais certaines personnes ont encore des questions. En quoi le mod\u00e8le se distingue-t-il du code d'infrastructure traditionnel? <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/category\/gitops\/\">et de la livraison continue (<\/a><\/noindex> continuous delivery <noindex><a rel=\"nofollow\" href=\"https:\/\/puppet.com\/blog\/a-deployment-pipeline-for-infrastructure-a-devops-case-study-at-nbn\">) ? Est-il obligatoire d'utiliser Kubernetes ?<\/a><\/noindex> Nous avons rapidement compris qu'il \u00e9tait n\u00e9cessaire de fournir une nouvelle description, offrant :<noindex><a rel=\"nofollow\" href=\"https:\/\/puppet.com\/blog\/a-deployment-pipeline-for-infrastructure-a-devops-case-study-at-nbn\">Un grand nombre d'exemples et d'histoires ;<\/a><\/noindex>Une d\u00e9finition pr\u00e9cise de GitOps ;<\/p>\n<p>Une comparaison avec la livraison continue traditionnelle.<\/p>\n<ol>\n<li> Dans cet article, nous avons essay\u00e9 de couvrir tous ces sujets. Vous y trouverez une introduction mise \u00e0 jour au GitOps ainsi qu'un point de vue des d\u00e9veloppeurs et du CI\/CD. Nous nous concentrons principalement sur Kubernetes, bien que le mod\u00e8le puisse \u00eatre g\u00e9n\u00e9ralis\u00e9.<\/li>\n<li> Voici GitOps<\/li>\n<li> Z\u043d\u0430\u043a\u043e\u043c\u044c\u0442\u0435\u0441\u044c: GitOps<\/li>\n<\/ol>\n<p>\nZ \u0437\u043d\u0430\u043a\u043e\u043c\u044c\u0442\u0435\u0441\u044c: GitOps<\/p>\n<h2>Z \u0437\u043d\u0430\u043a\u043e\u043c\u044c\u0442\u0435\u0441\u044c: GitOps<\/h2>\n<p>\nImagine Alice. She runs Family Insurance, offering health, auto, property, and travel insurance policies to people who are too busy to navigate the intricacies of contracts themselves. Her business started as a side project while Alice worked as a data scientist at a bank. One day, she realized she could use advanced computer algorithms for more efficient data analysis and to create insurance packages. Investors funded the project, and now her company generates over $20 million a year and is rapidly expanding. Currently, it employs 180 people in various roles, including a tech team responsible for developing, maintaining the website, the database, and analyzing the customer base. The 60-person team is led by Bob \u2014 the company\u2019s CTO.<\/p>\n<p>Bob's team deploys production systems in the cloud. Their main applications run on GKE, taking advantage of Kubernetes in Google Cloud. Additionally, they utilize various tools for data handling and analytics.<\/p>\n<p>Family Insurance ne pr\u00e9voyait pas d'utiliser des conteneurs, mais a \u00e9t\u00e9 contamin\u00e9e par l'enthousiasme autour de Docker. Peu apr\u00e8s, les sp\u00e9cialistes de l'entreprise ont d\u00e9couvert que GKE permet de d\u00e9ployer des clusters pour tester de nouvelles fonctionnalit\u00e9s facilement et sans effort. Jenkins a \u00e9t\u00e9 ajout\u00e9 pour l'int\u00e9gration continue et Quay pour organiser le registre des conteneurs, des scripts ont \u00e9t\u00e9 \u00e9crits pour Jenkins, qui poussent de nouveaux conteneurs et configurations dans GKE.<\/p>\n<p>Un certain temps est pass\u00e9. Alice et Bob ont \u00e9t\u00e9 d\u00e9\u00e7us par les performances de l'approche choisie et son impact sur les affaires. L'adoption des conteneurs n'a pas am\u00e9lior\u00e9 les performances autant que l'\u00e9quipe l'esp\u00e9rait. Parfois, les d\u00e9ploiements \u00e9chouaient, et il \u00e9tait difficile de savoir si cela \u00e9tait d\u00fb aux changements de code. Il \u00e9tait \u00e9galement difficile de suivre les modifications des configurations. Ils devaient souvent cr\u00e9er un nouveau cluster et y d\u00e9placer les applications, car c'\u00e9tait le moyen le plus simple de r\u00e9soudre le d\u00e9sordre dans lequel le syst\u00e8me s'\u00e9tait transform\u00e9. Alice craignait que la situation ne s'aggrave \u00e0 mesure que l'application \u00e9volue (de plus, un nouveau projet bas\u00e9 sur l'apprentissage automatique \u00e9tait en gestation). Bob avait automatis\u00e9 une grande partie du travail et ne comprenait pas pourquoi le pipeline restait instable, se redimensionnait mal et n\u00e9cessitait p\u00e9riodiquement une intervention manuelle.<\/p>\n<p><b>Puis ils ont entendu parler de GitOps. Cette solution s'est r\u00e9v\u00e9l\u00e9e \u00eatre exactement ce dont ils avaient besoin pour avancer avec assurance.<\/b><\/p>\n<p>Alice et Bob entendaient parler depuis des ann\u00e9es des workflows bas\u00e9s sur Git, de DevOps et de l'infrastructure en tant que code. L'unicit\u00e9 de GitOps est qu'il introduit un certain nombre de meilleures pratiques - cat\u00e9goriques et normatives - pour mettre en \u0153uvre ces id\u00e9es dans le contexte de Kubernetes. Ce sujet <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/search?q=gitops&amp;src=typd\">a \u00e9t\u00e9 soulev\u00e9 \u00e0 plusieurs reprises<\/a><\/noindex>, y compris dans le <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-high-velocity-cicd-for-kubernetes\">blog de Weaveworks<\/a><\/noindex>.<\/p>\n<p>Family Insurance d\u00e9cide d'adopter GitOps. L'entreprise dispose d\u00e9sormais d'un mod\u00e8le op\u00e9rationnel automatis\u00e9, compatible avec Kubernetes et combinant <i>rapidit\u00e9<\/i> avec <i>stabilit\u00e9<\/i>, car ils :<\/p>\n<ul>\n<li> ont d\u00e9couvert que la productivit\u00e9 de l'\u00e9quipe avait doubl\u00e9 sans que personne ne perde la raison ;<\/li>\n<li> ont cess\u00e9 de g\u00e9rer des scripts. Au lieu de cela, ils peuvent maintenant se concentrer sur de nouvelles fonctionnalit\u00e9s et am\u00e9liorer les m\u00e9thodes d'ing\u00e9nierie - par exemple, en introduisant des d\u00e9ploiements canari et en am\u00e9liorant les tests ;<\/li>\n<li> ont perfectionn\u00e9 le processus de d\u00e9ploiement - il ne tombe maintenant que rarement en panne ;<\/li>\n<li> ont obtenu la possibilit\u00e9 de restaurer les d\u00e9ploiements apr\u00e8s des \u00e9checs partiels sans intervention manuelle ;<\/li>\n<li> ont gagn\u00e9 en<i>de<\/i>confiance dans les syst\u00e8mes de livraison. Alice et Bob ont d\u00e9couvert qu'ils pouvaient diviser l'\u00e9quipe en groupes travaillant sur des microservices en parall\u00e8le ;<\/li>\n<li> pouvaient apporter 30 \u00e0 50 modifications au projet chaque jour gr\u00e2ce \u00e0 chaque groupe et essayer de nouvelles techniques.<\/li>\n<li> attirent facilement de nouveaux d\u00e9veloppeurs sur le projet, qui peuvent d\u00e9ployer des mises \u00e0 jour en production via des pull requests en quelques heures ;<\/li>\n<li> passe facilement l'audit dans le cadre du SOC2 <i>(concernant la conformit\u00e9 des fournisseurs de services aux exigences de gestion s\u00e9curis\u00e9e des donn\u00e9es; pour en savoir plus, par exemple, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.imperva.com\/learn\/data-security\/soc-2-compliance\/\">ici<\/a><\/noindex> \u2014 n.d.t.)<\/i>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Que s'est-il pass\u00e9?<\/h3>\n<p>\nGitOps \u2014 c'est deux choses :<\/p>\n<ol>\n<li> Un mod\u00e8le d'exploitation pour Kubernetes et cloud native. Il fournit un ensemble de meilleures pratiques pour le d\u00e9ploiement, la gestion et la surveillance des clusters et applications empaquet\u00e9s dans des conteneurs. Une d\u00e9finition \u00e9l\u00e9gante sous forme de <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/vitorsilva\/status\/999978906903080961\">une diapositive<\/a><\/noindex> \u00e0 partir de <noindex><a rel=\"nofollow\" href=\"https:\/\/2018.agilept.org\/speaker_luis_faceira.html\">Luis Faceira<\/a><\/noindex>:\n<\/li>\n<li> Le chemin vers la cr\u00e9ation d'un environnement ax\u00e9 sur les d\u00e9veloppeurs pour la gestion des applications. Nous appliquons le flux de travail Git tant \u00e0 l'exploitation qu'au d\u00e9veloppement. Notez qu'il ne s'agit pas simplement d'un Git push, mais de l'organisation de l'ensemble de l'ensemble des outils CI\/CD et UI\/UX.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Quelques mots sur Git<\/h3>\n<p>\nSi vous n'\u00eates pas familier avec les syst\u00e8mes de contr\u00f4le de version et les workflows bas\u00e9s sur Git, nous vous recommandons fortement de les \u00e9tudier. Au d\u00e9but, travailler avec des branches et des pull requests peut sembler de la magie noire, mais les avantages valent l'effort. Voici <noindex><a rel=\"nofollow\" href=\"https:\/\/codeburst.io\/trunk-based-development-vs-git-flow-a0212a6cae64\">un bon article<\/a><\/noindex> pour commencer.<\/p>\n<h2>Comment fonctionne Kubernetes<\/h2>\n<p>\nDans notre histoire, Alice et Bob se sont tourn\u00e9s vers GitOps apr\u00e8s avoir travaill\u00e9 un certain temps avec Kubernetes. En effet, GitOps est \u00e9troitement li\u00e9 \u00e0 Kubernetes \u2014 c'est un mod\u00e8le d'exploitation pour l'infrastructure et les applications bas\u00e9es sur Kubernetes.<\/p>\n<h3>Qu'est-ce que Kubernetes offre aux utilisateurs?<\/h3>\n<p>\nVoici quelques-unes de ses principales fonctionnalit\u00e9s :<\/p>\n<ol>\n<li> Dans le mod\u00e8le Kubernetes, tout peut \u00eatre d\u00e9crit de mani\u00e8re d\u00e9clarative.<\/li>\n<li> Le serveur API Kubernetes prend une telle d\u00e9claration comme entr\u00e9e, puis essaie en permanence d'amener le cluster \u00e0 l'\u00e9tat d\u00e9crit dans la d\u00e9claration.<\/li>\n<li> Les d\u00e9clarations suffisent pour d\u00e9crire et g\u00e9rer une grande vari\u00e9t\u00e9 de charges de travail - \"applications\".<\/li>\n<li> En cons\u00e9quence, les modifications apport\u00e9es \u00e0 l'application et au cluster se produisent en raison de :\n<ul>\n<li> modifications des images de conteneurs;<\/li>\n<li> modifications dans la sp\u00e9cification d\u00e9clarative;<\/li>\n<li> erreurs dans l'environnement \u2014 par exemple, des \u00e9checs de conteneurs.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h3>Les merveilleuses capacit\u00e9s de convergence de Kubernetes<\/h3>\n<p>\nLorsque l'administrateur apporte des modifications \u00e0 la configuration, l'orchestrateur Kubernetes les appliquera au cluster jusqu'\u00e0 ce que son \u00e9tat <i>se rapproche de la nouvelle configuration<\/i>. Ce mod\u00e8le fonctionne pour n'importe quelle ressource Kubernetes et peut \u00eatre \u00e9tendu \u00e0 l'aide de Custom Resource Definitions (CRDs). Ainsi, les d\u00e9ploiements Kubernetes poss\u00e8dent les propri\u00e9t\u00e9s merveilleuses suivantes :<\/p>\n<ul>\n<li> <b>Automatisation<\/b>: les mises \u00e0 jour de Kubernetes fournissent un m\u00e9canisme pour automatiser le processus de mise en \u0153uvre des modifications de mani\u00e8re correcte et opportune.<\/li>\n<li> <b>Convergence<\/b>: Kubernetes continuera d'essayer des mises \u00e0 jour jusqu'\u00e0 ce qu'elles r\u00e9ussissent.<\/li>\n<li> <b>Idempotence<\/b>: les r\u00e9applications de la convergence produisent le m\u00eame r\u00e9sultat.<\/li>\n<li> <b>D\u00e9terminisme<\/b>: lorsque les ressources sont suffisantes, l'\u00e9tat du cluster mis \u00e0 jour d\u00e9pend uniquement de l'\u00e9tat souhait\u00e9.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Comment fonctionne GitOps<\/h2>\n<p>\nNous'avons suffisamment appris sur Kubernetes pour expliquer les principes du fonctionnement de GitOps.<\/p>\n<p>Revenons aux \u00e9quipes de Family Insurance li\u00e9es aux microservices. Quel est leur travail habituel ? Consultez la liste ci-dessous (si certains \u00e9l\u00e9ments vous semblent \u00e9tranges ou inconnus, veuillez patienter avant de critiquer et restez avec nous). Ce ne sont que des exemples de workflows bas\u00e9s sur Jenkins. Il existe \u00e9galement de nombreux autres processus utilisant diff\u00e9rents outils.<\/p>\n<p>L'essentiel est que nous voyons que chaque mise \u00e0 jour se termine par des modifications des fichiers de configuration et des d\u00e9p\u00f4ts Git. Ces modifications dans Git entra\u00eenent l'actualisation du cluster par l'op\u00e9rateur GitOps :<\/p>\n<p>1. Flux de travail :<i>Build Jenkins \u2014 branche master<\/i>\u00bb.<br \/>\nListe des t\u00e2ches :<\/p>\n<ul>\n<li> Jenkins pousse les images \u00e9tiquet\u00e9es dans Quay ;<\/li>\n<li> Jenkins pousse la configuration et les Helm charts dans le bucket de stockage master ;<\/li>\n<li> Une fonction cloud copie la config et les charts du bucket de stockage principal dans le d\u00e9p\u00f4t Git principal;<\/li>\n<li> L'op\u00e9rateur GitOps met \u00e0 jour le cluster.<\/li>\n<\/ul>\n<p>\n2. <i>Build Jenkins \u2014 branche release ou hotfix<\/i>:<\/p>\n<ul>\n<li> Jenkins pousse les images non \u00e9tiquet\u00e9es dans Quay ;<\/li>\n<li> Jenkins pousse la configuration et les Helm charts dans le bucket de stockage staging ;<\/li>\n<li> Une fonction cloud copie la config et les charts du bucket de staging dans le d\u00e9p\u00f4t Git de staging;<\/li>\n<li> L'op\u00e9rateur GitOps met \u00e0 jour le cluster.<\/li>\n<\/ul>\n<p>\n3. <i>Build Jenkins \u2014 branche develop ou feature<\/i>:<\/p>\n<ul>\n<li> Jenkins pousse les images non \u00e9tiquet\u00e9es dans Quay ;<\/li>\n<li> Jenkins pousse la configuration et les Helm charts dans le bucket de stockage develop ;<\/li>\n<li> Une fonction cloud copie la config et les charts du bucket de d\u00e9veloppement dans le d\u00e9p\u00f4t Git de d\u00e9veloppement;<\/li>\n<li>L'op\u00e9rateur GitOps met \u00e0 jour le cluster.<\/li>\n<\/ul>\n<p>\n4. <i>Ajouter un nouveau client<\/i>:<\/p>\n<ul>\n<li> Le gestionnaire ou l'administrateur (LCM\/ops) appelle Gradle pour le d\u00e9ploiement initial et la configuration des load balancers r\u00e9seau (NLB);<\/li>\n<li> LCM\/ops commit un nouveau config pour pr\u00e9parer le d\u00e9ploiement aux mises \u00e0 jour ;<\/li>\n<li> L'op\u00e9rateur GitOps met \u00e0 jour le cluster.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Description succincte de GitOps<\/h3>\n<p><\/p>\n<ol>\n<li> D\u00e9crivez l'\u00e9tat d\u00e9sir\u00e9 de l'ensemble du syst\u00e8me en utilisant des sp\u00e9cifications d\u00e9claratives pour chaque environnement (dans notre histoire, l'\u00e9quipe de Bob d\u00e9finit toute la configuration du syst\u00e8me dans Git).\n<ul>\n<li> Le d\u00e9p\u00f4t Git est la seule source de v\u00e9rit\u00e9 concernant l'\u00e9tat d\u00e9sir\u00e9 de l'ensemble du syst\u00e8me.<\/li>\n<li> Tous les changements vers l'\u00e9tat d\u00e9sir\u00e9 se font par le biais de commits dans Git.<\/li>\n<li> Tous les param\u00e8tres d\u00e9sir\u00e9s du cluster sont \u00e9galement observables dans le cluster lui-m\u00eame. Ainsi, nous pouvons d\u00e9terminer si l'\u00e9tat d\u00e9sir\u00e9 et l'\u00e9tat observ\u00e9 sont (convergent, <i>converge<\/i>) ou diff\u00e9rents (divergent, <i>diverge<\/i>) l'un de l'autre.<\/li>\n<\/ul>\n<\/li>\n<li> Si l'\u00e9tat d\u00e9sir\u00e9 et l'\u00e9tat observ\u00e9 diff\u00e8rent, alors :\n<ul>\n<li> Il existe un m\u00e9canisme de convergence qui synchronisera t\u00f4t ou tard automatiquement l'\u00e9tat cible et l'\u00e9tat observ\u00e9. Au sein du cluster, cela est g\u00e9r\u00e9 par Kubernetes.<\/li>\n<li> Le processus se d\u00e9clenche imm\u00e9diatement avec la notification \u00ab changement engag\u00e9 \u00bb.<\/li>\n<li> Apr\u00e8s un certain intervalle de temps configurable, une notification \u00ab diff \u00bb peut \u00eatre envoy\u00e9e si les \u00e9tats diff\u00e8rent.<\/li>\n<\/ul>\n<\/li>\n<li> Ainsi, tous les commits dans Git entra\u00eenent des mises \u00e0 jour v\u00e9rifiables et idempotentes dans le cluster.\n<ul>\n<li>Un rollback est une convergence vers un \u00e9tat d\u00e9sir\u00e9 pr\u00e9c\u00e9dent.<\/li>\n<\/ul>\n<\/li>\n<li> La convergence est d\u00e9finitive. Elle se manifeste par :\n<ul>\n<li> L'absence de notifications \u00ab diff \u00bb pendant un certain temps.<\/li>\n<li> Une notification \u00ab converg\u00e9 \u00bb (par exemple, webhook, \u00e9v\u00e9nement de retour Git).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h3>Qu'est-ce que la divergence ?<\/h3>\n<p>\nR\u00e9p\u00e9tons-le encore une fois : <i>toutes les propri\u00e9t\u00e9s d\u00e9sir\u00e9es du cluster doivent \u00eatre observables dans le cluster lui-m\u00eame.<\/i>.<\/p>\n<p>Quelques exemples de divergence :<\/p>\n<ul>\n<li> Un changement dans le fichier de configuration \u00e0 cause d'une fusion de branches dans Git.<\/li>\n<li> Un changement dans le fichier de configuration \u00e0 cause d'un commit dans Git effectu\u00e9 par un client GUI.<\/li>\n<li> Multiples changements dans l'\u00e9tat d\u00e9sir\u00e9 \u00e0 cause d'un PR dans Git suivi d'une construction d'image de conteneur et de modifications de configuration.<\/li>\n<li> Un changement dans l'\u00e9tat du cluster \u00e0 cause d'une erreur, d'un conflit de ressources entra\u00eenant un \u00ab mauvais comportement \u00bb, ou simplement d'un \u00e9cart accidentel par rapport \u00e0 l'\u00e9tat original.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Qu'est-ce qu'un m\u00e9canisme de convergence ?<\/h3>\n<p>\nQuelques exemples :<\/p>\n<ul>\n<li> Pour les conteneurs et les clusters, le m\u00e9canisme de convergence est fourni par Kubernetes.<\/li>\n<li> Le m\u00eame m\u00e9canisme peut \u00eatre utilis\u00e9 pour g\u00e9rer des applications et des constructions bas\u00e9es sur Kubernetes (par exemple, Istio et Kubeflow).<\/li>\n<li> Le m\u00e9canisme de gestion des interactions de travail entre Kubernetes, les d\u00e9p\u00f4ts d'images et Git fournit <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/weaveworks\/flux\">l'op\u00e9rateur GitOps Weave Flux<\/a><\/noindex>, qui fait partie de <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.weave.works\/\">Weave Cloud<\/a><\/noindex>.<\/li>\n<li> Pour les machines de base, le m\u00e9canisme de convergence doit \u00eatre d\u00e9claratif et autonome. D'apr\u00e8s notre exp\u00e9rience, nous pouvons dire que <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.gruntwork.io\/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c\">Terraform<\/a><\/noindex> il est le plus proche de cette d\u00e9finition, mais n\u00e9cessite n\u00e9anmoins un contr\u00f4le humain. En ce sens, GitOps \u00e9largit les traditions de l'Infrastructure as Code.<\/li>\n<\/ul>\n<p>\nGitOps combine Git avec un excellent m\u00e9canisme de convergence Kubernetes, offrant un mod\u00e8le pour l'exploitation.<\/p>\n<p>GitOps nous permet d'affirmer que <i>seuls les syst\u00e8mes pouvant \u00eatre d\u00e9crits et observ\u00e9s sont soumis \u00e0 l'automatisation et au contr\u00f4le<\/i>.<\/p>\n<h3>GitOps est destin\u00e9 \u00e0 l'ensemble de la pile cloud native (par exemple, Terraform, etc.)<\/h3>\n<p>\nGitOps ne se limite pas \u00e0 Kubernetes. Nous voulons que tout le syst\u00e8me soit g\u00e9r\u00e9 de mani\u00e8re d\u00e9clarative et utilise la convergence. Par syst\u00e8me, nous entendons l'ensemble des environnements fonctionnant avec Kubernetes - par exemple, \u00ab dev cluster 1 \u00bb, \u00ab production \u00bb, etc. Chaque environnement comprend des machines, des clusters, des applications, ainsi que des interfaces pour des services externes fournissant des donn\u00e9es, de la surveillance, etc.<\/p>\n<p>Remarquez \u00e0 quel point Terraform est essentiel dans ce cas pour la probl\u00e9matique du bootstrapping. Kubernetes doit \u00eatre d\u00e9ploy\u00e9 quelque part, et l'utilisation de Terraform signifie que nous pouvons appliquer les m\u00eames workflows GitOps pour cr\u00e9er une couche de gestion sous-jacente \u00e0 Kubernetes et aux applications. C'est une bonne pratique.<\/p>\n<p>Une grande attention est port\u00e9e \u00e0 l'application des concepts GitOps aux couches au-dessus de Kubernetes. \u00c0 ce jour, il existe des solutions de type GitOps pour Istio, Helm, Ksonnet, OpenFaaS et Kubeflow, ainsi que, par exemple, pour Pulumi, qui cr\u00e9ent une couche pour le d\u00e9veloppement d'applications cloud native.<\/p>\n<h2>Kubernetes CI\/CD : comparaison de GitOps avec d'autres approches<\/h2>\n<p>\nComme mentionn\u00e9, GitOps est deux choses :<\/p>\n<ol>\n<li> Un mod\u00e8le d'exploitation pour Kubernetes et cloud native, d\u00e9crit ci-dessus.<\/li>\n<li> Le chemin vers l'organisation d'un environnement ax\u00e9 sur les d\u00e9veloppeurs pour g\u00e9rer des applications.<\/li>\n<\/ol>\n<p>\nPour beaucoup, GitOps est avant tout un workflow bas\u00e9 sur les pushes Git. Nous l'aimons aussi. Mais ce n'est pas tout : examinons maintenant les pipelines CI\/CD.<\/p>\n<h3>GitOps assure un d\u00e9ploiement continu (CD) sous Kubernetes<\/h3>\n<p>\nGitOps propose un m\u00e9canisme de d\u00e9ploiement continu, \u00e9liminant le besoin de syst\u00e8mes de gestion des d\u00e9ploiements s\u00e9par\u00e9s. Tout le travail est effectu\u00e9 par Kubernetes.<\/p>\n<ul>\n<li> La mise \u00e0 jour d'une application n\u00e9cessite une mise \u00e0 jour dans Git. Il s'agit d'une mise \u00e0 jour transactionnelle vers l'\u00e9tat souhait\u00e9. Le \u00ab d\u00e9ploiement \u00bb est ensuite effectu\u00e9 \u00e0 l'int\u00e9rieur du cluster par Kubernetes lui-m\u00eame, sur la base de la description mise \u00e0 jour.<\/li>\n<li> En raison de la nature du fonctionnement de Kubernetes, ces mises \u00e0 jour sont convergentes. Cela assure un m\u00e9canisme pour un d\u00e9ploiement continu, dans lequel toutes les mises \u00e0 jour sont atomiques.<\/li>\n<li> Remarque : <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.weave.works\/\">Weave Cloud<\/a><\/noindex> propose un op\u00e9rateur GitOps qui int\u00e8gre Git et Kubernetes et permet d'effectuer CD en harmonisant l'\u00e9tat d\u00e9sir\u00e9 et l'\u00e9tat actuel du cluster.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Sans kubectl et scripts<\/h3>\n<p>\nIl est d\u00e9conseill\u00e9 d'utiliser kubectl pour mettre \u00e0 jour le cluster, et en particulier des scripts pour regrouper les commandes kubectl. Au lieu de cela, gr\u00e2ce \u00e0 un pipeline GitOps, l'utilisateur peut mettre \u00e0 jour son cluster Kubernetes via Git.<\/p>\n<p>Les avantages incluent :<\/p>\n<ol>\n<li> <b>Pr\u00e9cision<\/b>. Un groupe de mises \u00e0 jour peut \u00eatre appliqu\u00e9, converg\u00e9 et enfin valid\u00e9, ce qui nous rapproche de l'objectif d'un d\u00e9ploiement atomique. En revanche, l'utilisation de scripts ne garantit aucune convergence (voir plus de d\u00e9tails ci-dessous).<\/li>\n<li> <b>S\u00e9curit\u00e9<\/b>. <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/kelseyhightower\/status\/939003832805179392?lang=en\">En citant<\/a><\/noindex> Kelsey Hightower : \u00ab Limitez l'acc\u00e8s au cluster Kubernetes aux outils d'automatisation et aux administrateurs charg\u00e9s de le d\u00e9boguer ou d'assurer sa disponibilit\u00e9. \u00bb Voir \u00e9galement <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-compliance-and-secure-cicd\">ma publication<\/a><\/noindex> sur la s\u00e9curit\u00e9 et la conformit\u00e9 technique, ainsi que <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@vesirin\/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab\">l'article sur le piratage de Homebrew<\/a><\/noindex> par le vol d'identifiants \u00e0 partir d'un script Jenkins mal con\u00e7u.<\/li>\n<li> <b>Exp\u00e9rience utilisateur<\/b>. Kubectl expose la m\u00e9canique du mod\u00e8le d'objet de Kubernetes, qui est tr\u00e8s complexe. Id\u00e9alement, les utilisateurs devraient interagir avec le syst\u00e8me \u00e0 un niveau d'abstraction plus \u00e9lev\u00e9. Ici, je citerai encore Kelsey et recommande de jeter un \u0153il \u00e0 <noindex><a rel=\"nofollow\" href=\"http:\/\/superuser.openstack.org\/articles\/kubernetes-boring\/\">ce r\u00e9sum\u00e9<\/a><\/noindex>.<\/li>\n<\/ol>\n<p><\/p>\n<h3>La diff\u00e9rence entre CI et CD<\/h3>\n<p>\nGitOps am\u00e9liore les mod\u00e8les CI\/CD existants.<\/p>\n<p>Un serveur CI moderne est un outil d'orchestration. En particulier, c'est un outil pour orchestrer les pipelines CI. Ils incluent build, test, merge to trunk, etc. Les serveurs CI automatisent la gestion de pipelines complexes multi-\u00e9tapes. Une tentation courante est de cr\u00e9er un script pour appliquer des mises \u00e0 jour Kubernetes et de l'ex\u00e9cuter comme une \u00e9tape du pipeline pour pousser les changements dans le cluster. En effet, beaucoup de sp\u00e9cialistes agissent ainsi. Cependant, ce n'est pas optimal, et voici pourquoi.<\/p>\n<p>CI doit \u00eatre utilis\u00e9 pour apporter des mises \u00e0 jour au trunk, et le cluster Kubernetes doit s'automatiser en fonction de ces mises \u00e0 jour pour g\u00e9rer le CD \u00ab en interne \u00bb. Nous appelons cela <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-compliance-and-secure-cicd\">un mod\u00e8le de pull pour le CD<\/a><\/noindex>, contrairement au mod\u00e8le de push CI. Le CD fait partie de <i>l'orchestration runtime<\/i>.<\/p>\n<h3>Pourquoi les serveurs CI ne doivent-ils pas faire de CD via des mises \u00e0 jour directes dans Kubernetes<\/h3>\n<p>\n<i>N'utilisez pas le serveur CI pour orchestrer des mises \u00e0 jour directes dans Kubernetes sous forme de s\u00e9ries de t\u00e2ches CI. C'est un anti-mod\u00e8le, dont nous en <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/kubernetes-anti-patterns-let-s-do-gitops-not-ciops\">avons d\u00e9j\u00e0 parl\u00e9<\/a><\/noindex> dans notre blog.<\/i><\/p>\n<p>Revenons \u00e0 Alice et Bob.<\/p>\n<p>Quels probl\u00e8mes ont-ils rencontr\u00e9s ? Le serveur CI de Bob applique des modifications au cluster, mais s'il se crash pendant le processus, Bob ne saura pas dans quel \u00e9tat se trouve (ou devrait se trouver) le cluster et comment le r\u00e9parer. La m\u00eame chose est vraie en cas de succ\u00e8s.<\/p>\n<p>Supposons que l'\u00e9quipe de Bob ait construit une nouvelle image et patch\u00e9 ses d\u00e9ploiements pour d\u00e9ployer cette image (tout cela depuis le pipeline CI).<\/p>\n<p>Si l'image se construit correctement, mais que le pipeline \u00e9choue, l'\u00e9quipe devra d\u00e9terminer :<\/p>\n<ul>\n<li> La mise \u00e0 jour a-t-elle \u00e9t\u00e9 d\u00e9ploy\u00e9e ?<\/li>\n<li> D\u00e9marrons-nous une nouvelle build ? Cela entra\u00eenera-t-il des effets secondaires ind\u00e9sirables \u2014 avec la possibilit\u00e9 d\u2019obtenir deux builds de la m\u00eame image inchang\u00e9e ? <\/li>\n<li> Devons-nous attendre la prochaine mise \u00e0 jour avant de lancer la build ?<\/li>\n<li> Que s'est-il exactement pass\u00e9 ? Quelles \u00e9tapes doivent \u00eatre r\u00e9p\u00e9t\u00e9es (et lesquelles peuvent \u00eatre r\u00e9p\u00e9t\u00e9es en toute s\u00e9curit\u00e9) ?<\/li>\n<\/ul>\n<p>\n<i>L'organisation d'un workflow bas\u00e9 sur Git ne garantit pas que l'\u00e9quipe de Bob ne rencontrera pas ces probl\u00e8mes. Ils peuvent toujours se tromper lors du push d'un commit, d'un tag ou d'un autre param\u00e8tre ; cependant, cette approche est tout de m\u00eame beaucoup plus proche d'un tout ou rien explicite.<\/i><\/p>\n<p>En r\u00e9sum\u00e9, voici pourquoi les serveurs CI ne devraient pas g\u00e9rer le CD :<\/p>\n<ul>\n<li> Les scripts de mise \u00e0 jour ne sont pas toujours d\u00e9terministes ; il est facile d'y introduire des erreurs.<\/li>\n<li> Les serveurs CI ne convergent pas vers un mod\u00e8le d\u00e9claratif du cluster.<\/li>\n<li> Il est difficile de garantir l'idempotence. Les utilisateurs doivent comprendre la s\u00e9mantique profonde du syst\u00e8me.<\/li>\n<li> Il est plus compliqu\u00e9 de r\u00e9cup\u00e9rer apr\u00e8s une d\u00e9faillance partielle.<\/li>\n<\/ul>\n<p>\n<i>Remarque sur Helm : si vous souhaitez utiliser Helm, nous vous recommandons de le combiner avec un op\u00e9rateur GitOps tel que <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/managing-helm-releases-the-gitops-way\">Flux-Helm<\/a><\/noindex>. Cela aide \u00e0 garantir la convergence. Helm, \u00e0 lui seul, n'est ni d\u00e9terministe ni atomique.<\/i><\/p>\n<h2>GitOps comme la meilleure m\u00e9thode pour r\u00e9aliser le Continuous Delivery pour Kubernetes<\/h2>\n<p>\nL'\u00e9quipe d'Alice et Bob impl\u00e9mente GitOps et d\u00e9couvre qu'il est beaucoup plus facile de travailler avec des produits logiciels tout en maintenant une haute performance et stabilit\u00e9. Terminons cet article avec des illustrations montrant \u00e0 quoi ressemble leur nouvelle approche. Notez que nous parlons principalement d'applications et de services, bien que GitOps puisse \u00eatre utilis\u00e9 pour g\u00e9rer l'ensemble de la plateforme.<\/p>\n<h3>Mod\u00e8le d'exploitation pour Kubernetes<\/h3>\n<p>\nRegardez le diagramme suivant. Il repr\u00e9sente Git et le registre d'images de conteneurs comme des ressources partag\u00e9es pour deux cycles de vie orchestr\u00e9s :<\/p>\n<ul>\n<li> Un pipeline d'int\u00e9gration continue qui lit et \u00e9crit des fichiers dans Git et peut mettre \u00e0 jour le registre des images de conteneurs.<\/li>\n<li> Un pipeline Runtime GitOps qui combine d\u00e9ploiement, gestion et observabilit\u00e9. Il lit et \u00e9crit des fichiers dans Git et peut t\u00e9l\u00e9charger des images de conteneurs.<\/li>\n<\/ul>\n<h3>Quelles sont les conclusions principales ?<\/h3>\n<p><\/p>\n<ol>\n<li> <b>S\u00e9paration des pr\u00e9occupations<\/b>: Remarquez que les deux pipelines peuvent \u00e9changer des donn\u00e9es uniquement en mettant \u00e0 jour Git ou le registre des images. En d'autres termes, il existe un pare-feu entre l'environnement CI et l'environnement runtime. Nous l'appelons \"pare-feu d'immuabilit\u00e9\" <i>(immutability firewall)<\/i>, car toutes les mises \u00e0 jour des d\u00e9p\u00f4ts cr\u00e9ent de nouvelles versions. Pour des informations suppl\u00e9mentaires sur ce sujet, veuillez vous r\u00e9f\u00e9rer aux diapositives 72-87 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.slideshare.net\/weaveworks\/continuous-lifecycle-london-2018-event-keynote-97418556\">de cette pr\u00e9sentation<\/a><\/noindex>.<\/li>\n<li> <b>Tout serveur CI et Git peut \u00eatre utilis\u00e9<\/b>: GitOps fonctionne avec n'importe quels composants. Vous pouvez continuer \u00e0 utiliser vos serveurs CI et Git pr\u00e9f\u00e9r\u00e9s, ainsi que vos registres d'images et ensembles de tests. Presque tous les autres outils de Continuous Delivery sur le march\u00e9 n\u00e9cessitent leur propre serveur CI\/Git ou registre d'images. Cela peut devenir une contrainte dans le d\u00e9veloppement cloud native. Avec GitOps, vous pouvez utiliser les outils que vous connaissez.<\/li>\n<li> <b>\u00c9v\u00e9nements comme outil d'int\u00e9gration<\/b>: D\u00e8s que les donn\u00e9es dans Git sont mises \u00e0 jour, Weave Flux (ou l'op\u00e9rateur Weave Cloud) en informe l'environnement runtime. Chaque fois que Kubernetes accepte un ensemble de changements, Git est mis \u00e0 jour. Cela garantit un mod\u00e8le d'int\u00e9gration simple pour organiser les flux de travail pour GitOps, comme montr\u00e9 ci-dessous.<\/li>\n<\/ol>\n<h2>Conclusion<\/h2>\n<p>\nGitOps fournit des garanties solides de mise \u00e0 jour n\u00e9cessaires \u00e0 tout outil CI\/CD moderne :<\/p>\n<ul>\n<li> automatisation;<\/li>\n<li> convergence;<\/li>\n<li> idempotence;<\/li>\n<li> d\u00e9terminisme.<\/li>\n<\/ul>\n<p>\nC'est important car il offre un mod\u00e8le d'exploitation pour les d\u00e9veloppeurs dans le domaine du cloud natif.<\/p>\n<ul>\n<li> Les outils traditionnels de gestion et de surveillance des syst\u00e8mes sont li\u00e9s aux \u00e9quipes d'exploitation, agissant dans le cadre d'un runbook <i>(un ensemble de proc\u00e9dures et d'op\u00e9rations routini\u00e8res \u2014 note du traducteur)<\/i>, li\u00e9 \u00e0 un d\u00e9ploiement sp\u00e9cifique.<\/li>\n<li> Dans la gestion des syst\u00e8mes cloud natifs, l'outil de surveillance est le meilleur moyen d'\u00e9valuer les r\u00e9sultats des d\u00e9ploiements, permettant ainsi \u00e0 l'\u00e9quipe de d\u00e9veloppeurs de r\u00e9agir rapidement.<\/li>\n<\/ul>\n<p>\nImaginez de nombreux clusters dispers\u00e9s \u00e0 travers divers clouds et de nombreux services avec leurs propres \u00e9quipes et plans de d\u00e9ploiement. GitOps propose un mod\u00e8le invariant \u00e0 grande \u00e9chelle pour g\u00e9rer cette abondance.<\/p>\n<h2>P.S. de l'auteur<\/h2>\n<p>\nLisez aussi dans notre blog :<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/456754\/\">GitOps : comparaison des m\u00e9thodes Pull et Push<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/434160\/\">Voici la biblioth\u00e8que kubedog pour le suivi des ressources Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/449096\/\">\u00c9largir et compl\u00e9ter Kubernetes (aper\u00e7u et vid\u00e9o de la pr\u00e9sentation)<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p class=\"for_users_only_msg\">Seuls les utilisateurs enregistr\u00e9s peuvent participer au sondage. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Connectez-vous<\/a><\/noindex>, s'il vous pla\u00eet.<\/p>\n<h2 class=\"default-block__polling-title\">Saviez-vous ce qu'\u00e9tait GitOps avant ces deux traductions sur Habr?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Oui, je le savais.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Uniquement en surface.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Non<\/p>\n<\/li>\n<\/ul>\n<p>    35 utilisateurs ont vot\u00e9. 10 utilisateurs se sont abstenus.<br \/>\n<br \/>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u041f\u043e\u0441\u043b\u0435 \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0439 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 pull \u0438 push \u0432 GitOps \u043c\u044b \u0443\u0432\u0438\u0434\u0435\u043b\u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441 \u043a \u044d\u0442\u043e\u0439 \u043c\u043e\u0434\u0435\u043b\u0438 \u0432 \u0446\u0435\u043b\u043e\u043c, \u043e\u0434\u043d\u0430\u043a\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u044b\u0445 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0439 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443 \u043e\u043a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0441\u043e\u0432\u0441\u0435\u043c \u043c\u0430\u043b\u043e (\u043d\u0430 \u0445\u0430\u0431\u0440\u0435 \u0438\u0445 \u043f\u043e\u043f\u0440\u043e\u0441\u0442\u0443 \u043d\u0435\u0442). \u041f\u043e\u0441\u0435\u043c\u0443 \u0440\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u043f\u0443\u0441\u0442\u044c \u0438 \u0443\u0436\u0435 \u043f\u043e\u0447\u0442\u0438 \u0433\u043e\u0434\u0438\u0447\u043d\u043e\u0439 \u0434\u0430\u0432\u043d\u043e\u0441\u0442\u0438! \u2014 \u043e\u0442 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Weaveworks, \u0433\u043b\u0430\u0432\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35941","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-zhe-takoe-gitops\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0427\u0442\u043e \u0436\u0435 \u0442\u0430\u043a\u043e\u0435 GitOps? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-zhe-takoe-gitops\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Qu'est-ce que GitOps ? | ProHoster","description":"Ex.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-zhe-takoe-gitops","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u0436\u0435 \u0442\u0430\u043a\u043e\u0435 GitOps? | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-zhe-takoe-gitops","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:07:41+00:00","article:modified_time":"2019-10-31T19:07:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35941","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 01:21:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:53:31","updated":"2026-01-22 01:21:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/35941","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=35941"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/35941\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=35941"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=35941"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=35941"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}