Sanalizasyon Nedir? Bilmeniz Gereken Her Şey

Çok da uzun olmayan bir süre önce, sunucu odaları basit bir kurala göre düzenlenirdi: bir makine, bir iş. E-posta kendi makinesinde çalışırdı. Dosya paylaşımı için özel bir sunucu vardı. Veritabanı başka bir yerdeydi. Her sistem kendi yamalama döngüsü, güç tüketimi ve donanım arızalarıyla gelirdi; tümü, az kullanılan makinelerle dolu bir odada katlanarak artardı.

Bu makinelerin çoğu yılın en kötü günü düşünülerek satın alınır, sonra yılın geri kalanında beklerdi. Sanalizasyon ekonomiyi tersine çevirdi. Her hizmete bir kutu ayırmak yerine, ekipler birden fazla iş yükünü daha güçlü az sayıda ana bilgisayara sığdırmaya başladı. Her iş yükü hâlâ kendi ortamında çalışır, ancak fiziksel ayak izi küçülür: satın alınacak, kablolayacak, besleyecek, soğutacak ve sonunda emekliye ayıracak daha az sunucu.

Bu rehber, pratikte önemli olan hareketli parçaları kapsar: hipervizörün ne yaptığı, Tip 1 ve Tip 2’nin nerede konumlandığı, kaynak tahsisinin nasıl çalıştığı ve VM’lerin, konteynerlerin ve bulut hizmetlerinin nasıl ilişkilendiği. Amaç, doğru aracı seçmenize ve ilk tanımı geçtikten sonra ortaya çıkan kısıtları anlamanıza yardımcı olmaktır.

Görsel: wirestock, Freepik.

Sanalizasyon Nasıl Çalışır

Sanalizasyon, tek bir fiziksel ana bilgisayarın birden fazla “makineyi” aynı anda çalıştırmasına olanak tanır—her biri kendi işletim sistemi, süreçleri ve dosya sistemiyle. Bunu mümkün kılan bileşen hipervizördür: CPU zamanı, bellek, depolama ve ağ kaynaklarını konuklar arasında bölen ve aralarındaki sınırları uygulayan kontrol katmanı.

Hipervizör katmanı

Hipervizör trafik denetleyicisidir. Konuklar CPU zamanı, RAM sayfaları, disk G/Ç’si ve ağa erişim ister; hipervizör bu istekleri zamanlar ki bir VM diğerlerini aç bırakmasın veya ana bilgisayarı ele geçirmesin.

Modern CPU’lar, masaüstü sanalizasyonu eskiden hantal hale getiren çeviri ek yükünü azaltan sanalizasyon uzantıları içerir (Intel VT-x, AMD AMD-V). Bu CPU uzantıları, masaüstü sanalizasyonunun bir “bilim projesi” gibi hissettirmeyi bırakmasının büyük sebeplerinden biridir. Modern donanımla, bir geliştirici dizüstü bilgisayarında birkaç VM çalıştırmak genelde sıkıcıdır—iyi anlamda.

Kaynak ataması, en sık etkileşimde bulunduğunuz kısımdır:

• CPU: konuğun gördüğü sanal çekirdek sayısı
• Bellek: takas ya da duraksama olmadan kullanabileceği RAM miktarı
• Depolama: konuğun perspektifinden fiziksel sürücü gibi davranan sanal disk
• Ağ: gerçek ağa sanal anahtarlar üzerinden bağlanan sanal NIC’ler

Konuk içinde her şey normal görünür: İS açılır, paketler yüklenir, dosyalar yazılır, soketler açılır. VM içinden göremediğiniz şey, alttaki uzlaştırmadır—sırada kimin CPU alacağı, kimin disk yazımlarının kuyruklandığı ve ana bilgisayarın ne zaman doygunlaştığı.

Tip 1 ve Tip 2 hipervizörler

