Çalışma Zamanı Sürüm Yönetimi: Farklı Sürümleri Yan Yana Çalıştırmak

Sunucunuzda üç proje var. Biri eski bir sürüm gerektiriyor, diğeri en güncelini istiyor, üçüncüsü ikisinin arasında bir sürümle çalışıyor.

Sistem genelinde tek bir sürüm kurmak bu durumda çözüm değildir. Bu yazı, VDS sunucunuzda birden fazla çalışma zamanı sürümünü bir arada yönetmeyi anlatıyor.

Tek Sürüm Sorunu

Sistem paket yöneticisiyle kurulan bir çalışma zamanı, genellikle tek bir sürümdür ve tüm sistem onu kullanır. Bu, birkaç sorun üretir:

Son satır, en az bilinen ama en ciddi risktir: bazı sistem araçları, kurulu çalışma zamanına bağımlıdır. Sistem genelindeki sürümü değiştirmek, paket yöneticisi gibi temel araçları çalışmaz hâle getirebilir.

Bu yüzden proje ihtiyaçları için sistem sürümünü değiştirmek yerine, ayrı sürümler kurmak tercih edilir.

Üç Yaklaşım

1. Paket Deposu Üzerinden Çoklu Sürüm

Bazı çalışma zamanları için, birden fazla sürümü yan yana kurmayı destekleyen depolar bulunur. Her sürüm ayrı bir paket olarak kurulur ve ayrı yollarla çağrılır.

Avantajı: sistem paket yöneticisiyle yönetilir, güvenlik güncellemeleri otomatik gelir.

Dezavantajı: yalnızca deponun sunduğu sürümlerle sınırlısınız.

2. Sürüm Yöneticisi Araçları

Birçok dil için, farklı sürümleri kurup aralarında geçiş yapmayı sağlayan araçlar vardır. Proje dizinine bir dosya koyarak o projenin hangi sürümle çalışacağını belirtebilirsiniz.

Avantajı: neredeyse her sürüme erişim, kolay geçiş.

Dezavantajı: güvenlik güncellemelerini kendiniz takip etmeniz gerekir.

3. Konteyner Kullanmak

Her proje, kendi çalışma zamanı sürümüyle birlikte izole bir ortamda çalışır. En temiz ayrımı sağlar.

Avantajı: tam izolasyon, taşınabilirlik, sistemi hiç etkilememe.

Dezavantajı: öğrenme eğrisi ve ek kaynak kullanımı.

Pratik tavsiye: iki üç projeniz varsa çoklu sürüm kurulumu yeterlidir. Proje sayısı arttıkça ve ortam farkları büyüdükçe konteyner yaklaşımı daha mantıklı hâle gelir.

Web Sunucusuyla Bağlantı

Çoklu sürüm kurulumunda kritik nokta, hangi sitenin hangi sürümü kullanacağının belirlenmesidir.

Yaygın yapı şudur: her sürüm için ayrı bir işlem havuzu çalışır ve web sunucusu, site bazında hangi havuza yönlendireceğini bilir.

Bu yapılandırmada dikkat edilecekler:

1. Her havuz ayrı kullanıcıyla çalışsın. Bir sitedeki açık diğerlerine sıçramasın.
2. Havuz kaynak sınırlarını ayrı ayarlayın. Toplam bellek kullanımı sunucu kapasitesini aşmasın.
3. Yalnızca kullanılan havuzları çalıştırın. Boşta duran havuzlar bellek tüketir.
4. Log dosyalarını ayırın. Hangi sürümde ne olduğunu görebilin.

Birinci madde önemli bir güvenlik kazancıdır: her site kendi kullanıcısıyla çalışıyorsa, birinin ele geçirilmesi diğerlerine erişim sağlamaz. Bu, çoklu sürüm kurulumunun beklenmedik bir yan faydasıdır.

Komut Satırı Karmaşası

Çoklu sürüm kurulumunda sık yaşanan bir kafa karışıklığı vardır: komut satırından çalıştırdığınız sürüm ile web üzerinden çalışan sürüm farklı olabilir.

Belirtisi tipiktir: bir betiği terminalden çalıştırdığınızda sorunsuz çalışır, aynı kod web üzerinden hata verir — çünkü farklı sürümlerde çalışıyorlar.

Bu karmaşayı önlemek için:

• Zamanlanmış görevlerde tam yol kullanın. Varsayılan sürüme güvenmeyin.
• Dağıtım betiklerinde sürümü açıkça belirtin.
• Hangi sürümde olduğunuzu doğrulayın. Sorun gidermeye başlamadan önce.
• Proje dizininde sürüm bilgisi tutun. Ekip üyeleri hangi sürümün gerektiğini görsün.

