Linux bất biến trên server: Fedora CoreOS, Talos, Flatcar

Bản phân phối Linux bất biến (immutable) là gì

Một bản phân phối Linux bất biến 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ừ "bất biến" (immutable) có phần nói quá. 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ế độ chỉ đọc (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.

Cách 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 chỉ định. 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 gói phần mềm. Một file cấu hình được chỉnh sửa trong lúc xử lý 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à đây 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. Ổ đĩa mới chứa sự thật.

Chế độ image mode loại bỏ nơi tích tụ của sự sai lệch này. /usr là read-only tại thời điểm runtime, vì vậy bất kỳ thao tác cài đặt thủ công nào 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 này 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 cố gắ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ộ ý tưởng

Lỗi mà mô hình này được thiết kế để xử lý là lỗi mà chúng ta đã ghi nhận: một VPS không thể boot 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 bằng tay. Cách đó hiệu quả vì bootloader giữ lại các kernel cũ, nhưng chỉ có kernel được quản lý phiên bản theo cách đó. Bản cập nhật glibc và các thay đổi systemd đi kèm trong cùng một transaction đã được áp dụng, và không có lệnh đơn lẻ nào có thể rollback tất cả chúng 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ở lại entry boot 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 build 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ự dưới các 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 bạn để nó chạy, nó sẽ staging lại bản cập nhật mà bạn vừa rollback. -r sẽ reboot sau khi rollback được staging. Để giữ lại một deployment 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 deployment theo thứ tự bootloader sẽ cung cấp, đánh dấu cái đang chạy bằng một dấu chấm, và hiển thị Pinned: yes trên cái bạn đã ghim (pin).

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ử (try counter) trong bảng phân vùng, vì vậy một slot không bao giờ boot 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 (good) 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 nào khớp 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 boot sạch đầu tiên.

Giải pháp thay thế cho "cài đặt gói": 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à giải pháp 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 trong CNCF Sandbox. Máy chủ của bạn trở thành một Containerfile. Tính đến tháng 8 năm 2026, image cơ sở của Fedora là quay.io/fedora/fedora-bootc:44 và 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

Xây dựng và push image giống 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à xếp hàng image mới cho lần khởi động tiếp theo. --check báo cáo xem có bản cập nhật hay không và không thay đổi bất cứ điều 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 đi kèm với dự án:

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

Đây là câu trả lời của mô hình 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 sẽ áp dụng bất kỳ phiên bản nào có trong repository 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 sẽ áp dụng một artifact duy nhất mà bạn đã khởi động ở nơi khác.

Hai quy tắc xây dựng đượ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 đã sửa đổi 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 đó thêm một lớp overlay tạm thời có thể ghi trên /usr và sẽ bị loại bỏ ở lần khởi động lại tiếp theo. Nó chỉ 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 sau khi reboot theo thiết kế.

Fedora CoreOS: thiết lập 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, chuyển đổi nó sang 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 khiến những người chuyển từ cloud-init sang thường gặp khó khăn. 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à thiết lập 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 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"

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

• days, 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ở, viết dưới dạng "22:30".
• length_minutes, thời gian cửa sổ mở, ví dụ như 60.

Các mốc thời gian đó tính theo UTC. Để dừng cập nhật hoàn toàn, 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 dự phòng:

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 đã được thêm vào, và thay đổi chỉ có hiệu lực sau khi khởi động lại. Cái giá phải trả sẽ đến sau. Tập hợp các gói đã layer của bạn được áp dụng lại trên mỗi base image mới, vì vậy một gói đã bị xóa khỏi kho lưu trữ vào ngày cập nhật sẽ khiến 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ứ gì quan trọng, 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ự kế thừa của CoreOS Container Linux và là lựa chọn nghiêm ngặt nhất trong các hệ điều hành đa mục đích. Hệ thống không có trình quản lý gói để bạn sử dụng. Mọi thứ bạn chạy đều là container. Việc cấp phát (provisioning) được thực hiện qua Ignition, giống như Fedora CoreOS. Các bản cập nhật sử dụng 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 khởi động lại.

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ờ khởi động lại. Chiến lược khởi động lại 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 khởi động lại cho bạn quyết định. SERVER=disabled trong cùng file này 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ể khởi động lại 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 chủ 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 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 trước đó, vì vậy nếu 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 thể xảy ra.

Những thứ mà người dùng VPS thực sự phải từ bỏ

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 overlay tạm thời sẽ mất đi khi reboot. Trên Fedora CoreOS, bạn nhận được một bản triển khai phân lớp (layered deployment) cần phải 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 gói phần mềm nghĩa là phải chỉnh sửa Containerfile, build image, đẩy nó lên registry và triển khai lại các server. Việc này rất đơn giản khi đã có sẵn pipeline. Nhưng sẽ là một khối lượng công việc thực sự nếu chưa có, và 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 đến 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 gói DKMS (dynamic kernel module support) phải được build vào trong image, dựa trên kernel của image đó. Bất cứ thứ gì cần một module mà image cơ sở không hỗ trợ sẽ trở thành vấn đề về build thay vì vấn đề về cài đặt.

Các agent của nhà cung cấp và dịch vụ. Các agent giám sát và sao lưu 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 một hệ thống chỉ đọc (read-only), script đó sẽ thất bại. Một số nhà cung cấp xuất bản 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 đ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 dạt 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 đĩa, đó là nội dung của phần tiếp theo.

Cài đặt lên VPS thuê ngoài

Trước hết, hãy xác nhận hai điều từ nhà cung cấp: bạn có quyền truy cập console out-of-band (VNC hoặc serial console) và bạn có thể boot vào hệ thống rescue. Nếu không có console, một máy chủ không khởi động lại được sẽ trở thành một ticket hỗ trợ thay vì chỉ mất năm phút để 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 rescue. Flatcar cung cấp sẵn một script 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

Chạy lệnh đó từ hệ thống rescue, tuyệt đối không chạy từ server bạn đang muốn thay thế, vì script sẽ phân vùng lại thiết bị đích trong quá trình thực hiện. Thiết bị cần ít nhất 8 GB dung lượng trống và môi trường rescue phải cung cấp bash, bzip2 hoặc lbzip2, lsblk, wget, udevadm, gpg và gawk. File 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ự, trình cài đặt của nó chạy dưới dạng một 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 phương thức bỏ qua chế độ rescue, 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

Đọ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 có thể xóa bỏ được. Sau khi reboot, máy chủ sẽ chạy image mới và toàn bộ các gói phần mềm cũ của bạn sẽ bị mất.

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 (continuous integration) 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 cứ trường hợp nào mà giải pháp cho một máy bị hỏng 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 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ó pipeline build. Chế độ image không làm giảm khối lượng 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 đó, 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 và làm cho 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 base OS là một quyết định riêng, được đề cập trong chọn OS để chạy trên VPS của bạn. Chế độ image 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) tại thời điểm runtime và được thay thế toàn bộ bằng image tiếp theo, trong khi /etc và /var vẫn có thể ghi và tồn tại sau các bả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ị loại 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 VPS không hỗ trợ sẵn 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 thiết bị block, 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ó bước nhập mật khẩu lần đầu để 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à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, thực hiện build lại, push, sau đó 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 bản cập nhật tương lai. Trên Flatcar và Talos không có trình quản lý package, vì vậy câu trả lời là sử 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, nó 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 nếu slot mới không boot được, vì một boot entry chỉ trở thành mặc định sau một lần boot thành công. Không có cách nào ngăn chặn hoàn toàn 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 rủi ro hơn.

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

Chọn bootc nếu bạn muốn một server Linux đa dụ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à có cập nhật tự động 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ó trình quản lý package để 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.