Bir web uygulamasını üretimde çalıştırmak, onu derlemeye başarmaktan çok daha fazlasıdır. Şifrelerin asla düz metin olarak diske dokunmaması, sadece çökmeleri değil kilitlenmeleri de tespit eden bir süreç denetçisi ve SSH ile umut gerektirmeyen bir güncelleme yolu demektir. Bu yazı, FFS'in Fedora CoreOS üzerine deploy edilmesini anlatıyor: neden CoreOS, deployment pipeline'ı nasıl çalışıyor ve bunun getirdiği ödünleşimler.
Neden Fedora CoreOS
CoreOS, tek bir iş için tasarlanmış bir işletim sistemidir: konteyner çalıştırmak. Geleneksel anlamda bir paket yöneticisi yoktur, elle derlenen araçlarla dolu bir /usr/local/bin yoktur, konfigürasyon sapması yoktur. Tüm sistem durumu, kurulum sırasında tek bir Ignition dosyasında tanımlanır. Bir düğüm çökerse, aynı dosyadan yeni bir tane provizyon edersiniz ve birebir aynı makineyi elde edersiniz.
Bu felsefe, FFS gibi bir platformla iyi uyuşur. Uygulama, kendi Wt çalışma zamanını, paylaşımlı kütüphanelerini ve derlenmiş bileşenlerini taşıyan bir konteyner imajı içinde çalışır. Sunucu çekirdeği, konteyner çalışma zamanını ve systemd'yi sağlar — başka bir şey değil.
Avantajlar:
Değişmez altyapı, "benim makinamda çalışıyor" sürprizlerini ortadan kaldırır. Aynı Ignition dosyasından provizyon edilen her CoreOS düğümü aynıdır: aynı güvenlik duvarı kuralları, aynı dizin yapısı, aynı systemd birimleri, aynı SSH anahtarları. Aylarca süren dnf install ve unutulmuş yapılandırma değişikliklerinden birikmiş bir durum yoktur.
Otomatik güncellemeler, operatör müdahalesi olmadan işletim sisteminin yamalı kalmasını sağlar. CoreOS bir A/B bölüm şeması kullanır — güncellemeyi pasif bölüme indirir, ona geçiş yapar ve önyükleme başarısız olursa otomatik olarak geri döner. Uygulama konteyneri kendi bağımlılıklarını taşıdığı için etkilenmez.
Minimal saldırı yüzeyi, salt okunur kök dosya sistemi ve paket yöneticisinin yokluğundan kaynaklanır. Derleyici yoktur, curl | bash riski yoktur, unutulmuş geliştirme başlık dosyaları yoktur. Yazılabilir olan tek yollar, açıkça mount edilmiş veri dizinleridir.
Ödünleşimler:
Bir CoreOS düğümünde hata ayıklamak, tam bir Linux iş istasyonundan daha zordur. gdb yoktur, strace yoktur (toolbox olmadan), vi dışında metin editörü yoktur. Gece saat 2'de bir şeyler ters gittiğinde, bir hata ayıklayıcı bağlamak yerine journalctl çıktılarını okuyup dikkatle düşünürsünüz.
Ignition tabanlı provizyon modeli, yapılandırma değişikliklerinin ya düğümün yeniden provizyon edilmesini ya da systemd birimlerinin manuel olarak düzenlenmesini gerektirdiği anlamına gelir — sunucu düzeyindeki değişiklikler için apt-get install veya dnf update yoktur. Bu bir hata değil, bir özelliktir, ancak disiplin gerektirir.
SELinux varsayılan olarak zorlayıcı moddadır. Konteyner volume mount'ları SELinux etiketleriyle etkileşir ve rootless Podman'ı bind-mount edilmiş sunucu dizinleriyle karıştırmak, çalışma zamanına kadar görünmeyen izin sorunları üretebilir. :Z volume bayrağı yeniden etiketlemeyi yönetir, ancak farklı UID ad alanlarına sahip konteynerler arasında dizin paylaştığınızda sizi şaşırtabilecek şekilde dosya sahipliğini değiştirir.
Deployment Pipeline
FFS'in CoreOS üzerine deployment'ı üç aşamalı bir pipeline izler: hazırlık, provizyon, deploy. Her aşamanın karmaşıklığı kapsülleyen özel bir betiği vardır.
Aşama 1 — Hazırlık (Geliştirici Makinası)
ffs-prepare.sh sunucuda değil, geliştiricinin iş istasyonunda çalışır. Proje yapılandırmasını okur, SSH anahtarlarını, SMTP kimlik bilgilerini ve TLS sertifika parolalarını toplar, ardından iki dosya üretir: bir Butane yapılandırması (ffs.bu) ve derlenmiş Ignition karşılığı (ffs.ign).
$ bash deploy/coreos/ffs-prepare.sh --project serbest --name www
Butane şablonu, projenin .env dosyasından ve etkileşimli istemlerden doldurulan yer tutucular (@PROJECT@, @INSTANCE_NAME@, @HTTPS_PORT@) kullanır. Sonuç, eksiksiz bir makine spesifikasyonudur: systemd birimleri, güvenlik duvarı kuralları, dizin izinleri, kullanıcı hesapları ve yetkilendirilmiş SSH anahtarları.
TLS sertifika parolası systemd-creds ile şifrelenir — diskte şifreli formda saklanır ve yalnızca servis başlangıcında geçici bir RAM destekli dizine çözülür.
Aşama 2 — Provizyon (CoreOS Kurulumu)
Üretilen ffs.ign, CoreOS yükleyicisine verilir. Bu, makine başına (veya yeniden provizyon başına) tek seferlik bir işlemdir:
$ coreos-installer install /dev/sda --ignition-file ffs.ign
Yeniden başlatmadan sonra makine her şeyi hazır olarak gelir: ffs sistem kullanıcısı, proje dizin ağacı, systemd servis birimleri ve güvenlik duvarı yapılandırması. İlk kurulum için SSH girişi gerekmez.
Aşama 3 — Deploy (İmaj Transferi)
ffs-deploy.sh konteyner imajını ve proje dosyalarını CoreOS düğümüne aktarır. İlk deploy'da ayrıca sunucu kurulum betiğini çalıştırır ve TLS kimlik bilgisini şifreler:
$ bash deploy/coreos/ffs-deploy.sh 192.168.1.10 \
--name www --user core --first-deploy
Sonraki güncellemeler daha basittir — sadece imaj ve değişen proje dosyaları:
$ bash deploy/coreos/ffs-deploy.sh 192.168.1.10 --name www
Deploy betiği, podman save / podman load ile imaj transferini, rsync ile proje dosyası senkronizasyonunu ve systemctl restart ile servis yeniden başlatmasını yönetir.
TLS Sertifika Yönetimi
FFS, şifreli TLS özel anahtarları kullanır. Özel anahtar, build sürecinde AES-256-CBC ile şifrelenir ve server.key.enc olarak saklanır. Konteyner başlangıcında giriş betiği onu /tmp/secrets/ dizinine çözer (tmpfs mount — yalnızca RAM, diske asla dokunmaz) ve CERT_PASS ortam değişkenini kullanır; bu değişken de bir systemd şifreli kimlik bilgisinden gelir.
Sertifika Rotasyonu
ffs-cert.sh sertifika yaşam döngüsü yönetimi sağlar:
# Mevcut sertifika durumunu görüntüle (yerel, sunucu, konteyner)
$ bash deploy/coreos/ffs-cert.sh status 192.168.1.10 --name www
# HTTPS sertifikasını yenile
$ bash deploy/coreos/ffs-cert.sh rotate-https 192.168.1.10 --name www
# SSH erişim anahtarlarını yenile
$ bash deploy/coreos/ffs-cert.sh rotate-ssh 192.168.1.10 --name www
status komutu sertifika son kullanma tarihlerini, parmak izlerini gösterir ve sertifikalar 30 gün içinde sona erecekse uyarır. rotate-https mevcut sertifikayı otomatik olarak yedekler, yenisini dağıtır, kimlik bilgisini yeniden şifreler ve servisi yeniden başlatır.
Süreç Denetimi ve Sağlık İzleme
İlk CoreOS deployment'larından öğrenilen en zor derslerden biri, çalışan bir sürecin mutlaka sağlıklı bir süreç olmadığını keşfetmekti. FFS başlangıçta basit bir fork tabanlı watchdog'a dayanıyordu: üst süreç alt süreci fork eder, bekler, çökmede yeniden başlatır. Bu, segfault'ları ve yakalanmamış istisnaları yakalar ancak kilitlenmeleri yakalamaz — bloke olmuş bir SMTP bağlantısı veya kilitlenmiş bir olay döngüsü, hiçbir şey sunamadan süreci canlı tutar.
Mevcut denetim mimarisi, pipe tabanlı sağlık sondaları kullanır:
üst süreç (denetçi)
└── alt süreç 0 ──pipe──→ üst süreç 'H' kalp atışlarını okur
└── alt süreç N ──pipe──→ (gelecek worker'lar)
Alt süreç her 10 saniyede bir pipe'a bir kalp atışı baytı yazar. Üst süreç tüm pipe'ları poll() ile izler — ardışık üç sonda aralığında kalp atışı gelmemesi alt sürecin kilitlendiği anlamına gelir ve üst süreç onu SIGTERM ile sonlandırır (SIGKILL öncesinde 5 saniyelik ek süre ile) ve yeniden başlatır.
systemd entegrasyonu için, tüm alt süreçler sağlıklı olduğunda üst süreç her sonda aralığında sd_notify("WATCHDOG=1") gönderir. Herhangi bir alt süreç sağlıksızsa, kalp atışı gönderilmez ve systemd'nin kendi WatchdogSec zamanlayıcısı sonunda tüm konteyneri sonlandırır — ikinci bir savunma hattı.
sd_notify uygulaması tamamen bağımsızdır: NOTIFY_SOCKET Unix datagram soketine doğrudan bir sendmsg() çağrısı, libsystemd bağımlılığı olmadan. Bu, konteyner imajını minimal tutar ve herhangi bir temel imajda çalışır.
Komut Satırı Bayrakları
./ffs --sd-notify # systemd entegrasyonu (CoreOS üretim)
./ffs --watchdog # bağımsız denetim (Docker, geliştirme konteynerleri)
./ffs # çıplak süreç (GDB, IDE, Valgrind)
Güncellemelerin Deploy Edilmesi
İlk deployment'tan sonra güncellemeler öngörülebilir bir iş akışı izler:
# 1. Yeni üretim imajını oluştur (geliştirme makinası, dev konteyner içinde)
ffscm rebuild production --project serbest --compiler intel
# 2. CoreOS düğümüne deploy et
bash deploy/coreos/ffs-deploy.sh 192.168.1.10 --name www
# 3. Doğrula
bash deploy/coreos/ffs-cert.sh status 192.168.1.10 --name www
Deploy betiği yalnızca değişen imaj katmanlarını ve proje dosyalarını aktarır. Servis otomatik olarak yeniden başlatılır. Yeni sürüm başlatamazsa (hızlı başarısızlık tespiti: 5 saniye içinde üç çökme), watchdog vazgeçer ve systemd'nin Restart=on-failure mekanizması artan bekleme süresiyle devreye girer.
Öğrenilen Dersler
systemd'nin WatchdogSec'i aktif katılım gerektirir. Kalp atışı göndermeden WatchdogSec=120s ayarlamak, systemd'nin servisi her iki dakikada bir sonlandırmasına neden olur. FFS bunu zor yoldan öğrendi — sunucu rastgele yeniden başlıyor gibi görünüyordu, ta ki yeniden başlatma aralığını watchdog zaman aşımıyla ilişkilendirene kadar.
Shell genişletmesi systemd'nin ExecStart'ında gerçekleşmez. Kimlik bilgisi kalıbı $(cat ${CREDENTIALS_DIRECTORY}/cert_pass) bir /bin/sh -c sarmalayıcı gerektirir. Bu olmadan, literal $(cat ...) dizesi konteynere iletilir ve TLS anahtar çözümlemesi sessizce başarısız olur.
Sırada Ne Var
Mevcut deployment modeli, tek düğümlü üretimi iyi yönetir. Gelecekteki iyileştirmeler arasında otomatik sertifika yenileme için Let's Encrypt entegrasyonu, çoklu worker desteği (N-alt süreç watchdog altyapısı zaten mevcut) ve güncellemenin başarılı ilan edilmesinden önce HTTPS uç noktasının doğru yanıt verdiğini doğrulayan bir deployment sağlık kontrolü yer alır.
CoreOS, FFS'in üretimde çalıştırılması için sağlam bir temel sunar. Değişmezlik garantileri, otomatik işletim sistemi güncellemeleri ve systemd entegrasyonu, operasyonel güvenilirliğe değer veren bir platform için doğal bir tercih yapar. Ödünleşim — daha az esneklik, daha dik hata ayıklama eğrisi — her deployment'ın tekrarlanabilir ve her yeniden başlatmanın denetimli olduğu güvencesi için buna değer.
