← Все руководства по миграции

Руководство по миграции конкурента

Мигрировать с Bun.serve на Webship без слепого переключения.

Разделяйте код приложения и задачи на краю: оставьте Bun как источник, в то время как Webship берет на себя TLS, доставку статических файлов, HTTP/3, защиту и маршрутизацию запросов.

Применяется к Webship 1.1.0TypeScript

Определите границу миграции перед изменением трафика.

Начните с переноса только того поведения, которое Webship может воспроизвести и проверить. Оставьте аутентификацию приложений, обнаружение сервисов, скрипты и специализированные правила кэша на существующем источнике до тех пор, пока их замены не пройдут тесты, аналогичные производственной среде.

Сначала переводите наименьший производственный путь.

Исходный фрагмент определяет концепцию миграции; фрагмент Webship показывает целевую форму. Замените примерные домены, адреса, сертификаты, лимиты и пути проверки состояния на значения, проверенные для вашей среды.

Представительная конфигурация Bun.serve
Bun.serve({
  port: 443,
  tls: { cert: Bun.file("cert.pem"), key: Bun.file("key.pem") },
  routes: {
    "/": new Response(Bun.file("./public/index.html")),
  },
});
Эквивалент Webship TOML
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

Соотносите концепции, а не синтаксис.

Технические указания не всегда совпадают один к одному. Используйте эту таблицу, чтобы найти эквивалентную область конфигурации Webship, затем проверьте фактическую конфигурацию и поведение во время выполнения.

Текущая концепция или директиваЦель конфигурации Webship
listener / virtual hostlisten + [reverse_proxy.protocols]
document root[[sites]].root
host matcher[[reverse_proxy.routes]]
certificate and private key[reverse_proxy.tls] / [[sites]] cert + key

Используйте обратимый пятиэтапный переход.

Держите старый слушатель активным до тех пор, пока Webship не пройдет проверки корректности, производительности, безопасности, наблюдаемости и отката на репрезентативном трафике.

  1. 1

    Наблюдаемое поведение инвентаря

    Запишите слушателей, домены, маршруты, upstream, сертификаты, переписывания, аутентификацию, правила кэша, проверки состояния, лимиты и операционные интеграции.

  2. 2

    Переведите одну границу

    Переместите один хост или маршрут в строгий TOML. Сохраняйте модули и приложенческую логику, специфичную для поставщика, за Webship, пока отдельные замены не будут протестированы.

  3. 3

    Проверка в оффлайн-режиме и локально

    Выполните --check-config и --print-effective-config, проверьте отредактированный результат, протестируйте работоспособность локально и используйте TLS через TCP и UDP, когда HTTP/3 включен.

  4. 4

    Canary реальный трафик

    Отправьте небольшой наблюдаемый фрагмент трафика на Webship. Сравните коды состояния, заголовки, тела, задержку, состояние upstream, поведение кэша, журналы и решения по безопасности.

  5. 5

    Продвигайте с готовностью к откату

    Увеличьте трафик на измеряемых этапах. Сохраняйте предыдущую цель здоровой и сразу доступной до тех пор, пока не пройдут согласованное окно наблюдения и контрольные точки нагрузки.

Сначала проверьте. Откатывайте через маршрутизацию, а не редактируя вживую.

Проверьте файл кандидата, осмотрите скрытую действующую конфигурацию и исследуйте частный слушатель перед изменением трафика. Сохраните старый бинарный файл, конфигурацию, слушатель и цель DNS или балансировщика нагрузки до закрытия окна наблюдения.

/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