সার্ভারে ইমিউটেবল Linux ডিস্ট্রিবিউশন ব্যবহারের সুবিধা

ইমিউটেবল (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 সার্ভার রক্ষণাবেক্ষণ চেকলিস্ট শৃঙ্খলার মাধ্যমে সমাধান করে, তবে এখানে তা ফাইলসিস্টেমের মাধ্যমেই নিয়ন্ত্রিত হয়।

রোলব্যাক মানেই রিবুট, আর এটাই এর মূল সুবিধা

এই মডেলটি যে ধরনের ব্যর্থতা মোকাবিলার জন্য তৈরি, তা আমরা আগেই নথিবদ্ধ করেছি: একটি VPS যা কার্নেল আপডেটের পর বুট হয় না। প্যাকেজ মোডে আপনি প্রোভাইডারের রেসকিউ কনসোল থেকে রিকভারি করেন। আপনি ডিস্ক মাউন্ট করেন, chroot করেন এবং হাতে কার্নেল প্যাকেজ রিমুভ করেন। এটি কাজ করে কারণ বুটলোডার পুরনো কার্নেলগুলো রেখে দেয়, কিন্তু শুধুমাত্র কার্নেলই এভাবে ভার্সন করা থাকে। একই ট্রানজ্যাকশনে আসা glibc আপডেট এবং systemd-এর পরিবর্তনগুলো ইতিমধ্যে প্রয়োগ হয়ে গেছে, এবং কোনো একক কমান্ড দিয়ে সেগুলোকে একসাথে আগের অবস্থায় ফিরিয়ে নেওয়া যায় না।

ইমেজ মোডে পুরো সিস্টেমটিই একটি ইউনিট। একটি bootc হোস্টে:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback বুটলোডার অর্ডারিং পরিবর্তন করে আগের বুট এন্ট্রিতে ফিরিয়ে নেয়, যা হলো সেই ইমেজটি যা আপনি এক ঘণ্টা আগে চালাচ্ছিলেন, কার্নেল এবং ইউজারস্পেসসহ। কোনো কিছু ডাউনলোড বা রিবিল্ড করার প্রয়োজন হয় না, কারণ পুরনো ইমেজটি ডিস্ক থেকে কখনোই মুছে যায়নি।

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

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

প্রথমে Zincati বন্ধ করুন। Zincati হলো সেই এজেন্ট যা Fedora CoreOS মেশিনকে নতুন রিলিজে রাখে, তাই এটি চালু রাখলে আপনি যে আপডেটটি বাতিল করেছেন তা আবার চলে আসবে। -r রোলব্যাক স্টেজ করা হলে রিবুট করে। আপনার পছন্দের একটি ডিপ্লয়মেন্ট যাতে গার্বেজ কালেকশন (garbage collected) না হয় তা নিশ্চিত করতে:

sudo ostree admin pin 0
rpm-ostree status

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

Talos-এর ক্ষেত্রে আপনার ওয়ার্কস্টেশন থেকে একটি মাত্র API কলই যথেষ্ট:

talosctl rollback --nodes 10.20.30.40

Flatcar দুটি /usr পার্টিশন রাখে এবং সেগুলোর মধ্যে অদলবদল করে। প্রতিটি স্লটের পার্টিশন টেবিলে একটি প্রায়োরিটি এবং ট্রাই কাউন্টার থাকে, তাই যে স্লটটি সফলভাবে বুট হয় না সেটি ট্রাই কাউন্টার শেষ করে ফেলে এবং বুটলোডার অন্যটিকে বেছে নেয়। আপনি কোন স্লটে আছেন এবং সেটি 'good' হিসেবে চিহ্নিত কি না তা পরীক্ষা করুন:

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

একটি সুস্থ চলমান স্লট priority=1 tries=0 successful=1 সম্বলিত একটি লাইন প্রিন্ট করে। যদি এমন কোনো লাইন না থাকে, তার মানে বর্তমান স্লটটি কখনোই নিশ্চিত (confirmed) হয়নি, যা একটি মেশিনের আপডেট এবং প্রথম সফল বুটের মধ্যবর্তী অবস্থা।

"install a package"-এর বিকল্প: bootc এবং Containerfile

bootc হলো এমন একটি টুল যা এই পদ্ধতিকে সাধারণীকরণ করেছে। এটি নিজেকে OCI (open container initiative) কন্টেইনার ইমেজ ব্যবহার করে ট্রানজ্যাকশনাল, ইন-প্লেস অপারেটিং সিস্টেম আপডেট হিসেবে বর্ণনা করে এবং এটি একটি CNCF স্যান্ডবক্স প্রজেক্ট। আপনার সার্ভার এখন একটি 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 ইমেজ সোর্স থেকে তথ্য সংগ্রহ করে এবং পরবর্তী বুটের জন্য নতুন ইমেজ কিউতে রাখে। --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-এর অধীনে থাকে, তাই যে সফটওয়্যার তার নিজস্ব ইনস্টল ডিরেক্টরিতে লিখতে চায়, সেটির জন্য বিল্ডের সময় একটি সিমলিংক বা 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-এর ধারাবাহিক সংস্করণ এবং সাধারণ ব্যবহারের উপযোগী বিকল্পগুলোর মধ্যে এটি সবচেয়ে কঠোর। এখানে কোনো প্যাকেজ ম্যানেজার নেই যার ওপর নির্ভর করা যায়। আপনি যা কিছু চালাবেন, তা সবই কন্টেইনার। এর প্রভিশনিং-এর জন্য Ignition ব্যবহৃত হয়, যা Fedora CoreOS-এর মতোই। আপডেটগুলো উপরে বর্ণিত দুটি 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, কোনো shell এবং কোনো console login নেই। প্রতিটি অপারেশন হলো একটি gRPC API কল, যা আপনার workstation থেকে talosctl ব্যবহার করে করা হয় এবং এটি এমন একটি machine config-এর বিপরীতে কাজ করে যা আপনি git-এ রাখেন।

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

যে release-এ আপনি যেতে চাচ্ছেন, সেই tag-টি প্রতিস্থাপন করুন। upgrade-টি একটি A-B scheme ব্যবহার করে যা পূর্ববর্তী kernel এবং OS image সংরক্ষণ করে। তাই নতুনটি boot করতে ব্যর্থ হলে, Talos কোনো হস্তক্ষেপ ছাড়াই স্বয়ংক্রিয়ভাবে roll back করে। Debugging-এর পদ্ধতি ভিন্ন কারণ এখানে কোনো shell নেই: আপনি বক্সে journalctl ব্যবহার করার পরিবর্তে talosctl logs এবং talosctl dmesg ব্যবহার করবেন।

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

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

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

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

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

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

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

ভাড়া করা VPS-এ এগুলো সেটআপ করা

প্রথমে আপনার প্রোভাইডারের কাছ থেকে দুটি বিষয় নিশ্চিত করুন: আপনার কাছে out-of-band console access (যেমন VNC বা serial console) আছে কি না এবং আপনি rescue system-এ বুট করতে পারেন কি না। কনসোল ছাড়া, কোনো মেশিন বুট না হলে সেটি ঠিক করতে পাঁচ মিনিটের বদলে সাপোর্ট টিকেটের ওপর নির্ভর করতে হবে।

যদি প্রোভাইডার কাস্টম ইমেজ গ্রহণ করে, তবে ভেন্ডরের raw বা qcow2 ইমেজ আপলোড করলেই কাজ শেষ। অন্যথায়, আপনাকে 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 environment-এ অবশ্যই bash, bzip2 বা lbzip2, lsblk, wget, udevadm, gpg এবং gawk থাকতে হবে। আপনার ignition.json-এ অবশ্যই একটি SSH key থাকতে হবে, অন্যথায় ইনস্টল করা সিস্টেমে প্রবেশ করার কোনো উপায় থাকবে না।

Fedora CoreOS-এর ক্ষেত্রেও একই নিয়ম প্রযোজ্য এবং এর ইনস্টলার একটি কন্টেইনার হিসেবে চলে:

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-এর ডকুমেন্টেশন পড়ুন এবং এমন একটি সার্ভারে পরীক্ষা করুন যা নষ্ট হলেও সমস্যা নেই। রিবুট করার পর মেশিনটি ইমেজ অনুযায়ী চলবে এবং আপনার আগের প্যাকেজ সেটগুলো মুছে যাবে।

কার জন্য immutable server উপযুক্ত এবং কার জন্য নয়

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

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

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

FAQ

একটি immutable Linux ডিস্ট্রো কি সত্যিই অপরিবর্তনীয়?

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

আমার VPS-এ যদি Fedora CoreOS বা Flatcar সাপোর্ট না থাকে, তবে কি আমি সেগুলো চালাতে পারি?

সাধারণত হ্যাঁ, যদি প্রোভাইডার আপনাকে একটি rescue system এবং console access দেয়। আপনি rescue মোডে বুট করে ডিস্ট্রিবিউশনের ডিস্ক ইমেজটি ব্লক ডিভাইসে রাইট করবেন এবং তারপর রিবুট করবেন। Flatcar-এর flatcar-install স্ক্রিপ্ট যেকোনো Linux থেকে এটি করতে পারে এবং Fedora CoreOS coreos-installer-কে একটি কন্টেইনার হিসেবে সরবরাহ করে যা একইভাবে চালানো যায়। উভয়ের জন্যই একটি Ignition ফাইল প্রয়োজন যাতে আপনার SSH key থাকবে, কারণ প্রথমবার বুট করার সময় পাসওয়ার্ড দেওয়ার কোনো সুযোগ থাকে না। console access ছাড়া এটি করার চেষ্টা করবেন না: মেশিনটি যদি বুট না হয়, তবে আপনি কোনো সমস্যা দেখার সুযোগ পাবেন না।

একটি immutable সার্ভারে আমি কীভাবে প্যাকেজ ইনস্টল করব?

আপনি এটিকে ইমেজে যোগ করবেন এবং পুনরায় ডিপ্লয় করবেন। bootc-এর ক্ষেত্রে এটি Containerfile-এ একটি RUN dnf -y install ... লাইন, তারপর একটি রিবিল্ড, একটি পুশ এবং মেশিনে sudo bootc upgrade --apply কমান্ড। Fedora CoreOS-এ আপনি sudo rpm-ostree install দিয়ে প্যাকেজ লেয়ার করতে পারেন এবং রিবুট করতে পারেন, তবে এর ফলে প্রতিটি ভবিষ্যতের আপডেটে প্যাকেজটি পুনরায় প্রয়োগ করতে হবে। Flatcar এবং Talos-এ কোনো প্যাকেজ ম্যানেজার নেই, তাই এর সমাধান হলো কন্টেইনার। bootc হোস্টের কোনো সাময়িক ডিবাগিং টুলের জন্য, sudo bootc usr-overlay আপনাকে একটি রাইটেবল /usr দেয় যা পরবর্তী রিবুটে মুছে যায়।

কার্নেল আপডেটের পর কোনো VPS বুট না হলে ইমেজ মোড কি তা ঠিক করতে পারে?

এটি রিকভারি প্রক্রিয়াকে rescue-console-এর কাজ থেকে রিবুট করার মতো সহজ করে তোলে। আগের ইমেজ, কার্নেল এবং ইউজারস্পেস ডিস্কে থেকে যায়, তাই sudo bootc rollback বা sudo rpm-ostree rollback -r ব্যবহার করে আপনি আগের অবস্থায় ফিরে যেতে পারেন। Talos এবং Flatcar আরও এক ধাপ এগিয়ে যায় এবং নতুন স্লট বুট করতে ব্যর্থ হলে স্বয়ংক্রিয়ভাবে রোলব্যাক করে, কারণ একটি বুট এন্ট্রি শুধুমাত্র একবার সফলভাবে বুট হওয়ার পরেই ডিফল্ট হিসেবে সেট হয়। এর কোনোটিই খারাপ আপডেট হওয়া আটকায় না, তবে এটি পূর্বাবস্থায় ফিরে যাওয়াকে সহজ করে তোলে।

সার্ভারের জন্য আমার কোন immutable ডিস্ট্রো বেছে নেওয়া উচিত?

আপনি যদি একটি সাধারণ কাজের Linux সার্ভার চান যা আপনি কন্টেইনার ইমেজের মতো তৈরি করবেন এবং যেকোনো মেশিনে ইনস্টল করতে পারবেন, তবে bootc বেছে নিন। আপনি যদি এমন মডেল চান যেখানে বিল্ড করার কাজ আগে থেকেই করা থাকে এবং স্বয়ংক্রিয় আপডেট পাওয়া যায়, তবে Fedora CoreOS বেছে নিন। আপনি যদি A/B আপডেট স্কিমসহ একটি মিনিমাল কন্টেইনার হোস্ট চান যেখানে কোনো প্যাকেজ ম্যানেজার নেই, তবে Flatcar বেছে নিন। শুধুমাত্র তখনই Talos বেছে নিন যখন মেশিনটি একটি Kubernetes নোড হিসেবে কাজ করবে, কারণ এতে কোনো শেল নেই এবং এটি অন্য কিছু চালায় না।