استفاده از توزیع‌های لینوکس Immutable در سرور

توزیع لینوکس تغییرناپذیر (Immutable) چیست

یک توزیع لینوکس تغییرناپذیر، سیستم‌عامل را به صورت یک ایمیج واحد ارائه می‌دهد؛ بنابراین به‌جای وصله‌کردن (patch) سیستم در محل، کل آن را جایگزین می‌کنید. در این مدل، بازنویسی فایل‌ها در apt upgrade تحت /usr روی یک سیستم در حال اجرا وجود ندارد. شما یک ایمیج جدید می‌سازید یا دریافت می‌کنید، دستگاه آن را در کنار ایمیج فعلی قرار می‌دهد و با ریبوت بعدی، ایمیج فعال تغییر می‌کند. ایمیج قبلی همچنان روی دیسک باقی می‌ماند، بنابراین بازگرداندن یک به‌روزرسانی ناموفق تنها با یک ریبوت انجام می‌شود.

واژه «تغییرناپذیر» (immutable) کمی اغراق‌آمیز است. هیچ مانع فیزیکی برای جلوگیری از نوشتن root روی دیسک وجود ندارد. کاری که این سیستم‌ها انجام می‌دهند، mount کردن دایرکتوری‌های سیستمی به صورت read-only و سپردن مالکیت آن‌ها به ایمیج است. داده‌های ماندگار در /var قرار می‌گیرند. پیکربندی‌های مختص هر ماشین در /etc ذخیره می‌شوند. هر چیزی در /usr متعلق به ایمیج است؛ به همین دلیل است که دو سرور با یک تگ ایمیج یکسان، فایل‌های سیستمی کاملاً مشابهی دارند.

نام‌گذاری‌های Red Hat برای این دو مدل، شفاف‌ترین آن‌هاست: حالت بسته (package mode) و حالت ایمیج (image mode). حالت بسته، یک سیستم در حال اجرا به همراه یک مدیر بسته است که آن را ویرایش می‌کند. حالت ایمیج، یک مرحله ساخت در جایی دیگر است که یک آرتیفکت تولید می‌کند و وظیفه سرور تنها بوت کردن آرتیفکتی است که به آن اشاره می‌کنید. تمام موارد زیر از همین تفاوت واحد ناشی می‌شوند.

چرا سیستم فقط‌خواندنی (read-only) در سرور اهمیت بیشتری دارد

سروری که دو سال در حال کار بوده، تاریخی دارد که هیچ‌کس آن را ثبت نکرده است. یک make install که در یک عصر پرشتاب انجام شده است. یک مخزن شخص ثالث که برای یک بسته اضافه شده است. یک فایل پیکربندی که در زمان قطعی ویرایش شده و هرگز به سیستم مدیریت پیکربندی شما بازگردانده نشده است. نام این پدیده «انحراف پیکربندی» (configuration drift) است و به همین دلیل است که بازسازی «همان» سرور از روی یادداشت‌هایتان، اغلب منجر به تولید ماشینی می‌شود که رفتار متفاوتی دارد. یادداشت‌ها حاوی نیت شما هستند، اما دیسک حاوی حقیقت است.

حالت Image mode مکانی که انحراف در آن جمع می‌شود را حذف می‌کند. /usr در زمان اجرا فقط‌خواندنی است، بنابراین نصبی که به‌صورت دستی انجام شود یا بلافاصله با شکست مواجه می‌شود یا به‌عنوان لایه‌ای ثبت می‌گردد که می‌توانید با یک دستور آن را فهرست کنید. این موضوع باعث می‌شود تفاوت بین دو ماشین به‌جای آنکه نیازمند بررسی‌های باستان‌شناسانه باشد، به‌وضوح قابل مشاهده شود. این همان مشکلی است که چک‌لیست نگهداری معمول سرور لینوکس با انضباط فردی به آن می‌پردازد، اما در اینجا توسط سیستم فایل مدیریت می‌شود.

