Bir uygulamayı container içine almak, onun işletim ihtiyaçlarını ortadan kaldırmıyor. Paketleme kolaylaşıyor; fakat bağımlılıklar, güvenlik sınırları ve güncelleme sorumluluğu devam ediyor. Bu nedenle “hangisi daha yeni?” sorusuyla başlayan seçim, uygulamanın ihtiyacını kaçırabiliyor. Önce çalıştırılacak iş yükünü tarif etmek gerekiyor.
Başlangıç noktası uygulamanın bağımlılıkları
Klasik bir sanal makine kendi işletim sistemini ve çekirdeğini çalıştırır. Standart Linux container'ları ise üzerinde çalıştıkları sistemin çekirdeğini paylaşan izole süreçlerdir. Bu ayrım, farklı çekirdek veya özel sürücü gerektiren uygulamalarda doğrudan karar kriteri olur. Container imajında kullanıcı alanı bağımlılıklarının bulunması, her işletim sistemi ve işlemci mimarisinde koşulsuz çalışacağı anlamına gelmez. Temel model Docker'ın container açıklamasında özetleniyor.
Uygulama belirli bir işletim sistemi sürümüne, üretici ajanına veya desteklenen kurulum biçimine bağlıysa önce destek matrisi okunmalı. Teknik olarak açılan bir servis, üreticinin desteklediği bir kurulum olmayabilir. Destek dışına çıkmanın maliyeti, dağıtım kolaylığından daha yüksek olabilir.
İzolasyonu yapılandırmayla birlikte değerlendirmek
Birden fazla bağımsız uygulama için ortak çekirdek kullanımının kabul edilip edilmediği netleşmeli. Container'ın yetkili modda çalışması, host dizinlerinin bağlanması veya yönetim soketine erişmesi güvenlik sınırını önemli ölçüde değiştirir. İmajı küçültmek tek başına bu riskleri çözmez. Docker güvenlik dokümanı daemon erişiminin ve container yetkilerinin neden ayrı incelenmesi gerektiğini açıklıyor.
VM de kendiliğinden güvenli bir alan oluşturmaz. Yönetim erişimi, işletim sistemi bakımı ve uygulama izinleri yine gerekir. Burada karar, ekibin gerçekten uygulayabildiği kontroller ve iş yükleri arasındaki güven ilişkisi üzerinden verilmelidir. Birbirine güvenmeyen müşterilerin kodunu çalıştırmak ile aynı uygulamanın servislerini ayırmak aynı değerlendirme değildir.
Dağıtım biçimi seçimi değiştirir
Sık güncellenen, yapılandırması dışarıdan verilen ve kolay yeniden oluşturulan servisler container yaklaşımından yararlanabilir. Ancak elle değiştirilen, uzun süre aynı örnek üzerinde yaşayan uygulamalar için önce işletim alışkanlığını düzeltmek gerekir. Eski sunucuyu imaja dönüştürmek, tekrarlanabilir bir teslimat süreci kurmakla aynı şey değildir.
İmaj sürümü de açıkça tanımlanmalı. Değişebilen etiketler yerine gereken durumlarda digest kullanmak, hangi içeriğin dağıtıldığını sabitlemeye yardım eder. Bu seçim güncelleme sürecini ortadan kaldırmaz; yeni digest'in kontrollü biçimde devreye alınmasını gerektirir. Kubernetes imaj belgeleri etiket ve digest davranışını ayrıntılandırıyor.
Karardan önce küçük bir çalışma kâğıdı
Her aday uygulama için şu soruları yanıtlamak yeterli bir başlangıç sağlar:
- Üretici hangi çalışma biçimini destekliyor?
- Ayrı çekirdek veya özel donanım erişimi gerekiyor mu?
- Yeni sürüm nasıl dağıtılacak ve önceki sürüme nasıl dönülecek?
- Uygulama yeniden oluşturulduğunda hangi veriler korunmalı?
- Sorunda hangi ekip hangi katmanı inceleyecek?
Ardından tek bir temsilî uygulamayla pilot yapılmalı. Kurulum süresinin yanında hata ayıklama, sürüm geçişi ve sorumluluk paylaşımı da değerlendirilmeli. Pilotun kabul koşulları baştan yazılırsa karar gösterişli bir demoya bağlı kalmaz.
Container ve VM birlikte de kullanılabilir. VM üzerinde container çalıştırmak oldukça yaygın bir yerleşimdir. Önemli olan katman sayısını artırırken yönetim sorumluluğunu belirsiz bırakmamaktır. Kararı kısa bir teknik notla kaydetmek, altı ay sonra aynı tartışmanın baştan yapılmasını da önler.
Yorumlar (0)
Henüz onaylanmış yorum yok.