Çoğu hipervizör iki sınıfa girer ve ayrım büyük ölçüde hipervizörün nerede yaşadığıyla ilgilidir.

• Tip 1 (çıplak metal) ana bilgisayar donanımı üzerinde çalışır ve üretimde standarttır; çünkü “alttaki katmana” harcanan kapasite daha azdır. ESXi ve sunucu dağıtımlarında Hyper-V bu sınıfa girer ve KVM, Linux tabanlı yığınlarda yaygın olarak sanalizasyon katmanı olarak kullanılır.
• Tip 2 (barındırılan) mevcut İS’nizin üzerinde bir uygulama olarak çalışır. Windows/macOS/Linux ana bilgisayar olarak kalır, ardından üzerine VirtualBox veya VMware Workstation kurarsınız. Kişisel bir makinede küçük bir laboratuvar kurmanın en kolay yoludur ve insanlar genellikle burada başlar.

Kaynak tahsisi

Bir VM oluşturduğunuzda bir bahis yaparsınız: “Bu iş yükünün yaklaşık şu kadar CPU, bellek ve disk kaynağına ihtiyacı var.” Hipervizörler bu kaynakların nasıl temsil edildiği ve rezerve edildiği konusunda esneklik sunar.

Bu takası görmenin en kolay yeri depolama sağlanmasıdır:

• Kalın sağlama (thick provisioning) sanal disk boyutunun tamamını baştan ayırır. 100 GB’lık bir disk oluşturun; ana bilgisayar, VM kullansa da kullanmasa da bu alanı hemen kenara koyar. Basit ve öngörülebilirdir; ayrıca VM çoğunlukla boşken bile depolama maliyetini peşin ödemeniz anlamına gelir.
• İnce sağlama (thin provisioning) maliyeti erteler. Konuk hâlâ 100 GB’lık bir disk görür; ancak ana bilgisayar yalnızca bloklar yazıldıkça alan tüketir. Bu, kullanım oranını iyileştirir ve aşırı tahsisi mümkün kılar; fakat bir arıza modu da yaratır: ana bilgisayarda gerçek disk alanı biterse, VM’ler hızlıca kurtarması zor hatalar vermeye başlayabilir.

CPU ve bellek çoğunlukla aynı “olasılık” zihniyetiyle aşırı tahsis (overcommitment) yoluyla ele alınır. Toplam sanal CPU’yu, fizikselde olandan daha fazla tahsis edebilirsiniz; çünkü iş yüklerinin aynı anda tepeye çıkmayacağını beklersiniz. Bu, birçok karma iş yükü için iyi çalışır; ancak her şey aynı anda yoğunlaşırsa çekişmeye yol açabilir. Aşırı tahsis “yanlış” değildir—sadece ana bilgisayarın baskı noktalarına görünürlük gerektiği anlamına gelir.

Anlık görüntüler ve canlı taşıma

Günlük operasyonları değiştirdiği için, sadece mimari diyagramları değil, iki özellik özellikle anılmaya değerdir.

• Anlık görüntüler (snapshots) geri alma noktası sağlar. Riskli bir yama veya yapılandırma değişikliğinden önce bir tane alın; VM açılmayı durdurur veya uygulama anormal davranırsa hızlıca geri dönebilirsiniz. Bu yüzden anlık görüntüler test/ön üretim ortamlarında ve bakım aralıklarında yaygındır.
• Canlı taşıma (live migration) operatörlerin çalışan bir VM’yi çok az kesintiyle başka bir ana bilgisayara taşımasına olanak tanır. Pratikte, ölçekli bakım böyle yapılır: bir ana bilgisayarı boşaltın, donanımı yamalayın veya değiştirin, iş yüklerini yeniden dengeleyin ve müşteriyle yüzleşen hizmetleri çalışır durumda tutun.

Önemli Sanalizasyon Türleri

Uzmanlaşmış sanalizasyon türleri (ağ, depolama, veri) vardır; ancak çoğu ekip sürekli olarak üç kategoriyle karşılaşır.

