GitOps : les in­fras­truc­tures au­to­ma­ti­sées ex­pli­quées

GitOps est un concept qui gère des in­fras­truc­tures et des ap­pli­ca­tions via une approche dé­cla­ra­tive et qui les contrôle à l’aide de Git. Son but est d’assurer un trai­te­ment au­to­ma­tisé qui permette de gagner du temps et ga­ran­tisse une col­la­bo­ra­tion sûre des équipes in­di­vi­duelles d’un dépôt à l’autre.

Dans le domaine du dé­ve­lop­pe­ment logiciel, l’au­to­ma­ti­sa­tion est im­por­tante. C’est l’une des raisons pour les­quelles DevOps a acquis une telle po­pu­la­rité. L’idée sous-jacente est celle de l’« in­fras­truc­ture en tant que Code » (IaC), dont l’intention est de mapper les in­fras­truc­tures et con­fi­gu­ra­tions d’un système in­for­ma­tique de manière à les rendre re­pro­duc­tibles. GitOps est une extension logique de cette approche. Depuis 2017, le logiciel open source Git contrôle le processus complet d’une ap­pli­ca­tion, de son ad­mi­nis­tra­tion à son dé­ve­lop­pe­ment logiciel final, en tant que « source unique de vérité ». À cette fin, GitOps définit un état cible et, si né­ces­saire, ajuste l’in­fras­truc­ture jusqu’à ce que cet état soit atteint.

Wea­ve­works dévoile un ensemble de bonnes pratiques quant à l’uni­fi­ca­tion des méthodes de su­per­vi­sion des con­te­neurs. Ces dernières sont valables pour Ku­ber­netes et pour d’autres tech­no­lo­gies 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 à dif­fé­rentes équipes de col­la­bo­rer sur un projet en parallèle. Les chan­ge­ments ne sont adoptés qu’après une coor­di­na­tion conjointe et les anciens statuts sont préservés. Les dé­ve­lop­peurs peuvent tra­vail­ler si­mul­ta­né­ment sur dif­fé­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é­cla­ra­tive. Les chan­ge­ments sont apportés con­for­mé­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 en­vi­ron­ne­ment com­pre­nant 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 chan­ge­ments ratifiés, ils sont fusionnés à l’état antérieur et appliqués di­rec­te­ment à l’in­fras­truc­ture en live. Ceci rend le trai­te­ment à la fois plus rapide et plus fluide, tout en assurant la stabilité et la fiabilité du système.

Du fait de principes clai­re­ment définis et immuables, les flux d’activité de GitOps s’avèrent re­la­ti­ve­ment fiables. Ceci affecte les systèmes dé­cla­ra­tifs qui sont habitués à d’autres systèmes Cloud Native. La des­crip­tion dé­cla­ra­tive 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 im­mé­dia­te­ment. De plus, les clés SSH assurent la pos­si­bi­lité de toujours pouvoir tracer l’origine d’un code. Du fait des dé­cla­ra­tions an­té­rieures, les chan­ge­ments peuvent être au­to­ma­ti­sés et les possibles sources d’erreurs détectées et corrigées à un stade précoce.

L’approche fon­da­men­tale de DevOps a toujours été la fusion du dé­ve­lop­pe­ment et de l’exécution pour sim­pli­fier les flux d’activité. Comme les équipes col­la­bo­rent étroi­te­ment, cela tend à améliorer le produit final et permet que des chan­ge­ments 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é­ra­tions). GitOps se focalise en­tiè­re­ment sur Git, tandis que DevOps et DevSecOps sont des idées plus fon­da­men­tales visant à susciter la col­la­bo­ra­tion 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 dif­fé­rence de la dis­tri­bu­tion continue et de l’in­té­gra­tion continue, GitOps tire toutes les in­for­ma­tions né­ces­saires di­rec­te­ment de Git con­for­mé­ment au principe du « pull », et ce sans dé­ploie­ment via un serveur CI. Ceci peut être utilisé avec GitOps mais n’est désormais res­pon­sable que de la phase de dé­ve­lop­pe­ment et de test. Apprenez-en plus sur la Con­ti­nuous In­te­gra­tion vs. Con­ti­nuous Delivery vs. Con­ti­nuous De­ploy­ment dans notre Digital Guide.

Du fait de sa po­ly­va­lence, Ku­ber­netes constitue sans nul doute la pla­te­forme la plus im­por­tante pour gérer des ap­pli­ca­tions basées sur des con­te­neurs. Ku­ber­netes fonc­tionne de manière dé­cla­ra­tive et considère l’état-cible d’un système, ce qui en fait une bonne option pour tra­vail­ler avec GitOps et pour faire office d’opérateur. Néanmoins, pour des raisons de sécurité et pour bé­né­fi­cier d’un meilleur aperçu, le code source et la con­fi­gu­ra­tion 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 syn­chro­ni­sa­tion ap­pro­priés devront être utilisés.

Il existe désormais un vaste choix d’outils pour GitOps, lesquels visent à sim­pli­fier et améliorer l’au­to­ma­ti­sa­tion. On y retrouve des outils pour tra­vail­ler avec Ku­ber­netes en tant qu’opé­ra­teurs pour l’im­plé­men­ta­tion de GitOps. L’opérateur (ou con­trô­leur per­son­na­lisé) est Flux. ArgoCD et Fleet en sont des al­ter­na­tives. 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 con­vien­nent par­fai­te­ment à une uti­li­sa­tion conjointe avec des clusters Ku­ber­netes. Dans l’ensemble, le marché est re­la­ti­ve­ment étendu, de sorte qu’il existe un outil adapté à chaque ap­pli­ca­tion ou presque.

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

• La pro­duc­ti­vité : l’au­to­ma­ti­sa­tion garantit le fait que les chan­ge­ments soient effectués en un temps réduit. Cela permet aux dé­ve­lop­peurs de tra­vail­ler plus ef­fi­ca­ce­ment.
• La sécurité et la stabilité : les vé­ri­fi­ca­tions précises ont pour effet que les erreurs sont détectées ra­pi­de­ment et corrigées au­to­ma­ti­que­ment. Ceci contribue à une sécurité et une stabilité accrues. Grâce aux rollbacks ré­si­lients, il est beaucoup plus facile de rétablir les états pré­cé­dents et l’approche « pull » évite des com­pli­ca­tions non sou­hai­tées.
• L’unité : les flux d’activité sont stan­dar­di­sés via GitOps. Ceci conduit à une col­la­bo­ra­tion à la fois meilleure et plus facile et permet aux nouveaux employés de se lancer plus ra­pi­de­ment.

• La sé­pa­ra­tion du CI et du CD : du fait de la stricte sé­pa­ra­tion du CI et du CD dans l’approche GitOps, il peut être difficile de réaliser des tests post-dé­ploie­ment.
• Vision d’ensemble : lorsque l’on travaille avec de multiples en­vi­ron­ne­ments, GitOps peut laisser un peu perplexe. La mul­ti­pli­cité des dépôts et des con­fi­gu­ra­tions peut ajouter à cette confusion.