Có nên dùng Immutable Linux distro trên VPS?

Immutable Linux distro là gì

Một bản phân phối Linux immutable cung cấp hệ điều hành dưới dạng một image duy nhất, vì vậy bạn thay thế toàn bộ hệ thống thay vì vá lỗi tại chỗ. Không có chuyện apt upgrade ghi đè file trong /usr trên một máy đang chạy. Bạn build hoặc pull một image mới, máy chủ sẽ lưu trữ nó bên cạnh image đang chạy, và lần reboot tiếp theo sẽ hoán đổi image nào đang hoạt động. Image cũ vẫn nằm trên ổ đĩa, nên việc hoàn tác một bản cập nhật lỗi chỉ đơn giản là reboot.

Từ "immutable" có phần hơi quá lời. Không có gì ngăn cản root ghi vào ổ đĩa về mặt vật lý. Những hệ thống này thực hiện mount các thư mục hệ thống ở chế độ read-only và gán quyền sở hữu chúng cho image. Dữ liệu bền vững nằm trong /var. Cấu hình riêng của máy nằm trong /etc. Mọi thứ dưới /usr đều thuộc về image, đó là lý do tại sao hai máy chủ chạy cùng một image tag sẽ có các file hệ thống giống hệt nhau.

Tên gọi của Red Hat cho hai mô hình này là rõ ràng nhất: package mode và image mode. Package mode là một hệ thống đang chạy cộng với một trình quản lý gói để chỉnh sửa nó. Image mode là một bước build ở nơi khác để tạo ra một artifact, và máy chủ chỉ có nhiệm vụ boot artifact mà bạn trỏ tới. Mọi thứ dưới đây đều xuất phát từ sự khác biệt duy nhất đó.

Tại sao hệ thống read-only lại quan trọng trên server

Một server đã chạy được hai năm thường chứa những thay đổi không được ghi chép lại. Một make install từ một buổi tối vội vã. Một repository bên thứ ba được thêm vào chỉ để cài một package. Một file cấu hình được sửa trong lúc sự cố nhưng không bao giờ được cập nhật lại vào hệ thống quản lý cấu hình của bạn. Hiện tượng này gọi là configuration drift, và đó là lý do tại sao việc dựng lại một server "giống hệt" từ ghi chú thường tạo ra một máy chủ có hành vi khác biệt. Ghi chú chỉ chứa ý định. Ổ cứng mới chứa sự thật.

Chế độ image mode loại bỏ nơi tích tụ của drift. /usr ở trạng thái read-only khi runtime, vì vậy việc cài đặt thủ công sẽ thất bại ngay lập tức hoặc được ghi lại thành một layer mà bạn có thể liệt kê bằng một lệnh duy nhất. Điều đó giúp sự khác biệt giữa hai máy trở nên rõ ràng thay vì phải đi "khảo cổ" tìm lỗi. Đây chính là vấn đề mà danh sách kiểm tra bảo trì server Linux thông thường giải quyết bằng kỷ luật, nhưng nay được xử lý trực tiếp bởi filesystem.

Rollback chỉ đơn giản là reboot, đó là toàn bộ ưu điểm

Mô hình này được xây dựng để xử lý lỗi mà chúng ta đã ghi nhận: một VPS không thể khởi động sau khi cập nhật kernel. Ở chế độ package, bạn khôi phục từ rescue console của nhà cung cấp. Bạn mount ổ đĩa, chroot vào, và gỡ bỏ gói kernel thủ công. Cách đó hiệu quả vì bootloader giữ lại các kernel cũ, nhưng chỉ kernel được quản lý phiên bản theo cách đó. Bản cập nhật glibc và các thay đổi của systemd trong cùng một transaction đã được áp dụng, và không có lệnh đơn lẻ nào có thể hoàn tác tất cả cùng lúc.

Ở chế độ image, đơn vị quản lý là toàn bộ hệ thống. Trên một host bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback hoán đổi thứ tự bootloader trở về entry khởi động trước đó, chính là image bạn đã chạy một giờ trước, bao gồm cả kernel và userspace. Không có gì được tải xuống và không có gì được xây dựng lại, vì image cũ chưa bao giờ bị xóa khỏi ổ đĩa.

Fedora CoreOS thực hiện điều tương tự với tên gọi khác:

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

Hãy dừng Zincati trước. Zincati là agent giữ cho máy Fedora CoreOS luôn ở phiên bản mới nhất, nên nếu để nó chạy, nó sẽ chuẩn bị lại bản cập nhật mà bạn vừa gỡ bỏ. -r sẽ reboot sau khi rollback được thiết lập. Để giữ lại một bản triển khai mà bạn tin tưởng khỏi bị garbage collected:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status liệt kê các bản triển khai theo thứ tự bootloader sẽ cung cấp, đánh dấu bản đang chạy bằng một dấu chấm, và hiển thị Pinned: yes trên bản bạn đã ghim.

Talos thực hiện việc này bằng một API call từ máy trạm của bạn:

talosctl rollback --nodes 10.20.30.40

Flatcar giữ hai phân vùng /usr và chuyển đổi qua lại giữa chúng. Mỗi slot mang một độ ưu tiên và một bộ đếm thử nghiệm trong bảng phân vùng, vì vậy một slot không bao giờ khởi động thành công sẽ hết số lần thử và bootloader sẽ chọn slot còn lại. Kiểm tra xem bạn đang ở slot nào và nó đã được đánh dấu là tốt hay chưa:

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

Một slot đang chạy ổn định sẽ in ra một dòng chứa priority=1 tries=0 successful=1. Nếu không có dòng tương ứng nghĩa là slot hiện tại chưa bao giờ được xác nhận, đây là trạng thái máy nằm giữa thời điểm cập nhật và lần khởi động sạch đầu tiên.

Thay thế "cài đặt gói" bằng bootc và Containerfile

bootc là công cụ tổng quát hóa mô hình này. Nó được định nghĩa là các bản cập nhật hệ điều hành tại chỗ, có tính giao dịch, sử dụng các container image theo chuẩn OCI (Open Container Initiative) và là một dự án CNCF Sandbox. Máy chủ của bạn trở thành một Containerfile. Tính đến tháng 8 năm 2026, base image của Fedora là quay.io/fedora/fedora-bootc:44 và base image của CentOS Stream là 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 và push image như bất kỳ image nào khác:

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

Sau đó trên máy chủ:

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

bootc upgrade truy vấn nguồn image và đưa image mới vào hàng đợi cho lần khởi động tiếp theo. --check báo cáo xem có bản cập nhật nào khả dụng hay không và không thay đổi bất cứ thứ gì. --apply khởi động lại vào image đó. bootc switch registry.example.com/edge/web:next trỏ máy chủ đến một image khác trong khi vẫn bảo toàn /etc và /var, đây là cách bạn chuyển đổi máy chủ giữa các luồng image mà không cần cài đặt lại.

Để cập nhật tự động, hãy bật timer mà dự án cung cấp:

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

Đây là câu trả lời theo chế độ image cho unattended upgrades trên Ubuntu và dnf-automatic trên Rocky và Alma. Sự khác biệt nằm ở những gì được áp dụng. Một timer ở chế độ gói (package-mode) sẽ áp dụng bất kỳ phiên bản nào mà repository có vào đêm đó, vì vậy tập hợp các gói kết quả sẽ hơi khác nhau trên mỗi máy. Một timer ở chế độ image (image-mode) sẽ áp dụng một artifact duy nhất mà bạn đã khởi động ở nơi khác.

Hai quy tắc build được rút ra từ Containerfile đó. Dữ liệu có thể ghi thuộc về /var, vì vậy phần mềm nào yêu cầu ghi vào thư mục cài đặt của chính nó cần một symlink hoặc một dòng BindPaths= trong systemd được thêm vào tại thời điểm build. Và /etc được hợp nhất ba chiều (three-way merged) khi cập nhật, nghĩa là một file bạn chưa bao giờ chỉnh sửa sẽ nhận phiên bản mới từ image, trong khi file bạn đã chỉnh sửa cục bộ sẽ được giữ nguyên.

Khi bạn cần một công cụ trên máy chủ đang chạy cho một phiên làm việc debug:

sudo bootc usr-overlay
sudo dnf -y install strace

Lệnh này thêm một lớp overlay có thể ghi tạm thời trên /usr và sẽ bị loại bỏ ở lần khởi động lại tiếp theo. Nó dùng để xem xét vấn đề, không phải để sửa lỗi. Bạn không thể thay đổi kernel theo cách này và mọi thứ bạn cài đặt sẽ biến mất khi khởi động lại theo thiết kế.

Fedora CoreOS: khởi tạo một lần, cập nhật mãi mãi

Fedora CoreOS không có trình cài đặt tương tác. Bạn viết một file Butane YAML, transpile nó thành Ignition JSON, rồi cung cấp file đó cho máy chủ ở lần khởi động đầu tiên:

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

Ignition chỉ chạy trong initramfs ở lần khởi động đầu tiên. Đây là điểm khác biệt khiến những người chuyển từ cloud-init hay gặp lỗi. Nếu cấu hình không chứa SSH key, máy sẽ khởi động mà không có cách nào để truy cập, và cách khắc phục duy nhất là khởi tạo lại từ đầu. Hãy kiểm tra cấu hình trên một máy dùng thử trước khi áp dụng cho máy chủ quan trọng.

Cài đặt vào ổ đĩa từ môi trường live:

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

Các bản cập nhật được thực hiện tự động theo mặc định. Bạn kiểm soát thời điểm, không phải việc có cập nhật hay không. Tạo một file TOML tại /etc/zincati/config.d/55-updates-strategy.toml để chọn chiến lược định kỳ:

[updates]
strategy = "periodic"

Dưới chiến lược đó, bạn thêm một cửa sổ bảo trì cho mỗi entry trong array-of-tables, vì vậy mỗi cửa sổ sẽ bắt đầu bằng tên updates.periodic.window được viết trong dấu ngoặc vuông kép làm tiêu đề, theo sau là ba khóa:

• days, một danh sách các ngày trong tuần, ví dụ như "Sat" và "Sun".
• start_time, thời điểm cửa sổ mở ra, được viết dưới dạng "22:30".
• length_minutes, thời gian cửa sổ duy trì, ví dụ như 60.

Các mốc thời gian này tính theo UTC. Để dừng hoàn toàn việc cập nhật, hãy chạy sudo systemctl disable --now zincati.service, và chấp nhận rằng từ giờ bạn phải tự quản lý lịch trình vá lỗi.

Package layering tồn tại như một lối thoát:

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

Lệnh này xây dựng một bản triển khai mới với gói phần mềm đã được thêm vào, và thay đổi chỉ có hiệu lực sau khi reboot. Cái giá phải trả sẽ đến sau. Tập hợp các gói bạn đã layer sẽ được áp dụng lại trên mỗi base image mới, vì vậy một gói đã biến mất khỏi repository vào ngày cập nhật sẽ làm cho quá trình cập nhật đó thất bại. Tài liệu của Fedora hướng bạn sử dụng container cho bất kỳ thành phần nào đáng kể, và sử dụng bootc image khi bạn thực sự cần thay đổi OS.

Flatcar Container Linux: hoàn toàn không có trình quản lý gói

Flatcar là sự tiếp nối của CoreOS Container Linux và là tùy chọn nghiêm ngặt nhất trong các hệ điều hành đa mục đích. Không có trình quản lý gói nào để bạn sử dụng. Mọi thứ bạn chạy đều là container. Việc provisioning sử dụng Ignition, tương tự như Fedora CoreOS. Các bản cập nhật được thực hiện thông qua hai phân vùng A/B /usr như đã mô tả ở trên, được điều khiển bởi update_engine, với locksmithd quyết định thời điểm reboot.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT nghĩa là phân vùng thụ động (passive slot) đã chứa image mới và chỉ còn chờ reboot. Chiến lược reboot mặc định là reboot với độ trễ năm phút, vì vậy một VPS production đơn lẻ sẽ tự khởi động lại theo lịch trình của nó trừ khi bạn cấu hình khác. Hãy thiết lập cửa sổ thời gian trong /etc/flatcar/update.conf:

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

REBOOT_STRATEGY=off để việc reboot cho bạn quyết định. SERVER=disabled trong cùng file đó sẽ dừng hoàn toàn việc kiểm tra cập nhật. Đối với một cluster, REBOOT_STRATEGY=etcd-lock kết hợp với locksmithctl set-max 4 giới hạn số lượng node có thể reboot cùng lúc, đảm bảo một bản cập nhật không bao giờ làm sập toàn bộ hệ thống cùng một lúc.

Talos Linux: không shell, không SSH, không console

Talos là hệ điều hành tối giản nhất trong bốn loại và có mục đích rõ ràng nhất. Nó chạy các node Kubernetes. Không có SSH daemon, không có shell và không có đăng nhập console. Mọi thao tác đều là một lệnh gọi gRPC API được thực hiện bằng talosctl từ máy trạm của bạn, dựa trên cấu hình máy (machine config) mà bạn lưu trong git.

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

Thay thế tag bằng phiên bản release mà bạn muốn chuyển sang. Quá trình nâng cấp sử dụng cơ chế A-B, giữ lại kernel và OS image cũ, vì vậy nếu phiên bản mới không khởi động được, Talos sẽ tự động rollback mà không cần can thiệp. Việc debug sẽ khác biệt vì không có shell: bạn sử dụng talosctl logs và talosctl dmesg thay vì journalctl trực tiếp trên máy.

Nếu workload của bạn không phải là Kubernetes, Talos không phải là lựa chọn phù hợp. Nếu đúng là Kubernetes, Talos loại bỏ hoàn toàn một nhóm sự cố, vì tình trạng "ai đó đăng nhập vào node và thay đổi cấu hình" sẽ không bao giờ xảy ra.

Những thứ thực sự bị mất khi dùng VPS tenant

Cài đặt ad-hoc trên hệ thống đang chạy. Đây là vấn đề lớn nhất. sudo apt install htop vào lúc 2 giờ sáng trong khi đang xử lý sự cố là điều không thể. Với bootc, bạn nhận được một lớp overlay tạm thời sẽ mất sau khi reboot. Trên Fedora CoreOS, bạn phải triển khai theo lớp (layered deployment) và cần reboot. Trên Flatcar và Talos, bạn không có gì cả.

Một pipeline build mà trước đây bạn không có. Thêm một package đồng nghĩa với việc chỉnh sửa Containerfile, build image, đẩy lên registry và triển khai lại các server. Việc này rất đơn giản nếu đã có sẵn pipeline. Nhưng nếu chưa có, đây là một khối lượng công việc thực sự, và bạn cần một registry mà các server có thể truy cập được; đó lại là một dịch vụ khác cần vận hành hoặc một hóa đơn khác cần thanh toán.

Kernel module. Kernel được lấy từ image, vì vậy một module được biên dịch dựa trên kernel đang chạy sẽ không tồn tại sau lần cập nhật tiếp theo. Các module out-of-tree và các package DKMS (dynamic kernel module support) phải được build trực tiếp vào image, dựa trên kernel của image đó. Bất cứ thứ gì cần module mà image gốc không hỗ trợ đều trở thành vấn đề về build thay vì vấn đề cài đặt.

Các agent của nhà cung cấp và dịch vụ. Các agent giám sát và backup thường được phân phối dưới dạng .deb hoặc .rpm kèm theo một script cài đặt ghi dữ liệu vào /usr và kích hoạt một unit. Trên hệ thống read-only, script đó sẽ thất bại. Một số nhà cung cấp phát hành container hoặc tài liệu hướng dẫn cài đặt theo chế độ image. Nhiều bên thì không. Hãy kiểm tra kỹ điều này trước khi quyết định, vì một hệ thống mà bạn không thể giám sát còn tệ hơn một hệ thống bị trôi cấu hình (drift).

Bản thân image. Hầu như không có bảng điều khiển VPS nào liệt kê Fedora CoreOS, Flatcar hoặc Talos bên cạnh Ubuntu và Debian. Bạn phải tự cung cấp disk, đây là nội dung của phần tiếp theo.

