Windows Server 2016 Containers – Bölüm 1 – Giriş, Kavramlar ve Mimari
Microsoft’un yeni nesil işletim sisteminin Windows Server 2016, 26-30 Eylül 2016 tarihleri arasında Atlanta’da düzenlenecek Ignite konferansında resmi lansmanının yapılacağı duyuruldu. Bu konudaki detayları bu linkten öğrenebilirsiniz. Buluta entegre sunucu işletim sistemi Windows Server 2016 ile kurumların BT olarak iş servislerine verdikleri hizmetleri ve katma-değeri daha da güçlendirecek, altyapı mimarisinde veri merkezi dönüşümünüzü hızlandıracak, genel ve özel bulut altyapılarını daha da güçlendirecek çok sayıda yenilik geliyor. Bu yeniliklerle birlikte yeni güvenlik katmanları ve servisleri ile güvenli mimarisini de daha sağlam ve güvenilir kılan innovasyonlar geliyor.
Son olarak Nisan sonunda yayınlanan “Windows Server 2016 Technical Preview 5” sürümüne ait ISO ya da VHD paketini bu linkten indirerek testlerinize başlayabilirsiniz. Daha önce Windows Server 2016 ile ilgili olarak yayınlamış olduğumuz aşağıdaki makaleleri de inceleyebilirsiniz:
http://www.cozumpark.com/blogs/windows_server/archive/2015/06/21/windows-server-nano-bolum-1.aspx
http://www.cozumpark.com/blogs/windows_server/archive/2015/06/21/windows-server-nano-bolum-2.aspx
Günümüzde çok klişelmiş ve hemen hemen çoğu geliştirme ortamında yaşanan bir vaka örneği ile başlayalım. Yazılım departmanında bir developer tarafından geliştirilen bir uygulama BT departmanına altında yer alan sistem operasyon birimine bir sunucuya konumlandırılması için verilir. Sistem operasyon departmanı bunu sunucuya atar ve çoğu zamanda çeşitli uygulama, işletim sistemi ya da eklenti vb. eksikliklerden dolayı ilk anda çalışmaz. Bu durumda ya yazılımcının paketi bu eksiklikleri de giderecek şekilde yenilemesi ya da sunucuya bunların tamamını tespit ederek kurulmasını sağlaması ya da kendisinin kurması gibi durumlarla karşılaşırız. İşte container teknolojisi sayesinde geliştiriciler sahip oldukları container içerisinde (user-mod) her türlü eklenti, uygulama, rol, kütüphane vb. kurulumlarını yapıp, bunları da bir imaj olarak kaydettiklerinde diğer birimlere bağımlı olmadan kendileri uygulamayı test etmeye başlayabilirler. Her container kendi dosya sistemi, registry ve ağ adreslerine sahiptir. Bu senaryoları çoğaltmak mümkün. Container teknolojisi geliştirme ekiplerinin uygulamayı devreye alma süreçlerini hızlandırırken, altyapıda da önemli oranda yönetim, disk alanı, operasyonel faaliyetlerde de tasarrufu sağlamış olacak. Bu ve benzeri katma-değer yaratan avantajları ile gelen container teknolojisini incelemeye başladığımız bu ilk bölümde container teknolojisine giriş yapıp, geleneksel sanal sunucu sanallaştırma teknolojilerinden farklılıklarını ve Container sanallaştırma ile ilgili teknik kavramları ve mimari bileşenleri inceliyoruz. İlerleyen makalelerde de container çeşitleri, kullanım alanlarını ve uygulama senaryolarından örnekleri paylaşıp, Windows Server 2016 ile container yönetimine ilişkin adım adım uygulamaları gerçekleştirmeyi hedefliyoruz.
Bugüne Nasıl Geldik?
Container esasında işletim-sistemi seviyesinde yeni bir sanallaştırma teknolojisi. Sanallaştırma farklı alanlarda farklı ihtiyaçlar için geliştirilmiş çözümlere sahip bir teknoloji. Dolayısıyla container konusuna geçmeden önce, biraz nostalji tadında çok da geriye gitmeden bu noktaya gelene kadar özellikle son 20-25 yıl içerisinde veri merkezi dönüşümünde geçilen evreleri, fiziksel sunuculardan sanallaştırma teknolojilerine geçişi biraz bandı geriye sararak kısaca hatırlayalım isterseniz.
İlk önce fiziksel sunucularla başladık. Şirketinizin iş alanı ile ilgili bir servisi gerek şirket içi kullanıma gerekse de dış dünyaya açmak için yapmamız gereken ilk iş o servise dedike bir sunucu tedarik etmekti. Dolayısıyla sahip olduğunuz servis çeşitliliği ne kadar fazla ise o oranda fiziksel sunucu parkı kapasitesini de genişletmeniz gerekiyordu. Her fiziksel sunucu için yer, güç, soğutma, ağ, depolama, elektrik, yedekleme, yönetim ve bakım maliyetleri de bütçeden önemli oranda kaynak ayırmak anlamına geliyordu. Ve fiziksel bir sunucunun tedarik edilmesi de uzun satın alma süreçlerini de göz önünde bulundurduğumuzda bazen haftalar hatta aylar alabiliyordu. Eğer sunucuyu kendiniz satın almak istemiyorsanız da bir servis sağlayıcı organizasyonunun veri merkezinde sunucu kiralama yöntemine de gidebiliyorduk. Fiziksel sunucu tedariği sonrasında ise, sunucu üzerine uygun işletim sisteminin kurulumu, yama paketlerinin yüklenmesi, en iyi yapılandırma adımlarının uygulanması, kurumsal standartlarınıza göre sunucu üzerinde özel ayarların etkinleştirilmesi sonrasında, sıra servis vereceğiniz uygulamanın sunucu üzerine yüklenmesine geliyordu. Uygulama kurulumu sonrasında da test, kalite ve kontrol süreçleri, sorunların giderilmesi vb. aşamalardan sonra uygulamamızı canlıya almış oluyorduk. Bu süreçler organizasyon yapısına, projenin çeşidine, ekibin yetkinliğine vb. daha birçok değişlken parametreye göre bazen hızlı ilerlerken, bazen de haftalar, aylar alabiliyordu. Kısaca bahsettiğimiz bu süreci her yeni uygulamayı canlıya almak için tekrar etmeniz gerekiyordu. Tabi dönem itibariyle servis çeşitliliği günümüzdeki kadar büyük silolara sahip değildi.
Veri merkezi endüstrisinde en önemli ikinci dönüşüm dönemi esasında donanım sanallaştırma ile başladı. Bugünkü geldiğimiz noktanın temelleri de bu şekilde atılmış oldu. Donanım sanallaştırma teknolojisi temelleri bilgi edindiğimiz kaynaklara göre 1960’lı yıllara dayanan, mainframe bilgisayarlar üzerinde sistem kaynaklarını farklı uygulamalar arasında mantıksal olarak bölümlemek amacıyla kullanılan bir teknoloji. Günümüzde donanım sanallaştırma özellikle iki alanda yoğun biçimde kullanılıyor:
Sunucu Sanallaştırma (Server Virtualization)
Masaüstü Sanallaştırma (Desktop Virtualization)
Not : Konuyu çok fazla dağıtmamak için diğer sanallaştırma teknolojilerine şimdilik girmek istemiyorum.
Sunucu sanallaştırma teknolojileri (x86 server virtualization) 2002 yılı ile başlayıp, kısa süre içerisinde hızla yaygınlaşarak, veri merkezlerinde büyük bir dönüşümü gerçekleştirdi. Gartner tarafından yayınlanan bir rapora göre 2016 yılı itibariyle dünyada sunucu sanallaştırma oranı ortalama yüzde 75’in üzerine çıkmış durumda. Bu pazarda da lider olarak Microsoft ve Vmware liderler kadranında. Sunucu sanallaştırma teknoloji altyapısı sayesinde bir servisi ya da uygulamayı devreye alma süresi eskisiyle kıyaslanmayacak oranda kısaltılmış oldu. Artık aynı gün içerisinde talep edilen sunucu üzerinde uygulamaları hızlı bir biçimde etkinleştirmek mümkün.
Veri merkezi endüstrisinde üçüncü dönüşüm dönemi bulut bilişim teknolojileri ile devam etti. Belli bir olgunluğa ulaşan sunucu sanallaştırma altyapısı üzerine bulut servisleri, yönetim araçları, otomasyon süreçleri de eklenince artık dakikalar içerisinde istediğiniz sunuculara sahip olmak mümkün hale geldi. Ayrıca bulut bilişim altyapılarının sahip olduğu karakteristik özellikleri olan; yatayda ve dikeyde ölçeklenebilirlik, yüksek erişilebilirlik, ihtiyaç anına hazır kaynak havuzları (CPU, RAM, disk vb.), kullandığın kadar ödeme kolaylığı, kendi kendine servis alabilme yetenekleri ile veri merkezlerini çok daha dinamik, ekonomik ve çevik bir yapıya dönüştürmüş oldu. Olaya sadece sanal sunucu açısından bakarsak, aslında sunucu sanallaştırmanın üzerine otomasyon, self servis portal gibi kolaylıklar gelmiş oldu. Bulut bilişim akımı ile şirketlerin hem kendi veri merkezlerinde özel bulut ortamlarını inşa etmeleri, hem de genel bulut servis sağlayıcılarınının platformlarını kullanarak daha dinamik bir iş yapış biçimine dönüşüm sağlanmış oldu. Bu kadar kolaylıkları getirmesine rağmen, günümüz iş yaşamının ve ihtiyaçların gerektirdiği ve talep edilen hız ve çevikliğe henüz ulaşılmış değil. Buraya kadarki adımları genel hatlarıyla maddeler halinde küçük adımlara bölersek oluşan özet durumu aşağıda görmektesiniz:
|
1 |
Fiziksel Sunucu Tedarik Edilmesi ya da Kiralanması |
|
2 |
İşletim Sistemi Kurulumu ve Yapılandırılması |
|
3 |
Yama Paketlerinin Geçilmesi |
|
4 |
Uygulamaların Kurulumu ve Yapılandırılması |
|
5 |
Test ve Kontrol Süreçleri |
|
6 |
Üretim Ortamına Alınması |
|
1 |
Sanal Sunucu Talebi ve Onay Süreci |
|
2 |
Uygulamaların Kurulumu ve Yapılandırılması* |
|
3 |
Sanal Sunucu Provizyonlama Süreci |
|
4 |
Test ve Kontrol Süreçleri |
|
5 |
Üretim Ortamına Alınması |
*: İstenen uygulama sunucu imajı içerisinde mevcutsa, bu süreç pas geçiliyor.
|
Bulut Ortamında Uygulamaların Üretime Alınması |
|
|
1 |
Sanal Sunucu Provizyonlama |
|
2 |
Uygulamaların Kurulumu ve Yapılandırılması* |
|
3 |
Test ve Kontrol Süreçleri |
|
4 |
Üretim Ortamına Alınması |
*: İstenen uygulama sunucu imajı içerisinde mevcutsa, bu süreç pas geçiliyor.
Dikkat ederseniz her dönüşümde süreç adımları daha da optimize edilerek, daha dinamik ve çevik bir yapıya kavuşmanın yanında ekonomik olarak da maliyetler daha da düşürülmüş durumda. Fakat bu nokta da beklentileri karşılamıyor. Neden? Çünkü:
Sanal sunucular için işletim sistemi yönetimi devam ediyor. Container’larda böyle bir gereksinim ortadan kalkıyor.
Sanal sunucular için işletim sistemi izleme ve bakım faaliyetleri devam ediyor.
Sanal sunucular üzerinde gerekli durumlarda işletim sistemini yeniden başlatma, dolayısıyla servis kesintileri yani iş kaybı devam ediyor. İşletim sisteminin başlatılması ve servislerin ayağa kalkması hala önemli bir süre alabiliyor.
Container mimarisinde ise container’lar tarafından ortak kullanılan container host işletim sistemi kernel’ı sürekli çalışır durumda olduğu için, sunucunun kapanıp, açılma gibi bir süreç ortadan kalkmış olacak.
Sanal sunucunun provizyonlanma süreci dakikalar içerisinde gerçekleşse de toplamda önemli bir zaman alıyor. Container imajları ise saniyeler içerisinde etkin olarak kullanılmaya başlanabilir.
Sanal sunucular üzerine hala uygulama kurulum ve yapılandırmaları önemli bir zaman alıyor.
Özellikle geliştirme ve test ortamları için ihtiyaç duyulan ortamın hazırlanması ve depolama, işlemci, bellek vb. kapasite ihtiyacı önemli bir engel teşkil ediyor. Yüksek kapasiteli ortamları kısa sürede hazır hale getirmek hem çok zor
hem de bazen kurumların kendi veri merkezlerinde çok mümkün olmayabiliyor.
İşte bu beklentileri daha da üst seviyelere çıkaracak, veri merkezi alt yapılarını bugünden daha çevik, dinamik ve güçlü hale getirecek, servis kesintisinin en aza indirgendiği, çoğu durumda hiç yaşatmayacak yeni bir dönem ve dönüşüm süreci başlıyor : “Containerization”
Container teknolojisi esasında Linux dünyasında 2000’li yıllarda temelleri atılmış bir süreçten geliyor. 2001 yılında Linux-Vserver çözümü ile başlayan çalışmalar daha sonraki yıllarda IBM, Oracle, Google, RedHAT vb. üreticilerin de katkıları ile gerçekleştirilen inovasyonlarla devam eder. 2008 yılında IBM mühendisleri tarafından hayata geçirilen LinuX Containers projesi ile kullanıcı deneyimi ve güvenlik testleri gibi alanlarla sürekli bir gelişim ve dönüşüm sürecinden geçer. 2013 yılında kurulan Docker projesi ile Linux Container alanında yeni bir dönem başlar. 2013 yılında RedHAT ile Docker organizasyonu önemli bir işbirliğine giderek, Red HAT OpenShift üzerinde container standardı olarak Docker’da karara varırlar. Her geçen yıl gelirlerini katlayarak container pazarında hızla büyüyen ve yeni satın almalarla kendini geliştiren Docker, 2014 Kasım itibariyle Microsoft ile iş ortaklığı kararını alır. Ve Microsoft ekosistemine container teknolojisinin de girişi bu adımla başlar. Docker tarafından Nisan 2015’de Windows işletim sistemi üzerinde çalışan Docker komut satırı arabirimi (CLI) çıkartıldı. Docker tarafından organize edilen ve dünyada container standartlarını belirlemek amacını taşıyan Open Container Initiative(OCI) konsorsiyumuna Temmuz 2015 itibariyle Microsoft da kurucu üye olarak dahil edilir. Ocak 2016 itibariyle Docker dünyada en popüler ve yaygın container yönetim sistemi. Docker’a alternatif olarak çıkan bir diğer container yönetim altyapısı Rocket(rkt).
Microsoft yeni nesil işletim sistemi Windows Server 2016 ile container desteğini getireceğini, “Windows Containers” adı ile duyurdu. Böylece Docker, Windows üzerinde Docker container’lar için yerleşik destek geliyor. Bu sayede Windows üzerinde Docker’ı çalıştırmak için sanal bir Linux sunucuya ihtiyaç kalmıyor, Windows native olarak bu desteği sağlıyor.
Geleneksel sunucu sanallaştırma mimarisi ile Container mimarisi birbirine benzer gibi görünse de esasında tamamen farklı iki teknolojidir.
Sunucu sanallaştırma teknolojisi; fiziksel sunucu üzerindeki CPU, RAM, Disk, Ağ Kartı vb. gibi donanımların sanallaştırılmasıdır. Container ise; işletim-sistemi seviyesinde sanallaştırma metodu olup, her uygulama için ayrı bir sanal sunucu gerektirmeden, aynı sanal ya da fiziksel sunucu üzerindeki işletim sistemi kernel yapısını ortak olarak kullanan ve birbirinden tamamen izole bir yapıda çalıştıran sanallaştırma teknolojisidir.
Windows işletim sistemi mimarisi “Kernel Mode (Çekirdek Modu)” ve “User Mode (Kullanıcı Modu)” olmak üzere iki önemli katmanda çalışır. Kernel Mod, işletim sistemi çekirdek komutlarının çalıştığı katmandır ve işletim sisteminin kalbinin attığı, korumalı ve güvenli tabakadır. Aygıt sürücüleri de yine bu katmanda çalışır. İşletim sistemi kendisi ayrıcalıklı işlemci modu olarak da isimlendirilen kernel mod katmanında çalışarak sistem verileri ve donanıma erişimi gerçekleştirir. User Mod ise, uygulamaların çalıştığı ve ayrıcalıksız işlemci modu olarak da isimlendirilen, sınırlı sayıda uygulama arabirimini kullanarak sistem verilerine ve işletim sistemi bileşenlerine erişimin sağlandığı katmandır. Kullanıcı modundan doğrudan donanım moduna erişim yapılamaz. Kullanıcı modunda çalışan bir uygulama ya da program bir sistem servisini çağırdığında, işlemci özel bir komut çalıştırarak istekte bulunan sistem parçacığını (thread) kernel moda aktarır. Sistem servisi görevini tamamladıktan sonra, işletim sistemi sistem parçacığının içeriğini kullanıcı moduna geri aktarak, çağrıda bulunan sıradaki işleme devam eder.
Container altyapısını kullanarak yazılım mimarilerinde çığır açacak gelişen bir diğer alan da mikroservisler(microservices). Container kullanımının yaygınlaşmasıyla, mikroservislerin kullanımı da artarak, standart web servislere göre çok daha hızlı çalışan ve küçük paket yapısı ile yazılım geliştirme mimarilerinin çevikliğini de artıracak bir teknoloji olacak. Container teknolojisinin yaygınlaşması ile birkaç yıl içerisinde sanal sunucular da yerini büyük oranda container teknolojisine bırakacağı tahmin ediliyor.
CONTAINER Mimarisini Oluşturan Bileşenler
Container Host : Windows Server Container özelliğinin (Windows Feature) kurulu olduğu ve üzerinde container nesnelerini barındıran fiziksel ya da sanal sunuculara “Container Host” adını veriyoruz.
Geleneceksel sunucu sanallaştırmada sanal sunucuları üzerinde barındıran Hypervisor katmanının kurulu olduğu fiziksel sistemlere “Server Virtualization Host” ya da Hyper-V Host gibi isimlendire yaparken, benzer şekilde container imajlarını barındıran sunucuları da “Container Host” olarak adlandırıyoruz.
Sanal olarak kullanılan container host sunucusu, VM Host olarak da isimlendirilir.
Sandbox : Container ilk oluşturulduktan sonra dosya sistemi değişiklikleri, registry düzenlemeleri ya da uygulama kurulumları vb. gibi tüm yazma aksiyonlarının gerçekleştiği katman “Sandbox” olarak adlandırılır.
Esasında container’ın ilk oluşma anındaki içi boş container gibi düşünebiliriz. Bütün ilave kurulum, ekleme ve yüklemeler bu sandbox içerisinde gerçekleşir.
Container İmaj : Sandbox içerisinde yapılan tüm değişiklikler tamamlandıktan sonra bunun kalıcı olarak saklandığı yeni container kopyasına “container imaj (container image)” adını veriyoruz. Container oluşturma sürecinde sandbox içerisinde yapılan tüm değişiklikler tamamlandıktan sonra, container kapatılır. Bu aşamadan sonra bunu kalıcı olarak saklamak istersek, container imajı olarak kaydediyoruz. İmaj olarak saklamak istemiyorsak da sandbox içeriği silinebilir. Örneğin; container oluşturmak için gelen temel (base) imajlardan “Windows Server Nano” imajı üzerinde bir container oluşturduğunuzu düşünelim. Bu container içerisine IIS rolünü yükledikten sonra bunu yeni bir container imajı olarak kaydettiğimizde Nano Server üzerinde IIS kurulu olan değişikliği içeren ve yeni oluşan bir container’a sahip olmuş oluyoruz. Oluşturulan bu yeni imaj baz alınarak üzerine örneğin; MySQL yapılandırarak, yeni bir container imajı daha oluşturulabilir. Oluşan bu imajlar container host üzerinde yerel olarak saklandığı gibi, merkezi bir repository içerisinde de saklanabilir. Böylelikle IIS üzerinde MySQL yapılandırılmış bir container imajına sahip birbirinden izole 8-10 adet sunucu ihtiyacı olduğunda son oluşturduğumuz container imajından yeni imajları dakikalar içerisinde devreye almak mümkün olacaktır.
Container Temel (Base) İşletim Sistemi İmajı : Container’lar oluşturulurken temel bir işletim sistemi imajı kullanılarak yaygınlaştırılırlar. Windows Server 2016 Core Server ve Windows Server 2016 Nano Server imajları bu amaçla tasarlanmış temel imajlardır.
Bu temel imajlar bir container yapısını oluşturan çok sayıda container imajının ilk katmanıdır ve container’lar için gerekli işletim sistemi ortamını sağlar. Container işletim sistemi temel imajı üzerinde değişiklik yapılamaz. Bu imajı kullanarak oluşturulan ilk container imajı içerisine istenen bileşenlerin, rollerin vb. yüklenmesi, geliştirmelerin yapılması sağlanır. Geleneksel uygulamalar için Windows Server Core imajı yaygın olarak kullanılırken, bulut tabanlı ortamlarda da Windows Server Nano kullanılır. Biz makale serimiz içerisinde her ikisinden de kullanım örneklerini inceliyor olacağız.
Container Repository : Her oluşturulan container imajı ilk oluşturma anında yerel imaj kütüphanesi (repository) içerisinde saklanır. Bu imajlar container host üzerinde yeni oluşturulacak container imajları için kullanılırlar. Yerel olarak oluşan bu container imajların merkezi olarak saklandığı yapılara da “container repository” adını veriyoruz.
Örneğin; DockerHub bulut servisi olarak hizmet veren yaygın bir repository örneğidir. Böylece oluşturulan imajların farklı ekipler, birimler ya da container host’lara arasından paylaşılması ve ihtiyacı olanın bu repository içerisinde ilgili imajı kendine indirerek kullanması sağlanmış olur. Bundan dolayı container repository aynı zamanda tekrarlı olarak kullanılabilir imajların kaydedildiği imaj deposudur.
Container Yönetim Araçları : Windows Server 2016 ile container bileşenlerinin yönetiminde iki önemli araç kullanıyoruz. Bunlar : PowerShell ve Docker.
Bu araçların her biri ile yeni container oluşturma, container imaj oluşturma ve uçtan uca container yaşam döngüsünün yönetimi yapılabilir. İlerleyen bölümlerde PowerShell ve Docker ile container yönetim adımlarını ayrıca inceliyor olacağız.
Windows Server Containers & Hyper-V Containers
Microsoft, yeni nesil bulut tabanlı işletim sistemi Windows Server 2016 ile bulut ve sanallaştırma ortamları için iki farklı container teknolojisini kullanıma sunuyor: Windows Containers ve Hyper-V Containers.
En çok sorulan sorulardan bir tanesi de ne zaman Windows Containers kullanmalıyım, ne zaman Hyper-V Containers kullanmalıyım şeklinde geliyor. Bu başlıkta da bu konuyu biraz açalım.
Windows Container’lar aynen Linux Container’ların kullanımına benzer şekilde kullanılan, hem fiziksel hem de sanal sunucular içerisinde oluşturulabilen container tipidir. Bu tip kullanımda aynı container host üzerinde oluşturulan container’lar ortak bir işletim sistemi kernel’ını paylaşarak kullanırken, birbirlerinden tamamen izole yapıda, user-mod katmanında çalışırlar. Her container’ın kendine ait dosya sistemi, registry kütüphanesi, üzerine kurulan uygulama kod kütüphanesi, işletim sistemi rol ve eklentileri bulunur.
Windows Container kullanımında her ne kadar birbirlerinden tamamen izole yapıda, user-mod katmanında çalışıyor olsa da, ortak bir kernel katmanını kullanıyorlar. Özellikle bir kurum ya kuruluşun kendi ortamı için ya da tek bir müşteriye hizmet veren bir ortam için bu sorun teşkil etmeyecektir. Fakat özellikle tamamen ayrı müşterilere hizmet veren, örneğin servis sağlayıcı gibi organizasyonlarda kötü niyetli bir müşteri ortak kullanılan Kernel katmanını kullanarak diğer container’lara saldırı yapmak isteyebilir. İşte bu tip durumlar için Windows Containers yerine Hyper-V Containers tercih edilebilir. Bu bir senaryo örneği.
İkinci bir senaryo olarak da işletim sistemi sürümü ve yama paketleri seviyesinden kaynaklı durumlarda Hyper-V Container kullanımı tercih edilebilir. Örneğin; Windows Server Nano container işletim sistemi üzerinde desteklenmeyen bir uygulama varsa bu durumda sanalda kurulu bir VM üzerine Windows Server Core işletim sistemi sürümü kurulup, bunun üzerinde de Hyper-V özelliği aktifleştirilerek container host işletim sisteminin (yani Kernel katmanının) tamamen izole bir yapıda kullanılması sağlanmış olur. Aynı işletim sistemi sürümü üzerinde farklı yama seviyelerinde sorun çıkaran uygulamalar varsa bunlar için de yine benzer şekilde sanalda ayrı bir Hyper-V Container bağımlılık ya da izolasyon sağlanmış olacaktır.
Windows Server 2016 işletim sistemi ile gelen “nested virtualization” desteği sayesinde artık sanal sunucu üzerinde “Hyper-V” rolünü etkinleştirebiliyoruz. Sanalda Hyper-V container kullanımının altında da bu yeni özellik bulunuyor. Esasında oluşturulan Hyper-V container içerisinde biz yine Windows Server Container kullanıyoruz. Tek fark Windows Server Container bir Hyper-V VM içerisinde çalışarak; kernel, işletim sistemi sürümü ve yama seviyesi izolasyonunu sağlamış oluyor. Container ilk oluşturulurken doğrudan bir Windows Containers içerisinde hazırlanıp, yaygınlaştırma anında Windows Server Container ya da Hyper-V Container’dan hangisi isteniyorsa onun üzerinde yayına alınabilir. Dolayısıyla container’ın hazırlandığı ortama bağımlılık da ortadan kalkmış oluyor. Ayrıca Windows Server Container üzerinde çalışan bir container Hyper-V container üzerine de sonradan taşınabilir. Bunun tersi de mümkün.
İLK BÖLÜMÜN SONU;
Evet, böylece Windows Server 2016 ile gelen ve sanallaştırmada yeni bir dönemi başlatacak “Container” mimarisini incelediğimiz makale serimizde ilk bölümü burda noktalıyoruz. Bu bölümde container teknolojisine giriş yapıp, geleneksel sanal sunucu sanallaştırma teknolojilerinden farklılıklarını ve container sanallaştırma ile ilgili teknik kavramları ve mimari bileşenleri, container çeşitlerini genel olarak inceledik. İlerleyen bölümlerde Windows Server 2016 ile container yönetimine ilişkin adım adım uygulamaları, container kullanım alanlarını ve özellikle DevOps kültürü açısından uygulama senaryolarından örnekleri paylaşmaya devam edeceğiz. Sağlıcakla kalın.
Mesut ALADAĞ
Microsoft MVP, MCT, P-TSP
www.mesutaladag.com | @mesutaladag
Elinize sağlık…