بازگشت به نسخه قبل (Rollback) تنها با یک راه‌اندازی مجدد انجام می‌شود و این تمام ماجراست

شکستی که این مدل برای آن طراحی شده، همان موردی است که قبلاً مستند کرده‌ایم: یک VPS که پس از به‌روزرسانی هسته (kernel) بوت نمی‌شود. در حالت package-based، شما از طریق کنسول نجات (rescue console) ارائه‌دهنده سرویس، سیستم را بازیابی می‌کنید. دیسک را mount کرده، وارد محیط chroot می‌شوید و بسته هسته را به‌صورت دستی حذف می‌کنید. این روش کار می‌کند زیرا bootloader هسته‌های قدیمی را نگه می‌دارد، اما فقط هسته به این شکل نسخه‌بندی می‌شود. به‌روزرسانی glibc و تغییرات systemd که در همان تراکنش اعمال شده‌اند، قبلاً نهایی شده‌اند و هیچ دستور واحدی برای بازگرداندن هم‌زمان آن‌ها وجود ندارد.

در حالت image-based، واحد اصلی کل سیستم است. روی یک میزبان bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback ترتیب bootloader را به ورودی بوت قبلی بازمی‌گرداند؛ یعنی همان تصویری (image) که یک ساعت پیش در حال اجرای آن بودید، شامل هسته و فضای کاربری (userspace) به‌صورت یکپارچه. هیچ فایلی دانلود یا بازسازی نمی‌شود، زیرا تصویر قدیمی هرگز از روی دیسک پاک نشده است.

Fedora CoreOS همین کار را با نام‌های متفاوتی انجام می‌دهد:

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

ابتدا Zincati را متوقف کنید. Zincati عاملی است که ماشین Fedora CoreOS را روی جدیدترین نسخه نگه می‌دارد، بنابراین اگر آن را در حال اجرا بگذارید، به‌روزرسانی‌ای که به‌تازگی از آن عقب‌نشینی کرده‌اید را دوباره اعمال می‌کند. -r پس از آماده‌سازی بازگشت، سیستم را reboot می‌کند. برای جلوگیری از حذف (garbage collection) نسخه‌ای که به آن اطمینان دارید:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status استقرارها (deployments) را به ترتیبی که bootloader ارائه می‌دهد فهرست می‌کند، نسخه در حال اجرا را با یک نقطه مشخص کرده و Pinned: yes را روی نسخه‌ای که پین (pin) کرده‌اید نشان می‌دهد.

Talos این کار را با یک فراخوانی API از ایستگاه کاری شما انجام می‌دهد:

talosctl rollback --nodes 10.20.30.40

Flatcar دو پارتیشن /usr نگه می‌دارد و بین آن‌ها جابه‌جا می‌شود. هر اسلات دارای یک اولویت و یک شمارنده تلاش در جدول پارتیشن است؛ بنابراین اسلاتی که هرگز با موفقیت بوت نشود، تعداد تلاش‌هایش تمام شده و bootloader اسلات دیگر را انتخاب می‌کند. بررسی کنید که در کدام اسلات هستید و آیا وضعیت آن good علامت‌گذاری شده است یا خیر:

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

یک اسلات سالم در حال اجرا، خطی شامل priority=1 tries=0 successful=1 چاپ می‌کند. نبودن خط مشابه به این معنی است که اسلات فعلی هرگز تأیید نشده است؛ این وضعیتی است که ماشین بین یک به‌روزرسانی و اولین بوت موفق خود در آن قرار دارد.

جایگزین «نصب بسته»: bootc و Containerfile

