Helm Charts no OpenShift: Guia Prático para DevOps

O OpenShift é uma plataforma de containers baseada em Kubernetes, projetada para simplificar o ciclo de vida de aplicações modernas. Embora o Kubernetes seja o padrão da indústria para orquestração de contêineres, gerenciar recursos como Deployment, Service e ConfigMap manualmente pode se tornar complexo e propenso a erros à medida que a infraestrutura escala. É aqui que entra o Helm.

O Helm funciona como o gerenciador de pacotes do Kubernetes, permitindo que você defina, instale e atualize aplicações complexas com comandos simples. Neste tutorial técnico completo, vamos explorar como integrar Helm Charts ao ambiente OpenShift, abordando desde a instalação da ferramenta até a criação de releases seguros e otimizados para o ecossistema Red Hat.

O que são Helm Charts e por que usá-los no OpenShift?

Um Helm Chart é uma coleção de arquivos YAML pré-configurados que descrevem uma instância relacionada do Kubernetes, como um conjunto de Pods ou serviços. Em vez de aplicar dezenas de arquivos YAML separados, você empacota tudo em um único chart e usa o comando helm install para implantá-lo.

No contexto do OpenShift, os benefícios são ainda mais pronunciados:

• Gerenciamento de Dependências: Charts podem depender de outros charts. O Helm resolve essas dependências automaticamente.
• Sincronização de Ambiente: Arquivos values.yaml</strong> permitem alterar configurações entre desenvolvimento, staging e produção sem modificar a estrutura do chart.</li><li><strong>Histórico de Mudanças:</strong> O Helm mantém o histórico de releases. Se uma atualização quebrar sua aplicação, você pode reverter para a versão anterior com um único comando.</li><li><strong>Segurança no OpenShift:</strong> O OpenShift impõe políticas de segurança rigorosas (como SELinux e SCCs - Security Context Constraints). Charts bem escritos podem ser configurados para respeitar essas restrições nativamente.</li></ul> <h2>Instalação do Helm CLI</h2> <p>Antes de começar, você precisa da linha de comando do Helm instalada em sua estação de trabalho ou no servidor CI/CD. O OpenShift não requer uma instalação específica do lado do servidor (Tiller) desde a versão 3.x do Helm, pois o gerenciamento é feito inteiramente pelo cliente.</p> <ol><li>Acesse o repositório oficial do Helm releases.</li><li>Baixe o binário compatível com seu sistema operacional (Linux, macOS ou Windows).</li></ol> <p>No Linux, o processo típico envolve baixar o arquivo tarball e extraí-lo:</p> <pre><code>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

  Verifique a instalação para garantir que a versão 3.x está ativa:

  helm version

  Configurando o Contexto do OpenShift

  O Helm precisa saber onde está o cluster Kubernetes. No OpenShift, isso é feito através do arquivo kubeconfig. Você pode obter as credenciais diretamente da interface web do OpenShift Console ou usando a CLI do OpenShift (oc).

  Se você ainda não possui o contexto configurado, execute:

  oc login --server=https://api.seu-cluster.com:6443 -u usuario -p senha

  O comando acima salva as credenciais e configura o kubectl (e por extensão, o helm) para apontar para o cluster correto. Para verificar se o Helm está conectado:

  helm list

  Se a lista retornar vazia ou sem erros de conexão, seu ambiente está pronto.

  Estrutura de um Helm Chart no OpenShift

  Para criar um chart personalizado para o OpenShift, é fundamental entender sua estrutura de diretórios. Vamos criar um chart básico chamado app-web.

  1. Crie a estrutura do diretório:

  helm create app-web

  O comando acima gera uma estrutura padrão. Para fins de tutorial, vamos focar nos arquivos essenciais que precisam ser modificados para o OpenShift:

  • Chart.yaml: Metadados do chart (nome, versão, descrição).
  • values.yaml: Valores padrão substituíveis.
  • templates/deployment.yaml: O manifesto Kubernetes que será renderizado.

  Adaptando o Deployment para OpenShift

  O maior desafio ao usar Helm no OpenShift é garantir que as imagens e permissões estejam em conformidade com as Security Context Constraints (SCCs). Por padrão, o OpenShift não permite que containers rodem como root (uid: 0).

  No arquivo templates/deployment.yaml, você deve garantir que o securityContext esteja configurado corretamente. Abaixo está um exemplo prático de como estruturar o deployment para aceitar variáveis do values.yaml.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: {{ .Release.Name }}-deployment
    labels:
      app: {{ .Release.Name }}
  spec:
    replicas: {{ .Values.replicaCount }}
    selector:
      matchLabels:
        app: {{ .Release.Name }}
    template:
      metadata:
        labels:
          app: {{ .Release.Name }}
      spec:
        containers:
          - name: {{ .Chart.Name }}
            image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
            imagePullPolicy: {{ .Values.image.pullPolicy }}
            ports:
              - containerPort: 8080
            securityContext:
              runAsNonRoot: true
              # O OpenShift injeta automaticamente um UID aleatório se você não especificar,
              # mas é boa prática declarar a intenção.
              capabilities:
                drop:
                  - ALL

  No arquivo values.yaml, defina os valores padrão:

  replicaCount: 2
  
  image:
    repository: registry.redhat.io/rhscl/nodejs-14-rhel7
    tag: latest
    pullPolicy: IfNotPresent

  Integração com ImageStreams do OpenShift

  Uma vantagem específica do OpenShift é o uso de ImageStreams. Em vez de apontar para uma URL externa de imagem (como Docker Hub), você pode usar um ImageStream local para gerenciar tags e builds internos.

  No arquivo values.yaml, altere a configuração da imagem para usar o ImageStream:

  image:
    repository: imagestream/nome-do-imagestream
    tag: latest
    pullPolicy: Always

  O Helm substituirá essas variáveis no template, e o OpenShift resolverá a referência internamente. Isso melhora a segurança e a velocidade de deploy em clusters internos.

  Instalando e Gerenciando Releases

  Agora que temos nosso chart preparado, vamos implantá-lo no cluster OpenShift.

  1. Instalação Básica

  helm install minha-app ./app-web -n meu-projeto

  O flag -n meu-projeto especifica o namespace do OpenShift onde os recursos serão criados. Se omitido, o Helm usará o namespace padrão configurado no contexto.

  2. Verificando o Status

  Para monitorar se o deployment foi aceito e as pods estão rodando:

  helm status minha-app -n meu-projeto

  O comando retornará informações detalhadas, incluindo o nome dos pods criados, o IP interno e o estado do container.

  3. Atualização de Versões (Rolling Update)

  No DevOps, a capacidade de atualizar aplicações sem downtime é crucial. Se você alterar a tag da imagem no values.yaml ou modificar o código do chart:

  1. Atualize o arquivo values.yaml com a nova versão.
  2. Rode o upgrade:

  helm upgrade minha-app ./app-web -n meu-projeto --set image.tag=v2.0

  O OpenShift realizará um rolling update, terminando os pods antigos gradualmente enquanto inicia os novos, garantindo disponibilidade contínua.

  4. Rollback

  Se a nova versão apresentar falhas, o Helm mantém o histórico. Para reverter:

  helm rollback minha-app 1 -n meu-projeto

  O número 1 refere-se à revisão (revision) do release anterior. O sistema volta exatamente para o estado daquela versão.

  Boas Práticas e Segurança no OpenShift

  Ao desenvolver Helm Charts para ambientes de produção no OpenShift, considere as seguintes diretrizes técnicas:

  • Não use Root: Como mencionado, evite runAsUser: 0. Use o UID injetado pelo OpenShift ou defina um UID não privilegiado.
  • Use ConfigMaps para Secrets: Nunca armazene senhas em texto claro no values.yaml. Utilize o comando helm create com flags de secreção ou integre-se ao HashiCorp Vault/External Secrets Operator.
  • Liveness e Readiness Probes: Configure verificações de saúde no template. O OpenShift depende disso para saber quando rotear tráfego para o pod.

  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
    initialDelaySeconds: 30
    periodSeconds: 10

  Usando Helm Repositórios Públicos e Locais

  Não é necessário criar todos os charts do zero. O OpenShift e a comunidade Kubernetes oferecem repositórios ricos.

  1. Adicionar um repositório: Por exemplo, adicionar o repositório oficial do Bitnami ou da Red Hat.

  helm repo add bitnami https://charts.bitnami.com/bitnami
  helm repo update

  1. Pesquisar e Instalar:

  helm search repo bitnami/postgresql

  Isso permite que você instale bancos de dados, filas (RabbitMQ) ou caches (Redis) já otimizados para Kubernetes. No entanto, sempre audite os templates desses charts para garantir compatibilidade com as SCCs do seu OpenShift específico.

  Conclusão

  O Helm é uma ferramenta indispensável para profissionais de DevOps e SREs que trabalham com OpenShift. Ele transforma o gerenciamento de contêineres de uma tarefa manual e frágil em um processo automatizado, versionado e seguro.

  Ao combinar a flexibilidade dos Helm Charts com as robustas ferramentas nativas do OpenShift (como ImageStreams e SCCs), você cria uma infraestrutura ágil e confiável. Lembre-se sempre de testar seus charts em um namespace de desenvolvimento antes de promovê-los para produção, validando não apenas a funcionalidade da aplicação, mas também a conformidade com as políticas de segurança do cluster.

  Agora que você domina os conceitos básicos, experimente containerizar sua primeira aplicação monolítica e empacotá-la em um Helm Chart personalizado. A maturidade DevOps começa com a padronização.