— nossa ferramenta CLI GitOps de código aberto para construir e entregar aplicativos no Kubernetes. Como prometido, marcou o início da adição de novas funcionalidades ao werf e a revisão de abordagens tradicionais. Agora estamos felizes em apresentar o lançamento v1.1, que é um grande passo no desenvolvimento e uma base para o futuro do construtor werf. A versão já está disponível no .
A base do lançamento é a nova arquitetura de armazenamento de estágios e a otimização do funcionamento de ambos os construtores (para Stapel e Dockerfile). A nova arquitetura de armazenamento abre oportunidades para a implementação de builds distribuídos em vários hosts e builds paralelos em um único host.
A otimização inclui a eliminação de cálculos desnecessários na fase de cálculo das assinaturas dos estágios e a mudança para mecanismos mais eficientes de cálculo de somas de verificação de arquivos. Essa otimização reduz o tempo médio de builds de projetos com o werf. E as builds nulas, quando todos os estágios estão em cache stages-storage, agora são realmente rápidas. Na maioria dos casos, reiniciar uma build levará menos de 1 segundo! Isso também se aplica aos procedimentos de verificação dos estágios durante o trabalho das equipes werf deploy e werf run.
Além disso, nesta versão, apareceu uma estratégia de etiquetagem de imagens baseada em conteúdo — content-based tagging, que agora está habilitada por padrão e é a única recomendada.
Vamos detalhar as principais inovações no werf v1.1 e aproveitamos para falar sobre os planos para o futuro.
O que mudou no werf v1.1?
Novo formato de nomeação de estágios e algoritmo de seleção de estágios do cache
Nova regra de geração de nome de estágio. Agora, cada build de estágio gera um nome de estágio único, que consiste em 2 partes: assinatura (como era na v1.0) mais um identificador de tempo único.
Por exemplo, o nome completo da imagem do estágio pode ser assim:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… ou de forma geral:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Aqui:
-
SIGNATURE— é a assinatura do estágio, que representa o identificador do conteúdo do estágio e depende do histórico de alterações no Git que levaram a esse conteúdo; -
TIMESTAMP_MILLISEC— é um identificador de imagem garantidamente único, que é gerado no momento da build de uma nova imagem.
O algoritmo de seleção de estágios do cache é baseado na verificação de relações entre commits do Git:
- O Werf calcula a assinatura de um determinado estágio.
- Em stages-storage podem existir vários estágios para uma mesma assinatura. O Werf escolhe todos os estágios adequados de acordo com a assinatura.
- Se o estágio atual estiver relacionado ao Git (git-archive, estágio personalizado com patches do Git:
install,beforeSetup,setup; ou git-latest-patch), o werf escolhe apenas os estágios que estão relacionados ao commit que é ancestral do commit atual (para o qual a construção foi chamada). - Dentre os estágios restantes adequados, um é escolhido — o mais antigo em data de criação.
Um estágio pode ter a mesma assinatura para diferentes branches do Git. Mas o werf impedirá o uso do cache relacionado a diferentes branches entre esses branches, mesmo que as assinaturas coincidam.
.
Novo algoritmo para criar e salvar estágios no repositório de estágios
Se durante a seleção de estágios do cache o werf não encontrar um estágio adequado, inicia-se o processo de construção de um novo estágio.
Observe que vários processos (em um ou vários hosts) podem começar a construir o mesmo estágio ao mesmo tempo. O Werf usa um algoritmo de bloqueio otimista stages-storage no momento de salvar a imagem recém-construída em stages-storage. Assim, quando a construção de um novo estágio estiver pronta, o werf bloqueia stages-storage e salva a imagem recém-construída lá apenas se já não existir uma imagem adequada (de acordo com a assinatura e outros parâmetros — veja o novo algoritmo de seleção de estágios do cache).
A imagem recém-construída terá, garantidamente, um identificador único de acordo com TIMESTAMP_MILLISEC (veja o novo formato de nomeação de estágios). No caso de encontrar uma imagem adequada em stages-storage , o werf descartará a imagem recém-construída e usará a imagem do cache.
Em outras palavras: o primeiro processo que terminar de construir a imagem (o mais rápido) terá o direito de salvá-la no stages-storage (e, em seguida, apenas essa única imagem será usada para todas as construções). O processo de construção mais lento nunca bloqueará um processo mais rápido de salvar os resultados da construção do estágio atual e passar para a construção do próximo.
.
Desempenho do construtor Dockerfile melhorado
Atualmente, o pipeline de estágios para a imagem sendo construída a partir do Dockerfile consiste em um único estágio — dockerfile. Ao calcular a assinatura, a soma de verificação dos arquivos é considerada. contexto, que serão utilizados durante a construção. Até essa atualização, werf percorria recursivamente todos os arquivos e obtinha um hash de verificação, somando o contexto e o modo de cada arquivo. A partir das versões v1.1, werf pode usar os hashes de verificação calculados armazenados no repositório Git.
A base do algoritmo é . O algoritmo considera registros em .dockerignore e percorre recursivamente a árvore de arquivos apenas quando necessário. Assim, nos desvinculamos da leitura do sistema de arquivos, e a dependência do algoritmo em relação ao tamanho contexto não é significativa.
O algoritmo também verifica arquivos não rastreados e, quando necessário, os considera no hash de verificação.
O desempenho ao importar arquivos foi melhorado
Nas versões do werf v1.1, um servidor rsync é utilizado ao . Anteriormente, a importação era realizada em duas etapas usando a montagem de diretórios do sistema host.
O desempenho das importações no macOS não é mais limitado aos volumes do Docker, e as importações ocorrem no mesmo tempo que no Linux e Windows.
Tagueamento baseado em conteúdo
O werf v1.1 suporta o que é chamado de tagueamento baseado no conteúdo da imagem — content-based tagging. 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 as imagens publicadas serão marcadas com a chamada assinatura de estágios da imagem. Cada imagem é marcada com sua própria assinatura de estágio, que é calculada de acordo com as mesmas regras que a assinatura regular de cada estágio individualmente, mas é um identificador geral da imagem.
A assinatura dos estágios da imagem depende de:
- do conteúdo dessa imagem;
- do histórico de alterações no Git que levaram a esse conteúdo.
No repositório Git, sempre existem commits vazios que não alteram o conteúdo dos arquivos da imagem. Por exemplo, commits apenas com comentários, ou commits de merge, ou commits que alteram aqueles arquivos no Git que não serão importados para a imagem.
Ao usar o tagueamento baseado em conteúdo, resolvem-se problemas de reinicializações excessivas de pods da aplicação no Kubernetes devido a alterações no nome da imagem, mesmo que o conteúdo da imagem não tenha mudado. A propósito, essa é uma das razões que dificultam o armazenamento de múltiplos microserviços de uma única aplicação em um único repositório Git.
Além disso, a marcação baseada em conteúdo é um método de tagueamento mais confiável do que o tagueamento por ramificações do Git, pois o conteúdo das imagens resultantes não depende da ordem de execução dos pipelines no sistema CI para construir vários commits da mesma ramificação.
Importante: a partir deste momento assinatura-dos-estágios seja a única estratégia de tagueamento recomendada. Esta será a utilizada por padrão na equipe werf ci-env (a menos que uma outra estratégia de tagueamento seja explicitamente especificada).
. Esta funcionalidade também será dedicada a uma publicação separada. ATUALIZADO (3 de abril): artigo com detalhes .
Níveis de logging
O usuário agora tem a capacidade de controlar a saída, definir o nível de logging e trabalhar com informações de depuração. As opções foram adicionadas --log-quiet, --log-verbose, --log-debug.
Por padrão, a saída contém o mínimo de informações:
Ao utilizar a saída detalhada (--log-verbose) é possível acompanhar como o werf funciona:
A saída detalhada (--log-debug), além das informações de depuração do werf, também contém logs das bibliotecas utilizadas. Por exemplo, é possível ver como a interação com o Docker Registry ocorre, além de registrar pontos onde um tempo considerável é gasto:
Planos Futuros
Atenção! As funcionalidades descritas a seguir com a marcação v1.1 estarão disponíveis nesta versão, muitas delas em breve. As atualizações virão através de atualizações automáticas . Essas funcionalidades não afetam a parte estável das funções v1.1, sua introdução não exigirá intervenção manual do usuário nas configurações existentes.
Suporte total a várias implementações do Docker Registry (NOVO)
- Versão: v1.1
- Prazo: março
O objetivo é que o usuário utilize qualquer implementação sem restrições ao usar o werf.
Atualmente, destacamos o seguinte conjunto de soluções para as quais garantimos suporte total:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
As soluções marcadas com um asterisco são aquelas atualmente totalmente suportadas pelo werf. Para as demais, há suporte, mas com limitações.
Podemos destacar dois problemas principais:
- Algumas soluções não suportam a remoção de tags através da API do Docker Registry, o que impede os usuários de utilizar a limpeza automática implementada no werf. Isso é verdade para AWS ECR, Docker Hub e GitHub Packages.
- Parte das 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 interface ou a API (AWS ECR).
Estamos planejando resolver esses e outros problemas utilizando APIs nativas das soluções. Esta tarefa também inclui a cobertura de testes do ciclo completo de funcionamento do werf para cada uma delas.
Compilação distribuída de imagens (↑)
- Versão: v1.2 v1.1 (a prioridade para a implementação dessa funcionalidade foi aumentada)
- Prazos: março-abril março
Atualmente, o werf v1.0 e v1.1 só podem ser usados em um único host dedicado para operações de compilação e publicação de imagens e implantação de aplicações no Kubernetes.
Para abrir as possibilidades de trabalho distribuído do werf, quando a compilação e implantação de aplicações no Kubernetes são iniciadas em vários hosts arbitrários e esses hosts não mantêm seu estado entre as compilações (runners temporários), o werf precisa implementar a capacidade de usar o Docker Registry como repositório de estágios.
Anteriormente, quando o projeto werf ainda se chamava dapp, havia essa possibilidade. No entanto, enfrentamos uma série de problemas que precisam ser considerados na implementação dessa função no werf.
Nota. Essa possibilidade não pressupõe o funcionamento do compilador dentro de pods do Kubernetes, pois para isso é necessário se livrar da dependência do servidor Docker local (no pod do Kubernetes não há acesso ao servidor Docker local, pois o próprio processo é executado dentro de um contêiner, e a comunicação com o servidor Docker pela rede não é suportada e não será suportada pelo werf). O suporte para funcionamento no Kubernetes será implementado separadamente.
Suporte oficial ao GitHub Actions (NOVO)
- Versão: v1.1
- Prazo: março
Inclui a documentação do werf (seções referência e guia), bem como a ação oficial do GitHub para trabalhar com o werf.
Além disso, permitirá que o werf funcione em runners efêmeros.
A mecânica de interação do usuário com o sistema CI será baseada na atribuição de labels a pull requests para iniciar determinadas ações de compilação/desdobramento da aplicação.
Desenvolvimento local e implantação de aplicações com werf (↓)
- Versão: v1.1
- Prazos: janeiro-fevereiro abril
O principal objetivo é alcançar uma configuração unificada para a implantação de aplicações tanto localmente quanto em produção, sem ações complexas, "pronto para uso".
A werf também requer um modo de operação que permita editar o código do aplicativo e receber feedback imediato do aplicativo em execução para depuração.
Novo algoritmo de limpeza (NOVO)
- Versão: v1.1
- Prazos: abril
Na versão atual do werf v1.1, o procedimento cleanup não contempla a limpeza de imagens para o esquema de tagueamento baseado em conteúdo — essas imagens serão acumuladas.
Além disso, na versão atual do werf (v1.0 e v1.1), são utilizadas políticas de limpeza diferentes para imagens publicadas de acordo com esquemas de tagueamento: branch do Git, tag do Git ou commit do Git.
Um novo algoritmo de limpeza unificado para todos os esquemas de tagueamento foi concebido com base no histórico de commits no Git:
- Manter não mais do que N1 imagens, relacionadas aos N2 últimos commits para cada HEAD do git (branches e tags).
- Manter não mais do que N1 imagens de estágios, relacionadas aos N2 últimos commits para cada HEAD do git (branches e tags).
- Manter todas as imagens que são utilizadas em quaisquer recursos do cluster Kubernetes (todos os kube-contexts do arquivo de configuração e namespaces são analisados; esse comportamento pode ser restringido por opções especiais).
- Manter todas as imagens que são utilizadas em manifests de configuração de recursos, salvos em releases do Helm.
- Uma imagem pode ser removida se não estiver associada a nenhum HEAD do git (por exemplo, porque o HEAD correspondente foi excluído) e não estiver em uso em nenhum dos manifests no cluster Kubernetes e nas releases do Helm.
Construção paralela de imagens (↓)
- Versão: v1.1
- Prazos: janeiro-fevereiro abril*
A versão atual do werf constrói imagens e artefatos descritos em werf.yaml, sequencialmente. É necessário paralelizar o processo de construção de estágios independentes de imagens e artefatos, além de garantir uma saída conveniente e informativa.
* Observação: o prazo foi adiado devido à priorização da implementação de uma construção distribuída, que adicionará mais capacidades de escalabilidade horizontal, além do uso do werf com o GitHub Actions. A construção paralela é o próximo passo de otimização, proporcionando escalabilidade vertical na construção de um único projeto.
Transição para o Helm 3 (↓)
- Versão: v1.2
- Prazos: fevereiro-março maio*
Inclui a transição para uma nova base de código e um método comprovado e conveniente para migração de instalações existentes.
* Nota: a transição para o Helm 3 não adicionará capacidades significativas ao werf, pois todos os recursos principais do Helm 3 (3-way-merge e ausência de tiller) já estão implementados no werf. Além disso, o werf possui além das mencionadas. No entanto, essa transição permanece em nossos planos e será executada.
Jsonnet para descrever a configuração do Kubernetes (↓)
- Versão: v1.2
- Prazos: janeiro-fevereiro abril-maio
O werf suportará a descrição da configuração para Kubernetes no formato Jsonnet. Neste caso, o werf permanecerá compatível com o Helm e haverá a possibilidade de escolher o formato de descrição.
A razão é que os templates da linguagem Go, segundo a avaliação de muitas pessoas, têm uma alta barreira de entrada, e a clareza do código desses templates também é comprometida.
Também está sendo considerada a implementação de outros sistemas de descrição de configuração do Kubernetes (por exemplo, Kustomize).
Trabalho dentro do Kubernetes (↓)
- Versão: v1.2
- Prazos: abril-maio maio-junho
Objetivo: garantir a construção de imagens e a entrega de aplicativos usando runners no Kubernetes. Ou seja, a construção de novas imagens, sua publicação, limpeza e deploy pode ocorrer diretamente de pods do Kubernetes.
Para implementar essa possibilidade, primeiro é necessária a capacidade de construção distribuída de imagens (veja o item acima).
Além disso, é necessário suporte ao modo de funcionamento do construtor sem servidor Docker (ou seja, construção semelhante ao Kaniko ou construção em userspace).
O werf suportará a construção no Kubernetes não apenas com Dockerfile, mas também com seu construtor Stapel com reconstruções incrementais e Ansible.
Passo em direção ao desenvolvimento aberto
Amamos nossa comunidade (, ) e queremos que cada vez mais pessoas ajudem a tornar o werf melhor, entendam para onde estamos indo e participem do desenvolvimento.
Recentemente, foi decidido adotar para abrir um pouco o fluxo de trabalho da nossa equipe. Agora é possível ver os planos mais próximos, bem como o trabalho atual nas seguintes áreas:
- ;
- ;
- ;
- .
Foi feito um grande trabalho com issues:
- Removidos os que não eram mais relevantes.
- Os existentes foram padronizados, com detalhes e informações suficientes.
- Adicionadas novas issues com ideias e sugestões.
Como habilitar a versão v1.1
A versão está disponível no momento em (nos canais stable e rock-solid as versões aparecerão à medida que se estabilizarem, no entanto, ea já é bastante estável para uso, pois passou pelos canais alpha e beta). Ativada da seguinte maneira:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusão
A nova arquitetura de armazenamento de estágios e a otimização do funcionamento do construtor para os construtores Stapel e Dockerfile abrem possibilidades para implementar compilações distribuídas e em paralelo no werf. Essas capacidades estarão disponíveis em breve na mesma versão v1.1 e serão automaticamente acessíveis através do mecanismo de autoatualizações (para os usuários ).
Nesta versão, foi adicionada uma estratégia de tagueamento com base no conteúdo das imagens — content-based tagging, — que se tornou a estratégia padrão. Além disso, o log de comandos principais foi reestruturado: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
O próximo passo significativo será a adição de compilações distribuídas. Compilações distribuídas desde a versão v1.0 tornaram-se uma tarefa mais prioritária do que compilações em paralelo, pois agregam mais valor ao werf: escalabilidade vertical dos construtores e suporte a construtores efêmeros em diferentes sistemas CI/CD, além da possibilidade de proporcionar suporte oficial ao GitHub Actions. Portanto, os prazos para a implementação de compilações em paralelo foram adiados. No entanto, estamos trabalhando para implementar ambas as possibilidades o mais rápido possível.
Fique ligado nas novidades! E não se esqueça de nos visitar em , para criar uma issue, encontrar uma já existente e dar um like, criar um PR ou apenas observar o desenvolvimento do projeto.
P.S.
Confira também em nosso blog:
- «»
- «»;
- Ciclo de notas sobre novidades no werf:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
