Ubuntu 18.04 LTS — คู่มืออัปเกรดและ Migration ไป 22.04/24.04

Ubuntu 18.04 LTS: จุดสิ้นสุดของยุคและการเตรียมความพร้อมสู่การเปลี่ยนแปลง

Ubuntu 18.04 LTS (Bionic Beaver) ถือเป็นหนึ่งในรุ่นที่ได้รับความนิยมและวางใจจากผู้ใช้ทั้งในแวดวงเดสก์ท็อปและเซิร์ฟเวอร์มายาวนาน ด้วยการสนับสนุนมาตรฐานระยะยาว (LTS) เป็นเวลา 5 ปี สำหรับภาพเดสก์ท็อปและ 10 ปี สำหรับภาพเซิร์ฟเวอร์ผ่านการสมัคร Ubuntu Pro อย่างไรก็ตาม การสนับสนุนมาตรฐานฟรีสำหรับ 18.04 LTS ได้สิ้นสุดลงในเดือนพฤษภาคม 2023 (สำหรับเดสก์ท็อป) และเมษายน 2028 (สำหรับเซิร์ฟเวอร์พื้นฐาน) ส่งสัญญาณที่ชัดเจนว่าถึงเวลาที่ผู้ใช้ต้องพิจารณาการอัปเกรดอย่างจริงจัง

การย้ายจากระบบเก่าที่ไม่ได้รับการอัปเดตความปลอดภัยอีกต่อไป เป็นความเสี่ยงที่องค์กรและบุคคลไม่สามารถเพิกเฉยได้ บทความนี้จะเป็นคู่มือที่ครอบคลุมทุกแง่มุม ตั้งแต่การประเมินสถานะปัจจุบัน การเตรียมระบบ การเลือกเป้าหมายระหว่าง Ubuntu 22.04 LTS (Jammy Jellyfish) หรือ 24.04 LTS (Noble Numbat) ที่เพิ่งเปิดตัว ไปจนถึงขั้นตอนการอัปเกรดจริงและแก้ไขปัญหาที่พบบ่อย พร้อมด้วยแนวทางปฏิบัติที่ดีที่สุดและกรณีศึกษาเพื่อให้การเปลี่ยนผ่านนี้เป็นไปอย่างราบรื่นและปลอดภัย

การประเมินระบบและเลือกเส้นทางที่เหมาะสม: 22.04 LTS หรือ 24.04 LTS?

ก่อนเริ่มกระบวนการใดๆ ขั้นตอนแรกที่สำคัญที่สุดคือการทำความเข้าใจสภาพแวดล้อมปัจจุบันของตนเองและตัดสินใจเลือกรุ่นเป้าหมายที่เหมาะสมที่สุด โดยมีสองตัวเลือกหลักคือ Ubuntu 22.04 LTS และ 24.04 LTS

การตรวจสอบระบบ Ubuntu 18.04 ปัจจุบัน

เปิด Terminal และรันคำสั่งต่อไปนี้เพื่อดูข้อมูลระบบ:

lsb_release -a
hostnamectl
df -h
apt list --installed | wc -l

นอกจากนี้ ให้บันทึกแอปพลิเคชันและบริการที่สำคัญทั้งหมด รวมถึงการตั้งค่าในไฟล์คอนฟิกที่แก้ไข (เช่น ใน `/etc/`) การใช้เครื่องมือเช่น `dpkg –get-selections > installed_packages.list` สามารถช่วยบันทึกรายการแพ็กเกจได้

เปรียบเทียบ Ubuntu 22.04 LTS และ 24.04 LTS

คำแนะนำ: สำหรับเซิร์ฟเวอร์และระบบที่ใช้ในงานวิกฤติ แนะนำให้อัปเกรดไปที่ 22.04 LTS ก่อนเพื่อความมั่นใจในความเสถียร จากนั้นค่อยวางแผนไป 24.04 ในอีก 1-2 ปีข้างหน้า ส่วนผู้ใช้เดสก์ท็อปทั่วไปที่ใช้ฮาร์ดแวร์ไม่เก่ามาก การข้ามไปที่ 24.04 LTS เลยก็เป็นตัวเลือกที่ดีเพื่ออายุการใช้งานที่ยาวนานขึ้น

แนวทางการอัปเกรด: In-Place Upgrade vs. Fresh Installation vs. Migration

มีสามเส้นทางหลักสำหรับการย้ายจาก Ubuntu 18.04 ไปสู่รุ่นใหม่ ซึ่งแต่ละวิธีมีข้อดีข้อเสียและเหมาะกับสถานการณ์ต่างกัน

1. การอัปเกรดแบบ In-Place (ทางตรง)

เป็นวิธีการอัปเดตระบบเดิมไปเป็นรุ่นใหม่โดยพยายามรักษาแอปพลิเคชัน การตั้งค่า และข้อมูลผู้ใช้ไว้ให้มากที่สุด ใช้เครื่องมือ `do-release-upgrade`

ข้อดี: รักษาการตั้งค่าและแอปไว้ได้, ใช้เวลาน้อยกว่าการติดตั้งใหม่, เหมาะสำหรับระบบที่การตั้งค่าซับซ้อน
ข้อเสีย:มีความเสี่ยงเกิดข้อผิดพลาดสะสม, อาจเจอความไม่เข้ากันของแพ็กเกจ, ทำความสะอาดระบบเก่าได้ไม่สมบูรณ์
เหมาะสำหรับ: ผู้ใช้เดสก์ท็อปทั่วไป, เซิร์ฟเวอร์ที่คอนฟิกไม่ซับซ้อนเกินไป

2. การติดตั้งใหม่แบบ Fresh Installation

คือการติดตั้ง Ubuntu รุ่นใหม่ลงบนพาร์ติชันที่ฟอร์แมตใหม่ทั้งหมด

ข้อดี: ได้ระบบที่สะอาดและปราศจากขยะ, เสถียรที่สุด, โอกาสเกิดปัญหาน้อย
ข้อเสีย: ต้องแบ็กอัพและกู้คืนข้อมูล/การตั้งค่า/แอปพลิเคชันทั้งหมดใหม่, ใช้เวลามาก
เหมาะสำหรับ: ระบบที่มีปัญหาสะสม, ต้องการเริ่มต้นใหม่, การย้ายไปฮาร์ดแวร์ใหม่, สภาพแวดล้อมที่ต้องการความสะอาดสูง

3. การย้ายระบบ (Migration) แบบคอนเทนเนอร์หรือเสมือน

สำหรับเซิร์ฟเวอร์ แนวทางสมัยใหม่คือการแยกบริการออกเป็นคอนเทนเนอร์ (Docker/Podman) หรือใช้การจัดการคอนฟิกด้วยเครื่องมือเช่น Ansible, Chef, Puppet ทำให้การย้ายระบบทำได้โดยการ deploy บนโฮสต์ใหม่

ข้อดี: ยืดหยุ่นสูง, ทำซ้ำได้, เหมาะกับ DevOps และระบบคลาวด์
ข้อเสีย: ต้องมีโครงสร้างพื้นฐานและความรู้ที่รองรับ
เหมาะสำหรับ: เซิร์ฟเวอร์ที่ให้บริการเว็บ, ฐานข้อมูล, แอปพลิเคชันที่อยู่ในคอนเทนเนอร์

คู่มือปฏิบัติ: ขั้นตอนการอัปเกรดจาก Ubuntu 18.04 LTS ไป 22.04 LTS

ส่วนนี้จะแสดงขั้นตอนโดยละเอียดสำหรับการอัปเกรดแบบ In-Place ไปยัง 22.04 LTS ซึ่งเป็นเส้นทางที่พบบ่อยที่สุด

ขั้นตอนที่ 1: การเตรียมระบบและแบ็กอัพที่ขาดไม่ได้

คำเตือน: ห้ามข้ามขั้นตอนนี้เป็นอันขาด

1. อัปเดตและอัปเกรด Ubuntu 18.04 ให้ถึงที่สุด:

   sudo apt update
   sudo apt upgrade
   sudo apt dist-upgrade
   sudo apt autoremove

2. แบ็กอัพข้อมูลสำคัญ: คัดลอกไฟล์ใน `/home`, `/etc`, `/var/www` (หากมี) และข้อมูลแอปพลิเคชันอื่นๆ ไปยังสื่อจัดเก็บภายนอกหรือคลาวด์
3. บันทึกรายการแพ็กเกจที่ติดตั้ง:

   dpkg --get-selections > ~/package-list-18.04.txt
   sudo apt list --installed > ~/installed-packages-18.04.txt

4. บันทึกการตั้งค่าเครือข่าย, ผู้ใช้, และบริการ: จดหมายเลข IP, ชื่อโฮสต์, และตรวจสอบไฟล์ใน `/etc/network/`, `/etc/ssh/sshd_config` เป็นต้น
5. ตรวจสอบพื้นที่ว่างบนดิสก์: ต้องมีพื้นที่ว่างอย่างน้อย 8-10 GB สำหรับกระบวนการอัปเกรด

ขั้นตอนที่ 2: เริ่มกระบวนการอัปเกรด

1. ติดตั้งเครื่องมือ `update-manager-core` (หากยังไม่มี):

   sudo apt install update-manager-core

2. เปิดไฟล์คอนฟิกเพื่อให้อนุญาตการอัปเกรด LTS-to-LTS:

   sudo nano /etc/update-manager/release-upgrades

   เปลี่ยนบรรทัด `Prompt=lts` ให้แน่ใจว่ามีค่าเช่นนี้ (ซึ่งเป็นค่าเริ่มต้น)

3. รันคำสั่งเพื่อเริ่มการอัปเกรด:

   sudo do-release-upgrade

4. เครื่องมือจะดาวน์โหลดแพ็กเกจ ตรวจสอบระบบ และแสดงข้อความสรุป กด y เพื่อดำเนินการต่อ
5. ระหว่างกระบวนการ จะมีข้อความถามเกี่ยวกับการแทนที่ไฟล์คอนฟิก (เช่น `sshd_config`, `apache2.conf`) ให้อ่านอย่างระมัดระวัง:
   • เลือก ‘Y’ หากต้องการใช้ไฟล์คอนฟิกใหม่ (ไฟล์เดิมจะถูกเปลี่ยนชื่อเป็น `.dpkg-old`)
   • เลือก ‘N’ หากต้องการเก็บไฟล์เดิมของคุณ (ไฟล์ใหม่จะถูกเปลี่ยนชื่อเป็น `.dpkg-dist`)
6. ระบบจะรีสตาร์ทหลังจากติดตั้งเสร็จสิ้น

ขั้นตอนที่ 3: หลังการอัปเกรดและการแก้ไขปัญหาเบื้องต้น

1. ตรวจสอบรุ่น:

   lsb_release -a
   cat /etc/os-release

2. อัปเดตแพ็กเกจของรุ่นใหม่:

   sudo apt update
   sudo apt upgrade
   sudo apt autoremove

3. ตรวจสอบการทำงานของบริการหลัก: เช่น Apache, MySQL, Docker, SSH

   sudo systemctl status ssh apache2 mysql

4. ปัญหาพบบ่อยและวิธีแก้:
   • รีพอซิทอรีของบุคคลที่สามพัง: ต้องอัปเดตลิงก์รีพอซิทอรีใน `/etc/apt/sources.list.d/` ให้เป็นรุ่น `jammy` (สำหรับ 22.04) หรือ `noble` (สำหรับ 24.04) หรือติดตั้งใหม่
   • ไดรเวอร์กราฟิกมีปัญหา: ลองใช้ไดรเวอร์โอเพนซอร์ส (`xserver-xorg-video-nouveau`) หรืออัปเดตไดรเวอร์ proprietary จาก “Software & Updates”
   • แอปพลิเคชันไม่ทำงาน: ตรวจสอบว่าต้องการไลบรารีรุ่นใหม่หรือไม่ หรือหาทางติดตั้งผ่าน Snap/Flatpak/AppImage แทน

กรณีศึกษาและแนวทางปฏิบัติที่ดีที่สุด (Best Practices)

กรณีศึกษา 1: บริษัทสตาร์ทอัพย้ายเว็บเซิร์ฟเวอร์จาก 18.04 ไป 22.04

สถานการณ์: มีเซิร์ฟเวอร์ 2 เครื่อง ให้บริการเว็บแอปพลิเคชัน (LEMP Stack: Linux, Nginx, MySQL, PHP) และเซิร์ฟเวอร์แอปพลิเคชัน (Node.js)

แผนการดำเนินงาน:

1. เตรียมเซิร์ฟเวอร์ใหม่: ติดตั้ง Ubuntu 22.04 LTS บนเซิร์ฟเวอร์ใหม่ (บนคลาวด์หรือฮาร์ดแวร์ใหม่)
2. ใช้ Infrastructure as Code: ใช้สคริปต์ Ansible ที่มีอยู่แล้ว deploy Nginx, MySQL, Node.js และการตั้งค่าความปลอดภัยพื้นฐานลงบนเซิร์ฟเวอร์ใหม่
3. ย้ายข้อมูล: ดัมป์ฐานข้อมูล MySQL จากเซิร์ฟเวอร์เก่าและกู้คืนลงใหม่, ซิงค์ไฟล์เว็บแอปพลิเคชันผ่าน rsync
4. ทดสอบ: ชี้ DNS record การทดสอบ (เช่น staging.example.com) ไปที่เซิร์ฟเวอร์ใหม่และทดสอบการทำงานอย่างละเอียด
5. สลับระบบ (Cut-over): ในเวลาที่ traffic ต่ำสุด (เช่น เที่ยงคืนวันเสาร์) ปรับ TTL ของ DNS ล่วงหน้า, ทำขั้นตอนที่ 3 อีกครั้งเพื่อเก็บข้อมูลล่าสุด, สลับ DNS record หลักไปที่เซิร์ฟเวอร์ใหม่
6. เฝ้าสังเกต: ตรวจสอบ error log และ performance ของเซิร์ฟเวอร์ใหม่อย่างใกล้ชิดหลังสลับระบบ

ผลลัพธ์: การย้ายระบบสำเร็จโดยมี Downtime น้อยกว่า 5 นาที และได้ระบบที่สะอาดและอัปเดตแล้ว

กรณีศึกษา 2: ห้องแล็บวิจัยอัปเกรดเดสก์ท็อป 50 เครื่อง

สถานการณ์: คอมพิวเตอร์ในห้องแล็บติดตั้ง Ubuntu 18.04 พร้อมซอฟต์แวร์เฉพาะทางด้านวิทยาศาสตร์หลายตัว

แผนการดำเนินงาน:

1. สร้าง Master Image: เลือกเครื่องทดสอบ 1 เครื่อง, ทำ Fresh Installation Ubuntu 22.04/24.04, ติดตั้งและคอนฟิกซอฟต์แวร์ทั้งหมดให้สมบูรณ์, ใช้เครื่องมือเช่น `systemback` (ในอดีต) หรือ `Cubic` เพื่อสร้าง ISO image ที่ปรับแต่งแล้ว
2. ทดสอบภาพ: Deploy ภาพดังกล่าวบนเครื่องทดสอบ 2-3 เครื่อง และให้ผู้ใช้ทดลองใช้งานจริง
3. แบ็กอัพข้อมูลผู้ใช้: ใช้สคริปต์เก็บข้อมูลใน `/home` ของแต่ละเครื่องขึ้นเซิร์ฟเวอร์กลาง
4. ติดตั้งภาพแบบไร้สาย (PXE Boot) หรือผ่าน USB: ติดตั้งภาพ Master ลงบนเครื่องทั้งหมดในเครือข่าย
5. คืนข้อมูลผู้ใช้: คืนข้อมูลจากเซิร์ฟเวอร์กลางกลับไปยังเครื่องแต่ละเครื่องหลังติดตั้ง

แนวทางปฏิบัติที่ดีที่สุดสำหรับทุกสถานการณ์

• ทดสอบในสภาพแวดล้อมที่ไม่ใช่ Production ก่อนเสมอ: สร้าง VM หรือใช้เครื่องสำรองเพื่อทดสอบกระบวนการอัปเกรดทั้งหมด
• มีแผน Rollback ที่ชัดเจน: รู้ว่าจะย้อนกลับไปสู่ระบบเดิมได้อย่างไรหากเกิดปัญหาร้ายแรง (เช่น จากแบ็กอัพเต็มระบบ)
• ตรวจสอบความเข้ากันได้ของซอฟต์แวร์เฉพาะทาง: ซอฟต์แวร์ทางวิทยาศาสตร์, การเงิน, หรือซอฟต์แวร์ล้าสมัยอาจทำงานบนไลบรารีรุ่นเก่า ต้องวางแผนใช้ Docker หรือ LXD เพื่อแยกสภาพแวดล้อมหากจำเป็น
• สื่อสารกับผู้ใช้: หากเป็นองค์กร ต้องแจ้งกำหนดการ Downtime และการเปลี่ยนแปลงที่อาจส่งผลต่อการทำงานล่วงหน้า
• ติดตาม Log อย่างใกล้ชิด: ตรวจสอบ `/var/log/dist-upgrade/` และ log ของระบบ (`journalctl`) หลังอัปเกรดเพื่อหาข้อผิดพลาดที่ซ่อนอยู่

การย้ายไป Ubuntu 24.04 LTS: สิ่งที่ต้องพิจารณาเพิ่มเติม

หากคุณตัดสินใจที่จะข้ามรุ่นไปที่ Ubuntu 24.04 LTS โดยตรงจาก 18.04 มีประเด็นสำคัญบางประการที่แตกต่างจากการอัปเกรดไป 22.04

• ต้องอัปเกรดสองขั้นตอน (Double Upgrade): โดยทั่วไป `do-release-upgrade` จะอนุญาตให้อัปเกรดจาก LTS รุ่นก่อนหน้าได้เพียงรุ่นเดียว (จาก 18.04 ไป 20.04) ดังนั้นคุณอาจต้องอัปเกรดไปที่ 20.04 ก่อน แล้วค่อยไป 22.04 และสุดท้ายไป 24.04 ซึ่งมีความเสี่ยงสูงและใช้เวลานาน ทางเลือกที่ดีกว่าคือการทำ Fresh Installation สำหรับการข้ามรุ่นที่มากขนาดนี้
• การเปลี่ยนแปลงครั้งใหญ่ของ GNOME: UI ของ GNOME 46 ใน Ubuntu 24.04 มีการปรับปรุงครั้งใหญ่ (เช่น ปุ่มปิด-ขยาย-ย่อหน้าต่างที่ย้ายไปด้านขวา, การจัดการ Workspace ใหม่) ผู้ใช้ต้องเตรียมใจและอาจต้องฝึกอบรมเล็กน้อย
• การสนับสนุนฮาร์ดแวร์รุ่นใหม่: Linux Kernel 6.8 รองรับฮาร์ดแวร์ล่าสุดได้ดีกว่า แต่ก็อาจลดการสนับสนุนไดรเวอร์สำหรับฮาร์ดแวร์ที่เก่ามากๆ ลง ตรวจสอบการทำงานของอุปกรณ์พิเศษเช่น Printer, Scanner, การ์ดจอ
• การเปลี่ยนมาใช้ Snap เป็นหลักสำหรับบางแพ็กเกจ: Ubuntu 24.04 ส่งมอบ Firefox และบางแอปเป็น Snap package โดยค่าเริ่มต้นมากขึ้น ผู้ใช้ที่ต้องการ .deb แบบเดิมอาจต้องติดตั้งจากช่องทางอื่นหรือปรับตัวกับการใช้ Snap

Summary

การอัปเกรดจาก Ubuntu 18.04 LTS ที่สิ้นสุดการสนับสนุนแล้ว เป็นภารกิจที่หลีกเลี่ยงไม่ได้สำหรับการรักษาความปลอดภัยและประสิทธิภาพของระบบ ไม่ว่าจะเลือกเส้นทางไปสู่ 22.04 LTS ที่พิสูจน์ความเสถียรแล้ว หรือก้าวกระโดดไปยัง 24.04 LTS ที่ทันสมัยที่สุด สิ่งสำคัญที่สุดคือการวางแผนอย่างรอบคอบ การแบ็กอัพข้อมูลอย่างไม่มีข้อยกเว้น และการทดสอบในสภาพแวดล้อมที่ไม่ใช่ Production ก่อนลงมือจริง สำหรับเซิร์ฟเวอร์ แนวโน้มการย้ายไปสู่การจัดการด้วย IaC และคอนเทนเนอร์จะทำให้การอัปเกรดในอนาคตง่ายขึ้นมาก ในขณะที่ผู้ใช้เดสก์ท็อปอาจพบว่าการติดตั้งใหม่พร้อมการย้ายข้อมูลเป็นวิธีที่สะอาดและน่าเชื่อถือที่สุด การอัปเกรดไม่ใช่แค่การได้ระบบปฏิบัติการรุ่นใหม่ แต่เป็นโอกาสในการทำความสะอาดระบบ ปรับปรุงความปลอดภัย และอัปเดตสถาปัตยกรรมให้ทันสมัย พร้อมรับมือกับความท้าทายในอีกหลายปีข้างหน้า