{"id":34735,"date":"2019-10-31T22:00:06","date_gmt":"2019-10-31T19:00:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/znakomstvo-s-helm-3\/"},"modified":"2019-10-31T22:00:06","modified_gmt":"2019-10-31T19:00:06","slug":"znakomstvo-s-helm-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/znakomstvo-s-helm-3","title":{"rendered":"Introdu\u00e7\u00e3o ao Helm 3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o ao Helm 3\" src=\"\/wp-content\/uploads\/2019\/05\/6de0e2887ddcc802f1dd71c902325401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Nota do tradutor.<\/b>: 16 de maio deste ano \u2014 um marco significativo no desenvolvimento do gerenciador de pacotes para Kubernetes \u2014 Helm. Nesse dia, foi apresentado o primeiro release alfa da futura vers\u00e3o importante do projeto \u2014 3.0. Seu lan\u00e7amento trar\u00e1 mudan\u00e7as substanciais e esperadas ao Helm, nas quais muitos na comunidade Kubernetes depositam grandes expectativas. N\u00f3s mesmos nos inclu\u00edmos entre esses, pois utilizamos ativamente o Helm para implantar aplicativos: o integramos \u00e0 nossa ferramenta para implementa\u00e7\u00e3o de CI\/CD <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> e, ocasionalmente, contribu\u00edmos para o desenvolvimento upstream. Esta tradu\u00e7\u00e3o re\u00fane 7 notas do blog oficial do Helm, que marcam o primeiro release alfa do Helm 3 e contam a hist\u00f3ria do projeto e suas principais funcionalidades. O autor \u00e9 Matt \"bacongobbler\" Fisher, funcion\u00e1rio da Microsoft e um dos principais mantenedores do Helm.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>15 de outubro de 2015 nasceu o projeto, agora conhecido como Helm. Apenas um ano ap\u00f3s sua funda\u00e7\u00e3o, a comunidade do Helm se juntou ao Kubernetes, trabalhando ativamente no Helm 2. Em junho de 2018, o Helm <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cncf.io\/blog\/2018\/06\/01\/cncf-to-host-helm\/\">entrou para a CNCF<\/a><\/noindex> como um projeto incubando. Vamos ao presente \u2014 e j\u00e1 est\u00e1 se aproximando o primeiro release alfa do novo Helm 3 <i>(este release <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">j\u00e1 ocorreu<\/a><\/noindex> em meados de maio \u2014 nota do tradutor)<\/i>.<\/p>\n<p>Neste material, contarei como tudo come\u00e7ou, como chegamos ao est\u00e1gio atual, apresentarei algumas caracter\u00edsticas \u00fanicas dispon\u00edveis no primeiro release alfa do Helm 3 e explicarei como planejamos seguir em frente.<\/p>\n<p>Resumo:<\/p>\n<ul>\n<li>hist\u00f3ria da cria\u00e7\u00e3o do Helm;<\/li>\n<li>uma despedida carinhosa ao Tiller;<\/li>\n<li>reposit\u00f3rios de charts;<\/li>\n<li>gest\u00e3o de releases;<\/li>\n<li>altera\u00e7\u00f5es nas depend\u00eancias dos charts;<\/li>\n<li>library charts;<\/li>\n<li>e agora, o que fazer?<\/li>\n<\/ul>\n<p><\/p>\n<h2>A Hist\u00f3ria da Cria\u00e7\u00e3o do Helm<\/h2>\n<p><\/p>\n<h3>Nascimento<\/h3>\n<p>\nO Helm 1 come\u00e7ou como um projeto de C\u00f3digo Aberto, criado pela empresa Deis. Fomos uma pequena startup, <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.microsoft.com\/blog\/2017\/04\/10\/microsoft-acquire-deis-help-companies-innovate-containers\/\">absorvida<\/a><\/noindex> pela Microsoft na primavera de 2017. Nosso outro projeto de C\u00f3digo Aberto, tamb\u00e9m chamado Deis, possu\u00eda uma ferramenta <code>deisctl<\/code>, que era usada (entre outras coisas) para instalar e operar a plataforma Deis em um <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/fleet\">cluster Fleet<\/a><\/noindex>. Naquela \u00e9poca, o Fleet era uma das primeiras plataformas de orquestra\u00e7\u00e3o de cont\u00eaineres.<\/p>\n<p>No meio de 2015, decidimos mudar de dire\u00e7\u00e3o e migramos o Deis (naquele momento rebatizado como Deis Workflow) do Fleet para o Kubernetes. Um dos primeiros a ser reformulado foi a ferramenta de instala\u00e7\u00e3o <code>deisctl<\/code>. N\u00f3s a utilizamos para instalar e gerenciar o Deis Workflow em um cluster Fleet.<\/p>\n<p>O Helm 1 foi criado com base em conhecidos gerenciadores de pacotes, como Homebrew, apt e yum. Sua principal tarefa era simplificar tarefas como empacotamento e instala\u00e7\u00e3o de aplicativos no Kubernetes. O Helm foi oficialmente apresentado em 2015 na confer\u00eancia KubeCon em San Francisco.<\/p>\n<p>Nossa primeira tentativa com Helm funcionou, mas n\u00e3o sem limita\u00e7\u00f5es s\u00e9rias. Ele usava um conjunto de manifestos do Kubernetes, enriquecidos por geradores, como blocos YAML de entrada. <i>(front-matter)<\/i>*, e carregava os resultados no Kubernetes.<\/p>\n<p><i>* <b>Nota do tradutor.<\/b>: A partir da primeira vers\u00e3o do Helm, foi escolhido o syntax YAML para descrever os recursos do Kubernetes, e ao escrever as configura\u00e7\u00f5es, suportava-se templates Jinja e scripts Python. Mais sobre isso e sobre como era a primeira vers\u00e3o do Helm, escrevemos no cap\u00edtulo \"Uma breve hist\u00f3ria do Helm\" <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">deste material<\/a><\/noindex>.<\/i><\/p>\n<p>Por exemplo, para substituir um campo em um arquivo YAML, era necess\u00e1rio adicionar a seguinte constru\u00e7\u00e3o no manifesto:<\/p>\n<pre><code class=\"plaintext\">#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my\/pod.yaml<\/code><\/pre>\n<p>\n\u00c9 incr\u00edvel que hoje existam geradores de templates, n\u00e3o \u00e9 mesmo?<\/p>\n<p>Por muitas raz\u00f5es, esse primeiro instalador do Kubernetes exigia uma lista rigidamente definida de arquivos de manifestos e executava apenas uma sequ\u00eancia fixa de eventos. Us\u00e1-lo era t\u00e3o dif\u00edcil que a equipe de P&amp;D do Deis Workflow teve dificuldades quando tentou migrar seu produto para essa plataforma \u2014 no entanto, as sementes da ideia j\u00e1 haviam sido plantadas. Nossa primeira tentativa foi uma excelente oportunidade de aprendizado: percebemos que est\u00e1vamos realmente apaixonados por criar ferramentas pragm\u00e1ticas que resolvessem problemas cotidianos para nossos usu\u00e1rios.<\/p>\n<p>Baseando-se na experi\u00eancia de erros passados, come\u00e7amos a desenvolver o Helm 2.<\/p>\n<h3>Cria\u00e7\u00e3o do Helm 2<\/h3>\n<p>\nNo final de 2015, a equipe do Google entrou em contato conosco. Eles estavam trabalhando em uma ferramenta semelhante para o Kubernetes. O Deployment Manager para Kubernetes era um porto de uma ferramenta existente que era usada para a Google Cloud Platform. \"N\u00e3o queremos, \u2014 perguntaram eles, \u2014 passar alguns dias discutindo semelhan\u00e7as e diferen\u00e7as?\"<\/p>\n<p>Em janeiro de 2016, as equipes do Helm e do Deployment Manager se encontraram em Seattle para trocar ideias. As negocia\u00e7\u00f5es resultaram em um plano ambicioso: unir ambos os projetos para criar o Helm 2. Junto com a Deis e o Google, a equipe de desenvolvedores contou com a participa\u00e7\u00e3o de pessoas de <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/skippbox\">SkippBox<\/a><\/noindex> <i>(hoje parte da Bitnami \u2014 nota do tradutor)<\/i>, e come\u00e7amos a trabalhar no Helm 2.<\/p>\n<p>Quer\u00edamos manter a simplicidade de uso do Helm, mas adicionar o seguinte:<\/p>\n<ul>\n<li> modelos de charts para personaliza\u00e7\u00e3o;<\/li>\n<li> gerenciamento intra-cluster para equipes;<\/li>\n<li> um reposit\u00f3rio de charts de primeira classe;<\/li>\n<li> um formato de pacotes est\u00e1vel com suporte \u00e0 assinatura;<\/li>\n<li> um forte compromisso com versionamento sem\u00e2ntico e manuten\u00e7\u00e3o da compatibilidade reversa entre vers\u00f5es.<\/li>\n<\/ul>\n<p>\nPara alcan\u00e7ar esses objetivos, foi adicionado um segundo elemento ao ecossistema Helm. Este componente intra-cluster foi chamado de Tiller e era respons\u00e1vel pela instala\u00e7\u00e3o e gerenciamento de charts do Helm.<\/p>\n<p>Desde o lan\u00e7amento do Helm 2 em 2016, o Kubernetes passou por v\u00e1rias inova\u00e7\u00f5es significativas. O gerenciamento de acesso baseado em fun\u00e7\u00f5es (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/422801\/\">RBAC<\/a><\/noindex>), que eventualmente substituiu o controle de acesso baseado em atributos (ABAC). Novos tipos de recursos foram introduzidos (os Deployments ainda estavam em status beta na \u00e9poca). As Custom Resource Definitions foram inventadas (originalmente chamadas de Third Party Resources ou TPRs). E, o mais importante, um conjunto de melhores pr\u00e1ticas foi estabelecido.<\/p>\n<p>Em meio a todas essas mudan\u00e7as, o Helm continuou a servir com lealdade os usu\u00e1rios do Kubernetes. Ap\u00f3s tr\u00eas anos e muitas novas adi\u00e7\u00f5es, ficou claro que era hora de fazer mudan\u00e7as significativas na base de c\u00f3digo para que o Helm pudesse continuar a atender \u00e0s crescentes necessidades do ecossistema em evolu\u00e7\u00e3o.<\/p>\n<h2>Uma despedida carinhosa ao Tiller<\/h2>\n<p>\nDurante o desenvolvimento do Helm 2, apresentamos o Tiller como parte da nossa integra\u00e7\u00e3o com o Deployment Manager do Google. O Tiller desempenhou um papel crucial para as equipes que operam em um cluster compartilhado: ele permitia que diferentes especialistas que gerenciavam a infraestrutura interagissem com o mesmo conjunto de lan\u00e7amentos.<\/p>\n<p>Como o controle de acesso baseado em fun\u00e7\u00f5es (RBAC) foi habilitado por padr\u00e3o no Kubernetes 1.6, trabalhar com o Tiller em produ\u00e7\u00e3o tornou-se mais complexo. Devido ao grande n\u00famero de pol\u00edticas de seguran\u00e7a poss\u00edveis, nossa posi\u00e7\u00e3o era oferecer uma configura\u00e7\u00e3o permissiva por padr\u00e3o. Isso permitia que os novatos experimentassem com o Helm e o Kubernetes sem precisar primeiro se aprofundar nas configura\u00e7\u00f5es de seguran\u00e7a. Infelizmente, essa configura\u00e7\u00e3o permissiva poderia dar ao usu\u00e1rio um conjunto de permiss\u00f5es muito amplo, que ele n\u00e3o precisava. Engenheiros de DevOps e SRE tinham que aprender etapas operacionais adicionais ao instalar o Tiller em um cluster multi-tenant.<\/p>\n<p>Ao descobrir como os membros da comunidade usam o Helm em situa\u00e7\u00f5es espec\u00edficas, entendemos que o sistema de gerenciamento de lan\u00e7amentos do Tiller n\u00e3o precisava depender de um componente intracluster para manter estados ou funcionar como um hub central com informa\u00e7\u00f5es sobre o lan\u00e7amento. Em vez disso, poder\u00edamos simplesmente obter informa\u00e7\u00f5es do servidor API do Kubernetes, gerar o chart do lado do cliente e armazenar um registro da instala\u00e7\u00e3o no Kubernetes.<\/p>\n<p>A principal tarefa do Tiller poderia ser realizada sem o Tiller, ent\u00e3o uma de nossas primeiras decis\u00f5es em rela\u00e7\u00e3o ao Helm 3 foi eliminar completamente o Tiller.<\/p>\n<p>Com a sa\u00edda do Tiller, o modelo de seguran\u00e7a do Helm foi radicalmente simplificado. O Helm 3 agora suporta todos os m\u00e9todos modernos de seguran\u00e7a, identifica\u00e7\u00e3o e autoriza\u00e7\u00e3o do Kubernetes atual. As permiss\u00f5es do Helm s\u00e3o definidas por meio de <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/organize-cluster-access-kubeconfig\/\">arquivo kubeconfig<\/a><\/noindex>. Administradores de cluster podem restringir os direitos dos usu\u00e1rios com qualquer n\u00edvel de detalhe. Os lan\u00e7amentos ainda s\u00e3o mantidos dentro do cluster, e a funcionalidade restante do Helm \u00e9 preservada.<\/p>\n<h2>Reposit\u00f3rios de charts<\/h2>\n<p>\nEm um n\u00edvel alto, um reposit\u00f3rio de charts \u00e9 um lugar para armazenar e compartilhar charts. O cliente Helm empacota e envia charts para o reposit\u00f3rio. Em termos simples, um reposit\u00f3rio de charts \u00e9 um servidor HTTP primitivo com um arquivo index.yaml e alguns charts empacotados.<\/p>\n<p>Embora haja algumas vantagens em um API de reposit\u00f3rio de charts atender aos requisitos mais b\u00e1sicos de armazenamento, ele tamb\u00e9m apresenta algumas desvantagens:<\/p>\n<ul>\n<li> Os reposit\u00f3rios de charts s\u00e3o mal compat\u00edveis com a maioria das implementa\u00e7\u00f5es de seguran\u00e7a necess\u00e1rias em ambientes de produ\u00e7\u00e3o. Ter uma API padr\u00e3o para autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o \u00e9 extremamente importante em cen\u00e1rios de produ\u00e7\u00e3o.<\/li>\n<li> As ferramentas do Helm para rastreamento da origem do chart, usadas para assinatura, verifica\u00e7\u00e3o de integridade e origem do chart, s\u00e3o uma parte opcional do processo de publica\u00e7\u00e3o do Chart.<\/li>\n<li> Em cen\u00e1rios multusu\u00e1rio, o mesmo chart pode ser carregado por outro usu\u00e1rio, dobrando a quantidade de espa\u00e7o necess\u00e1ria para armazenar o mesmo conte\u00fado. Para resolver esse problema, reposit\u00f3rios mais inteligentes foram desenvolvidos, mas eles n\u00e3o fazem parte da especifica\u00e7\u00e3o formal.<\/li>\n<li> O uso de um \u00fanico arquivo de \u00edndice para buscar, armazenar metadados e obter charts complicou o desenvolvimento de implementa\u00e7\u00f5es multusu\u00e1rio seguras.<\/li>\n<\/ul>\n<p>\nProjeto <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/docker\/distribution\">Docker Distribution<\/a><\/noindex> (tamb\u00e9m conhecido como Docker Registry v2) \u00e9 o sucessor do Docker Registry e, de fato, serve como um conjunto de ferramentas para empacotar, enviar, armazenar e entregar imagens Docker. Muitos grandes provedores de servi\u00e7os em nuvem oferecem produtos baseados no Distribution. Devido a essa aten\u00e7\u00e3o aumentada, o projeto Distribution se beneficiou de anos de melhorias, melhores pr\u00e1ticas de seguran\u00e7a e testes em condi\u00e7\u00f5es de \"campo\", transformando-o em um dos her\u00f3is n\u00e3o cantados mais bem sucedidos do mundo Open Source.<\/p>\n<p>Mas voc\u00ea sabia que o projeto Distribution foi desenvolvido para distribuir qualquer forma de conte\u00fado, e n\u00e3o apenas imagens de cont\u00eaineres?<\/p>\n<p>Gra\u00e7as aos esfor\u00e7os <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opencontainers.org\/\">Open Container Initiative<\/a><\/noindex> (ou OCI), os charts do Helm podem ser hospedados em qualquer inst\u00e2ncia do Distribution. Enquanto esse processo ainda est\u00e1 em car\u00e1ter experimental. O trabalho para suportar logins e outras fun\u00e7\u00f5es necess\u00e1rias para um Helm 3 completo ainda n\u00e3o foi conclu\u00eddo, mas estamos muito animados com a oportunidade de aprender com as descobertas feitas pelas equipes da OCI e do Distribution ao longo dos anos. E gra\u00e7as \u00e0 sua orienta\u00e7\u00e3o e supervis\u00e3o, estamos descobrindo o que significa operar um servi\u00e7o de alta disponibilidade em grande escala.<\/p>\n<p>Uma descri\u00e7\u00e3o mais detalhada de algumas altera\u00e7\u00f5es futuras nos reposit\u00f3rios dos charts do Helm est\u00e1 dispon\u00edvel <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.bacongobbler.com\/post\/2019-01-25-distributing-with-distribution\/\">no link<\/a><\/noindex>.<\/p>\n<h2>Gerenciamento de lan\u00e7amentos<\/h2>\n<p>\nNo Helm 3, o estado do aplicativo \u00e9 rastreado dentro do cluster por meio de um par de objetos:<\/p>\n<ul>\n<li> o objeto release \u2014 representa uma inst\u00e2ncia do aplicativo;<\/li>\n<li> o segredo da vers\u00e3o de lan\u00e7amento representa o estado desejado do aplicativo em um momento espec\u00edfico (por exemplo, o lan\u00e7amento de uma nova vers\u00e3o).<\/li>\n<\/ul>\n<p>\nChamada <code>helm install<\/code> cria o objeto de lan\u00e7amento e o segredo da vers\u00e3o de lan\u00e7amento. A chamada <code>helm upgrade<\/code> exige a presen\u00e7a do objeto de lan\u00e7amento (que pode ser alterado) e cria um novo segredo de vers\u00e3o de lan\u00e7amento, contendo novos valores e um manifesto preparado.<\/p>\n<p>O objeto de release cont\u00e9m informa\u00e7\u00f5es sobre o release, onde o release \u00e9 uma instala\u00e7\u00e3o espec\u00edfica de um chart nomeado e valores. Este objeto descreve os metadados de alto n\u00edvel sobre o release. O objeto de release \u00e9 mantido durante todo o ciclo de vida da aplica\u00e7\u00e3o e atua como o propriet\u00e1rio de todos os secrets de vers\u00e3o de release, bem como de todos os objetos que s\u00e3o diretamente criados pelo chart do Helm.<\/p>\n<p>O segredo de vers\u00e3o de lan\u00e7amento vincula o lan\u00e7amento a uma s\u00e9rie de revis\u00f5es (instala\u00e7\u00e3o, atualiza\u00e7\u00f5es, revers\u00f5es, exclus\u00f5es).<\/p>\n<p>No Helm 2, as revis\u00f5es eram exclusivamente sequenciais. A chamada <code>helm install<\/code> criou v1, a atualiza\u00e7\u00e3o subsequente (upgrade) \u00e9 v2, e assim por diante. O release e o secret de vers\u00e3o do release foram combinados em um \u00fanico objeto, conhecido como revis\u00e3o. As revis\u00f5es eram armazenadas no mesmo namespace que o Tiller, o que significava que cada release era \"global\" em termos de namespace; como resultado, apenas uma inst\u00e2ncia do nome poderia ser utilizada.<\/p>\n<p>No Helm 3, cada release est\u00e1 associado a um ou mais secrets de vers\u00e3o de release. O objeto de release sempre descreve o release atual implantado no Kubernetes. Cada secret de vers\u00e3o de release descreve apenas uma vers\u00e3o desse release. Uma atualiza\u00e7\u00e3o (upgrade), por exemplo, criar\u00e1 um novo secret de vers\u00e3o de release e ent\u00e3o mudar\u00e1 o objeto de release para apontar para essa nova vers\u00e3o. Em caso de rollback, \u00e9 poss\u00edvel usar os secrets de vers\u00e3o de release anteriores para reverter o release para seu estado anterior.<\/p>\n<p>Ap\u00f3s a remo\u00e7\u00e3o do Tiller, o Helm 3 armazena dados sobre o release em um \u00fanico namespace associado ao release. Essa mudan\u00e7a permite que um chart com o mesmo nome de release seja instalado em outro namespace, e os dados s\u00e3o mantidos entre atualiza\u00e7\u00f5es\/reinicializa\u00e7\u00f5es do cluster no etcd. Por exemplo, \u00e9 poss\u00edvel instalar o WordPress no namespace \"foo\", e depois no namespace \"bar\", e ambos os releases podem ser chamados de \"wordpress\".<\/p>\n<h2>Mudan\u00e7as nas depend\u00eancias dos gr\u00e1ficos<\/h2>\n<p>\nGr\u00e1ficos empacotados (usando <code>helm package<\/code>) para uso com o Helm 2, pode ser instalado com o Helm 3, no entanto, o fluxo de trabalho de desenvolvimento de charts foi completamente revisado, portanto, algumas altera\u00e7\u00f5es s\u00e3o necess\u00e1rias para continuar o desenvolvimento de charts com o Helm 3. Em particular, o sistema de gerenciamento de depend\u00eancias de charts mudou.<\/p>\n<p>O sistema de gerenciamento de depend\u00eancias do chart passou a ser <code>requirements.yaml<\/code> e <code>requirements.lock<\/code> para <code>Chart.yaml<\/code> e <code>Chart.lock<\/code>. Isso significa que os charts que usavam o comando <code>helm dependency<\/code>, requerem algumas ajustes para funcionar no Helm 3.<\/p>\n<p>Vamos considerar um exemplo. Vamos adicionar uma depend\u00eancia ao chart do Helm 2 e ver o que muda ao migrar para o Helm 3.<\/p>\n<p>No Helm 2 <code>requirements.yaml<\/code> parecia o seguinte:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nNo Helm 3, a mesma depend\u00eancia ser\u00e1 refletida em seu <code>Chart.yaml<\/code>:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nOs charts ainda s\u00e3o baixados e colocados no diret\u00f3rio <code>charts\/<\/code>, portanto, os subcharts <i>(subcharts)<\/i>, localizados na pasta <code>charts\/<\/code>, continuar\u00e3o a funcionar sem altera\u00e7\u00f5es.<\/p>\n<h2>Apresentando Library Charts<\/h2>\n<p>\nO Helm 3 suporta uma classe de charts conhecida como charts de biblioteca <i>(library chart)<\/i>. Este chart \u00e9 utilizado por outros charts, mas n\u00e3o cria nenhum artefato de release por conta pr\u00f3pria. Os templates dos charts de biblioteca podem declarar apenas elementos <code>definir<\/code>. Conte\u00fados diferentes s\u00e3o simplesmente ignorados. Isso permite que os usu\u00e1rios reutilizem e compartilhem fragmentos de c\u00f3digo que podem ser usados em muitos charts, evitando a duplica\u00e7\u00e3o e seguindo o princ\u00edpio <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_repeat_yourself\">DRY<\/a><\/noindex>.<\/p>\n<p>Os library charts s\u00e3o declarados na se\u00e7\u00e3o <code>dependencies<\/code> no arquivo <code>Chart.yaml<\/code>. A instala\u00e7\u00e3o e gerenciamento deles n\u00e3o diferem de outros charts.<\/p>\n<pre><code class=\"plaintext\">dependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io<\/code><\/pre>\n<p>\nEstamos ansiosos pelas possibilidades de uso que este componente abrir\u00e1 para os desenvolvedores de charts, bem como pelas melhores pr\u00e1ticas que podem surgir atrav\u00e9s dos library charts.<\/p>\n<h2>E agora?<\/h2>\n<p>\nHelm 3.0.0-alpha.1 \u00e9 a base sobre a qual come\u00e7amos a construir uma nova vers\u00e3o do Helm. Neste artigo, descrevi algumas possibilidades interessantes do Helm 3. Muitas delas ainda est\u00e3o em est\u00e1gios iniciais de desenvolvimento, e isso \u00e9 normal; a natureza do alpha release \u00e9 testar a ideia, coletar feedback dos primeiros usu\u00e1rios e validar nossas suposi\u00e7\u00f5es.<\/p>\n<p>Assim que a vers\u00e3o alpha for lan\u00e7ada <i>(lembrando que isso <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">j\u00e1 ocorreu<\/a><\/noindex> \u2014 nota do tradutor.)<\/i>, come\u00e7aremos a aceitar patches para o Helm 3 da comunidade. \u00c9 necess\u00e1rio criar uma base s\u00f3lida que permita desenvolver e aceitar novas funcionalidades, e que os usu\u00e1rios possam se sentir envolvidos no processo, abrindo tickets e fazendo corre\u00e7\u00f5es.<\/p>\n<p>Neste artigo, procurei destacar algumas melhorias significativas que vir\u00e3o com o Helm 3, no entanto, esta lista n\u00e3o pode ser considerada exaustiva. O plano abrangente para o Helm 3 inclui inova\u00e7\u00f5es como estrat\u00e9gias de atualiza\u00e7\u00e3o aprimoradas, uma integra\u00e7\u00e3o mais profunda com registros OCI e o uso de esquemas JSON para valida\u00e7\u00e3o de valores de charts. Tamb\u00e9m planejamos limpar a base de c\u00f3digo e atualizar partes que foram negligenciadas nos \u00faltimos tr\u00eas anos.<\/p>\n<p>Se voc\u00ea sentir que esquecemos de algo, adorar\u00edamos ouvir suas opini\u00f5es!<\/p>\n<p>Junte-se \u00e0 discuss\u00e3o em nossos <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.slack.com\/\">canais do Slack<\/a><\/noindex>:<\/p>\n<ul>\n<li> <code>#helm-users<\/code> para perguntas e para um bate-papo simples com a comunidade;<\/li>\n<li> <code>#helm-dev<\/code> para discuss\u00e3o de pull requests, c\u00f3digo e bugs.<\/li>\n<\/ul>\n<p>\nVoc\u00ea tamb\u00e9m pode participar de nossas Public Developer Calls semanais, \u00e0s quintas-feiras \u00e0s 19:30 MSK. As reuni\u00f5es s\u00e3o dedicadas \u00e0 discuss\u00e3o de tarefas em que os principais desenvolvedores e a comunidade est\u00e3o trabalhando, bem como aos t\u00f3picos de discuss\u00e3o da semana. Qualquer um pode se juntar e participar da reuni\u00e3o. O link est\u00e1 dispon\u00edvel no canal do Slack <code>#helm-dev<\/code>.<\/p>\n<h2>P.S. do tradutor<\/h2>\n<p>\nConfira tamb\u00e9m em nosso blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">Gerenciador de pacotes para Kubernetes \u2014 Helm: passado, presente, futuro<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438814\/\">Um olhar s\u00f3brio sobre o Helm 2: \"Assim como est\u00e1...\"<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/420437\/\">Introdu\u00e7\u00e3o pr\u00e1tica ao gerenciador de pacotes para Kubernetes \u2014 Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/441964\/\">Dicas e truques do Kubernetes: migrando recursos em execu\u00e7\u00e3o no cluster para o Helm 2<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/336170\/\">Pr\u00e1tica com dapp. Parte 2. Deploy de imagens Docker no Kubernetes usando Helm<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: 16 \u043c\u0430\u044f \u044d\u0442\u043e\u0433\u043e \u0433\u043e\u0434\u0430 \u2014 \u0437\u043d\u0430\u0447\u0438\u043c\u0430\u044f \u0432\u0435\u0445\u0430 \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0430 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 \u0434\u043b\u044f Kubernetes \u2014 Helm. \u0412 \u044d\u0442\u043e\u0442 \u0434\u0435\u043d\u044c \u0431\u044b\u043b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d \u043f\u0435\u0440\u0432\u044b\u0439 \u0430\u043b\u044c\u0444\u0430-\u0440\u0435\u043b\u0438\u0437 \u0431\u0443\u0434\u0443\u0449\u0435\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u2014 3.0. \u0415\u0451 \u0432\u044b\u0445\u043e\u0434 \u043f\u0440\u0438\u043d\u0435\u0441\u0451\u0442 \u0432 Helm \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0435 \u0438 \u0434\u043e\u043b\u0433\u043e\u0436\u0434\u0430\u043d\u043d\u044b\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043d\u043e\u0433\u0438\u0435 \u0432 Kubernetes-\u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0435 \u0432\u043e\u0437\u043b\u0430\u0433\u0430\u044e\u0442 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043d\u0430\u0434\u0435\u0436\u0434\u044b. \u041a \u0442\u0430\u043a\u043e\u0432\u044b\u043c \u043e\u0442\u043d\u043e\u0441\u0438\u043c\u0441\u044f \u0438 \u043c\u044b \u0441\u0430\u043c\u0438, \u043f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0430\u043a\u0442\u0438\u0432\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26173,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Introdu\u00e7\u00e3o ao Helm 3 | ProHoster","description":"Nota.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/znakomstvo-s-helm-3","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/znakomstvo-s-helm-3","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:06+00:00","article:modified_time":"2019-10-31T19:00:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34735","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:26:53","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 23:08:04","updated":"2026-01-21 20:26:53","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=34735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/26173"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=34735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=34735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=34735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}