Get best of the week

Versão Werf 1.1: melhorias no colecionador hoje e planos para o futuro



werf é nosso utilitário GitOps CLI de código aberto para criar e entregar aplicativos ao Kubernetes. Como prometido, o lançamento da v1.0 marcou o início da adição de novos recursos ao werf e da revisão de abordagens familiares. Agora temos o prazer de lançar a v1.1, que é um grande passo no desenvolvimento e no futuro do werf coletor . A versão está atualmente disponível no canal 1.1 ea .

A base do release é a nova arquitetura do armazenamento de palco e a otimização do trabalho de ambos os coletores (para Stapel e Dockerfile). A nova arquitetura de armazenamento abre a possibilidade de implementar assemblies distribuídos de vários hosts e assemblies paralelos em um único host.

A otimização do trabalho inclui a eliminação de cálculos desnecessários no estágio de cálculo de assinaturas de estágio e a alteração dos mecanismos de cálculo das somas de verificação de arquivo para outras mais eficientes. Essa otimização reduz o tempo médio de construção de um projeto usando werf. E as construções inativas, quando todos os estágios existem no cache de armazenamento de estágios , agora são muito rápidas. Na maioria dos casos, reiniciar a montagem será mais rápido que em 1 segundo! Isso também se aplica aos procedimentos para verificar etapas durante o trabalho de equipes werf deploye werf run.

Também nesta versão, havia uma estratégia para marcar imagens por conteúdo - marcação baseada em conteúdo , que agora está ativada por padrão e é a única recomendada.

Vamos examinar mais de perto as principais inovações do werf v1.1 e, ao mesmo tempo, falar sobre planos para o futuro.

O que mudou no werf v1.1?


Novo formato de nomeação de estágio e algoritmo de seleção de estágio de cache


Nova regra de geração de nome de estágio. Agora, cada montagem do estágio gera um nome de estágio exclusivo, que consiste em 2 partes: uma assinatura (como na v1.0) mais um identificador temporário exclusivo.

Por exemplo, o nome completo da imagem do palco pode ser assim:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

... ou em geral:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Aqui:

  • SIGNATURE - esta é a assinatura do palco, que representa o identificador do conteúdo do palco e depende do histórico de edições no Git que levaram a esse conteúdo;
  • TIMESTAMP_MILLISEC - Isso garante um identificador exclusivo para a imagem gerada no momento da montagem da nova imagem.

O algoritmo para selecionar estágios do cache é baseado na verificação do relacionamento dos commit do Git:

  1. Werf calcula a assinatura de algum estágio.
  2. No armazenamento de estágios , pode haver vários estágios para uma determinada assinatura. Werf seleciona todos os estágios adequados para a assinatura.
  3. Se o estado actual está associada com GIT (git-arquivo, passo utilizador c git-manchas: install, beforeSetup, setup, ou git-última-adesivo), em seguida, Werf selecciona apenas os passos que se referem a cometer, que é o antepassado da corrente cometer (para a qual causada conjunto )
  4. Dos estágios adequados restantes, um é selecionado - o mais antigo por data de criação.

Um estágio para diferentes ramificações do Git pode ter a mesma assinatura. Mas o werf impedirá o uso de um cache associado a diferentes ramificações entre essas ramificações, mesmo que as assinaturas correspondam.

→ Documentação .

Novo algoritmo para criar e salvar estágios no armazenamento de estágios


Se o werf não encontrar um estágio adequado durante a seleção de estágios do cache, o processo de montagem de um novo estágio será iniciado.

Observe que vários processos (em um ou mais hosts) podem começar a montar o mesmo estágio aproximadamente ao mesmo tempo. O Werf usa o algoritmo de bloqueio otimista de armazenamento de estágios quando uma imagem recém-coletada é armazenada no armazenamento de estágios . Assim, quando a montagem do novo estágio estiver pronta, o werf bloqueia o armazenamento dos estágios e salva a imagem recém-coletada apenas se não houver uma imagem adequada (para a assinatura e outros parâmetros - consulte o novo algoritmo para selecionar os estágios do cache) .

É garantido que uma imagem recém-escolhida tenha um identificador exclusivo TIMESTAMP_MILLISEC (consulte o novo formato de nomeação de estágio) . Se uma imagem adequada for encontrada no armazenamento de estágios , o werf descartará a imagem recém-coletada e usará a imagem do cache.

Em outras palavras: o primeiro processo que concluir a coleta da imagem (o mais rápido) receberá o direito de salvá-la no armazenamento de estágios (e, em seguida, essa imagem em particular será usada para todas as montagens). Um processo lento de montagem nunca impedirá que um processo mais rápido salve os resultados da montagem do estágio atual e prossiga para a próxima montagem.

→ Documentação .

Desempenho aprimorado do coletor do Dockerfile


No momento, o pipeline do estágio para uma imagem compilada do Dockerfile consiste em um estágio - dockerfile. Ao calcular a assinatura, é considerada a soma de verificação dos arquivos context, que será usada durante a montagem. Antes dessa melhoria, o werf atravessava recursivamente todos os arquivos e recebia uma soma de verificação, resumindo o contexto e o modo de cada arquivo. A partir da v1.1, o werf pode usar as somas de verificação calculadas armazenadas no repositório Git.

O algoritmo é baseado no git ls-tree . O algoritmo leva em consideração as entradas .dockerignoree passa recursivamente pela árvore de arquivos somente se necessário. Assim, nos livramos da leitura do sistema de arquivos, e a dependência do algoritmo no tamanho contextnão é significativa.

O algoritmo também verifica arquivos não rastreados e, se necessário, leva-os em consideração na soma de verificação.

Desempenho aprimorado ao importar arquivos


O Werf v1.1 usa o servidor rsync ao importar arquivos de artefatos e imagens . Anteriormente, a importação era realizada em duas etapas usando a montagem do diretório a partir do sistema host.

O desempenho da importação no macOS não está mais limitado aos volumes do Docker, e as importações são feitas ao mesmo tempo que o Linux e o Windows.

Etiquetagem baseada em conteúdo


O Werf v1.1 suporta a chamada marcação pelo conteúdo da imagem - marcação baseada em conteúdo . As tags para as imagens resultantes do Docker dependem do conteúdo dessas imagens.

Quando você executa o comando werf publish --tags-by-stages-signatureou werf ci-env --tagging-strategy=stages-signature, as imagens publicadas da chamada assinatura do estágio de imagem serão testadas . Cada imagem é marcada com sua própria assinatura dos estágios desta imagem, calculada de acordo com as mesmas regras da assinatura regular de cada estágio separadamente, mas é um identificador generalizado da imagem.

A assinatura dos estágios da imagem depende de:

  1. o conteúdo desta imagem;
  2. Histórico de revisões do Git que levaram a este conteúdo.

Os repositórios Git sempre têm confirmações inativas que não modificam o conteúdo dos arquivos de imagem. Por exemplo, confirma apenas com comentários ou confirma mesclagem ou confirma que alteram os arquivos no Git que não serão importados para a imagem.

O uso da marcação baseada em conteúdo resolve o problema de reinicializações desnecessárias dos pods de aplicativos no Kubernetes devido a alterações no nome da imagem, mesmo que o conteúdo da imagem não tenha sido alterado. A propósito, esse é um dos motivos que dificulta o armazenamento de muitos microsserviços de um aplicativo em um único repositório Git.

Além disso, a marcação baseada em conteúdo é um método de marcação mais confiável do que a marcação pelas ramificações do Git, porque o conteúdo das imagens resultantes não depende da ordem de execução dos pipelines no sistema de IC para reunir vários commits da mesma ramificação.

Importante: A partir de agora, a assinatura de estágios é a única estratégia de marcação recomendada . Ele será usado por padrão na equipe werf ci-env(a menos que você especifique explicitamente um esquema de marcação diferente).

→ Documentação . Uma publicação separada também será dedicada a esse recurso. ATUALIZADO (3 de abril): Um artigo com detalhes foi publicado .

Níveis de log


O usuário tem a oportunidade de controlar a saída, definir o nível de log e trabalhar com informações de depuração. Opções adicionadas --log-quiet, --log-verbose, --log-debug.

Por padrão, a saída contém um mínimo de informações:



Ao usar a saída detalhada ( --log-verbose), você pode rastrear como o werf funciona:



A saída detalhada ( --log-debug), além das informações de depuração do werf, também contém os logs das bibliotecas usadas. Por exemplo, você pode ver como a interação com o Docker Registry acontece e também corrigir os locais onde é gasto uma quantidade significativa de tempo:



Planos futuros


Atenção! Os recursos descritos abaixo marcados como v1.1 estarão disponíveis nesta versão, muitos deles em breve. As atualizações serão atualizadas automaticamente ao usar o multiwerf . Esses recursos não afetam a parte estável das funções da v1.1; sua aparência não exigirá intervenção manual do usuário nas configurações existentes.

Suporte completo para várias implementações do Docker Registry (NEW)



O objetivo é que o usuário use uma implementação arbitrária sem restrições ao usar o werf.

Até o momento, identificamos o seguinte conjunto de soluções para as quais garantiremos suporte total:

  • Padrão (biblioteca / registro) *,
  • AWS ECR,
  • Azure *,
  • Hub Docker
  • GCR *,
  • Pacotes do Github
  • Registro GitLab *,
  • Porto *,
  • Cais.

Um asterisco indica soluções que atualmente são totalmente suportadas pelo werf. Quanto ao resto, há suporte, mas com limitações.

Dois problemas principais podem ser distinguidos:

  • Algumas soluções não oferecem suporte à remoção de tags usando a API do Docker Registry, que não permite que os usuários usem a limpeza automática implementada no werf. Isso vale para os pacotes AWS ECR, Docker Hub e GitHub.
  • Algumas soluções não oferecem suporte aos chamados repositórios aninhados (Docker Hub, Pacotes do GitHub e Quay), mas o usuário deve criá-las manualmente usando a interface do usuário ou API (AWS ECR).

Vamos resolver esses e outros problemas usando APIs nativas de soluções. Essa tarefa também inclui a cobertura do ciclo werf completo com testes para cada um deles.

Montagem de imagem distribuída (↑)



No momento, o werf v1.0 e v1.1 pode ser usado apenas em um host dedicado para montagem e publicação de imagens e implantação de aplicativos no Kubernetes.

Para abrir as possibilidades de trabalho distribuído pelo werf, quando a montagem e a implantação de aplicativos no Kubernetes são iniciadas em vários hosts arbitrários e esses hosts não mantêm seu estado entre assemblies (corredores temporários), o werf é necessário para implementar a possibilidade de usar o Docker Registry como um repositório de estágio.

Anteriormente, quando o projeto werf ainda era chamado dapp, havia uma oportunidade. No entanto, encontramos vários problemas que devem ser considerados ao implementar esta função no werf.

Nota. Esse recurso não implica o trabalho do coletor dentro dos pods do Kubernetes, pois para fazer isso, livre-se da dependência do servidor Docker local (no pod do Kubernetes, não há acesso ao servidor Docker local, porque o próprio processo está sendo executado no contêiner, e o werf não suporta e não suporta trabalhar com o servidor Docker na rede). O suporte ao trabalho no Kubernetes será implementado separadamente.

Suporte oficial às ações do GitHub (NOVO)



Inclui documentação do werf (seções de referência e guia ), bem como a ação oficial do GitHub para trabalhar com o werf.

Além disso, permitirá que o werf trabalhe em corredores efêmeros.

A mecânica da interação do usuário com o sistema de IC será baseada na colocação de etiquetas em solicitações pull para iniciar determinadas ações para criar / implantar o aplicativo.

Desenvolvimento e implantação de aplicativos locais com werf (↓)


  • Versão: v1.1
  • Datas: janeiro a fevereiro de abril
  • Questão

O objetivo principal é obter uma única configuração unificada para implantar aplicativos localmente e em produção, sem ações complexas, prontas para uso.

O Werf também precisa de um modo de operação no qual seja conveniente editar o código do aplicativo e receber instantaneamente feedback de um aplicativo em funcionamento para depuração.

Novo algoritmo de limpeza (NOVO)



Na versão atual do werf v1.1, o procedimento cleanupnão fornece imagens de limpeza para o esquema de marcação com base em conteúdo - essas imagens serão acumuladas.

Além disso, na versão atual do werf (v1.0 e v1.1), políticas de limpeza diferentes são usadas para imagens publicadas por esquemas de marcação: branch Git, tag Git ou commit Git.