Triển khai lên VPS bạn thuê

Trước tiên hãy xác nhận hai điều với nhà cung cấp: bạn có quyền truy cập console ngoài băng tần (out-of-band), nghĩa là VNC hoặc serial console, và bạn có thể boot vào hệ thống cứu hộ (rescue system). Nếu không có console, một máy chủ không khởi động lại được sẽ biến thành một ticket hỗ trợ thay vì chỉ mất năm phút để sửa.

Nếu nhà cung cấp cho phép dùng image tùy chỉnh, hãy upload file raw hoặc qcow2 của nhà phát hành và công việc hoàn tất. Nếu không, bạn phải tự ghi đĩa từ hệ thống cứu hộ. Flatcar cung cấp một script độc lập cho việc này và nó chạy được trên mọi bản phân phối 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

Hãy chạy lệnh đó từ hệ thống cứu hộ, tuyệt đối không chạy từ server bạn đang thay thế, vì script sẽ phân vùng lại thiết bị đích trong quá trình thực hiện. Nó cần ít nhất 8 GB dung lượng khả dụng trên thiết bị, và môi trường cứu hộ phải cung cấp bash, bzip2 hoặc lbzip2, lsblk, wget, udevadm, gpg và gawk. ignition.json của bạn phải chứa SSH key, nếu không hệ thống sau khi cài đặt sẽ không có cách nào để bạn đăng nhập.

Fedora CoreOS cũng có cách thức tương tự, và trình cài đặt của nó chạy dưới dạng 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

Kiểm tra tên thiết bị bằng lsblk trước khi chạy lệnh. Ghi nhầm vào thiết bị khác sẽ xóa sạch dữ liệu trên đó và không có bất kỳ thông báo xác nhận nào.

bootc cung cấp một lộ trình bỏ qua chế độ cứu hộ, vì nó chuyển đổi hệ thống Linux đang chạy tại chỗ:

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

Hãy đọc tài liệu của base image bạn đang sử dụng trước khi chạy lệnh đó, và hãy thử nghiệm trên một server mà bạn có thể bỏ đi. Sau khi reboot, máy sẽ chạy image mới và toàn bộ tập hợp gói phần mềm cũ của bạn sẽ bị xóa sạch.

Ai nên dùng immutable server và ai không nên

Bạn nên dùng nếu coi server như gia súc (cattle). Nhiều máy được tạo từ một công thức duy nhất. Các CI runner chỉ tồn tại trong một giờ. Các node k3s hoặc Kubernetes được thay thế thay vì sửa chữa. Bất kỳ trường hợp nào mà giải pháp cho một máy bị lỗi là "xóa nó đi và tạo máy mới". Cách này cũng hiệu quả khi bạn cần chứng minh với kiểm toán viên về những gì đang chạy trên máy, vì câu trả lời là một image digest thay vì một danh sách gói phần mềm.

Bạn không nên dùng nếu bạn chỉ có một VPS được chăm sóc thủ công với ba dịch vụ, bạn cài đặt mọi thứ khi cần và không có build pipeline. Image mode không giúp giảm bớt công việc. Nó chuyển công việc từ server sang quá trình build, đồng thời yêu cầu bạn phải có registry và pipeline để thực hiện việc đó. Nếu bạn có nơi để xử lý khối lượng công việc này, bạn sẽ có các server giống hệt nhau và việc rollback chỉ đơn giản là reboot. Nếu không, bạn chỉ đang thêm các thành phần phức tạp vào một hệ thống vốn đang ổn định, khiến việc xử lý sự cố lúc 2 giờ sáng trở nên khó khăn hơn.

Giải pháp trung dung vẫn hiệu quả: một bản phân phối Linux thông thường với các bản cập nhật bảo mật tự động, cộng với một quy trình rebuild mà bạn đã thực sự thực hành. Việc chọn hệ điều hành cơ sở là một quyết định riêng, được đề cập trong chọn hệ điều hành để chạy trên VPS của bạn. Image mode chỉ là vòng lặp mới nhất của một cuộc tranh luận rất cũ về cách phần mềm nên được đưa đến máy chủ, và lịch sử của các bản phân phối Linux phần lớn chính là sự lặp lại của cuộc tranh luận đó.

FAQ

Bản phân phối Linux immutable có thực sự bất biến không?

Không, và cái tên này gây ra sự nhầm lẫn. Người dùng root vẫn có thể ghi vào đĩa. Thực tế là /usr được mount ở chế độ chỉ đọc (read-only) khi runtime và được thay thế hoàn toàn bằng image mới ở lần cập nhật sau, trong khi /etc và /var vẫn có thể ghi và giữ nguyên dữ liệu qua các lần cập nhật. Các thay đổi bạn thực hiện dưới /usr sẽ bị từ chối ngay lúc đó hoặc bị xóa bỏ ở lần cập nhật kế tiếp, vì vậy hiệu quả thực tế là các thư mục hệ thống chỉ thay đổi khi image thay đổi.

Tôi có thể chạy Fedora CoreOS hoặc Flatcar trên một VPS không hỗ trợ sẵn chúng không?

Thường là có, nếu nhà cung cấp cho bạn hệ thống rescue và quyền truy cập console. Bạn boot vào rescue, ghi disk image của bản phân phối đó vào block device, sau đó reboot. Script flatcar-install của Flatcar thực hiện việc này từ bất kỳ Linux nào, và Fedora CoreOS cung cấp coreos-installer dưới dạng một container mà bạn có thể chạy theo cách tương tự. Cả hai đều cần một file Ignition chứa SSH key của bạn, vì không có prompt nhập mật khẩu ở lần boot đầu tiên để dự phòng. Nếu không có quyền truy cập console, đừng thử: một máy chủ không khởi động lại được sẽ khiến bạn không có cách nào để kiểm tra lỗi.

Làm thế nào để cài đặt một package trên server immutable?

Bạn thêm nó vào image và triển khai lại. Trên bootc, đó là một dòng RUN dnf -y install ... trong Containerfile, sau đó build lại, push, rồi chạy sudo bootc upgrade --apply trên máy chủ. Trên Fedora CoreOS, bạn có thể layer nó bằng sudo rpm-ostree install và reboot, với cái giá là package đó sẽ được áp dụng lại trong mọi lần cập nhật sau này. Trên Flatcar và Talos không có package manager, nên câu trả lời là dùng container. Đối với một công cụ debug dùng một lần trên host bootc, sudo bootc usr-overlay cung cấp cho bạn một /usr có thể ghi được và sẽ biến mất ở lần reboot tiếp theo.

Image mode có sửa được VPS không boot được sau khi cập nhật kernel không?

Nó biến việc khôi phục từ một công việc cần đến rescue-console thành một thao tác reboot đơn giản. Image trước đó, bao gồm cả kernel và userspace, vẫn nằm trên đĩa, vì vậy sudo bootc rollback hoặc sudo rpm-ostree rollback -r sẽ đưa bạn trở lại trạng thái cũ. Talos và Flatcar còn tiến xa hơn khi tự động rollback mà không cần yêu cầu nếu slot mới không boot được, vì một boot entry chỉ trở thành mặc định sau khi boot thành công một lần. Không cách nào ngăn chặn được một bản cập nhật lỗi, nhưng nó giúp việc hoàn tác trở nên dễ dàng và ít tốn kém hơn.

Tôi nên chọn bản phân phối immutable nào cho server?

Hãy chọn bootc nếu bạn muốn một Linux server đa năng mà bạn có thể build như một container image và cài đặt lên máy chủ hiện có. Chọn Fedora CoreOS nếu bạn muốn mô hình đó với việc build được thực hiện sẵn và tự động cập nhật ngay khi cài đặt. Chọn Flatcar nếu bạn muốn một container host tối giản với cơ chế cập nhật A/B và không có package manager để tránh việc cài đặt tùy tiện. Chỉ chọn Talos khi máy chủ là một Kubernetes node, vì nó không có shell và không chạy bất kỳ thứ gì khác.