Migrar de Envoy para Webship sem uma transição cega.

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

Comece por mover apenas o comportamento que Webship consegue reproduzir e validar. Deixe a autenticação da aplicação, a descoberta de serviços, os scripts e as regras de cache especializadas na origem existente até que os seus substitutos passem em testes semelhantes aos de produção.

Traduza primeiro o caminho de produção mais pequeno.

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

static_resources:
  listeners:
    - name: https
      address: { socket_address: { address: 0.0.0.0, port_value: 443 } }
  clusters:
    - name: app
      load_assignment:
        cluster_name: app
        endpoints: []

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.

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

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

Mantenha o ouvinte antigo pronto até que Webship tenha passado os portões de corretude, capacidade, segurança, observabilidade e reversão com tráfego representativo.

1. 1

   Comportamento observável de inventário

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

2. 2

   Traduzir uma fronteira

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

3. 3

   Validar offline e localmente

   Executar --check-config e --print-effective-config, inspecionar o resultado redigido, testar a saúde localmente e utilizar TLS sobre TCP e UDP quando HTTP/3 estiver ativado.

4. 4

   Tráfego real canário

   Envie um pequeno segmento de tráfego observável para Webship. Compare códigos de status, cabeçalhos, conteúdos, latência, estado dos upstreams, comportamento de cache, registos e decisões de segurança.

5. 5

   Promover com reversão pronta

   Aumentar o tráfego nas etapas medidas. Manter o alvo anterior saudável e imediatamente roteável até que a janela de observação acordada e os portões de carga sejam ultrapassados.

Valide primeiro. Revertir através de encaminhamento, não editando ao vivo.

Valide o ficheiro do candidato, inspecione a configuração eficaz redigida e verifique o ouvinte privado antes de alterar o tráfego. Preserve o binário antigo, configuração, ouvinte e alvo DNS ou de 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