Blue-Green e Rollbacks

Toda implantação no sh0 usa uma estratégia blue-green para lançamentos sem tempo de inatividade. Se algo der errado, reverta para qualquer versão anterior instantaneamente.

Implantações Blue-Green

Implantação blue-green é uma estratégia de lançamento que elimina o tempo de inatividade ao executar dois ambientes idênticos em paralelo. A qualquer momento, um ambiente (blue) serve o tráfego ao vivo enquanto o outro (green) está ocioso ou sendo atualizado com a nova versão.

Quando você implanta uma nova versão, o sh0 inicia o novo contêiner ao lado do atual. Uma vez que o novo contêiner passe nos health checks, o tráfego é instantaneamente trocado do contêiner antigo para o novo. O contêiner antigo é mantido em execução brevemente como fallback antes de ser desligado.

Como o sh0 Implementa

Aqui está o processo passo a passo que o sh0 segue para cada implantação:

1. Build: A nova imagem Docker é construída a partir do seu código-fonte ou puxada de um registro
2. Iniciar contêiner green: Um novo contêiner é iniciado com a imagem atualizada, conectado à mesma rede e volumes do contêiner atual
3. Health check: O sh0 executa health checks no novo contêiner (endpoint HTTP, porta TCP ou comando personalizado)
4. Executar hooks de pré-deploy: Se configurados, hooks de pré-deploy são executados no novo contêiner (ex.: migrações de banco de dados)
5. Troca de tráfego: A configuração do proxy reverso do Caddy é atualizada para rotear todo o tráfego para o novo contêiner
6. Executar hooks de pós-deploy: Hooks de pós-deploy são executados (ex.: limpeza de cache, notificações)
7. Drenar contêiner antigo: O contêiner antigo recebe um período de graça (padrão: 30 segundos) para finalizar requisições em andamento
8. Parar contêiner antigo: O contêiner antigo é parado e removido

A troca de tráfego acontece no nível do proxy reverso (Caddy), o que significa que é instantânea. Não há intervalo entre parar o contêiner antigo e iniciar o novo -- ambos rodam simultaneamente durante a transição.

Implantações sem Tempo de Inatividade

Como o contêiner antigo continua servindo tráfego até o novo ser verificado como saudável, seus usuários nunca experimentam tempo de inatividade durante implantações. A transição é transparente:

• Sem erros 502 durante a implantação
• Sem conexões perdidas ou requisições descartadas
• Sem necessidade de janelas de manutenção
• Conexões WebSocket no contêiner antigo são finalizadas naturalmente

Health Checks

Health checks são fundamentais para implantações sem tempo de inatividade. O sh0 suporta três tipos de health checks:

{
  "healthcheck": {
    "type": "http",
    "path": "/health",
    "interval": 10,
    "timeout": 5,
    "retries": 3,
    "start_period": 30
  }
}

Histórico de Implantação

O sh0 mantém um histórico completo de cada implantação para cada aplicação. O histórico de implantação inclui:

• Status da implantação (sucesso, falha, revertida)
• SHA e mensagem do commit Git
• Tag e digest da imagem Docker
• Duração do build e da implantação
• Quem acionou a implantação (usuário, webhook ou API)
• Log completo do build

Clique em qualquer implantação para ver o log completo do build, resultados de execução de hooks e saída do health check. A implantação atualmente ativa é destacada na lista.

Rollback com Um Clique

Se uma implantação introduz um bug ou problema de performance, você pode reverter para qualquer versão anterior no histórico de implantação. Clique no botão Rollback ao lado de qualquer implantação bem-sucedida anterior para reimplantar instantaneamente aquela versão.

Um rollback segue o mesmo processo blue-green de uma implantação regular: a imagem Docker da versão antiga é usada para iniciar um novo contêiner, health checks são executados e o tráfego é trocado. Isso significa que rollbacks também são sem tempo de inatividade.

Rollback via API

Você também pode acionar rollbacks programaticamente usando a API do sh0. Isso é útil para rollbacks automatizados acionados por sistemas de monitoramento.

# Rollback to a specific deployment ID
curl -X POST https://your-sh0-server.com:9000/api/apps/{app_id}/rollback \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"deploy_id": "deploy_abc123"}'

# Rollback to the immediately previous version
curl -X POST https://your-sh0-server.com:9000/api/apps/{app_id}/rollback \
  -H "Authorization: Bearer YOUR_TOKEN"

Quando nenhum deploy_id é especificado, o sh0 reverte para a implantação bem-sucedida mais recente antes da atual.

Comportamento do Rollback

Detalhes importantes sobre como rollbacks funcionam:

• Apenas código: Rollbacks revertem o código da aplicação (imagem Docker) mas não revertem alterações no banco de dados. Se sua implantação incluiu uma migração de banco de dados, pode ser necessário escrever uma migração reversa manualmente.
• Variáveis de ambiente: Rollbacks usam as variáveis de ambiente atuais, não as variáveis do momento da implantação original. Isso garante que segredos e configurações atualizados permaneçam em vigor.
• Hooks executam: Hooks de pré-deploy e pós-deploy são executados durante um rollback, assim como seriam durante uma implantação regular.
• Entrada no histórico: Rollbacks criam uma nova entrada no histórico de implantação com um rótulo "rollback", mostrando qual implantação foi restaurada.