Sunucularda Immutable Linux Dağıtımları Kullanımı

Değişmez (immutable) Linux dağıtımı nedir

Değişmez bir Linux dağıtımı, işletim sistemini tek bir imaj olarak sunar; bu nedenle sistemi yerinde yamalamak yerine bütünüyle değiştirirsiniz. Çalışan bir makinede apt upgrade dizini altındaki dosyaları /usr ile yeniden yazmak gibi bir durum söz konusu değildir. Yeni bir imaj oluşturur veya çekersiniz; makine bu imajı çalışmakta olanın yanına hazırlar ve bir sonraki yeniden başlatmada hangisinin aktif olacağını değiştirir. Önceki imaj diskte kalmaya devam eder, bu sayede hatalı bir güncellemeyi geri almak yalnızca bir yeniden başlatma işleminden ibarettir.

"Değişmez" kelimesi bu durumu biraz abartılı yansıtır. Fiziksel olarak root kullanıcısının diske yazmasını engelleyen bir şey yoktur. Bu sistemlerin yaptığı, sistem dizinlerini salt okunur (read-only) olarak bağlamak ve bunların sahipliğini imaja vermektir. Kalıcı veriler /var içinde barınır. Makineye özgü yapılandırmalar ise /etc içinde yer alır. /usr altındaki her şey imaja aittir; aynı imaj etiketini çalıştıran iki sunucunun tamamen aynı sistem dosyalarına sahip olmasının nedeni budur.

Red Hat'in bu iki model için kullandığı isimlendirmeler en net olanlarıdır: paket modu ve imaj modu. Paket modu, çalışan bir sistem ve onu düzenleyen bir paket yöneticisinden oluşur. İmaj modu ise başka bir yerde gerçekleştirilen bir derleme adımıyla bir çıktı (artifact) üretilmesi ve sunucunun tek görevinin işaret ettiğiniz bu çıktıyı başlatmak olmasıdır. Aşağıdaki her şey bu tek farktan kaynaklanmaktadır.

Bir sunucuda salt okunur sistem neden daha önemlidir

İki yıldır çalışan bir sunucunun, kimsenin kaydetmediği bir geçmişi vardır. Aceleyle geçen bir akşamdan kalma bir make install. Tek bir paket için eklenmiş üçüncü taraf bir depo. Bir kesinti sırasında düzenlenip yapılandırma yönetiminize geri işlenmemiş bir yapılandırma dosyası. Bunun adı yapılandırma sapmasıdır (configuration drift) ve "aynı" sunucuyu notlarınızdan yeniden oluşturduğunuzda neden genellikle farklı davranan bir makine elde ettiğinizin sebebidir. Notlar niyeti barındırır. Disk ise gerçeği barındırır.

İmaj modu, sapmanın biriktiği alanı ortadan kaldırır. /usr çalışma zamanında salt okunurdur; bu nedenle elle yapılan bir kurulum ya doğrudan başarısız olur ya da tek bir komutla listeleyebileceğiniz bir katman olarak kaydedilir. Bu, iki makine arasındaki farkı arkeolojik bir çalışma yerine görünür kılar. Bu, düzenli bir Linux sunucu bakım kontrol listesi ile disiplinle çözülmeye çalışılan sorunun aynısıdır; ancak bu sefer dosya sistemi düzeyinde ele alınır.

Geri alma işlemi bir yeniden başlatmadır ve tüm mantık bundan ibarettir

Bu modelin tasarlandığı hata senaryosu, halihazırda belgelendirdiğimiz durumdur: çekirdek güncellemesi sonrası açılmayan bir VPS. Paket modunda kurtarma işlemini sağlayıcının kurtarma konsolu üzerinden yaparsınız. Diski bağlar, chroot ile içeri girer ve bir çekirdek paketini elle kaldırırsınız. Bu yöntem çalışır çünkü önyükleyici eski çekirdekleri tutar, ancak yalnızca çekirdek bu şekilde sürümlenir. Aynı işlemle gelen glibc güncellemesi ve systemd değişiklikleri çoktan uygulanmıştır ve bunları tek bir komutla birlikte geri almanın yolu yoktur.

