é nosso utilitário GitOps CLI de código aberto para construir e entregar aplicativos para Kubernetes. Como prometido, marcou o início da adição de novos recursos ao werf e da revisão das abordagens tradicionais. Agora temos o prazer de apresentar a versão v1.1, que é um grande passo no desenvolvimento e uma base para o futuro colecionador bem. A versão está atualmente disponível em .
A base do lançamento é uma nova arquitetura de armazenamento de palco e otimização do trabalho de ambos os coletores (para Stapel e Dockerfile). A nova arquitetura de armazenamento abre a possibilidade de implementação de assemblies distribuídos de vários hosts e assemblies paralelos no mesmo host.
A otimização do trabalho inclui eliminar cálculos desnecessários na fase de cálculo de assinaturas de estágio e alterar os mecanismos de cálculo de somas de verificação de arquivos para outros mais eficientes. Essa otimização reduz o tempo médio de construção de projetos usando werf. E compilações inativas, quando todos os estágios existem no cache armazenamento de estágios, agora são muito rápidos. Na maioria dos casos, reiniciar a compilação levará menos de 1 segundo! Isto também se aplica aos procedimentos de verificação das etapas do processo de trabalho das equipes. werf deploy и werf run.
Também neste lançamento apareceu uma estratégia de marcação de imagens por conteúdo - marcação baseada em conteúdo, que agora está habilitado por padrão e é o único recomendado.
Vamos dar uma olhada mais de perto nas principais inovações do werf v1.1 e, ao mesmo tempo, falar sobre os planos para o futuro.
O que mudou no werf v1.1?
Novo formato de nomenclatura de estágios e algoritmo para seleção de estágios do cache
Nova regra de geração de nome artístico. Agora, cada construção de estágio gera um nome de estágio exclusivo, que consiste em 2 partes: uma assinatura (como era na v1.0) mais um identificador temporário exclusivo.
Por exemplo, o nome completo da imagem do cenário pode ser assim:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...ou em geral:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Aqui:
-
SIGNATUREé uma assinatura de 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é um identificador de imagem exclusivo garantido que é gerado no momento em que uma nova imagem é construída.
O algoritmo para selecionar estágios do cache é baseado na verificação do relacionamento dos commits do Git:
- Werf calcula a assinatura de um determinado estágio.
- В armazenamento de estágios Pode haver vários estágios para uma determinada assinatura. Werf seleciona todos os estágios que correspondem à assinatura.
- Se o estágio atual estiver vinculado ao Git (git-archive, estágio personalizado com patches do Git:
install,beforeSetup,setup; ou git-latest-patch), então o werf seleciona apenas os estágios associados a um commit que é um ancestral do commit atual (para o qual o build é chamado). - Dos demais estágios adequados, 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á que o cache associado a diferentes ramificações seja usado entre essas ramificações, mesmo que as assinaturas correspondam.
.
Novo algoritmo para criar e salvar estágios no armazenamento de estágios
Se, ao selecionar estágios do cache, o werf não encontrar um estágio adequado, então é iniciado o processo de montagem de um novo estágio.
Observe que vários processos (em um ou mais hosts) podem começar a construir o mesmo estágio aproximadamente ao mesmo tempo. Werf usa um algoritmo de bloqueio otimista armazenamento de estágios no momento de salvar a imagem recém-coletada em armazenamento de estágios. Dessa forma, quando a construção do novo estágio estiver pronta, o werf bloqueará armazenamento de estágios e salva lá uma imagem recém-coletada somente se uma imagem adequada não existir mais lá (por assinatura e outros parâmetros - veja o novo algoritmo para selecionar estágios do cache).
É garantido que uma imagem recém-montada tenha um identificador exclusivo por TIMESTAMP_MILLISEC (veja o novo formato de nomenclatura de palco). Caso em armazenamento de estágios uma imagem adequada será encontrada, o werf descartará a imagem recém-compilada e usará a imagem do cache.
Ou seja: o primeiro processo a finalizar a construção da imagem (o mais rápido) terá o direito de armazená-la em stage-storage (e então é essa única imagem que será utilizada para todas as construções). Um processo de construção lento nunca impedirá que um processo mais rápido salve os resultados da construção do estágio atual e passe para a próxima construção.
.
Melhor desempenho do construtor Dockerfile
No momento, o pipeline de estágios para uma imagem construída a partir de um Dockerfile consiste em um estágio - dockerfile. Ao calcular a assinatura, a soma de verificação dos arquivos é calculada context, que será usado durante a montagem. Antes dessa melhoria, o werf percorreu recursivamente todos os arquivos e obteve uma soma de verificação somando o contexto e o modo de cada arquivo. A partir da v1.1, o werf pode usar somas de verificação calculadas armazenadas em um repositório Git.
O algoritmo é baseado em . O algoritmo leva em conta registros em .dockerignore e percorre a árvore de arquivos recursivamente somente quando necessário. Assim, nos desvinculamos da leitura do sistema de arquivos e da dependência do algoritmo do tamanho context não é significativo.
O algoritmo também verifica os arquivos não rastreados e, se necessário, os leva em consideração na soma de verificação.
Melhor desempenho ao importar arquivos
Versões do werf v1.1 usam um servidor rsync quando . Anteriormente, a importação era feita em duas etapas usando uma montagem de diretório do sistema host.
O desempenho de importação no macOS não é mais limitado pelos volumes do Docker e as importações são concluídas no mesmo tempo que no Linux e no Windows.
Marcação baseada em conteúdo
Werf v1.1 suporta a chamada marcação por conteúdo de imagem - marcação baseada em conteúdo. As tags das imagens Docker resultantes dependem do conteúdo dessas imagens.
Ao executar o comando werf publish --tags-by-stages-signature ou werf ci-env --tagging-strategy=stages-signature publicou imagens do chamado assinatura de palco imagem. Cada imagem é marcada com sua própria assinatura das etapas desta imagem, que é calculada de acordo com as mesmas regras da assinatura regular de cada etapa separadamente, mas é um identificador geral da imagem.
A assinatura dos estágios da imagem depende de:
- o conteúdo desta imagem;
- histórias das mudanças no Git que levaram a este conteúdo.
Um repositório Git sempre possui commits fictícios que não alteram o conteúdo dos arquivos de imagem. Por exemplo, commits apenas com comentários ou commits de mesclagem, ou commits que alteram os arquivos no Git que não serão importados para a imagem.
Ao usar a marcação baseada em conteúdo, os problemas de reinicializações desnecessárias de pods de aplicativos no Kubernetes devido a alterações no nome da imagem são resolvidos, mesmo que o conteúdo da imagem não tenha sido alterado. Aliás, esse é um dos motivos que impede o armazenamento de muitos microsserviços de uma aplicação 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 em ramificações Git, porque o conteúdo das imagens resultantes não depende da ordem em que os pipelines são executados no sistema de CI para montar vários commits da mesma ramificação.
É importante: a partir de agora assinatura de estágios - É a única estratégia de marcação recomendada. Ele será usado por padrão no comando werf ci-env (a menos que você especifique explicitamente um esquema de marcação diferente).
. Uma publicação separada também será dedicada a esse recurso. ATUALIZADA (3 de abril): Artigo com detalhes .
Níveis de registro
O usuário agora tem a oportunidade de controlar a saída, definir o nível de registro 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 as informações mínimas:
Ao usar saída detalhada (--log-verbose) você pode ver como o werf funciona:
Saída detalhada (--log-debug), além das informações de depuração do werf, também contém logs de bibliotecas usadas. Por exemplo, você pode ver como ocorre a interação com o Docker Registry e também registrar os locais onde uma quantidade significativa de tempo é gasta:
Mais planos
Atenção! As opções descritas abaixo estão marcadas v1.1 estarão disponíveis nesta versão, muitos deles em um futuro próximo. As atualizações virão por meio de atualizações automáticas . Esses recursos não afetam a parte estável das funções da versão 1.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 (NOVO)
- Versão: v1.1
- Datas: março
O objetivo é que o usuário utilize uma implementação customizada sem restrições ao usar o werf.
Atualmente identificamos o seguinte conjunto de soluções para as quais vamos garantir total suporte:
- Padrão (biblioteca/registro)*,
- ECR da AWS
- Azul*,
- DockerHub
- GCR*,
- Pacotes GitHub
- Registro GitLab*,
- Porto*,
- Cais.
As soluções que atualmente são totalmente suportadas pelo werf estão marcadas com um asterisco. Para outros há apoio, mas com limitações.
Dois problemas principais podem ser identificados:
- Algumas soluções não suportam a remoção de tags usando a API Docker Registry, impedindo que os usuários usem a limpeza automática do werf. Isso se aplica aos pacotes AWS ECR, Docker Hub e GitHub.
- Algumas soluções não suportam os chamados repositórios aninhados (Docker Hub, GitHub Packages e Quay) ou suportam, mas o usuário deve criá-los manualmente usando a UI ou API (AWS ECR).
Vamos resolver esses e outros problemas utilizando APIs nativas das soluções. Esta tarefa também inclui cobrir todo o ciclo de operação do werf com testes para cada um deles.
Construção de imagem distribuída (↑)
- Versão: v1.2 v1.1 (a prioridade para implementação deste recurso foi aumentada)
- Datas: março-abril março
No momento, o werf v1.0 e v1.1 pode ser usado apenas em um host dedicado para operações de construção e publicação de imagens e implantação do aplicativo no Kubernetes.
Para abrir as possibilidades de trabalho distribuído do werf, quando a construção e implantação de aplicativos no Kubernetes são iniciadas em vários hosts arbitrários e esses hosts não salvam seu estado entre compilações (executores temporários), o werf é necessário para implementar a capacidade de usar o Docker Registry como um armazenamento de palco.
Anteriormente, quando o projeto werf ainda se chamava dapp, ele tinha essa oportunidade. No entanto, encontramos vários problemas que precisam ser levados em consideração ao implementar esta funcionalidade no werf.
Nota. Esse recurso não exige que o coletor funcione dentro dos pods do Kubernetes, porque Para fazer isso, você precisa se livrar da dependência do servidor Docker local (no pod Kubernetes não há acesso ao servidor Docker local, porque o processo em si está sendo executado em um contêiner, e o werf não suporta e não irá suportar trabalhando com o servidor Docker pela rede). O suporte para execução do Kubernetes será implementado separadamente.
Suporte oficial para GitHub Actions (NOVO)
- Versão: v1.1
- Datas: março
Inclui documentação werf (seções referência и 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 de interação do usuário com o sistema de CI será baseada na colocação de rótulos em solicitações pull para iniciar determinadas ações para construir/implementar a aplicação.
Desenvolvimento local e implantação de aplicações com werf (↓)
- Versão: v1.1
- Datas: janeiro a fevereiro de abril
O principal objetivo é alcançar uma configuração única e unificada para implantação de aplicativos tanto localmente quanto em produção, sem ações complexas e prontas para uso.
O werf também precisa ter um modo operacional no qual seja conveniente editar o código do aplicativo e receber instantaneamente feedback do aplicativo em execução para depuração.
Novo algoritmo de limpeza (NOVO)
- Versão: v1.1
- Datas: abril
Na versão atual do werf v1.1 no procedimento cleanup Não há previsão de limpeza de imagens para o esquema de marcação com base em conteúdo – essas imagens serão acumuladas.
Além disso, a versão atual do werf (v1.0 e v1.1) usa diferentes políticas de limpeza para imagens publicadas sob esquemas de marcação: Git branch, Git tag ou Git commit.
Um novo algoritmo para limpeza de imagens baseado no histórico de commits no Git, unificado para todos os esquemas de marcação, foi inventado:
- Mantenha no máximo imagens N1 associadas aos commits mais recentes do N2 para cada git HEAD (ramificações e tags).
- Armazene no máximo imagens de estágio N1 associadas aos commits mais recentes N2 para cada git HEAD (ramificações e tags).
- Armazene todas as imagens usadas em qualquer recurso de cluster Kubernetes (todos os contextos kube do arquivo de configuração e namespaces são verificados; você pode limitar esse comportamento com opções especiais).
- Armazene todas as imagens usadas em manifestos de configuração de recursos salvos em versões do Helm.
- Uma imagem pode ser excluída se não estiver associada a nenhum HEAD do git (por exemplo, porque o próprio HEAD correspondente foi excluído) e não for usada em nenhum manifesto no cluster Kubernetes e nas versões do Helm.
Construção de imagem paralela (↓)
- Versão: v1.1
- Datas: janeiro a fevereiro, abril*
A versão atual do werf coleta as imagens e artefatos descritos em werf.yaml, sequencialmente. É necessário paralelizar o processo de montagem de etapas independentes de imagens e artefatos, bem como fornecer resultados convenientes e informativos.
* Observação: o prazo foi alterado devido ao aumento da prioridade para implementação de montagem distribuída, que adicionará mais recursos de escalonamento horizontal, bem como o uso de werf com GitHub Actions. A montagem paralela é a próxima etapa de otimização, proporcionando escalabilidade vertical ao montar um projeto.
Transição para o Leme 3 (↓)
- Versão: v1.2
- Datas: Fevereiro-Março Maio*
Inclui migração para nova base de código e uma maneira comprovada e conveniente de migrar instalações existentes.
* Observação: mudar para o Helm 3 não adicionará recursos significativos ao werf, porque todos os recursos principais do Helm 3 (mesclagem de 3 vias e sem leme) já estão implementados no werf. Além disso, werf tem além dos indicados. No entanto, esta transição permanece nos nossos planos e será implementada.
Jsonnet para descrever a configuração do Kubernetes (↓)
- Versão: v1.2
- Datas: janeiro a fevereiro, abril a maio
Werf oferecerá suporte a descrições de configuração para Kubernetes no formato Jsonnet. Ao mesmo tempo, o werf permanecerá compatível com o Helm e haverá uma escolha de formato de descrição.
A razão é que os modelos Go, segundo muitas pessoas, têm uma grande barreira de entrada, e a compreensão do código desses modelos também é prejudicada.
A possibilidade de introduzir outros sistemas de descrição de configuração do Kubernetes (por exemplo, Kustomize) também está sendo considerada.
Trabalhando dentro do Kubernetes (↓)
- Versão: v1.2
- Datas: abril-maio maio-junho
Objetivo: garantir que as imagens sejam construídas e que o aplicativo seja entregue usando executores no Kubernetes. Aqueles. Novas imagens podem ser criadas, publicadas, limpas e implantadas diretamente dos pods do Kubernetes.
Para implementar esse recurso, primeiro você precisa ser capaz de construir imagens distribuídas (ver ponto acima).
Também requer suporte para o modo operacional do construtor sem um servidor Docker (ou seja, construção semelhante a Kaniko ou construção no espaço do usuário).
Werf apoiará a construção em Kubernetes não apenas com Dockerfile, mas também com seu construtor Stapel com reconstruções incrementais e Ansible.
Um passo em direção ao desenvolvimento aberto
Amamos nossa comunidade (, ) e queremos que mais e mais pessoas ajudem a melhorar o werf, entendam a direção que estamos tomando e participem do desenvolvimento.
Muito recentemente, foi decidido mudar para a fim de revelar o processo de trabalho da nossa equipe. Agora você pode ver os planos imediatos, bem como o trabalho atual nas seguintes áreas:
- ;
- ;
- ;
- .
Muito trabalho foi feito com questões:
- Removido os irrelevantes.
- Os existentes são reunidos em um formato único, com número suficiente de detalhes e detalhes.
- Novas edições com ideias e sugestões foram adicionadas.
Como habilitar a versão v1.1
A versão está atualmente disponível em (em canais estável и Rocha sólida liberações aparecerão conforme ocorre a estabilização, no entanto ea em si já é estável o suficiente para uso, porque passou pelos canais alfa и beta). ativado Da seguinte maneira:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusão
A nova arquitetura de armazenamento de estágio e otimizações de construtor para construtores Stapel e Dockerfile abrem a possibilidade de implementação de compilações 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 ).
Nesta versão, foi adicionada uma estratégia de marcação baseada em conteúdo de imagem - marcação baseada em conteúdo, que se tornou a estratégia padrão. O log de comando principal também foi reformulado: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
A próxima etapa significativa é adicionar assemblies distribuídos. As compilações distribuídas tornaram-se uma prioridade mais alta do que as compilações paralelas desde a v1.0 porque agregam mais valor ao werf: escala vertical de construtores e suporte para construtores efêmeros em vários sistemas CI/CD, bem como a capacidade de fazer suporte oficial para GitHub Actions . Portanto, os prazos de implementação das assembleias paralelas foram alterados. No entanto, estamos trabalhando para implementar ambas as possibilidades o mais rápido possível.
Acompanhe as novidades! E não se esqueça de nos visitar em para criar um problema, encontrar um existente e adicionar um plus, criar um PR ou simplesmente observar o desenvolvimento do projeto.
PS
Leia também em nosso blog:
- «»
- «";
- Uma série de notas sobre inovações no werf:
- «";
- «";
- «";
- «".
Fonte: habr.com