O tópico de um mono-repositório foi discutido mais de uma vez e, via de regra, causa polêmica muito ativa. Ao criar como uma ferramenta de código aberto projetada para melhorar o processo de criação de código de aplicativo do Git para imagens do Docker (e depois entregá-las ao Kubernetes), não pensamos muito sobre qual escolha é a melhor. Para nós, é primordial disponibilizar tudo o que é necessário para adeptos de opiniões diversas (se isso não contrariar o bom senso, claro).
O recente suporte mono-repo do werf é um bom exemplo disso. Mas primeiro, vamos descobrir como esse suporte geralmente está relacionado ao uso do werf e o que o Docker Registry tem a ver com isso ...
Problemas
Vamos imaginar tal situação. A empresa tem muitas equipes de desenvolvimento trabalhando em projetos independentes. A maioria dos aplicativos é executada no Kubernetes e, portanto, é conteinerizada. Para armazenar contêineres, imagens, você precisa de um registro. A empresa usa o Docker Hub como um registro com uma única conta COMPANY. Semelhante à maioria dos sistemas de armazenamento de código-fonte, O Docker Hub não permite hierarquia de repositório aninhada, como COMPANY/PROJECT/IMAGE. Nesse caso… como você pode armazenar aplicativos não monolíticos no registro com essa limitação sem criar uma conta separada para cada projeto?
Talvez a situação descrita seja familiar para alguém em primeira mão, mas vamos considerar a questão de organizar o armazenamento de aplicativos em geral, ou seja, sem referência ao exemplo acima e ao Docker Hub.
Soluções
Se o aplicativo monolítico, vem em uma imagem, então não há dúvidas e simplesmente salvamos as imagens no registro de contêiner do projeto.
Quando um aplicativo é apresentado como vários componentes, microsserviços, então uma determinada abordagem é necessária. No exemplo de um aplicativo da web típico que consiste em duas imagens: frontend и backend - as opções possíveis são:
- Armazene imagens em repositórios aninhados separados:
- Armazene tudo em um repositório e considere o nome da imagem na tag, por exemplo, da seguinte maneira:
NB: Na verdade, há outra opção de salvar em diferentes repositórios, PROJECT-frontend и PROJECT-backend, mas não vamos considerá-lo devido à complexidade do suporte, organização e distribuição de direitos entre os usuários.
suporte werf
Inicialmente, o werf limitava-se a repositórios aninhados - felizmente, a maioria dos registros oferece suporte a esse recurso. A partir da versão , adicionou trabalho com registros em que aninhamento não é suportado, e o Docker Hub é um deles. A partir daí, o usuário pode escolher como armazenar as imagens do aplicativo.
Implementação disponível sob opção --images-repo-mode=multirepo|monorepo (predefinição multirepo, ou seja armazenamento em repositórios aninhados). Ele define os padrões pelos quais as imagens são armazenadas no registro. Basta selecionar o modo desejado ao usar os comandos básicos e todo o resto permanecerá inalterado.
Porque a maioria das opções werf podem ser definidas variáveis ambientais, em sistemas CI/CD, o modo de armazenamento geralmente é fácil de definir globalmente para todo o projeto. Por exemplo, no caso do GitLab basta adicionar uma variável de ambiente nas configurações do projeto: Configurações -> CI / CD -> Variáveis: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Se falamos de publicação de imagens e implantação de aplicativos (você pode ler sobre esses processos em detalhes nos artigos de documentação relevantes: и ), o modo determina apenas o modelo pelo qual você pode trabalhar com a imagem.
O diabo está nos detalhes
A diferença e a principal dificuldade ao adicionar um novo método de armazenamento está no processo de limpeza do registro (para recursos de limpeza suportados pelo werf, consulte ).
Ao limpar, o werf leva em consideração as imagens usadas nos clusters Kubernetes, bem como as políticas configuradas pelo usuário. As políticas são baseadas na divisão de tags em estratégias. Estratégias atualmente suportadas:
- 3 estratégias vinculadas por primitivos do Git, como tag, branch e commit;
- 1 estratégia para tags personalizadas arbitrárias.
Salvamos informações sobre a estratégia de tags ao publicar a imagem nos rótulos da imagem final. O significado em si é o chamado meta tag - Necessário para aplicar algumas das políticas. Por exemplo, ao deletar um branch ou tag de um repositório Git, é lógico deletar não utilizado imagens do registro, que é coberto por parte de nossas políticas.
Quando salvo em um repositório (monorepo), na tag da imagem, além da meta tag, também pode ser armazenado o nome da imagem: PROJECT:frontend-META-TAG. Para separá-los, não introduzimos nenhum separador específico, mas simplesmente adicionamos o valor necessário ao rótulo da imagem final no momento da publicação.
NB: Se você estiver interessado em ver tudo descrito no código-fonte do werf, o ponto de partida pode ser .
Neste artigo, não daremos mais atenção aos problemas e justificativas de nossa abordagem: sobre estratégias de marcação, armazenamento de dados em rótulos e o processo de publicação como um todo - tudo isso é descrito em detalhes em um relatório recente de Dmitry Stolyarov: “".
resumindo
A falta de suporte para registros não aninhados não foi um fator de bloqueio para nós ou para os usuários werf conhecidos por nós - afinal, você sempre pode criar um registro de imagem separado (ou mudar para um Container Registry condicional no Google Cloud) ... No entanto, remover tal restrição parecia lógico para que a ferramenta fosse mais conveniente para a comunidade DevOps mais ampla. Ao implementá-lo, enfrentamos a principal dificuldade em retrabalhar o mecanismo de limpeza do registro de contêineres. Agora que tudo está pronto, é bom perceber que ficou mais fácil para alguém, e nós (como os principais desenvolvedores do projeto) não teremos nenhuma dificuldade perceptível em oferecer suporte adicional a esse recurso.
Fique conosco e muito em breve contaremos sobre outras novidades em !
PS
Leia também em nosso blog:
- «";
- «".
Fonte: habr.com