Sunucu sanalizasyonu

Sunucu sanalizasyonu emektar modeldir: tek bir fiziksel ana bilgisayar, her biri kendi İS ve uygulamalarıyla bir VM olarak birçok sunucu örneğini çalıştırır.

Kazanımların hızlıca görüldüğü yer burasıdır. Şirketlerdeki tipik “küçük filo”yu düşünün: hafif bir web uygulaması, bir veritabanı, dahili panolar, bir zamanlayıcı, bir dosya hizmeti, izleme, belki bir mesaj aracısı. Ayrı ayrı bakıldığında, her biri bir sunucuyu hak ediyor gibi görünür. Gerçekte, çoğu uzun süreler boyunca çok az iş yapar. Sanalizasyon bu boşta geçen zamanı paylaşılan kapasiteye dönüştürür.

Birçok kuruluşun gördüğü somut bir örnek:

10 fiziksel sunucu → 2 sanalizasyon ana bilgisayarı

Konsolidasyondan sonra değişen sadece maliyet değildir. Sağlama daha hızlı hale gelir. Kapasite, izole adacıklar kümesi yerine bir havuz olur. Bir iş yükünün daha fazla kaynağa ihtiyacı olduğunda, yeni donanım sipariş etmek yerine tahsisleri ayarlar veya onu taşırsınız.

Dezavantajı, paylaşılan kaderdir: bir ana bilgisayar arızalandığında, aynı anda birkaç VM ortadan kaybolur. Bu nedenle üretim kurulumları yedeklilik, izleme ve temkinli kapasite payları etrafında inşa edilir.

Masaüstü sanalizasyonu (VDI)

VDI, masaüstü ortamlarını veri merkezinde (veya bulutta) VM’ler olarak çalıştırır. Kullanıcılar ağa üzerinden bağlanır; işlem ve depolama uç noktada değil, merkezi ortamda kalır.

VDI, kuruluşların şu istekleri olduğunda ortaya çıkar:

• cihazlar arasında kullanıcıları takip eden masaüstleri
• merkezi güncellemeler, yamalar ve politika uygulaması
• kaybolan veya çalınan uç noktalarda veri bulundurma riskinin azaltılması

Hızlı bir karşılaştırma yaygın bir kafa karışıklığını giderir:

• Uzak Masaüstü: başka bir yerdeki mevcut bir makineye giriş yaparsınız.
• VDI: kuruluş, paylaşılan ana bilgisayar altyapısında (genellikle kullanıcı başına veya oturum başına) masaüstü VM’ler sağlar.

Ekranlar benzer görünebilir, ancak operasyonel model öyle değildir. Gecikme birincil endişedir; GPU ağırlıklı işler maliyetleri hızla artırır ve büyük bir masaüstü havuzunu çalıştırmak gerçek bir kapasite planlaması gerektirir.

Uygulama sanalizasyonu ve konteynerler

Konteynerler, VM’lerden farklı bir sorunu çözer. Tam konuk İS örnekleri çalıştırmak için donanımı sanallaştırmak yerine, konteynerler ana makine çekirdeğini paylaşırken uygulamaları izole eder. Başka bir işletim sistemi önyüklemeden süreç/dosya sistemi/ağ düzeyinde ayrım elde edersiniz.

Docker bu modeli erişilebilir kıldı: uygulamayı ve bağımlılıklarını bir imaj olarak paketleyin, ardından aynı eseri geliştirme, CI ve üretimde çalıştırın. Bu tekrarlanabilirlik, konteynerlerin bu kadar hızlı yayılmasının nedenidir—daha az ortama özgü sürpriz, daha az “önce şu on şeyi yükleyin” kurulum dokümanı.

Konteynerlerin pratik ergonomisi de avantajdır:

• Başlatma genellikle dakikalar değil saniyelerdir
• Ayak izi çoğunlukla gigabaytlar yerine megabaytlardır
• Yerelde birçok küçük hizmet çalıştırmak gerçektedir

VM’ler ve konteynerler kısmen örtüşen ama farklı sorunları çözer:

Yaygın bir üretim deseni “VM’ler üzerinde konteynerler”dir. VM sınırı altyapı izolasyonu ve filo yönetimi için kullanılır; konteynerler ise uygulama katmanında dağıtım ve ölçeklemeyi ele alır. Introduction to Docker kursumuz konteyner temellerini kapsar. Containerization and Virtualization with Docker and Kubernetes öğrenim yolumuz ise orkestrasyon kalıplarına daha derin iner.

VM’ler vs. Konteynerler vs. Bulut: Fark Nedir?

Bu terimler genellikle aynı yığında göründükleri için birlikte anılır. Bunları, gerçekte ne elde ettiğinize göre ayırmak yardımcı olur: izole bir İS (VM), izole bir uygulama çalışma zamanı (konteyner) veya ikisini de sağlayan yönetilen bir platform (bulut).

Sanal Makineler

Sanal makine, tam bir işletim sistemiyle birlikte sanal donanım ve uygulamaları paketler. Her VM kendi çekirdeğine sahiptir; bu da aynı ana bilgisayar üzerindeki iş yükleri arasında güçlü izolasyon sağlar.

Bedeli ağırlıktır: tam İS örnekleri daha fazla bellek tüketir, daha uzun sürede açılır ve daha büyük imajlar üretir. Bu ek yük, üretimde genellikle kabul edilebilirdir; çünkü izolasyon ve uyumluluk buna değerdir.

Konteynerler

Konteynerler, uygulama çalışma zamanını izole ederken ana makine İS çekirdeğini paylaşır. Bu paylaşılan çekirdek, konteynerleri hafif ve hızlı kılan şeydir. İmajlar daha küçük ve taşınması daha kolay olma eğilimindedir; bu yüzden konteynerler modern dağıtım iş akışlarına iyi uyar.

Konteyner izolasyonu gerçektir; ancak “ayrı çekirdekler” ile aynı sınır değildir. Konteynerler hâlâ ana makine çekirdeğine bağlıdır; bu yüzden iş yükü hassasiyeti ve güvenlik duruşu, ekiplerin konteynerleri doğrudan ana bilgisayarlarda mı yoksa VM’ler içinde mi çalıştıracağını etkiler.

Bulut Bilişim

Bulut platformları sanalizasyona (ve sıklıkla konteynerlere) dayanır ve bunu yönetilen bir kontrol düzlemine sarar: API’ler, sağlama, faturalama, ağ ve kendiniz işletmediğiniz hizmetler (veritabanları, kuyruklar, nesne depolama, izleme).

Bir EC2 örneği başlattığınızda, fiilen AWS filosundan bir VM kiralamış olursunuz. Diğer ürünler—sunucusuz işlevler, yönetilen konteyner hizmetleri—daha hafif izolasyon mekanizmaları kullanır; fakat ortak nokta aynıdır: bulut, kaynakları talep üzerine sunar ve pek çok altyapı işini bir API’nin arkasında gizler.

Basit bir karar çerçevesi:

• Tasarımı İS ayrımı veya uyumluluk yönlendiriyorsa VM’leri kullanın.
• Hızlı başlatma ve tekrarlanabilir bir dağıtım eseri istiyorsanız konteynerleri kullanın.
• Esneklik ve yönetilen operasyonlar, alttaki ana bilgisayarları kontrol etmekten daha önemliyse bulut hizmetlerini kullanın.

Pratikte “yığılmış” sürüm yaygındır: bulut VM’leri Kubernetes kümelerine ev sahipliği yapar; bu kümeler konteynerleri zamanlar; konteynerler de uygulamaları çalıştırır. Bulut mimarisi hakkında daha derin bağlam için Understanding Cloud Computing kursumuzu ve Azure’a özgü hizmetler için Understanding Microsoft Azure Architecture and Services kursumuzu inceleyin. 

