Immutable Linux สำหรับเซิร์ฟเวอร์ เลือกตัวไหนดี

Linux distro แบบ immutable คืออะไร

Linux distro แบบ immutable จะส่งมอบระบบปฏิบัติการในรูปแบบอิมเมจชุดเดียว ดังนั้นคุณจึงเปลี่ยนระบบแทนการแพตช์ไฟล์ในที่เดิม ไม่มีการเขียนทับไฟล์ภายใต้ apt upgrade ใน /usr ขณะที่เครื่องกำลังทำงาน คุณสร้างหรือดึงอิมเมจใหม่ขึ้นมา เครื่องจะเตรียมอิมเมจนั้นไว้ข้างๆ อิมเมจที่กำลังรันอยู่ และการรีบูตครั้งถัดไปจะเป็นการสลับอิมเมจที่ใช้งาน อิมเมจเดิมจะยังคงอยู่ในดิสก์ ดังนั้นการย้อนกลับการอัปเดตที่ผิดพลาดจึงทำได้เพียงแค่การรีบูต

คำว่า "immutable" อาจเป็นการกล่าวเกินจริง ไม่มีสิ่งใดขัดขวาง root จากการเขียนข้อมูลลงดิสก์ได้ในทางกายภาพ สิ่งที่ระบบเหล่านี้ทำคือการ mount ไดเรกทอรีของระบบแบบอ่านอย่างเดียว (read-only) และกำหนดความเป็นเจ้าของให้กับอิมเมจ ข้อมูลที่คงอยู่ถาวรจะอยู่ใน /var การตั้งค่าเฉพาะของเครื่องจะอยู่ใน /etc ทุกอย่างภายใต้ /usr เป็นของอิมเมจ ซึ่งเป็นเหตุผลว่าทำไมเซิร์ฟเวอร์สองเครื่องที่รันอิมเมจแท็กเดียวกันจึงมีไฟล์ระบบที่เหมือนกันทุกประการ

ชื่อเรียกของ Red Hat สำหรับทั้งสองโมเดลนี้มีความชัดเจนที่สุด ได้แก่ package mode และ image mode โดย package mode คือระบบที่กำลังทำงานร่วมกับตัวจัดการแพ็กเกจที่คอยแก้ไขไฟล์ในระบบ ส่วน image mode คือขั้นตอนการสร้างที่เกิดขึ้นที่อื่นเพื่อผลิตอาร์ทิแฟกต์ (artifact) ออกมา และเซิร์ฟเวอร์ที่มีหน้าที่เพียงอย่างเดียวคือการบูตอาร์ทิแฟกต์ที่คุณกำหนดให้ ทุกอย่างที่กล่าวถึงด้านล่างนี้ล้วนเป็นผลมาจากความแตกต่างเพียงประการเดียวนี้

เหตุผลที่ระบบแบบ read-only มีความสำคัญต่อเซิร์ฟเวอร์

เซิร์ฟเวอร์ที่เปิดใช้งานมานาน 2 ปีมักมีประวัติการเปลี่ยนแปลงที่ไม่มีใครจดบันทึกไว้ ไม่ว่าจะเป็น make install ที่ทำขึ้นอย่างเร่งรีบในช่วงค่ำคืน การเพิ่ม repository จากภายนอกเพื่อติดตั้งเพียงแพ็กเกจเดียว หรือไฟล์ config ที่ถูกแก้ไขระหว่างเกิดเหตุขัดข้องแต่ไม่เคยถูกนำกลับไปรวมในระบบ configuration management สิ่งเหล่านี้เรียกว่า configuration drift ซึ่งเป็นสาเหตุที่ว่าทำไมการสร้างเซิร์ฟเวอร์ "เครื่องเดิม" ขึ้นมาใหม่ตามบันทึกที่จดไว้ มักจะได้ผลลัพธ์การทำงานที่แตกต่างออกไป บันทึกเหล่านั้นเก็บไว้เพียงความตั้งใจ แต่สิ่งที่อยู่บนดิสก์คือความจริง

โหมด image ช่วยกำจัดพื้นที่ที่ drift มักจะสะสมตัวอยู่ /usr จะถูกตั้งค่าเป็น read-only ในขณะรันไทม์ ดังนั้นการติดตั้งซอฟต์แวร์ด้วยมือจะล้มเหลวทันที หรือไม่ก็ถูกบันทึกเป็นเลเยอร์ที่คุณสามารถแสดงรายการออกมาได้ด้วยคำสั่งเดียว สิ่งนี้ทำให้ความแตกต่างระหว่างเครื่องสองเครื่องสามารถมองเห็นได้ชัดเจน แทนที่จะต้องมาขุดคุ้ยหาสาเหตุเหมือนการทำโบราณคดี นี่คือปัญหาเดียวกันกับที่ รายการตรวจสอบการบำรุงรักษาเซิร์ฟเวอร์ Linux ทั่วไป พยายามแก้ไขด้วยวินัยในการทำงาน แต่ในกรณีนี้ระบบไฟล์จะเป็นตัวจัดการให้โดยอัตโนมัติ

การย้อนกลับคือการรีบูต และนั่นคือจุดเด่นทั้งหมดของแนวทางนี้

ความล้มเหลวที่โมเดลนี้ถูกออกแบบมาเพื่อรองรับคือสิ่งที่เราได้จัดทำเอกสารไว้แล้ว นั่นคือ VPS ที่ไม่สามารถบูตได้หลังจากการอัปเดตเคอร์เนล ในโหมดแพ็กเกจ คุณจะกู้คืนระบบผ่าน rescue console ของผู้ให้บริการ คุณต้อง mount ดิสก์, ทำ chroot เข้าไป และลบแพ็กเกจเคอร์เนลออกด้วยตนเอง วิธีนี้ได้ผลเพราะ bootloader ยังคงเก็บเคอร์เนลเวอร์ชันเก่าไว้ แต่มีเพียงเคอร์เนลเท่านั้นที่มีการจัดการเวอร์ชันในลักษณะนี้ ส่วนการอัปเดต glibc และการเปลี่ยนแปลงของ systemd ที่มาพร้อมกับธุรกรรมเดียวกันนั้นถูกนำไปใช้แล้ว และไม่มีคำสั่งเดียวที่สามารถย้อนการเปลี่ยนแปลงเหล่านั้นกลับไปพร้อมกันได้

ในโหมดอิมเมจ หน่วยการจัดการคือระบบทั้งหมด บนโฮสต์ bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback จะสลับลำดับของ bootloader กลับไปยังรายการบูตก่อนหน้า ซึ่งก็คืออิมเมจที่คุณใช้งานเมื่อชั่วโมงที่แล้ว ทั้งเคอร์เนลและ userspace จะกลับมาพร้อมกัน ไม่มีการดาวน์โหลดหรือสร้างใหม่ใดๆ เพราะอิมเมจเก่ายังคงอยู่ในดิสก์เสมอ

Fedora CoreOS ใช้วิธีการเดียวกันภายใต้ชื่อที่แตกต่างกัน:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

ให้หยุดการทำงานของ Zincati ก่อน Zincati คือเอเจนต์ที่คอยอัปเดตเครื่อง Fedora CoreOS ให้เป็นเวอร์ชันล่าสุด ดังนั้นหากคุณปล่อยให้มันทำงานต่อไป มันจะเตรียมการอัปเดตที่คุณเพิ่งย้อนกลับไปอีกครั้ง -r จะทำการรีบูตเมื่อการย้อนกลับถูกเตรียมพร้อมแล้ว เพื่อป้องกันไม่ให้ deployment ที่คุณเชื่อถือถูกลบออกโดยกระบวนการ garbage collection:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status จะแสดงรายการ deployment ตามลำดับที่ bootloader จะนำเสนอ โดยทำเครื่องหมายตัวที่กำลังทำงานอยู่ด้วยจุด และแสดง Pinned: yes บนตัวที่คุณปักหมุดไว้

Talos ใช้วิธีการเรียกผ่าน API เพียงครั้งเดียวจากเวิร์กสเตชันของคุณ:

talosctl rollback --nodes 10.20.30.40

Flatcar จะเก็บพาร์ทิชัน /usr ไว้สองชุดและสลับการใช้งานระหว่างกัน แต่ละช่องจะมีลำดับความสำคัญและตัวนับจำนวนครั้งในการลอง (try counter) อยู่ในตารางพาร์ทิชัน ดังนั้นหากช่องใดไม่สามารถบูตได้สำเร็จ ระบบจะลองจนครบจำนวนครั้งที่กำหนดและ bootloader จะเลือกอีกช่องหนึ่งแทน ตรวจสอบว่าคุณกำลังใช้งานช่องใดและมีการทำเครื่องหมายว่าใช้งานได้ปกติหรือไม่:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

ช่องที่ทำงานได้ปกติจะแสดงบรรทัดที่มี priority=1 tries=0 successful=1 หากไม่พบข้อความดังกล่าว หมายความว่าช่องปัจจุบันยังไม่ได้รับการยืนยัน ซึ่งเป็นสถานะที่เครื่องจะค้างอยู่ระหว่างการอัปเดตและการบูตที่สมบูรณ์ครั้งแรก

สิ่งที่ใช้แทน "การติดตั้งแพ็กเกจ": bootc และ Containerfile

bootc เป็นเครื่องมือที่ทำให้รูปแบบนี้เป็นมาตรฐานทั่วไป โดยนิยามตัวเองว่าเป็นการอัปเดตระบบปฏิบัติการแบบ transactional และ in-place โดยใช้ OCI (Open Container Initiative) container image และเป็นโครงการภายใต้ CNCF Sandbox เซิร์ฟเวอร์ของคุณจะกลายเป็น Containerfile ณ เดือนสิงหาคม 2026 base image ของ Fedora คือ quay.io/fedora/fedora-bootc:44 และ base image ของ CentOS Stream คือ quay.io/centos-bootc/centos-bootc:stream10

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

สร้างและ push image เหมือนกับ image อื่นๆ:

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

จากนั้นบนเซิร์ฟเวอร์:

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade จะสอบถามแหล่งที่มาของ image และจัดคิว image ใหม่สำหรับการบูตครั้งถัดไป --check จะรายงานว่ามีการอัปเดตหรือไม่โดยไม่มีการเปลี่ยนแปลงใดๆ --apply จะรีบูตเข้าสู่ image ใหม่ bootc switch registry.example.com/edge/web:next จะชี้เครื่องไปยัง image อื่นโดยยังคงรักษา /etc และ /var ไว้ ซึ่งเป็นวิธีที่คุณใช้ย้ายเซิร์ฟเวอร์ระหว่าง image stream โดยไม่ต้องติดตั้งใหม่

สำหรับการอัปเดตแบบอัตโนมัติ ให้เปิดใช้งาน timer ที่มาพร้อมกับโครงการ:

sudo systemctl enable --now bootc-fetch-apply-updates.timer

นี่คือคำตอบในรูปแบบ image-mode สำหรับ unattended upgrades บน Ubuntu และ dnf-automatic บน Rocky และ Alma ความแตกต่างอยู่ที่สิ่งที่ถูกติดตั้งลงไป timer ในรูปแบบ package-mode จะใช้เวอร์ชันใดก็ตามที่มีอยู่ใน repository ในคืนนั้น ทำให้ผลลัพธ์ของชุดซอฟต์แวร์บนแต่ละเครื่องแตกต่างกันเล็กน้อย ในขณะที่ timer ในรูปแบบ image-mode จะใช้ artifact ชุดเดียวกับที่คุณเคยบูตใช้งานที่อื่นมาแล้ว

กฎการ build สองข้อที่ตามมาจาก Containerfile นั้นคือ ข้อมูลที่เขียนได้ (writable data) ต้องอยู่ภายใต้ /var ดังนั้นซอฟต์แวร์ที่จำเป็นต้องเขียนข้อมูลลงในไดเรกทอรีติดตั้งของตัวเองจำเป็นต้องใช้ symlink หรือเพิ่มบรรทัด BindPaths= ของ systemd ในขั้นตอนการ build และ /etc จะถูกรวมแบบ three-way merge ในระหว่างการอัปเดต ซึ่งหมายความว่าไฟล์ที่คุณไม่เคยแก้ไขจะได้รับเวอร์ชันใหม่จาก image ในขณะที่ไฟล์ที่คุณแก้ไขไว้ในเครื่องจะถูกคงไว้

เมื่อคุณต้องการเครื่องมือบนเครื่องที่กำลังทำงานอยู่เพื่อการดีบั๊กชั่วคราว:

sudo bootc usr-overlay
sudo dnf -y install strace

คำสั่งนี้จะเพิ่ม transient writable overlay บน /usr ซึ่งจะถูกลบทิ้งเมื่อรีบูตเครื่องครั้งถัดไป วิธีนี้ใช้สำหรับการตรวจสอบปัญหา ไม่ใช่การแก้ไขปัญหา คุณไม่สามารถเปลี่ยน kernel ด้วยวิธีนี้ และทุกอย่างที่คุณติดตั้งจะหายไปเมื่อรีบูตตามการออกแบบของระบบ

Fedora CoreOS: ติดตั้งครั้งเดียว อัปเดตตลอดไป

Fedora CoreOS ไม่มีตัวติดตั้งแบบโต้ตอบ คุณต้องเขียนไฟล์ Butane YAML แล้วแปลงเป็น Ignition JSON จากนั้นจึงส่งไฟล์นี้ให้เครื่องในระหว่างการบูตครั้งแรก:

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition จะทำงานใน initramfs เฉพาะการบูตครั้งแรกเท่านั้น นี่คือจุดที่ผู้ใช้งานที่ย้ายมาจาก cloud-init มักจะพลาด หากคอนฟิกไม่มี SSH key เครื่องจะบูตขึ้นมาโดยไม่มีทางเข้าถึงได้ และวิธีแก้ไขคือต้องติดตั้งใหม่ตั้งแต่ต้น ควรทดสอบคอนฟิกบนเครื่องทดลองก่อนนำไปใช้กับเซิร์ฟเวอร์จริง

การติดตั้งลงดิสก์จากสภาพแวดล้อมแบบ live:

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

การอัปเดตเป็นแบบอัตโนมัติโดยค่าเริ่มต้น คุณสามารถควบคุมได้ว่าจะให้อัปเดตเมื่อใด แต่ไม่สามารถเลือกที่จะไม่อัปเดตได้ ให้สร้างไฟล์ TOML ไว้ที่ /etc/zincati/config.d/55-updates-strategy.toml เพื่อกำหนดกลยุทธ์การอัปเดตตามช่วงเวลา:

[updates]
strategy = "periodic"

ภายใต้กลยุทธ์ดังกล่าว คุณสามารถเพิ่มช่วงเวลาการบำรุงรักษาได้หนึ่งรายการต่อหนึ่ง array-of-tables โดยแต่ละช่วงเวลาจะขึ้นต้นด้วยชื่อ updates.periodic.window ภายในวงเล็บเหลี่ยมคู่เป็นส่วนหัว ตามด้วยคีย์สามรายการ:

• days: รายชื่อวัน เช่น "Sat" และ "Sun"
• start_time: เวลาที่เริ่มช่วงเวลาการบำรุงรักษา เขียนในรูปแบบ "22:30"
• length_minutes: ระยะเวลาที่เปิดให้ดำเนินการ เช่น 60

เวลาเหล่านี้เป็นเวลา UTC หากต้องการหยุดการอัปเดตโดยสิ้นเชิง ให้รันคำสั่ง sudo systemctl disable --now zincati.service และยอมรับว่าคุณจะต้องรับผิดชอบตารางการแพตช์ระบบด้วยตนเอง

Package layering มีไว้เพื่อเป็นทางเลือกสำรอง:

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

คำสั่งนี้จะสร้าง deployment ใหม่โดยเพิ่มแพ็กเกจเข้าไป และการเปลี่ยนแปลงจะมีผลหลังจากรีบูตเท่านั้น ต้นทุนจะตามมาในภายหลัง เนื่องจากชุดแพ็กเกจที่คุณเพิ่มจะถูกนำไปติดตั้งทับบน base image ใหม่ทุกครั้ง ดังนั้นหากแพ็กเกจใดหายไปจาก repository ในวันที่อัปเดต จะส่งผลให้การอัปเดตล้มเหลว เอกสารของ Fedora แนะนำให้ใช้คอนเทนเนอร์สำหรับงานส่วนใหญ่ และใช้ bootc image เมื่อคุณจำเป็นต้องปรับแต่งระบบปฏิบัติการจริงๆ

Flatcar Container Linux: ไม่มีตัวจัดการแพ็กเกจใดๆ ทั้งสิ้น

Flatcar เป็นการสืบทอดต่อจาก CoreOS Container Linux และเป็นตัวเลือกที่มีความเข้มงวดที่สุดในบรรดาตัวเลือกสำหรับวัตถุประสงค์ทั่วไป โดยไม่มีตัวจัดการแพ็กเกจให้ใช้งาน ทุกสิ่งที่คุณรันจะเป็นคอนเทนเนอร์ การจัดเตรียมระบบ (provisioning) ใช้ Ignition เช่นเดียวกับ Fedora CoreOS การอัปเดตใช้พาร์ทิชัน A/B /usr สองส่วนตามที่อธิบายไว้ข้างต้น โดยขับเคลื่อนด้วย update_engine และมี locksmithd เป็นตัวกำหนดเวลาที่จะทำการรีบูต

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT หมายความว่าสล็อตสำรอง (passive slot) ได้รับอิมเมจใหม่เรียบร้อยแล้วและเหลือเพียงขั้นตอนการรีบูตเท่านั้น กลยุทธ์การรีบูตเริ่มต้นคือ reboot โดยมีการหน่วงเวลา 5 นาที ดังนั้น VPS ในระบบผลิต (production) เครื่องเดียวจะรีสตาร์ทตามกำหนดเวลาของมันเองเว้นแต่คุณจะตั้งค่าเป็นอย่างอื่น คุณสามารถกำหนดช่วงเวลาได้ใน /etc/flatcar/update.conf:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

REBOOT_STRATEGY=off จะปล่อยให้การรีบูตเป็นหน้าที่ของคุณ ส่วน SERVER=disabled ในไฟล์เดียวกันจะหยุดการตรวจสอบการอัปเดตโดยสิ้นเชิง สำหรับคลัสเตอร์ การใช้ REBOOT_STRATEGY=etcd-lock ร่วมกับ locksmithctl set-max 4 จะช่วยจำกัดจำนวนโหนดที่สามารถรีบูตได้ในเวลาเดียวกัน เพื่อไม่ให้การอัปเดตทำให้ระบบทั้งหมดหยุดทำงานพร้อมกัน

Talos Linux: ไม่มีเชลล์, ไม่มี SSH, ไม่มีคอนโซล

Talos เป็นระบบปฏิบัติการที่จำกัดขอบเขตการทำงานมากที่สุดในบรรดาสี่ตัวเลือก และมีความชัดเจนในวัตถุประสงค์อย่างยิ่ง โดยทำหน้าที่รันโหนด Kubernetes เท่านั้น ระบบนี้ไม่มี SSH daemon, ไม่มีเชลล์ และไม่มีการล็อกอินผ่านคอนโซล การดำเนินการทุกอย่างทำผ่านการเรียก gRPC API ด้วย talosctl จากเวิร์กสเตชันของคุณ โดยอ้างอิงกับ machine config ที่คุณจัดเก็บไว้ใน git

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

ให้แทนที่แท็กด้วยเวอร์ชันของ release ที่คุณต้องการย้ายไป การอัปเกรดใช้รูปแบบ A-B ซึ่งจะเก็บ kernel และ OS image เวอร์ชันก่อนหน้าไว้ ดังนั้นหากเวอร์ชันใหม่ไม่สามารถบูตได้ Talos จะย้อนกลับ (rollback) โดยอัตโนมัติโดยที่คุณไม่ต้องเข้าไปจัดการ การดีบั๊กจะแตกต่างออกไปเนื่องจากไม่มีเชลล์ให้ใช้งาน คุณต้องใช้ talosctl logs และ talosctl dmesg แทนการใช้ journalctl บนตัวเครื่อง

หากภาระงานของคุณไม่ใช่ Kubernetes แสดงว่า Talos ไม่ใช่คำตอบที่เหมาะสม แต่หากเป็น Kubernetes Talos จะช่วยกำจัดเหตุการณ์ไม่พึงประสงค์ประเภทหนึ่งออกไปได้ทั้งหมด เพราะปัญหาที่เกิดจาก "มีคนล็อกอินเข้าไปในโหนดแล้วแก้ไขค่าบางอย่าง" จะไม่สามารถเกิดขึ้นได้อีกต่อไป

สิ่งที่ผู้เช่า VPS ต้องสูญเสียไปจริงๆ

