সার্ভারে Immutable Linux ডিস্ট্রো: bootc, CoreOS ও Talos

ইমিউটেবল (immutable) Linux ডিস্ট্রিবিউশন কী

একটি ইমিউটেবল Linux ডিস্ট্রিবিউশন অপারেটিং সিস্টেমকে একটি একক ইমেজ হিসেবে রিলিজ করে, তাই আপনি সিস্টেমটিকে সরাসরি প্যাচ না করে বরং সম্পূর্ণ নতুন ইমেজ দিয়ে প্রতিস্থাপন করেন। চলমান সিস্টেমে apt upgrade-এর অধীনে কোনো ফাইল পরিবর্তন করার সুযোগ নেই /usr। আপনি একটি নতুন ইমেজ তৈরি বা ডাউনলোড করেন, মেশিনটি সেটিকে বর্তমান ইমেজের পাশাপাশি সাজিয়ে রাখে এবং পরবর্তী রিবুটের সময় সক্রিয় ইমেজটি পরিবর্তিত হয়ে যায়। আগের ইমেজটি ডিস্কে থেকে যায়, তাই কোনো ত্রুটিপূর্ণ আপডেট হলে কেবল একটি রিবুট করেই আগের অবস্থায় ফিরে আসা সম্ভব।

"ইমিউটেবল" শব্দটি কিছুটা অতিরঞ্জিত। শারীরিকভাবে root-কে ডিস্কে লেখা থেকে আটকানোর কোনো উপায় নেই। এই সিস্টেমগুলো যা করে তা হলো, সিস্টেম ডিরেক্টরিগুলোকে রিড-অনলি (read-only) হিসেবে মাউন্ট করে এবং সেগুলোর মালিকানা ইমেজের ওপর ন্যস্ত করে। স্থায়ী ডেটা /var-এ থাকে। মেশিন-নির্দিষ্ট কনফিগারেশন /etc-এ থাকে। /usr-এর অধীনে সবকিছুই ইমেজের অংশ, আর এই কারণেই একই ইমেজ ট্যাগ ব্যবহার করা দুটি সার্ভারের সিস্টেম ফাইলগুলো হুবহু একই থাকে।

এই দুটি মডেলের জন্য Red Hat-এর দেওয়া নামগুলো সবচেয়ে স্পষ্ট: package mode এবং image mode। Package mode হলো একটি চলমান সিস্টেম এবং একটি প্যাকেজ ম্যানেজার যা সেটিকে এডিট করে। Image mode হলো অন্য কোথাও একটি বিল্ড ধাপ যা একটি আর্টিফ্যাক্ট তৈরি করে, এবং সার্ভারের একমাত্র কাজ হলো আপনার নির্দেশিত আর্টিফ্যাক্টটি বুট করা। নিচের সবকিছুই এই একটি পার্থক্যের ওপর ভিত্তি করে তৈরি।

সার্ভারে কেন read-only সিস্টেম গুরুত্বপূর্ণ

দুই বছর ধরে চলমান একটি সার্ভারের এমন একটি ইতিহাস থাকে যা কেউ লিখে রাখে না। তাড়াহুড়োর সন্ধ্যায় করা একটি make install। একটি প্যাকেজের জন্য যোগ করা থার্ড-পার্টি রিপোজিটরি। বিভ্রাটের সময় এডিট করা কোনো কনফিগারেশন ফাইল যা আর কখনোই কনফিগারেশন ম্যানেজমেন্টে ফিরিয়ে আনা হয়নি। একে বলা হয় configuration drift, আর এই কারণেই আপনার নোট দেখে "একই" সার্ভার পুনরায় তৈরি করলেও সেটি ভিন্নভাবে আচরণ করে। নোটগুলোতে কেবল উদ্দেশ্য থাকে। ডিস্কে থাকে প্রকৃত সত্য।

Image mode সেই জায়গাটি সরিয়ে ফেলে যেখানে drift জমা হয়। /usr রানটাইমে read-only থাকে, তাই হাতে করা কোনো ইনস্টলেশন হয় সরাসরি ব্যর্থ হয়, অথবা এমন একটি লেয়ার হিসেবে রেকর্ড হয় যা আপনি একটি কমান্ড দিয়েই তালিকাভুক্ত করতে পারেন। এটি দুটি মেশিনের মধ্যে পার্থক্যকে প্রত্নতাত্ত্বিক অনুসন্ধানের বদলে দৃশ্যমান করে তোলে। এটি সেই একই সমস্যা যা একটি সাধারণ Linux সার্ভার রক্ষণাবেক্ষণ চেকলিস্ট শৃঙ্খলার মাধ্যমে সমাধান করে, তবে এখানে তা ফাইলসিস্টেমের মাধ্যমেই নিয়ন্ত্রিত হয়।

Rollback হলো reboot, এবং এটিই পুরো বিষয়

এই মডেলটি যে ব্যর্থতার জন্য তৈরি, সেটিই আমরা আগে নথিভুক্ত করেছি: kernel update-এর পরে boot না হওয়া একটি VPS। package mode-এ provider-এর rescue console থেকে recovery করতে হয়। disk mount করে chroot-এ ঢুকতে হয় এবং হাতে একটি kernel package সরাতে হয়। bootloader পুরোনো kernel রেখে দেয় বলেই এটি কাজ করে। তবে এভাবে শুধু kernel version করা থাকে। একই transaction-এ আসা glibc update এবং systemd পরিবর্তনগুলো ইতিমধ্যে প্রয়োগ হয়ে যায়। কোনো একক command এগুলোকে একসঙ্গে আগের অবস্থায় ফিরিয়ে দেয় না।

image mode-এ unit হলো সম্পূর্ণ system। bootc host-এ:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback bootloader-এর ordering আগের boot entry-তে ফিরিয়ে দেয়। এটি সেই image, যেটি এক ঘণ্টা আগে চালু ছিল; kernel এবং userspace একসঙ্গেই ফিরে আসে। কিছু download বা rebuild হয় না, কারণ পুরোনো image disk ছেড়ে যায়নি। নিচে বর্ণিত automatic update timer চালু থাকলে আগে সেটি বন্ধ করুন। bootc documentation সতর্ক করে যে automated upgrade চালানো agent rollback ফিরিয়ে দিতে পারে।

Fedora CoreOS ভিন্ন নামে একই কাজ করে:

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

প্রথমে Zincati বন্ধ করুন। Zincati হলো সেই agent, যা Fedora CoreOS machine-কে সর্বশেষ release-এ রাখে। আপনি যে deployment-এ rollback করেছেন, এটি সেটি পুনরায় install করবে না। তবে এটি update খুঁজতে থাকবে এবং নতুন কোনো update পাওয়া গেলে upgrade করবে। তাই fix release না হওয়া পর্যন্ত machine-টিকে বর্তমান অবস্থায় রাখতে হলে sudo systemctl disable --now zincati.service চালান। rollback stage হয়ে গেলে -r reboot করে। কোনো বিশ্বাসযোগ্য deployment-কে garbage collection থেকে রক্ষা করতে:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status deployment-গুলোকে সেই ক্রমে তালিকাভুক্ত করে, যে ক্রমে bootloader সেগুলো দেখাবে। এটি চলমান deployment-কে একটি dot দিয়ে চিহ্নিত করে এবং যেটিতে আপনি pin করেছেন সেটিতে Pinned: yes দেখায়।

Talos আপনার workstation থেকে একটি API call-এই কাজটি করে:

talosctl rollback --nodes 10.20.30.40