İmaj modunda ise birim tüm sistemdir. Bir bootc ana makinesinde:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback, önyükleyici sıralamasını bir saat önce çalıştırdığınız imaj olan bir önceki önyükleme girdisine geri döndürür; bu hem çekirdeği hem de kullanıcı alanını kapsar. Hiçbir şey indirilmez ve hiçbir şey yeniden oluşturulmaz, çünkü eski imaj diskten hiç silinmemiştir.

Fedora CoreOS aynı işlemi farklı isimlerle gerçekleştirir:

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

Önce Zincati'yi durdurun. Zincati, Fedora CoreOS makinesini en güncel sürümde tutan aracıdır; bu nedenle çalışır durumda bırakırsanız, az önce geri aldığınız güncellemeyi tekrar hazırlayacaktır. -r, geri alma işlemi hazırlandığında sistemi yeniden başlatır. Güvendiğiniz bir dağıtımın çöp toplayıcı tarafından silinmesini önlemek için:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status, dağıtımları önyükleyicinin sunacağı sırayla listeler, çalışan dağıtımı bir nokta ile işaretler ve sabitlediğiniz dağıtımı Pinned: yes ile gösterir.

Talos, bu işlemi iş istasyonunuzdan tek bir API çağrısı ile yapar:

talosctl rollback --nodes 10.20.30.40

Flatcar iki adet /usr bölümü tutar ve bunlar arasında geçiş yapar. Her yuva, bölüm tablosunda bir önceliğe ve deneme sayacına sahiptir; bu sayede başarıyla açılmayan bir yuvanın deneme hakkı biter ve önyükleyici diğerini seçer. Hangi yuvada olduğunuzu ve yuvanın başarılı olarak işaretlenip işaretlenmediğini kontrol edin:

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

Sağlıklı çalışan bir yuva, priority=1 tries=0 successful=1 içeren bir satır yazdırır. Eşleşen bir satırın olmaması, mevcut yuvanın hiçbir zaman onaylanmadığı anlamına gelir; bu, bir makinenin güncelleme ile ilk temiz önyükleme arasında bulunduğu durumdur.

"Paket kurmak" yerine ne kullanılır: bootc ve Containerfile

bootc, bu modeli genelleştiren araçtır. Kendisini OCI (open container initiative) konteyner imajlarını kullanarak yapılan işlemsel ve yerinde işletim sistemi güncellemeleri olarak tanımlar ve bir CNCF Sandbox projesidir. Sunucunuz bir Containerfile haline gelir. Ağustos 2026 itibarıyla Fedora temel imajı quay.io/fedora/fedora-bootc:44, CentOS Stream temel imajı ise quay.io/centos-bootc/centos-bootc:stream10 şeklindedir.

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

İmajı diğer tüm imajlar gibi derleyin ve gönderin:

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

Ardından sunucuda:

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade, imaj kaynağını sorgular ve yeni imajı bir sonraki önyükleme için kuyruğa alır. --check, bir güncellemenin mevcut olup olmadığını bildirir ve hiçbir şeyi değiştirmez. --apply, yeni imaja yeniden başlatma yapar. bootc switch registry.example.com/edge/web:next, makineyi farklı bir imaja yönlendirirken /etc ve /var dizinlerini korur; sunucuyu yeniden kurmadan farklı imaj akışları arasında taşımanın yolu budur.

Katılımsız güncellemeler için projenin sunduğu zamanlayıcıyı etkinleştirin:

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

Bu, Ubuntu üzerinde katılımsız yükseltmeler ve Rocky ve Alma üzerinde dnf-automatic konularına imaj tabanlı yaklaşımın cevabıdır. Fark, sisteme neyin yüklendiğidir. Paket tabanlı bir zamanlayıcı, o gece depoda hangi sürümler varsa onları uygular; bu nedenle ortaya çıkan yapı her makinede biraz farklı olur. İmaj tabanlı bir zamanlayıcı ise başka bir yerde zaten önyüklemesini yaptığınız tek bir yapıyı (artifact) uygular.

Bu Containerfile yapısından iki derleme kuralı çıkar. Yazılabilir veriler /var altında bulunmalıdır; bu nedenle kendi kurulum dizinine yazmakta ısrar eden yazılımlar için derleme zamanında bir sembolik bağ veya systemd BindPaths= satırı eklenmelidir. Ayrıca /etc, güncelleme sırasında üç yönlü birleştirilir (three-way merge); bu, hiç dokunmadığınız bir dosyanın imajın yeni sürümünü alacağı, yerel olarak düzenlediğiniz bir dosyanın ise korunacağı anlamına gelir.

