Sunucularda immutable Linux dağıtımı 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 dizinindeki dosyaların üzerine yazmak gibi bir işlem /usr 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şlemidir.

"Değişmez" ifadesi bu durumu olduğundan fazla iddialı gösterir. Fiziksel olarak root kullanıcısının diske yazmasını engelleyen bir durum 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 /etc içinde yer alır. /usr altındaki her şey imaja aittir; aynı imaj etiketini çalıştıran iki sunucunun özdeş 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 yapı (artifact) üretilmesi ve sunucunun tek görevinin işaret edilen bu yapıyı başlatmak olmasıdır. Aşağıdaki her şey bu temel farktan kaynaklanmaktadır.

Neden salt okunur bir sistem sunucuda 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, sunucuların neden genellikle farklı davrandığının sebebi budur. Notlar niyeti tutar. Disk ise gerçeği tutar.

İ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 durum, 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 burada dosya sistemi tarafından ele alınır.

Rollback, yeniden başlatmadır; açıklamanın tamamı budur

Bu modelin hedeflediği hata, zaten belgelediğimiz hatadır: kernel güncellemesinden sonra boot etmeyen bir VPS. Paket modunda sağlayıcının rescue console özelliğinden kurtarma yapılır. Disk mount edilir, chroot ile sisteme girilir ve bir kernel paketi elle kaldırılır. Bu yöntem çalışır; çünkü bootloader eski kernel'ları korur. Ancak bu şekilde yalnızca kernel sürümlenir. Aynı işlemde gelen glibc güncellemesi ve systemd değişiklikleri zaten uygulanmıştır. Bunları birlikte geri alan tek bir komut yoktur.

Image modunda birim, sistemin tamamıdır. Bir bootc host üzerinde:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback bootloader sıralamasını önceki boot girdisine geri döndürür. Bu girdi, bir saat önce çalıştırılan image'dır; kernel ve userspace birlikte geri alınır. Eski image diskten hiç silinmediği için hiçbir şey indirilmez ve yeniden oluşturulmaz. İleride açıklanan automatic update timer etkinleştirildiyse önce durdurulmalıdır. bootc belgeleri, otomatik yükseltme yapan bir agent'ın rollback işlemini geri alabileceği konusunda uyarır.

Fedora CoreOS aynı işlemi farklı adlarla yapar:

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

Önce Zincati durdurulmalıdır. Zincati, Fedora CoreOS makinesini en yeni release üzerinde tutan agent'tır. Az önce geri alınan deployment'ı yeniden kurmaz. Ancak güncellemeleri aramayı sürdürür ve görünen daha yeni bir sürüme yükseltme yapar. Makinenin bir düzeltme release edilene kadar mevcut durumda kalması isteniyorsa sudo systemctl disable --now zincati.service çalıştırılmalıdır. -r rollback hazırlığa alındıktan sonra yeniden başlatma yapar. Güvenilen bir deployment'ın garbage collection ile silinmesini önlemek için:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status deployment'ları bootloader'ın sunacağı sırayla listeler. Çalışan deployment'ı nokta ile işaretler ve sabitlediğiniz deployment üzerinde Pinned: yes gösterir.

Talos bunu workstation'dan yapılan tek bir API çağrısıyla gerçekleştirir:

talosctl rollback --nodes 10.20.30.40

Flatcar iki /usr partition tutar ve bunlar arasında geçiş yapar. Her slot, partition table içinde bir öncelik ve deneme sayacı taşır. Başarıyla boot etmeyen bir slotun deneme hakkı tükenir ve bootloader diğer slotu seçer. Hangi slotta olduğunuzu ve slotun good olarak işaretlenip işaretlenmediğini kontrol etmek için:

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

Sağlıklı ve çalışan bir slot, tries=0 successful=1 içeren bir satır yazdırır. Aynı satırdaki priority numarası yalnızca bootloader'ın tercih ettiği slotu sıralar. Bu nedenle tamamen sağlıklı bir makinede 1 veya 2 değerini alabilir. Eşleşen satır yoksa mevcut slot hiçbir zaman doğrulanmamıştır. Makine, bir güncelleme ile ilk sorunsuz boot arasındaki sürede bu durumda bulunur.

"Paket kurma" işleminin yerini ne alı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 oluşturun 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 şu komutu çalıştırın:

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

bootc upgrade, imaj kaynağını sorgular ve yeni imajı bir sonraki açılış için kuyruğa alır. --check, bir güncellemenin mevcut olup olmadığını bildirir ve hiçbir şeyi değiştirmez. --apply, sistemi yeniden başlatarak yeni imaja geçer. bootc switch registry.example.com/edge/web:next, /etc ve /var dizinlerini koruyarak makineyi farklı bir imaja yönlendirir; bu, bir sunucuyu yeniden kurmadan imaj akışları arasında taşımanın yoludur.

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 sonuçta oluşan set her makinede biraz farklıdır. İmaj tabanlı bir zamanlayıcı ise başka bir yerde zaten test edip başlattığı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. /etc ise güncelleme sırasında üç yönlü birleştirilir (three-way merge); bu, hiç dokunmadığınız bir dosyanın imajdaki yeni sürümü 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 silinecek geçici ve yazılabilir bir katman ekler. Bu işlem sorunu incelemek içindir, kalıcı olarak 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ı hazırlar, bunu Ignition JSON formatına dönüştürür ve ilk önyükleme sırasında makineye verirsiniz:

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 çok hata yaptığı nokta burasıdır. Yapılandırma dosyası bir SSH anahtarı içermiyorsa, makineye erişim imkanı olmadan açılır 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. Her pencere, başlık olarak çift köşeli parantez içinde updates.periodic.window ismiyle başlar ve ardından üç anahtar gelir:

• days, "Sat" ve "Sun" gibi gün isimlerinden oluşan bir liste.
• 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ğunu tamamen üstlendiğinizi kabul edin.

Paket katmanlama (package layering), bir kaçış noktası 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şlatma sonrasında etkinleşir. Bunun maliyeti ise daha sonra ortaya çıkar. Katmanlı setiniz 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 konteynerleri, 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şvurulacak 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 A/B /usr bölümü üzerinden, 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 tuttuğunu ve sadece 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 belirtilmedikçe tek bir üretim VPS'i kendi zamanlamasına göre yeniden başlatılı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 kullanımı, 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: shell yok, SSH yok, konsol yok

Talos, bu dört seçenek içinde en dar kapsamlı olanıdır ve amacını en açık biçimde ortaya koyar. Kubernetes node'larını çalıştırır. SSH daemon'u, login shell'i ve konsol üzerinden login işlemi yoktur. Fiziksel konsolda login istemi yerine makinenin durumunu incelemeye yarayan bir dashboard görüntülenir. Tüm işlemler, workstation'ınızdan talosctl kullanılarak, git'te tuttuğunuz bir machine config'e karşı yapılan gRPC API çağrılarıyla gerçekleştirilir.

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

Talos 1.14 sürümünden beri ghcr.io/siderolabs/installer image'ı yayımlanmamaktadır; installer image'ları bunun yerine Image Factory'den alınır. Bu path'teki uzun ID, özelleştirme içermeyen bir makineye ait boş schematic'tir. Node'unuzun kurulumunda kullanılan schematic'i kullanın; böylece system extension'ları da korunur ve tag'i geçiş yapacağınız release ile değiştirin. Upgrade işlemi, önceki kernel ve OS image'ını koruyan bir A-B düzeni kullanır. Yeni image boot edemezse Talos herhangi bir müdahale gerektirmeden kendi kendine rollback yapar. Login shell bulunmadığı için debugging işlemi farklıdır: makinede journalctl yerine talosctl logs ve talosctl dmesg kullanılır. Node üzerinde araçlara ihtiyaç duyulduğunda talosctl debug, sağladığınız bir image'dan privileged bir container başlatır ve sizi bu container'ın shell'ine bırakır. Container, çıkış yaptığınızda kaldırılır.

