مهاجرت از OpenResty به Webship بدون تغییر ناگهانی.

مرز مهاجرت را پیش از تغییر ترافیک تعریف کنید.

با انتقال فقط رفتاری که Webship می‌تواند بازتولید و تأیید کند شروع کنید. احراز هویت برنامه، کشف سرویس، اسکریپت‌ها، و قوانین کش تخصصی را روی منبع موجود رها کنید تا زمانی که جایگزین‌هایشان آزمون‌های محیط تولید را پشت سر بگذارند.

ابتدا کوچک‌ترین مسیر تولید را ترجمه کنید.

قطعه منبع مفهوم مهاجرت را شناسایی می‌کند؛ قطعه Webship شکل هدف را نشان می‌دهد. دامنه‌ها، آدرس‌ها، گواهینامه‌ها، محدودیت‌ها و مسیرهای سلامتی نمونه را با مقادیری که برای محیط شما تایید شده‌اند جایگزین کنید.

server {
  listen 443 ssl;
  server_name app.example.com;
  location / {
    access_by_lua_file /etc/openresty/auth.lua;
    proxy_pass http://127.0.0.1:8080;
  }
}

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

   رفتار مشهود موجودی

   گوش‌دهنده‌ها، دامین‌ها، مسیرها، سرورهای بالادست، گواهینامه‌ها، بازنویسی‌ها، احراز هویت، قوانین کش، پروب‌های سلامت، محدودیت‌ها و ادغام‌های عملیاتی را ثبت کنید.

2. 2

   ترجمه یک مرز

   یک میزبان یا مسیر را به TOML سخت منتقل کنید. ماژول‌ها و منطق برنامه خاص فروشنده را پشت Webship نگه دارید تا تعویض‌های جداگانه اثبات شوند.

3. 3

   به صورت آفلاین و محلی اعتبارسنجی کنید

   --check-config و --print-effective-config را اجرا کنید، نتیجه سانسور شده را بررسی کنید، سلامت را به‌صورت محلی آزمایش کنید و TLS را بر روی هر دو TCP و UDP زمانی که HTTP/3 فعال است اعمال کنید.

4. 4

   ترافیک واقعی کاناری

   یک بخش کوچک و قابل مشاهده از ترافیک را به Webship ارسال کنید. کدهای وضعیت، هدرها، محتوا، تأخیر، سلامت سرورهای بالادست، رفتار کش، لاگ‌ها، و تصمیمات امنیتی را مقایسه کنید.

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