Canlı bir sistemde tek seferlik bir hata ayıklama oturumu için bir araca ihtiyaç duyduğunuzda:

sudo bootc usr-overlay
sudo dnf -y install strace

Bu komut, /usr üzerinde bir sonraki yeniden başlatmada atılacak geçici ve yazılabilir bir katman ekler. Bu, sorunu incelemek içindir, düzeltmek için değil. Bu yöntemle çekirdeği değiştiremezsiniz ve kurduğunuz her şey tasarım gereği yeniden başlatmada kaybolur.

Fedora CoreOS: bir kez yapılandır, sonsuza dek güncelle

Fedora CoreOS etkileşimli bir yükleyiciye sahip değildir. Bir Butane YAML dosyası yazılır, bu dosya Ignition JSON formatına dönüştürülür ve ilk önyükleme sırasında makineye verilir:

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

Ignition yalnızca ilk önyüklemede initramfs içinde çalışır. cloud-init sisteminden gelen kullanıcıların en sık hata yaptığı nokta burasıdır. Yapılandırma dosyası bir SSH anahtarı içermiyorsa, makineye erişim yolu olmadan önyükleme gerçekleşir ve tek çözüm makineyi sıfırdan yeniden yapılandırmaktır. Yapılandırmayı, üzerinde çalıştığınız sunucuya uygulamadan önce geçici bir makinede test edin.

Canlı bir ortamdan diske kurulum yapmak için:

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

Güncellemeler varsayılan olarak otomatiktir. Güncellemenin yapılıp yapılmayacağını değil, ne zaman yapılacağını kontrol edersiniz. Periyodik stratejiyi seçmek için /etc/zincati/config.d/55-updates-strategy.toml dizinine bir TOML dosyası yerleştirin:

[updates]
strategy = "periodic"

Bu strateji altında, her tablo dizisi girişi için bir bakım penceresi eklersiniz; böylece her pencere, başlık olarak çift köşeli parantez içinde updates.periodic.window adıyla başlar ve ardından üç anahtar gelir:

• days, "Sat" ve "Sun" gibi gün adlarının listesi.
• start_time, pencerenin açıldığı an, "22:30" formatında yazılır.
• length_minutes, pencerenin ne kadar süre açık kalacağı, örneğin 60.

Bu zamanlar UTC bazlıdır. Güncellemeleri tamamen durdurmak için sudo systemctl disable --now zincati.service komutunu çalıştırın ve yama takviminin sorumluluğunun artık sizde olduğunu kabul edin.

Paket katmanlama (package layering), bir kaçış yolu olarak mevcuttur:

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

Bu komut, eklenen paketle birlikte yeni bir dağıtım oluşturur ve değişiklik yalnızca yeniden başlatmanın ardından geçerli olur. Bunun maliyeti ise daha sonra ortaya çıkar. Katmanlı kümeniz, her yeni temel imajın üzerine yeniden uygulanır; bu nedenle güncelleme gününde depodan kaldırılmış bir paket, güncellemenin başarısız olmasına neden olur. Fedora'nın kendi belgeleri, önemli her türlü işlem için container yapılarını, işletim sistemini gerçekten değiştirmeniz gerektiğinde ise bootc imajlarını kullanmanızı önerir.

Flatcar Container Linux: paket yöneticisi bulunmaması

Flatcar, CoreOS Container Linux'un devamıdır ve genel amaçlı seçenekler arasında en katı olanıdır. Başvurulabilecek bir paket yöneticisi yoktur. Çalıştırdığınız her şey bir container'dır. Provisioning işlemi, Fedora CoreOS ile aynı olan Ignition ile yapılır. Güncellemeler, yukarıda açıklanan iki adet A/B /usr bölümü üzerinden gerçekleştirilir; süreç update_engine tarafından yönetilir ve yeniden başlatmanın ne zaman gerçekleşeceğine locksmithd karar verir.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT, pasif bölümün yeni imajı halihazırda içerdiğini ve yalnızca yeniden başlatmanın beklendiğini ifade eder. Varsayılan yeniden başlatma stratejisi, beş dakikalık bir gecikme ile reboot şeklindedir; bu nedenle, aksi belirtilmediği sürece tek bir üretim VPS'i kendi zamanlamasına göre yeniden başlatılacaktır. /etc/flatcar/update.conf içerisinde bir pencere belirleyin:

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

