Estratégias de implantação com tempo de inatividade zero: mantenha seu aplicativo em execução durante as atualizações

O tempo de inatividade planejado custa às empresas uma média de US$ 5.600 por minuto. Mesmo assim, 43% das empresas ainda colocam seus aplicativos off-line durante as implantações. A implantação com tempo de inatividade zero não é um luxo – é uma expectativa. Clientes, mecanismos de pesquisa e parceiros de integração penalizam os aplicativos que ficam off-line, mesmo que por pouco tempo.

Este guia aborda as três principais estratégias de implantação com tempo de inatividade zero, técnicas de migração de banco de dados que preservam o tempo de atividade e mecanismos de reversão automatizados.

Principais conclusões

• A implantação azul-verde é a estratégia mais segura: reversão instantânea ao retornar o tráfego para a versão anterior
• As migrações de banco de dados devem ser compatíveis com versões anteriores --- a versão antiga do aplicativo deve funcionar com o novo esquema
• Verificações de integridade e sondagens de prontidão evitam o roteamento do tráfego para pods que não estão prontos para veiculação
• A reversão automatizada baseada no monitoramento da taxa de erros reduz o tempo médio de recuperação para menos de 2 minutos

---

Comparação de estratégias

---

Implantação Azul-Verde

Arquitetura

Load Balancer
    |
    |--- [ACTIVE] Blue environment (v2.0.0) <-- receives 100% traffic
    |
    |--- [IDLE] Green environment (v2.1.0) <-- deployed, tested, waiting

Na implantação:

1. Implante a v2.1.0 no ambiente inativo (verde)
2. Execute testes de fumaça contra o verde
3. Mude o balanceador de carga para verde
4. Azul fica ocioso (disponível para reversão instantânea)

Implementação com Nginx

# /etc/nginx/conf.d/app.conf
upstream blue {
    server 10.0.1.10:3000;
    server 10.0.1.11:3000;
}

upstream green {
    server 10.0.2.10:3000;
    server 10.0.2.11:3000;
}

# Active environment - change this during deployment
map $host $active_upstream {
    default blue;  # Change to 'green' to switch
}

