O werf é um utilitário GitOps CLI de
código aberto para criar e entregar aplicativos ao Kubernetes. O werf suporta a montagem de imagens de aplicativos usando o Dockerfile ou seu próprio coletor interno (baseado na sintaxe YAML, com suporte Ansible e reconstrução incremental baseada no Git). O formato de configuração compatível com o leme é usado para entregar o aplicativo. O código do aplicativo, a configuração das imagens coletadas e a configuração de distribuição do aplicativo são armazenados em um repositório Git.
A tão esperada
versão estável 1.0 é a versão básica do utilitário concluída por funções
(o número exato da versão da primeira versão estável é 1.0.6) . Na versão básica, o werf suporta todo o ciclo de entrega e manutenção de aplicativos. Isso inclui a montagem de imagens de aplicativos, a implantação no Kubernetes e a limpeza de imagens não utilizadas.
É importante que na versão 1.0, todas as operações em um projeto (
build ,
deploy ,
cleanup ) sejam executadas em um host. Isso significa que um trabalhador fixo deve ser usado no sistema de IC. Ao mesmo tempo, não há restrições ao paralelismo de tarefas: o werf resolve completamente esse problema. Você também pode distribuir diferentes projetos entre diferentes trabalhadores.
Neste artigo dedicado ao lançamento, examinaremos mais de perto o que esta versão fornece e não fornece, além de nossos planos para versões futuras. Mas começaremos entendendo o entendimento do termo “GitOps” e o papel do werf nos processos de integração contínua e entrega de aplicativos (CI / CD).
Por que werf é GitOps
Então, o que queremos dizer com GitOps e quais áreas o werf cobre?
O termo “GitOps” foi cunhado pelo Weaveworks há cerca de 2,5 anos, e recentemente
traduzimos um artigo de seus autores que revela a essência desse novo fenômeno para o blog. Em nosso entendimento, a principal idéia e o principal significado do GitOps é que o
Git é uma "única fonte de verdade" . Lojas Git:
- código da aplicação
- todas as dependências;
- informações sobre como coletar contêineres;
- informações sobre como implantar no Kubernetes;
- e outros
E depois há "algo" que faz a
realidade mudar de acordo com as mudanças do Git . Essa abordagem pode ser implementada não apenas instalando algum operador no Kubernetes que monitora o Git, mas também usando um utilitário de console que pode ser chamado de qualquer sistema de IC. Além disso, do nosso ponto de vista, a abordagem com o utilitário CLI não impõe restrições desnecessárias: podemos fazer IC com qualquer ferramenta e com inúmeras nuances, chamando um utilitário CLI que sincroniza a “realidade” (Kubernetes) com o estado do Git .
O werf fornece uma interface CLI de alto nível com comandos básicos para criar e publicar imagens, fornecendo aplicativos e limpando imagens: o
werf build-and-publish , o
werf deploy , o
werf dismiss , o
werf cleanup . Supõe-se que esses comandos muito básicos sejam incorporados em um sistema de IC específico e forneçam a sincronização necessária com a realidade. Além disso, o werf também fornece uma interface CLI de baixo nível para gerenciar vários subsistemas - consulte os
comandos de gerenciamento de baixo nível na documentação.
Não importa se o CI / CD interno funcionará de acordo com o modelo push ou pull
(leia mais sobre eles aqui ) , porque o
werf pode ser incorporado em qualquer modelo . Ao mesmo tempo, o werf fecha problemas como trabalhar com utilitários separados de baixo nível, como api-server
git ,
docker e kubernetes, sendo a “parte que falta” para configurar um aplicativo CI / CD unificado.
O que é werf 1.0 estável
1. Montagem, publicação e limpeza de imagens
Se seu aplicativo exigir a construção de imagens do Docker, usando o werf 1.0, você poderá:
- descreva as regras para montar imagens (você pode ter várias) em uma única configuração
werf.yaml ; - Colete imagens e publique no Docker Registry
- limpe periodicamente o Docker Registry para obter políticas personalizadas.
O werf suporta
duas maneiras de descrever a montagem : conectar o
werf.yaml Dockerfiles existentes e instruções para
o coletor Stapel . Construir com a Stapel tem suas vantagens: reconstrução incremental mais rápida ao alterar o código do aplicativo no Git, usando a sintaxe Ansible para montagem e outras. Você pode
aprender mais sobre esse coletor e sintaxe
na documentação , e um exemplo de seu uso é apresentado no
manual .
Esquemas diferentes para marcação / controle de versão de imagens coletadas estão disponíveis com referência a confirmações, ramificações e tags do Git.
A montagem de imagens é um estágio opcional da implantação do aplicativo e pode ser ignorada na ausência de suas próprias imagens montadas.
2. Estágio de armazenamento em apenas um host
O werf introduz o conceito de armazenamento de estágios. Os principais comandos werf usam o armazenamento em estágio da seguinte maneira:
- Salvar resultados da montagem - imagens do Docker no armazenamento de palco
- use imagens do armazenamento de palco como um cache para reconstruir e montar novas imagens;
- use o repositório para obter informações sobre as imagens coletadas para uso posterior (por exemplo, ao entregar um aplicativo ao Kubernetes).
Ao implantar um único aplicativo, um armazenamento de estágio único deve ser usado para todas as equipes (montagem, publicação, limpeza de imagens, implantação de aplicativos).
Na versão 1.0, apenas o armazenamento do host local pode atuar como um armazenamento de estágio (o parâmetro correspondente para os comandos é:
--stages-storage=:local ). Ao usar
:local estágios
:local são armazenados no disco. A conseqüência disso:
werf 1.0 pode ser usada apenas
em um host para organizar a implantação de um
único aplicativo . Esse host deve salvar os dados entre as ativações do comando para que o werf funcione corretamente.
Na versão 1.0, não há suporte para armazenar estágios no armazenamento externo, com o qual você pode organizar um assembly distribuído. No entanto, essa função aparecerá em versões futuras do werf
(veja abaixo para mais detalhes) .
3. Abra o aplicativo e verifique a disponibilidade
Para implementar o aplicativo, o usuário descreve o gráfico em um formato compatível com o Helm: um conjunto de manifestos e parâmetros de modelo do Kubernetes.
O werf lança o aplicativo no Kubernetes e fornece uma garantia de que ele inicia e funciona antes de concluir o processo de lançamento do aplicativo. Isso inclui a saída dos logs de componentes e a resposta instantânea a erros de lançamento quando algo deu errado - o comando de lançamento será descartado com um código diferente de zero. Assim, ao usar o lançamento do werf no CI / CD,
obtemos feedback adequado do software : se o aplicativo foi baixado ou não, e informações suficientes para depurar e corrigir problemas (sem a necessidade de executar outros utilitários para encontrar problemas como o
kubectl ).
O werf é totalmente compatível com as instalações existentes do Helm 2, mas o werf tem várias vantagens sobre ele. Por exemplo, como um mecanismo para atualizar recursos, o Kubernetes usa patches de
3 vias e também há a possibilidade de receber feedback quando o aplicativo é entregue ao cluster. Uma lista completa de diferenças é descrita
nesta página .
4. O relacionamento das imagens coletadas com o processo de entrega do aplicativo
O werf integra as imagens coletadas em um único sistema, o processo de identificação e controle de versão com o processo de entrega do aplicativo ao Kubernetes. As imagens que o werf coleta podem ser usadas nos modelos de descrição de recurso do Kubernetes.
É devido a essas funções que podemos dizer que o
werf fornece uma interface de nível superior ao Helm, Docker e outros construtores e utilitários para implantar separadamente. Essa interface permite que você simplesmente integre o werf em qualquer sistema de CI / CD existente e não resolva os problemas de combinar todos os componentes usados - ele cuida dessa tarefa.
5. Integração com sistemas CI / CD existentes
Na versão 1.0, a integração automática está disponível apenas
no sistema GitLab CI . Para fazer isso, o comando
werf ci-env é fornecido. Ele recebe as informações necessárias do sistema de CI / CD e configura automaticamente o werf para funcionar corretamente no ambiente de CI.
Você pode ler mais sobre como a integração com qualquer sistema de CI / CD funciona nos manuais (
revisão ,
especificações específicas do GitLab CI ,
integração com outros sistemas ).
6. Desenvolvimento de plataforma cruzada para Linux, Windows e macOS
O werf 1.0 é um arquivo binário vinculado estaticamente que funciona independentemente com as versões do Docker e do Helm. Dependências externas no sistema host:
- Daemon do Docker local
- utilitário git.
O werf pode ser executado em qualquer sistema operacional e ambiente de GNU / Linux, Windows ou macOS. Além disso, o resultado da montagem será o mesmo, independentemente do sistema utilizado: a mesma assinatura dos estágios de cache, o mesmo preenchimento dos estágios, independentemente do sistema em que esse estágio foi coletado. Alterações na configuração para trabalhar em sistemas diferentes também não são necessárias.
Portanto, o werf 1.0 fornece ferramentas de plataforma cruzada para criar e entregar aplicativos ao Kubernetes.
Também deve ser observado aqui que o werf coleta imagens padrão do Docker para trabalhar em um ambiente Linux, mas
os contêineres do Windows não
são suportados na versão 1.0.
7. Cobrindo a funcionalidade com testes
Atualmente, 60% do código werf é coberto por testes e2e de integração e testes de unidade.
O werf é testado em todos os sistemas operacionais suportados (Linux, Windows e macOS) usando as ações do GitHub para organizar seu lançamento. Alguns detalhes de teste também estão disponíveis no
Code Climate .
8. Versão do werf
No momento, no lançamento da versão 1.0,
cerca de 700 lançamentos foram feitos no projeto.
O werf usa um sistema avançado de lançamento com canais de estabilidade:
alfa ,
beta ,
ea (acesso antecipado) ,
estável e
sólido . Este post foi programado para coincidir com o lançamento da primeira versão 1.0 no canal
estável . Alterações instáveis na versão passam por uma cadeia de canais e acabam sendo
sólidas . Os lançamentos são frequentemente feitos (às vezes vários por dia) e as alterações são entregues continuamente em "pequenas porções".
Os canais de estabilidade e muitas versões frequentes permitem obter feedback contínuo sobre novas alterações, a capacidade de revertê-las rapidamente e geralmente garantir alta estabilidade do software e, ao mesmo tempo, uma velocidade aceitável de seu desenvolvimento.
O ponto importante é que, ao alternar entre as versões 1.0-> 1.1, 1.1-> 1.2, são possíveis alterações no werf que requerem intervenção manual do usuário (pode ser um script de migração ou apenas instruções para execução manual descritas no release). A atualização das versões dentro de 1.0 (1.0.1, 1.0.2, ... 1.0.6-alpha.1, 1.0.6-beta.2, etc.) garante que essas alterações manuais não sejam necessárias.
Você pode ler mais sobre a promessa de compatibilidade com versões anteriores
aqui .
Planos adicionais
Veja como são as principais áreas de trabalho principais para versões futuras e os termos aproximados para sua implementação:
1. Desenvolvimento local e implantação de aplicativos com werf
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.
Versão 1.1, janeiro a fevereiro de 20202. Marcação baseada em conteúdo
Etiquetar imagens quando publicadas, com base apenas no conteúdo desta imagem. Ao contrário dos modos com ligação às confirmações do Git, esse modo se livra completamente das reconstruções desnecessárias. Git-commit-id não é um identificador universal para o conteúdo da árvore de trabalho (embora dependa disso).
No caso em que o código do aplicativo não foi alterado, mas uma nova confirmação foi feita, o modo de marcação atual para confirmações do Git criará uma imagem com um novo nome quando ele for publicado. Isso também implicará uma reversão de recursos usando esta imagem no Kubernetes. Ao mesmo tempo, o conteúdo da imagem em si não mudou.
Para resolver esses problemas, o werf apresentará um novo tipo de marcação com base nos cálculos das somas de verificação do
conteúdo do aplicativo - marcação baseada em
conteúdo .
Versão 1.1, fevereiro a março de 20203. A transição para o leme 3
Inclui a transição para a nova base de código do
Helm 3 e uma maneira comprovada e conveniente de migrar as instalações existentes.
Versão 1.1, fevereiro a março de 20204. Montagem paralela de imagens
No momento, o werf 1.0 coleta todos os estágios de imagens e artefatos declarados em
werf.yaml sequencialmente. Requer a capacidade de paralelizar o processo de montagem do palco.
Versão: 1.1, janeiro-fevereiro de 20205. Montagem distribuída de imagens
No momento, o werf 1.0 pode ser usado apenas em um host dedicado
(consulte o ponto acima sobre o armazenamento do palco em apenas um host) .
Para abrir as possibilidades de montagem distribuída, quando a montagem é iniciada em vários hosts 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 também era chamado dapp, havia uma oportunidade. No entanto, encontramos vários problemas que devem ser considerados ao implementar esta função no werf.
Versão 1.2: março a abril de 20206. Jsonnet para descrever a configuração do Kubernetes
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 que os modelos de linguagem Go, de acordo com muitas pessoas, têm um grande limite de entrada, e a inteligibilidade do código desses modelos também sofre.
Outras opções para implementar os sistemas de descrição de configuração do Kubernetes (como o Kustomize) também estão sendo consideradas.
Versão 1.1: janeiro a fevereiro de 20207. Trabalhe dentro do Kubernetes
Objetivo: Garantir a montagem de imagens e a entrega de aplicativos usando corredores no Kubernetes. I.e. montagem de novas imagens, sua publicação, limpeza e implantação podem ocorrer diretamente dos pods do Kubernetes.
Para realizar esse recurso, você primeiro precisa distribuir imagens de maneira distribuída
(consulte o parágrafo acima) .
Ele também requer suporte para o modo de operação de compilação sem o daemon do Docker (ou seja, uma compilação semelhante ao Kaniko ou uma
compilação no espaço do usuário ).
O werf suportará compilações do Kubernetes não apenas com o Dockerfile, mas também com seu construtor Stapel com reconstruções incrementais.
Versão 1.2: abril a maio de 20208. Outros
Também está planejado:
- Atualização da versão Ansible e a capacidade de usar diferentes versões do Ansible;
- suporte para papéis ansíveis;
- suporte para estágios de montagem arbitrários no Stapel (atualmente o werf suporta um conjunto estático de estágios:
beforeInstall , install , beforeSetup , setup ); - sintaxe
werf.yaml aprimorada, alternando para configVersion: 2 (associado, entre outros, aos dois pontos anteriores), suporte para a especificação OpenAPI; - Suporte ao Git LFS no Stapel para armazenar arquivos grandes no Git;
- aprimoramento dos mecanismos de limpeza de imagens (falhas não críticas na versão atual estão associadas a imagens não declaradas na configuração
werf.yaml na ramificação principal principal - essas imagens serão excluídas pela limpeza periódica); - trabalho mais correto com o namespace Kubernetes compartilhado, quando vários aplicativos são implantados em um namespace;
- reversão automática do aplicativo para a versão de trabalho mais recente em caso de implantação malsucedida.
Total
Serei breve em resumir. Nós somos:
- longa caminhada até o advento da versão 1.0;
- levou em conta muita experiência real;
- Apresentamos para uso um utilitário comprovado com funcionalidade estável, verificado por dezenas de milhares de lançamentos.
O lançamento da versão 1.0 marca o início de uma nova fase de desenvolvimento do werf, na qual os novos recursos fundamentalmente serão adicionados. Acompanhe as novidades! E também participe
do werf_ru tg-channel , na vida em que participam os desenvolvedores diretos do werf, bem como nossos engenheiros e usuários do utilitário fora da empresa Flant.
PS
Leia também em nosso blog: