Bu rehber, Proxmox Otomasyon Serisi'nin üçüncü modülüdür.
Faz 2 saha oturumu, depolama mimarisinin canlı ortamda kanıtlanmasıyla noktalanmıştı: Terraform üzerinde seri numaralarıyla () tanımlanan dört disk, idempotent bir Ansible playbook aracılığıyla LVM ve XFS katmanlarından geçirilip altına bağlanmış, çalışan sanal makinede (VM) disk boyutu 20 GB'den 30 GB'ye kesintisiz büyütülmüş ve her iddianın arkasına somut terminal çıktıları konmuştu.
Bu sağlam bir zemin olsa da Faz 2 tamamlandığında arkasında henüz test edilmemiş iki büyük varsayım ve bir mimari açık bırakmıştı: Reboot Kalıcılık Testi: Dosya sistemlerinin reboot sonrasında geri geleceği varsayılıyordu. satırları yazılmış ve LVM'in açılışta volume group'ları otomatik etkinleştirmesi bekleniyordu; fakat birisi makineyi gerçekten yeniden başlatıp kontrol edene kadar bu bir kanıt değil, bir temenniden ibarettir. Üretim ortamlarındaki veritabanı sunucularında "makine reboot oldu ve veri diskleri geri gelmedi" durumu klasik bir kriz senaryosudur ve neredeyse her zaman tek satırlık bir hatadan kaynaklanır: 'da bir yazım yanlışı, aktivasyon kapsamı dışında kalan bir VG veya açılış sürecinin bağlamayı reddettiği bir dosya sistemi.
Yeni Disk İhtiyacı: Faz 2'deki büyüme senaryosu mevcut bir diski büyütmeyi kapsıyordu.
Oysa sahada depolama büyümesi sıklıkla ortama yeni bir diskin eklenmesi şeklinde gelir: yeni bir iş yükü için depolama ekibinden gelen taze bir LUN.
Yapılandırma Kayması Riski (Configuration Drift): Depolama düzeni playbook'unun içindeki bloğunda tanımlanmıştı.
Tek bir playbook varken bu durum sorunsuzdu; ancak aynı listeyi doğrulayacak ikinci bir playbook geldiği anda iki dosya arasında kopyala-yapıştır yapmak kaçınılmaz bir drift riskine davetiye çıkaracaktı.
Bu sağlamlaştırma adımı, çalışan parçaları bozmadan bu üç açığı kapatıyor: Disk düzeni tek gerçek kaynak (Single Source of Truth) olarak dosyasına taşınıyor.
Yeni yazılan playbook'u makineyi yeniden başlatarak reboot sonrası kalıcılığını doğrulama token'ları, güncel fact'ler ve assertion'lar ile kanıtlıyor.
Opsiyonel bir beşinci disk ise uçtan uca yeni disk ekleme iş akışını sınıyor.
Dosya Değişiklik Amaç Yeni Depolama düzenini tek bir liste olarak tanımlar: , , , .
Hem kurulum hem doğrulama playbook'ları buradan okur.
Güncellendi (v3) listesi 'a taşındı; dosya eksikse açık bir mesajla süreci durduran koruyucu eklendi.
Görevler v2 ile aynı kaldı.
Yeni (v1.1) Reboot sonrası kalıcılık doğrulaması: doğrulama token'ları, reboot, taze fact'ler, assertion'lar ve doğrulama logları. İlk saha testinde tespit edilen düzeltmesini içerir.
Güncellendi Yeni değişken: (varsayılan: =
- disk kapalı).
Güncellendi Değişken sıfırdan büyük olduğunda arayüzünde serial'li diski üreten dinamik blok ().
Güncellendi - diskin büyüme iş akışıyla birlikte belgelenen yeni parametresi.
Kapsam sınırları yine bilinçli olarak dar tutuldu: Kapsam Dahilinde Kapsam Dışında Kurulum ve doğrulama playbook'larının paylaştığı tek listesi Terraform state'ten beslenen dinamik envanter (Faz 4) Senaryolaştırılmış reboot ile boot kalıcılığının kanıtlanması Dosya sistemi kullanımının sürekli izlenmesi (Zabbix Faz 3'te geliyor) parametresiyle kontrol edilen opsiyonel beşinci disk Disk silme veya küçültme 02, 03 ve büyüme çalıştırmalarının gerçek saha logları (, , büyümede ) Rebootsuz hızlı test modunun logları ( belgelendi, henüz sahada loglanmadı) Depolama Düzeni İçin Tek Gerçek Kaynak Faz 2 playbook'u disk listesini play başındaki bir bloğunda tanımlamıştı. İkinci bir playbook aynı bilgiye ihtiyaç duyduğu anda sorun başlar: doğrulama playbook'unun da aynı serial'lere, aynı VG/LV adlarına ve aynı bağlama noktalarına ihtiyacı vardır; çünkü altyapıyı kanıtlamak, kurulum playbook'unun kurduğunu iddia ettiği şeyi birebir denetlemek demektir. İki dosyada tek bir listenin kopyasını tutmak drift'in doğduğu yerdir: beşinci bir disk eklersiniz, bir playbook'u günceller, diğerini unutursunuz ve doğrulama adımı fark ettirmeden o diski denetlemeyi bırakır. Çözüm standart Ansible yöntemidir: grup değişkenleri ().
Envanter zaten adında bir grup tanımlıyor; bu nedenle konumundaki bir dosya, hiçbir playbook kodu çalışmadan önce o gruptaki her host için otomatik olarak yüklenir. İki playbook da artık doğrudan değişkenini okur ve mimari bir garanti elde edilir: depoda tek bir liste vardır.
Bu dosyadaki yorum satırları SCSI arayüzünü ve değişkenini her serial'in yanında tutar; çünkü bu dosya Terraform tarafı ile Ansible tarafı arasındaki bir sözleşmedir. değişkeni de playbook'un derinliklerine gömülmek yerine buraya kondu; böylece operatör ayarları aradığı yerde bulur.
Listeyi playbook dışına taşımak dosya bulunamadığında ne olacağını değiştirir; bu yüzden her iki playbook da en başta bir koruyucu ile açılır.
Yanlış dizinden ya da bu grubu içermeyen bir envanterle çalıştırma durumunda süreç ortalarda tanımsız değişken hatasıyla patlamak yerine, henüz hiçbir şeye dokunmadan neden durduğunu açıkça bildirir: Ansible öncelik sıralaması (precedence) burada kritik bir tasarım kararı içerir: Öncelik (Düşükten Yükseğe) Bu Tasarımdaki Anlamı Tek gerçek kaynak; her iki playbook da olduğu gibi okur.
Playbook içindeki 'ı override eder; içinden özellikle kaldırıldı ki dosyadaki listeyle yarışamasın.
Komut satırındaki Her şeyi override eder; tek seferlik geçici denemeler için belgelenmiş kaçış kapısı ().
Reboot Testi: Faz 2 saha oturumu depolama katmanını bırakıldığı anki haliyle doğrulamıştı: bağlı, boyutlandırılmış ve üzerinden okunabilir durumda.
Ancak makinenin bir reboot sonrasında ayağa kalkıp kalkmayacağı test edilmemişti. girdileri yalnızca açılışta okunur.
Açılıştaki LVM aktivasyonu, kurulum playbook'unun tetiklediği açık çalıştırmadan tamamen farklı bir mekanizmadır.
Elle komutu çalıştırıldığı için ayakta duran bir dosya sistemi ile kalıcı olan bir dosya sistemi, ilk yeniden başlatmaya kadar birbirinden ayırt edilemez.
Doğrulama playbook'u, dikkatli bir sistem mühendisinin elle yapacağı adımları tekrarlanabilir çıktılara döker.
Reboot Öncesi Belirteçler (Token & Marker) Kalıcılığı dizin adıyla değil içerikle denetlemek gerekir; çünkü yeni formatlanmış boş bir disk de aynı mount point'e bağlanabilir ama içindeki veriyi kaybetmiştir.
Playbook, reboot öncesinde her dosya sistemine benzersiz bir token yazar: Token, her çalıştırmanın yalnızca kendi yazdığını doğrulaması için üretilir.
Sabit bir string'e karşı kontrol yapmak önceki çalıştırmadan kalan bayat bir dosyada bile geçer; oysa reboot'tan saniyeler önce üretilen bir token'ı aramak, okunan verinin tam o oturumda diske yazıldığını garantiler.
Dosya içeriği mount yolu ile token'ın birleşimidir; yani yanlışlıkla başka diske yazılan bir belirteç de doğrulamadan geçemez.
Reboot ve Fact Yenileme Mantığı Bu iki görevde iki hayati teknik detay bulunur: görevi gereksiz görünür ama zorunludur. play'in en başında tek bir kez çalışır; dolayısıyla reboot sonrasında listesi hâlâ makinenin açılış öncesi dünyasını tarif eder.
Reboot sonrası modülünü çağırmak, mount kontrollerinin güncel gerçeği okumasını sağlar.
Koşulda yer alan filtresi zorunludur.
Komut satırından ile geçilen değerler Ansible'a string olarak ulaşır.
Jinja motorunda string'i truthy (doğru kabul edilen) bir değerdir; bu filtre konmazsa parametresi verildiğinde playbook tam da reboot etmemesini istediğiniz anda makineyi yeniden başlatır.
LVM Kontrolü: Neden Karakterleri Değil?
LVM, volüm durumunu öznitelik dizgisinin - karakterinde kodlar ( = active).
Ancak pozisyona dayalı karakter okumak, araçlar raporlama düzenini değiştirdiğinde sessizce patlayan kırılgan bir yöntemdir.
Playbook bunun yerine komutundan JSON raporu alarak volüm sayısını doğrular, ardından sistemin doğrudan kendisine sorar: aktif bir mantıksal volüm aygıt düğümünü altında sunar, aktif olmayan bir volümün düğümü oluşmaz.
Bu yüzden her volüm için çalıştırmak hem daha sade hem daha güvenilir bir testtir. İlk saha oturumunun öğrettiği dersi tam buraya aittir. bir blok aygıtı değil, udev tarafından yönetilen bir sembolik bağdır ().