👩🏽‍💼 👩🏼‍🎤 ⤴️ Etiquetagem baseada em conteúdo no werf collector: por que e como funciona? 👩🏾‍🤝‍👩🏼 🙋🏾 ☀️

werf é nosso utilitário GitOps CLI de código aberto para criar e entregar aplicativos ao Kubernetes. Na versão v1.1, há um novo recurso para o coletor de imagens: marcação de imagens por conteúdo ou marcação baseada em conteúdo . Até agora, o esquema de marcação típico no werf envolvia a marcação de imagens do Docker usando uma tag Git, ramificação Git ou confirmação Git. Mas todos esses esquemas têm falhas que são completamente resolvidas pela nova estratégia de marcação. Detalhes sobre ela e por que ela é tão boa - sob o corte.

Retroceder um conjunto de microsserviços de um repositório Git

Muitas vezes, há uma situação em que o aplicativo é dividido em muitos serviços mais ou menos independentes. As liberações desses serviços podem ocorrer independentemente: um ou vários serviços podem ser liberados por vez, enquanto o restante deve continuar funcionando sem nenhuma alteração. Mas, do ponto de vista do armazenamento de código e do gerenciamento de projetos, é mais conveniente manter esses serviços de aplicativos em um único repositório.

Há situações em que os serviços são verdadeiramente independentes e não estão conectados a um aplicativo. Nesse caso, eles estarão localizados em projetos separados e seu lançamento ocorrerá através de processos de CI / CD separados em cada um dos projetos.

No entanto, na realidade, os desenvolvedores geralmente dividem um único aplicativo em vários microsserviços, mas ter um repositório e projeto separados para cada ... é um exagero óbvio. É sobre essa situação que será discutida mais adiante: vários desses microsserviços estão em um único repositório de projeto e as liberações ocorrem através de um único processo no CI / CD.

Tag Git e tag Git

Digamos que a estratégia de marcação mais comum seja usada - tag-branch- . Para ramificações Git, as imagens são marcadas com o nome da ramificação; para uma ramificação por vez, há apenas uma imagem publicada nomeada para essa ramificação. Para tags Git, as imagens são marcadas de acordo com o nome da tag.

Ao criar uma nova tag Git - por exemplo, quando uma nova versão é lançada - uma nova tag Docker será criada para todas as imagens do projeto no Docker Registry:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

Esses novos nomes de imagens passam pelos padrões do Helm para a configuração do Kubernetes. Quando a implantação é iniciada, o comando werf deployatualiza o campo imagenos manifestos do recurso Kubernetes e reinicia os recursos correspondentes devido ao nome da imagem alterado.

Problema : em um caso em que o vykata real anterior (tag Git) não alterou o conteúdo da imagem, mas apenas o tag Docker que ocorre uma vez que reinicie este Aplicativo e, consequentemente, seja o mais simples possível. Embora não houvesse motivo real para fazer esse reinício.

Como resultado, com o atual esquema de marcação, você precisa cercar vários repositórios Git separados e surge o problema de organizar a distribuição desses vários repositórios. Em geral, esse esquema é sobrecarregado e complexo. É melhor combinar muitos serviços em um único repositório e criar essas tags do Docker para que não haja reinicializações desnecessárias.

Marcação de confirmação do Git

O Werf também tem uma estratégia de marcação relacionada aos commit do Git.

Git-commit é o identificador do conteúdo do repositório Git e depende do histórico de edições de arquivo no repositório Git, portanto, parece lógico usá-lo para marcar imagens no Docker Registry.

No entanto, a marcação pelo commit do Git tem as mesmas desvantagens dos ramos do Git ou das tags do Git:

, , Docker- .
merge-, , Docker- .
, Git, , Docker- .

Git-

Há outro problema relacionado à estratégia de marcação para as ramificações do Git.

A marcação pelo nome de uma ramificação funciona, desde que as confirmações dessa ramificação sejam coletadas seqüencialmente em ordem cronológica.

Se no esquema atual o usuário começar a reconstruir a confirmação antiga associada a alguma ramificação, o werf apagará a imagem usando a tag Docker correspondente com a versão recém-montada da imagem para a confirmação antiga. As implantações que usam essa tag a partir de agora em risco durante o reinício do pod para extrair outra versão da imagem, como resultado do qual nosso aplicativo perderá a conexão com o sistema de IC e ficará fora de sincronia.

