O tópico do monorepositório foi discutido mais de uma vez e, via de regra, causa um debate muito ativo. Criando o
werf como uma ferramenta de código-fonte aberto projetada para melhorar o processo de
compilação do código do aplicativo das imagens do Git para o Docker (e sua entrega subsequente ao Kubernetes), não pensamos muito sobre qual opção é melhor. É fundamental que forneçamos todo o necessário para apoiadores de opiniões diferentes (se isso não contradizer o bom senso, é claro).
O suporte recente ao mono-repo no werf é um bom exemplo. Mas primeiro, vamos ver como esse suporte geralmente está associado ao uso do werf e o que o Docker Registry tem a ver com ele ...
Edição
Imagine essa situação. A empresa possui muitas equipes de desenvolvimento envolvidas em projetos independentes. A maioria dos aplicativos é executada no Kubernetes e, portanto, é em contêiner. Para armazenar contêineres, imagens, é necessário um registro. A empresa usa o Docker Hub com uma única conta da
COMPANY como um registro. Semelhante à maioria dos sistemas de armazenamento de código-fonte, o
Docker Hub não permite criar uma hierarquia aninhada de repositórios , como
COMPANY/PROJECT/IMAGE . Nesse caso ... como manter aplicativos não monolíticos no registro com essa restriçã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 da organização do 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, não há perguntas e apenas salvamos as imagens no repositório do projeto.
Quando um aplicativo é apresentado na forma de vários componentes,
microsserviços , é necessário escolher uma abordagem específica. Usando um exemplo de um aplicativo Web típico que consiste em duas imagens:
frontend -
backend e
backend -
backend , as opções possíveis são as seguintes:
- Armazene imagens em repositórios aninhados separados:
- Armazene tudo em um repositório e leve o nome da imagem para a tag, por exemplo, da seguinte maneira:
NB : Na verdade, ainda existe a opção de salvar o PROJECT-frontend e o PROJECT-backend em vários repositórios, mas não o consideraremos devido à complexidade do suporte, organização e distribuição de direitos entre os usuários.Suporte Werf
Inicialmente, o werf se limitou a repositórios aninhados - felizmente, a maioria dos registros suporta esse recurso. A partir da versão
v1.0.4-alpha.3 , foram adicionados trabalhos com registros nos quais o
aninhamento não é
suportado e o Docker Hub entre eles. A partir desse momento, o usuário teve a opção de armazenar imagens de aplicativos.
A implementação está disponível como parte da opção
--images-repo-mode=multirepo|monorepo (por padrão,
multirepo , ou seja, armazenamento em repositórios aninhados). Ele define os padrões pelos quais as imagens são armazenadas no registro. Basta escolher o modo desejado ao usar os comandos básicos, e todo o resto permanecerá inalterado.
Como a maioria das opções werf pode ser configurada
com variáveis de ambiente , nos sistemas de CI / CD, o modo de armazenamento geralmente é fácil de configurar globalmente para todo o projeto. Por exemplo,
no caso do GitLab, basta adicionar a variável de ambiente nas configurações do projeto:
Configurações -> CI / CD -> Variáveis: WERF_IMAGES_REPO_MODE: multirepo|monorepo .
Se falamos sobre a publicação de imagens e a implementação de aplicativos (você pode ler mais sobre esses processos nos artigos relevantes da documentação:
Processo de publicação e
processo de implantação ), o modo determina exclusivamente o modelo pelo qual você pode trabalhar com a imagem.
Diabo em detalhes
A diferença e a principal dificuldade ao adicionar um novo método de armazenamento ocorre durante o processo de limpeza do registro
(para opções de limpeza suportadas pelo werf, consulte o processo de limpeza ) .
Ao limpar, o werf leva em consideração as imagens usadas nos clusters do 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 relacionadas às primitivas do Git, como tag, branch e commit;
- 1 estratégia para tags personalizadas.
Salvamos informações sobre a estratégia de tags ao publicar a imagem nos rótulos da imagem final. O significado em si - a chamada
meta tag - é necessário para a aplicação de algumas políticas. Por exemplo, ao excluir uma ramificação ou marca do repositório Git, é lógico excluir as imagens
não utilizadas associadas do registro, coberto por parte de nossas políticas.
Ao salvar em um repositório (
monorepo ), além da meta tag, o nome da imagem também pode ser armazenado na tag 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 ao publicar.
NB : Se você estiver interessado em analisar tudo descrito no código-fonte do werf, o PR 1684 pode servir como ponto de partida.Neste artigo, não prestaremos 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: “
werf é nossa ferramenta para CI / CD em Kubernetes ".
Resumindo
A falta de suporte ao registro sem aninhamento não era um fator de bloqueio para nós ou para os usuários que conhecemos - você sempre pode criar um registro de imagem separado (ou alternar para o Registro de contêiner condicional no Google Cloud) ... No entanto, remover essa restrição parecia lógico para tornar a ferramenta mais conveniente ampla comunidade DevOps. Ao implementá-lo, enfrentamos a principal dificuldade no processamento do mecanismo de limpeza do registro de contêiner. Agora que tudo está pronto, é bom perceber que ficou mais fácil para alguém, e nós (como principais desenvolvedores do projeto) não temos dificuldades significativas em apoiar ainda mais esse recurso.
Fique conosco e muito em breve falaremos sobre outras inovações no
werf !
PS
Leia também em nosso blog: