Immutable Linux distro सर्वर के लिए क्या सही है?

Immutable Linux distro क्या है

एक immutable Linux distro ऑपरेटिंग सिस्टम को एक सिंगल इमेज के रूप में प्रदान करता है, इसलिए आप सिस्टम को इन-प्लेस पैच करने के बजाय उसे पूरी तरह बदल देते हैं। चलते हुए सिस्टम पर apt upgrade /usr के अंतर्गत फाइलों को फिर से लिखने जैसा कुछ नहीं होता है। आप एक नई इमेज बनाते हैं या उसे पुल करते हैं, मशीन उसे वर्तमान में चल रही इमेज के साथ स्टेज करती है, और अगला रीबूट यह तय करता है कि कौन सी इमेज सक्रिय होगी। पिछली इमेज डिस्क पर ही रहती है, इसलिए किसी खराब अपडेट को हटाने के लिए केवल एक रीबूट की आवश्यकता होती है।

"Immutable" शब्द इसे जरूरत से ज्यादा बढ़ा-चढ़ाकर पेश करता है। भौतिक रूप से कोई भी चीज root को डिस्क पर लिखने से नहीं रोकती है। ये सिस्टम जो करते हैं, वह यह है कि सिस्टम डायरेक्टरीज को read-only मोड में माउंट करते हैं और उनका स्वामित्व इमेज को दे देते हैं। स्थायी डेटा /var में रहता है। मशीन-विशिष्ट कॉन्फ़िगरेशन /etc में रहता है। /usr के अंतर्गत सब कुछ इमेज का हिस्सा होता है, यही कारण है कि एक ही इमेज टैग चलाने वाले दो सर्वर में समान सिस्टम फाइलें होती हैं।

Red Hat द्वारा इन दो मॉडलों के लिए दिए गए नाम सबसे स्पष्ट हैं: package mode और image mode। Package mode एक चलता हुआ सिस्टम है जिसमें एक पैकेज मैनेजर होता है जो इसे एडिट करता है। Image mode कहीं और किया गया एक बिल्ड स्टेप है जो एक आर्टिफैक्ट तैयार करता है, और सर्वर का एकमात्र काम उस आर्टिफैक्ट को बूट करना होता है जिसे आप उसे पॉइंट करते हैं। नीचे दी गई हर बात उसी एक अंतर से निकलती है।

सर्वर पर read-only सिस्टम का महत्व

दो साल से चल रहे सर्वर का एक ऐसा इतिहास होता है जिसे किसी ने कहीं लिखा नहीं होता। एक जल्दबाजी भरी शाम का make install। किसी एक पैकेज के लिए जोड़ा गया third-party repository। outage के दौरान एडिट की गई और कभी भी configuration management में वापस न डाली गई config file। इसे configuration drift कहा जाता है, और यही कारण है कि आपके नोट्स से "वही" सर्वर दोबारा बनाने पर अक्सर एक ऐसी मशीन तैयार होती है जो अलग तरह से व्यवहार करती है। नोट्स में केवल इरादा होता है। डिस्क में सच्चाई होती है।

Image mode उस जगह को खत्म कर देता है जहाँ drift जमा होता है। /usr runtime पर read-only होता है, इसलिए हाथ से किया गया कोई भी install या तो तुरंत विफल हो जाता है या एक ऐसी layer के रूप में रिकॉर्ड हो जाता है जिसे आप एक command से देख सकते हैं। यह दो मशीनों के बीच के अंतर को पुरातात्विक खोज के बजाय स्पष्ट रूप से दृश्यमान बनाता है। यह वही समस्या है जिसे नियमित Linux सर्वर मेंटेनेंस चेकलिस्ट अनुशासन के साथ हल करती है, जिसे यहाँ filesystem द्वारा नियंत्रित किया जाता है।

Rollback का मतलब केवल एक reboot है, और यही इसकी मुख्य विशेषता है

यह मॉडल जिस विफलता के लिए बनाया गया है, वह वही है जिसे हम पहले ही document कर चुके हैं: एक VPS जो kernel update के बाद boot नहीं होता। Package mode में आप provider के rescue console से recovery करते हैं। आप disk को mount करते हैं, chroot करते हैं, और हाथ से kernel package को हटाते हैं। यह इसलिए काम करता है क्योंकि bootloader पुराने kernels को सुरक्षित रखता है, लेकिन केवल kernel ही इस तरह से versioned होता है। उसी transaction में आए glibc update और systemd बदलाव पहले ही लागू हो चुके होते हैं, और कोई एक command उन्हें एक साथ वापस नहीं ले जा सकती।

