Migrar de Bun.serve 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.

Bun.serve({
  port: 443,
  tls: { cert: Bun.file("cert.pem"), key: Bun.file("key.pem") },
  routes: {
    "/": new Response(Bun.file("./public/index.html")),
  },
});

listen = "0.0.0.0:443"
workers = 4

[[sites]]
domain = "app.example.com"
root = "/srv/app/public"
listen = "0.0.0.0:443"
cert = "/etc/letsencrypt/live/app.example.com/fullchain.pem"
key = "/etc/letsencrypt/live/app.example.com/privkey.pem"

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

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