O Helm é frequentemente chamado de "gerenciador de pacotes do Kubernetes", e por boas razões. Assim como o apt ou yum simplificam a instalação de software em sistemas Linux, o Helm simplifica a implantação de aplicações em clusters Kubernetes. Em vez de lidar com dezenas de arquivos YAML espalhados, você empacota tudo em um chart e instala com um único comando. Nesta aula, vamos explorar os conceitos centrais do Helm, desde a estrutura de um chart até a criação de templates dinâmicos, passando por casos de uso reais que mostram por que o Helm se tornou uma ferramenta indispensável no ecossistema DevOps.

O Helm não apenas facilita a instalação, mas também permite atualizações, rollbacks e gerenciamento de dependências entre serviços. Ele usa um modelo de empacotamento chamado Chart, que descreve todos os recursos Kubernetes necessários para executar uma aplicação. Com o Helm, você pode versionar sua infraestrutura, compartilhá-la com a equipe e até mesmo publicá-la em repositórios públicos ou privados.

O que é Helm

Helm é um projeto open-source que atua como gerenciador de pacotes para Kubernetes. Ele foi criado para resolver o problema de gerenciar múltiplos manifestos YAML, que muitas vezes são repetitivos e difíceis de manter. Com o Helm, você define uma aplicação completa em um pacote chamado chart, que contém todos os recursos necessários, como Deployments, Services, ConfigMaps, Secrets, etc. Depois de empacotado, você pode instalar, atualizar e desinstalar a aplicação com comandos simples.

O Helm funciona em duas partes principais: o cliente (helm) e o servidor (Tiller originalmente, mas desde a versão 3, o Tiller foi removido e o Helm usa diretamente a API do Kubernetes). Na versão 3, o Helm se tornou mais seguro e simples, pois não requer um componente extra no cluster. O cliente envia os charts para o cluster e gerencia o ciclo de vida dos releases (instalações).

Para instalar o Helm, você pode usar um script oficial ou gerenciadores de pacotes. Por exemplo, no macOS com Homebrew:

brew install helm

No Linux, você pode baixar o binário do site oficial ou usar o script:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

Após instalar, verifique a versão:

helm version

Charts

Um Chart é a unidade de empacotamento do Helm. Ele é uma coleção de arquivos que descrevem um conjunto relacionado de recursos Kubernetes. A estrutura básica de um chart é a seguinte:

mychart/
├── Chart.yaml
├── values.yaml
├── charts/
├── templates/
└── README.md
  • Chart.yaml: contém metadados sobre o chart, como nome, versão, descrição.
  • values.yaml: define valores padrão que podem ser sobrescritos pelo usuário.
  • templates/: contém arquivos de modelo que geram os manifestos Kubernetes.
  • charts/: pode conter dependências (sub-charts).

O Chart.yaml tem uma estrutura obrigatória. Exemplo:

apiVersion: v2
name: mychart
description: Um chart simples para demonstração
type: application
version: 0.1.0
appVersion: "1.0.0"

O values.yaml define parâmetros que podem ser personalizados. Por exemplo:

replicaCount: 1
image:
  repository: nginx
  tag: latest
service:
  type: ClusterIP
  port: 80

Para criar um novo chart, use o comando:

helm create mychart

Isso gera um esqueleto completo com exemplos. Você pode então editar os arquivos conforme necessário. Depois de pronto, você pode empacotar o chart:

helm package mychart

Isso cria um arquivo mychart-0.1.0.tgz, que pode ser distribuído e instalado em qualquer cluster.

Templates

Os templates são a parte mais poderosa do Helm. Eles permitem que você escreva manifestos Kubernetes parametrizados, usando a linguagem de templates do Go (o Helm usa a biblioteca text/template). Com templates, você pode gerar diferentes valores de configuração sem duplicar arquivos.

Um template típico para um Deployment se parece com:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name | default "mychart" }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Values.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}

Os valores entre {{ }} são expressões de template. Eles acessam os valores definidos em values.yaml ou podem ser passados via linha de comando com --set.

O Helm também oferece funções e pipelines para manipular valores, como default, quote, uppercase, etc. Por exemplo:

image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default "latest" }}"

Além disso, você pode usar estruturas de controle como if, with e range. Por exemplo, para incluir um Service apenas se habilitado:

{{- if .Values.service.enabled }}
apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.name }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
{{- end }}

Os templates são processados no momento da instalação, gerando os manifestos finais que são aplicados ao cluster. Isso permite que você crie charts altamente configuráveis e reutilizáveis.

Casos de uso

