No último Helm Summit, em Amsterdã, o projeto Helm foi o centro das atenções. Helm já é um gerenciador de pacotes padrão para a comunidade Kubernetes e está prestes a entrar no Cloud Native Computing Foundation (CNCF) como um projeto de nível superior.
O Helm é um gerenciador de pacotes de aplicações em execução no Kubernetes que descreve a estrutura de uma aplicação através dos Helm Charts, facilitando a instalação e o gerenciamento de pacotes e suas dependências. O Helm é semelhante aos gerenciadores de pacotes de sistemas operacionais yum, apt m, Homebrew, etc.
Com o advento dos microservices e a necessidade de dimensionar e gerenciar esses serviços de forma independente, o Helm oferece uma maneira de fazer isso através do uso de Helm Charts.
A InfoQ conversou com Matt Butcher, fundador do Helm e organizador do Helm Summit em Amsterdã, e explorou o crescimento do uso do Helm e seu futuro. Butcher também falou sobre a história do Helm, de como seu design foi influenciado por outros gerenciadores de pacotes, e como está ajudando a comunidade Kubernetes, seu tremendo crescimento e alguns dos desafios de segurança.
InfoQ: Poderia começar nos dando um breve "trip report" (relatório de viagem) do recente Helm summit e uma breve história do Helm? Poderia também nos dar algumas dicas de como tudo começou e algumas histórias internas que podem ser relevantes?
Matt Butcher: Na Deis, eu liderava uma equipe para criar a primeira oferta PaaS com base no Kubernetes, chamada Deis Workflow. Instalar essa aplicação multi-microservices foi difícil. Quando a Deis teve uma reunião de dois dias com toda a empresa, tivemos um exercício de criação entre equipes de hackathon. A equipe vencedora do hackathon recebeu um vale-presente de 75 dólares da Amazon. Formei um grupo com Jack Francis e Rimas Mocevicius e decidimos resolver o problema de instalação de aplicações no Kubernetes.
Durante o hackathon, criamos uma ferramenta que chamamos de "k8s place" ("Kate's Place") que era um sistema de gerenciamento de pacotes para o Kubernetes. Vencemos o hackathon.
No dia seguinte à reunião com toda a empresa, o CEO e o CTO me ligaram. Eles estavam conversando e queriam saber se Jack, Rimas e eu pensamos que essa coisa do K8S Place poderia ser transformada em uma ferramenta real. Eu disse que achava que podia. Mas todos concordamos que o nome do K8S Place era um pouco fofo demais para um projeto. Então, Jack e eu recebemos uma ligação e lemos um glossário de termos náuticos para encontrar um nome de projeto melhor que se encaixasse no tema Kubernetes. E assim nasceu Helm.
Alguns meses depois, lançamos o Helm no primeiro KubeCon. E alguns meses depois disso, ele se tornou um subprojeto oficial do Kubernetes.
O primeiro Helm Summit - O Helm ganhou mais força do que havíamos previsto. Mas quando se tratava do KubeCon, geralmente ficávamos parados, mergulhados em sessões profundas e detalhadas. E os organizadores do KubeCon não puderam alocar muitas sessões ao Helm porque o ecossistema é muito grande. Então Karen Chu, gerente da comunidade da Deis e depois do Microsoft Azure, teve a ideia de realizar um Helm Summit. Para o primeiro, em Portland, OR, fizemos uma conferência de trilha única. Foi incrível, enchemos o local e conheci dezenas e dezenas de devops, desenvolvedores e administradores de sistema. Brian Grant, líder do projeto Kubernetes, veio. Posteriormente, sugeriu que talvez o Helm tivesse superado o sub-projeto Kubernetes. Ele defendeu Helm subindo diretamente para a CNCF e nos ajudou ao longo do caminho.
A primeira Helm Summit Europeia - The Helm Summit em Amsterdã foi o nosso primeiro evento na europa. Inicialmente, tínhamos esperávamos 120 pessoas, mas chegamos a 130. Inicialmente, queríamos fazer isso em Milão, Itália. Mas não conseguimos encontrar o local perfeito. E o pessoal da Microsoft em Amsterdã ofereceu um local por lá, e assim mudamos.
O Helm Summit Amsterdam foi o nosso primeiro evento Helm realizado pela CNCF. Isso foi espetacular. Eles trouxeram conhecimentos e foram fabulosos para se trabalhar. Eu nunca participei de uma conferência tão bem organizada antes.
Neste Summit, mudamos o estilo de trilha única do Helm Summit Portland para uma conferência com duas trilhas. Isso nos permitiu aceitar mais palestrantes e também fornecer algum conteúdo do workshop em paralelo com as sessões regulares. A qualidade da sessão foi muito alta e, recebemos críticas positivas por unanimidade. Eu acho que grande parte dessa positividade era do tamanho. Acho que conheci e cumprimentei quase todas as pessoas que compareceram. Enquanto o KubeCon para 12.000 pessoas é divertido e chamativo, uma pequena conferência como essa permite algumas conexões pessoais, oferecendo ampla oportunidade para conhecer pessoas com interesses em comum.
O ponto alto da Helm Summit para mim foi conhecer Yusuke (conhecido no mundo Kubernetes por seu username do GitHub 'mumoshu'). Trabalho online com Yusuke há anos, e ele contribuiu em muitos projetos relacionados ao Helm, bem como ao Brigade (outro projeto do CNCF que iniciei). Mas nunca tivemos a oportunidade de nos encontrarmos pessoalmente. Eu voei do Colorado e ele de Tóquio. Vivemos em mundo fabuloso, podemos colaborar por anos sem realmente nos encontrar - e depois nos encontrarmos pela primeira vez em um continente estrangeiro para nós.
InfoQ: Como o Helm é frequentemente posicionado como um gerenciador de pacotes Kubernetes como o Homebrew/apt/yum, o Helm é mais aplicável aos administradores de sistemas do que desenvolvedores e arquitetos?
Butcher: Jack, Rimas e eu fomos profundamente inspirados pelo Apt e Homebrew. Adam Reese e Michelle Noorali (que se juntaram ao Helm em sua primeira semana oficial como projeto na Deis) foram profundamente influenciados pelo ecossistema do Ruby. Juntos, acreditávamos que estávamos estendendo a metáfora da gerenciamento de pacotes para um novo espaço: Cloud native (distribuídos) apps.
Como vemos (e acho que posso falar confortavelmente por todos), o primeiro objetivo de Helm sempre foi facilitar a historia do "do zero para o Kubernetes". Seja você um desenvolvedor, um engenheiro devops experiente ou um estudante que está apenas começando, nosso objetivo é fazer com que você instale aplicações no Kubernetes em dois minutos.
Claro que, desde dos dias em que estabelecemos esse objetivo, as coisas mudaram bastante. O Kubernetes explodiu em popularidade. Agora é comum ver clusters de produção k8s. Em um ponto de inflexão como esse, é bom perguntar: qual é o verdadeiro público de Helm?
Acreditamos que aqueles que estão em operação, irão obter benefícios de imediato do Kubernetes. O Helm Hub, concebido por engenheiros da Bitnami (agora VM Ware), é um portal projetado com as operações Kubernetes em mente.
Trabalhamos duro para tornar Helm Charts fácil para os desenvolvedores. A equipe criou um projeto chamado Draft, desenvolvido especificamente para ajudar os desenvolvedores a passar do código ao gráfico sem precisar aprender primeiro os manifestos do Kubernetes. Nossa filosofia de design aqui (como no Helm e em outros projetos) é a seguinte: ofereça às pessoas uma ferramenta para realizar seu trabalho de alta prioridade AGORA e, em seguida, dê a elas os meios para "aprender o caminho reverso" na tecnologia subjacente. O Ruby On Rails fez isso excepcionalmente bem no mundo do Ruby, e vimos isso há muito tempo como uma inspiração para o nosso trabalho.
InfoQ: Os Helm Charts substituem a complexidade dos arquivos YAML na instalação de aplicações Kubernetes? Como algumas das outras críticas, especialmente as complexidades de Kubernetes, são tratadas em Helm?
Butcher: Nosso principal objetivo com o formato gráfico era deixá-lo de uma maneira que um novato no Kubernetes nunca tivesse que ver um manifesto do Kubernetes YAML para instalar algo no Kubernetes. Porém, à medida que esses usuários se interessavam cada vez mais, para fazer mais com o Kubernetes, o Helm se tornaria uma ferramenta pedagógica. Mais uma vez, com base na resposta anterior, o Helm deve ajudar as pessoas a "aprender o caminho inverso" no Kubernetes. Instale um gráfico. Então vá ver o que foi criado (afinal, Helm diz a você). Então mude algumas coisas. Experimente suas alterações. Veja mais alguns gráficos. Veja como eles funcionam. Em pouco tempo, o usuário motivado do Helm se torna um usuário experiente do Kubernetes. E durante todo o processo de aprendizado, esses indivíduos podem implantar aplicações com sucesso! Uma coisa de que nos orgulhamos no Helm 3 é que os gráficos continuam relativamente simples. Tivemos opções para adicionar muitas linguagens de modelos diferentes, muito mais funcionalidades. Mas quando ouvimos nossos usuários, o que ouvimos:
- (a) a simplicidade foi ótima para aprender;
- (b) as ferramentas que fornecemos para os usuários foram suficientes para 95% dos casos;
- (c) onde o Helm não era suficiente, uma variedade de ferramentas complementares foram criadas para preencher as lacunas.
InfoQ: O Helm é relevante na integração ou entrega contínua (CI / CD) de microservices e, em caso afirmativo, qual o papel do Helm?
Butcher: não tenho certeza de que agrupar CI e microservices é um ajuste natural, mas vou tentar.
A arquitetura de microservices tornou-se algo novo: tornou-se uma maneira real de escrever e operar aplicações distribuídas. Mas para fazer isso bem, os microservices realmente precisam da camada de orquestração fornecida pelo Kubernetes. Caso contrário, é simplesmente muito complexo conectar todas as peças.
Helm abordou uma parte da esfera de aplicações cloud native: Isso facilitou a parte do Kubernetes. Mas eu diria que ficamos aquém em alguns caminhos chaves:
O Helm aborda apenas parte Kubernetes. Ofertas modernas cloud incluem serviços hospedados, ferramentas gerenciadas (como serviços de banco de dados), máquinas virtuais e armazenamento em rede - tudo fora do Kubernetes. O Helm não faz nada por isso. O Helm não gerencia as imagens do container. Apenas pressupõe que esses sejam gerenciados externamente e apenas gerencia os manifestos de Kubernetes.
Pensamos em adicionar ambos ao Helm, mas percebemos que isso poderia arruinar uma das principais coisas que amamos no Helm: sua simplicidade.
Seguindo mentalidade do UNIX de "faça bem uma coisa", criamos uma nova ferramenta para lidar com o cloud native. Criamos uma especificação aberta denominada Cloud Native Application Bundles CNAB, doamos ao JDF da Linux Foundation e, em seguida, criamos uma implementação de referência e um construtor declarativo opinativo. O CNAB trabalha com o Helm - e também com o Terraform, Ansible e praticamente qualquer ferramenta de gerenciamento de implantação - para permitir implantações realmente ricas de aplicações cloud native.
O CI também é uma história interessante. Frequentemente implantamos nossos gráficos Helm como parte de um pipeline no estilo gitops. E as outras ferramentas que construímos têm necessidades semelhantes. Mas quando analisamos o CI e o CD, notamos um território desconhecido. O Kubernetes fornece as camadas rudimentares de operações contínuas: os Jobs são de curta duração, enquanto as implantações são perfeitas para os gateways de longa duração. Mas, quando demos uma olhada no cenário em 2017, ninguém tinha feito uso dessa capacidade do Kubernetes.
Então, pegamos o conhecimento que adquirimos com Helm e criamos Brigade. O Brigade não é apenas um sistema de CI no entanto. É mais flexível que isso. Inspirados na maneira como os scripts shell do UNIX permitem que os usuários encadeiam comandos de shell e encaminhe os dados de um para o outro, criamos uma estrutura geral para escrever scripts (em JavaScript) que poderiam encadear containers do Docker, passando informações de um para o outro para pipelines de processamento.
O Brigade, é também um projeto do CNCF, fornece uma interface orientada a eventos. Assim, você pode escrever scripts do Brigade que respondem a solicitações de pull requests do GitHub, ou eventos cloud, ou eventos da API do Kubernetes ou mensagens de pub/sub do Kafka ... o céu é o limite.
No Helm Summit Amsterdã, Yusuke (mumoshu) fez uma apresentação na qual mostrou como havia usado o Brigade e construido um sofisticado pipeline de CI para gráficos Helm, que depois entregou os gráficos testados a um sistema de CD que os colocou imediatamente em produção. Foi um momento tão agradável ver alguém tomar um pouco de uma idéia que eu tive e correr com ela, construindo algo muito mais elegante e poderoso do que eu imaginava quando minha equipe começou no Brigade.
InfoQ: Podemos perguntar o que há de novo no Helm 3? Como estão sendo resolvidos alguns dos problemas de segurança do componente Tiller no lado do cluster?
Butcher: Primeiro, para esclarecer as coisas, "os rumores sobre a insegurança do Helm 2 são amplamente exagerados". A principal reclamação foi que o Kubernetes não era multi-tenant garantido por padrão, o que é verdade. É preciso ativar a segurança no Helm. Alguns indivíduos barulhentos espalharam rumores de que havia alguma profunda e inerente falha de segurança no Helm, quando, na realidade, a solução é "ativar o mTLS". (O próprio Helm tem apenas dois CVEs, nenhum deles crítico)
O Helm 3 removeu completamente o Tiller. Nós nunca ficamos entusiasmados com o Tiller quando o adicionamos ao Helm 2, mas na época o Kubernetes parecia que ia ser totalmente gRPC, e tínhamos imaginado uma experiência mais integrada. Em vez disso, o Kubernetes ficou com o YAML e o REST. Por isso, seguimos o ciclo Helm 2 de maneira respeitosa, sem fazer alterações. Então a primeira coisa que fizemos na branch do Helm 3 foi remover o Tiller e refatorar o código. O Helm 3 agora usa recursos no cluster com controle de versão atomic para armazenar versões, mas não requer mais a execução de nenhum código no cluster.
Fizemos o possível para permanecer fiel ao SemVer2, sem quebrar a compatibilidade entre o Helm 2.0 e o atual. Mas o Helm 3 é nossa chance de consertar muitas coisas. Por exemplo, os CRDs foram introduzidos ao longo de um ano no Helm 2. Portanto, não foi possível adicionar suporte a CRDs de forma alguma que pudesse quebrar os clientes ou charts existentes. Mas com o Helm 3, finalmente conseguimos escrever uma implementação sensata dos CRDs.
Embora tenhamos literalmente reescrito todo Helm, o interessante é que, o usuário comum não precisa mudar muito. Alguns sinalizadores de linha de comando foram alterados. Introduzimos um novo formato de chart (Chart v2), mas quase tudo "funcionará" como sempre. E para instalações Helm estabelecidas, temos até uma ferramenta de migração para facilitar a transição.
InfoQ: Você pode falar sobre o crescimento da comunidade Helm? Há algo mais que você queira destacar no Helm que evite alguns pontos problemáticos para desenvolvedores e arquitetos?
Buthcer: O ecossistema do Helm ficou grande o suficiente para que eu não consiga mais rastreá-lo. Um dos momentos mais petrificantes da minha vida aconteceu quando um indivíduo me viu usando o logotipo da Kubernetes e veio falar comigo, dizendo que fez sua renda com Helm. Ele não tinha ideia de quem eu era, e eu nunca disse a ele. Eu apenas ouvi o discurso dele em silêncio, fiz algumas perguntas e segui em frente. Mas foi um momento poderoso para mim. Eu nunca tinha pensado no fato de que uma ferramenta criada por minha equipe era realmente a fonte de subsistência para uma empresa com mais de 20 pessoas!
Costumávamos acompanhar todas as ferramentas no ecossistema Helm no GitHub. Mas, nesse ponto, esse documento não é mais o representante de um ecossistema muito maior que se formou em torno do projeto. Não posso lhe dizer que privilégio é saber que tantos projetos foram criados em torno do nosso pequeno projeto de hackathon. Código aberto ... me surpreendeu por alguns dias. Pense nas milhares de horas que todos esses desenvolvedores espalhados por todo o mundo colocam em ferramentas de construção "que se coçam" e, em seguida, oferecem para outras pessoas usarem e expandirem.
No lado do código, estou totalmente impressionado com a participação da comunidade. Milhares de colaboradores de mais de 700 empresas nos ajudaram a criar o Helm, criar charts e gerenciar as principais ferramentas e o site do Helm. Muitas dessas pessoas também contribuem para outros projetos no ecossistema mais amplo, como Helmfile, Helm Hub e Monocular.
Eu poderia dizer que tenho orgulho do Helm. Mas "orgulhoso" não é a palavra certa. Isso implica que eu o criei para ser o que eu queria que fosse. Em vez disso, estou intimidado pelo Helm. As pessoas, o código, o ecossistema - tudo isso está muito além do que Jack, Rimas e eu imaginávamos quando construímos pela primeira vez nossa pequena demonstração do K8S Place. Dois anos atrás, quando a Microsoft adquiriu a Deis, me perguntaram, quais eram minhas esperanças para Helm. Na época, eu disse: "Espero que Helm seja um projeto de 10 anos", o que significa que esperava que fosse um projeto que pudesse atingir uma idade avançada no mundo do software em ritmo acelerado. E ainda espero que isso seja verdade. Hoje em dia, minha verdadeira esperança é que a visão da comunidade a seu redor continue superando minha própria imaginação superficial.
Em resumo, o Helm se tornou o gerenciador de pacotes do Kubernetes e experimentou um crescimento constante ao resolver os principais problemas de desenvolvimento de aplicações na plataforma de infraestrutura.
Informações mais detalhadas estão disponíveis no Docs, incluindo um guia para os primeiros passos.