Workload'unuz Kubernetes değilse Talos doğru seçenek değildir. Kubernetes kullanıyorsanız Talos, "birisi node'a login oldu ve bir şeyi değiştirdi" türündeki olayların yaşanabileceği bir ortam bırakmadığı için tüm bir incident kategorisini ortadan kaldırır.

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şlatmada 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üncellemeyi gerektirir. Hat mevcut olduğunda bu işlem ucuzdur. Ancak hat kurulmadığında bu ciddi bir iştir ve sunucuların erişebileceği bir kayıt defteri gerektirir; 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 çekirdek üzerinde 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 çekirdeğine uygun şekilde imajın içine 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 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 sunucu filosu, yapılandırması bozulan 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.

Bunlardan birini kiraladığınız VPS üzerine kurma

Önce sağlayıcınızla ilgili iki noktayı doğrulayın: VNC veya seri konsol anlamına gelen out-of-band konsol erişiminiz olmalı ve rescue system ile boot edebilmelisiniz. Konsol yoksa geri gelmeyen bir makine, beş dakikada çözülebilecek bir sorun yerine destek talebine dönüşür.

Sağlayıcı özel image kabul ediyorsa vendor tarafından sağlanan raw veya qcow2 image dosyasını yükleyin. Ancak yalnızca yükleme yapmak, giriş yapabileceğiniz bir makine oluşturmaz. Fedora CoreOS içindeki core kullanıcısının varsayılan bir parolası veya SSH key'i yoktur. Bu nedenle key'inizi içeren bir Ignition config sağlamanız gerekir. Afterburn destekleyen bir cloud platformunda ise key'i sağlayıcının kendi SSH key özelliğiyle de tanımlayabilirsiniz. Aksi durumda diski rescue system üzerinden kendiniz yazmanız gerekir. Flatcar bunun için doğrudan bu amaçla kullanılabilen, kendi içinde gerekli bileşenleri barındıran bir script sağlar ve bu script herhangi bir Linux sisteminden çalıştırılabilir:

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

Bu komutu değiştirdiğiniz sunucuda değil, rescue system üzerinden çalıştırın. Çünkü script çalışırken hedef cihazın partition yapısını yeniden oluşturur. Cihazda en az 8 GB kullanılabilir alan bulunmalıdır. Ayrıca rescue environment içinde bash, bzip2 veya lbzip2, lsblk, wget, udevadm, gpg ve gawk bulunmalıdır. ignition.json bir SSH key içermelidir. Aksi halde kurulan sisteme giriş yapılamaz.

Fedora CoreOS da aynı yöntemi kullanır ve installer 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

Komutu çalıştırmadan önce cihaz adını lsblk ile kontrol edin. Yanlış cihaza yazmak, o cihazdaki tüm verileri yok eder. Komut herhangi bir onay istemi göstermez.

bootc, rescue mode kullanımını atlayan tek seçeneği 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

Komutu çalıştırmadan önce kullandığınız base image için sağlanan dokümantasyonu okuyun. Ayrıca işlemi, silinmesi sorun olmayacak bir sunucuda deneyin. Yeniden başlatmadan sonra makine image ile çalışır ve daha önce sahip olduğunuz package set artık mevcut olmaz.

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

Sunucularınız "sığır" (cattle) mantığıyla yönetiliyorsa bu yöntemi tercih edin. Tek bir tariften üretilen çok sayıda makine. Bir saat yaşayan CI (sürekli entegrasyon) çalıştırıcıları. Onarılmak yerine yenisiyle değiştirilen k3s veya Kubernetes düğümleri. Bozuk bir kutu için çözümün "sil ve yenisini oluştur" olduğu her durum. Ayrıca bir denetçiye makinede neyin çalıştığını kanıtlamanız gerektiğinde de avantaj sağlar; çünkü cevap bir paket listesi değil, bir imaj özetidir (image digest).

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 etmeyin. İmaj modu iş yükünü ortadan kaldırmaz. İşi sunucudan alıp derleme sürecine taşır ve bu taşıma için sizden bir kayıt defteri (registry) ve bir hat (pipeline) kullanmanızı ister. Bu işi yapacak bir yeriniz varsa, birbirinin aynısı sunuculara ve yeniden başlatma kadar kolay bir geri alma (rollback) sürecine sahip olursunuz. Eğer yoksa, zaten sorunsuz çalışan bir kutuya hareketli parçalar eklemiş ve gece saat 02:00'deki müdahaleleri zorlaştırmış olursunuz.