Flatcar দুটি /usr partition রাখে এবং সেগুলোর মধ্যে পরিবর্তন করে। প্রতিটি slot-এর priority এবং try counter partition table-এ থাকে। কোনো slot সফলভাবে boot না হলে তার try শেষ হয়ে যায় এবং bootloader অন্য slot বেছে নেয়। আপনি কোন slot-এ আছেন এবং সেটি good হিসেবে চিহ্নিত হয়েছে কি না, তা দেখুন:

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

সুস্থ অবস্থায় চলমান slot-এর output-এ tries=0 successful=1 থাকা একটি line দেখা যায়। একই line-এর priority number শুধু bootloader কোন slot-কে অগ্রাধিকার দেবে তা নির্ধারণ করে। তাই সম্পূর্ণ সুস্থ machine-এও এটি 1 বা 2 হতে পারে। কোনো matching line না থাকলে বোঝায়, বর্তমান slot-কে কখনও confirmed করা হয়নি। update এবং প্রথম clean boot-এর মধ্যবর্তী সময়ে machine এই অবস্থায় থাকে।

"install a package"-এর বিকল্প কী: 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

অন্য যেকোনো ইমেজের মতোই এটি বিল্ড এবং পুশ করুন:

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 ইমেজ সোর্স থেকে তথ্য সংগ্রহ করে এবং পরবর্তী বুটের জন্য নতুন ইমেজটিকে কিউ (queue) করে। --check কোনো আপডেট উপলব্ধ কি না তা জানায় এবং কোনো কিছু পরিবর্তন করে না। --apply নতুন ইমেজে রিবুট করে। bootc switch registry.example.com/edge/web:next মেশিনটিকে একটি ভিন্ন ইমেজের দিকে নির্দেশ করে, যেখানে /etc এবং /var সংরক্ষিত থাকে; এভাবেই আপনি সার্ভারকে পুনরায় ইনস্টল না করেই এক ইমেজ স্ট্রিম থেকে অন্যটিতে স্থানান্তর করতে পারেন।

স্বয়ংক্রিয় আপডেটের জন্য, প্রজেক্টের সাথে আসা টাইমারটি এনাবল করুন:

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

এটি Ubuntu-তে unattended upgrades এবং Rocky ও Alma-তে dnf-automatic-এর ইমেজ-মোড উত্তর। পার্থক্য হলো কী ইনস্টল হচ্ছে তার ওপর। প্যাকেজ-মোড টাইমার সেই রাতে রিপোজিটরিতে থাকা যেকোনো ভার্সন প্রয়োগ করে, তাই প্রতিটি মেশিনে সফটওয়্যারের সেট কিছুটা ভিন্ন হতে পারে। ইমেজ-মোড টাইমার এমন একটি আর্টিফ্যাক্ট প্রয়োগ করে যা আপনি আগেই অন্য কোথাও বুট করে দেখেছেন।

সেই Containerfile থেকে দুটি বিল্ড রুল অনুসরণ করতে হয়। রাইটেবল ডেটা /var-এর অধীনে থাকে, তাই যে সফটওয়্যার তার নিজস্ব ইনস্টল ডিরেক্টরির ভেতরে লিখতে চায়, সেটির জন্য বিল্ডের সময় একটি সিমলিংক (symlink) বা systemd BindPaths= লাইন যোগ করতে হবে। এবং /etc আপডেটের সময় থ্রি-ওয়ে মার্জ (three-way merged) হয়, যার মানে হলো আপনি যে ফাইলটি কখনো পরিবর্তন করেননি সেটি ইমেজের নতুন ভার্সন গ্রহণ করবে, আর যে ফাইলটি আপনি লোকালি এডিট করেছেন সেটি অপরিবর্তিত থাকবে।

যখন আপনার লাইভ বক্সে কোনো ডিবাগিং সেশনের জন্য একটি টুলের প্রয়োজন হয়:

sudo bootc usr-overlay
sudo dnf -y install strace