O Helm é amplamente utilizado em diversos cenários de DevOps. Aqui estão alguns casos de uso comuns:

1. Implantação de aplicações complexas

Aplicações modernas geralmente consistem em múltiplos serviços, bancos de dados, filas, etc. Com Helm, você pode empacotar todos esses componentes em um único chart, facilitando a instalação e o gerenciamento. Por exemplo, um chart para WordPress pode incluir o Deployment do WordPress, o Service, o PersistentVolumeClaim, e também um sub-chart para o MySQL.

2. Gerenciamento de múltiplos ambientes

Você pode usar os mesmos charts para diferentes ambientes (dev, staging, prod) alterando apenas os valores. Por exemplo, no ambiente de produção você pode aumentar o número de réplicas ou usar imagens específicas.

helm install myapp ./mychart -f values-prod.yaml

3. Versionamento e rollback

O Helm mantém um histórico de releases. Se uma atualização causar problemas, você pode facilmente reverter para uma versão anterior:

helm rollback myapp 1

4. Compartilhamento de infraestrutura como código

Charts podem ser versionados em Git e compartilhados via repositórios. Isso promove a infraestrutura como código e facilita a colaboração entre equipes.

5. Gerenciamento de dependências

Charts podem depender de outros charts. Por exemplo, um chart de aplicação pode depender de um chart de banco de dados. O Helm baixa e instala automaticamente as dependências.

Para usar um chart de um repositório remoto, você adiciona o repositório e instala:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install mydb bitnami/mongodb

Esses casos mostram como o Helm se tornou essencial no fluxo de trabalho DevOps, permitindo automação, reprodutibilidade e escalabilidade.

Boas práticas e observações finais

Ao trabalhar com Helm, considere as seguintes boas práticas:

  • Versionamento de charts: Sempre incremente a versão do chart quando houver mudanças.
  • Valores padrão: Forneça valores padrão seguros em values.yaml e documente as opções.
  • Testes: Use helm lint para validar a estrutura e helm template para simular a renderização.
  • Segurança: Evite colocar segredos em valores; use Secrets do Kubernetes ou ferramentas externas.
  • Dependências: Se usar sub-charts, mantenha-os atualizados e use versões específicas.

Em resumo, o Helm é uma ferramenta poderosa que transforma a maneira como gerenciamos aplicações no Kubernetes. Dominar seus conceitos é fundamental para qualquer profissional DevOps.

Referências

Exercícios

  1. Crie um chart simples chamado meu-app usando helm create e explique a estrutura gerada.
  2. Modifique o values.yaml do chart para definir um novo nome de imagem e tag, e renderize o template com helm template para ver o resultado.
  3. Instale o chart em um cluster Kubernetes (se disponível) ou use helm install --dry-run para simular. Qual é a saída?
  4. Adicione uma condição no template para incluir um Service apenas se uma variável service.enabled for verdadeira. Teste com --set service.enabled=true.
  5. Crie um chart que dependa de um chart externo (ex: bitnami/nginx) e instale-o com helm dependency update. Verifique se a dependência é baixada.

✓ Resposta: O comando helm create meu-app cria uma pasta meu-app com a estrutura padrão: Chart.yaml, values.yaml, templates/ (com exemplos como deployment.yaml, service.yaml, etc.), charts/ (vazio) e README.md. O Chart.yaml contém metadados, values.yaml define valores padrão, e os templates geram manifestos Kubernetes parametrizados.

✓ Resposta: Edite o values.yaml para alterar, por exemplo, image.repository para nginx e image.tag para 1.21. Depois execute helm template meu-app para renderizar os templates e ver os manifestos com os novos valores. A saída mostrará os YAMLs com a imagem nginx:1.21.

✓ Resposta: O comando helm install --dry-run meu-app ./meu-app simula a instalação sem aplicar ao cluster. A saída mostra os manifestos gerados e o status da release, mas nada é criado de fato. Se houver um cluster, helm install meu-app ./meu-app instala e retorna informações sobre a release.

✓ Resposta: No template templates/service.yaml, envolva o conteúdo com {{- if .Values.service.enabled }} ... {{- end }}. No values.yaml, adicione service.enabled: false. Para testar, execute helm template --set service.enabled=true e veja o Service no output; sem o set, ele não aparecerá.

✓ Resposta: Adicione em Chart.yaml a seção dependencies com o chart desejado, por exemplo: 
dependencies:
  - name: nginx
    version: "15.1.0"
    repository: "https://charts.bitnami.com/bitnami"
Depois execute helm dependency update para baixar o chart para a pasta charts/. Em seguida, helm install meu-app . instalará tanto o chart pai quanto a dependência.