ย้าย DirectAdmin จาก CentOS 7 ไป Debian 12 บน Proxmox (สารบัญซีรีส์)

เครื่อง DirectAdmin shared host ตัวหลักของผมรันบน CentOS 7 มาเกือบ 10 ปี หมด EOL ไปกลางปี 2024 ผมดองมานานพอสมควร ลูกค้า 80 กว่า user รอย้าย OS ใหม่อยู่ จนเพิ่งมาลงมือทำเสร็จไปปลายเดือนที่แล้ว ตอนนี้ใช้งานจริงมาเกือบเดือน ทุกอย่างนิ่งดี เลยถือโอกาสมาเขียนเล่ากระบวนการทั้งหมดไว้เป็นซีรีส์ แตกเป็นตอนๆ เผื่อใครเจอสถานการณ์เดียวกันจะได้เอาไปทำตามได้

หน้านี้เป็นสารบัญรวมของซีรีส์ ผมจะเกริ่นภาพรวมการย้ายทั้งโปรเจกต์ก่อน แล้วค่อยลิงก์ไปแต่ละตอนด้านล่าง

ทำไมถึงต้องย้าย และทำไมเลือก Debian 12

CentOS 7 หมด EOL ไปแล้ว ไม่มี security update เข้ามาอีก สำหรับเครื่องที่เปิดบริการ shared hosting ให้คนนอกใช้ การปล่อยให้รัน OS ที่ไม่มีแพตช์ต่อไปเรื่อยๆ มันเสี่ยงเกินรับได้ ผมเลยต้องย้าย

ตัวเลือก OS ปลายทาง ผมชั่งใจอยู่นานพอควร

สรุปคือ Debian 12 (bookworm) เป็นจุดที่ผมลงตัวที่สุด ทั้งเรื่อง life cycle และความเข้ากันได้กับ DirectAdmin

ภาพรวมขั้นตอนการย้ายทั้งโปรเจกต์

ก่อนจะลงรายละเอียดแต่ละตอน ผมขอวางภาพรวมไว้ก่อน เพื่อให้เห็นว่าทั้งกระบวนการมันต่อกันยังไง

หลักการคือ เตรียมเครื่องปลายทางให้พร้อมที่สุดก่อน ในขณะที่เครื่องเก่ายัง online ให้บริการอยู่ตามปกติ พอทุกอย่างฝั่งใหม่พร้อม ค่อยทำ cutover ตัวจริงในช่วงเวลาสั้นๆ แล้วปิดท้ายด้วยการ hardening ความปลอดภัย

จุดที่ผมว่าสำคัญที่สุดของแผนนี้คือ การ pre-stage ผ่าน NAT ตั้งแต่ตอนที่ 1 มันทำให้ผมเตรียม config และ test ฝั่งใหม่ได้เกือบทั้งหมดโดยที่ลูกค้าบนเครื่องเก่าไม่รู้สึกอะไรเลย stress ช่วง prep เลยลดลงเยอะ

สเปกชุดที่ใช้ทำซีรีส์นี้

ของพวกนี้ผมทำบนชุดต่อไปนี้ ใครเวอร์ชันต่างไปอาจเจอ behavior ไม่เหมือนกันบ้าง

ตรงนี้มีเรื่องต้องบอกไว้ก่อน ผมใช้ DirectAdmin แบบ legacy license ไม่ใช่ Modern license แบบ subscription ใครใช้ Modern license อาจไม่เจอบาง issue เพราะ DA support distro ใหม่ให้ตรงๆ ส่วน legacy license แบบผมก็ต้องทำ workaround ไปบ้าง ตรงไหนที่เป็น workaround เฉพาะ legacy ผมจะระบุไว้ในแต่ละตอน

ของจริงไม่ได้ downtime เป็น 0

ขอพูดเรื่องนี้ตรงๆ ตั้งแต่แรก ตอนแรกผมตั้งใจจะทำให้ downtime เป็น 0 ตามแผน แต่ของจริงลูกค้าโดน downtime ไปประมาณ 1 ชั่วโมง

สาเหตุหลักคือติดเรื่อง DA legacy license บวกกับ qcow2 อ่านช้าในช่วง cutover (รายละเอียดเต็มอยู่ตอนที่ 4) แต่ถึงจะไม่ได้ 0 ตามฝัน กระบวนการ NAT pre-stage ก็ยังช่วยให้ช่วงเตรียมงานทั้งหมดราบรื่นกว่าการทำสดมาก

ทั้ง 5 ตอนของซีรีส์

ด้านล่างนี้คือสารบัญทั้งหมด แต่ละตอนต่อยอดจากตอนก่อนหน้า แนะนำให้ไล่อ่านตามลำดับถ้าจะเอาไปทำตามจริง แต่ถ้าจะกระโดดอ่านเฉพาะหัวข้อที่สนใจก็ได้ หลักการแต่ละตอนแยกกันอ่านได้เหมือนกัน

ตอนที่ 1 — เตรียม VM ใหม่ + NAT pre-stage trick

ตอนที่ 1: เตรียม VM ใหม่ + NAT pre-stage

เป็นพื้นฐานของซีรีส์ทั้งหมด ว่าด้วยการเตรียม VM ปลายทางบน Proxmox และเทคนิค NAT pre-stage ที่ทำให้เตรียมและทดสอบฝั่งใหม่ได้โดยเครื่องเก่ายังให้บริการอยู่ ถ้าจะอ่านตอนเดียว อ่านตอนนี้

ตอนที่ 2 — ถอด RAID เก่า + สร้าง ZFS mirror

ตอนที่ 2: ถอด RAID + สร้าง ZFS mirror

ว่าด้วยการถอด RAID ชุดเก่าออก แล้วสร้าง ZFS mirror ขึ้นมาใหม่ในโหมด degraded ระหว่างที่ VM เก่ายัง online อยู่ เป็นการสลับดิสก์แบบค่อยเป็นค่อยไปโดยไม่ดับบริการ

ตอนที่ 3 — ลง DA + CustomBuild บน Debian 12

ตอนที่ 3: ลง DA + CustomBuild

ลง DirectAdmin และ CustomBuild บน Debian 12 พร้อม stack ที่ใช้จริง ทั้ง PHP หลาย slot, nginx + ModSecurity และ rspamd จัดการ config ฝั่งใหม่ให้เทียบเท่าของเดิม

ตอนที่ 4 — Cutover ย้ายจริง + ปัญหาที่เจอ

ตอนที่ 4: Cutover + ปัญหาหลังย้าย

ตอนที่หินที่สุด การ cutover ย้ายข้อมูลจริง ที่ผมเจอกำแพงเรื่องเวลา และรวมปัญหาที่โผล่มาหลังย้าย พร้อมวิธีแก้ทีละข้อ ตอนนี้คือเหตุผลว่าทำไม downtime ไม่ได้เป็น 0

ตอนสุดท้าย — Security fixes + hardening

ตอนที่ 5: Security fixes + hardening

ปิดท้ายด้วยการเก็บงานความปลอดภัย ทั้งเรื่อง sudoers wildcard CVE, การปรับ OpenSSL SECLEVEL, การวาง ModSecurity rule แบบ before-CRS และแนวทางให้ config รอด 5 ชั้นเวลา DA อัปเดต

ปิดท้าย

ทั้งหมดนี้ผมทำกับ DA 1.700/1.701 บน Debian 12.7 และ PVE 8.4 ใครใช้ DA Modern license อาจไม่เจอบาง issue เพราะ DA support distro ใหม่ให้ตรงๆ ส่วน legacy license แบบผมก็ต้องลุย workaround ไปตามทาง

ผมทำเป็นรอบๆ ไป ตอนไหนตกหล่นหรือมีอะไรผิดพลาด เดี๋ยวจะกลับมาแก้ให้ ใครจะไล่อ่านตามลำดับหรือกระโดดอ่านเฉพาะตอนที่ต้องใช้ก็ตามสะดวก หลักการเหมือนกันหมด