Kendin barındırma (self-hosting) dünyasında en tehlikeli hatalar, hata mesajı verenler değil, 'her şey yolunda' diyerek sizi yanıltanlardır. Bir sayfanın 200 OK döndürmesi, Docker konteynerinin sağlıklı görünmesi, yedeklemenin sorunsuz tamamlanması... Bunların hepsi yalan söylüyor olabilir. Üç yıllık self-hosting deneyimimde en çok zamanımı alan başarısızlıklar, hata vermeyenler oldu. İşte aynı makinede (2016 model bir masaüstü, i7-6700/32 GB RAM, Caddy arkasında Docker, yalnızca Tailscale üzerinden erişilebilir) karşılaştığım dört sessiz katil.
1. 200 Döndüren Yükleme Sayfası: Bu hata hakkında hiçbir yazı bulamadım, bu yüzden en çok vaktimi aldı. Sessiz bir kutu için ağır hizmetleri isteğe bağlı çalıştırıyorum: Sablier, boş konteynerleri durduruyor ve ilk istekte başlatıyor. Caddy (Sablier eklentisi ile) bir sanal sunucuyu bir konteyner grubunun arkasına alıyor ve grup başlatılırken 'lütfen bekleyin, başlatılıyor' sayfası gösteriyor. Nextcloud vhost'unu, WebDAV dahil, bu şekilde koruyorum. Sessiz hata şu: eğer gruptaki konteyner sağlıklı değilse, Sablier her istekte bu HTML yükleme sayfasını 200 OK ile döndürüyor. WebDAV istemcisi bir dizin listesi isterken XML yerine HTML alıyor ve senkronizasyon 'no root multistatus found' hatasıyla ölüyor. Nextcloud'un kendisi sağlıklıydı ama önündeki geçit 200 döndürdüğü için her şey yeşil görünüyordu. Ders: Bir hizmeti isteğe bağlı bir reverse proxy arkasına koyduğunuzda, o geçidin sağlığı hizmetin sağlığıdır ve geçit yanlış gövdeyle başarı döndürerek başarısız olur.
2. Yalan Söyleyen Sağlık Kontrolü: Yukarıdaki grup sağlıksız kaldı çünkü Docker, Collabora'yı sağlıksız işaretlemişti. Collabora'nın belgelenen sağlık kontrolü, keşif uç noktasını curl ile yokluyordu. 25.04 sürümünden itibaren imajdan curl kaldırıldı (image küçültmek için). Sağlık kontrolü curl'in eksik olduğundan şikayet etmez, sadece her aralıkta sıfır olmayan bir çıkış koduyla biter. Böylece tüm gerçek isteklere doğru yanıt veren bir konteyner, hiçbir şeyi test etmeyen bir kontrol yüzünden 'sağlıksız' işaretlenir. Sablier bu işarete güvenir, grubu 'başlatılıyor' durumunda tutar ve hata 1 gerisini halleder. Aynı sorun Ollama, litellm ve diğer minimal imajlarda da var. Çözüm: İmajın içermeyebileceği hiçbir şeye bağımlı olmayın. /dev/tcp, harici bir ikili dosya gerektirmeyen bir bash yerleşiğidir. Socket açılır, hizmet dinliyorsa sağlık kontrolü dürüst olur.
Detaylar ve Etkileri
3. Boş Yedek: Yedekleme işim, her veritabanını döküp rclone ile şifrelenmiş bir uzak sunucuya senkronize etmekti. Dökümler 0 çıkış koduyla bitiyor, dosyalar var, senkronizasyon başarılı rapor ediyor. Ancak ikisi bir süre boştu fark etmeden önce. MariaDB iki kez yalan söyledi: Bir MariaDB konteyneri, bağlantıları kabul etmeden birkaç saniye önce 'başladı' raporu verir. Duran bir DB'yi başlatıp hemen döken bir script, kesik veya boş bir .sql dosyası alır. Çözüm: Dökmeden önce yoklayın. SQLite (Vaultwarden) farklı başarısız oldu: Hacimdeki DB dosyası root'a ait, bu yüzden host kullanıcısı .backup çalıştıramaz. Çözüm: sqlite3 içeren geçici bir konteyner kullanın. Ve .backup kullanın, cp değil: uygulama yazarken bile tutarlı bir anlık görüntü verir. Kural: Hiç geri yüklemediğiniz bir yedek, sadece bir söylentidir.
4. Kaybolan Paket: Sessiz bir kutu çoğu zaman uykuda olduğu için, makineleri uzaktan uyandırmak için Wake-on-LAN'a güveniyorum. İlk denemem: sihirli paketi hedefin Tailscale IP'sine göndermek. Çalıştı, hiçbir hata yazdırmadı ve hiçbir şey olmadı. Sebep, WoL'nin asla uyarmadığı bir katman karışıklığı: uyuyan bir makinede işletim sistemi çalışmaz, dolayısıyla IP yığını veya Tailscale yoktur. WoL yalnızca yerel L2 segmentinde bir yayın olarak çalışır, ağ kartı tarafından donanımda yakalanır. L3 adresine gönderilen bir paket, uyuyan bir makineye asla ulaşmaz. Çözüm: Sihirli paketi, hedefin MAC adresine yerel ağın yayın adresine gönderin. Tailscale üzerinden WoL, özel bir yayın mekanizması veya bir uyandırma vekili gerektirir.
Önemli Gelişmeler
Bu dört hata ortak bir deseni paylaşıyor: hepsi size 'başarılı' sinyali verirken aslında başarısız oluyorlar. Çözümler basit ama püf noktası, bu hataların var olduğunu bilmek. Sağlık kontrollerinizi test edin, yedeklerinizi geri yükleyin, ağ katmanlarını anlayın ve reverse proxy'nizin arkasındaki hizmetlerin gerçek durumunu izleyin. Unutmayın: yeşil olan her şey yalan söylüyor olabilir.
Kaynak: dev.to