Image mode में पूरी unit ही पूरा system होती है। एक bootc host पर:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback bootloader के क्रम को वापस पिछली boot entry पर बदल देता है, जो कि वही image है जिसे आप एक घंटे पहले चला रहे थे, kernel और userspace दोनों के साथ। कुछ भी download नहीं होता और कुछ भी rebuild नहीं होता, क्योंकि पुरानी image कभी disk से हटती ही नहीं है।

Fedora CoreOS अलग नामों से यही काम करता है:

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

सबसे पहले Zincati को रोकें। Zincati वह agent है जो Fedora CoreOS machine को नवीनतम release पर रखता है, इसलिए यदि आप इसे चलते रहने देंगे तो यह उस update को फिर से stage कर देगा जिसे आपने अभी हटाया है। -r rollback stage होने के बाद reboot करता है। जिस deployment पर आप भरोसा करते हैं उसे garbage collection से बचाने के लिए:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status deployments को उस क्रम में दिखाता है जिस क्रम में bootloader उन्हें offer करेगा, चल रही deployment को एक dot के साथ चिह्नित करता है, और आपके द्वारा pin की गई deployment पर Pinned: yes दिखाता है।

Talos इसे आपके workstation से एक API call के रूप में करता है:

talosctl rollback --nodes 10.20.30.40

Flatcar दो /usr partitions रखता है और उनके बीच switch करता है। प्रत्येक slot में partition table के भीतर एक priority और एक try counter होता है, इसलिए जो slot कभी सफलतापूर्वक boot नहीं होता, उसके प्रयास समाप्त हो जाते हैं और bootloader दूसरे slot को चुन लेता है। जाँचें कि आप किस slot पर हैं और क्या उसे good के रूप में चिह्नित किया गया था:

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

एक स्वस्थ चल रहा slot एक line print करता है जिसमें priority=1 tries=0 successful=1 होता है। यदि कोई matching line नहीं मिलती है, तो इसका मतलब है कि वर्तमान slot की पुष्टि कभी नहीं हुई थी, जो कि वह स्थिति है जिसमें machine update और उसके पहले clean boot के बीच रहती है।

"install a package" की जगह क्या लेता है: bootc और एक Containerfile

bootc वह टूल है जिसने इस पैटर्न को सामान्यीकृत किया है। यह खुद को OCI (open container initiative) container images का उपयोग करके ट्रांसेक्शनल, इन-प्लेस ऑपरेटिंग सिस्टम अपडेट के रूप में वर्णित करता है, और यह एक 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 इमेज सोर्स को क्वेरी करता है और अगले बूट के लिए नई इमेज को कतार में लगाता है। --check रिपोर्ट करता है कि क्या कोई अपडेट उपलब्ध है और कुछ भी नहीं बदलता है। --apply इसे रिबूट करके लागू करता है। bootc switch registry.example.com/edge/web:next मशीन को एक अलग इमेज की ओर निर्देशित करता है जबकि /etc और /var को सुरक्षित रखता है, जो कि सर्वर को रीइंस्टॉल किए बिना इमेज स्ट्रीम के बीच ले जाने का तरीका है।

अनअटेंडेड अपडेट के लिए, उस टाइमर को इनेबल करें जिसे प्रोजेक्ट प्रदान करता है:

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

यह Ubuntu पर अनअटेंडेड अपग्रेड और Rocky और Alma पर dnf-automatic का इमेज-मोड उत्तर है। अंतर यह है कि क्या लागू होता है। पैकेज-मोड टाइमर उस रात रिपॉजिटरी में मौजूद किसी भी वर्जन को लागू करता है, इसलिए परिणामी सेट हर मशीन पर थोड़ा अलग होता है। इमेज-मोड टाइमर उस एक आर्टिफैक्ट को लागू करता है जिसे आपने पहले ही कहीं और बूट किया है।

उस Containerfile से दो बिल्ड नियम निकलते हैं। राइटेबल डेटा /var के अंतर्गत आता है, इसलिए जो सॉफ्टवेयर अपनी इंस्टॉलेशन डायरेक्टरी के अंदर लिखने पर जोर देता है, उसे बिल्ड समय पर एक सिमलिंक या systemd BindPaths= लाइन की आवश्यकता होती है। और /etc अपडेट पर थ्री-वे मर्ज किया जाता है, जिसका अर्थ है कि जिस फाइल को आपने कभी नहीं छुआ, वह इमेज का नया वर्जन प्राप्त कर लेती है, जबकि आपके द्वारा स्थानीय रूप से संपादित फाइल सुरक्षित रहती है।

जब आपको एक लाइव बॉक्स पर एक डीबगिंग सत्र के लिए किसी टूल की आवश्यकता हो:

sudo bootc usr-overlay
sudo dnf -y install strace

यह /usr पर एक ट्रांजिएंट राइटेबल ओवरले जोड़ता है जिसे अगले रिबूट पर हटा दिया जाता है। यह किसी समस्या को देखने के लिए है, न कि उसे ठीक करने के लिए। आप इस तरह से कर्नेल को नहीं बदल सकते हैं, और जो कुछ भी आप इंस्टॉल करते हैं वह डिजाइन के अनुसार रिबूट पर गायब हो जाता है।

Fedora CoreOS: एक बार provision करें, हमेशा update रखें

Fedora CoreOS में कोई interactive installer नहीं होता है। आप एक Butane YAML फ़ाइल लिखते हैं, उसे Ignition JSON में transpile करते हैं, और पहली बार boot होते समय मशीन को वह सौंप देते हैं:

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

Ignition केवल पहली बार boot होने पर initramfs में चलता है। यह वह हिस्सा है जहाँ cloud-init से आने वाले लोग अक्सर गलती करते हैं। यदि config में कोई SSH key नहीं है, तो मशीन बिना किसी access के boot होगी, और इसका एकमात्र समाधान इसे शुरू से दोबारा provision करना है। किसी महत्वपूर्ण सर्वर पर config लागू करने से पहले उसे एक अस्थायी मशीन पर test करें।

Live environment से disk पर install करना:

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

Updates डिफ़ॉल्ट रूप से automatic होते हैं। आप यह नियंत्रित करते हैं कि वे कब होंगे, यह नहीं कि वे होंगे या नहीं। /etc/zincati/config.d/55-updates-strategy.toml पर एक TOML फ़ाइल रखें जो periodic strategy का चयन करती है:

[updates]
strategy = "periodic"

उस strategy के अंतर्गत आप प्रत्येक array-of-tables entry के लिए एक maintenance window जोड़ते हैं, इसलिए प्रत्येक window का नाम updates.periodic.window के रूप में double square brackets के अंदर header के तौर पर लिखा जाता है, जिसके बाद तीन keys होती हैं:

• days, दिनों के नामों की एक सूची, जैसे "Sat" और "Sun"।
• start_time, वह समय जब window खुलती है, जिसे "22:30" के रूप में लिखा जाता है।
• length_minutes, यह कितनी देर तक खुली रहती है, जैसे 60।

ये समय UTC में होते हैं। Updates को पूरी तरह रोकने के लिए, sudo systemctl disable --now zincati.service चलाएँ, और यह स्वीकार करें कि अब patching schedule की जिम्मेदारी आपकी है।

Package layering एक escape hatch के रूप में मौजूद है:

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

यह package को जोड़कर एक नया deployment बनाता है, और बदलाव केवल reboot के बाद ही प्रभावी होता है। इसकी कीमत बाद में चुकानी पड़ती है। आपका layered set हर नए base image के ऊपर फिर से लागू किया जाता है, इसलिए यदि कोई package update के दिन repository से गायब हो जाता है, तो वह update विफल हो जाएगा। Fedora का अपना documentation आपको किसी भी महत्वपूर्ण कार्य के लिए containers का उपयोग करने, और जब आपको वास्तव में OS बदलने की आवश्यकता हो, तो bootc image का उपयोग करने की सलाह देता है।

Flatcar Container Linux: इसमें कोई package manager नहीं है

Flatcar, CoreOS Container Linux का ही विस्तार है और सामान्य उपयोग वाले विकल्पों में सबसे सख्त है। इसमें निर्भर रहने के लिए कोई package manager नहीं है। आप जो कुछ भी चलाते हैं, वह एक container होता है। Provisioning के लिए Ignition का उपयोग होता है, जो Fedora CoreOS के समान है। Updates ऊपर वर्णित दो A/B /usr partitions के माध्यम से होते हैं, जो update_engine द्वारा संचालित होते हैं, और locksmithd यह तय करता है कि reboot कब होगा।

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT का अर्थ है कि passive slot में पहले से ही नई image मौजूद है और केवल reboot बाकी है। डिफ़ॉल्ट reboot strategy reboot है जिसमें पाँच मिनट की देरी होती है, इसलिए यदि आप अन्यथा निर्देश नहीं देते हैं, तो एक अकेला production VPS अपने स्वयं के schedule पर restart हो जाएगा। /etc/flatcar/update.conf में एक window सेट करें:

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

REBOOT_STRATEGY=off reboot का निर्णय आप पर छोड़ देता है। उसी file में SERVER=disabled update check को पूरी तरह से रोक देता है। Cluster के लिए, REBOOT_STRATEGY=etcd-lock को locksmithctl set-max 4 के साथ मिलाने पर यह सीमित हो जाता है कि एक बार में कितने nodes reboot हो सकते हैं, ताकि कोई update पूरे fleet को एक साथ बंद न कर दे।

Talos Linux: कोई shell नहीं, कोई SSH नहीं, कोई console नहीं

Talos इन चारों में सबसे सीमित है और अपने उद्देश्य के प्रति सबसे स्पष्ट है। यह Kubernetes nodes चलाता है। इसमें कोई SSH daemon, कोई shell और कोई console login नहीं है। प्रत्येक operation आपके workstation से talosctl का उपयोग करके किया गया एक gRPC API call है, जो उस machine config के विरुद्ध होता है जिसे आप git में रखते हैं।

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

Tag को उस release से बदलें जिस पर आप जा रहे हैं। यह upgrade एक A-B scheme का उपयोग करता है जो पिछले kernel और OS image को सुरक्षित रखता है, इसलिए यदि नया version boot होने में विफल रहता है, तो Talos बिना किसी हस्तक्षेप के स्वयं rollback कर लेता है। Debugging अलग तरह से होती है क्योंकि इसमें कोई shell नहीं है: आप box पर journalctl के बजाय talosctl logs और talosctl dmesg का उपयोग करते हैं।

यदि आपका workload Kubernetes नहीं है, तो Talos सही विकल्प नहीं है। यदि यह Kubernetes है, तो Talos एक पूरी श्रेणी की समस्याओं को समाप्त कर देता है, क्योंकि "किसी ने node में login करके कुछ बदल दिया" जैसी स्थिति के लिए यहाँ कोई जगह ही नहीं है।

VPS tenant वास्तव में क्या छोड़ता है

चलते सिस्टम पर Ad-hoc इंस्टॉलेशन। यह सबसे महत्वपूर्ण बदलाव है। किसी incident के दौरान रात के 2 बजे sudo apt install htop उपलब्ध नहीं होता। bootc पर आपको एक transient overlay मिलता है जो reboot के बाद खत्म हो जाता है। Fedora CoreOS पर आपको एक layered deployment मिलता है जिसके लिए reboot की आवश्यकता होती है। Flatcar और Talos पर आपको कुछ नहीं मिलता।

एक build pipeline जो पहले आपके पास नहीं थी। किसी package को जोड़ने का मतलब है Containerfile को edit करना, image को build करना, उसे registry में push करना और servers को roll करना। जब pipeline पहले से मौजूद हो तो यह आसान है। यदि यह मौजूद न हो, तो इसे तैयार करना एक वास्तविक काम है। इसके लिए एक ऐसी registry की आवश्यकता होती है जिसे servers access कर सकें, जो या तो एक अतिरिक्त service है जिसे चलाना होगा या एक और बिल है जिसका भुगतान करना होगा।

Kernel modules। Kernel image से आता है, इसलिए चल रहे kernel के लिए compile किया गया module अगले update के बाद सुरक्षित नहीं रहता। Out-of-tree modules और DKMS (dynamic kernel module support) packages को image के अंदर, उस image के kernel के विरुद्ध build करना पड़ता है। जिस किसी भी चीज़ के लिए ऐसे module की आवश्यकता होती है जो base image में नहीं है, वह एक install problem के बजाय एक build problem बन जाता है।

Vendor और provider agents। Monitoring और backup agents आमतौर पर .deb या .rpm के रूप में आते हैं, जिसमें एक install script होती है जो /usr में लिखती है और एक unit को enable करती है। Read-only सिस्टम पर वह script विफल हो जाती है। कुछ vendors container publish करते हैं या image-mode इंस्टॉलेशन का documentation देते हैं। बहुत से ऐसा नहीं करते। प्रतिबद्ध होने से पहले इसकी जाँच करें, क्योंकि जिस fleet को आप monitor नहीं कर सकते, वह drift करने वाली fleet से भी बदतर है।

स्वयं image। लगभग कोई भी VPS control panel Ubuntu और Debian के साथ Fedora CoreOS, Flatcar या Talos को सूचीबद्ध नहीं करता है। आपको स्वयं disk प्रदान करनी होती है, जो कि अगला भाग है।

किराए पर लिए गए VPS पर इन्हें इंस्टॉल करना

सबसे पहले अपने प्रदाता (provider) के बारे में दो चीजें सुनिश्चित करें: आपके पास आउट-ऑफ-बैंड कंसोल एक्सेस (VNC या सीरियल कंसोल) होना चाहिए, और आप एक रेस्क्यू सिस्टम (rescue system) बूट करने में सक्षम होने चाहिए। कंसोल के बिना, यदि मशीन वापस बूट नहीं होती है, तो आपको सपोर्ट टिकट खोलना पड़ेगा, जबकि कंसोल होने पर इसे पाँच मिनट में ठीक किया जा सकता है।

यदि प्रदाता कस्टम इमेज स्वीकार करता है, तो वेंडर की 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

इसे हमेशा रेस्क्यू सिस्टम से चलाएं, उस सर्वर से कभी नहीं जिसे आप बदल रहे हैं, क्योंकि यह स्क्रिप्ट काम करते समय टारगेट डिवाइस को रिपार्टिशन (repartition) करती है। इसे डिवाइस पर कम से कम 8 GB उपयोग योग्य स्थान की आवश्यकता होती है, और रेस्क्यू एनवायरनमेंट में 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 एक ऐसा रास्ता प्रदान करता है जो रेस्क्यू मोड को छोड़ देता है, क्योंकि यह चल रहे 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

इसे चलाने से पहले उस बेस इमेज के लिए डॉक्यूमेंटेशन पढ़ें जिसका आप उपयोग कर रहे हैं, और इसे ऐसे सर्वर पर आज़माएं जिसे आप हटा सकें। रीबूट के बाद मशीन इमेज को चलाती है, और आपके पास मौजूद पैकेज सेट हट जाता है।

किसे immutable server चलाना चाहिए और किसे नहीं

यदि आपके सर्वर 'cattle' (मवेशी) की तरह हैं, तो आपको इसकी आवश्यकता है। एक ही recipe से कई मशीनें बनाना। CI (continuous integration) runners जो केवल एक घंटे के लिए चलते हैं। k3s या Kubernetes nodes जिन्हें ठीक करने के बजाय बदला जाता है। ऐसी कोई भी स्थिति जहाँ खराब सर्वर का समाधान केवल "इसे डिलीट करें और दूसरा बनाएँ" है, वहाँ यह उपयोगी है। यह तब भी फायदेमंद है जब आपको किसी ऑडिटर को यह साबित करना हो कि मशीन पर क्या चल रहा है, क्योंकि इसका उत्तर package list के बजाय एक image digest होता है।

यदि आपके पास केवल एक hand-tended VPS है जिस पर तीन services चल रही हैं, आप जरूरत पड़ने पर चीजें install करते हैं, और आपके पास कोई build pipeline नहीं है, तो आपको इसकी आवश्यकता नहीं है। Image mode काम को कम नहीं करता है। यह काम को सर्वर से हटाकर build प्रक्रिया में ले जाता है, और इसके लिए आपको एक registry और pipeline की आवश्यकता होती है। यदि आपके पास उस काम को संभालने के लिए बुनियादी ढांचा है, तो आपको एक जैसे सर्वर मिलते हैं और rollback केवल एक reboot बन जाता है। यदि आपके पास ऐसा नहीं है, तो आपने एक ठीक चल रहे सर्वर में अनावश्यक जटिलता जोड़ दी है, जिससे रात के 2 बजे आने वाली समस्याएं और कठिन हो सकती हैं।

बीच का सामान्य रास्ता अभी भी कारगर है: automatic security updates के साथ एक सामान्य Linux distribution, और एक ऐसा rebuild जिसे आपने वास्तव में अभ्यास में लाया हो। उस आधार को चुनना एक अलग निर्णय है, जिसे अपने VPS पर कौन सा OS चलाएं, यह चुनना में कवर किया गया है। Image mode इस पुरानी बहस का सबसे नया दौर है कि सॉफ्टवेयर मशीन तक कैसे पहुँचना चाहिए, और Linux distributions का इतिहास काफी हद तक इसी बहस की पुनरावृत्ति है।

FAQ

क्या एक immutable Linux distro वास्तव में immutable होता है?

नहीं, और यह नाम भ्रम पैदा करता है। root अभी भी डिस्क पर लिख सकता है। वास्तव में होता यह है कि runtime पर /usr को read-only mount किया जाता है और अगले image के आने पर उसे पूरी तरह बदल दिया जाता है, जबकि /etc और /var writable रहते हैं और updates के बाद भी बने रहते हैं। /usr के अंतर्गत किए गए बदलाव या तो उस समय अस्वीकार कर दिए जाते हैं या अगले update पर हटा दिए जाते हैं, इसलिए व्यावहारिक रूप से system directories केवल तभी बदलती हैं जब image बदलती है।

क्या मैं ऐसे VPS पर Fedora CoreOS या Flatcar चला सकता हूँ जो उन्हें offer नहीं करता?

आमतौर पर हाँ, यदि provider आपको rescue system और console access देता है। आप rescue mode में boot करें, distribution की disk image को block device पर लिखें, और फिर reboot करें। Flatcar की flatcar-install script किसी भी Linux से ऐसा कर सकती है, और Fedora CoreOS coreos-installer को एक container के रूप में प्रदान करता है जिसे आप उसी तरह चला सकते हैं। दोनों को एक Ignition file की आवश्यकता होती है जिसमें आपकी SSH key हो, क्योंकि इसमें first-boot password prompt जैसा कोई विकल्प नहीं होता। यदि console access न हो, तो ऐसा करने का प्रयास न करें: यदि machine वापस boot नहीं होती है, तो आपके पास जाँचने के लिए कुछ नहीं बचेगा।

मैं एक immutable server पर package कैसे install करूँ?

आप इसे image में जोड़ते हैं और redeploy करते हैं। bootc पर यह Containerfile में एक RUN dnf -y install ... लाइन है, जिसे rebuild और push करने के बाद machine पर sudo bootc upgrade --apply चलाना होता है। Fedora CoreOS पर आप इसे sudo rpm-ostree install के साथ layer कर सकते हैं और reboot कर सकते हैं, लेकिन इसकी कीमत यह है कि वह package हर भविष्य के update पर फिर से apply होगा। Flatcar और Talos पर कोई package manager नहीं है, इसलिए इसका उत्तर एक container है। bootc host पर एक बार के debugging tool के लिए, sudo bootc usr-overlay आपको एक writable /usr देता है जो अगले reboot पर गायब हो जाता है।

क्या image mode उस VPS को ठीक करता है जो kernel update के बाद boot नहीं होता?

यह recovery को rescue-console के काम से बदलकर एक साधारण reboot बना देता है। पिछली image, kernel और userspace के साथ, अभी भी disk पर होती है, इसलिए sudo bootc rollback या sudo rpm-ostree rollback -r आपको वापस उस पर ले आता है। Talos और Flatcar इससे आगे बढ़कर बिना कहे ही roll back कर देते हैं जब नया slot boot होने में विफल रहता है, क्योंकि एक boot entry केवल एक सफल boot के बाद ही default बनती है। इनमें से कोई भी खराब update को रोकता नहीं है। यह उसे undo करना आसान बनाता है।

मुझे server के लिए कौन सा immutable distro चुनना चाहिए?

यदि आप एक general-purpose Linux server चाहते हैं जिसे आप container image की तरह build करते हैं और अपनी existing machine पर install कर सकते हैं, तो bootc चुनें। यदि आप वही model चाहते हैं जिसमें building आपके लिए पहले से हो और automatic updates भी मिलें, तो Fedora CoreOS चुनें। यदि आप A/B update scheme वाला एक minimal container host चाहते हैं जिसमें कोई package manager न हो, तो Flatcar चुनें। Talos केवल तभी चुनें जब machine एक Kubernetes node हो, क्योंकि इसमें कोई shell नहीं होता और यह कुछ और नहीं चलाता।