เตรียมเซิร์ฟเวอร์และใบรับรองสำหรับโฮสต์เนมที่ต้องการ ทดสอบแอปพลิเคชันก่อนเปลี่ยน DNS สาธารณะ และเก็บสภาพแวดล้อมเก่าไว้ให้พร้อมใช้ระหว่างการเปลี่ยนผ่าน ตรวจสอบเรกคอร์ด authoritative คำตอบที่แคชไว้ และ TLS แยกกัน การอัปเดต DNS เพียงอย่างเดียวไม่ได้ยืนยันว่าแอปพลิเคชันและใบรับรองที่ถูกต้องกำลังให้บริการอยู่
จัดทำทะเบียนชื่อและความสัมพันธ์เชิงพึ่งพา
ระบุโฮสต์เนมทุกชื่อที่เว็บไซต์ใช้ รวมถึงโดเมนหลัก ชื่อแทน ปลายทาง API และ callback ของแอปพลิเคชัน บันทึกว่าใครควบคุมการจดทะเบียนและ DNS แบบ authoritative การโฮสต์แอปพลิเคชันไม่ได้จดทะเบียนโดเมนของมันโดยอัตโนมัติ หรือให้ผู้ดูแลเซิร์ฟเวอร์ควบคุมเรกคอร์ดของมัน เก็บการเข้าถึงสภาพแวดล้อมที่มีอยู่ไว้จนกว่าสภาพแวดล้อมใหม่จะได้รับการตรวจสอบ
ระบุเรกคอร์ดอีเมลและการยืนยันจากบุคคลที่สามที่การย้ายควรเก็บรักษาไว้ด้วย การโยกย้ายเว็บไซต์ไม่ควรแทนที่โซน DNS ทั้งหมดอย่างไม่ระมัดระวัง จัดทำแผนการเปลี่ยนแปลงระดับเรกคอร์ดพร้อมที่อยู่ที่ต้องการและค่าย้อนกลับ เก็บข้อมูลรับรองเป็นความลับ คู่มือปฏิบัติงานต้องการเจ้าของและขั้นตอน ไม่ใช่รหัสผ่านจริงหรือโทเค็น API
เตรียมการกำหนดเส้นทางโฮสต์เนมบนเซิร์ฟเวอร์ใหม่
เครื่องที่รับการเชื่อมต่อต้องให้บริการแอปพลิเคชันที่ต้องการสำหรับโฮสต์เนมของตน กำหนดค่าเว็บเซิร์ฟเวอร์หรือแผงโฮสติ้งให้สอดคล้อง โดยแยก document root สาธารณะออกจากการกำหนดค่าและข้อมูลรับรองส่วนตัว ทดสอบชื่อและ redirect ที่จำเป็นทั้งหมด ไม่ใช่เพียงหน้า welcome ทั่วไปที่เข้าถึงผ่านที่อยู่ของเซิร์ฟเวอร์
ใช้วิธีการทดสอบแบบควบคุมที่ส่งโฮสต์เนมที่ต้องการไปยังปลายทางใหม่ก่อนการเปลี่ยนแปลงสาธารณะ ตรวจสอบการเข้าสู่ระบบ การอัปโหลด และลิงก์ที่สร้างโดยแอปพลิเคชันตามความเหมาะสม ปิดใช้งานงานที่อาจทำให้การดำเนินการในโปรดักชันซ้ำซ้อนระหว่างการทดสอบ การทดสอบควรพิสูจน์พฤติกรรมของแอปพลิเคชันโดยไม่ส่งอีเมลจริง รับชำระเงิน หรือแก้ไขฐานข้อมูลจริงเดิมโดยไม่ตั้งใจ
เลือกวิธีการตรวจสอบใบรับรอง
การออกใบรับรองต้องมีการพิสูจน์การควบคุมสำหรับชื่อที่ร้องขอ Let's Encrypt ระบุ HTTP-01 และ DNS-01 เป็นหนึ่งในวิธีการตรวจสอบ การตรวจสอบ HTTP ขึ้นอยู่กับการให้บริการ challenge ที่ต้องการอย่างถูกต้อง การตรวจสอบ DNS ใช้เรกคอร์ด DNS ที่ระบุและสามารถรองรับการออกใบรับรองแบบ wildcard เลือกวิธีการที่เหมาะกับการปรับใช้จริงและสามารถดูแลรักษาได้อย่างปลอดภัย
จำกัดขอบเขตข้อมูลรับรองการตรวจสอบให้แคบที่สุดเท่าที่ทำได้ การทำงานอัตโนมัติของ DNS มีความละเอียดอ่อนเป็นพิเศษเพราะข้อมูลรับรอง DNS ที่กว้างขวางอาจส่งผลกระทบมากกว่าหนึ่งเว็บไซต์ วางแผนการต่ออายุใบรับรองและวิธีที่ไฟล์ที่ต่ออายุแล้วไปถึงกระบวนการให้บริการ การออกใบรับรองครั้งแรกสำเร็จนั้นมีประโยชน์ แต่เว็บไซต์ยังต้องมีกระบวนการต่ออายุที่ทำงานได้และการตรวจสอบใบรับรองที่นำเสนอจริง
วางแผนช่วงเวลาแคชก่อนเปลี่ยน DNS
เรกคอร์ด DNS มี time-to-live ที่ตัวแก้ชื่อใช้เมื่อแคชคำตอบ การเปลี่ยนเรกคอร์ดไม่ได้แทนที่ผลลัพธ์ที่แคชไว้ทั้งหมดทันที หากการเปลี่ยนผ่านได้ประโยชน์จาก TTL ที่สั้นลง ให้วางแผนปรับตั้งแต่เนิ่นๆ เพื่อให้คำตอบที่แคชไว้ก่อนหน้าหมดอายุได้ เก็บทั้งสภาพแวดล้อมเก่าและใหม่ให้สามารถรองรับการเปลี่ยนผ่านที่คุณออกแบบไว้
ลำดับตัวอย่างนี้แยกการเตรียมการออกจากการสลับระบบสาธารณะ ระยะเวลาต้องปรับให้เหมาะกับโดเมน พฤติกรรมของตัวแก้ชื่อ และแอปพลิเคชัน ไม่ใช่ตารางการแพร่กระจายสากล การโยกย้ายที่เกี่ยวข้องกับการเขียนสดยังต้องมีการสลับข้อมูลเฉพาะแอปพลิเคชัน เพราะเว็บเซิร์ฟเวอร์ที่ทำงานได้สองตัวอาจรับการเปลี่ยนแปลงเข้าสู่ชุดข้อมูลที่ต่างกัน
| ขั้นตอน | การดำเนินการ | เงื่อนไขก่อนดำเนินการต่อ |
|---|---|---|
| การเตรียมการ | จัดทำทะเบียนเรกคอร์ดและกำหนดค่าปลายทางใหม่ | แอปพลิเคชันทำงานสำหรับชื่อที่ต้องการ |
| ใบรับรอง | ออกและติดตั้งใบรับรอง | เชนและโฮสต์เนมที่ถูกต้องผ่านการตรวจสอบ |
| การเปลี่ยนผ่าน | อัปเดตเฉพาะเรกคอร์ด DNS ที่วางแผนไว้ | กำหนดการสลับข้อมูลและการย้อนกลับแล้ว |
| การสังเกต | ตรวจสอบผลลัพธ์ authoritative และจากไคลเอนต์ | เส้นทางผู้ใช้สำเร็จผ่านปลายทางใหม่ |
| การเสร็จสิ้น | ปลดระวางบริการเก่าหลังการตรวจสอบ | ทบทวนปริมาณการใช้งานที่เหลือและความต้องการกู้คืน |
ตรวจสอบ DNS และ TLS แยกกัน
ตรวจสอบเรกคอร์ด authoritative ก่อน จากนั้นเปรียบเทียบคำตอบจากไคลเอนต์หรือตัวแก้ชื่อที่เกี่ยวข้องกับการเปลี่ยนผ่าน ค่าที่ถูกต้องจาก authoritative และค่าที่แคชไว้เก่ากว่าสามารถอยู่ร่วมกันได้ ตรวจสอบปลายทางที่เบราว์เซอร์เข้าถึง แทนที่จะสันนิษฐานว่าทุกการเชื่อมต่อใช้ที่อยู่ใหม่แล้ว เก็บการสังเกตพร้อมประทับเวลาเพื่อให้การเปลี่ยนผ่านเข้าใจได้
สำหรับ TLS ให้ตรวจสอบโฮสต์เนมที่ต้องการ ความถูกต้องของใบรับรอง และเชนผ่านการเชื่อมต่อไคลเอนต์จริง ตรวจสอบชื่อแทนและเส้นทาง redirect ที่จำเป็นทั้งหมด เอกสาร TLS ของ Mozilla อธิบายการพิสูจน์ตัวตนเซิร์ฟเวอร์และข้อกังวลเรื่องเนื้อหาผสม: หน้าเว็บและทรัพยากรย่อยควรถูกส่งอย่างปลอดภัย ใบรับรองบนโฮสต์เนมหนึ่งไม่ได้ครอบคลุมปลายทางแอปพลิเคชันอื่นโดยอัตโนมัติ
ทำให้การย้อนกลับเป็นการตัดสินใจด้านข้อมูลด้วย
การย้อนกลับ DNS สามารถเปลี่ยนเส้นทางได้ แต่ไม่ได้ย้อนการเขียนที่เกิดขึ้นบนแอปพลิเคชันใหม่ กำหนดวิธีจัดการข้อมูลนั้นก่อนการสลับระบบ สำหรับสิ่งพิมพ์แบบคงที่ การย้อนกลับอาจตรงไปตรงมา สำหรับบริการที่รับการอัปโหลดหรือคำสั่งซื้อ สถานะของแอปพลิเคชันต้องมีเจ้าของที่ชัดเจนและขั้นตอนการกระทบยอด
ลองจินตนาการถึงการโยกย้ายเว็บไซต์สิ่งพิมพ์ขนาดเล็กที่มีความคิดเห็น คุณสามารถเตรียมช่วงเวลาบำรุงรักษาหรือการเปลี่ยนผ่านแบบอ่านอย่างเดียวที่ควบคุมไว้ระหว่างคัดลอกข้อมูลสุดท้าย ทดสอบขั้นตอนการเปิดใหม่และเตรียมการปรับใช้เก่าให้พร้อม เลือกแนวทางที่เหมาะกับแอปพลิเคชัน แทนที่จะใช้การเปลี่ยน DNS เป็นตัวแทนของการวางแผนความสอดคล้อง
สังเกตเว็บไซต์หลังการสลับ
ตรวจสอบเส้นทางผู้ใช้จริง อัตราข้อผิดพลาด การนำเสนอใบรับรอง และงานเบื้องหลังหลังจากปลายทางใหม่รับปริมาณการใช้งาน ยืนยันว่าการสำรองข้อมูลครอบคลุมแอปพลิเคชันและข้อมูลที่ต้องการแล้ว ทบทวนการเข้าถึงเซิร์ฟเวอร์เก่าก่อนปลดระวางและลบข้อมูลรับรองที่ล้าสมัยเมื่อความต้องการด้านการกู้คืนและการย้อนกลับได้รับการแก้ไขแล้ว บันทึกการกำหนดค่า DNS และใบรับรองขั้นสุดท้าย
เมื่อเลือกเว็บโฮสติ้งหรือคอมพิวต์ SwissOctet ให้ยืนยันความรับผิดชอบที่แท้จริงด้านโดเมน ใบรับรอง และการดูแลระบบสำหรับการกำหนดค่านั้น แค็ตตาล็อกมีปลายทางโฮสติ้งและทรัพยากร แต่ไม่ได้ยืนยันว่าโดเมนของคุณเชื่อมต่อแล้วหรือการต่ออายุใบรับรองได้รับการกำหนดค่าแล้ว ทำให้ขั้นตอนเหล่านั้นเป็นรูปธรรมและตรวจสอบได้ในแผนการปรับใช้
รายการตรวจสอบปฏิบัติของคุณ
- จัดทำทะเบียนโฮสต์เนมทุกชื่อและเก็บรักษาเรกคอร์ด DNS ที่ไม่เกี่ยวข้อง
- ทดสอบการกำหนดเส้นทางโฮสต์เนมก่อนการสลับระบบสาธารณะ
- เลือกและทำให้การตรวจสอบใบรับรองที่เหมาะสมเป็นอัตโนมัติ
- วางแผนการเปลี่ยน TTL และการเปลี่ยนผ่านข้อมูล
- ตรวจสอบ DNS และ TLS ผ่านการตรวจสอบแยกกัน
- เก็บการเข้าถึงสำหรับย้อนกลับและจัดการการเขียนใหม่ก่อนย้อนกลับ
รายละเอียดที่สำคัญ
การเปลี่ยน A record เปิดใช้งาน HTTPS หรือไม่+
ไม่ DNS เลือกปลายทาง ปลายทางนั้นยังต้องมีการกำหนดเส้นทางโฮสต์เนมที่ถูกต้องและใบรับรองที่ติดตั้งและใช้งานได้
ฉันสามารถย้อนกลับเฉพาะเรกคอร์ด DNS ได้หรือไม่หากมีบางอย่างเสียหาย+
ปริมาณการใช้งานสามารถเปลี่ยนเส้นทางได้ แต่การเขียนของแอปพลิเคชันต้องจัดการแยกต่างหาก กำหนดแผนการย้อนกลับหรือกระทบยอดข้อมูลก่อนการโยกย้าย
จำเป็นต้องใช้ใบรับรองแบบ wildcard เสมอหรือไม่+
ไม่ เลือกชื่อใบรับรองและการตรวจสอบตามโฮสต์เนมจริง wildcard มีความครอบคลุมและข้อกำหนดการตรวจสอบเฉพาะ ไม่ใช่ทางลัดสากลสำหรับการโยกย้าย
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- Let's Encrypt: ประเภทของ Challenge letsencrypt.org
- IETF RFC 1034: แนวคิดและความสามารถของ DNS datatracker.ietf.org
- Mozilla MDN: Transport Layer Security developer.mozilla.org
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก