Acesse o painel da sua conta

Não tem uma conta? Registrar

Entrar em contato

Visite também nosso site craftxp.com.br

  • img
  • img
  • img
  • img
  • img
  • img

Entre em contato

Helm: Gerenciamento de Pacotes Kubernetes na Prática

Helm: Gerenciamento de Pacotes Kubernetes na Prática

O que é o Helm?

Helm é o gerenciador de pacotes do Kubernetes — análogo ao apt para Debian ou ao Homebrew para macOS. Ele empacota recursos do Kubernetes (Deployments, Services, ConfigMaps, Secrets, Ingresses, etc.) em unidades reutilizáveis chamadas Charts. Com um único comando, é possível instalar aplicações complexas com dezenas de componentes, configurá-las via valores customizados e gerenciar seu ciclo de vida com versões e rollbacks.

Criado inicialmente pela Deis e hoje mantido pela CNCF (Cloud Native Computing Foundation) como um projeto graduado, o Helm se tornou o padrão de facto para distribuição de aplicações no ecossistema Kubernetes.

Arquitetura e Conceitos Fundamentais

O Helm introduz três conceitos essenciais que todo desenvolvedor precisa dominar:

  • Chart: Um pacote Helm contendo templates YAML, metadados (Chart.yaml), valores padrão (values.yaml) e dependências. Charts podem ser armazenados em repositórios públicos ou privados.
  • Release: Uma instância específica de um Chart implantada em um cluster Kubernetes. Cada release tem um nome único e mantém seu próprio histórico de revisões.
  • Repository: Um local HTTP(S) onde Charts são armazenados e versionados. O repositório oficial da comunidade é o Artifact Hub (artifacthub.io), que reúne milhares de Charts prontos para uso.

A arquitetura do Helm 3 (versão atual) eliminou o componente server-side Tiller, tornando a segurança mais simples: o cliente Helm interage diretamente com a API do Kubernetes usando suas credenciais do kubeconfig.

Instalação e Primeiros Passos

A instalação do Helm é direta e funciona nos principais sistemas operacionais:

# Linux (script oficial)
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# macOS (Homebrew)
brew install helm

# Windows (Chocolatey)
choco install kubernetes-helm

# Verificar instalação
helm version

Após instalar, adicione um repositório público e explore os Charts disponíveis:

# Adicionar o repositório Bitnami (um dos mais completos)
helm repo add bitnami https://charts.bitnami.com/bitnami

# Atualizar a lista de repositórios
helm repo update

# Buscar Charts disponíveis
helm search repo bitnami/nginx

# Listar repositórios configurados
helm repo list

Criando seu Primeiro Chart

Vamos criar um Chart do zero para entender a estrutura de diretórios:

helm create meu-app

# Estrutura gerada:
meu-app/
├── Chart.yaml          # Metadados (nome, versão, descrição)
├── values.yaml         # Valores padrão configuráveis
├── charts/             # Dependências (sub-charts)
├── templates/          # Templates YAML com Go templates
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── hpa.yaml
│   ├── serviceaccount.yaml
│   ├── _helpers.tpl    # Funções auxiliares reutilizáveis
│   └── tests/
└── .helmignore         # Arquivos a ignorar no empacotamento

O coração do Helm está nos templates Go. Eles permitem injetar valores dinamicamente nos arquivos YAML, tornando um mesmo Chart reutilizável para diferentes ambientes (dev, staging, produção).

Instalando e Gerenciando Releases

Com o Chart pronto, podemos instalar, atualizar e reverter releases facilmente:

# Instalar uma release
helm install meu-app-release ./meu-app --namespace meu-namespace --create-namespace

# Instalar com valores customizados (arquivo)
helm install meu-app-release ./meu-app -f producao-values.yaml

# Instalar com valores inline
helm install meu-app-release ./meu-app --set replicas=3 --set image.tag=2.0

# Listar releases
helm list -n meu-namespace

# Atualizar uma release existente
helm upgrade meu-app-release ./meu-app -f novos-values.yaml

# Ver histórico de revisões
helm history meu-app-release -n meu-namespace

# Rollback para revisão anterior
helm rollback meu-app-release 1 -n meu-namespace

