Migrar de NGINX para Webship sem um corte cego.

Defina o limite da migração antes de alterar o tráfego.

Comece movendo apenas o comportamento Webship que pode ser reproduzido e validado. Deixe a autenticação do aplicativo, a descoberta de serviços, os scripts e as regras especializadas de cache na origem existente até que suas substituições passem nos testes em ambiente semelhante à produção.

Traduza primeiro o menor caminho de produção.

O fragmento de origem identifica o conceito de migração; o fragmento Webship mostra a forma alvo. Substitua domínios, endereços, certificados, limites e caminhos de saúde de exemplo por valores validados para seu ambiente.

upstream app {
  server 127.0.0.1:8080;
  server 127.0.0.1:8081;
}
server {
  listen 443 ssl http2;
  server_name app.example.com;
  location / { proxy_pass http://app; }
}

listen = "0.0.0.0:443"
workers = 4

[reverse_proxy]
enabled = true
tls_termination = true
connect_timeout_ms = 2000
max_retries = 0

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/letsencrypt/live/app.example.com/fullchain.pem"
key = "/etc/letsencrypt/live/app.example.com/privkey.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["127.0.0.1:8080", "127.0.0.1:8081"]
load_balancing = "weighted-peak-ewma"

[[reverse_proxy.upstreams]]
address = "127.0.0.1:8080"
protocol = "http1"
health_check_path = "/health"
health_check_interval_ms = 5000
health_check_timeout_ms = 1000

[[reverse_proxy.upstreams]]
address = "127.0.0.1:8081"
protocol = "http1"
health_check_path = "/health"
health_check_interval_ms = 5000
health_check_timeout_ms = 1000

[[reverse_proxy.policies]]
name = "default"
hosts = []
path_prefixes = ["/"]
methods = []
max_body_bytes = 1048576
total_timeout_ms = 30000

Mapear conceitos, não sintaxe.

Diretivas técnicas nem sempre correspondem um a um. Use esta tabela para localizar a área de configuração equivalente de Webship, depois valide a configuração efetiva e o comportamento em tempo de execução.

Use uma transição de cinco etapas reversível.

Mantenha o ouvinte antigo pronto até que Webship tenha passado pelos critérios de correção, capacidade, segurança, observabilidade e reversão em tráfego representativo.

1. 1

   Comportamento observável de inventário

   Registre listeners, domínios, rotas, upstreams, certificados, reescritas, autenticação, regras de cache, sondas de saúde, limites e integrações operacionais.

2. 2

   Translatar um limite

   Mova um host ou rota para o TOML estrito. Retenha módulos específicos do fornecedor e a lógica de aplicação atrás do Webship até que substituições separadas sejam comprovadas.

3. 3

   Validar offline e localmente

   Execute --check-config e --print-effective-config, inspecione o resultado oculto, verifique a saúde localmente e utilize TLS tanto sobre TCP quanto UDP quando HTTP/3 estiver habilitado.

4. 4

   Tráfego real canário

   Envie uma pequena fatia de tráfego observável para Webship. Compare códigos de status, cabeçalhos, corpos, latência, saúde upstream, comportamento de cache, logs e decisões de segurança.

5. 5

   Promover com rollback pronto

   Aumente o tráfego nos estágios medidos. Mantenha o alvo anterior saudável e imediatamente roteável até que a janela de observação acordada e os controles de carga sejam ultrapassados.

Valide primeiro. Faça rollback roteando, não editando ao vivo.

Valide o arquivo do candidato, inspecione a configuração efetiva redigida e verifique o ouvinte privado antes de alterar o tráfego. Preserve o binário antigo, configuração, ouvinte e o alvo DNS ou do balanceador de carga até que a janela de observação se feche.

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
/usr/local/bin/webship --print-effective-config --config /etc/webship/production.toml
curl --http3-only --insecure https://127.0.0.1:443/health