ابزار bootc این الگو را تعمیم داده است. این ابزار خود را به‌روزرسانی تراکنشی و درجا برای سیستم‌عامل با استفاده از ایمیج‌های کانتینری OCI (مخفف Open Container Initiative) معرفی می‌کند و یک پروژه در CNCF Sandbox است. سرور شما به یک Containerfile تبدیل می‌شود. تا اوت 2026، ایمیج پایه Fedora برابر با quay.io/fedora/fedora-bootc:44 و ایمیج پایه 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 کنید:

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 منبع ایمیج را پرس‌وجو کرده و ایمیج جدید را برای بوت بعدی در صف قرار می‌دهد. --check گزارش می‌دهد که آیا به‌روزرسانی موجود است یا خیر و هیچ تغییری ایجاد نمی‌کند. --apply سیستم را با ایمیج جدید reboot می‌کند. bootc switch registry.example.com/edge/web:next دستگاه را به یک ایمیج متفاوت اشاره می‌دهد، در حالی که /etc و /var حفظ می‌شوند؛ این روشی است که بدون نصب مجدد، سرور را بین جریان‌های ایمیج جابه‌جا می‌کنید.

برای به‌روزرسانی‌های خودکار (unattended)، تایمری که پروژه ارائه می‌دهد را فعال کنید:

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

این پاسخِ «حالت ایمیج» (image-mode) به unattended upgrades در اوبونتو و dnf-automatic در راکی و آلما است. تفاوت در چیزی است که اعمال می‌شود. تایمر در «حالت بسته» (package-mode) هر نسخه‌ای که مخزن در آن شب ارائه می‌دهد را اعمال می‌کند، بنابراین مجموعه نهایی بسته‌ها در هر ماشین کمی متفاوت است. تایمر در «حالت ایمیج» یک آرتیفکت واحد را اعمال می‌کند که قبلاً در جای دیگری آن را بوت کرده‌اید.

دو قانون ساخت از آن Containerfile استخراج می‌شود. داده‌های قابل‌نوشتن متعلق به /var هستند، بنابراین نرم‌افزاری که اصرار دارد داخل دایرکتوری نصب خود بنویسد، به یک symlink یا یک خط BindPaths= در systemd نیاز دارد که در زمان ساخت اضافه شود. همچنین /etc در هنگام به‌روزرسانی به صورت سه-طرفه (three-way) ادغام می‌شود؛ این یعنی فایلی که هرگز تغییر نداده‌اید، نسخه جدید ایمیج را دریافت می‌کند، در حالی که فایلی که به صورت محلی ویرایش کرده‌اید، حفظ می‌شود.

هنگامی که برای یک نشست عیب‌یابی به ابزاری روی سیستم زنده نیاز دارید:

sudo bootc usr-overlay
sudo dnf -y install strace

این دستور یک overlay موقت و قابل‌نوشتن روی /usr اضافه می‌کند که در reboot بعدی حذف می‌شود. این کار برای بررسی مشکل است، نه برای رفع آن. شما نمی‌توانید هسته (kernel) را به این روش تغییر دهید و هر چیزی که نصب می‌کنید طبق طراحی، با reboot ناپدید می‌شود.

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 باشد، ماشین بدون هیچ راه ورودی بالا می‌آید و تنها راه حل، پیکربندی مجدد از صفر است. پیش از اعمال پیکربندی روی سرور اصلی، آن را روی یک ماشین آزمایشی تست کنید.

نصب روی دیسک از محیط 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"

تحت این استراتژی، برای هر ورودی در آرایه جداول، یک پنجره نگهداری اضافه می‌کنید؛ به‌طوری که هر پنجره با نام 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 جدید با بسته اضافه شده می‌سازد و تغییرات تنها پس از reboot اعمال می‌شوند. هزینه این کار بعداً مشخص می‌شود. مجموعه بسته‌های لایه‌بندی‌شده شما روی هر ایمیج پایه جدید دوباره اعمال می‌شود، بنابراین اگر بسته‌ای در روز به‌روزرسانی از مخزن حذف شده باشد، آن به‌روزرسانی با شکست مواجه خواهد شد. مستندات خودِ Fedora برای هر کار اساسی، شما را به استفاده از کانتینرها و در صورت نیاز واقعی به تغییر سیستم‌عامل، به استفاده از ایمیج‌های bootc هدایت می‌کند.

Flatcar Container Linux: بدون هیچ‌گونه مدیر بسته

Flatcar ادامهٔ مسیر CoreOS Container Linux و سخت‌گیرانه‌ترین گزینه در میان سیستم‌عامل‌های عمومی است. در این سیستم هیچ مدیر بسته‌ای برای نصب نرم‌افزار وجود ندارد. هر چیزی که اجرا می‌کنید، یک کانتینر است. تأمین منابع (Provisioning) از طریق Ignition انجام می‌شود، مشابه آنچه در Fedora CoreOS می‌بینید. به‌روزرسانی‌ها از طریق دو پارتیشن A/B /usr که پیش‌تر توضیح داده شد صورت می‌گیرد و توسط update_engine هدایت می‌شود؛ در حالی که locksmithd تعیین می‌کند چه زمانی عملیات reboot انجام شود.

update_engine_client -status
update_engine_client -check_for_update

وضعیت UPDATE_STATUS_UPDATED_NEED_REBOOT به این معناست که اسلات غیرفعال (passive slot) هم‌اکنون تصویر جدید را دریافت کرده و تنها مرحلهٔ باقی‌مانده، reboot است. استراتژی پیش‌فرض برای reboot، گزینه 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 مسئولیت reboot را به عهدهٔ شما می‌گذارد. تنظیم SERVER=disabled در همان فایل، بررسی به‌روزرسانی‌ها را به‌طور کامل متوقف می‌کند. برای یک کلاستر، استفاده از REBOOT_STRATEGY=etcd-lock در ترکیب با locksmithctl set-max 4 محدود می‌کند که چند گره (node) می‌توانند هم‌زمان reboot شوند؛ بدین ترتیب یک به‌روزرسانی هرگز باعث از دسترس خارج شدن کل ناوگان به‌صورت یکجا نخواهد شد.

Talos Linux: بدون شل، بدون SSH، بدون کنسول

Talos محدودترین گزینه در میان این چهار مورد است و هدف آن از همه شفاف‌تر است. این سیستم‌عامل نودهای Kubernetes را اجرا می‌کند. در آن هیچ daemon مربوط به SSH، هیچ شل و هیچ لاگین کنسولی وجود ندارد. هر عملیات، یک فراخوانی gRPC API است که با استفاده از talosctl از ایستگاه کاری شما و بر اساس یک machine config که در git نگهداری می‌کنید، انجام می‌شود.

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

این تگ را با نسخه‌ای (release) که قصد مهاجرت به آن را دارید جایگزین کنید. این ارتقا از طرح A-B استفاده می‌کند که هسته و ایمیج سیستم‌عامل قبلی را حفظ می‌کند؛ بنابراین اگر نسخه جدید بوت نشود، Talos به‌طور خودکار و بدون نیاز به دخالت، به نسخه قبلی بازمی‌گردد (rollback). عیب‌یابی در این سیستم متفاوت است زیرا شلی وجود ندارد: شما به‌جای استفاده از journalctl روی دستگاه، از talosctl logs و talosctl dmesg استفاده می‌کنید.

اگر workload شما Kubernetes نیست، Talos انتخاب مناسبی نخواهد بود. اما اگر هست، Talos کل یک دسته از حوادث را حذف می‌کند، زیرا دیگر جایی برای اینکه «کسی وارد نود شود و چیزی را تغییر دهد» وجود ندارد.

آنچه مستأجر VPS در واقع از دست می‌دهد

نصب‌های موردی (Ad-hoc) روی سیستم در حال اجرا. این مهم‌ترین مورد است. اجرای sudo apt install htop در ساعت 2 بامداد هنگام بروز یک حادثه، دیگر امکان‌پذیر نیست. در bootc شما یک overlay گذرا دریافت می‌کنید که با reboot از بین می‌رود. در Fedora CoreOS شما یک deployment لایه‌بندی‌شده دارید که نیاز به reboot دارد. در Flatcar و Talos شما هیچ‌کدام را ندارید.

