{"id":35594,"date":"2019-10-31T22:05:15","date_gmt":"2019-10-31T19:05:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/gitops-sravnenie-metodov-pull-i-push\/"},"modified":"2019-10-31T22:05:15","modified_gmt":"2019-10-31T19:05:15","slug":"gitops-sravnenie-metodov-pull-i-push","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps : comparaison des m\u00e9thodes Pull et Push","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Note de traduction.<\/b>: Dans la communaut\u00e9 Kubernetes, une tendance appel\u00e9e GitOps gagne en popularit\u00e9, comme nous l\u2019avons personnellement constat\u00e9, en visitant<\/a><\/noindex> KubeCon Europe 2019. Ce terme a \u00e9t\u00e9 invent\u00e9 relativement r\u00e9cemment par le responsable de l\u2019entreprise Weaveworks \u2014 Alexis Richardson \u2014 et d\u00e9signe l\u2019utilisation d\u2019outils familiers aux d\u00e9veloppeurs (principalement Git, d\u2019o\u00f9 le nom) pour r\u00e9soudre des probl\u00e8mes d\u2019exploitation. En particulier, il s\u2019agit de l\u2019exploitation de Kubernetes par le stockage de ses configurations dans Git et de l\u2019application automatique des modifications dans le cluster. Matthias Jg aborde ces deux approches dans cet article.<\/a><\/noindex> (en r\u00e9alit\u00e9, cela a formellement eu lieu en ao\u00fbt 2017 \u2014 note de la traduction.)<\/i><\/p>\n

\"GitOps
\n
\nL'ann\u00e9e derni\u00e8re un nouvel abord de d\u00e9ploiement d\u2019applications dans Kubernetes est apparu. Celui-ci est appel\u00e9 GitOps, et il repose sur le principe fondamental selon lequel le suivi des versions des d\u00e9ploiements est effectu\u00e9 dans un environnement s\u00e9curis\u00e9 d\u2019un d\u00e9p\u00f4t Git.<\/i> Une nouvelle approche du d\u00e9ploiement d'applications dans Kubernetes a vu le jour. Elle s'appelle GitOps et repose sur le principe fondamental que le suivi des versions des d\u00e9ploiements se fait dans un environnement Git s\u00e9curis\u00e9.<\/a><\/noindex><\/p>\n

