{"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\/pt\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: compara\u00e7\u00e3o entre m\u00e9todos Pull e Push","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota do tradutor.<\/b>: Na comunidade Kubernetes, a tend\u00eancia chamada GitOps est\u00e1 ganhando popularidade, do que pessoalmente temos certeza, visitando<\/a><\/noindex> o KubeCon Europe 2019. Este termo foi criado relativamente recentemente, pelo chefe da Weaveworks \u2014 Alexis Richardson \u2014 e refere-se ao uso de ferramentas familiares para desenvolvedores (principalmente o Git, de onde vem o nome) para resolver problemas de opera\u00e7\u00e3o. Em particular, fala-se da opera\u00e7\u00e3o do Kubernetes atrav\u00e9s do armazenamento de suas configura\u00e7\u00f5es no Git e da implanta\u00e7\u00e3o autom\u00e1tica de altera\u00e7\u00f5es no cluster. Matthias Jg discute esses dois m\u00e9todos de implanta\u00e7\u00e3o neste artigo.<\/a><\/noindex> No ano passado<\/i><\/p>\n

\"GitOps:
\n
\n(na verdade, oficialmente isso ocorreu em agosto de 2017 \u2014 nota do tradutor) apareceu uma nova abordagem para a implanta\u00e7\u00e3o de aplica\u00e7\u00f5es no Kubernetes. Ela \u00e9 chamada GitOps, e sua base \u00e9 a ideia de que o rastreamento de vers\u00f5es de implanta\u00e7\u00f5es \u00e9 feito em um ambiente seguro de reposit\u00f3rio Git.<\/i> surgiu uma nova abordagem para a implanta\u00e7\u00e3o de aplicativos no Kubernetes. Chama-se GitOps, e sua base \u00e9 a ideia b\u00e1sica de que o rastreamento de vers\u00f5es das implanta\u00e7\u00f5es \u00e9 feito em um reposit\u00f3rio Git seguro.<\/a><\/noindex><\/p>\n

Versionamento de implanta\u00e7\u00f5es e hist\u00f3rico de altera\u00e7\u00f5es<\/b>:<\/p>\n

    \n
  1. Versionamento de implanta\u00e7\u00f5es e hist\u00f3rico de altera\u00e7\u00f5es<\/b>. O estado de todo o cluster \u00e9 armazenado em um reposit\u00f3rio Git, e as implanta\u00e7\u00f5es s\u00e3o atualizadas apenas por meio de commits. Al\u00e9m disso, todas as altera\u00e7\u00f5es podem ser rastreadas atrav\u00e9s do hist\u00f3rico de commits.<\/li>\n
  2. . Simples<\/b>permite desfazer altera\u00e7\u00f5es nas implanta\u00e7\u00f5es; estados anteriores est\u00e3o sempre dispon\u00edveis. git reset<\/code> permite reverter altera\u00e7\u00f5es nas implanta\u00e7\u00f5es; sempre s\u00e3o acess\u00edveis estados anteriores.<\/li>\n
  3. . Normalmente, um sistema Git cont\u00e9m muitos dados confidenciais, portanto, a maioria das empresas d\u00e1 grande import\u00e2ncia \u00e0 sua prote\u00e7\u00e3o. Consequentemente, essa prote\u00e7\u00e3o se estende tamb\u00e9m \u00e0s opera\u00e7\u00f5es com implanta\u00e7\u00f5es.<\/b>. Normalmente, sistemas Git cont\u00eam muitos dados confidenciais, por isso a maioria das empresas d\u00e1 aten\u00e7\u00e3o especial \u00e0 sua prote\u00e7\u00e3o. Consequentemente, essa prote\u00e7\u00e3o se estende tamb\u00e9m \u00e0s opera\u00e7\u00f5es com implanta\u00e7\u00f5es.<\/li>\n
  4. . A maioria dos sistemas Git originalmente suporta pol\u00edticas para diferentes ramifica\u00e7\u00f5es \u2014 por exemplo, apenas pull requests podem atualizar o master, e as altera\u00e7\u00f5es devem ser revisadas e aprovadas por outro membro da equipe. Assim como no controle de acesso, as mesmas pol\u00edticas se aplicam \u00e0s atualiza\u00e7\u00f5es das implanta\u00e7\u00f5es.<\/b>. A maioria dos sistemas Git inicialmente suporta pol\u00edticas para diferentes ramifica\u00e7\u00f5es \u2014 por exemplo, apenas pull requests podem atualizar a master, e as altera\u00e7\u00f5es devem ser revisadas e aprovadas por outro membro da equipe. Assim como no controle de acesso, essas mesmas pol\u00edticas se aplicam \u00e0s atualiza\u00e7\u00f5es das implanta\u00e7\u00f5es.<\/li>\n<\/ol>\n

    \nComo voc\u00ea pode ver, o m\u00e9todo GitOps possui v\u00e1rias vantagens. No \u00faltimo ano, dois enfoques ganharam popularidade. Um \u00e9 baseado em push, o outro em pull. Antes de analis\u00e1-los, vamos primeiro olhar como s\u00e3o as implanta\u00e7\u00f5es t\u00edpicas do Kubernetes.<\/p>\n

    Nos \u00faltimos anos, surgiram v\u00e1rias maneiras e ferramentas para implanta\u00e7\u00f5es no Kubernetes:<\/h2>\n

    \nBaseadas em templates nativos do Kubernetes\/Kustomize<\/p>\n

      \n
    1. Baseado em modelos nativos do Kubernetes\/Kustomize<\/b>Este \u00e9 o m\u00e9todo mais simples de implantar aplicativos no Kubernetes. O desenvolvedor cria arquivos YAML b\u00e1sicos e os aplica. Para evitar a reescrita constante dos mesmos modelos, foi desenvolvido o Kustomize (que transforma os modelos do Kubernetes em m\u00f3dulos). Nota do tradutor.<\/b>: O Kustomize foi integrado ao kubectl com o lan\u00e7amento do Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Charts do Helm<\/b>. Os charts Helm permitem criar conjuntos de modelos, init-containers, sidecars etc., que s\u00e3o aplicados para implantar aplicativos com mais flexibilidade na configura\u00e7\u00e3o do que na abordagem baseada em modelos. Este m\u00e9todo baseia-se em arquivos YAML modelados. O Helm preenche esses arquivos com diferentes par\u00e2metros e, em seguida, os envia para o Tiller \u2014 um componente do cluster que os implanta no cluster e permite realizar atualiza\u00e7\u00f5es e rollbacks. O importante \u00e9 que, essencialmente, o Helm simplesmente insere os valores necess\u00e1rios nos modelos e os aplica da mesma forma que na abordagem tradicional. (para saber mais sobre como tudo isso funciona e como us\u00e1-lo, leia o nosso artigo sobre Helm<\/a><\/noindex> \u2014 nota do tradutor.)<\/i>. Existe uma grande variedade de charts do Helm prontos, cobrindo uma ampla gama de tarefas.<\/li>\n
    3. Ferramentas alternativas<\/b>. Existem muitas ferramentas alternativas. Todas elas t\u00eam em comum o fato de transformar certos arquivos-modelo em arquivos YAML compreens\u00edveis para o Kubernetes e, em seguida, aplic\u00e1-los.<\/li>\n<\/ol>\n

      \nEm nosso trabalho, usamos constantemente charts do Helm para ferramentas importantes (j\u00e1 que muitos deles est\u00e3o prontos, o que facilita muito a vida) e arquivos YAML \"limpos\" do Kubernetes para implantar nossos pr\u00f3prios aplicativos.<\/p>\n

      Pull & Push<\/h2>\n

      \nEm uma de suas publica\u00e7\u00f5es recentes no blog, apresentei a ferramenta Weave Flux<\/a><\/noindex>, permitindo comitar modelos no reposit\u00f3rio Git e atualizar a implanta\u00e7\u00f5es ap\u00f3s cada commit ou push do cont\u00eainer. Minha experi\u00eancia mostra que essa ferramenta \u00e9 uma das principais no impulso da abordagem pull, ent\u00e3o vou me referir a ela com frequ\u00eancia. Se voc\u00ea quiser saber mais sobre como us\u00e1-la, aqui est\u00e1 o link para o artigo<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Todas as vantagens do uso do GitOps s\u00e3o mantidas para ambas as abordagens.<\/i><\/p>\n

      Abordagem baseada em Pull<\/h2>\n

      \n\"GitOps:
      \n
      \nA abordagem pull baseia-se no fato de que todas as altera\u00e7\u00f5es s\u00e3o aplicadas de dentro do cluster. Dentro do cluster, h\u00e1 um operador que verifica regularmente os reposit\u00f3rios relacionados do Git e do Docker Registry. Se houver alguma altera\u00e7\u00e3o, o estado do cluster \u00e9 atualizado internamente. Geralmente, acredita-se que esse processo \u00e9 bastante seguro, pois nenhum cliente externo tem acesso aos direitos de administrador do cluster.<\/p>\n

      Acesso direto aos sistemas de cabos transpac\u00edficos. Ping m\u00ednimo para a China, Jap\u00e3o, Austr\u00e1lia e costa oeste dos EUA.<\/b><\/p>\n

        \n
      1. Nenhum cliente externo tem direitos para fazer altera\u00e7\u00f5es no cluster, todas as atualiza\u00e7\u00f5es s\u00e3o aplicadas de dentro.<\/li>\n
      2. Algumas ferramentas tamb\u00e9m permitem sincronizar atualiza\u00e7\u00f5es de Helm charts e vincul\u00e1-las ao cluster.<\/li>\n
      3. O Docker Registry pode ser escaneado em busca de novas vers\u00f5es. Se uma nova imagem aparecer, o reposit\u00f3rio Git e a implementa\u00e7\u00e3o s\u00e3o atualizados para a nova vers\u00e3o.<\/li>\n
      4. As ferramentas pull podem ser distribu\u00eddas em diferentes namespaces com diferentes reposit\u00f3rios Git e direitos de acesso. Isso permite a aplica\u00e7\u00e3o de um modelo multitenant. Por exemplo, a equipe A pode usar o namespace A, a equipe B o namespace B, e a equipe de infraestrutura pode usar o namespace global.<\/li>\n
      5. Geralmente, as ferramentas s\u00e3o bastante leves.<\/li>\n
      6. Em combina\u00e7\u00e3o com ferramentas como o operador Bitnami Sealed Secrets<\/a><\/noindex>, segredos podem ser armazenados de forma criptografada no reposit\u00f3rio Git e extra\u00eddos dentro do cluster.<\/li>\n
      7. N\u00e3o h\u00e1 conex\u00e3o com pipelines de CD, uma vez que as implementa\u00e7\u00f5es ocorrem dentro do cluster.<\/li>\n<\/ol>\n

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

          \n
        1. Gerenciar segredos de implanta\u00e7\u00f5es a partir de gr\u00e1ficos Helm \u00e9 mais complicado do que fazer isso com os comuns, pois primeiro \u00e9 necess\u00e1rio ger\u00e1-los como, digamos, segredos selados, depois descriptograf\u00e1-los com um operador interno e s\u00f3 ent\u00e3o eles ficam dispon\u00edveis para a ferramenta de pull. Depois disso, \u00e9 poss\u00edvel iniciar um lan\u00e7amento no Helm com os valores j\u00e1 contidos nos segredos implantados. A maneira mais simples \u00e9 criar um segredo com todos os valores do Helm usados para a implanta\u00e7\u00e3o, descriptograf\u00e1-lo e comit\u00e1-lo no Git.<\/li>\n
        2. Ao aplicar a abordagem de pull, voc\u00ea se v\u00ea atado a ferramentas que operam com pulls. Isso limita a possibilidade de personalizar o processo de implanta\u00e7\u00e3o no cluster. Por exemplo, trabalhar com Kustomize torna-se mais complicado, pois ele deve ser executado antes que os modelos finais sejam enviados ao Git. N\u00e3o estou dizendo que n\u00e3o se pode usar ferramentas separadas, mas \u00e9 mais dif\u00edcil integr\u00e1-las no processo de implanta\u00e7\u00e3o.<\/li>\n<\/ol>\n

          <\/p>\n

          Abordagem baseada em Push<\/h2>\n

          \n\"GitOps:
          \n
          \nNa abordagem push, um sistema externo (principalmente pipelines de CD) dispara implanta\u00e7\u00f5es no cluster ap\u00f3s um commit no reposit\u00f3rio Git ou em caso de sucesso da execu\u00e7\u00e3o anterior do pipeline de CI. Nessa abordagem, o sistema tem acesso ao cluster.<\/p>\n

          Pr\u00f3s<\/b>:<\/p>\n

            \n
          1. A seguran\u00e7a \u00e9 determinada pelo reposit\u00f3rio Git e pelo pipeline de constru\u00e7\u00e3o.<\/li>\n
          2. Implantar charts do Helm \u00e9 mais simples, j\u00e1 que h\u00e1 suporte para plugins do Helm.<\/li>\n
          3. Gerenciar segredos \u00e9 mais f\u00e1cil, pois os segredos podem ser aplicados em pipelines e tamb\u00e9m armazenados no Git de forma criptografada (dependendo das prefer\u00eancias do usu\u00e1rio).<\/li>\n
          4. Aus\u00eancia de depend\u00eancia a ferramentas espec\u00edficas, pois \u00e9 poss\u00edvel usar qualquer tipo delas.<\/li>\n
          5. Atualiza\u00e7\u00f5es de vers\u00f5es de cont\u00eaineres podem ser iniciadas pelo pipeline de constru\u00e7\u00e3o.<\/li>\n<\/ol>\n

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

              \n
            1. Os dados para acesso ao cluster est\u00e3o dentro do sistema de constru\u00e7\u00e3o.<\/li>\n
            2. Atualizar os cont\u00eaineres de implanta\u00e7\u00f5es ainda \u00e9 mais f\u00e1cil de realizar com o processo de pull.<\/li>\n
            3. Forte depend\u00eancia do sistema de CD, uma vez que os pipelines necess\u00e1rios podem ter sido inicialmente escritos para Gitlab Runners, e depois a equipe decide migrar para Azure DevOps ou Jenkins... e ser\u00e1 necess\u00e1rio migrar um grande n\u00famero de pipelines de constru\u00e7\u00e3o.<\/li>\n<\/ol>\n

              <\/p>\n

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

              \nComo geralmente acontece, cada abordagem tem seus pr\u00f3s e contras. Algumas tarefas s\u00e3o mais f\u00e1ceis de realizar com uma e mais dif\u00edceis com outra. No in\u00edcio, eu fazia implementa\u00e7\u00f5es manualmente, mas depois de encontrar alguns artigos sobre Weave Flux, decidi implementar processos GitOps para todos os projetos. Para os templates b\u00e1sicos, isso foi f\u00e1cil, mas depois comecei a enfrentar dificuldades ao trabalhar com charts do Helm. Naquela \u00e9poca, o Weave Flux oferecia apenas uma vers\u00e3o inicial do Helm Chart Operator, mas mesmo agora algumas tarefas s\u00e3o mais complicadas devido \u00e0 necessidade de criar segredos manualmente e aplic\u00e1-los. Voc\u00ea pode argumentar que a abordagem pull \u00e9 muito mais segura, pois as credenciais do cluster n\u00e3o est\u00e3o dispon\u00edveis fora dele, o que aumenta tanto a seguran\u00e7a que vale o esfor\u00e7o extra.<\/p>\n

              Depois de refletir um pouco, cheguei a uma conclus\u00e3o inesperada: isso n\u00e3o \u00e9 verdade. Se falarmos sobre componentes que exigem m\u00e1xima prote\u00e7\u00e3o, essa lista incluir\u00e1 reposit\u00f3rios de segredos e sistemas de CI\/CD, reposit\u00f3rios Git. As informa\u00e7\u00f5es dentro deles s\u00e3o bastante vulner\u00e1veis e precisam de m\u00e1xima prote\u00e7\u00e3o. Al\u00e9m disso, se algu\u00e9m invadir seu reposit\u00f3rio Git e conseguir fazer push de c\u00f3digo, ele poder\u00e1 implantar tudo o que desejar (independentemente da abordagem escolhida, seja pull ou push) e invadir os sistemas do cluster. Assim, os componentes mais importantes que exigem prote\u00e7\u00e3o s\u00e3o os reposit\u00f3rios Git e os sistemas de CI\/CD, e n\u00e3o as credenciais do cluster. Se voc\u00ea tiver pol\u00edticas e medidas de seguran\u00e7a bem configuradas para esses sistemas e as credenciais do cluster forem extra\u00eddas para os pipelines apenas na forma de segredos, a seguran\u00e7a adicional da abordagem de pull pode n\u00e3o ser t\u00e3o valiosa quanto inicialmente se pensava.<\/p>\n

              Ent\u00e3o, se a abordagem pull \u00e9 mais trabalhosa e n\u00e3o oferece uma vantagem em seguran\u00e7a, n\u00e3o seria mais l\u00f3gico usar apenas a abordagem push? Mas algu\u00e9m pode argumentar que na abordagem push voc\u00ea fica muito dependente do sistema de CD e, talvez, seja melhor n\u00e3o fazer assim, para que seja mais f\u00e1cil realizar migra\u00e7\u00f5es no futuro.<\/p>\n

              Na minha opini\u00e3o (como sempre), devemos usar o que se adequa melhor ao caso espec\u00edfico ou combinar. Pessoalmente, uso ambas as abordagens: Weave Flux para implanta\u00e7\u00f5es baseadas em pull, que incluem principalmente nossos pr\u00f3prios servi\u00e7os, e a abordagem push com Helm e plugins, que simplifica a aplica\u00e7\u00e3o de charts Helm ao cluster e permite criar segredos sem problemas. Acredito que nunca haver\u00e1 uma solu\u00e7\u00e3o \u00fanica que sirva para todos os casos, pois h\u00e1 sempre muitas nuances que dependem da aplica\u00e7\u00e3o espec\u00edfica. Recomendo fortemente o GitOps \u2014 ele facilita muito a vida e melhora a seguran\u00e7a.<\/p>\n

              Espero que minha experi\u00eancia sobre esse tema ajude a decidir qual m\u00e9todo \u00e9 mais adequado para seu tipo de implanta\u00e7\u00f5es, e eu ficarei feliz em saber sua opini\u00e3o.<\/p>\n

              P.S. Nota do tradutor<\/h2>\n

              \nNos contras do modelo pull, h\u00e1 o ponto de que \u00e9 dif\u00edcil colocar manifests renderizados no Git, por\u00e9m n\u00e3o h\u00e1 desvantagem de que o pipeline de CD no modelo pull vive separado do rollout e, na verdade, se torna um pipeline da categoria Continuous Apply<\/i>. Portanto, ser\u00e1 necess\u00e1rio um esfor\u00e7o ainda maior para reunir o status de todas as implanta\u00e7\u00f5es e fornecer acesso de alguma forma aos logs\/status, preferencialmente vinculado ao sistema de CD.<\/p>\n

              Nesse sentido, o modelo push permite garantir alguma seguran\u00e7a na implanta\u00e7\u00e3o, uma vez que a dura\u00e7\u00e3o do pipeline pode ser feita igual \u00e0 dura\u00e7\u00e3o da implementa\u00e7\u00e3o.<\/p>\n

              Testamos ambos os modelos e chegamos \u00e0s mesmas conclus\u00f5es que o autor do artigo:<\/p>\n

                \n
              1. O modelo pull se adequa para organizar a atualiza\u00e7\u00e3o de componentes do sistema em um grande n\u00famero de clusters (veja o artigo sobre addon-operator<\/a><\/noindex>).<\/li>\n
              2. O modelo push baseado no GitLab CI se adapta bem para a implanta\u00e7\u00e3o de aplica\u00e7\u00f5es usando charts Helm. Assim, a implanta\u00e7\u00e3o das implementa\u00e7\u00f5es dentro dos pipelines \u00e9 monitorada por meio da ferramenta werf<\/a><\/noindex>. A prop\u00f3sito, no contexto deste nosso projeto, ouvimos constantemente 'GitOps' quando discut\u00edamos os problemas urgentes dos engenheiros DevOps em nosso estande na KubeCon Europe '19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. do tradutor<\/h2>\n

                \nConfira tamb\u00e9m em nosso blog:<\/p>\n