خط لوله ساخت (Build pipeline) که قبلاً نداشتید. افزودن یک بسته به معنای ویرایش یک Containerfile، ساخت image، ارسال آن به یک registry و به‌روزرسانی سرورهاست. وقتی خط لوله وجود دارد، این کار کم‌هزینه است. اما راه‌اندازی آن از صفر کار دشواری است و به یک registry نیاز دارد که سرورها بتوانند به آن دسترسی داشته باشند؛ که خود سرویس دیگری برای اجرا یا هزینه‌ای دیگر برای پرداخت است.

ماژول‌های هسته (Kernel modules). هسته از داخل image می‌آید، بنابراین ماژولی که برای هسته در حال اجرا کامپایل شده باشد، پس از به‌روزرسانی بعدی باقی نمی‌ماند. ماژول‌های خارج از درخت (Out-of-tree) و بسته‌های DKMS (پشتیبانی پویا از ماژول هسته) باید درون image و متناسب با هسته همان image ساخته شوند. هر چیزی که به ماژولی نیاز داشته باشد که در image پایه وجود ندارد، به جای یک مشکل نصب، به یک مشکل در فرآیند ساخت تبدیل می‌شود.

عوامل (Agents) فروشنده و ارائه‌دهنده. عوامل مانیتورینگ و پشتیبان‌گیری معمولاً به صورت یک .deb یا .rpm همراه با یک اسکریپت نصب عرضه می‌شوند که در /usr می‌نویسد و یک unit را فعال می‌کند. در یک سیستم فقط‌خواندنی (read-only)، آن اسکریپت با شکست مواجه می‌شود. برخی فروشندگان یک container منتشر می‌کنند یا نصب در حالت image را مستند کرده‌اند. بسیاری از آن‌ها این کار را نمی‌کنند. پیش از تعهد، این مورد را بررسی کنید، زیرا ناوگانی که نتوانید مانیتور کنید، بدتر از ناوگانی است که دچار drift (انحراف پیکربندی) می‌شود.

خودِ image. تقریباً هیچ پنل مدیریتی VPS، سیستم‌عامل‌های Fedora CoreOS یا Flatcar یا Talos را در کنار Ubuntu و Debian فهرست نمی‌کند. شما باید دیسک را خودتان تأمین کنید، که موضوع بخش بعدی است.

انتقال یکی از این سیستم‌عامل‌ها به VPS اجاره‌ای

پیش از هر چیز، دو مورد را در مورد ارائه‌دهنده سرویس خود تأیید کنید: دسترسی کنسول خارج از باند (out-of-band) داشته باشید، یعنی VNC یا کنسول سریال، و همچنین امکان بوت کردن یک سیستم نجات (rescue system) وجود داشته باشد. بدون کنسول، ماشینی که پس از تغییرات بالا نمی‌آید، به جای یک تعمیر 5 دقیقه‌ای، به یک تیکت پشتیبانی تبدیل می‌شود.

اگر ارائه‌دهنده اجازه استفاده از ایمیج‌های سفارشی را می‌دهد، ایمیج raw یا qcow2 ارائه‌دهنده را آپلود کنید و کار تمام است. در غیر این صورت، باید دیسک را خودتان از طریق سیستم نجات بنویسید. Flatcar یک اسکریپت مستقل دقیقاً برای همین کار ارائه می‌دهد که از هر توزیع 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

این دستور را از داخل سیستم نجات اجرا کنید، نه از روی سروری که قصد جایگزینی آن را دارید، زیرا اسکریپت در حین کار، پارتیشن‌بندی دستگاه مقصد را تغییر می‌دهد. این کار حداقل به 8 GB فضای قابل استفاده روی دستگاه نیاز دارد و محیط نجات باید bash، bzip2 یا lbzip2، lsblk، wget، udevadm، gpg و gawk را فراهم کند. فایل ignition.json شما باید حاوی یک کلید SSH باشد، در غیر این صورت سیستم نصب‌شده راهی برای ورود شما نخواهد داشت.

Fedora CoreOS نیز ساختار مشابهی دارد و نصب‌کننده آن به صورت یک 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 تنها مسیری است که نیاز به حالت نجات را حذف می‌کند، زیرا یک سیستم 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

پیش از اجرای آن، مستندات مربوط به ایمیج پایه مورد استفاده خود را مطالعه کنید و آن را روی سروری تست کنید که امکان حذف آن را دارید. پس از reboot، ماشین ایمیج جدید را اجرا می‌کند و مجموعه بسته‌های قبلی شما حذف خواهد شد.

چه کسانی باید از سرور تغییرناپذیر (Immutable) استفاده کنند و چه کسانی نباید

اگر سرورهای خود را مانند «گله» مدیریت می‌کنید، به این روش نیاز دارید. یعنی تعداد زیادی ماشین که همگی از یک دستورالعمل واحد ساخته شده‌اند. نمونه‌هایی از این دست عبارتند از: CI runners که تنها یک ساعت عمر می‌کنند، یا نودهای k3s و Kubernetes که به‌جای تعمیر، جایگزین می‌شوند. هر سناریویی که در آن پاسخ به خرابی یک ماشین، «حذف و ساخت مجدد آن» باشد، برای این مدل مناسب است. همچنین زمانی که باید به یک حسابرس ثابت کنید چه چیزی روی ماشین در حال اجراست، این روش کارآمد است؛ چرا که پاسخ شما یک image digest دقیق است، نه یک لیست طولانی از بسته‌های نصب‌شده.

اگر یک VPS دارید که به‌صورت دستی مدیریت می‌شود، سه سرویس روی آن اجرا کرده‌اید، هر زمان نیاز باشد چیزی نصب می‌کنید و هیچ pipeline برای build ندارید، نباید از این روش استفاده کنید. حالت Image-based کار را حذف نمی‌کند، بلکه آن را از سرور به مرحله build منتقل می‌کند و هزینه استفاده از یک registry و یک pipeline را به شما تحمیل می‌کند. اگر زیرساختی برای مدیریت این فرآیند دارید، سرورهایی یکسان خواهید داشت که بازگشت به نسخه قبلی (rollback) در آن‌ها تنها با یک reboot انجام می‌شود. در غیر این صورت، تنها پیچیدگی‌های غیرضروری به سیستمی که به‌خوبی کار می‌کرد اضافه کرده‌اید و عیب‌یابی در ساعت 2 بامداد را دشوارتر خواهید کرد.

حد وسطِ منطقی همچنان کارآمد است: استفاده از یک توزیع معمولی با به‌روزرسانی‌های امنیتی خودکار، به‌علاوه یک فرآیند بازسازی (rebuild) که قبلاً آن را تمرین کرده‌اید. انتخاب توزیع پایه، تصمیمی مستقل است که در انتخاب سیستم‌عامل برای اجرا روی VPS به آن پرداخته شده است. حالت Image-based تنها جدیدترین دور از یک بحث بسیار قدیمی درباره نحوه انتقال نرم‌افزار به ماشین است و تاریخچه توزیع‌های لینوکس تا حد زیادی بازتاب تکرار همین بحث است.

FAQ

آیا توزیع‌های لینوکس تغییرناپذیر (Immutable) واقعاً تغییرناپذیر هستند؟

خیر، و این نام باعث سردرگمی می‌شود. کاربر root همچنان می‌تواند روی دیسک بنویسد. آنچه در واقع رخ می‌دهد این است که /usr در زمان اجرا به‌صورت read-only mount می‌شود و در به‌روزرسانی بعدی، کل آن با یک image جدید جایگزین می‌گردد، در حالی که /etc و /var قابل نوشتن باقی می‌مانند و پس از به‌روزرسانی‌ها حفظ می‌شوند. تغییراتی که در /usr اعمال می‌کنید یا در همان لحظه رد می‌شوند و یا در به‌روزرسانی بعدی از بین می‌روند؛ بنابراین اثر عملی این است که دایرکتوری‌های سیستم فقط زمانی تغییر می‌کنند که image تغییر کند.

