Arşiv

Posts Tagged ‘Photon’

234: PhotonOS üzerine docker-compose kurulumu

dockercompose0PhotonOS, tek bir konteyner çalıştırma stratejisi ile optimize edilmiş bir işletim sistemi, Docker Compose ise, birden fazla docker konteyner bileşenini içeren uygulamaları tanımlamak ve çalıştırmak için kullanılan bir araç. Dolayısı ile, VMware’ın CNA stratejisi içerisinde PhotonOS ile birlikte varsayılan olarak docker-compose aracının bulunmamasını normal karşılayabiliriz. Ancak test amaçlı veya bir takım özel senaryolar için docker-compose aracına ihtiyaç duyabiliriz, örnek olarak Harbor Projesi, PhotonOS üzerinde çalışır ve üzerinde docker-compose ile tanımlanmış altı adet konteyner bulunur.

Kurulum için aklımıza gelen ilk yöntem, PhotonOS’in standard paket yöneticisi tdnf olur. Ancak tdnf ile arama yaptığımızda, repolar içerisinde bulamayacağız.

dockercompose1

Bu noktada yapabileceğimiz, GitHub repoları üzerinden indirmek ve dosya seviyesinde gerekli işlemleri yapmak. Bu adım için sunucunun internet erişiminin olması gerekecektir.

curl -L “https://github.com/docker/compose/releases/download/1.9.0/docker-compose-$(uname -s)-$(uname -m)” -o /usr/local/bin/docker-compose

dockercompose2

Eğer sunucumuzun internet erişimi bulunmuyorsa, manuel olarak bu dosya indirilebilir ve ilgili alana scp yardımı ile kopyalayabiliriz. Bu aslında yukarıda yer alan curl komutunun manuel yolla işletilmesinden farklı birşey değildir.

Bu işlemlerden sonra docker-compose aracının beklendiği gibi çalıştığını görebileceğiz.

Kategoriler:VMware Etiketler:,

213: Kurumsal ortamlarda docker çalıştırmak

Kurumsal bir ortam içerisinde container yapılarından faydalanmak istediğiniz durumda, akla ilk gelen mantıklı çözüm lokal bir registry oluşturmak ve imajlarınızı buradan pull/push etmek olacaktır. Ancak bu yazıda, konuyu daha basitten alıp, ilerleyen zamanlarda bu entegrasyonlardan söz etmeyi planlıyorum.

Proxy tanımlamaları:

Kurumsal bir ortamda, docker hostlarımızın muhtemelen docker hub’a direk bir erişimi olmayacaktır, Bu yüzden ilk olarak docker servisi için proxy tanımı yapmamız gerekir. Aşağıdaki tanımlamalar, Photon OS için geçerli olacaktır ve farklı işletim sistemlerinde farklılık gösterebilir.

Öncelikle bu ekstra tanımlama için yeni bir klasör ve altında konfigürasyon dosyası oluşturulur.

mkdir /etc/systemd/system/docker.service.d
touch /etc/systemd/system/docker.service.d/http-proxy.conf
vi /etc/systemd/system/docker.service.d/http-proxy.conf

Dosya içerisine aşağıdaki satırlar eklenir.

[Service]
Environment=”HTTP_PROXY=http://username:password@proxy.domain.com:8080/”
Environment=”NO_PROXY=localhost,*.domain.com”

Dosya kaydedildikten sonra, docker servisi yeniden başlatılır.

systemctl daemon-reload
systemctl restart docker

Tanımladığımız environment parametrelerini aşağıdaki komut ile görebiliriz.

systemctl show –property Environment docker

Tarball olarak taşımak:

docker-portabilityAncak belirli senaryolarda proxy üzerinden bile public repository’lere erişim belirli kurumlar tarafından yasaklı olabilir. Bu durumda uygulayabileceğimiz tek çözüm, container yapılarının taşınabilirlik özelliklerinden faydalanmak.

Container yapılarının bir çok faydasını sayabiliriz ancak piyasa üzerinde bu karar popülarite kazanmasının başlıca sebeplerinde biri, portability ve mobility özelliklerinin üst düzeyde olması. Elbette VM’ler için de aynı şeyi söyleyebiliriz, bir VM’i export edip OVF formatı ile taşıyabilir ve istediğimiz yere import edebiliriz. Ancak bu GB’lar (hatta onlarca GB) mertebesinde olacaktır. Container imajlarının ayakizi çok daha küçük olduğundan (çoğu zaman MB mertebelerinde) dolayı çok daha kolay taşınabilir bir yapıları vardır. İmajların içerisinde de uygulamanın kendisi ile birlikte tüm bağımlılıkları da bulunduğundan dolayı, çalışırlılığından emin olabiliriz.

Bunu gerçekleştirebilmek için uygulanması gereken, docker hub erişimi olan bir sunucu üzerinde ilgili imajı pull etmek, sonra bu sunucu üzerinde tarball formatında export edip, aklınıza gelebilecek her hangi bir yöntem ile (USB, scp, vb) asıl docker host sunucunuza göndermek ve orada import edip çalıştırmak. Şimdi gerekli komutları listeleyelim;

Host1 -> docker pull vmware/powerclicore
Host1 -> docker save -o /tmp/PowerCliCore.tar vmware/powerclicore
Host1 -> scp /tmp/PowerCliCore.tar root@Host2:/tmp
Host2 -> docker load -i /tmp/PowerCliCore.tar
Host2 -> docker run –rm -it vmware/powerclicore

docker-portability2

Örnekte kullandığım powerclicore imajı yaklaşık 400MB idi ve bu bile bir çok imaj için büyük sayılabilecek bir boyut. Sonuç olarak, her hangi bir ortamda hazır oluşturulmuş bir imajı çalıştırmak istiyorsanız, size engel olabilecek çok fazla birşey yok. Keyfini çıkarın :)

 

Kategoriler:Docker, VMware Etiketler:,

209: PowerCLI ve çoklu platform desteği

powerclicoreVMworld 2016 sonrası yazılacak çok fazla konu var ancak neden bilmiyorum SDK takımının gerçekleştirdiklerinin bende hep ayrı bir yeri var. Keynote lansmanları esnasında, amiral gemisi olarak nitelendirebileceğimiz ürünlerin yanında yer bulmaya başlamaları da bir diğer gelişme. Bu yüzden bir önceki yazıda, kısaca kaldığımız yerden devam edeceğim. Asıl konuları da, yakın zamanda daha detaylı bir şekilde kaleme alacağım.

Yakın zamanda, Photon OS üzerinden bir docker container olarak powershell kullanabilir olduğumuzu görmüştük. Şimdi ise SDK takımı konuyu bir kademe ileriye taşıdı ve PowerCLI’ın core bileşenlerini de, hem Linux/MacOS üzerinde, hem de docker container olarak çalışabilir hale getirdi. Container olarak da, daha öncekilerinden farklı olarak, Ubuntu yerine Photon OS imajı kullanıldı.

Photon OS üzerinde aşağıdaki iki komutu kullanarak, hızlı bir şekilde, PowerCLI ortamını canlandırabilirsiniz.

docker pull vmware/powerclicore

docker run –rm -it –entrypoint=’/usr/bin/powershell’ vmware/powerclicore

Powershell ve beraberinde PowerCLI artık gerçek anlamla çoklu platform desteği sağlamış görünüyor ve aynı zamanda container ile taşınabilirlik özelliklerini. Windows, Linux, Mac OS, Docker, Photon OS…. Peki geriye ne kaldı? Belki mainframe :)

powerclicore2

Özelikle docker tarafını önemli buluyorum. Neden mi? Sadece farklı platformlarda bir scripti çalıştırmanın, evet, çok büyük bir esprisi yok. Ancak, normalde bir sunucu üzerinde silo halinde tutup çalıştırdığımız PowerCLI scriptlerin veya fonksiyonların, artık bir codebase içerisinde, bir event ile tetiklenip, beraberinde bir container oluşturup, çalışıp, sonuç üretip, işi bittikten sonra da container ile birlikte yok olan ve bu şekilde hem verimlilik hem de yönetilebilirlik avantajları getirecek bir nesile evrimleşmesi mümkün görünüyor. Elbette bunun için önümüzde daha zaman var ancak IT dünyasında zamanın nasıl hızlı geçebildiğini hepimiz iyi biliyoruz.

PowerCLICore lansmanı yapıldığında aklıma gelen bir diğer konu ise, bunu bir noktada VCSA veya vMA üzerinde görüp göremeyeceğimiz oldu ve bu konuyu vCenter Product Management ekibinden birisine sorma şansını yakaladım. Zannedersem biraz fazla gizli bilgi içerecek bir konu olduğundan net bir cevap alamadım ancak edindiğim izlenim olumluya yakın bir “neden olmasın” idi :)

Son olarak, paketlere fling sayfasından da erişebilirsiniz.

PowerCLI Core Fling

Kategoriler:Docker, VMware Etiketler:, ,

208: PhotonOS ile Powershell

11.10.2016 1 yorum

Bugün yazacağım konu kısa bir konu olacak ancak çarpışan dev galaksilerin açığa çıkardığı enerjinin maddeye dönüşmüş hali benzeri bir durum söz konusu ve bunu görmüş olmak bile insana heyecan veriyor. Konu, Linux kernele sahip minimal bir işletim sistemi (Photon OS) üzerinde docker container olarak Powershell çalıştırmak. 2001 yılında Steve Ballmer’ın Linux’u kanser olarak nitelendirdiği günlerden nerelere geldiğimizin net bir örneği.

Son dönemlerdeki Microsoft-Linux evliliği elbette Powershell ile sınırlı değil. DotNet, Visual Studio Core, hatta SQL sunucularının Linux versiyonlarını da göreceğiz. Diğer taraftan Ubuntu bash’ini de Windows 10 üzerinde çalıştırabilir durumdayız. Yani gerçek anlamda galaksiler çarpışıyor ve oluşacak olan görsel şölenin izlenmeye değer olacağını düşünüyorum.

Konumuza geri dönmek gerekirse, elimizde çalışan bir Photon OS ve docker servisi olduğunu varsayıyorum. Docker hub içerisinde arama yaptığımızda aslında birçok imajın hazırlanmış olduğunu görebiliriz.

powershell1

Hangi imajı kullanacağımızı seçtikten sonra aşağıdaki komut ile container olarak çalıştırabiliriz;

docker run -it centos/powershell

powershell2

Burada kullanılan powershell alpha versiyonu olacaktır (6.0.0-alpha.9). Elbette üretim ortamlarında kullanılmaya hazır değil ancak ileride neler yapabileceğimizin güzel bir göstergesi olduğunu düşünüyorum. Yakın zamanda Powershell yanında powerCLI’ın da hazırlanacağını biliyorum. Kim bilir, belki de Linux üzerinde Powershell desteğini ileride vCenter Appliance üzerinde de görürüz ve aşina olduğumuz powerCLI scriptlerini artık vCenter üzerinden tetikleyebilir noktaya geliriz.

 

 

Kategoriler:Docker, VMware Etiketler:, ,

207: PhotonOS docker güncellemeleri

docker-vmwarePhoton OS içerisinde docker güncellemelerinden bahsettiğimiz durumda aslında iki adet senaryodan bahsedebiliriz, container olarak çalışan uygulamalar ve docker servisinin kendisi.

Öncelikle docker servisine değinelim. Normal birçok Linux dağıtımında YUM (Yellowdog Updater, modified) kullanılır. Yum komut satırı üzerinden kullanılan, açık kaynak bir paket yönetim aracıdır ve RPM Package Manager kullanır. Bunun üzerine, Fedore 18 ile birlikte DNF (Dandified Yum) kullanılmaya başlandı. DNF, YUM’un yeni jenerasyon versiyonu olup, YUM’da yaşanan performans, kaynak yönetimi, yavaşlık gibi problemleri çözmek amacı ile geliştirildi. Photon OS üzerinde ise TDNF (Tiny DNF) kullanılmaktadır. TDNF, VMware tarafından geliştirilen, minimal Photon OS üzerinde varsayılan gelen, yum ile uyumlu, DNF’in sadeleştirilmiş bir versiyonudur, dolayısı ile çok daha düşük bir ayakizine sahiptir.

Aşağıdaki komutlar basit operasyonları gerçekleştirmeniz için yeterli olacaktır;

  • tdnf repolist: Kullanılan repository’leri listeler
  • tdnf list: Tüm paketleri listeler
  • tdnf check-update: Paketler içerisinde güncellenebilecek olanları listeler
  • tdnf update docker: Docker servisini günceller.

