ConfigMaps for Application Configuration

O que é um ConfigMap?

Um ConfigMap é um objeto da API do Kubernetes usado para armazenar dados de configuração não confidenciais em pares chave-valor. Pense nele como um local centralizado no seu cluster para guardar variáveis de ambiente, argumentos de linha de comando ou até mesmo arquivos de configuração inteiros que seus Pods podem usar no momento da execução.

A principal vantagem é o desacoplamento: sua imagem de contêiner pode ser genérica e agnóstica ao ambiente, enquanto a configuração específica é injetada pelo Kubernetes dependendo de onde o Pod está sendo executado.

Criando e Inspecionando um ConfigMap

Como outros objetos do Kubernetes, os ConfigMaps são tipicamente definidos declarativamente usando um manifesto YAML.

A estrutura é simples:

• apiVersion: v1
• kind: ConfigMap
• metadata: Contém o nome do ConfigMap.
• data: Um dicionário onde cada entrada é um par chave-valor. O valor é sempre uma string.

Vamos criar um ConfigMap simples para uma aplicação hipotética.

1. Crie o arquivo app-configmap.yaml:

   # app-configmap.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: my-app-config
   data:
     # Configuração como pares chave-valor simples
     LOG_LEVEL: "info"
     API_URL: "http://my-api-service.default.svc.cluster.local"
   
     # Configuração como um arquivo de propriedades inteiro
     app.properties: |
       feature.flag.new.ui=true
       cache.size=256
       database.pool.size=10
   

   Note o uso do caractere pipe (|) para app.properties. Isso permite que você insira um bloco de texto de várias linhas como o valor de uma única chave, o que é extremamente útil para arquivos de configuração inteiros.

2. Aplique o manifesto ao seu cluster:

   kubectl apply -f app-configmap.yaml
   

3. Inspecione o ConfigMap:

   Você pode verificar se o ConfigMap foi criado e ver seu conteúdo.

   # Listar todos os ConfigMaps
   kubectl get configmaps
   
   # Descrever o ConfigMap específico para ver suas chaves e valores
   kubectl describe configmap my-app-config
   

Consumindo Dados do ConfigMap em Pods

Agora que nosso ConfigMap existe no cluster, como fazemos para que nossa aplicação o utilize? Existem duas maneiras principais de injetar esses dados em um Pod.

Método 1: Como Variáveis de Ambiente

Esta é a abordagem mais direta. Você pode mapear chaves do ConfigMap diretamente para variáveis de ambiente dentro do seu contêiner.

Aqui está um exemplo de manifesto de Deployment que consome nosso my-app-config:

# nginx-deployment-with-env.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        env:
          # Injetando uma única chave do ConfigMap
          - name: NGINX_LOG_LEVEL
            valueFrom:
              configMapKeyRef:
                name: my-app-config  # Nome do ConfigMap
                key: LOG_LEVEL      # Chave a ser usada

        # Injetando todas as chaves do ConfigMap como variáveis de ambiente
        envFrom:
          - configMapRef:
              name: my-app-config

Método 2: Como Arquivos em um Volume

Para configurações maiores, como o app.properties que criamos, ou quando você não quer depender de variáveis de ambiente, a melhor abordagem é montar o ConfigMap como um volume. Quando você faz isso, cada chave no campo data do ConfigMap se torna um arquivo no diretório montado, e o conteúdo do arquivo é o valor da chave.

Isso é análogo a montar um diretório do host em um contêiner com docker run -v, um conceito com o qual você já deve estar familiarizado.

Vamos adaptar nosso Deployment para usar este método:

# nginx-deployment-with-volume.yaml
apiVersion: apps/v1
kind: Deployment
# ... metadata, spec.replicas, spec.selector ...
  template:
    # ... metadata ...
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: app-config-volume   # Nome do volume a ser montado
          mountPath: /etc/config   # Diretório dentro do contêiner
      
      # Define o volume
      volumes:
      - name: app-config-volume      # Deve corresponder ao nome em volumeMounts
        configMap:
          name: my-app-config      # O nome do ConfigMap a ser usado

Se você aplicar este manifesto e executar kubectl exec para entrar no Pod, encontrará os seguintes arquivos em /etc/config: LOG_LEVEL, API_URL e app.properties, cada um contendo o valor correspondente.

Atualizações de ConfigMap: O Ponto Crucial

Aqui está uma das partes mais importantes e que muitas vezes causa confusão: o que acontece quando você atualiza um ConfigMap que já está em uso? A resposta depende de como ele está sendo consumido.

Resumindo a demonstração do vídeo:

• Variáveis de Ambiente: São imutáveis. Elas são injetadas no contêiner no momento em que ele é criado. Alterações posteriores no ConfigMap não serão refletidas nos Pods em execução. Você precisaria reiniciar os Pods para que eles peguem os novos valores.
• Volumes Montados: São dinâmicos. O Kubernetes atualiza periodicamente os arquivos montados quando o ConfigMap associado muda. Há um pequeno atraso (geralmente até um minuto), mas as alterações são propagadas para os Pods em execução sem a necessidade de reiniciá-los.

Aplicação Prática: Hot-Reloading em .NET

Apenas porque o Kubernetes atualiza o arquivo no disco, não significa que sua aplicação .NET irá automaticamente recarregar a configuração. Dado seu background em .NET, vamos ver como conectar essas duas peças.

O IConfiguration do .NET tem mecanismos para observar mudanças em arquivos, mas há um detalhe importante ao trabalhar com volumes de ConfigMap do Kubernetes.

Os passos essenciais para habilitar o "hot-reloading" em sua aplicação .NET são:

1. Montar o ConfigMap como um volume no seu manifesto de Deployment (como vimos no Método 2).
2. No Program.cs da sua aplicação, usar o provedor de configuração AddKeyPerFile:

   builder.Configuration.AddKeyPerFile("/etc/config", optional: true, reloadOnChange: true);
   

   Isso instrui o .NET a carregar cada arquivo no diretório /etc/config como uma chave de configuração e a observar mudanças.
3. Adicionar a seguinte variável de ambiente ao manifesto do seu contêiner:

   env:
     - name: DOTNET_USE_POLLING_FILE_WATCHER
       value: "true"
   

   Isso é necessário porque o Kubernetes usa symlinks para atualizar os arquivos do ConfigMap, e o observador de arquivos padrão do .NET pode não detectar essas alterações de forma confiável. O modo de "polling" garante que o .NET verifique ativamente os arquivos em intervalos regulares, capturando as atualizações feitas pelo Kubernetes.

Conclusão

Parabéns! Você aprendeu a separar a configuração do código da sua aplicação usando ConfigMaps, um passo crucial para construir aplicações robustas e portáteis no Kubernetes.

Principais Pontos:

• ConfigMaps desacoplam a configuração: Eles permitem que você gerencie configurações não confidenciais externamente à sua imagem de contêiner.
• Dois métodos de consumo: Você pode injetar dados como variáveis de ambiente ou como arquivos em um volume.
• O comportamento de atualização é a chave: Variáveis de ambiente são estáticas e exigem um reinício do Pod para serem atualizadas. Volumes montados são dinâmicos e se atualizam automaticamente.
• Para hot-reloading em .NET: Use a montagem de volume, AddKeyPerFile com reloadOnChange: true, e a variável de ambiente DOTNET_USE_POLLING_FILE_WATCHER.

Próxima Lição:
Nós enfatizamos que ConfigMaps são para dados não confidenciais. Mas e quanto a senhas de banco de dados, chaves de API e certificados TLS? Armazená-los em texto plano em um ConfigMap é uma péssima prática de segurança. Na próxima lição, "Gerenciar dados sensíveis usando Secrets", veremos a solução do Kubernetes para este problema.