{"id":37667,"date":"2019-10-31T22:18:58","date_gmt":"2019-10-31T19:18:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry\/"},"modified":"2019-10-31T22:18:58","modified_gmt":"2019-10-31T19:18:58","slug":"podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Suporte a monorepo e multirepo no werf e qual a rela\u00e7\u00e3o com o Docker Registry.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Suporte
\n
\nO tema do monoreposit\u00f3rio j\u00e1 foi discutido diversas vezes e, geralmente, provoca debates bastante acalorados. Ao criar werf<\/a><\/noindex> uma ferramenta de c\u00f3digo aberto, destinada a melhorar os processos de constru\u00e7\u00e3o de c\u00f3digo de aplica\u00e7\u00f5es do Git em imagens Docker (e sua posterior entrega no Kubernetes), raramente refletimos sobre qual escolha \u00e9 melhor. Para n\u00f3s, o primordial \u00e9 garantir tudo que \u00e9 necess\u00e1rio para os defensores de diferentes opini\u00f5es (se isso n\u00e3o contradizer o bom senso, \u00e9 claro).<\/p>\n

O apoio recente ao mono-repo no werf \u00e9 um bom exemplo disso. Mas, antes de tudo, vamos entender como esse suporte se relaciona ao uso do werf e qual a conex\u00e3o com o Docker Registry...<\/a><\/noindex><\/p>\n

Problemas<\/h2>\n

\nVamos imaginar a seguinte situa\u00e7\u00e3o. A empresa possui v\u00e1rias equipes de desenvolvedores trabalhando em projetos independentes. A maioria das aplica\u00e7\u00f5es opera no Kubernetes, e, consequentemente, est\u00e1 conteinerizada. Para armazenar cont\u00eaineres e imagens, \u00e9 necess\u00e1rio um registro (registry). A empresa utiliza o Docker Hub com uma \u00fanica conta COMPANY<\/code>. Por analogia com a maioria dos sistemas de armazenamento de c\u00f3digo fonte, o Docker Hub n\u00e3o permite criar uma hierarquia de reposit\u00f3rios aninhados<\/b>, como COMPANY\/PROJECT\/IMAGE<\/code>. Nesse caso... como armazenar no registro aplica\u00e7\u00f5es n\u00e3o monol\u00edticas sem criar uma conta separada para cada projeto? <\/p>\n

\"Suporte
\n
\nTalvez a situa\u00e7\u00e3o descrita seja familiar para alguns, mas vamos considerar a quest\u00e3o da organiza\u00e7\u00e3o do armazenamento de aplica\u00e7\u00f5es de forma geral, ou seja, sem amarras ao exemplo mencionado acima e ao Docker Hub.<\/p>\n

Solu\u00e7\u00f5es<\/h3>\n

\nSe a aplica\u00e7\u00e3o for monol\u00edtica<\/b>, n\u00e3o h\u00e1 problemas e simplesmente armazenamos as imagens no registro de cont\u00eaineres do projeto.<\/p>\n

