Sunucu taşıması öncesinde hangi bağımlılıklar çıkarılmalıdır?

Sunucu taşıması öncesinde hangi bağımlılıklar çıkarılmalıdır?​

Sunucu taşımasından önce yalnızca dosyaları ve veritabanını değil, uygulamanın çalışması için ihtiyaç duyduğu bağlantıları, servisleri, kimlik bilgilerini, zamanlanmış işleri ve ağ izinlerini çıkarmalısınız. Yöntem; mevcut sunucuyu inceleyerek bir bağımlılık envanteri oluşturmak, her bağımlılık için yeni sunucudaki karşılığını belirlemek ve taşıma öncesinde doğrulama testi yapmaktır.

Bağımlılık envanterinde neler bulunmalı?​

Uygulamanın çalışma zincirini şu başlıklara ayırın:

• Uygulama dosyaları, yükleme dizinleri, kullanıcı tarafından oluşturulan medya ve sunucu dışında tutulan depolama alanları.
• Veritabanı türü, sürümü, bağlantı adresi, kullanıcı hesabı, karakter seti ve veritabanına erişen diğer uygulamalar.
• Ortam değişkenleri ve yapılandırma dosyaları: veritabanı bilgileri, uygulama anahtarları, ödeme veya e-posta servis ayarları.
• Web sunucusu, ters vekil, PHP veya başka çalışma zamanı sürümü, gerekli eklentiler ve işletim sistemi paketleri.
• DNS kayıtları, TLS sertifikaları, alt alan adları, yönlendirmeler ve dışarıdan gelen webhook adresleri.
• Cron görevleri, kuyruk işçileri, arka plan servisleri, systemd birimleri ve otomatik dağıtım görevleri.
• SMTP, ödeme, harita, kimlik doğrulama, dosya depolama, CDN ve izleme servisleri gibi dış API'ler.
• Güvenlik duvarı kuralları, IP izin listeleri, VPN bağlantıları, SSH erişimi ve dış servislerde kayıtlı sunucu IP'leri.

Envanteri kod, çalışan süreçler, DNS ve servis panelleriyle çapraz kontrol edin.

Somut örnek: küçük bir web uygulaması​

Örneğin example.com üzerinde çalışan bir uygulama; Nginx, PHP, MariaDB, yükleme dizini, günlük yedekleme cron'u, SMTP servisi ve ödeme sağlayıcısından gelen webhook'a bağlı olsun. Taşıma planı yalnızca web dosyaları ile MariaDB'yi kopyalarsa uygulama açılabilir; ancak e-posta gönderimi, ödeme bildirimleri veya gece yedekleri çalışmayabilir.

Bu örnekte yeni sunucuda web sunucusu ve çalışma zamanı hazırlanmalı, veritabanı aktarılmalı, yükleme dizini eşitlenmeli, SMTP kimlik bilgileri ve ödeme webhook'u kontrol edilmeli, cron yeniden oluşturulmalı ve ödeme servisi kaynak IP kısıtlaması kullanıyorsa yeni çıkış IP'si ilgili izin listesinde tanımlanmalıdır. Her adımın yanında sorumlu kişi, hedef değer, doğrulama yöntemi ve geri dönüş planı bulunmalıdır.

Bağımlılığı karara dönüştürme​

Envanteri aşağıdaki gibi sınıflandırmak, taşıma sırasında ne yapılacağını netleştirir:


Her kalemde hedef ortam hazırlığını, test sonucunu ve geri dönüş koşulunu işaretleyin.

Uygulanabilir çıkarma ve doğrulama adımları​

1. Mevcut sunucunun uygulama dizinlerini, yapılandırma dosyalarını, çalışan servislerini ve zamanlanmış görevlerini listeleyin. Gizli değerleri envantere düz metin olarak kopyalamak yerine yalnızca değişken adını ve nereden alınacağını kaydedin.
2. Kod deposu, dağıtım betikleri ve yapılandırma dosyalarında veritabanı adresi, sabit IP, alt alan adı, SMTP, webhook ve dış API araması yapın. Bulunan her değerin yeni ortamda değişip değişmeyeceğini işaretleyin.
3. DNS, TLS, e-posta, ödeme ve erişim izinlerini ayrı kontrol listelerine ayırın. Dış servislerde eski IP'ye bağlı izin varsa yeni IP için önceden hazırlık yapın.
4. Yeni sunucuda aynı çalışma zamanı ve gerekli eklentileri kurun. Sürüm farkı varsa uygulamayı canlıya almadan önce staging ortamında uyumluluk testi yapın.
5. Dosyaları ve veritabanını aktarın; ardından sahiplik, dosya izinleri, bağlantı bilgileri ve yazma gerektiren dizinleri test edin. Uygulama açılıyor olsa bile dosya yükleme ve arka plan işleri ayrıca denenmelidir.
6. Cron, kuyruk işçisi ve webhook gibi görünmeyen akışları test ortamında kontrollü çalıştırın. Gerçek ödeme/e-posta göndermeyin; eski ve yeni ortamda aynı görevin çift çalışmasını önleyin. Beklenen günlük kaydı veya dış servis yanıtı oluşmuyorsa bağımlılık tamamlanmış sayılmaz.
7. DNS değişikliğinden önce yeni sunucuyu doğru alan adı ve TLS sunucu adı korunacak biçimde yerel hosts kaydıyla veya kontrollü test ortamında deneyin. Doğrudan IP, sanal konak ve sertifika davranışını aynı şekilde sınamayabilir. Ana sayfa, giriş, veritabanına yazma, dosya yükleme, e-posta ve kritik entegrasyonları kontrol edin.
8. Envanterde her kalemin veri sahibi ve yazma yönünü belirtin. Yeni ortamda yazma başladıktan sonra yalnız DNS'i eskiye çevirmek geri dönüş sağlamaz; son verinin hangi ortamda korunacağını ayrıca planlayın.

Başarısız testin anlamı genellikle eksik dosyadan çok yanlış ortam değişkeni, ağ izni, DNS önbelleği, dosya sahipliği veya çalıştırılmamış zamanlanmış görevdir. Hata günlüğünü ve ilgili servisin kendi kayıtlarını birlikte inceleyin; yalnızca tarayıcıdaki sonucu ölçüt kabul etmeyin.

Sık yapılan anlamlı hatalar​

En yaygın hata, yalnızca web kök dizinini arşivlemektir. Kullanıcı yüklemeleri, yükleme dışındaki ortak dizinler ve dosya izinleri ayrıca incelenmelidir. İkinci hata, cron görevlerini yeni sunucuda yeniden oluşturmamaktır. Üçüncü hata, dış servislerdeki IP izinlerini ve webhook hedeflerini kontrol etmeden DNS'i değiştirmektir. Ayrıca gizli anahtarları kod deposuna koymak, farklı çalışma zamanı sürümlerini test etmeden geçiş yapmak ve geri dönüş planı olmadan eski sunucuyu kapatmak riski artırır.

Sık sorulan sorular​

DNS kayıtları da bağımlılık sayılır mı?​

Evet. Alan adı, alt alan adı, posta kayıtları, doğrulama kayıtları ve webhook adresleri uygulamanın erişilebilirliğini etkileyebilir. Bunları uygulama dosyalarından bağımsız bir geçiş kalemi olarak takip edin.

Eski sunucu ne zaman kapatılmalı?​

Yeni sunucuda kritik akışlar doğrulanıp beklenmeyen hata görülmediği ve geri dönüş ihtiyacı kalmadığı anlaşılana kadar eski sunucu korunmalıdır. Kapatmadan önce son yedek ve yapılandırma arşivini de alın.

Bir bağımlılığın unutulduğunu nasıl fark ederim?​

Uygulamanın yalnızca ana sayfasını değil; giriş, yazma, dosya yükleme, e-posta, ödeme veya webhook, cron ve yönetim işlemlerini test edin. Eski sunucuda çalışan süreç ve günlüklerle yeni sunucudaki sonuçları karşılaştırmak, görünmeyen bağımlılıkları ortaya çıkarır.