Birinci madde en sık yaşanan sorunu çözer: zamanlanmış bir görev, varsayılan sürümle çalışır ve o sürüm proje için yanlışsa görev sessizce başarısız olur.

Bağımlılık Yönetimi

Farklı sürümler, farklı bağımlılık kümeleri gerektirir. Yönetimi karıştırmamak için:

1. Her projenin bağımlılıkları kendi dizininde olsun. Sistem geneline kurmayın.
2. Bağımlılık tanım dosyalarını sürüm kontrolüne alın. Ama kurulu paketleri değil.
3. Sürüm kilit dosyalarını da saklayın. Aynı kurulum her yerde tekrarlanabilsin.
4. Uzantı ve eklentileri sürüm bazında kurun. Her çalışma zamanı sürümünün kendi uzantıları vardır.

Dördüncü madde çoklu sürüm kurulumunda sık atlanır: bir uzantıyı bir sürüme kurmak, diğerinde de kullanılabilir olduğu anlamına gelmez. Her sürüm için ayrı ayrı kurulmalıdır.

Kademeli Yükseltme

Çoklu sürüm desteğinin en değerli faydası, yükseltmeyi risksiz hâle getirmesidir:

1. Yeni sürümü sisteme kurun — mevcut projeler etkilenmez
2. Bir projeyi test ortamında yeni sürüme geçirin
3. Sorunları düzeltin
4. O projeyi canlıda yeni sürüme alın
5. Diğer projeleri sırayla geçirin
6. Hiçbir proje kullanmadığında eski sürümü kaldırın

Bu akış, "hepsi birden yükseltilecek" baskısını ortadan kaldırır. Her proje kendi hızında ilerler ve sorun çıkarsa yalnızca o proje etkilenir.

Dördüncü adımda geri dönüş de kolaydır: sorun çıkarsa o sitenin havuzunu eski sürüme geri çevirmek dakikalar sürer.

Bakım Yükü

Çoklu sürüm kurulumunun bir bedeli vardır ve göz ardı edilmemelidir:

• Her sürüm ayrı güvenlik güncellemesi gerektirir
• Desteği biten sürümler risk üretir
• Her havuz bellek tüketir
• Yapılandırma karmaşıklığı artar

İkinci madde en kritik olanıdır: desteği biten bir sürümde çalışan bir proje, güvenlik güncellemesi almayan bir projedir. Çoklu sürüm desteği, eski sürümde kalmak için bir bahane olmamalıdır — geçişi kolaylaştırmak için bir araçtır.

Bu yüzden kullandığınız sürümlerin destek bitiş tarihlerini takip edin ve VDS sunucu bakım planınıza ekleyin.

Sonuç

Farklı sürüm gerektiren projeleri tek sunucuda çalıştırmanın yolu, sistem sürümünü değiştirmek değil yan yana birden fazla sürüm kurmaktır — üstelik sistem araçları kurulu çalışma zamanına bağımlı olduğu için, sistem sürümünü değiştirmek temel araçları bozabilir. İki üç projede çoklu sürüm kurulumu yeterlidir; ortam farkları büyüdükçe konteyner yaklaşımı mantıklı hâle gelir. En sık yaşanan tuzağı hatırlayın: zamanlanmış görevler varsayılan sürümle çalışır ve bu, proje için yanlış sürüm olabilir — tam yol kullanın.

Sıkça Sorulan Sorular (SSS)

Sistem sürümünü değiştirmek neden riskli?

Bazı sistem araçları kurulu çalışma zamanına bağımlıdır; sistem genelindeki sürümü değiştirmek paket yöneticisi gibi temel araçları çalışmaz hâle getirebilir. Proje ihtiyaçları için sistem sürümünü değiştirmek yerine ayrı sürümler kurun.

Hangi yöntemi seçmeliyim?

İki üç projeniz varsa paket deposu üzerinden çoklu sürüm kurulumu yeterlidir ve güvenlik güncellemeleri otomatik gelir. Proje sayısı arttıkça ve ortam farkları büyüdükçe konteyner yaklaşımı daha temiz izolasyon sağlar.

Terminalde çalışıyor ama web'de çalışmıyor?

Büyük ihtimalle farklı sürümlerde çalışıyorlar. Komut satırındaki varsayılan sürüm ile web sunucusunun kullandığı havuz farklı olabilir. Zamanlanmış görevlerde ve dağıtım betiklerinde sürümü tam yolla belirtin.

Eski sürümde kalmaya devam edebilir miyim?

Teknik olarak evet ama riskli. Desteği biten bir sürüm güvenlik güncellemesi almaz ve zamanla açık birikimine dönüşür. Çoklu sürüm desteğini eski sürümde kalmak için değil, geçişi kademeli ve risksiz yapmak için kullanın.