এটি /usr-এর ওপর একটি অস্থায়ী রাইটেবল ওভারলে যোগ করে যা পরবর্তী রিবুটের সময় মুছে যায়। এটি সমস্যা দেখার জন্য, সমাধান করার জন্য নয়। আপনি এভাবে কার্নেল পরিবর্তন করতে পারবেন না এবং ডিজাইনের কারণেই আপনার ইনস্টল করা সবকিছু রিবুটের পর অদৃশ্য হয়ে যাবে।

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 না থাকে, তবে মেশিনে প্রবেশের কোনো উপায় থাকে না এবং এর সমাধান হলো শুরু থেকে পুনরায় প্রভিশন করা। গুরুত্বপূর্ণ সার্ভারে প্রয়োগ করার আগে একটি পরীক্ষামূলক মেশিনে কনফিগারেশনটি যাচাই করে নিন।

লাইভ এনভায়রনমেন্ট থেকে ডিস্কে ইনস্টল করার পদ্ধতি:

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

আপডেটগুলো ডিফল্টভাবে স্বয়ংক্রিয়। আপনি কখন আপডেট হবে তা নিয়ন্ত্রণ করতে পারেন, কিন্তু আপডেট হবে কি না তা নয়। /etc/zincati/config.d/55-updates-strategy.toml-এ একটি TOML ফাইল রাখুন যা পর্যায়ক্রমিক কৌশল (periodic strategy) নির্ধারণ করে:

[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

এটি প্যাকেজটি যুক্ত করে একটি নতুন ডিপ্লয়মেন্ট তৈরি করে এবং রিবুট করার পরেই পরিবর্তনটি কার্যকর হয়। এর মাশুল পরে দিতে হয়। আপনার লেয়ার করা সেটটি প্রতিটি নতুন বেস ইমেজের ওপর পুনরায় প্রয়োগ করা হয়, তাই আপডেটের দিন কোনো প্যাকেজ রিপোজিটরি থেকে হারিয়ে গেলে সেই আপডেটটি ব্যর্থ হবে। Fedora-এর নিজস্ব ডকুমেন্টেশন বড় কোনো পরিবর্তনের জন্য কন্টেইনার এবং ওএস (OS) পরিবর্তনের প্রয়োজন হলে bootc ইমেজ ব্যবহারের পরামর্শ দেয়।

Flatcar Container Linux: কোনো প্যাকেজ ম্যানেজার নেই

Flatcar হলো CoreOS Container Linux-এর ধারাবাহিক সংস্করণ এবং সাধারণ ব্যবহারের জন্য এটি সবচেয়ে কঠোর অপারেটিং সিস্টেম। এখানে কোনো প্যাকেজ ম্যানেজার নেই যার ওপর আপনি নির্ভর করতে পারেন। আপনি যা কিছু চালাবেন, তা সবই কন্টেইনার। Fedora CoreOS-এর মতোই এখানে প্রোভিশনিংয়ের জন্য Ignition ব্যবহার করা হয়। আপডেটগুলো উপরে বর্ণিত দুটি A/B /usr পার্টিশনের মাধ্যমে সম্পন্ন হয়, যা update_engine দ্বারা পরিচালিত হয় এবং locksmithd নির্ধারণ করে কখন রিবুট হবে।

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT মানে হলো প্যাসিভ স্লটে ইতিমধ্যে নতুন ইমেজটি রয়েছে এবং শুধুমাত্র রিবুট হওয়া বাকি। ডিফল্ট রিবুট কৌশল হলো reboot, যার সাথে পাঁচ মিনিটের বিলম্ব যুক্ত থাকে। তাই আপনি যদি অন্য কোনো নির্দেশনা না দেন, তবে একটি সিঙ্গেল প্রোডাকশন VPS তার নিজস্ব সময়সূচী অনুযায়ী রিস্টার্ট হবে। /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: কোনো shell, SSH বা console নেই

এই চারটির মধ্যে Talos-এর পরিসর সবচেয়ে সংকীর্ণ এবং এর উদ্দেশ্যও সবচেয়ে স্পষ্ট। এটি Kubernetes node চালায়। কোনো SSH daemon, login shell বা console login নেই। physical console-এ login prompt নয়, machine state পরিদর্শনের জন্য একটি dashboard দেখা যায়। আপনার workstation থেকে talosctl ব্যবহার করে, git-এ সংরক্ষিত machine config-এর ভিত্তিতে করা প্রতিটি operation একটি gRPC API call।

talosctl upgrade --nodes 10.20.30.40 \
  --image factory.talos.dev/metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v1.14.2

Talos 1.14 থেকে ghcr.io/siderolabs/installer image আর প্রকাশ করা হয় না; এর পরিবর্তে installer image Image Factory থেকে আসে। ওই path-এর দীর্ঘ ID হলো কোনো customization ছাড়া machine-এর empty schematic। যে schematic থেকে আপনার node install করা হয়েছিল, সেটিই ব্যবহার করুন, যাতে তার system extension-গুলোও অন্তর্ভুক্ত থাকে। এরপর tag-টি আপনি যে release-এ upgrade করছেন, সেটি দিয়ে প্রতিস্থাপন করুন। Upgrade-এ A-B scheme ব্যবহার করা হয়। এতে আগের kernel ও OS image সংরক্ষিত থাকে। নতুন image boot করতে ব্যর্থ হলে Talos নিজে থেকেই rollback করে; কোনো intervention প্রয়োজন হয় না। Login shell না থাকায় debugging-এর পদ্ধতিও আলাদা। Machine-এ journalctl ব্যবহার না করে talosctl logs এবং talosctl dmesg ব্যবহার করবেন। Node-এ কোনো tool প্রয়োজন হলে talosctl debug আপনার দেওয়া image থেকে একটি privileged container চালু করে এবং তার shell-এ নিয়ে যায়। আপনি বের হলে container-টি সরিয়ে ফেলা হয়।

আপনার workload Kubernetes না হলে Talos উপযুক্ত নয়। Kubernetes হলে Talos একটি সম্পূর্ণ ধরনের incident দূর করে। কারণ “কেউ node-এ login করে কিছু পরিবর্তন করেছে”—এমন ঘটনা ঘটার কোনো সুযোগ নেই।

একজন VPS টেন্যান্ট আসলে যা যা ত্যাগ করেন

চলমান সিস্টেমে অ্যাড-হক ইনস্টল। এটি সবচেয়ে বড় পরিবর্তন। কোনো ইনসিডেন্টের সময় রাত 2টায় sudo apt install htop করার সুযোগ আর থাকে না। bootc-এ আপনি একটি ক্ষণস্থায়ী ওভারলে পান যা রিবুটের সাথে সাথে মুছে যায়। Fedora CoreOS-এ আপনি লেয়ারড ডিপ্লয়মেন্ট পান যার জন্য রিবুট প্রয়োজন। Flatcar এবং Talos-এ আপনি কিছুই পান না।

একটি বিল্ড পাইপলাইন যা আগে আপনার ছিল না। কোনো প্যাকেজ যোগ করার অর্থ হলো একটি Containerfile এডিট করা, ইমেজ বিল্ড করা, সেটি একটি রেজিস্ট্রিতে পুশ করা এবং সার্ভারগুলো রোল করা। পাইপলাইন তৈরি থাকলে এটি সহজ। কিন্তু পাইপলাইন না থাকলে এটি বেশ পরিশ্রমের কাজ। এর জন্য এমন একটি রেজিস্ট্রি প্রয়োজন যেখানে সার্ভারগুলো পৌঁছাতে পারে, যা আবার আলাদা একটি সার্ভিস বা বাড়তি খরচের কারণ।

কার্নেল মডিউল। কার্নেলটি ইমেজ থেকেই আসে, তাই চলমান কার্নেলের সাথে কম্পাইল করা কোনো মডিউল পরবর্তী আপডেটের পর আর টিকে থাকে না। আউট-অফ-ট্রি মডিউল এবং DKMS (dynamic kernel module support) প্যাকেজগুলোকে ইমেজের ভেতরেই, সেই ইমেজের কার্নেলের বিপরীতে বিল্ড করতে হয়। বেস ইমেজে নেই এমন কোনো মডিউল প্রয়োজন হলে তা ইনস্টলেশন সমস্যার পরিবর্তে একটি বিল্ড সমস্যায় পরিণত হয়।

ভেন্ডর এবং প্রোভাইডার এজেন্ট। মনিটরিং এবং ব্যাকআপ এজেন্টগুলো সাধারণত একটি .deb বা .rpm হিসেবে আসে, যার সাথে একটি ইনস্টল স্ক্রিপ্ট থাকে যা /usr-এ ফাইল লেখে এবং একটি ইউনিট এনাবল করে। রিড-অনলি সিস্টেমে সেই স্ক্রিপ্ট কাজ করে না। কিছু ভেন্ডর কন্টেইনার প্রকাশ করে বা ইমেজ-মোড ইনস্টলেশনের ডকুমেন্টেশন দেয়। অনেকে তা দেয় না। কোনো কিছুতে প্রতিশ্রুতিবদ্ধ হওয়ার আগে এটি যাচাই করে নিন, কারণ যে ফ্লিট আপনি মনিটর করতে পারেন না, তা ড্রিফট হওয়া ফ্লিটের চেয়েও খারাপ।

ইমেজটি নিজেই। প্রায় কোনো VPS কন্ট্রোল প্যানেলই Ubuntu এবং Debian-এর পাশাপাশি Fedora CoreOS, Flatcar বা Talos-এর তালিকা রাখে না। আপনাকে ডিস্কটি সরবরাহ করতে হয়, যা পরবর্তী সেকশনের আলোচ্য বিষয়।

VPS-এ আপনার ভাড়া করা সার্ভারে এর একটি ইনস্টল করা

প্রথমে আপনার provider সম্পর্কে 2টি বিষয় নিশ্চিত করুন: আপনার out-of-band console access আছে কি না, অর্থাৎ VNC বা serial console, এবং আপনি rescue system boot করতে পারবেন কি না। console ছাড়া যে machine পুনরায় চালু হয়ে ফিরে আসে না, সেটি 5 মিনিটে ঠিক করার কাজ না হয়ে support ticket হয়ে দাঁড়ায়।

provider custom image গ্রহণ করলে vendor-এর raw বা qcow2 image upload করুন। তবে শুধু upload করলেই এমন machine তৈরি হয় না, যেটিতে আপনি login করতে পারবেন। Fedora CoreOS-এর core user-এর কোনো default password বা SSH key নেই। তাই আপনাকে আপনার key-সহ একটি Ignition config সরবরাহ করতে হবে। অথবা Afterburn সমর্থন করে এমন cloud platform হলে provider-এর নিজস্ব SSH key feature ব্যবহার করে key সেট করতে হবে। তা না হলে rescue system থেকে আপনাকেই disk লিখতে হবে। Flatcar এই কাজের জন্য একটি self-contained script সরবরাহ করে, এবং এটি যেকোনো 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 থেকে চালান, যে server-টি প্রতিস্থাপন করছেন সেখান থেকে কখনো নয়। কারণ script-টি কাজ করার সময় target device-এর partition পুনর্গঠন করে। device-এ কমপক্ষে 8 GB ব্যবহারযোগ্য স্থান থাকতে হবে। rescue environment-এ bash, bzip2 বা lbzip2, lsblk, wget, udevadm, gpg এবং gawk থাকতে হবে। আপনার ignition.json-এ একটি SSH key থাকতে হবে। তা না হলে installed system আপনাকে প্রবেশের কোনো উপায় দেবে না।

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 দিয়ে device-এর নাম যাচাই করুন। ভুল device-এ লিখলে সেটিতে থাকা সবকিছু নষ্ট হয়ে যাবে, এবং কোনো confirmation prompt দেখানো হবে না।

bootc rescue mode এড়িয়ে যাওয়ার একটি উপায় দেয়। এটি চলমান Linux system-কে সেখানেই রূপান্তর করে:

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 ব্যবহার করছেন তার documentation পড়ুন। পাশাপাশি, ফেলে দেওয়া যায় এমন একটি server-এ এটি পরীক্ষা করুন। reboot-এর পরে machine-টি image চালাবে, এবং আগে থাকা package set আর থাকবে না।

কার জন্য ইমিউটেবল সার্ভার উপযোগী এবং কার জন্য নয়

আপনার সার্ভারগুলো যদি 'cattle' বা গবাদি পশুর মতো হয়, তবে এটি আপনার জন্য। অর্থাৎ, একটি রেসিপি থেকে অনেকগুলো মেশিন তৈরি করা। এক ঘণ্টার জন্য চালু থাকা CI (continuous integration) রানার। k3s বা Kubernetes নোড, যা মেরামত করার বদলে প্রতিস্থাপন করা হয়। এমন যেকোনো ক্ষেত্র যেখানে কোনো সার্ভার নষ্ট হলে সমাধান হিসেবে "সেটি মুছে ফেলে নতুন আরেকটি তৈরি করা" প্রযোজ্য, সেখানে এটি কার্যকর। অডিটরকে মেশিনে কী চলছে তা প্রমাণ করার ক্ষেত্রেও এটি সুবিধাজনক, কারণ তখন উত্তরের বদলে একটি image digest প্রদান করলেই চলে, প্যাকেজ লিস্টের প্রয়োজন হয় না।

আপনার যদি একটি হাতে রক্ষণাবেক্ষণ করা VPS থাকে যেখানে তিনটি সার্ভিস চলছে, প্রয়োজন অনুযায়ী আপনি সেখানে সফটওয়্যার ইনস্টল করেন এবং আপনার কোনো build pipeline নেই, তবে এটি আপনার জন্য নয়। ইমেজ মোড কাজের পরিমাণ কমায় না। এটি সার্ভারের কাজকে বিল্ড পর্যায়ে সরিয়ে নেয় এবং এর বিনিময়ে আপনাকে একটি registry ও pipeline ব্যবহার করতে হয়। যদি এই বাড়তি কাজের জন্য আপনার অবকাঠামো থাকে, তবে আপনি অভিন্ন সার্ভার পাবেন এবং রিবুট করেই রোলব্যাক করতে পারবেন। যদি তা না থাকে, তবে আপনি অহেতুক জটিলতা বাড়ালেন, যা রাত 2টার সময় সমস্যা সমাধানে আপনার কাজকে আরও কঠিন করে তুলবে।

মাঝামাঝি পর্যায়ের সাধারণ পদ্ধতি এখনো কার্যকর: একটি সাধারণ ডিস্ট্রিবিউশন যাতে স্বয়ংক্রিয় সিকিউরিটি আপডেট চালু আছে এবং এমন একটি রিবিল্ড প্রক্রিয়া যা আপনি নিয়মিত অনুশীলন করেন। সেই বেস বেছে নেওয়া একটি আলাদা সিদ্ধান্ত, যা আপনার VPS-এ কোন OS চালাবেন তা নির্বাচন করা অংশে আলোচনা করা হয়েছে। ইমেজ মোড হলো সফটওয়্যার কীভাবে মেশিনে পৌঁছাবে তা নিয়ে চলা দীর্ঘদিনের বিতর্কের সর্বশেষ সংস্করণ, এবং Linux ডিস্ট্রিবিউশনের ইতিহাস মূলত সেই বিতর্কেরই পুনরাবৃত্তি।

FAQ

একটি immutable Linux distro কি সত্যিই immutable?

না, এবং নামটি বিভ্রান্তি তৈরি করে। root এখনও disk-এ লিখতে পারে। বাস্তবে যা ঘটে তা হলো, /usr runtime-এ read only হিসেবে mount করা হয় এবং পরবর্তী image দিয়ে সম্পূর্ণভাবে প্রতিস্থাপিত হয়, আর /etc ও /var writable থাকে এবং update-এর পরও বজায় থাকে। /usr-এর অধীনে করা পরিবর্তন হয় তখনই প্রত্যাখ্যাত হয়, নয়তো পরবর্তী update-এ বাদ পড়ে। তাই বাস্তবে system directory কেবল image পরিবর্তিত হলেই বদলায়।

যেসব VPS-এ Fedora CoreOS বা Flatcar দেওয়া হয় না, সেগুলোতে কি এগুলো চালানো যায়?

সাধারণত যায়, যদি provider আপনাকে rescue system ও console access দেয়। rescue system boot করুন, distribution-এর disk image block device-এ লিখুন, তারপর reboot করুন। Flatcar-এর flatcar-install script যেকোনো Linux থেকে এই কাজ করে, আর Fedora CoreOS একইভাবে চালানো যায় এমন container হিসেবে coreos-installer সরবরাহ করে। উভয়ের জন্য আপনার SSH key-সহ একটি Ignition file প্রয়োজন, কারণ বিকল্প হিসেবে প্রথম boot-এ password prompt থাকে না। Console access না থাকলে এটি করার চেষ্টা করবেন না: যে machine boot হয়ে ফিরে আসে না, সেটি পরীক্ষা করার মতো কোনো access আপনাকে দেবে না।

immutable server-এ package কীভাবে install করব?

Package-টি image-এ যোগ করে redeploy করুন। bootc-এ Containerfile-এ একটি RUN dnf -y install ... line যোগ করতে হয়, তারপর rebuild, push এবং machine-এ sudo bootc upgrade --apply চালাতে হয়। Fedora CoreOS-এ sudo rpm-ostree install ব্যবহার করে package layer করা যায় এবং reboot করা যায়, তবে পরবর্তী প্রতিটি update-এ package-টি আবার প্রয়োগ হবে। Flatcar ও Talos-এ package manager নেই, তাই এর উত্তর হলো container। bootc host-এ একবারের debugging tool দরকার হলে sudo bootc usr-overlay একটি writable /usr দেয়, যা পরবর্তী reboot-এ অদৃশ্য হয়ে যায়।

kernel update-এর পরে boot না করা VPS কি image mode ঠিক করতে পারে?

এটি recovery-কে rescue-console কাজের বদলে reboot-এ পরিণত করে। আগের image, kernel এবং userspace একসঙ্গে disk-এ থেকে যায়। তাই sudo bootc rollback বা sudo rpm-ostree rollback -r ব্যবহার করে আগের অবস্থায় ফিরে যাওয়া যায়। Talos ও Flatcar আরও এগিয়ে নতুন slot boot করতে ব্যর্থ হলে কোনো নির্দেশ ছাড়াই rollback করে, কারণ একটি boot entry একবার সফলভাবে boot হওয়ার পরেই default হয়। এর কোনোটিই খারাপ update প্রতিরোধ করে না। তবে একটি update বাতিল করা সহজ করে।

server-এর জন্য কোন immutable distro বেছে নেব?

সাধারণ উদ্দেশ্যের Linux server চাইলে bootc বেছে নিন, যেটি container image-এর মতো build করা যায় এবং ইতিমধ্যে থাকা machine-এ install করা যায়। Build নিজে না করে এই model এবং শুরু থেকেই automatic update চাইলে Fedora CoreOS বেছে নিন। A/B update scheme-সহ একটি minimal container host এবং ব্যবহারের জন্য কোনো package manager না চাইলে Flatcar বেছে নিন। Machine-টি Kubernetes node হলেই Talos বেছে নিন, কারণ এতে login shell নেই এবং এটি অন্য কিছু চালায় না।