REBOOT_STRATEGY=off, yeniden başlatma işlemini size bırakır. Aynı dosya içerisindeki SERVER=disabled, güncelleme denetimini tamamen durdurur. Bir küme (cluster) için REBOOT_STRATEGY=etcd-lock ve locksmithctl set-max 4 kombinasyonu, aynı anda kaç düğümün yeniden başlatılabileceğini sınırlar; böylece bir güncelleme tüm filoyu aynı anda devre dışı bırakmaz.

Talos Linux: kabuk yok, SSH yok, konsol yok

Talos, bu dört seçenek arasında en dar kapsamlı olanıdır ve amacını en net şekilde ortaya koyar. Kubernetes düğümlerini çalıştırır. SSH daemon, kabuk veya konsol girişi bulunmaz. Her işlem, iş istasyonunuzdan talosctl ile yapılan ve git üzerinde tuttuğunuz bir makine yapılandırmasına karşı gerçekleştirilen gRPC API çağrısıdır.

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

Etiketi, geçiş yapacağınız sürüm ile değiştirin. Yükseltme işlemi, önceki çekirdek ve işletim sistemi imajını koruyan bir A-B şeması kullanır; bu sayede yeni sürüm önyüklenemezse Talos herhangi bir müdahale gerektirmeden otomatik olarak geri döner. Kabuk bulunmadığı için hata ayıklama süreci farklı işler: makine üzerinde journalctl kullanmak yerine talosctl logs ve talosctl dmesg araçlarından yararlanırsınız.

İş yükünüz Kubernetes değilse, Talos yanlış tercihtir. Eğer Kubernetes ise, Talos tüm bir olay kategorisini ortadan kaldırır; çünkü "birisi düğüme giriş yaptı ve bir şeyi değiştirdi" durumu gerçekleşemez.

Bir VPS kiracısının aslında vazgeçtikleri

Çalışan bir sistem üzerinde geçici kurulumlar. En önemli konu budur. Bir olay anında gece saat 02:00'de sudo apt install htop kullanılamaz. bootc üzerinde, yeniden başlatma ile kaybolan geçici bir katman elde edersiniz. Fedora CoreOS üzerinde, yeniden başlatma gerektiren katmanlı bir dağıtım alırsınız. Flatcar ve Talos üzerinde ise hiçbir şey elde edemezsiniz.

Daha önce sahip olmadığınız bir derleme hattı. Bir paket eklemek, bir Containerfile dosyasını düzenlemek, imajı derlemek, bir kayıt defterine (registry) göndermek ve sunucuları güncellemek anlamına gelir. Hat mevcut olduğunda bu işlem kolaydır. Mevcut olmadığında ise kurulumu gerçek bir iştir; ayrıca sunucuların erişebileceği bir kayıt defteri gerektirir ki bu da çalıştırılması gereken başka bir servis veya ödenmesi gereken başka bir fatura demektir.

Çekirdek modülleri. Çekirdek, imajdan gelir; bu nedenle çalışan çekirdeğe göre derlenen bir modül, bir sonraki güncellemede varlığını sürdüremez. Ağaç dışı (out-of-tree) modüller ve DKMS (dynamic kernel module support) paketleri, imajın içine ve o imajın çekirdeğine göre derlenmelidir. Temel imajda bulunmayan bir modüle ihtiyaç duyan her şey, bir kurulum sorunu olmaktan çıkıp bir derleme sorununa dönüşür.

Satıcı ve sağlayıcı aracıları. İzleme ve yedekleme araçları genellikle .deb veya .rpm olarak, /usr dizinine yazan ve bir birimi (unit) etkinleştiren bir kurulum betiği ile birlikte gelir. Salt okunur bir sistemde bu betik başarısız olur. Bazı satıcılar bir container yayınlar veya imaj tabanlı bir kurulum dokümante eder. Birçoğu ise bunu yapmaz. Taahhütte bulunmadan önce bunu kontrol edin; çünkü izleyemediğiniz bir filo, sapma gösteren bir filodan daha kötüdür.

İmajın kendisi. Neredeyse hiçbir VPS kontrol paneli, Ubuntu ve Debian'ın yanında Fedora CoreOS, Flatcar veya Talos listelemez. Diski siz sağlarsınız; bu da bir sonraki bölümün konusudur.