Um novo algoritmo de limpeza de imagem unificado para todos os esquemas de identificação foi inventado com base no histórico de confirmações no Git:

  • Armazene não mais que as imagens N1 associadas ao último commit de N2 para cada um dos git HEAD (ramificações e tags).
  • Armazene não mais do que os estágios de imagens N1 associados às últimas confirmações N2 para cada um dos git HEAD (ramificações e tags).
  • , - Kubernetes ( kube- namespace'; ).
  • , , Helm-.
  • , HEAD git (, HEAD ) Kubernetes Helm.

(↓)


  • : v1.1
  • : - *

A versão atual do werf coleta as imagens e artefatos descritos em werf.yaml, sequencialmente. É necessário paralelizar o processo de montagem de estágios independentes de imagens e artefatos, além de fornecer uma conclusão conveniente e informativa.

* Nota: o prazo é alterado devido à prioridade aumentada para a implementação de um assembly distribuído, que adicionará mais recursos para dimensionamento horizontal, além do uso do werf com as ações do GitHub. A montagem paralela é a próxima etapa de otimização, fornecendo escalabilidade vertical ao montar um único projeto.

Mudar para o leme 3 (↓)


  • Versão: v1.2
  • Datas: fevereiro a março de maio *

Inclui a transição para a nova base de código do Helm 3 e uma maneira comprovada e conveniente de migrar instalações existentes.

* Nota: mudar para o Helm 3 não adicionará recursos significativos ao werf, porque todos os principais recursos do Helm 3 (combinação de três vias e falta de leme) já estão implementados no werf. Além disso, o werf possui recursos adicionais além daqueles indicados. No entanto, essa transição permanece em nossos planos e será implementada.

Descrição da configuração do Jsonnet for Kubernetes (↓)


  • Versão: v1.2
  • Datas: janeiro-fevereiro, abril-maio

O Werf suportará a descrição da configuração do Kubernetes no formato Jsonnet. Ao mesmo tempo, o werf permanecerá compatível com o Helm e será possível selecionar um formato de descrição.

O motivo é o fato de os padrões de linguagem Go, de acordo com muitas pessoas, terem um grande limite de entrada, e a inteligibilidade do código desses padrões também sofrer.

Outras opções para implementar os sistemas de descrição de configuração do Kubernetes (como o Kustomize) também estão sendo consideradas.

Trabalhar dentro do Kubernetes (↓)


  • Versão: v1.2
  • Datas: abril-maio maio-junho

Objetivo: Garantir a montagem de imagens e a entrega de aplicativos usando corredores no Kubernetes. Essa. montagem de novas imagens, sua publicação, limpeza e implantação podem ocorrer diretamente dos pods do Kubernetes.

Para realizar esse recurso, você precisa primeiro da capacidade de criar imagens distribuídas (consulte o parágrafo acima) .

Também requer suporte para o modo de operação de compilação sem o servidor Docker (ou seja, uma compilação semelhante ao Kaniko ou uma compilação no espaço do usuário).

O Werf oferecerá suporte à montagem no Kubernetes não apenas com o Dockerfile, mas também com o construtor Stapel, com reconstruções incrementais e Ansible.

Passo em direção ao desenvolvimento de código aberto


Adoramos nossa comunidade ( GitHub , Telegram ) e queremos que mais e mais pessoas ajudem a melhorar o werf, entender em que direção estamos seguindo e participar do desenvolvimento.

Mais recentemente, decidiu-se mudar para os quadros de projetos do GitHub para abrir o fluxo de trabalho de nossa equipe. Agora você pode ver os planos imediatos, bem como o trabalho em andamento nas seguintes áreas:


Muito trabalho foi feito com problemas:

  • Removido irrelevante.
  • Os existentes são reduzidos para um único formato, um número suficiente de detalhes e detalhes.
  • Adicionadas novas edições com idéias e sugestões.

Como habilitar a versão v1.1


Atualmente, a versão está disponível no canal 1.1 e a (os lançamentos em canais estáveis e sólidos como o rock aparecerão à medida que se estabilizam, mas o próprio ea já é estável o suficiente para uso, pois passou pelos canais alfa e beta ). É ativado através do multiwerf da seguinte maneira:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

Conclusão


A nova arquitetura de armazenamento de palco e o desempenho otimizado dos coletores para os coletores Stapel e Dockerfile abrem a possibilidade de implementar montagens distribuídas e paralelas no werf. Esses recursos aparecerão em breve na mesma versão v1.1 e ficarão automaticamente disponíveis através do mecanismo de atualização automática (para usuários com vários usuários ).

Nesta versão, uma estratégia de marcação baseada em conteúdo foi adicionada , que se tornou a estratégia padrão. Um log também foi redesenhado os comandos básicos: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

O próximo passo significativo será adicionar assemblies distribuídos. Os assemblies distribuídos desde a v1.0 tornaram-se uma prioridade mais alta que os assemblies paralelos, porque agregam mais valor werf: escala vertical de coletores e suporte para coletores efêmeros em vários sistemas de CI / CD, bem como a capacidade de oferecer suporte oficial às ações do GitHub. Portanto, o momento da implementação de montagens paralelas foi alterado. No entanto, estamos trabalhando para realizar rapidamente as duas possibilidades.

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

PS


Leia também no nosso blog:

More articles:


All Articles