آیا می‌توانم Fedora CoreOS یا Flatcar را روی VPSای که آن‌ها را ارائه نمی‌دهد اجرا کنم؟

معمولاً بله، اگر ارائه‌دهنده به شما یک سیستم rescue و دسترسی کنسول بدهد. شما سیستم rescue را بوت می‌کنید، image دیسک توزیع مورد نظر را روی block device می‌نویسید و سپس سیستم را reboot می‌کنید. اسکریپت flatcar-install در Flatcar این کار را از هر سیستم‌عاملی انجام می‌دهد و Fedora CoreOS نیز coreos-installer را به عنوان یک container ارائه می‌دهد که می‌توانید به همان روش اجرا کنید. هر دو به یک فایل Ignition حاوی کلید SSH شما نیاز دارند، زیرا هیچ مرحله‌ای برای تنظیم رمز عبور در اولین بوت وجود ندارد که بتوانید به آن تکیه کنید. بدون دسترسی کنسول، این کار را انجام ندهید: اگر ماشین پس از تغییر بالا نیاید، هیچ راهی برای مشاهده وضعیت آن نخواهید داشت.

چگونه می‌توانم یک پکیج را روی سرور تغییرناپذیر نصب کنم؟

شما آن را به image اضافه کرده و دوباره مستقر (redeploy) می‌کنید. در bootc این کار با یک خط RUN dnf -y install ... در Containerfile، بازسازی (rebuild)، push کردن و سپس اجرای sudo bootc upgrade --apply روی ماشین انجام می‌شود. در Fedora CoreOS می‌توانید آن را با sudo rpm-ostree install لایه‌بندی (layer) کرده و reboot کنید، با این هزینه که آن پکیج در هر به‌روزرسانی بعدی دوباره اعمال می‌شود. در Flatcar و Talos پکیج منیجر وجود ندارد، بنابراین پاسخ استفاده از container است. برای یک ابزار عیب‌یابی موقت در میزبان bootc، دستور sudo bootc usr-overlay یک /usr قابل نوشتن به شما می‌دهد که با reboot بعدی ناپدید می‌شود.

آیا حالت image-mode، مشکل VPSای که پس از به‌روزرسانی هسته (kernel) بوت نمی‌شود را حل می‌کند؟

این کار بازیابی سیستم را از یک عملیات دشوار در کنسول rescue به یک reboot ساده تبدیل می‌کند. image قبلی، شامل هسته و فضای کاربری (userspace)، همچنان روی دیسک باقی است، بنابراین sudo bootc rollback یا sudo rpm-ostree rollback -r شما را به وضعیت قبل بازمی‌گرداند. Talos و Flatcar فراتر می‌روند و در صورتی که slot جدید بوت نشود، به‌طور خودکار به نسخه قبل بازمی‌گردند، زیرا یک ورودی بوت تنها پس از یک بوت موفق به عنوان پیش‌فرض انتخاب می‌شود. هیچ‌کدام از این‌ها از بروز یک به‌روزرسانی بد جلوگیری نمی‌کنند، اما بازگرداندن آن را کم‌هزینه می‌کنند.

برای سرور کدام توزیع تغییرناپذیر را انتخاب کنم؟

اگر یک سرور لینوکس عمومی می‌خواهید که آن را مانند یک container image بسازید و روی ماشین فعلی خود نصب کنید، bootc را انتخاب کنید. اگر همین مدل را با ساخت خودکار و به‌روزرسانی‌های پیش‌فرض می‌خواهید، Fedora CoreOS را انتخاب کنید. اگر یک میزبان container مینیمال با طرح به‌روزرسانی A/B و بدون پکیج منیجر می‌خواهید، Flatcar را انتخاب کنید. Talos را فقط زمانی انتخاب کنید که ماشین شما یک node در Kubernetes باشد، زیرا این سیستم shell ندارد و هیچ چیز دیگری را اجرا نمی‌کند.