Kiraladığınız bir VPS üzerinde kurulum

Öncelikle sağlayıcınız hakkında iki şeyi doğrulayın: VNC veya seri konsol gibi bant dışı (out-of-band) konsol erişiminizin olması ve bir kurtarma sistemini (rescue system) başlatabiliyor olmanız. Konsol erişimi yoksa, açılmayan bir makine beş dakikalık bir düzeltme yerine bir destek talebine dönüşür.

Sağlayıcı özel imajları kabul ediyorsa, tedarikçinin raw veya qcow2 imajını yükleyin; işlem tamamdır. Aksi takdirde diski kurtarma sisteminden kendiniz yazmanız gerekir. Flatcar, tam olarak bu iş için kendi kendine yeten bir betik sunar ve bu betik herhangi bir Linux üzerinde çalışır:

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

Bunu asla değiştirmekte olduğunuz sunucudan değil, kurtarma sisteminden çalıştırın; çünkü betik çalışırken hedef aygıtı yeniden bölümlendirir. Aygıt üzerinde en az 8 GB kullanılabilir alan gerekir ve kurtarma ortamı bash, bzip2 veya lbzip2, lsblk, wget, udevadm, gpg ve gawk araçlarını sağlamalıdır. ignition.json dosyanız bir SSH anahtarı içermelidir, aksi takdirde kurulan sisteme giriş yapamazsınız.

Fedora CoreOS da benzer bir yapıya sahiptir ve yükleyicisi bir container olarak çalışır:

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

Çalıştırmadan önce lsblk ile aygıt adını kontrol edin. Yanlış aygıta yazmak, üzerinde ne varsa siler ve herhangi bir onay istemi çıkmaz.

bootc, kurtarma modunu atlayan tek yolu sunar çünkü çalışan bir Linux sistemini yerinde dönüştürür:

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

Bunu çalıştırmadan önce kullandığınız temel imajın belgelerini okuyun ve gözden çıkarabileceğiniz bir sunucuda deneyin. Yeniden başlatmanın ardından makine imajı çalıştırır ve sahip olduğunuz paket seti silinir.

Değişmez (immutable) sunucuları kimler kullanmalı, kimler kullanmamalı

Sunucularınız "sürü" (cattle) mantığıyla yönetiliyorsa bu yöntemi tercih etmelisiniz. Tek bir tariften üretilen çok sayıda makine, bir saatlik ömrü olan CI (sürekli entegrasyon) çalıştırıcıları, onarılmak yerine yenisiyle değiştirilen k3s veya Kubernetes düğümleri buna örnektir. Bozuk bir makine için çözümün "sil ve yenisini oluştur" olduğu her senaryo için uygundur. Ayrıca bir denetçiye makinede neyin çalıştığını kanıtlamanız gerektiğinde, paket listesi yerine bir imaj özeti (image digest) sunabildiğiniz için büyük avantaj sağlar.

Eğer üzerinde üç servis barındıran, elle yönetilen tek bir VPS'niz varsa, ihtiyaç duydukça kurulum yapıyorsanız ve bir derleme hattınız (build pipeline) yoksa bu yöntemi tercih etmemelisiniz. İmaj modu iş yükünü ortadan kaldırmaz. İş yükünü sunucudan derleme aşamasına taşır ve bu taşıma için sizden bir kayıt defteri (registry) ve bir hat (pipeline) kullanmanızı talep eder. Bu iş yükünü yönetecek bir altyapınız varsa, birbirinin aynısı sunuculara ve yeniden başlatma kadar basit bir geri alma (rollback) sürecine sahip olursunuz. Eğer altyapınız yoksa, sorunsuz çalışan bir sisteme karmaşık parçalar eklemiş ve gece saat 02:00'de çıkacak bir sorunu daha da zorlaştırmış olursunuz.

Sıkıcı ama güvenli orta yol hala geçerlidir: otomatik güvenlik güncellemelerine sahip standart bir dağıtım ve üzerinde pratik yaptığınız bir yeniden oluşturma süreci. Bu temel yapıyı seçmek başlı başına bir karardır ve VPS üzerinde hangi işletim sisteminin çalıştırılacağını seçme konusunda ele alınmıştır. İmaj modu, yazılımın bir makineye nasıl ulaşması gerektiğine dair çok eski bir tartışmanın en yeni halkasıdır ve Linux dağıtımlarının tarihi büyük ölçüde bu tartışmanın kendini tekrar etmesinden ibarettir.

FAQ

Değişmez (immutable) bir Linux dağıtımı gerçekten değişmez midir?

Hayır, bu isimlendirme kafa karışıklığına yol açmaktadır. root kullanıcısı disk üzerine hala yazabilir. Gerçekte olan şudur: /usr çalışma zamanında salt okunur (read-only) olarak bağlanır ve bir sonraki imaj ile tamamen değiştirilir; /etc ve /var ise yazılabilir kalır ve güncellemelerden etkilenmez. /usr altında yaptığınız değişiklikler ya o an reddedilir ya da bir sonraki güncellemede silinir; dolayısıyla pratik sonuç, sistem dizinlerinin yalnızca imaj değiştiğinde değişmesidir.

Fedora CoreOS veya Flatcar'ı, bu dağıtımları sunmayan bir VPS üzerinde çalıştırabilir miyim?

Sağlayıcınız bir kurtarma sistemi (rescue system) ve konsol erişimi sağlıyorsa genellikle evet. Kurtarma modunda başlatma yapıp dağıtımın disk imajını blok aygıta yazdıktan sonra yeniden başlatırsınız. Flatcar'ın flatcar-install betiği bunu herhangi bir Linux üzerinden yapar; Fedora CoreOS ise aynı şekilde çalıştırabileceğiniz bir coreos-installer container'ı sunar. Her ikisi de SSH anahtarınızı içeren bir Ignition dosyasına ihtiyaç duyar, çünkü ilk açılışta parola girmenizi isteyen bir ekran yoktur. Konsol erişiminiz yoksa denemeyin: geri gelmeyen bir makinede inceleyebileceğiniz hiçbir şey kalmaz.

Değişmez bir sunucuya nasıl paket kurarım?

Paketi imaja ekler ve yeniden dağıtırsınız. bootc üzerinde bu, Containerfile içinde bir RUN dnf -y install ... satırı, ardından yeniden derleme, push işlemi ve makinede sudo bootc upgrade --apply komutudur. Fedora CoreOS üzerinde, paketi sudo rpm-ostree install ile katmanlayabilir ve yeniden başlatabilirsiniz; ancak bu durumda paket her güncellemede yeniden uygulanır. Flatcar ve Talos üzerinde paket yöneticisi yoktur, bu yüzden çözüm bir container kullanmaktır. bootc ana makinesinde tek seferlik bir hata ayıklama aracı için sudo bootc usr-overlay, bir sonraki yeniden başlatmada kaybolacak yazılabilir bir /usr sağlar.

İmaj modu, çekirdek güncellemesinden sonra açılmayan bir VPS'i düzeltir mi?

Kurtarma konsolu ile uğraşmak yerine sistemi yeniden başlatarak kurtarmanızı sağlar. Önceki imaj, çekirdek ve kullanıcı alanı (userspace) ile birlikte diskte durmaya devam eder; bu nedenle sudo bootc rollback veya sudo rpm-ostree rollback -r sizi eski sürüme döndürür. Talos ve Flatcar daha ileri giderek, yeni sürüm açılmadığında otomatik olarak geri dönüş yapar; çünkü bir önyükleme girdisi ancak başarılı bir açılıştan sonra varsayılan hale gelir. Bunların hiçbiri hatalı bir güncellemeyi engellemez. Sadece geri almayı kolaylaştırır.

Bir sunucu için hangi değişmez dağıtımı seçmeliyim?

Bir container imajı gibi oluşturduğunuz ve mevcut bir makineye kurabileceğiniz genel amaçlı bir Linux sunucusu istiyorsanız bootc seçin. Bu modeli hazır bir şekilde sunan ve kutudan çıktığı gibi otomatik güncellemeler yapan bir yapı istiyorsanız Fedora CoreOS seçin. A/B güncelleme şemasına sahip, paket yöneticisi bulunmayan ve container barındırmaya odaklı minimal bir sistem istiyorsanız Flatcar seçin. Talos'u ise yalnızca makine bir Kubernetes düğümü olacaksa seçin; çünkü Talos'ta kabuk (shell) yoktur ve başka hiçbir şey çalışmaz.