Versionnement des d\u00e9ploiements et historique des modifications<\/b>:<\/p>\n

    \n
  1. Versionnage des d\u00e9ploiements et historique des modifications<\/b>. L'\u00e9tat complet du cluster est conserv\u00e9 dans un d\u00e9p\u00f4t Git, et les d\u00e9ploiements ne sont mis \u00e0 jour que par des commits. De plus, toutes les modifications peuvent \u00eatre suivies gr\u00e2ce \u00e0 l'historique des commits.<\/li>\n
  2. . La simple<\/b>git reset permet de r\u00e9tablir les modifications dans les d\u00e9ploiements ; les \u00e9tats pr\u00e9c\u00e9dents sont toujours accessibles.<\/code> permet de revenir aux versions ant\u00e9rieures des d\u00e9ploiements; les \u00e9tats pass\u00e9s sont toujours accessibles.<\/li>\n
  3. . En g\u00e9n\u00e9ral, un syst\u00e8me Git contient de nombreuses donn\u00e9es sensibles, c\u2019est pourquoi la plupart des entreprises accordent une attention particuli\u00e8re \u00e0 sa protection. Cette protection s\u2019\u00e9tend donc \u00e9galement aux op\u00e9rations sur les d\u00e9ploiements.<\/b>. En g\u00e9n\u00e9ral, un syst\u00e8me Git contient de nombreuses donn\u00e9es sensibles, c'est pourquoi la majorit\u00e9 des entreprises accordent une attention particuli\u00e8re \u00e0 sa protection. Cette protection s'\u00e9tend \u00e9galement aux op\u00e9rations sur les d\u00e9ploiements.<\/li>\n
  4. . La plupart des syst\u00e8mes Git prennent en charge d\u00e8s le d\u00e9part des politiques pour diff\u00e9rentes branches \u2014 par exemple, seules les pull requests peuvent mettre \u00e0 jour la master, et les modifications doivent \u00eatre examin\u00e9es et accept\u00e9es par un autre membre de l\u2019\u00e9quipe. Comme pour le contr\u00f4le d\u2019acc\u00e8s, les m\u00eames politiques s\u2019appliquent aux mises \u00e0 jour des d\u00e9ploiements.<\/b>. La plupart des syst\u00e8mes Git prennent initialement en charge des politiques pour diff\u00e9rentes branches - par exemple, seuls les pull requests peuvent mettre \u00e0 jour le master, et les modifications doivent \u00eatre v\u00e9rifi\u00e9es et accept\u00e9es par un autre membre de l'\u00e9quipe. Comme pour le contr\u00f4le d'acc\u00e8s, les m\u00eames politiques s'appliquent aux mises \u00e0 jour des d\u00e9ploiements.<\/li>\n<\/ol>\n

    \nComme vous pouvez le voir, la m\u00e9thode GitOps pr\u00e9sente de nombreux avantages. Au cours de l'ann\u00e9e derni\u00e8re, deux approches ont particuli\u00e8rement gagn\u00e9 en popularit\u00e9. L'une est bas\u00e9e sur le push, l'autre sur le pull. Avant d'examiner ces approches, regardons d'abord \u00e0 quoi ressemblent les d\u00e9ploiements typiques de Kubernetes.<\/p>\n

    Au cours des derni\u00e8res ann\u00e9es, diff\u00e9rentes m\u00e9thodes et outils de d\u00e9ploiement se sont \u00e9tablis dans Kubernetes :<\/h2>\n

    \nBas\u00e9 sur des mod\u00e8les natifs de Kubernetes\/Kustomize.<\/p>\n

      \n
    1. Bas\u00e9 sur des mod\u00e8les natifs Kubernetes\/Kustomize<\/b>C'est la mani\u00e8re la plus simple de d\u00e9ployer des applications dans Kubernetes. Le d\u00e9veloppeur cr\u00e9e des fichiers YAML de base et les applique. Pour \u00e9viter de r\u00e9\u00e9crire constamment les m\u00eames mod\u00e8les, Kustomize a \u00e9t\u00e9 d\u00e9velopp\u00e9 (il transforme les mod\u00e8les Kubernetes en modules). Note de traduction.<\/b>: Kustomize a \u00e9t\u00e9 int\u00e9gr\u00e9 dans kubectl avec la version Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Les Charts Helm<\/b>. Les charts Helm permettent de cr\u00e9er des ensembles de mod\u00e8les, des init-containers, des sidecars, etc., qui sont utilis\u00e9s pour le d\u00e9ploiement d'applications avec des capacit\u00e9s de configuration plus flexibles que dans l'approche bas\u00e9e sur des mod\u00e8les. Ce m\u00e9thode repose sur des fichiers YAML mod\u00e9lis\u00e9s. Helm les remplit avec divers param\u00e8tres et les envoie ensuite \u00e0 Tiller, le composant du cluster qui les d\u00e9ploie dans le cluster et permet d'effectuer des mises \u00e0 jour et des retours en arri\u00e8re. Il est important de noter qu'en essence, Helm ins\u00e8re simplement les valeurs n\u00e9cessaires dans les mod\u00e8les et les applique de la m\u00eame mani\u00e8re que dans l'approche traditionnelle. (pour en savoir plus sur le fonctionnement de tout cela et comment l'utiliser, lisez notre article sur Helm<\/a><\/noindex> \u2014 n.d.t.)<\/i>. Il existe une grande vari\u00e9t\u00e9 de Charts Helm pr\u00eats \u00e0 l'emploi, couvrant un large \u00e9ventail de t\u00e2ches.<\/li>\n
    3. Outils alternatifs<\/b>. Il existe de nombreux outils alternatifs. Tous ont en commun qu'ils transforment certains fichiers-mod\u00e8les en fichiers YAML Kubernetes compr\u00e9hensibles et les appliquent ensuite.<\/li>\n<\/ol>\n

      \nDans notre travail, nous utilisons constamment des Charts Helm pour des outils importants (puisqu'ils contiennent beaucoup de choses pr\u00eates, ce qui facilite consid\u00e9rablement la vie) et des fichiers YAML Kubernetes \u00ab purs \u00bb pour d\u00e9ployer nos propres applications.<\/p>\n

      Pull & Push<\/h2>\n

      \nDans l'un de mes r\u00e9cents articles de blog, j'ai pr\u00e9sent\u00e9 un outil Weave Flux<\/a><\/noindex>, permettant de commettre des mod\u00e8les dans un d\u00e9p\u00f4t Git et de mettre \u00e0 jour le d\u00e9ploiement apr\u00e8s chaque commit ou push de conteneur. Mon exp\u00e9rience montre que cet outil est l'un des essentiels pour promouvoir l'approche pull, c'est pourquoi je vais souvent m'y r\u00e9f\u00e9rer. Si vous souhaitez en savoir plus sur son utilisation, voici le lien vers l'article<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Tous les avantages de l'utilisation de GitOps restent valables pour les deux approches.<\/i><\/p>\n

      Approche bas\u00e9e sur Pull<\/h2>\n

      \n\"GitOps
      \n
      \nLa d\u00e9marche pull repose sur le fait que toutes les modifications sont appliqu\u00e9es depuis l'int\u00e9rieur du cluster. \u00c0 l'int\u00e9rieur du cluster, un op\u00e9rateur v\u00e9rifie r\u00e9guli\u00e8rement les d\u00e9p\u00f4ts Git et le registre Docker associ\u00e9s. Si des modifications y surviennent, l'\u00e9tat du cluster est mis \u00e0 jour de l'int\u00e9rieur. On consid\u00e8re g\u00e9n\u00e9ralement que ce processus est assez s\u00fbr, car aucun client externe n'a acc\u00e8s aux droits d'administrateur du cluster.<\/p>\n

      Avantages :<\/b><\/p>\n

        \n
      1. Aucun client externe n'a de droits pour apporter des modifications au cluster, toutes les mises \u00e0 jour sont effectu\u00e9es de l'int\u00e9rieur.<\/li>\n
      2. Certaines outils permettent \u00e9galement de synchroniser les mises \u00e0 jour des charts Helm et de les lier au cluster.<\/li>\n
      3. Le registre Docker peut \u00eatre scann\u00e9 pour d\u00e9tecter de nouvelles versions. Si une nouvelle image appara\u00eet, le d\u00e9p\u00f4t Git et le d\u00e9ploiement sont mis \u00e0 jour vers la nouvelle version.<\/li>\n
      4. Les outils pull peuvent \u00eatre r\u00e9partis dans diff\u00e9rents espaces de noms avec diff\u00e9rents d\u00e9p\u00f4ts Git et droits d'acc\u00e8s. Cela permet d'appliquer un mod\u00e8le multi-tenant. Par exemple, l'\u00e9quipe A peut utiliser l'espace de nom A, l'\u00e9quipe B l'espace de nom B, et l'\u00e9quipe en charge de l'infrastructure peut utiliser un espace de nom global.<\/li>\n
      5. En g\u00e9n\u00e9ral, les outils sont assez l\u00e9gers.<\/li>\n
      6. En combinaison avec des outils tels que l'op\u00e9rateur Bitnami Sealed Secrets<\/a><\/noindex>, les secrets peuvent \u00eatre stock\u00e9s sous forme chiffr\u00e9e dans le d\u00e9p\u00f4t Git et extraits \u00e0 l'int\u00e9rieur du cluster.<\/li>\n
      7. Il n'y a pas de lien avec les pipelines CD, car les d\u00e9ploiements se font \u00e0 l'int\u00e9rieur du cluster.<\/li>\n<\/ol>\n

        \nInconv\u00e9nients<\/b>:<\/p>\n

          \n
        1. G\u00e9rer les secrets des d\u00e9ploiements depuis des charts Helm est plus complexe que les secrets ordinaires, car ils doivent d'abord \u00eatre g\u00e9n\u00e9r\u00e9s sous forme de secrets scell\u00e9s, puis d\u00e9chiffr\u00e9s par un op\u00e9rateur interne avant de devenir accessibles \u00e0 l'outil de pull. Ensuite, un release peut \u00eatre lanc\u00e9 dans Helm avec les valeurs d\u00e9j\u00e0 d\u00e9ploy\u00e9es dans les secrets. La mani\u00e8re la plus simple est de cr\u00e9er un secret avec toutes les valeurs Helm utilis\u00e9es pour le d\u00e9ploiement, de le d\u00e9chiffrer et de le commettre dans Git.<\/li>\n
        2. En appliquant l'approche pull, vous \u00eates contraint d'utiliser des outils qui fonctionnent avec des pulls. Cela limite la possibilit\u00e9 de configurer le processus de d\u00e9ploiement des d\u00e9ploiements dans le cluster. Par exemple, travailler avec Kustomize est compliqu\u00e9, car il doit \u00eatre ex\u00e9cut\u00e9 avant que les mod\u00e8les finaux n'atteignent Git. Je ne dis pas qu\u2019il est impossible d\u2019utiliser des outils s\u00e9par\u00e9s, mais leur int\u00e9gration dans le processus de d\u00e9ploiement est plus difficile.<\/li>\n<\/ol>\n

          <\/p>\n

          Approche bas\u00e9e sur le push<\/h2>\n

          \n\"GitOps
          \n
          \nDans l'approche push, un syst\u00e8me externe (principalement des pipelines CD) d\u00e9clenche des d\u00e9ploiements dans le cluster apr\u00e8s un commit dans le d\u00e9p\u00f4t Git ou en cas d'ex\u00e9cution r\u00e9ussie du pipeline CI pr\u00e9c\u00e9dent. Dans cette approche, le syst\u00e8me a acc\u00e8s au cluster.<\/p>\n

          Avantages<\/b>:<\/p>\n

            \n
          1. La s\u00e9curit\u00e9 est d\u00e9termin\u00e9e par le d\u00e9p\u00f4t Git et le pipeline de build.<\/li>\n
          2. D\u00e9ployer des charts Helm est plus facile, avec un support pour les plugins Helm.<\/li>\n
          3. G\u00e9rer les secrets est plus simple, car les secrets peuvent \u00eatre utilis\u00e9s dans les pipelines et peuvent \u00e9galement \u00eatre stock\u00e9s dans Git de mani\u00e8re chiffr\u00e9e (selon les pr\u00e9f\u00e9rences de l'utilisateur).<\/li>\n
          4. Absence de d\u00e9pendance \u00e0 un outil sp\u00e9cifique, car on peut utiliser n'importe quel type d'outil.<\/li>\n
          5. Les mises \u00e0 jour des versions des conteneurs peuvent \u00eatre initi\u00e9es par le pipeline de build.<\/li>\n<\/ol>\n

            \nInconv\u00e9nients<\/b>:<\/p>\n

              \n
            1. Les donn\u00e9es d'acc\u00e8s au cluster se trouvent \u00e0 l'int\u00e9rieur du syst\u00e8me de build.<\/li>\n
            2. La mise \u00e0 jour des conteneurs des d\u00e9ploiements est toujours plus simple \u00e0 r\u00e9aliser avec un processus de pull.<\/li>\n
            3. Forte d\u00e9pendance au syst\u00e8me CD, car les pipelines n\u00e9cessaires sont peut-\u00eatre initialement \u00e9crits pour Gitlab Runners, et ensuite l'\u00e9quipe d\u00e9cidera de passer \u00e0 Azure DevOps ou Jenkins\u2026 et il faudra effectuer la migration d'un grand nombre de pipelines de build.<\/li>\n<\/ol>\n

              <\/p>\n

              Conclusion : Push ou Pull ?<\/h2>\n

              \nComme d'habitude, chaque approche a ses avantages et ses inconv\u00e9nients. Certaines t\u00e2ches sont plus faciles \u00e0 r\u00e9aliser avec l'une et plus difficiles avec l'autre. Au d\u00e9but, je d\u00e9ployais manuellement, mais apr\u00e8s avoir trouv\u00e9 quelques articles sur Weave Flux, j'ai d\u00e9cid\u00e9 d'impl\u00e9menter des processus GitOps pour tous les projets. Pour les mod\u00e8les de base, cela s'est av\u00e9r\u00e9 facile, mais j'ai ensuite commenc\u00e9 \u00e0 rencontrer des difficult\u00e9s avec les charts Helm. \u00c0 l'\u00e9poque, Weave Flux n'offrait qu'une version embryonnaire de Helm Chart Operator, mais m\u00eame maintenant, certaines t\u00e2ches sont plus compliqu\u00e9es en raison de la n\u00e9cessit\u00e9 de cr\u00e9er manuellement des secrets et de les appliquer. On peut dire que l'approche pull est beaucoup plus s\u00e9curis\u00e9e, car les informations d'identification du cluster ne sont pas accessibles de l'ext\u00e9rieur, ce qui am\u00e9liore tellement la s\u00e9curit\u00e9 qu'il en vaut la peine de faire des efforts suppl\u00e9mentaires.<\/p>\n

              Apr\u00e8s r\u00e9flexion, je suis arriv\u00e9 \u00e0 la conclusion inattendue que ce n'est pas le cas. En ce qui concerne les composants n\u00e9cessitant une protection maximale, cela inclurait les stockages de secrets et les syst\u00e8mes CI\/CD, ainsi que les d\u00e9p\u00f4ts Git. Les informations qu'ils contiennent sont tr\u00e8s vuln\u00e9rables et n\u00e9cessitent une protection maximale. De plus, si quelqu'un parvient \u00e0 p\u00e9n\u00e9trer dans votre d\u00e9p\u00f4t Git et \u00e0 y pousser du code, il pourra d\u00e9ployer tout ce qu'il souhaite (quel que soit l'approche choisie, que ce soit pull ou push) et s'infiltrer dans les syst\u00e8mes du cluster. Ainsi, les composants les plus critiques n\u00e9cessitant une protection sont le d\u00e9p\u00f4t Git et les syst\u00e8mes CI\/CD, pas les identifiants du cluster. Si vous avez bien configur\u00e9 les politiques et mesures de s\u00e9curit\u00e9 pour les syst\u00e8mes de ce type, et que les identifiants du cluster sont extraits dans les pipelines uniquement sous forme de secrets, la s\u00e9curit\u00e9 suppl\u00e9mentaire de l'approche pull pourrait ne pas \u00eatre aussi pr\u00e9cieuse que pr\u00e9vu au d\u00e9part.<\/p>\n

              Donc, si l'approche pull est plus laborieuse et n'apporte aucun avantage en termes de s\u00e9curit\u00e9, n'est-il pas logique d'utiliser uniquement l'approche push ? Mais quelqu'un pourrait dire qu'avec l'approche push, vous d\u00e9pendez trop du syst\u00e8me CD et qu'il serait peut-\u00eatre mieux de ne pas le faire pour faciliter les futures migrations.<\/p>\n

              \u00c0 mon avis (comme toujours), il faut utiliser ce qui convient le mieux \u00e0 chaque cas sp\u00e9cifique ou combiner diff\u00e9rentes m\u00e9thodes. Personnellement, j'utilise les deux approches : Weave Flux pour les d\u00e9ploiements bas\u00e9s sur des pulls, principalement pour nos propres services, et l'approche push avec Helm et des plugins, ce qui simplifie l'application des charts Helm au cluster et permet de cr\u00e9er des secrets sans probl\u00e8me. Je pense qu'il n'y aura jamais de solution unique adapt\u00e9e \u00e0 tous les cas, car il y a toujours beaucoup de nuances qui d\u00e9pendent des patterns d'utilisation sp\u00e9cifiques. Cela dit, je recommande vivement GitOps : cela facilite grandement la vie et am\u00e9liore la s\u00e9curit\u00e9.<\/p>\n

              J'esp\u00e8re que mon exp\u00e9rience sur ce sujet vous aidera \u00e0 choisir la m\u00e9thode qui convient le mieux \u00e0 votre type de d\u00e9ploiement, et je serais ravi d'avoir votre avis.<\/p>\n

              P.S. Note du traducteur<\/h2>\n

              \nDans les inconv\u00e9nients du mod\u00e8le pull, il y a le point selon lequel il est difficile de mettre dans Git des manifestes rendus, mais il n'y a pas d'inconv\u00e9nient, car le pipeline CD dans le mod\u00e8le pull vit s\u00e9par\u00e9ment de la mise en production et devient en quelque sorte un pipeline de la cat\u00e9gorie Continuous Apply<\/i>. Cela n\u00e9cessitera encore plus d'efforts pour collecter le statut de tous les d\u00e9ploiements et donner un acc\u00e8s aux logs\/statuts, de pr\u00e9f\u00e9rence en lien avec le syst\u00e8me CD.<\/p>\n

              Dans ce sens, le mod\u00e8le push permet de donner au moins quelques garanties au d\u00e9ploiement, car la dur\u00e9e de vie du pipeline peut \u00eatre \u00e9gale \u00e0 celle du d\u00e9ploiement.<\/p>\n

              Nous avons essay\u00e9 les deux mod\u00e8les et en sommes arriv\u00e9s aux m\u00eames conclusions que l'auteur de l'article :<\/p>\n

                \n
              1. Le mod\u00e8le pull convient pour organiser la mise \u00e0 jour des composants syst\u00e8me dans un grand nombre de clusters (voir l'article sur l'addon-operator<\/a><\/noindex>).<\/li>\n
              2. Le mod\u00e8le push bas\u00e9 sur GitLab CI convient bien au d\u00e9ploiement d'applications \u00e0 l'aide de charts Helm. De plus, le d\u00e9ploiement des d\u00e9ploiements dans le cadre des pipelines est suivi \u00e0 l'aide de l'outil werf<\/a><\/noindex>. \u00c0 propos, dans le contexte de notre projet, nous avons constamment entendu \u00ab GitOps \u00bb lorsque nous discutions des probl\u00e8mes pressants des ing\u00e9nieurs DevOps \u00e0 notre stand lors de KubeCon Europe '19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. du traducteur<\/h2>\n

                \nLisez aussi dans notre blog :<\/p>\n