O artigo é dedicado ao desenvolvimento de gráficos Helm para o Kubernetes usando soluções prontas de repositórios de gráficos. Com essa abordagem, o usuário aplica receitas próprias ou da comunidade, garantindo a atualização oportuna dos componentes padrão de todos os seus projetos e a conveniência de manter soluções em geral.
Um recurso tão conveniente agora está embutido em nosso utilitário werf GitOps, que deve simplificar todo o processo de operação da infraestrutura para aplicativos montados e implementados no Kubernetes.
Elmo Integrado
Talvez o principal sucesso do Helm - o "gerenciador de pacotes do Kubernetes" - esteja associado não tanto à sua funcionalidade quanto ao
repositório oficial de
gráficos e suporte a repositórios em geral. As configurações de receitas e gráficos são acompanhadas por uma enorme comunidade. Os especialistas suportam soluções atualizadas exigidas pelos usuários finais. Cada gráfico do repositório oficial é padronizado e bem documentado.
Em casos triviais, o usuário nem precisa criar um gráfico para implementar o aplicativo: ele apenas encontra uma solução pronta, lê a documentação, prepara as configurações e usa o gráfico oficial.
Por muito tempo, usamos ativamente o Helm dentro do werf para implantar a infraestrutura de aplicativos e agora vamos mais longe. A partir da versão
v1.0.4-alpha.10 , os
comandos para trabalhar com dependências e repositórios de gráficos foram adicionados ao werf para abandonar completamente o cliente Helm.
Os principais comandos para isso:
werf helm repo
add Add a chart repository fetch Download a chart from a repository and (optionally) unpack it in local directory init Init default chart repositories configuration list List chart repositories remove Remove a chart repository search Search for a keyword in charts update Update information of available charts locally from chart repositories
werf helm dependency
build Rebuild the charts/ directory based on the requirements.lock file list List the dependencies update Update charts/ based on the contents of requirements.yaml
Além disso, o suporte à
referência de gráfico foi adicionado ao
werf helm deploy-chart .
E aqui está como toda essa mágica parece em ação - mais precisamente, aqui mostramos uma comparação da distribuição do mesmo gráfico em werf (à esquerda) e em Helm (à direita):
Mais prática
Voltando à conveniência de usar soluções prontas para implantar aplicativos inteiros - um
exemplo comum do WordPress . A apresentação do gráfico Helm no cluster Kubernetes usando werf pode ser assim:
$ cat << EOF > values.yaml wordpressBlogName: flant wordpressUsername: admin wordpressPassword: password mariadb: mariadbRootPassword: password EOF $ werf helm deploy-chart --values values.yaml stable/wordpress my-web-app
→
Demonstração em asciicinema .
Como os repositórios contêm
muitas soluções , você pode
criar seus próprios aplicativos como cubos, onde os cubos serão os vários gráficos Helm dos quais todo o sistema depende. Provavelmente, você só precisa configurar corretamente os componentes de acordo com suas necessidades.
Por exemplo, um aplicativo Web requer uma fila, cache e armazenamento de dados. Como implantamos esses componentes através do werf?
Para começar - vamos acelerar a pesquisa de tudo o que você precisa usando a CLI:
$ werf helm repo search queue NAME CHART VERSION APP VERSION DESCRIPTION stable/rabbitmq 6.4.1 3.7.17 Open source message broker software that implements the A... stable/rabbitmq-ha 1.31.0 3.7.15 Highly available RabbitMQ cluster, the open source messag...
Por analogia, encontraremos os componentes restantes para todos os repositórios de gráficos registrados (a lista de repositórios usados pode ser vista executando o
werf helm repo list ).
Depois que tudo é encontrado, resta apenas adicioná-los ao gráfico. Existem várias maneiras de fazer isso: adicione gráficos de componentes ao diretório de gráficos ou crie um arquivo
requirements.yaml e descreva as dependências e interaja com eles usando os
werf helm dependency build|list|update especiais
werf helm dependency build|list|updateIlustração do segundo caminho:
$ cat << EOF > .helm/requirements.yaml dependencies: - name: mysql version: 0.3.4 repository: "@stable" - name: redis version: 1.1.11 repository: "@stable" - name: rabbitmq version: 0.6.16 repository: "@stable" EOF $ werf helm dependency build $ werf deploy --env test
→
Demonstração em asciicinema .
Durante o processo de implementação, o werf
criará todas as dependências e as rastreará junto com o restante dos recursos - nenhuma ação adicional é necessária.
Como resultado, levando em consideração a experiência da comunidade experiente, você economiza significativamente tempo no desenvolvimento e manutenção de gráficos. No entanto, ninguém o restringe a usar gráficos públicos: você pode distribuí-los com o mesmo sucesso, cuja configuração é preparada levando em consideração as especificidades necessárias.
A documentação sobre comandos de repositório e dependência no werf é apresentada
aqui . Você também pode estar interessado em ler a documentação para obter mais detalhes sobre a
implantação no werf e as
principais diferenças do Helm .
Conclusão
A ausência de recursos críticos para nós nas soluções existentes de código aberto nos obriga a criar os recursos, ligações e integração correspondentes. O projeto werf foi criado e suportado, em primeiro lugar, para resolver as tarefas diárias de nossos engenheiros de DevOps.
Como exemplo, estamos trabalhando há muito tempo (segundo ano!) Para que
nossa proposta de rastreamento de recursos no Helm seja aceita como um modo alternativo na principal base de código do projeto (upstream). A comunidade aceitou e apoiou a ideia, como muitos precisam dessa oportunidade. No entanto, o progresso nessa direção começou no
Helm 3 e só agora ...
Até agora, a implementação dessa idéia no Helm foi praticamente bloqueada pelos desenvolvedores. Entretanto, durante esse tempo, desenvolvemos as funções correspondentes para rastrear recursos em uma biblioteca de código-fonte aberto separada -
kubedog - e já a estamos usando no werf. E, a julgar pela atividade no GitHub, a biblioteca encontrou interesse entre outros usuários do Kubernetes / Helm, o que é muito agradável.
Você pode apoiar nossa ideia (e implementação) colocando uma estrela no projeto kubedog no GitHub e / ou polegares para cima na
edição original do Helm. Obrigada
PS
Leia também em nosso blog: