Como criar um Blue/Green Deploy em Kubernetes com GitHub Actions

Este tutorial explica como criar um Blue/Green deploy em Kubernetes com GitHub Actions — uma estratégia útil para reduzir tempo de indisponibilidade, validar novas versões em produção e permitir rollback rápido. Vai ver porque o padrão Blue/Green é prático e um exemplo simples para implementar com manifests e um workflow CI/CD.

Pré-requisitos

• Conta GitHub com repositório e GitHub Actions ativado
• Cluster Kubernetes acessível (minikube, kind ou AKS) e kubectl configurado
• Imagem Docker pública ou registada (ex.: myrepo/myapp:latest)
• Familiaridade básica com Kubernetes Deployments e Services

Passo 1: Entender o padrão Blue/Green

Blue/Green significa ter duas versões concorrentes da aplicação: "blue" (atual) e "green" (nova). O tráfego é comutado mudando o selector do Service ou alterando um ingress. Isto permite testar a versão green em produção sem remover a blue e voltar atrás rapidamente.

Passo 2: Estruturar os manifests Kubernetes

Vamos criar dois Deployments (app-blue e app-green) e um Service que aponta para uma label comum (app: myapp) mas cujo selector decide qual versão recebe o tráfego. No exemplo o Service usa label track: blue ou track: green.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      track: blue
  template:
    metadata:
      labels:
        app: myapp
        track: blue
    spec:
      containers:
      - name: app
        image: myrepo/myapp:stable
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      track: green
  template:
    metadata:
      labels:
        app: myapp
        track: green
    spec:
      containers:
      - name: app
        image: myrepo/myapp:canary
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: myapp
    track: blue

Passo 3: Testar localmente no cluster

Aplica os manifests e confirma que o Service aponta para o deployment blue. Valida através de kubectl e, se usar minikube, aceda ao serviço para ver a página da aplicação.

# aplicar manifests
kubectl apply -f k8s/blue-green.yaml
# ver pods e service
kubectl get deployments,pods,svc -l app=myapp
# testar endpoint (exemplo minikube)
minikube service myapp-service --url

Passo 4: Criar workflow GitHub Actions para deploy controlado

O workflow faz build da imagem, faz push e actualiza o Deployment green. Depois executa um passo para comutar o Service de blue para green. Separar passos permite validar a versão antes do cutover.

name: CI CD BlueGreen
on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: Build and push image
      run: |
        IMAGE=myrepo/myapp:${{ github.sha }}
        docker build -t $IMAGE .
        echo "$IMAGE"
        docker push $IMAGE
      env:
        DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_HUB_USERNAME }}
        DOCKER_HUB_PASSWORD: ${{ secrets.DOCKER_HUB_PASSWORD }}

    - name: Update green Deployment image
      run: |
        kubectl set image deployment/app-green app=$IMAGE --record
      env:
        KUBECONFIG: ${{ secrets.KUBECONFIG }}

    - name: Smoke tests on green
      run: |
        # Exemplo simples: verificar pods prontos
        kubectl rollout status deployment/app-green --timeout=60s
        kubectl get pods -l track=green
      env:
        KUBECONFIG: ${{ secrets.KUBECONFIG }}

    - name: Switch Service to green (cutover)
      if: success()
      run: |
        kubectl patch service myapp-service -p '{"spec":{"selector":{"app":"myapp","track":"green"}}}'
      env:
        KUBECONFIG: ${{ secrets.KUBECONFIG }}

Passo 5: Estratégias de rollback e limpeza

Se algo correr mal depois do cutover, volte a apontar o Service para track: blue. Pode automatizar rollback se os smoke tests falharem ou usar monitorização para detetar erros. Depois de estável, pode escalar para baixo o deployment blue ou removê-lo.

# rollback manual (apontar de volta para blue)
kubectl patch service myapp-service -p '{"spec":{"selector":{"app":"myapp","track":"blue"}}}'
# remover a versão antiga quando confirmado
kubectl delete deployment app-blue

Verificar o resultado

Confirme que o Service serve a nova versão: faça uma requisição ao endpoint e valide headers, versão ou conteúdo. Use kubectl get svc e kubectl get pods -l track=green para verificar que o tráfego está na green. Monitorize logs para erros e valide métricas.

Conclusão

Implementar Blue/Green deploy em Kubernetes com GitHub Actions reduz risco e facilita rollback. Próximos passos: adicionar health checks, automatizar verificação de desempenho e integrar monitorização (Prometheus/Alertmanager). Dica: comece com minikube ou kind para experimentar antes de aplicar em produção — qual é o próximo serviço que quer lançar com Blue/Green?