O Helm mantém um histórico completo de cada atualização. Se algo der errado, o rollback restaura a configuração anterior em segundos — sem scripts complexos ou backups manuais.

Values, Dependências e Hooks: Recursos Avançados

Três recursos tornam o Helm extremamente poderoso em cenários reais:

1. Hierarquia de Valores

Os valores podem vir de múltiplas fontes com precedência bem definida: --set (maior prioridade) > -f (arquivo) > values.yaml (padrão) > valores padrão do template. Isso permite que um Chart base sirva múltiplos ambientes com sobreposições mínimas.

2. Dependências (Sub-charts)

Charts podem depender de outros Charts. Por exemplo, um Chart de aplicação web pode depender de um Chart de banco de dados Redis:

# Chart.yaml com dependências
dependencies:
  - name: redis
    version: "~17.0.0"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

3. Hooks

Hooks permitem executar ações em momentos específicos do ciclo de vida: pré-instalação (criar bancos), pós-instalação (rodar migrations), pré-deleção (backups), etc.

# templates/migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: "{{ .Release.Name }}-migration"
  annotations:
    "helm.sh/hook": post-install,post-upgrade
    "helm.sh/hook-weight": "5"
spec:
  template:
    spec:
      containers:
        - name: migration
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          command: ["bin/rails", "db:migrate"]

Helm no Fluxo CI/CD

Integrar Helm com pipelines CI/CD é uma prática essencial. Veja um exemplo com GitHub Actions:

# .github/workflows/deploy.yml
name: Deploy com Helm
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/setup-helm@v4
        with:
          version: v3.16.0
      - name: Deploy
        run: |
          helm upgrade --install meu-app-release ./charts/meu-app \
            --namespace production \
            --values ./config/producao.yaml \
            --set image.tag=${{ github.sha }} \
            --atomic \
            --timeout 5m \
            --wait

A flag --atomic garante que, se o deployment falhar, o Helm automaticamente executa rollback — essencial para deploys seguros em produção.

Boas Práticas e Padrões Recomendados

Após anos de adoção pela comunidade, algumas práticas se consolidaram:

  • Versionamento Semântico: Use SemVer para versionar Charts (Chart.yaml), não apenas a aplicação.
  • Values Bem Documentados: Cada chave em values.yaml deve ter um comentário explicando seu propósito, tipo e valor padrão.
  • Testes Integrados: Crie pods de teste em templates/tests/ que validem se a aplicação responde corretamente após a instalação.
  • Charts Pequenos e Focados: Prefira Charts atômicos (uma aplicação por Chart) a Charts monolíticos com múltiplos componentes acoplados.
  • Lint Automatizado: Inclua helm lint no pipeline para validar a estrutura e sintaxe dos Charts.
  • Valores por Ambiente: Mantenha arquivos separados (dev.yaml, staging.yaml, prod.yaml) em vez de sobrecarregar o values.yaml base.

Helm vs. Kustomize: Quando Usar Cada Um?

Uma dúvida comum é comparar Helm com Kustomize (nativo do kubectl). Ambos resolvem problemas diferentes:

  • Helm é ideal quando você precisa distribuir aplicações completas como pacotes — especialmente útil para softwares de terceiros (nginx ingress, Prometheus, Grafana, cert-manager). Charts funcionam como "Apps" prontos para instalar.
  • Kustomize é mais adequado para customizar manifests que você já mantém em seu repositório, usando patches e sobreposições sem modelos Go.

Na prática, muitas equipes usam ambos: Helm para dependências externas e Charts próprios distribuíveis, Kustomize para ajustes finos nos manifests da aplicação principal.

Conclusão

O Helm revolucionou a forma como empacotamos e distribuímos aplicações no Kubernetes. Com seu sistema de Charts, templates parametrizáveis e gerenciamento de releases com rollback nativo, ele se tornou uma ferramenta indispensável no dia a dia de times DevOps e SRE.

Se você trabalha com Kubernetes e ainda não adota o Helm, este é o momento de começar. A curva de aprendizado é curta — instale, crie um Chart simples e veja como o deployment de aplicações complexas se torna trivial. Em pouco tempo, você estará gerenciando stacks completas (aplicação + banco + cache + fila) com apenas alguns comandos helm install e helm upgrade.

Craft XP
Craft XP