Sıkıcı orta yol hala geçerlidir: otomatik güvenlik güncellemelerine sahip standart bir dağıtım ve bizzat pratik ettiğiniz bir yeniden kurulum süreci. Bu temeli 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ştirilemez bir Linux dağıtımı gerçekten değiştirilemez mi?

Hayır; adlandırma kafa karışıklığına neden olur. root hesabı diske yazmaya devam edebilir. Gerçekte /usr çalışma zamanında salt okunur olarak bağlanır ve bir sonraki image ile bütünüyle değiştirilir; /etc ve /var ise yazılabilir durumda kalır ve güncellemeler arasında korunur. /usr altında yapılan değişiklikler ya o anda reddedilir ya da bir sonraki güncellemede silinir. Bu nedenle pratikte sistem dizinleri yalnızca image değiştiğinde değişir.

Fedora CoreOS veya Flatcar, bunları sunmayan bir VPS üzerinde çalıştırılabilir mi?

Genellikle evet; sağlayıcı bir rescue system ve console access sunuyorsa çalıştırılabilir. Önce rescue system başlatılır, dağıtımın disk image'ı block device üzerine yazılır ve ardından yeniden başlatılır. Flatcar'ın flatcar-install script'i bu işlemi herhangi bir Linux sisteminden yapar. Fedora CoreOS ise aynı şekilde çalıştırılabilen bir container olarak coreos-installer bileşenini sunar. Her ikisi de SSH key içeren bir Ignition file gerektirir. Bunun nedeni, kullanılabilecek bir first-boot password prompt bulunmamasıdır. Console access yoksa bu işlem denenmemelidir. Yeniden başlatılamayan bir makinede incelenecek bir arayüz kalmaz.

Değiştirilemez bir sunucuya paket nasıl kurulur?

Paket image'a eklenir ve yeniden dağıtım yapılır. bootc üzerinde Containerfile içine RUN dnf -y install ... satırı eklenir, ardından rebuild ve push yapılır, makinede ise sudo bootc upgrade --apply çalıştırılır. Fedora CoreOS üzerinde paket sudo rpm-ostree install ile katman olarak eklenebilir. Bunun karşılığında paket, sonraki her güncellemede yeniden uygulanır. Flatcar ve Talos üzerinde package manager bulunmaz; bu nedenle çözüm bir container kullanmaktır. bootc ana bilgisayarında tek seferlik bir hata ayıklama aracı için sudo bootc usr-overlay, bir sonraki reboot işleminde ortadan kalkan yazılabilir bir /usr sağlar.

Image mode, kernel güncellemesinden sonra açılmayan bir VPS sorununu düzeltir mi?

Kurtarma işlemini rescue-console çalışmasından bir reboot işlemine dönüştürür. Önceki image, kernel ve userspace birlikte hâlâ diskte bulunur. Bu nedenle sudo bootc rollback veya sudo rpm-ostree rollback -r kullanılarak önceki image'a dönülebilir. Talos ve Flatcar bir adım daha ileri gider. Yeni slot boot edemezse kullanıcıdan işlem beklemeden rollback yaparlar. Bunun nedeni, bir boot entry'nin ancak bir başarılı boot işleminden sonra varsayılan hale gelmesidir. Bunların hiçbiri hatalı bir güncellemeyi engellemez. Ancak tek bir güncellemeyi geri almayı kolaylaştırır.

Bir sunucu için hangi değiştirilemez dağıtım seçilmelidir?

Genel amaçlı bir Linux sunucusu isteniyorsa bootc seçilmelidir. Bu modelde sunucu bir container image gibi oluşturulur ve mevcut bir makineye kurulabilir. Oluşturma işleminin kullanıcı adına yapılması ve automatic updates özelliğinin hazır gelmesi isteniyorsa Fedora CoreOS seçilmelidir. A/B update scheme kullanan, minimal bir container host ve başvurulabilecek bir package manager istemeyenler Flatcar seçmelidir. Talos yalnızca makine bir Kubernetes node olduğunda seçilmelidir. Çünkü Talos üzerinde login shell bulunmaz ve başka bir işlem çalıştırılmaz.