Além disso, com push'ahs consecutivos em um ramo com um pequeno intervalo de tempo entre eles, o commit antigo pode ser coletado posteriormente ao mais recente: a versão antiga da imagem apagará o novo usando a tag do branch Git. Esses problemas podem ser resolvidos pelo sistema CI / CD (por exemplo, no GitLab CI, o pipeline deste último é lançado para uma série de confirmações). No entanto, isso não é suportado por todos os sistemas e deve haver uma maneira mais confiável de evitar um problema tão fundamental.

O que é marcação baseada em conteúdo?

Então, o que exatamente é a marcação baseada em conteúdo - etiquetar imagens por conteúdo.

Para criar tags Docker, não são usadas as primitivas Git (ramificação Git, tag Git ...), mas uma soma de verificação associada a:

. - . , ;
Git. , Git- werf, -.

A chamada assinatura dos estágios da imagem atua como uma etiqueta de identificação .

Cada imagem é composta por um conjunto de passos: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patchetc. Cada estágio possui um identificador, que reflete seu conteúdo - o estágio de assinatura (assinatura do estágio) .

A imagem final, composta por esses estágios, é marcada com a chamada assinatura do conjunto desses estágios - assinatura de estágios - que é generalizada para todos os estágios da imagem.

Cada imagem da configuração werf.yamlgeralmente possui sua própria assinatura e, consequentemente, a tag Docker.

A assinatura do palco resolve todos esses problemas:

Resistente ao commit vazio do git.
Resistente ao git confirma que alteram arquivos que não são relevantes para a imagem.
Não leva a um problema de moagem da versão atual da imagem ao reiniciar montagens para confirmações antigas do Git da ramificação.

Agora, essa é a estratégia de marcação recomendada e é usada por padrão no werf para todos os sistemas de IC.

Como ativar e usar no werf

A opção correspondente apareceu para a equipe werf publish: --tag-by-stages-signature=true|false

no sistema de CI, a estratégia de marcação é definida pelo comando werf ci-env. Anteriormente, um parâmetro era definido para ele werf ci-env --tagging-strategy=tag-or-branch. Agora, se você especificar werf ci-env --tagging-strategy=stages-signatureessa opção ou não, o werf usará uma estratégia de marcação por padrão stages-signature. O comando werf ci-envdefinirá automaticamente os sinalizadores necessários para o comando werf build-and-publish(ou werf publish), portanto, nenhuma opção adicional para esses comandos precisará ser especificada.

Por exemplo, o comando:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... pode criar as seguintes imagens:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

Aqui 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386destá a assinatura dos estágios da imagem backende f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6a assinatura dos estágios da imagem frontend.

Ao usar funções especiais werf_container_imagee werf_container_envnos modelos do Helm, nada precisa ser alterado: essas funções geram automaticamente os nomes de imagem corretos.

Exemplo de configuração em um sistema de IC:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Mais informações de configuração estão disponíveis na documentação:

Total

Nova opção werf publish --tag-by-stages-signature=true|false.
O novo valor da opção werf ci-env --tagging-strategy=stages-signature|tag-or-branch(se não for especificado, será por padrão stages-signature).
Se as opções de marcação para confirmações do Git foram usadas antes ( WERF_TAG_GIT_COMMITou a opção werf publish --tag-git-commit COMMIT), certifique-se de mudar para a estratégia de marcação com assinatura de estágios .
Novos projetos são melhores para mudar imediatamente para um novo esquema de marcação.
Ao traduzir para o werf 1.1, é aconselhável alternar projetos antigos para o novo esquema de identificação, no entanto, a identificação ou ramificação antiga ainda é suportada.

A marcação com base em conteúdo resolve todos os problemas destacados no artigo:

A estabilidade do nome da tag do Docker para esvaziar confirmações do git.
A estabilidade do nome da marca do Docker no Git confirma que alteram arquivos que não são relevantes para a imagem.
Não leva a um problema de moagem da versão atual da imagem ao reiniciar montagens para confirmações antigas do Git para ramificações do Git.

Use-o! E não se esqueça de visitar o nosso GitHub para criar um problema ou encontrar um existente, colocar um plus, criar um PR ou apenas assistir ao desenvolvimento do projeto.

Etiquetagem baseada em conteúdo no werf collector: por que e como funciona?