server {
    listen 443 ssl;
    server_name app.example.com;

    location / {
        proxy_pass http://$active_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Script de implantação

#!/bin/bash
set -e

CURRENT=$(cat /etc/nginx/active-env)  # "blue" or "green"
TARGET=$( [ "$CURRENT" = "blue" ] && echo "green" || echo "blue" )

echo "Current: $CURRENT, deploying to: $TARGET"

# Deploy to inactive environment
ssh "deploy@$TARGET-1" "cd /opt/app && git pull && pnpm install --frozen-lockfile && pnpm build && pm2 restart all"
ssh "deploy@$TARGET-2" "cd /opt/app && git pull && pnpm install --frozen-lockfile && pnpm build && pm2 restart all"

# Wait for health checks
for i in 1 2; do
  echo "Checking $TARGET-$i health..."
  for attempt in $(seq 1 30); do
    if curl -sf "http://$TARGET-$i:3000/health" > /dev/null; then
      echo "$TARGET-$i is healthy"
      break
    fi
    sleep 2
  done
done

# Run smoke tests
pnpm test:smoke --base-url "http://$TARGET-1:3000"

# Switch traffic
sed -i "s/default $CURRENT/default $TARGET/" /etc/nginx/conf.d/app.conf
nginx -s reload
echo "$TARGET" > /etc/nginx/active-env

echo "Traffic switched to $TARGET. Rollback: change active-env back to $CURRENT"

---

Atualização contínua

As atualizações contínuas substituem as instâncias de forma incremental, garantindo que alguma capacidade esteja sempre disponível.

Atualização contínua do Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Create 1 extra pod during update
      maxUnavailable: 0   # Never reduce below desired replicas
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 3001
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 3001
            initialDelaySeconds: 15
            periodSeconds: 10

O processo de atualização contínua com maxSurge: 1 e maxUnavailable: 0:

1. Crie 1 novo pod com v2.1.0 (6 pods no total: 5 antigos + 1 novo)
2. Aguarde a aprovação da nova sondagem de prontidão do pod
3. Encerre 1 pod antigo (5 pods: 4 antigos + 1 novo)
4. Crie outro novo pod (6 pods: 4 antigos + 2 novos)
5. Repita até que todos os pods sejam v2.1.0

---

Implantação Canário

Divisão de tráfego

# Istio VirtualService for canary routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-canary
spec:
  hosts:
    - api.example.com
  http:
    - route:
        - destination:
            host: api-stable
            port:
              number: 3001
          weight: 95
        - destination:
            host: api-canary
            port:
              number: 3001
          weight: 5

Lançamento Canário Progressivo

---

Migrações de banco de dados sem tempo de inatividade

O maior desafio na implantação com tempo de inatividade zero são as alterações no esquema do banco de dados. A versão antiga do aplicativo deve funcionar com o novo esquema e vice-versa.

O padrão de expansão-contrato

Fase 1: Expandir (implantar alteração de esquema)

-- Add new column (nullable, no default)
ALTER TABLE orders ADD COLUMN shipping_method VARCHAR(50);

O código antigo do aplicativo ignora a nova coluna. O novo código do aplicativo grava nas colunas novas e antigas.

Fase 2: Migrar dados

-- Backfill existing data
UPDATE orders SET shipping_method = 'standard' WHERE shipping_method IS NULL;

Fase 3: Contrato (implantar código que usa exclusivamente nova coluna)

Depois que todas as instâncias do aplicativo usarem a nova coluna:

-- Make column required
ALTER TABLE orders ALTER COLUMN shipping_method SET NOT NULL;
ALTER TABLE orders ALTER COLUMN shipping_method SET DEFAULT 'standard';

Padrões de migração perigosos

---

Reversão automatizada

Reversão baseada na taxa de erros

#!/bin/bash
# post-deploy-monitor.sh

DEPLOY_TIME=$(date +%s)
MONITOR_DURATION=300  # 5 minutes
ERROR_THRESHOLD=0.02  # 2%

while [ $(($(date +%s) - DEPLOY_TIME)) -lt $MONITOR_DURATION ]; do
  ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_requests_total{status=~'5..'}[2m])/rate(http_requests_total[2m])" | jq -r '.data.result[0].value[1]')

  if (( $(echo "$ERROR_RATE > $ERROR_THRESHOLD" | bc -l) )); then
    echo "ERROR: Rate $ERROR_RATE exceeds threshold $ERROR_THRESHOLD"
    echo "Initiating rollback..."
    kubectl rollout undo deployment/api
    exit 1
  fi

  sleep 15
done

echo "Deployment healthy for $MONITOR_DURATION seconds"

---

Perguntas frequentes

Com qual estratégia devemos começar?

Comece com a implantação azul esverdeada. É o mais simples de implementar, fornece reversão instantânea e funciona com qualquer arquitetura de aplicativo. As atualizações graduais são melhores para ambientes Kubernetes com muitas réplicas. As implantações Canary são para aplicativos de alto tráfego onde você deseja validar as alterações com tráfego real antes da implementação completa.

Como lidamos com trabalhos em segundo plano de longa duração durante a implantação?

Use o desligamento normal. Quando um pod receber um sinal de encerramento, pare de aceitar novos trabalhos, termine os trabalhos em andamento (com um tempo limite) e desligue-o. No Kubernetes, configure terminationGracePeriodSeconds para permitir tempo suficiente para a conclusão dos trabalhos. Para trabalhos que demoram mais do que o período de carência, use uma fila de trabalhos (Redis, RabbitMQ) que tenta novamente trabalhos com falha em trabalhadores sobreviventes.

E as conexões WebSocket durante a implantação?

As conexões WebSocket duram muito e devem ser tratadas com cuidado. Durante uma atualização contínua, as conexões existentes no pod antigo permanecem ativas até que o pod seja encerrado. Os clientes devem implementar uma lógica de reconexão automática. Para implantações azul-verde, alterne novas conexões para o novo ambiente enquanto permite que as conexões existentes sejam drenadas no ambiente antigo com um tempo limite.

Como testamos implantações com tempo de inatividade zero?

Execute um teste de carga durante a implantação. Use k6 ou uma ferramenta semelhante para gerar tráfego contínuo e, em seguida, acione uma implantação. Verifique se há erros, aumento de latência ou queda de conexões durante a substituição. Consulte nosso guia de teste de carga para obter detalhes de implementação.

---

O que vem a seguir

A implantação com tempo de inatividade zero é um pré-requisito para lançamentos frequentes e confiáveis. Combine-o com automação CI/CD para o pipeline de implantação completo e monitoramento para verificação pós-implantação.

Entre em contato com a ECOSIRE para obter consultoria de estratégia de implantação ou explore nosso guia DevOps para obter o roteiro completo de infraestrutura.

---

Publicado pela ECOSIRE – ajudando as empresas a implantar sem interrupções.