Docker servisinin güncellenmesinden sonra servisi aşağıdaki şekilde yeniden başlatır ve test edebiliriz.

  • systemctl daemon-reload: Sistem dosyalarının yeniden yüklenmesini sağlar.
  • systemctl restart docker: Docker servisini yeniden başlatır.
  • docker run hello-world: Servisin çalışır olduğunun en kolay yoldan testi.

docker-update

Diğer güncelleme noktası ise çalışan docker imajların güncellenmesidir. Docker imajları prensipte sabit (immutable) olması gerektiğinden dolayı, yum, dnf veya tdnf benzeri araçlar ile güncellenmesi tavsiye edilmez, bir anti-pattern olarak kabul edilir. Container uygulamaları, repository üzerinde yer alan güncel versiyonlarından “pull” edilir.

  • docker pull nginx
  • docker stop nginx-container
  • docker rm nginx-container
  • docker run –name nginx-updated-container -p 8080:80 -d nginx

Tüm imajları daha sofistike bir şekilde güncellemek istiyorsanız, aşağıdaki komut işinizi görecektir.

docker images | awk ‘/^REPOSITORY|\<none\>/ {next} {print $1}’ | xargs -n 1 docker pull

docker-update2

Kategoriler:Docker, VMware Etiketler:, ,

197: PhotonOS v1.0

Photon-1Geçen sene, özellikle VMworld 2015 sonrası, beni en çok etkileyen konular container ve CNA (cloud native apps) alanındaki gelişmeler olmuştu ve bu vizyonu kısaca kaleme almaya çalışmıştım (buradan erişebilirsiniz). Yakın zaman içerisinde de, VMware’ın 2015 Nisan ayında duyurusunu yaptığı, bu alandaki en önemli bileşenlerinden biri olan Photon OS’un GA sürümü yayınlandı. Photon OS, vSphere platformu için optimize edilmiş, açık kaynak, minimal bir ayak izine sahip olan ve üzerinde Docker, Rocket (rkt), Garden formatlarında container yapılarını çalıştırılabilen, Linux tabanlı bir sistemdir.

Photon’u vSphere platformunuzda çok basit bir şekilde ayağa kaldırabilirsiniz. Bunun için tek ihtiyacınız olan, GitHub üzerinden ister ISO formatında, ister OVA formatında gerekli bileşenleri indirip kurulumu gerçekleştirmek. Ben biraz daha açıklayıcı olabilmesi adına ISO formatını tercih edeceğim çünkü OVA ile hazır appliance kurulumu yapıldığından aradaki az sayıda olan adımı da göremeyeceğiz.

Öncelikle manuel bir sanal sunucu oluşturarak işe başlayabiliriz. Sanal sunucuyu oluştururken aşağıdaki değerleri kullandım. Bu arada CPU ve RAM kaynaklarının aslında üzerinde koşturulması planlanan container uygulamaları doğrultusunda şekillendirilmesi uygun olacaktır.

  • Disk alanı: 8GB ancak kuracağımız Photon tipine göre değişebilir
  • Compatibility: Hardware Level 11 (ESXi 6.0)
  • Guest OS Version: Other 3.x or later Linux (64-bit)
  • vCPU: 1
  • vRAM: 384 MB

Sonrasında ISO’yu sunucuya mount edip, kuruluma başlayabiliriz. Welcome page, license agreement ve disk formatlama ile ilgili kısımları geçersek, bize soracağı en önemli soru aşağıdaki olacaktır.

Photon-2

  • Photon Minimal: Üzerinde container çalıştırabilmek adına, Photon’un en düşük ayak izine sahip versiyonu (yaklaşık 60 MB). Bu sayede uygulamanız için hem en iyi performans sağlayanacak hem de en hızlı şekilde çoğaltabileceksiniz.
  • Photon Full: Container host runtime özellikleri haricinde, yeni uygulamalarınızı da paketlemenizi ve container olarak çalıştırabilmenizi sağlayan bileşenleri de içerir. Eğer amacınız test etmek veya yeni container uygulamaları oluşturmak ise uygun olacaktır. Yaklaşık 128 MB’lık bir ayak izine sahiptir.
  • Photon OSTree Host: OSTree, işletim sisteminin dosya yapısını, read-only bir şekilde ve versiyonlanabilir, merkezi bir yapı üzerinden dağıtımını ve sync edilmesini sağlayan bir mekanizmadır. Ne tam olarak bir paket dağıtım mekanizması ne de disk imajlarını yönetim şeklidir. İkisi arasında bir yerdedir. Burada da Photon’un OSTree mekanizmasını destekleyen client versiyonunun kurulumu hedeflenmektedir.
  • Photon OSTree Server: Oluşturulmuş Photon OSTree Host’lar için repository görevi görmek amacı ile oluşturulabilecek profildir.

Bu noktada Photon Full ile devam ediyorum. Sunucu adı ve root şifresi bilgilerini girdikten sonra kurulum başlayabilir. Full versiyonunun kurulumu tam olarak 172 saniye sürdü. Minimal versiyon ise çok çok daha hızlı olacaktır.

Photon-3

Varsayılan olarak, sunucu DHCP’den IP alması üzerine tasarlanmıştır, olması gereken de bu şekildedir. Ancak biz bu ilk örneğimizde statik IP ile devam ediyoruz. Bunun için tanımlamaları yapacağımız ayrı bir .network dosyası yaratabileceğimiz gibi, varolan /etc/systemd/network/10-dhcp-en.network dosyası güncelleyerek de ilerleyebiliriz. Kolay olması açısından, dosyayı aşağıdaki şekilde güncelliyorum.


[Match]
Name=eth0

[Network]
Address=192.168.0.2/24
Gateway=192.168.0.1
DNS=192.168.0.10
NTP=192.168.0.10

Sonrasında systemctl restart systemd-networkd komutu ile bu tanımın aktif olmasını sağlamalıyız. Servis yeniden başladığında .network uzantılı dosyaları alfabetik olarak tarayacak ve dosyalar içerisinde yazılmış “match” kuralları doğrultusunda ilgili interface’in tanımlamalarını yapacaktır. Bu dosyalar içerisinde yapabileceğiniz çok detaylı tanımlamalar için buradan bilgi alabilirsiniz.

Photon-4

Sistem üzerinde daha rahat çalışabilmek için root kullanıcısına SSH yetkisi vermek de anlamlı olacaktır. Bunun için, /etc/ssh/sshd_config dosyası içerisinde PermitRootLogin değerini yes olarak güncellemek ve SSH servisini yeniden başlatmak yeterli olacaktır.

Photon-5

Photon OS ile ilgili en temel gereksinimlerimizi karşıladığımıza göre, bu sunucu üzerinde hangi komutlar ile neler yapabiliriz, onlara kısaca bakalım ve şimdilik burada bırakalım.

Örnek docker komutları:

  • systemctl start docker: Docker servisini başlatır
  • systemctl enable docker: Docker servisinin sunucu ile başlamasını sağlar
  • docker images: Lokalde bulunan docker imajlarını listeler
  • docker run -d -p 80:80 vmwarecna/nginx: Arka planda yeni bir docker container başlatır
  • docker info: Container host sunucusunun bilgilerini listeler.
  • docker ps: Docker proseslerini listeler
  • docker stop <id>: Docker prosesini durdurur
Kategoriler:VMware Etiketler:, ,

179: Cloud Native Applications

25.10.2015 1 yorum

CloudNativeAppsKendinizi bundan 15 sene öncesinde düşünün, ancak evinizi taşırken hareket ettirme ihtiyacı hissettiğiniz “ağır ve hantal” PC’nizi bir dizüstü bilgisayar ile değiştirdiğiniz günleri ve duyduğunuz tarifsiz mutluluğu. Şimdi ise kim bir yere giderken “ağır ve hantal” dizüstü bilgisayarlarını taşımak ister, tablet ile her işi yapabilmek varken.

IT’nin, uygulamaları destekleme misyonunda kullandığı enstrumanlarda da aynı değişimi gözlemlemek mümkün, fiziksel sunuculardan sanal sunuculara geçişde olduğu gibi. Artık sanal sunucuların bile ağır ve hantal kabul edildiği, development yaşam döngülerinin son derece çevik olması gereken dönemlerdeyiz. İşte bu noktada, aslında uzun zamandır Unix dünyasında var olan ancak piyasanın yakın zamanlarda önemini farkedip endüstri standardı yapma yolunda hızla ilerlediği container teknolojisi devreye giriyor.

Peki nedir bu container? “Bir uygulamanın geliştirildiği platformdan başka bir platforma taşındığında aynı şekilde çalışacağından nasıl emin olabilirim?” sorusuna getirilen bir çözümdür, işletim sistemi seviyesinde farklı bir sanallaştırma katmanından faydalanarak. Aşina olduğumuz sunucu sanallaştırmada donanım ile işletim sistemi katmanları birbirinden soyutlanmıştır. Container teknolojisinde ise uygulama ile işletim sistemi (kernel) birbirinden soyutlanmakta. Linux platformunda bunu gerçekleştirmek için “namespace isolation” adı verilen bir teknik uygulanır. Bu teknik ile, her bir container için sanal bir namespace oluşturulur ve bu namespace ilgili uygulamanın çalışabilmesi için gerekli tüm dosyalar, network portları, çalışan prosesler gibi kaynakları barındırır. Bu şekilde bir container, başka bir container için oluşturulan namespace’e erişemez, böylelikle kendisi işletim sistemi üzerinde çalışan tek uygulama olarak düşünür. Verimliliği artırmak adına arka tarafta, bir takım işletim sistemi dosyaları, klasörleri ve servisleri namespace’ler arasında paylaştırılır. Bir container, bu paylaşılmış dosyalar üzerinde değişiklik yapmak istediğinde ise, bunu sadece kendi namespace’i içerisinde yapar. Linux/Docker tüm bunları UnionFS (union file systems) adını verdiği bir servis ile yapar.

Containers1

Sonuç olarak, aynı kernel’ı paylaşan ancak birbirlerinden bağımsız çalışan uygulamaları hayata geçirmek mümkün. Peki bu durum neden bu kadar önemli? Madde madde incelemeye çalışalım;

  • Düşük ayakizi: Bir VM’de bir uygulama çalıştırdığınızı varsayarsak, uygulamanın en iyi ihtimalde 20-30GB’lık bir ayakizi olacaktır. Container teknolojisinde ise bir uygulamanın ayakizi MB mertebelerine inebilecek.
  • Çok hızlı üretilebilme: Bir uygulamanın ayağa kalkması için işletim sisteminin ayağa kalkması zorunluluğundan sizi kurtarıp, saniye mertebesinde uygulamayı devreye alma imkanı sağlayabilecek. Özellikle uygulamanızda kapasite artışı ihtiyacı hissettiğinizde saniyeler içerisinde bu talebe cevap verebilecek.
  • Kolay yönetim: Özellikle troubleshoot sorununa vereceği net cevap; “Problem çözmekle uğraşma, yok et ve yeniden deploy et” olacak.
  • Daha verimli development: API destekli yönetim modülleri ile developer’lara esnek hareket etme imkanı sağlayacak ve dev ortamında geliştirilen  bir uygulamanın aynı şekilde SDLC sürecinde yer alan diğer ortamlarda çalışacağı da garanti edilebilecek.

Tüm bu avantajları düşündüğümüzde, piyasanın container teknolojilerine olan ilgisi artık daha anlaşılır hale geliyor. Şimdiden birçok teknoloji devi, bu teknolojiyi bünyesinde barındırmak için açık kaynak projelere çok ciddi destek vermeye başladı. Örneğin Microsoft, Windows Server 2016 Technical Preview 3 (TP3) ile Docker motorunu bünyesine eklemeye başladı. TP4 ile birlikte de Hyper-V container gelmesi bekleniyor.

Peki, VMware tarafında durum nedir? VMware’ın konu ile ilgili farklı yaklaşımları var.

vSphere Integrated Containers:

vSphere Integrated Containers (VIC), Docker Linux container yapısının esnekliği ve taşınabilirliği ile vSphere platformunun stabilite, izolasyon, yönetilebilirlik gibi özelliklerini bir araya getiren bir çözüm. Şu anda, o da Technical Preview seviyesinde.

[SCM]actwin,0,0,0,0;Zoom Player zplayer 9/2/2015 , 9:06:28 AM

Tüm avantajlarının yanı sıra, standard Docker çözümlerinde iki konu kritik noktaya ulaşıyor, biri güvenlik diğeri ise izlenebilirlik. Önce güvenlik konusunu ele alalım. Soru; eğer bir container üzerindeki uygulama ele geçirilirse ne olacağı? Ortak paylaşılan bileşenler, geri kalan container uygulamalarının da ele geçirilmesini çok zor kılmayacaktır. UnionFS bu konuda komple bir izolasyon sağlayamıyor. VMware bu sorunu, container yapısını 1:1 olacak şekilde düzenleyerek çözme niyetinde, yani eskisi gibi bir sunucu üzerinde bir uygulama çalıştırarak, ancak standard bir VM üzerinde değil, jeVM dediği (just enough VM) özel bir Linux kernel’i kullanarak. Bu platform’a PhotonOS ismi verildi ve yaklaşık 25MB’lık bir ayakizi ile çalışan, tamamen container çalıştırabilmek amacı ile optimize edilmiş, son derece verimli bir platform.

Şu ana kadar bahsettiklerimiz doğrultusunda, VMware, güvenlik konusunda yol katetmemizi sağlamış görünüyor, izolasyon konusunda en becerikli bileşenini araya sokarak yani hipervizörünü, hele bir de NSX ile entegre edersek. Ancak container mimarisinden beklenen çevikliği henüz göremedik. Burada da VMware, vSphere6 ile birlikte gelen instant clone (VM-Fork) özelliğini kullanmak niyetinde. Bu şekilde bir jeVM, instant clone özelliği ile anında fork edilip, üzerinde çalışan container uygulaması ayağa kaldırılıp devreye alınabilir. Buyrun size saniyeler içerisinde, çalışan uygulamanızın yeni bir instance’ı.

Containers5

İkinci konunun da izlenebilirlik olduğundan bahsetmiştik. Sanal platformda standard bir linux üzerinde container yapısının kullanıldığını düşünün. Bir troubleshoot durumunda, VMware adminleri bu yapı içerisinde hangi container uygulamasının probleme sebebiyet verdiğini bilemeyecek, developer ise hangi platform üzerine kod deploy ettiğini. Ancak VIC iki parti için de bu izlenebilirlik problemini ortadan kaldıracaktır.

Mimariyi anlatırken önemli bir bileşenden de bahsetmenin faydalı olacağını düşünüyorum; Virtual Container Host (VCH). Container servislerini kontrol etmeye yarayan, bir Docker API endpoint olarak tanımlayabiliriz. Normal bir Docker çözümünde bu katman işletim sistemi üzerinde bulunur. VIC’de ise bir VM’in ötesinde, resource pool yada dedicated host bu görevi görebilir.

Photon Platform:

VIC, halihazırda vSphere kullanan, normal uygulamalarının yanında container uygulamalarını da kullanmak isteyen firmalar için gayet kullanışlı bir yöntem. Ancak VMware, Photon Platform ile vSphere katmanını tamamen aradan çıkartarak ve ESXi katmanından elde ettiği tecrübe ile sadece container uygulamalarını çalıştırmak için optimize edilmiş bir katman (microvizör) ile önümüzdeki zamanlarda karşımıza çıkacak gibi görünüyor. Bu platform API-driven bir yapıda olacak ve yüksek oranda Docker, Mesos, Cloud Foundry, Kubernetes desteği olacak.

Containers3

Bu platformun iki adet bileşeni olacak. Bunlar;

  • Photon Machine: Docker container uygulamalarının direk olarak üzerinde çalıştırabileceği, yeni bir ESX Microvizör katmanı.
  • Photon Controller: Tüm bu platformu yönetecek, dağıtık bir yönetim katmanı.

İki yöntemi karşılaştırdığımızda aşağıdaki şekilde bir manzara karşımıza çıkıyor. Özetle, ihtiyacınız geleneksel VM’ler ile birlikte container yapısını da kullanmak ve container yapınız 100’ler ile ifade edilebilecek ölçeklerde ise VIC size daha uygun görünüyor. Ancak container uygulama sayınız 10 binler ile ölçülecek, hız ve çeviklik sizin birinci önceliğiniz olacak ise, Photon Platform size istediğinizi sunacaktır.

Containers4

Hangi yaklaşım belirlenirse belirlensin, container uygulamaları ve cloud native apps hızla hayatımıza giriyor. Şimdiden keyfini çıkarın :)

Kategoriler:VMware Etiketler:, ,
%d blogcu bunu beğendi: