Linux แบบ Immutable บนเซิร์ฟเวอร์ คุ้มไหมสำหรับ VPS

ดิสโทร Linux แบบ immutable คืออะไร

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

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

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

เหตุใดระบบแบบ read-only จึงสำคัญต่อเซิร์ฟเวอร์มากกว่า

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

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

การ rollback คือการ reboot และนี่คือจุดเด่นทั้งหมด

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

ในโหมด image หน่วยที่ rollback คือทั้งระบบ บน host ที่ใช้ bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback สลับลำดับของ bootloader กลับไปยัง boot entry ก่อนหน้า ซึ่งเป็น image ที่กำลังใช้งานเมื่อ 1 ชั่วโมงก่อน โดยมีทั้ง kernel และ userspace อยู่ด้วยกัน ไม่มีการดาวน์โหลดและไม่มีการ build ใหม่ เพราะ image เดิมยังคงอยู่บนดิสก์

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

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

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

sudo ostree admin pin 0
rpm-ostree status

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

Talos ทำเช่นเดียวกันด้วย API call เดียวจาก workstation ของคุณ:

talosctl rollback --nodes 10.20.30.40

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

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

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

อะไรมาแทน “ติดตั้งแพ็กเกจ”: bootc และ Containerfile

bootc เป็นเครื่องมือที่ทำให้รูปแบบนี้เป็นแนวทางทั่วไป โดยอธิบายตัวเองว่าเป็นการอัปเดตระบบปฏิบัติการแบบ transactional และ in-place โดยใช้ container image ของ OCI (open container initiative) และเป็นโครงการ CNCF Sandbox เซิร์ฟเวอร์ของคุณจะกลายเป็น Containerfile ณ เดือน August 2026 Fedora base image คือ quay.io/fedora/fedora-bootc:44 และ CentOS Stream base คือ 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

Build และ push เหมือน 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 จะ query แหล่งที่มาของ image และจัดคิว image ใหม่ไว้สำหรับการบูตครั้งถัดไป --check รายงานว่ามี update หรือไม่ โดยไม่เปลี่ยนแปลงอะไร --apply reboot ระบบเข้า image ดังกล่าว bootc switch registry.example.com/edge/web:next เปลี่ยนให้เครื่องใช้ image อื่น โดยคง /etc และ /var ไว้ วิธีนี้ทำให้ย้ายเซิร์ฟเวอร์ระหว่าง image stream ได้โดยไม่ต้องติดตั้งระบบใหม่

หากต้องการ update แบบไม่ต้องดูแลเอง ให้ enable timer ที่โครงการจัดเตรียมไว้:

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

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

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

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

sudo bootc usr-overlay
sudo dnf -y install strace

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

Fedora CoreOS: provisioned once, updated forever

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 มักเข้าใจผิด หาก config ไม่มี SSH key เครื่องจะบูตโดยไม่มีช่องทางให้เข้าถึง และต้องแก้ไขด้วยการ provision เครื่องใหม่ตั้งแต่ต้น ควรทดสอบ config บนเครื่องที่ทิ้งได้ก่อนนำไปใช้กับเซิร์ฟเวอร์ที่ต้องการเก็บไว้ใช้งาน

การติดตั้งลงดิสก์จาก live environment:

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

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

[updates]
strategy = "periodic"

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

• days รายการชื่อวัน เช่น "Sat" และ "Sun"
• start_time เวลาที่ window เปิด โดยเขียนเป็น "22:30"
• length_minutes ระยะเวลาที่ window เปิด เช่น 60

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

มี Package layering เป็นทางเลือกสำหรับกรณีจำเป็น:

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

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

Flatcar Container Linux: ไม่มี package manager เลย

Flatcar เป็นรุ่นต่อเนื่องจาก CoreOS Container Linux และเป็นตัวเลือกแบบ general-purpose ที่มีข้อจำกัดเข้มงวดที่สุด ไม่มี package manager ให้ใช้เป็นทางเลือกสำรอง ทุกอย่างที่รันอยู่จะเป็น container การเตรียมระบบใช้ Ignition เช่นเดียวกับ Fedora CoreOS การอัปเดตใช้พาร์ทิชัน /usr แบบ A/B สองพาร์ทิชันตามที่อธิบายไว้ข้างต้น โดยมี update_engine เป็นตัวดำเนินการ และ locksmithd เป็นตัวกำหนดว่าจะ reboot เมื่อใด

update_engine_client -status
update_engine_client -check_for_update

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

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

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

Talos Linux: ไม่มี shell, ไม่มี SSH และไม่มี console

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

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

แทนที่ tag ด้วย release ที่ต้องการอัปเกรดไป การอัปเกรดใช้รูปแบบ A-B ซึ่งเก็บ kernel และ OS image ก่อนหน้าไว้ ดังนั้นหากรายการใหม่บูตไม่สำเร็จ Talos จะ rollback กลับมาเองโดยไม่ต้องดำเนินการใดเพิ่มเติม การ debug จึงแตกต่างออกไป เพราะไม่มี shell โดยใช้ talosctl logs และ talosctl dmesg แทน journalctl บนเครื่อง

หาก workload ของคุณไม่ใช่ Kubernetes Talos ก็ไม่ใช่ตัวเลือกที่เหมาะสม แต่หากใช่ Talos จะตัด incident ออกไปได้ทั้งประเภท เพราะกรณีที่ “มีผู้เข้าสู่ระบบบน node แล้วเปลี่ยนแปลงบางอย่าง” จะไม่สามารถเกิดขึ้นได้

สิ่งที่ผู้เช่า VPS ต้องสละจริง

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

กระบวนการ build ที่ก่อนหน้านี้คุณไม่จำเป็นต้องมี การเพิ่ม package หมายถึงการแก้ไข Containerfile, build image, push image ไปยัง registry และ rolling servers วิธีนี้มีต้นทุนต่ำเมื่อมี pipeline อยู่แล้ว แต่ต้องใช้แรงงานจริงในการจัดตั้งเมื่อยังไม่มี และต้องมี registry ที่ servers เข้าถึงได้ ซึ่งหมายถึงต้องดูแล service เพิ่มอีกหนึ่งรายการหรือมีค่าใช้จ่ายเพิ่มเติม

Kernel modules kernel มาจาก image ดังนั้น module ที่ compile โดยอ้างอิง kernel ซึ่งกำลังทำงานอยู่จะไม่คงอยู่หลังการอัปเดตครั้งถัดไป ต้อง build out-of-tree modules และ package DKMS (dynamic kernel module support) เข้าไปใน image โดยอ้างอิง kernel ของ image นั้น สิ่งใดก็ตามที่ต้องใช้ module ซึ่ง base image ไม่มี จะกลายเป็นปัญหาด้านการ build แทนที่จะเป็นปัญหาด้านการติดตั้ง

Agent ของผู้จำหน่ายและผู้ให้บริการ โดยทั่วไป monitoring และ backup agents จะเผยแพร่เป็น .deb หรือ .rpm พร้อม install script ที่เขียนลงใน /usr และเปิดใช้งาน unit บนระบบแบบ read-only script ดังกล่าวจะทำงานล้มเหลว ผู้จำหน่ายบางรายเผยแพร่ container หรือจัดทำเอกสารสำหรับการติดตั้งแบบ image-mode แต่หลายรายไม่ได้ทำ ควรตรวจสอบเรื่องนี้ก่อนตัดสินใจ เพราะ fleet ที่คุณ monitor ไม่ได้ย่อมแย่กว่า fleet ที่ configuration เปลี่ยนแปลงไปตามเวลา

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

การติดตั้งระบบเหล่านี้ลงบน VPS ที่เช่า

ตรวจสอบข้อมูลของผู้ให้บริการก่อน 2 ข้อ ได้แก่ คุณมีสิทธิ์เข้าถึงคอนโซลนอกแบนด์ เช่น VNC หรือ serial console และคุณสามารถบูต rescue system ได้หรือไม่ หากไม่มีคอนโซล เครื่องที่บูตกลับมาไม่ได้จะต้องเปิด ticket กับฝ่ายสนับสนุน แทนที่จะแก้ไขได้ภายใน 5 นาที

หากผู้ให้บริการรองรับ custom image ให้อัปโหลด image แบบ raw หรือ qcow2 ของผู้จัดจำหน่าย แล้วจึงเสร็จสิ้นการติดตั้ง หากไม่รองรับ คุณต้องเขียน disk เองจาก rescue system โดย Flatcar มีสคริปต์แบบ self-contained สำหรับงานนี้โดยเฉพาะ และสคริปต์ทำงานได้จาก 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

เรียกใช้สคริปต์นี้จาก rescue system เท่านั้น ห้ามเรียกใช้จากเซิร์ฟเวอร์ที่คุณกำลังแทนที่ เพราะสคริปต์จะจัดแบ่งพาร์ติชันของอุปกรณ์เป้าหมายใหม่ระหว่างทำงาน อุปกรณ์ต้องมีพื้นที่ใช้งานได้อย่างน้อย 8 GB และสภาพแวดล้อม rescue ต้องมี bash, bzip2 หรือ lbzip2, lsblk, wget, udevadm, gpg และ gawk ให้พร้อมใช้งาน ส่วน ignition.json ต้องมี SSH key มิฉะนั้นระบบที่ติดตั้งแล้วจะไม่มีช่องทางให้คุณเข้าสู่ระบบ

Fedora CoreOS มีลักษณะการติดตั้งเช่นเดียวกัน โดย installer ทำงานใน 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

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

bootc มีวิธีเดียวที่ข้าม rescue mode ได้ เพราะสามารถแปลงระบบ Linux ที่กำลังทำงานอยู่โดยตรง:

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

อ่านเอกสารของ base image ที่คุณใช้งานก่อนเรียกใช้คำสั่งนี้ และทดลองกับเซิร์ฟเวอร์ที่สามารถยกเลิกทิ้งได้ หลัง reboot เครื่องจะทำงานด้วย image ดังกล่าว และชุด package เดิมที่ติดตั้งไว้จะหายไปแล้ว

ใครควรใช้เซิร์ฟเวอร์แบบ immutable และใครไม่ควรใช้

ควรใช้แนวทางนี้หากเซิร์ฟเวอร์ของคุณเป็นแบบ cattle คือสร้างเครื่องจำนวนมากจาก recipe เดียวกัน เช่น CI (continuous integration) runner ที่ทำงานอยู่เพียง 1 ชั่วโมง หรือ node ของ k3s หรือ Kubernetes ที่ถูกแทนที่แทนการซ่อมแซม หากเมื่อเครื่องมีปัญหา คำตอบที่มีอยู่แล้วคือ “ลบทิ้งแล้วสร้างเครื่องใหม่” แนวทางนี้จะเหมาะกับคุณ นอกจากนี้ยังมีประโยชน์เมื่อจำเป็นต้องยืนยันกับ auditor ว่าเครื่องกำลังใช้งานอะไรอยู่ เพราะสามารถตอบด้วย image digest แทน package list ได้

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

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

FAQ

ดิสโทร Linux แบบ immutable ไม่สามารถเปลี่ยนแปลงได้จริงหรือไม่

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

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

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

จะติดตั้ง package บนเซิร์ฟเวอร์แบบ immutable ได้อย่างไร

ให้เพิ่ม package ลงใน image แล้ว redeploy บน bootc ให้เพิ่มบรรทัด RUN dnf -y install ... ใน Containerfile จากนั้น rebuild, push แล้วจึงใช้ sudo bootc upgrade --apply บนเครื่อง สำหรับ Fedora CoreOS สามารถ layer package ด้วย sudo rpm-ostree install แล้ว reboot ได้ แต่ package ดังกล่าวจะถูกนำมาใช้ใหม่ในการอัปเดตครั้งต่อไปทุกครั้ง ส่วน Flatcar และ Talos ไม่มี package manager ดังนั้นคำตอบคือใช้ container หากต้องการเครื่องมือสำหรับ debugging เพียงครั้งเดียวบน host ที่ใช้ bootc ให้ใช้ sudo bootc usr-overlay เพื่อสร้าง /usr ที่เขียนได้ และจะหายไปเมื่อ reboot ครั้งถัดไป

image mode แก้ปัญหา VPS ที่ boot ไม่ได้หลังอัปเดต kernel หรือไม่

image mode เปลี่ยนการกู้คืนจากงานที่ต้องใช้ rescue console ให้เหลือเพียงการ reboot image, kernel และ userspace ก่อนหน้าจะยังอยู่บนดิสก์ ดังนั้น sudo bootc rollback หรือ sudo rpm-ostree rollback -r จะนำระบบกลับไปใช้ image ดังกล่าว Talos และ Flatcar ทำได้มากกว่านั้น โดยจะ rollback ให้อัตโนมัติเมื่อ slot ใหม่ boot ไม่สำเร็จ เนื่องจาก boot entry จะกลายเป็นค่าเริ่มต้นหลังจาก boot สำเร็จ 1 ครั้งเท่านั้น กลไกเหล่านี้ไม่ได้ป้องกันการอัปเดตที่มีปัญหา แต่ทำให้การย้อนกลับจากการอัปเดตดังกล่าวทำได้ง่าย

ควรเลือกดิสโทร immutable ใดสำหรับเซิร์ฟเวอร์

เลือก bootc หากต้องการ Linux server แบบ general-purpose ที่ build ในลักษณะเดียวกับ container image และสามารถติดตั้งลงในเครื่องที่มีอยู่แล้วได้ เลือก Fedora CoreOS หากต้องการแนวทางดังกล่าวโดยไม่ต้องจัดการการ build เอง และต้องการ automatic updates ตั้งแต่เริ่มต้น เลือก Flatcar หากต้องการ container host ขนาดเล็กที่ใช้ A/B update scheme และไม่มี package manager ให้เรียกใช้ เลือก Talos เฉพาะเมื่อเครื่องนั้นเป็น Kubernetes node เนื่องจากไม่มี shell และไม่รันสิ่งอื่นนอกเหนือจากนั้น