Sunucunuz çalışıyor, her şey yolunda. Sonra bir gün taşınmanız gerekiyor — ve uygulamanın yıllar içinde o makineye ne kadar kök saldığını fark ediyorsunuz.
Bu yazı, uygulamanızı tek bir sunucuya bağımlı olmaktan çıkarmayı ele alıyor.
Bağımlılık Belirtileri
Uygulamanız şu durumlardaysa taşınması zordur:
- Kurulum adımları belgelenmemiştir. Nasıl kurulduğu hatırlanmıyor.
- Elle yapılmış ayarlar vardır. Kaynağı bilinmeyen düzeltmeler.
- Mutlak yollar koda gömülüdür. Dizin yapısı değişemez.
- Sunucuya özel değerler koddadır. IP, ad, port.
- Bağımlılık sürümleri sabitlenmemiştir. Yeni kurulumda farklı sürüm gelir.
Beşinci madde en sinsi olanıdır: yeni sunucuda kurulum yaptığınızda gelen sürümler eskisinden farklıdır ve uygulamanız beklenmedik şekilde davranır.
Bu sorun taşınma anında ortaya çıkar ve teşhisi zordur, çünkü kod değişmemiştir — değişen, altındaki bağımlılıklardır.
Neyin Nerede Durması Gerekir
Taşınabilirliğin temeli, doğru ayrımdır:
| Öğe | Nerede durmalı |
|---|---|
| Uygulama kodu | Sürüm kontrolünde |
| Bağımlılık listesi | Sürüm kontrolünde, sürümler sabit |
| Ortama özel ayarlar | Ortam değişkenlerinde |
| Sırlar ve anahtarlar | Ayrı, koda girmeden |
| Kullanıcı dosyaları | Ayrı bir depolama katmanında |
| Sunucu yapılandırması | Kod olarak, sürüm kontrolünde |
Üçüncü satır en önemli ilkedir: aynı kod, farklı ortam değişkenleriyle hem test hem üretim ortamında çalışabilmelidir.
Kod içinde "eğer sunucu adı şu ise" tipi koşullar varsa, taşınabilirlik daha baştan kaybedilmiştir.
Yapılandırmayı Dışarı Almak
Pratik adımlar:
- Koddaki sabit değerleri bulun. Veritabanı adresi, dosya yolu, dış servis adresleri.
- Bunları ortam değişkenlerine taşıyın.
- Örnek bir yapılandırma dosyası hazırlayın. Gerçek değerler olmadan.
- Eksik değişken varsa uygulama açıkça hata versin.
- Gerçek değerleri sürüm kontrolüne koymayın.
Dördüncü madde önemli bir güvenlik ve teşhis kazancı sağlar: eksik yapılandırmada sessizce varsayılan değere düşen bir uygulama, yanlış veritabanına bağlanabilir.
Açıkça hata vermek, sorunu ilk saniyede görünür kılar — sessizce yanlış çalışmaktan çok daha iyidir.
Veri Katmanını Ayırmak
Kod taşınabilir olsa bile veri yerinde kalır. Bunun için:
- Kullanıcı dosyalarını uygulama dizininin dışında tutun.
- Veritabanı bağlantısını yapılandırmadan alın. Yerelde olması zorunlu olmasın.
- Oturum verisini dosya yerine paylaşılan bir depoda tutun.
- Önbelleği yeniden üretilebilir kabul edin. Taşınması gerekmesin.
Üçüncü madde ileride ikinci bir sunucu ekleme ihtimalini açık tutar: oturum verisi diskte duruyorsa, ikinci sunucu eklediğiniz anda kullanıcılar rastgele çıkış yapmaya başlar.
Dördüncü madde ise taşınmayı basitleştirir. Önbellek yeniden üretilebilir olduğu sürece taşınmasına gerek yoktur — yeni sunucuda sıfırdan oluşur.
Kurulumu Tekrarlanabilir Kılmak
Taşınabilirliğin en somut testi şudur: boş bir sunucudan çalışan bir sisteme kaç adımda ulaşıyorsunuz?
Cevabı iyileştirmek için:
- Kurulum adımlarını bir betikte toplayın
- Betiği yeni bir sunucuda test edin
- Eksik çıkan her adımı betiğe ekleyin
- Tekrar test edin
- Betik sıfırdan çalışana kadar döngüyü sürdürün
İkinci ve üçüncü adımlar arasındaki döngü, belgelenmemiş adımları ortaya çıkarmanın tek güvenilir yoludur. Yıllar önce elle yapılmış bir ayar ancak böyle görünür hâle gelir.
Bu çalışmayı yapmak için tek seferlik bir test sunucusu kullanabilirsiniz — VDS sunucu seçenekleri arasında kısa süreli, düşük maliyetli bir kurulum bu doğrulama için yeterlidir.
Konteyner Yaklaşımı
Taşınabilirliği yapısal olarak zorlayan bir yöntemdir:
| Kazanç | Maliyet |
|---|---|
| Bağımlılıklar tanımlıdır | Öğrenme eğrisi |
| Kurulum tekrarlanabilir | Ek katman yönetimi |
| Ortamlar aynıdır | Kalıcı veri ayrı düşünülmeli |
| Sürüm geçişi kolaydır | İmaj boyutu ve depolama |
Konteyner zorunlu değildir — aynı disiplini betiklerle de kurabilirsiniz. Ancak konteyner, taşınabilirliği bir tercih olmaktan çıkarıp zorunluluk hâline getirir, çünkü tanımlanmamış hiçbir bağımlılık çalışmaz.
Taşınabilirlik Testi
Yılda bir yapılması önerilen bir tatbikat:
- Yeni bir sunucu açın.
- Yalnızca belgelere ve betiklere bakarak kurun.
- Mevcut sunucuya bakmadan ilerleyin.
- Takıldığınız her noktayı not edin.
- Notları belgelere ve betiklere işleyin.
Üçüncü madde kuralın özüdür: mevcut sunucuya bakarak yapılan bir kurulum, taşınabilirliği test etmez — yalnızca kopyalar. Asıl soru, o sunucu erişilemez olsaydı sistemi kurabilir miydiniz sorusudur.
Sonuç
Taşınabilirliğin tek gerçek testi şudur: boş bir sunucudan çalışan bir sisteme, mevcut sunucuya hiç bakmadan ulaşabiliyor musunuz? Bunu sağlamak için aynı kod farklı ortam değişkenleriyle her ortamda çalışabilmeli, eksik yapılandırmada sessizce varsayılana düşmek yerine açıkça hata vermelidir. Bağımlılık sürümlerini sabitleyin — taşınmada değişen genellikle kod değil, altındaki sürümlerdir. Ve oturum verisini diskten çıkarın; ikinci bir sunucu eklediğiniz anda kullanıcılar rastgele çıkış yapmaya başlar.
Sıkça Sorulan Sorular (SSS)
Nereden başlamalıyım?
Koddaki sabit değerleri bulup ortam değişkenlerine taşıyarak. Veritabanı adresi, dosya yolları, dış servis adresleri ve anahtarlar koda gömülü olmamalıdır. Ardından kurulum adımlarını bir betikte toplayın ve boş bir sunucuda test edin.
Konteyner kullanmak zorunda mıyım?
Zorunda değilsiniz — aynı disiplini betiklerle de kurabilirsiniz. Konteynerin farkı, taşınabilirliği bir tercih olmaktan çıkarıp zorunluluk hâline getirmesidir: tanımlanmamış hiçbir bağımlılık çalışmaz, bu yüzden eksikler hemen görünür.
Kullanıcı dosyalarını nasıl yönetmeliyim?
Uygulama dizininin dışında, ayrı bir depolama katmanında tutun. Böylece kod güncellemeleri ve taşımalar veriyi etkilemez. Önbelleği ise yeniden üretilebilir kabul edin — taşınması gerekmez, yeni sunucuda sıfırdan oluşur.
Ne sıklıkla test etmeliyim?
Yılda bir kez yeterli. Yeni bir sunucu açın ve yalnızca belgelerinize bakarak kurmayı deneyin — mevcut sunucuya bakmadan. Takıldığınız her nokta, belgelerinizdeki bir eksiktir ve gerçek bir taşınma anında sizi bekliyor demektir.