Quando a aplica\u00e7\u00e3o \u00e9 apresentada na forma de v\u00e1rios componentes, microsservi\u00e7os<\/b>, \u00e9 necess\u00e1rio escolher um determinado enfoque. Tomando como exemplo uma aplica\u00e7\u00e3o web t\u00edpica, composta por duas imagens: frontend<\/code> e backend<\/code> \u2014 as op\u00e7\u00f5es poss\u00edveis s\u00e3o:<\/p>\n

    \n
  1. Armazenar as imagens em reposit\u00f3rios aninhados separados:\n

    \"Suporte<\/li>\n

  2. Armazenar tudo em um \u00fanico reposit\u00f3rio, considerando o nome da imagem no tag, por exemplo, da seguinte forma:\n

    \"Suporte<\/li>\n<\/ol>\n

    \nNB<\/b>: Na verdade, h\u00e1 tamb\u00e9m a op\u00e7\u00e3o de armazenamento em diferentes reposit\u00f3rios, PROJECT-frontend<\/code> e PROJECT-backend<\/code>, mas n\u00e3o iremos considerar isso devido \u00e0 complexidade de suporte, organiza\u00e7\u00e3o e distribui\u00e7\u00e3o de direitos entre os usu\u00e1rios.<\/i><\/p>\n

    Suporte no werf<\/h2>\n

    \nInicialmente, o werf limitou-se a reposit\u00f3rios aninhados \u2014 felizmente, a maioria dos registros suporta essa possibilidade. A partir da vers\u00e3o v1.0.4-alpha.3<\/a><\/noindex>, foi adicionada a possibilidade de trabalhar com registros que n\u00e3o suportam aninhamento<\/b>, incluindo o Docker Hub. A partir de agora, o usu\u00e1rio teve a op\u00e7\u00e3o de como armazenar as imagens da aplica\u00e7\u00e3o.<\/p>\n

    A implementa\u00e7\u00e3o est\u00e1 dispon\u00edvel na op\u00e7\u00e3o --images-repo-mode=multirepo|monorepo<\/code> (por padr\u00e3o, multirepo<\/code>, ou seja, armazenamento em reposit\u00f3rios aninhados). Ela determina os padr\u00f5es de como as imagens s\u00e3o armazenadas no registro. \u00c9 suficiente escolher o modo desejado ao usar os comandos principais, e tudo o mais permanecer\u00e1 inalterado.<\/p>\n

    Como a maioria das op\u00e7\u00f5es do werf pode ser definida por vari\u00e1veis de ambiente<\/b>, em sistemas CI\/CD, o modo de armazenamento geralmente \u00e9 f\u00e1cil de definir globalmente para todo o projeto. Por exemplo, no caso do GitLab,<\/b> basta adicionar uma vari\u00e1vel de ambiente nas configura\u00e7\u00f5es do projeto: Configura\u00e7\u00f5es -> CI \/ CD -> Vari\u00e1veis: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    Falando sobre a publica\u00e7\u00e3o de imagens e o lan\u00e7amento de aplica\u00e7\u00f5es (sobre esses processos, pode-se ler em detalhes nos artigos correspondentes da documenta\u00e7\u00e3o: Processo de Publica\u00e7\u00e3o<\/a><\/noindex> e Processo de Implanta\u00e7\u00e3o<\/a><\/noindex>), o modo define exclusivamente o padr\u00e3o de como trabalhar com a imagem.<\/p>\n

    O diabo est\u00e1 nos detalhes.<\/h3>\n

    \nA diferen\u00e7a e a principal dificuldade ao adicionar uma nova forma de armazenamento s\u00e3o o processo de limpeza do registro (as capacidades de limpeza suportadas no werf est\u00e3o na Processo de Limpeza<\/a><\/noindex>)<\/i>.<\/p>\n

    Ao limpar, o werf considera as imagens usadas nos clusters Kubernetes, bem como as pol\u00edticas configuradas pelo usu\u00e1rio. A base das pol\u00edticas \u00e9 a divis\u00e3o de tags em estrat\u00e9gias. As estrat\u00e9gias atualmente suportadas s\u00e3o:<\/p>\n

      \n
    1. 3 estrat\u00e9gias relacionadas a primitivas do Git, como tag, ramo e commit;<\/li>\n
    2. 1 estrat\u00e9gia para tags personalizadas arbitr\u00e1rias.<\/li>\n<\/ol>\n

      \nAs informa\u00e7\u00f5es sobre a estrat\u00e9gia de tag s\u00e3o armazenadas ao publicar a imagem nos r\u00f3tulos da imagem final. O pr\u00f3prio valor \u2014 o chamado metatag<\/b> \u2014 \u00e9 necess\u00e1rio para a aplica\u00e7\u00e3o de algumas pol\u00edticas. Por exemplo, ao excluir um ramo ou uma tag do reposit\u00f3rio Git, \u00e9 l\u00f3gico remover tamb\u00e9m as imagens n\u00e3o utilizadas<\/i> do registro, o que \u00e9 coberto por uma parte de nossas pol\u00edticas.<\/p>\n

      Ao armazenar em um \u00fanico reposit\u00f3rio (monorepo<\/code>), na tag da imagem, al\u00e9m do metatag, tamb\u00e9m pode ser armazenado o nome da imagem: PROJETO:frontend<\/b>-META-TAG<\/code>. Para separ\u00e1-los, n\u00e3o introduzimos um delimitador espec\u00edfico, mas apenas adicionamos o valor necess\u00e1rio ao r\u00f3tulo da imagem final ao public\u00e1-la.<\/p>\n

      NB<\/b>: Se estiver interessado em ver tudo que foi descrito no c\u00f3digo-fonte do werf, um ponto de partida pode ser PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      Neste artigo, n\u00e3o vamos nos aprofundar mais nos problemas e na justificativa da nossa abordagem: sobre estrat\u00e9gias de tagueamento, armazenamento de dados em r\u00f3tulos e o processo de publica\u00e7\u00e3o em geral \u2014 tudo isso foi descrito em detalhes no recente relat\u00f3rio de Dmitry Stolyarov: \u201cwerf \u2014 nossa ferramenta para CI\/CD no Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Resumindo<\/h2>\n

      \nA falta de suporte para registros sem aninhamento n\u00e3o foi um fator bloqueador para n\u00f3s ou para os usu\u00e1rios conhecidos do werf \u2014 sempre \u00e9 poss\u00edvel levantar um registro separado de imagens (ou mudar para um Container Registry no Google Cloud)\u2026 No entanto, a remo\u00e7\u00e3o dessa limita\u00e7\u00e3o parecia l\u00f3gica para que a ferramenta fosse mais conveniente para uma comunidade DevOps mais ampla. Ao implement\u00e1-la, encontramos a principal dificuldade na reestrutura\u00e7\u00e3o do mecanismo de limpeza do registro de cont\u00eaineres. Agora, com tudo pronto, \u00e9 gratificante saber que facilitou a vida de algu\u00e9m, e para n\u00f3s (como principais desenvolvedores do projeto) n\u00e3o prevemos grandes dificuldades na manuten\u00e7\u00e3o futura dessa funcionalidade.<\/p>\n

      Fique conosco e em breve contaremos sobre outras inova\u00e7\u00f5es em werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

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