Docker · 1/11
Container nedir, sanal makineden farkı nedir?
Bu serinin ilk durağında amacım şu: “container” dediğimiz şeyi teknik kartvizit gibi değil, gerçekten zihinde canlandırılabilir bir hikâye olarak kurmak. Çünkü birçok ekip Docker’a geçtiğinde önce komutları öğreniyor; fakat altyapıdaki izolasyon modeli net olmayınca kararlar (ağ, depolama, güvenlik) yanlış zeminde alınıyor.
Aşağıda üç katman var: kısa ve net “nedir?”, üretim düşüncesini taşıyan “derin” okuma ve en sonda atölye tarzında küçük bir senaryo.
Nedir?
Container, uygulamanın çalışması için gereken dosyaları ve ayarları paketleyip, işletim sistemi üzerinde kendi görünür alanında çalıştırmayı sağlayan bir çalıştırma biçimidir. Kısaca: aynı makinede birden fazla uygulama yan yana durur; birbirinin dosyalarına “yanlışlıkla” karışmaz, kaynak sınırları da net biçimde konuşulabilir.
Sanal makine (VM) ise tam başka bir hikâye: üstünde ayrı bir işletim sistemi kurulur. Yani her VM kendi kernel’iyle, kendi servisleriyle daha “kalın” bir sınırdır. Container’da ise çoğu senaryoda ana makinenin kernel’i paylaşılır; izolasyon, Linux’ta namespace ve cgroup gibi mekanizmalarla sağlanır. Bu yüzden container genelde daha hafif başlar; VM ise daha ağır ama sınırı daha “katı” hissettirir.
Docker, bu container fikrini paketlemek, imaj üretmek ve çalıştırmak için pratik bir araç takımıdır. “Docker = container” demek doğru değildir; Docker, container’ı üretim hayatına taşıyan en yaygın yollardan biridir.
Derin: üretimde bu ayrım neden önemli?
Üretimde soru genelde şudur: “Bu izolasyon bana hangi güvenceyi veriyor?” VM, iki farklı ekibin aynı cluster’da yan yana dururken “tam OS ayrımı” istediğinizde hâlâ çok güçlü bir seçenektir. Container ise çoğu zaman uygulama teslim hızı ve yoğunluk için optimize edilir; fakat kernel paylaşımı nedeniyle tehdit modelini farklı okursunuz.
Örneğin patch stratejisi: VM dünyasında her makineye işletim sistemi yaması ayrı bir ritüel olabilir. Container dünyasında host işletim sistemi ve imaj içindeki kütüphaneler ayrı ayrı ele alınır; birini güncellediğiniz diğerini otomatik çözmez. Bu “ince” ayrım, operasyon ekibinin checklist’ini değiştirir.
Performans ve maliyet tarafında container genelde daha fazla yoğunluk sağlar; aynı fiziksel kaynak üzerinde daha çok iş yükü koyabilirsiniz. Bunun bedeli, sınırları doğru çizmek zorunda olmanızdır: CPU ve bellek sınırları, ağ politikaları, dosya sistemi izinleri gibi konular “sonra” değil, tasarıda konuşulmalıdır.
Kısacası: VM “kalın sınır”, container “doğru çizildiğinde hızlı ve verimli sınır” gibidir. Hangisinin doğru olduğu ortamınızın regülasyonundan, ekip olgunluğundan ve risk iştahından çıkar.
Atölye: küçük bir düşünce deneyi
Şimdi somutlaştıralım. Diyelim ki kurumsal sitenizin arkasında iki farklı bileşen var: statik içerik için hafif bir web sunucusu ve ayrıca ziyaretçi formunu işleyen küçük bir API. İkisini aynı VM’in içinde iki servis olarak da koşturabilirsiniz; ya da iki ayrı VM’e de koyabilirsiniz; ya da iki ayrı container olarak aynı host üzerinde koşturabilirsiniz.
Container yaklaşımında tipik resim şöyle düşünülür: API trafiği bir container’a, statik site trafiği diğerine; gerekirse alt alan adlarıyla (ör. api.sirketiniz.com) yönlendirme yapılır. Kaynak ihtiyacı değiştiğinde container ölçeğini konuşursunuz; VM ölçeği ise daha pahalı bir adım olabilir. Örneklerde isimlendirmeyi tutarlı tutmak, anlatıyı da sabitler.
Bu serinin ilerleyen yazılarında Dockerfile, imaj katmanları ve compose gibi konulara geçtiğimizde bu düşünce deneyini adım adım gerçek komutlara bağlayacağız. Şimdilik kritik nokta şu: container bir “sihir” değil; izolasyon ve teslim hızı için seçilmiş bir çalışma modeli. VM ile farkını net gördüyseniz, bir sonraki yazıda Docker’ın parçalarını oturtmak çok daha kolay olacak.