คู่มือการโยกย้ายของคู่แข่ง
ย้ายจาก Bun.serve ไปยัง Webship โดยไม่ต้องตัดการใช้งานทันที
แยกโค้ดแอปพลิเคชันออกจากหน้าที่ edge: รักษา Bun เป็นต้นทางในขณะที่ Webship ดูแล TLS, การส่งไฟล์สแตติก, HTTP/3, การป้องกัน, และการกำหนดเส้นทางคำขอ
กำหนดขอบเขตการย้ายก่อนที่จะเปลี่ยนการจราจร
เริ่มต้นด้วยการย้ายเฉพาะพฤติกรรมที่ Webship สามารถสร้างซ้ำและตรวจสอบได้ ปล่อยให้การยืนยันตัวตนของแอปพลิเคชัน, การค้นหาบริการ, สคริปต์ และกฎแคชเฉพาะ อยู่บนต้นทางที่มีอยู่จนกว่าการทดสอบแบบใกล้เคียงการผลิตของพวกมันจะผ่าน
แปลเส้นทางการผลิตที่เล็กที่สุดก่อน
ชิ้นส่วนต้นทางระบุแนวคิดการย้ายข้อมูล; ชิ้นส่วน Webship แสดงรูปร่างของเป้าหมาย แทนที่โดเมน ตัวอย่าง ที่อยู่ ใบรับรอง ขีดจำกัด และเส้นทางสุขภาพด้วยค่าที่ได้รับการตรวจสอบแล้วสำหรับสภาพแวดล้อมของคุณ
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จับคู่แนวคิด ไม่ใช่ไวยากรณ์
คำสั่งทางเทคนิคไม่ตรงกันเสมอ ใช้ตารางนี้เพื่อหาบริเวณการกำหนดค่า Webship ที่เทียบเท่า แล้วตรวจสอบการกำหนดค่าที่มีผลและพฤติกรรมในเวลารัน
| แนวคิดหรือแนวทางปัจจุบัน | เป้าหมายการกำหนดค่า Webship |
|---|---|
listener / virtual host | listen + [reverse_proxy.protocols] |
document root | [[sites]].root |
host matcher | [[reverse_proxy.routes]] |
certificate and private key | [reverse_proxy.tls] / [[sites]] cert + key |
ใช้การเปลี่ยนอย่างห้าขั้นตอนที่สามารถย้อนกลับได้
เก็บผู้ฟังเก่าให้พร้อมจนกว่า Webship จะผ่านเกณฑ์ความถูกต้อง ความจุ ความปลอดภัย การตรวจสอบ และการย้อนกลับบนการจราจรตัวอย่าง
- 1
พฤติกรรมที่สังเกตได้ของสินค้าคงคลัง
บันทึกผู้ฟัง โดเมน เส้นทาง upstream ใบรับรอง การเขียนซ้ำ การตรวจสอบสิทธิ์ กฎแคช การตรวจสอบสุขภาพ ขีดจำกัด และการบูรณาการเชิงปฏิบัติการ
- 2
แปลงขอบเขตหนึ่ง
ย้ายโฮสต์หนึ่งตัวหรือเส้นทางเข้าสู่ TOML อย่างเข้มงวด รักษาโมดูลเฉพาะผู้ขายและตรรกะแอปพลิเคชันไว้หลัง Webship จนกว่าการเปลี่ยนทดแทนแยกต่างหากจะได้รับการพิสูจน์แล้ว
- 3
ตรวจสอบแบบออฟไลน์และภายในเครื่อง
รัน --check-config และ --print-effective-config ตรวจสอบผลที่ถูกลบข้อมูล ตรวจสอบสภาพแวดล้อมในพื้นที่ และใช้งาน TLS ผ่านทั้ง TCP และ UDP เมื่อ HTTP/3 ถูกเปิดใช้งาน
- 4
Canary real traffic
ส่งส่วนเล็ก ๆ ของการจราจรที่สามารถสังเกตได้ไปยัง Webship เปรียบเทียบรหัสสถานะ ส่วนหัว เนื้อหา ความหน่วง สุขภาพของ upstream พฤติกรรมแคช บันทึก และการตัดสินใจด้านความปลอดภัย
- 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