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

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

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

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

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

frontend https
  bind :443 ssl crt /etc/haproxy/app.pem
  default_backend app
backend app
  balance roundrobin
  server app1 127.0.0.1:8080 check
  server app2 127.0.0.1:8081 check

listen = "0.0.0.0:443"
workers = 4

[reverse_proxy]
enabled = 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

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

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

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

Держите старый слушатель активным до тех пор, пока 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