Sanalizasyon Neden Önemlidir

Sanalizasyon, geliştirme, operasyonlar ve veri çalışmalarında pratik sorunları çözdüğü için varlığını sürdürür.

Geliştirme ve test

Sanalizasyon, kontrol edilen ortamları oluşturmayı ucuz hale getirir. Bir boru hattını iki İS sürümünde test etmeniz mi gerekiyor? İki VM oluşturun, aynı adımları çalıştırın, davranışı karşılaştırın. Riskli bir yükseltmeyi denemeniz mi gerekiyor? Önce anlık görüntü alın, ilerleyin, gerekirse geri dönün.

Ayrıca çapraz platform kontrollerindeki sürtünmeyi de ortadan kaldırır. macOS üzerinde çalışan bir geliştirici, birden fazla fiziksel makineyi sırayla kullanmak zorunda kalmadan davranışı Windows’ta doğrulayabilir.

Veri çalışmalarında tekrarlanabilirlik yinelenen temadır. Sonuçlar genellikle belirli bir paket, sistem kitaplığı ve yapılandırma karışımına bağlıdır. Sanalize edilmiş ortamlar bu bağımlılıkları istikrarlı ve taşınabilir tutmaya yardımcı olur.

Maliyet ve verimlilik

Kaynakları havuzlamak temel avantajdır: on adet boşta makine için para ödemeyi bırakır ve aynı donanımı daha tutarlı şekilde kullanmaya başlarsınız.

Tasarruflar sıkıcı ve ölçülebilir yerlerde ortaya çıkar: satın alınacak daha az sunucu, daha az raf alanı, daha düşük soğutma payı, daha az bakım sözleşmesi ve sonunda değiştirilmesi gereken daha küçük bir donanım yığını. Konsolidasyon operasyonel işleri ortadan kaldırmaz; fakat şeklini değiştirir.

Esneklik ve ölçekleme

Sağlama bir yazılım görevine dönüşür. Donanım sipariş etmek, teslimat beklemek, rafa yerleştirmek ve bir İS imajlamak yerine, ekipler bir şablonu klonlar, tahsisleri ayarlar ve dağıtır.

Ölçekleme de daha az katıdır. Talep artarsa VM ekleyebilir veya mevcutları yeniden boyutlandırabilirsiniz. Talep düşerse, aylarca az kullanılan fiziksel bir sunucuyu bırakmak yerine kapasiteyi geri kazanabilirsiniz.

Felaket kurtarma otomatik hale gelmez; ancak sanalizasyon araç kutusunu değiştirir. “Sunucu”, yönetilen bir VM imajı artı veriler olduğunda, çoğaltma ve kurtarma stratejileri, kutu başına tek uygulama dönemine kıyasla standartlaştırması daha kolay hale gelir.

Yaygın Zorluklar ve Nasıl Baş Edilir

Sanalizasyon bir sınıf baş ağrısını ortadan kaldırır ve farklı bir sınıfı getirir. Çoğu sorun gizemli değildir; kaynak sınırları, çekişme veya operasyonel hijyendir.

Performans sorunları

En yaygın performans şikayeti çekişmedir: birden çok VM’in aynı CPU zamanı, bellek bant genişliği veya depolama G/Ç’si için kapışması. Her şey, birkaç iş yükü birlikte tepeye çıkana kadar iyi hissedilir; sonra gecikme sıçrar ve çıktı düşer.

Pratikte yardımcı olanlar:

• Yalnızca konuk metriklerini değil, ana bilgisayar metriklerini izleyin (CPU hazır zamanı, bellek baskısı, disk gecikmesi/G/Ç bekleme).
• Boyutlandırmayı düzenli olarak gözden geçirin. Her iki uç da zararlıdır: aşırı tahsis kapasiteyi boşa harcar; yetersiz tahsis takasa ve savrulmaya neden olur.
• Kalıcı yüksek kullanım oranını bir kapasite sinyali olarak ele alın ve belirtilerin peşinden VM VM dolaşmak yerine buna göre plan yapın.

Azınlık bir iş yükü hâlâ çıplak metalde olmalıdır: aşırı gecikme hassasiyeti, özel donanıma sıkı sıkıya bağlılık veya küçük zamanlama oynamalarının dahi kabul edilemez olduğu gerçek zamanlı kısıtlar.

Güvenlik hususları

VM izolasyonu güçlüdür; ama bir kuvvet alanı değildir. Ana bilgisayarlar paylaşımlıdır, hipervizörler kritik altyapıdır ve güvenlik açıkları—her gün olmasa da—vardır.

Pratik güvenlik duruşu şuna benzer:

• Hipervizörleri ve ana bilgisayarları hızlıca yamalayın
• Ağları bölümleyin; böylece “aynı ana bilgisayar” “aynı güven zonu” anlamına gelmesin
• Risk profili gerektirdiğinde yüksek hassasiyetli iş yüklerini ayırın

Konteynerler ek bir tercih katmanı getirir: konteynerleri doğrudan ana bilgisayarlarda mı yoksa VM’ler içinde mi çalıştıracağınız, izolasyon gereksinimlerinize ve operasyonel modelinize bağlıdır.

VM enflasyonu

Sanalizasyon oluşturmayı kolaylaştırır; bu yüzden ortamlar hızla büyür. Korkuluklar olmadan, sahipsiz VM’ler, bilinmeyen sahipler ve “her ihtimale karşı” var olan makinelerle karşılaşırsınız.

İşe yarar bir önleme modeli:

• Sahiplik ve amaç etiketleri zorunlu olsun
• Geliştirme/test VM’leri için son kullanma tarihleri atayın
• Kullanımı düzenli gözden geçirin (ve gerçekten boşta olanları silin)
• Üretim dışı ortamlarda temizliği otomatikleştirin

Denetimler sıklıkla uzun süre çok az iş yapan şaşırtıcı derecede yüksek bir VM oranı bulur. Çözüm nadiren karmaşıktır; çoğunlukla disiplin ve yaşam döngüsü yönetimidir.

Gerçek Dünyada Sanalizasyon

Sanalizasyon, birçok ekibin her gün kullandığı yerlerde ortaya çıkar; buna bu isim verilmemiş olsa bile.

Geliştirme ve veri bilimi

CI/CD sistemleri, iş akışlarının her çalıştırmasının temiz başlaması için işleri yaygın olarak geçici VM’lerde veya konteynerlerde çalıştırır. Bu, bağımlılık kaymasını önler ve hataları yeniden üretmeyi kolaylaştırır.

İzolasyon, projelerin çarpışmasını önlemeye de yardımcı olur. Bir iş akışı daha eski CUDA kitaplıklarına ihtiyaç duyabilir; bir diğeri daha yeni sürümleri gerektirebilir. Ayrı ortamlar, bu gereksinimlerin bir bağımlılık çekişmesine dönüşmesini önler.

Barındırılan not defterleri, sanalizasyonun önemli olduğu bir diğer yerdir. Colab gibi platformlarda Jupyter çalıştırdığınızda, not defteri başkası tarafından yönetilen bir altyapı içinde yürütülür. Bu bağlamı anlamak, kaynak sınırlarını, yeniden başlatmaları ve dosya sistemi davranışını daha az gizemli kılar.

Kurumsal ve bulut

Bulut sağlayıcıları sanalizasyonu devasa ölçekte çalıştırır. İşleri, farklı müşteri iş yüklerini paylaşılan filolara verimli şekilde sığdırmaya ve izolasyon sınırlarını sağlam tutmaya bağlıdır.

Kuruluşlar aynı oyunu konsolidasyon ve miras uyumluluk için uygular. Daha eski bir uygulamayı sanallaştırmak, orijinal sunucusu ömrünü doldurduktan çok sonra bile modern donanım üzerinde çalışmasını sağlayabilir.

Hibrit kurulumlar için, AWS Outposts gibi hizmetler vardır; çünkü kuruluşlar bazı iş yüklerini kendi tesislerine daha yakın çalıştırırken de bulut benzeri modeller ister.

Öğrenme ve deney

Sanalizasyon, öğrenme için en güvenli ortamlardan biri olmaya devam eder. Bir Linux VM çalıştırabilir, özgürce deney yapabilir, bozabilir, bir anlık görüntüye dönebilir veya birincil sisteminize dokunmadan tamamen silebilirsiniz.

Ayrıca tek bir makinede çok hizmetli sistemleri simüle etmek için de faydalıdır: bir web katmanı, bir uygulama katmanı ve sanal ağlar üzerinden iletişim kuran bir veritabanı katmanı—kavramsal öğrenme için yeterli gerçekçilik, üstelik bir bulut faturası olmadan.

Sanalizasyonun Yönü

Önümüzdeki birkaç yıl içinde ekiplerin sanalizasyonu kullanım şeklini şekillendiren birkaç eğilim var.

Uç bilişim (edge computing) daha fazla iş yükünü verinin üretildiği yere yaklaştırır. Hafif VM’ler ve konteynerler, dağıtık konumlar arasında dağıtımı standartlaştırmaya yardımcı olur; ancak uçta filoları yönetmek kendi karmaşıklığını getirir.

Daha akıllı kaynak yönetimi olgunlaşmaya devam ediyor. Platformlar, doğru boyutlandırmayı giderek daha fazla otomatikleştiriyor, iş yüklerini daha agresif yeniden dengeliyor ve özellikle el ayarının ölçeklenmediği ortamlarda israfı daha hızlı ortaya çıkarıyor.

Son olarak, hibrit yığınlar norm haline geliyor. Kubernetes, birçok ortamda konteyner orkestrasyonuna hakim ve “VM’ler içinde konteynerler” yaygın bir üretim kalıbı olmaya devam ediyor: altyapı katmanında VM izolasyonu, uygulama katmanında konteyner esnekliği. Introduction to Kubernetes temel bilgileri kapsar.

Sonuç

Sanalizasyon, modern altyapıyı ölçekli olarak pratik kılan şeydir: tek bir fiziksel ana bilgisayarı, rafa dokunmadan oluşturulabilen, yeniden boyutlandırılabilen, taşınabilen ve emekliye ayrılabilen izole ortamlara böler. 

Biz veri insanları için bu arka plan bilgisi değildir. Tekrarlanabilir ortamlarda, projeler arasındaki bağımlılık çatışmalarında ve altta yönetilen bir çalışma zamanı olduğunu hatırladığınızda daha anlamlı hale gelen küçük “bu not defteri neden yeniden başladı?” anlarında karşımıza çıkar.

Kavramları kalıcı kılmanın en hızlı yolu küçük bir laboratuvar kurmaktır. Bir Tip 2 hipervizör kurun, bir Linux VM oluşturun, bir anlık görüntü alın, bilerek bir şeyi bozun ve geri alın. Ardından benzer bir iş yükünü bir konteynerde çalıştırın ve nelerin değiştiğini karşılaştırın: başlatma süresi, kaynak ayak izi ve her durumda “izolasyon”un gerçekte ne anlama geldiği.

Öğrenmeye devam etmenize yardımcı olacak iyi kaynaklarımız var:

• Containerization and Virtualization Concepts (uygulamalı temel)
• Introduction to Docker (pratikte konteynerler)
• Containerization and Virtualization with Docker and Kubernetes (öğrenim yolu, temeller → orkestrasyon)