การติดตั้งแบบเฉพาะกิจบนระบบที่กำลังทำงานอยู่ นี่คือประเด็นสำคัญ การใช้ sudo apt install htop ตอนตี 2 ระหว่างเกิดเหตุการณ์ไม่คาดคิดนั้นทำไม่ได้ ในระบบ bootc คุณจะได้ overlay ชั่วคราวที่จะหายไปเมื่อรีบูต ใน Fedora CoreOS คุณจะได้การปรับใช้แบบเลเยอร์ที่ต้องอาศัยการรีบูต ส่วนใน Flatcar และ Talos คุณจะทำอะไรไม่ได้เลย

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

Kernel modules เคอร์เนลมาจากอิมเมจ ดังนั้นโมดูลที่คอมไพล์สำหรับเคอร์เนลที่กำลังทำงานอยู่จะไม่คงอยู่หลังการอัปเดตครั้งถัดไป โมดูลที่อยู่นอกเคอร์เนลหลักและแพ็กเกจ DKMS (dynamic kernel module support) จะต้องถูกสร้างรวมเข้าไปในอิมเมจโดยอ้างอิงกับเคอร์เนลของอิมเมจนั้นๆ สิ่งใดก็ตามที่ต้องการโมดูลซึ่งไม่มีอยู่ในอิมเมจพื้นฐานจะกลายเป็นปัญหาเรื่องการสร้างอิมเมจแทนที่จะเป็นปัญหาเรื่องการติดตั้ง

เอเจนต์ของผู้ให้บริการและผู้จำหน่าย เอเจนต์สำหรับตรวจสอบระบบและสำรองข้อมูลมักมาในรูปแบบ .deb หรือ .rpm พร้อมสคริปต์ติดตั้งที่เขียนลงใน /usr และเปิดใช้งาน unit บนระบบที่อ่านได้อย่างเดียว สคริปต์เหล่านี้จะทำงานล้มเหลว ผู้จำหน่ายบางรายเผยแพร่อิมเมจในรูปแบบคอนเทนเนอร์หรือมีเอกสารการติดตั้งแบบ image-mode แต่หลายรายไม่มี ให้ตรวจสอบเรื่องนี้ก่อนตัดสินใจใช้งาน เพราะกลุ่มเซิร์ฟเวอร์ที่คุณไม่สามารถตรวจสอบสถานะได้นั้นแย่ยิ่งกว่ากลุ่มเซิร์ฟเวอร์ที่ค่าคอนฟิกคลาดเคลื่อนไปจากเดิม

ตัวอิมเมจเอง แทบไม่มีแผงควบคุม VPS ใดแสดงรายการ Fedora CoreOS, Flatcar หรือ Talos เคียงข้างกับ Ubuntu และ Debian คุณต้องจัดหาดิสก์เอง ซึ่งเป็นหัวข้อถัดไป

Getting one of these onto a VPS you rent

Confirm two things about your provider first: that you have out-of-band console access, meaning VNC or a serial console, and that you can boot a rescue system. Without a console, a machine that does not come back is a support ticket instead of a five-minute fix.

If the provider accepts custom images, upload the vendor's raw or qcow2 image and the job is done. Otherwise you write the disk yourself from the rescue system. Flatcar ships a self-contained script for exactly this, and it runs from any Linux:

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

Run that from the rescue system, never from the server you are replacing, because the script repartitions the target device while it works. It needs at least 8 GB of usable space on the device, and the rescue environment must provide bash, bzip2 or lbzip2, lsblk, wget, udevadm, gpg and gawk. Your ignition.json must contain an SSH key, or the installed system will have no way to let you in.

Fedora CoreOS has the same shape, and its installer runs as a container:

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

Check the device name with lsblk before you run it. Writing to the wrong device destroys whatever was on it, and there is no confirmation prompt.

bootc offers the one path that skips rescue mode, because it converts a running Linux system in place:

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

Read the documentation for the base image you are using before you run that, and try it on a server you can throw away. After the reboot the machine runs the image, and the package set you had is gone.

ใครควรใช้ immutable server และใครไม่ควรใช้

คุณควรเลือกใช้หากคุณมองว่าเซิร์ฟเวอร์เป็นเหมือนปศุสัตว์ (cattle) คือการมีเครื่องจำนวนมากที่สร้างจากพิมพ์เขียวเดียวกัน เช่น CI (continuous integration) runners ที่มีอายุการใช้งานเพียงหนึ่งชั่วโมง, โหนด k3s หรือ Kubernetes ที่ถูกเปลี่ยนใหม่แทนการซ่อมแซม หรือกรณีใดก็ตามที่วิธีแก้ปัญหาเมื่อเซิร์ฟเวอร์พังคือ "ลบทิ้งแล้วสร้างใหม่" นอกจากนี้ยังเป็นประโยชน์เมื่อคุณต้องพิสูจน์ต่อผู้ตรวจสอบว่ามีซอฟต์แวร์ใดทำงานอยู่บนเครื่องบ้าง เพราะคำตอบจะเป็น image digest แทนที่จะเป็นรายการแพ็กเกจ

คุณไม่ควรเลือกใช้หากคุณมี VPS เพียงเครื่องเดียวที่ดูแลด้วยมือและรันบริการ 3 อย่าง โดยที่คุณติดตั้งซอฟต์แวร์ตามความต้องการและไม่มี build pipeline การใช้โหมด image ไม่ได้ช่วยลดภาระงาน แต่เป็นการย้ายภาระงานจากเซิร์ฟเวอร์ไปไว้ที่ขั้นตอนการ build และทำให้คุณต้องมี registry กับ pipeline เพิ่มขึ้น หากคุณมีพื้นที่รองรับงานส่วนนี้ คุณจะได้เซิร์ฟเวอร์ที่เหมือนกันทุกประการและสามารถย้อนกลับ (rollback) ได้เพียงแค่การรีบูต แต่หากคุณไม่มี คุณเพียงแค่เพิ่มความซับซ้อนให้กับระบบที่เดิมก็ทำงานได้ดีอยู่แล้ว และจะทำให้การแก้ไขปัญหาตอนตี 2 ยากขึ้นกว่าเดิม

ทางสายกลางที่เรียบง่ายยังคงใช้งานได้ดี นั่นคือการใช้ Linux distribution ปกติที่ตั้งค่า automatic security updates ควบคู่ไปกับการซ้อม rebuild ระบบที่คุณได้ฝึกฝนจริง การเลือก OS พื้นฐานเป็นการตัดสินใจเฉพาะตัว ซึ่งครอบคลุมอยู่ใน การเลือก OS สำหรับรันบน VPS ของคุณ โหมด image เป็นเพียงวิวัฒนาการล่าสุดของการถกเถียงที่มีมานานเกี่ยวกับวิธีการส่งมอบซอฟต์แวร์ไปยังเครื่องเซิร์ฟเวอร์ และ ประวัติของ Linux distributions ก็คือการถกเถียงเรื่องเดิมที่วนเวียนซ้ำไปมานั่นเอง

FAQ

Linux แบบ immutable นั้น immutable จริงหรือไม่?

ไม่จริง และชื่อนี้มักทำให้เกิดความเข้าใจผิด ผู้ใช้ระดับ root ยังคงเขียนข้อมูลลงดิสก์ได้ สิ่งที่เกิดขึ้นจริงคือ /usr จะถูก mount แบบอ่านได้อย่างเดียว (read-only) ในขณะรันไทม์ และจะถูกแทนที่ด้วยอิมเมจใหม่ทั้งหมดในการอัปเดตครั้งถัดไป ในขณะที่ /etc และ /var จะยังคงเขียนข้อมูลได้และคงอยู่หลังการอัปเดต การเปลี่ยนแปลงที่คุณทำภายใต้ /usr จะถูกปฏิเสธในขณะนั้นหรือไม่ก็ถูกลบทิ้งเมื่อมีการอัปเดตครั้งถัดไป ดังนั้นผลลัพธ์ในทางปฏิบัติคือไดเรกทอรีของระบบจะเปลี่ยนแปลงก็ต่อเมื่ออิมเมจมีการเปลี่ยนแปลงเท่านั้น

ฉันสามารถรัน Fedora CoreOS หรือ Flatcar บน VPS ที่ไม่มีตัวเลือกนี้ให้ได้หรือไม่?

โดยปกติแล้วทำได้ หากผู้ให้บริการมีระบบ rescue และให้สิทธิ์เข้าถึง console คุณสามารถบูตเข้าสู่โหมด rescue แล้วเขียนอิมเมจดิสก์ของ distribution ลงใน block device จากนั้นจึงรีบูต สคริปต์ flatcar-install ของ Flatcar สามารถทำสิ่งนี้ได้จาก Linux ทุกตัว และ Fedora CoreOS ก็มี coreos-installer ในรูปแบบคอนเทนเนอร์ที่คุณสามารถรันด้วยวิธีเดียวกัน ทั้งสองระบบต้องการไฟล์ Ignition ที่มี SSH key ของคุณ เนื่องจากไม่มีการถามรหัสผ่านเมื่อบูตครั้งแรก หากไม่มีสิทธิ์เข้าถึง console อย่าพยายามทำ เพราะหากเครื่องไม่กลับมาทำงาน คุณจะไม่สามารถตรวจสอบสาเหตุได้เลย

ฉันจะติดตั้งแพ็กเกจบนเซิร์ฟเวอร์แบบ immutable ได้อย่างไร?

คุณต้องเพิ่มแพ็กเกจนั้นลงในอิมเมจแล้วทำการ deploy ใหม่ สำหรับ bootc วิธีนี้คือการเพิ่มบรรทัด RUN dnf -y install ... ใน Containerfile, ทำการ build ใหม่, push อิมเมจ แล้วรัน sudo bootc upgrade --apply บนเครื่องนั้น สำหรับ Fedora CoreOS คุณสามารถทำ layering ด้วย sudo rpm-ostree install แล้วรีบูต โดยมีข้อแลกเปลี่ยนคือแพ็กเกจนั้นจะถูกติดตั้งใหม่ทุกครั้งที่มีการอัปเดตในอนาคต สำหรับ Flatcar และ Talos จะไม่มีตัวจัดการแพ็กเกจ ดังนั้นคำตอบคือการใช้คอนเทนเนอร์ สำหรับเครื่องมือแก้ปัญหาเฉพาะกิจบนโฮสต์ bootc คำสั่ง sudo bootc usr-overlay จะช่วยให้คุณได้ /usr ที่เขียนข้อมูลได้ ซึ่งจะหายไปเมื่อรีบูตครั้งถัดไป

Image mode ช่วยแก้ปัญหา VPS ที่บูตไม่ขึ้นหลังอัปเดต kernel ได้หรือไม่?

มันเปลี่ยนขั้นตอนการกู้คืนจากการต้องใช้ rescue-console ให้กลายเป็นเพียงการรีบูต อิมเมจก่อนหน้าซึ่งรวมถึง kernel และ userspace จะยังคงอยู่บนดิสก์ ดังนั้น sudo bootc rollback หรือ sudo rpm-ostree rollback -r จะช่วยให้คุณย้อนกลับไปใช้เวอร์ชันเดิมได้ Talos และ Flatcar ทำได้มากกว่านั้นโดยการย้อนกลับอัตโนมัติเมื่อ slot ใหม่บูตไม่สำเร็จ เนื่องจากรายการบูตจะถูกตั้งเป็นค่าเริ่มต้นก็ต่อเมื่อบูตสำเร็จหนึ่งครั้งเท่านั้น สิ่งเหล่านี้ไม่ได้ป้องกันการอัปเดตที่ผิดพลาด แต่ช่วยให้การแก้ไขทำได้ง่ายและประหยัดเวลา

ฉันควรเลือก immutable distro ตัวไหนสำหรับเซิร์ฟเวอร์?

เลือก bootc หากคุณต้องการเซิร์ฟเวอร์ Linux อเนกประสงค์ที่คุณสร้างเหมือนอิมเมจคอนเทนเนอร์และสามารถติดตั้งลงบนเครื่องที่คุณมีอยู่แล้วได้ เลือก Fedora CoreOS หากคุณต้องการโมเดลการทำงานแบบเดียวกันโดยมีการสร้างอิมเมจให้และมีการอัปเดตอัตโนมัติมาให้พร้อมใช้งาน เลือก Flatcar หากคุณต้องการโฮสต์คอนเทนเนอร์ขนาดเล็กที่มีระบบอัปเดตแบบ A/B และไม่มีตัวจัดการแพ็กเกจให้ใช้งาน เลือก Talos เฉพาะเมื่อเครื่องนั้นเป็นโหนดของ Kubernetes เท่านั้น เนื่องจากมันไม่มี shell และไม่รันซอฟต์แวร์อื่นใดนอกเหนือจากนี้