Container, bir uygulamayı çalışması için gereken her şeyle birlikte paketleyip yalıtılmış biçimde çalıştıran birim. Çözdüğü sorun eski ve tanıdık: uygulamanın geliştiricinin makinesinde çalışıp sunucuda çalışmaması. Paketin içeriği her ortamda aynı olduğu için bu fark ortadan kalkıyor.
Sanal makineden farkı
Sanal makine kendi işletim sistemini taşır. Açılırken o işletim sistemi baştan başlar, bu yüzden başlaması saniyeler değil dakikalar sürer ve her sanal makine gigabaytlarca yer kaplar.
Container kendi çekirdeğini taşımaz; üzerinde çalıştığı makinenin çekirdeğini paylaşır. Taşıdığı şey yalnızca uygulama ve bağımlılıkları. Bu yüzden saniyeler içinde başlar, megabaytlar mertebesinde yer kaplar ve aynı sunucuda çok daha fazlası çalışabilir.
Bunun bedeli yalıtım düzeyinde. Sanal makineler birbirinden daha kalın bir duvarla ayrılır. Container'lar aynı çekirdeği paylaştığı için yalıtım daha ince; bu, container'ların güvensiz olduğu anlamına gelmiyor ama farklı güven seviyelerindeki iş yüklerini ayırmak için ek tedbir gerektiriyor.
İmaj, katman ve kayıt defteri
İmaj, bir container'ın çalıştırılabilir şablonu. Katmanlardan oluşur: temel bir işletim sistemi katmanı, üzerine kurulan kütüphaneler, en üstte sizin uygulamanız. Katmanlı yapı sayesinde ortak parçalar tekrar tekrar indirilmez.
Kayıt defteri (registry), imajların saklandığı ve sürümlendiği
yer. Bir imaj etiketiyle çağrılır. Buradaki en yaygın hata, etiket olarak
latest kullanmak: bugün çektiğiniz latest ile bir ay
sonra çektiğiniz aynı şey olmayabilir, dolayısıyla üretimde neyin çalıştığından
emin olamazsınız.
Asıl risk nerede
Container'ın güvenlik konusu genelde yanlış yerde aranıyor. Asıl risk container'ın kendisinde değil, imajın içine ne girdiğinde. Bir imaj temel katmanıyla birlikte yüzlerce paket taşır ve bunların çoğunu siz seçmezsiniz. Bir yıl önce üretilmiş bir temel imaj, o gün bilinmeyen ama bugün yayımlanmış onlarca zafiyet taşıyor olabilir.
İkinci risk kaynağı, imajın nereden geldiği. Genel bir kayıt defterinden çekilen ve kimin ürettiği doğrulanmayan bir imaj, üretim ortamınıza doğrudan giren dış koddur. Tedarik zinciri saldırılarının çalışma mantığı tam olarak bu.
Bizde nasıl ele alınıyor
İmajları özel bir kayıt defterinde tutuyor, dağıtımdan önce tarıyoruz. Tarama her açığı engellemek için değil, hangi açığın gerçekten sömürülebilir olduğunu ayırmak için var; bulunan her bulgu üretimi durduracak olsaydı hiçbir dağıtım geçmezdi. Kapsam ve eşiklerin nasıl belirlendiğini container registry sayfasında anlattık.
İmza doğrulama tarafında beklenen kazanç, üretime yalnızca bizim ürettiğimiz imajların girmesi. Bunun pratikte neyi çözdüğünü ve nerede eksik kaldığını imaj tarama ve tedarik zinciri yazımızda ölçümlerle yazdık.
Container'ları birden fazla sunucu üzerinde çalıştırmak istediğinizde işin adı orkestrasyon oluyor; oraya Kubernetes giriyor. Cluster'ı siz yönetmek istemiyorsanız Container as a Service daha uygun olabilir.
Container mı, sanal makine mi
İkisi rakip değil, farklı işlerin araçları. Uygulamanız modern bir çalışma zamanı üzerinde çalışıyorsa, sık dağıtılıyorsa ve yatay ölçekleniyorsa container doğru seçim. Başlama süresinin saniyeler olması, ölçeklemeyi gerçekten kullanılabilir kılıyor.
Sanal makine şu durumlarda hâlâ daha uygun: kendi işletim sistemi çekirdeğine ihtiyaç duyan yükler, container'a taşınması için yeniden yazılması gereken eski uygulamalar, ve farklı güven seviyelerindeki iş yüklerinin kalın bir duvarla ayrılması gereken durumlar.
Pratikte çoğu kurumda ikisi bir arada bulunuyor. Yeni servisler container olarak yazılıyor, eski sistemler sanal makinelerde çalışmaya devam ediyor ve ikisi aynı ağ üzerinde konuşuyor. Her şeyi container'a taşımayı bir hedef haline getirmek, taşınmaya değmeyen uygulamalar için harcanan aylara mal oluyor. Karar verirken bakılacak soru şu: bu uygulamayı ne sıklıkla dağıtıyoruz ve yükü ne kadar değişiyor?
Sık yapılan yanlışlar
Container'ı sanal makine gibi kullanmak. İçine girip elle değişiklik yapmak, sonra o değişikliğin kaybolmasına şaşırmak. Container geçicidir; kalıcı olması gereken şey imajda ya da dışarıdaki depolamada durur.
Her şeyi tek bir imaja koymak. Uygulama, veri tabanı ve arka plan işlerini aynı container'a sıkıştırmak, container'ın sağladığı bağımsız ölçekleme ve dağıtım imkânını yok eder.
Kaynak limiti tanımlamamak. Limitsiz bir container, bir hata durumunda aynı node'daki diğer iş yüklerinin belleğini tüketebilir. Limitler performans ayarı değil, komşu koruma tedbiridir.
Log'u dosyaya yazmak. Container silindiğinde içindeki dosyalar da gider. Log'un container dışına, merkezî bir toplayıcıya akması gerekiyor; aksi halde arıza sonrası elinizde inceleyecek hiçbir kayıt kalmıyor. Bu, sorun çıktıktan sonra en çok pişman olunan eksik.
Terimlerin kısa tanımları için sözlüğe, hangi hizmet katmanının size uygun olduğu için katman karşılaştırmasına bakabilirsiniz.
Container'a geçmeyi düşünüyorsanız en iyi başlangıç, üretimdeki en kritik uygulama değil, dağıtımı en sık yapılan ve kesintiye en toleranslı olanı. İlk uygulamayı taşırken öğrenilen şeyler, ikinci ve üçüncüde çok daha hızlı ilerlemenizi sağlıyor. Hepsini aynı anda taşımaya çalışmak, en yaygın ve en pahalı hata.