Arşiv

Posts Tagged ‘VIC’

233: VICui plugin hakkında

VICui, vSphere Integrated Containers bünyesinde kurulan VCH’ların ve konteynerlerin, vSphere yöneticisine yönelik izlenebilirlik yeteneklerini artırmayı hedefleyen bir Web Client eklentisidir. Daha önceden klasör olarak indirmiş ve VCH kurulumlarında kullanmış olduğumuz vic klasörü içerisinde, plugin kurulumu ile ilgili paketler de yer almaktadır. Kurulum Windows tabanlı vCenter ile appliance tabanlı vCenter arasında farklılık gösterecektir. Ben kendi ortamım doğrultusunda, appliance tabanlı olan vCenter ile vic-machine olarak PhotonOS kullandığım senaryoyu kaleme alacağım.

Kurulumu gerçekleştirmeden önce kontrol etmemiz gereken önemli konu, vCenter appliance sunucusunun root kullanıcısının shell’inin bash olması gerektiğidir. Eğer varsayılan olarak appliancesh bırakılmış ise, SSH üzerinden gerçekleştirilecek erişim başarısız olacak ve işlem devam edemeyecektir. Bunu değiştirmek için, vCenter sunucusu üzerinde SSH yapıldıktan sonra aşağıdaki komutlar çalıştırılır;

shell.set –enabled true
shell
chsh -s /bin/bash root

İşlem bittikten sonra ise eğer isterseniz aşağıdaki komut ile varsayılan shell’e dönebilirsiniz.

chsh -s /bin/appliancesh root

Gerekli önkoşulu sağladıktan sonra kurulum kısmına geçebiliriz. Vic-machine olarak tanımladığımız sunucuda, vic klasörü altında yer alan kurulum paketleri arasında bulunan konfigürasyon dosyasına, vCenter sunucusunun bilgisini yazmamız gerekecektir. IP kısmı zorunlu, diğer parametreler opsiyoneldir. Aşağıda bunun örneğini görebilirsiniz.

vicpluginSonrasında aşağıdaki komut dizilimi ile install.sh scriptini çalıştırılır. Öncelikle install.sh scriptinin çalıştırılabilir olması gerekmektedir. Bu script kendi içerisinde de vic-ui-linux.sh scriptini çağırır, bu yüzden bu scriptin de yetkilerinin düzenlenmesi gerekir, yoksa yetki hatası sonucu işlem yarıda kalacaktır.

chmod +x install.sh
chmod +x ../../vic-ui-linux.sh
./install.sh

Scripti çalıştırdıktan sonra aşağıdaki gibi bir çıktı ile karşılaşmayı bekleyebiliriz.

vicplugin2

Bu kurulum işlemi esnasında bizden üç kere şifre girmemizi isteyecektir;

  • Bash’in açık olup olmadığını test etmek için, eğer bash shell açık değilse kurulum devam etmeyecektir.
  • SSH üzerinden gerekli dosyaları kopyalamak için.
    • Kaynak klasör: /root/vic/ui/vsphere-client-serenity/
    • Hedef klasör: /etc/vmware/vsphere-client/vc-packages/
  • Dosya ve klasörlerin yetkilerinin düzenlenmesi için.

Bu adımları başarılı geçtikten sonra com.vmware.vicui.Vicui isimli bir eklentinin eklenmiş olduğunu göreceğiz.

vicplugin4

Web Client tarafında ise farkettiğim, VIC’in daha önceki beta versiyonlarında daha zengin ve bilgilendirici bir arayüzün bizlerle birlikte olduğu idi, 2015 yılında yayınlanan bu makalede görüldüğü gibi. Güncel versiyon olan 0.8.0 versiyonunda karşılaştığım durum ise, VCH endpoint VM ve konteyner VM’lere tıkladığımızda, özet sayfasında bir portlet vasıtası ile bize ekstra bilgiler sunması. Ancak yeni VCH oluşturmak gibi opsiyonları göremedim.

vicplugin3

Kategoriler:VMware Etiketler:,

232: VCH ve docker entegrasyonu

En son VIC-Engine yapısından ve temel bileşeni olan Virtual Container Host’dan (VCH) bahsetmiştik. Tekrar etmek gerekirse VCH, vSphere platformu üzerinde konteynerlerin yaşam döngülerini yönetmeyi amaçlayan araçları ve sistem kaynaklarını (CPU ve bellek gibi) barındıran mantıksal bir yapıdır. Aynı zamanda, kullanıcılara Docker API erişimi sağlar ve Docker Hub üzerinden imajların yönetimine izin verir (VCH detayları için lütfen tıklayın).

Bir vSphere kümesi üzerinde, örnek olarak aşağıdaki komut dizilimi ile bir VCH oluşturabiliriz. Bu komut sonrasında ilgili kaynak havuzu içerisinde bir vApp oluşacak ve bu vApp içerisinde bir adet appliance VM konumlandırılacak (VCH endpoint VM).


./vic-machine-linux create \
--name=democvh01 \
--target=demovc.demo.local/DEMO.Datacenter \
--thumbprint="E6:C9:E2:6E:90:9D:DB:5B:48:AA:F6:F6:0E:5D:16:16:4E:52:32:D7" \
--user=orcunuso \
--ops-user=svcvic \
--ops-password=Password! \
--compute-resource=DEMO.Cluster/DEMO.Vic \
--image-store=VMFS01/VCH/demovch \
--volume-store=VMFS01/VCH/demovch:default \
--bridge-network=DPG.Vlan200 \
--public-network=DPG.Vlan100 \
--client-network=DPG.Vlan100 \
--management-network=DPG.Vlan100 \
--dns-server=10.1.94.10 \
--public-network-ip=10.1.93.24 \
--public-network-gateway=10.1.93.1/24 \
--bridge-network-range=172.16.0.0/12 \
--appliance-cpu=2 \
--appliance-memory=4096 \
--registry-ca=/root/vic/ca.crt \
--tls-cname=demovch01.demo.local \
--certificate-key-size=2048 \
--organization=DEMO \
--no-tlsverify

Kullandığım parametreleri detaylandırmak gerekirse;

Satır 2: Kurulacak VCH ismi
Satır 3: Hedef vCenter ve datacenter bilgisi
Satır 4: Hedef vCenter SSL sertifika parmak izi
Satır 5: Kurulumu yapacak kullanıcının ismi. Şifreyi kurulum esnasında soracaktır ancak eğer istersek –password parametresi ile de belirtebiliriz.
Satır 6-7: vSphere üzerinde VCH operasyonlarını yapacak kullanıcı adı ve şifresi
Satır 8: Hedef küme ve resource pool bilgisi
Satır 9: Konteyner imaj ve VM dosyalarının saklanacağı alan
Satır 10: Persistent volume oluşturulacaksa, bunların saklanacağı alan
Satır 11: Bridge network olarak kullanılacak portgroup bilgisi. Bridge network, konteyner VM’lerin kendi aralarında ve VCH VM ile konuşabilecekleri özel bir L2 network olmalıdır.
Satır 12: Public network olarak kullanılacak portgroup bilgisi. Public network, konteyner VM’lerin dış dünya ile iletişim kurdukları network. Eğer port mapping kullanılıyorsa, ilgili portun expose edildiği arayüzdür.
Satır 13: Client network olarak kullanılacak portgroup bilgisi. Client network, Docker istemcilerinin API komutlarını yönlendirdikleri networkdür.
Satır 14: Management network olarak kullanılacak portgroup bilgisi. Management network, VCH’ın vCenter ve ESXi sunucular ile konuştuğu networkdür.
Satır 15-17: VCH endpoint VM için yaptığımız network konfigürasyonu. DHCP kullanıyorsak gerek duymayabiliriz.
Satır 18: Bridge network için tercih ettiğimiz IP subnet’i.
Satır 19-20: VCH endpoint VM için tanımlayabileceğimiz kaynak değerleri.
Satır 21: İçeride kullandığımız registry sunucusunun SSL sertifikası.
Satır 22: VCH için oluşturulacak sertifikanın cname bilgisi
Satır 23: VCH için oluşturulacak sertifikanın anahtar boyutu
Satır 24: VCH için oluşturulacak sertifikanın organizasyon bilgisi
Satır 25: İstemci erişimleri için TLS doğrulamasının zorunlu tutulmaması.

vCenter ortamımızda bulunan VCH’ları listelemek veya silmek istersek de, aşağıdaki komut dizilimlerini kullanabiliriz.


./vic-machine-linux ls \
--target=demovc.demo.local \
--thumbprint="E6:C9:E2:6E:90:9D:DB:5B:48:AA:F6:F6:0E:5D:16:16:4E:52:32:D7" \
--user=orcunuso

./vic-machine-linux delete \
--target=demovc.demo.local/DEMO.Datacenter \
--thumbprint="E6:C9:E2:6E:90:9D:DB:5B:48:AA:F6:F6:0E:5D:16:16:4E:52:32:D7" \
--name=demovch \
--compute-resource=DEMO.Cluster/DEMO.Vic \
--user=orcunuso \
--force

Temel olarak VCH ile neler yapabileceğimizi gördük, şimdi ise docker API endpoint olarak neler yapabileceğimize bakalım. Aslında temelde kullandığımız docker remote API komutlarından farklı bir komut kullanmayacağız. Aşağıdaki örnekteki gibi, çalıştıracağımız komutlara aynı cevapları verecektir. TLS üzerinden erişim sağladığımızdan dolayı 2376 portunu kullanıyoruz. Eğer –no-tls parametresi ile oluşturmuş olsaydık, 2375 portunu kullanmamız gerekecekti.

docker -H demovch01.demo.local:2376 –tls info

virtualcontainerhost1

Burada dikkat çeken nokta, toplam bellek ve CPU kapasitesinin kümenin toplamına eşit olması. Eğer VCH bazında kısıtlamak istersek (ki multi-tenant bir yapıda anlamlı olabilir), vApp seviyesinde limit tanımlamamız, bu maksimum değerlerin değişmesini tetikleyecektir.

Şimdi de bir adet konteyner çalıştıralım. Bu arada her komut için -H parametresini kullanmak istemeyebiliriz, bunun için ortam değişkeni tanımlamak işimizi kolaylaştıracaktır.

export DOCKER_HOST=demovch01.demo.local:2376
docker –tls run –name Nginx_Konteyner -d -p 8080:80 \
demoharbor.demo.local/library/vmnginx:1.0

virtualcontainerhost2

Bu örnekte, nginx imajını daha önceden 1.0 etiketi ile göndermiş olduğum harbor registry sunucusundan çağırdım. Arka planda gerçekleştirilen ise, vApp içerisinde, PhotonOS temelli bir işletim sisteminin, vic dosyaları içerisinde daha önceden gördüğümüz bootstrap.iso isimli liveCD imajı ile açılması ve üzerinde nginx imajının ayağa kaldırılması oldu. Network erişimi, bridge network olarak tanımladığımız portgroup üzerinden port mapping şeklinde gerçekleşti, yani VCH endpoint VM’e 8080 portundan gelen trafiğin 172’li network üzerinden bu konteyner sunucusunun 80 portuna yönlendirilmesi şeklinde. İçeriden dışarıya olan erişim ise, yine VCH sunucusunun public arayüzü üzerinden SNAT (Source NAT) yapılarak gerçekleşecek. vCenter üzerindeki görüntüsü ise aşağıdaki gibi olacaktır.

virtualcontainerhost3

Son olarak, oluşturduğumuz VCH, bize web tabanlı bir arayüz de sunmaktadır. VCH sunucusuna bir tarayıcı üzerinden 2378 portu ile erişip temel sağlık bilgilerine ve loglara ulaşabiliriz.

Günün sonunda VIC ile, standard bir docker host üzerinde gerçekleştirilebilecek hemen hemen tüm işlemlerin, çok benzer mantıklar ile vSphere katmanına uyarlanmış olduğunu görebiliyoruz.

Kategoriler:VMware Etiketler:,

231: VIC-engine ve Virtual Container Host kurulumu

07.01.2017 1 yorum

Şu ana kadar genel olarak VIC (vSphere Integrated Containers) stratevic0jisinden ve özel bir registry hizmeti veren Harbor uygulamasından bahsettik. Şimdi ise işin asıl gerçekleştiği katmandan yani VICE (VIC-Engine) katmanından bahsedelim.

VICE, vSphere özelinde oluşturulmuş bir konteyner çalıştırma platformudur, yazılım geliştiriciler aşina oldukları docker komutları ile konteyner oluşturma ve paketleme yapabilir ve vSphere platformu üzerinde çalıştırabilirler. Bu yapının getirdiği en büyük avantaj, vSphere ortamının sahip olduğu HA, DRS, yedekleme, izleme, izolasyon, güvenlik gibi özellikleri doğal olarak bünyesinde barındırmasıdır. Bunun ile beraber sistem yöneticileri de, yine aşina oldukları yöntemler ile sanal sunucu içerisine 1:1 oranında konumlandırılmış bu konteynerleri yönetebilir ve izleyebilirler. Daha teknik bir ifade ile tanımlamak gerekirse, docker API’ları ile vSphere API’ları arasında bir köprü görevi görür.

VIC modülünü vSphere 6.0 veya 6.5 üzerine kurabilirsiniz. Ortam bileşenlerinden kısaca bahsetmek gerekirse;

VIC-Machine: Oluşturacağımız Virtual Container Host (VCH)’ların yaşam döngülerini yöneteceğimiz aracın adıdır. Bu Windows, Linux veya MacOS bir makine olabilir. My Vmware üzerinden indireceğiniz paketi istediğiniz platformda açabilir ve komut satırından çalıştırabilirsiniz.

Virtual Container Host: VCH, docker çalıştıran bir linux sunucunun vSphere karşılığıdır, tabi bir takım farklar ile. Öncelikle linux tabanlı bir docker host, linux sunucunun kaynakları ile sınırlı iken, VCH, vSphere cluster veya resource pool kaynakları ile sınırlıdır, vSphere karşılığı ise vApp’dir. Kendisini vApp olarak konumlandırdığından dolayı da, kaynaklarını istediğimiz gibi şekillendirebiliriz. Bir küme veya resource pool içerisinde birden fazla VCH kurabiliriz, aynı geleneksel yöntemde birden fazla linux docker host kurabileceğimiz gibi ve konteynerlerin cluster yönetimi de bu sayede vSphere tarafından yapılır.

VCH Endpoint VM: vApp veya resource pool içerisinde çalışan bir sanal sunucudur ve her bir VCH için bir tane yaratılır. Temel görevi, docker remote API noktası olmasıdır. Kendisine gelen docker API komutlarını vSphere API komutlarına çevirir ve bu sayede konteynerlerin yaşam döngülerinin yönetilmesini sağlar. Kendi üzerinde konteyner barındırmaz. Üzerinde Port Layer adı verilen özel bir katman barındırır ve aslında bütün sihiri bu katman gerçekleştirir. VIC ortamına docker kimliğini kazandıran da bu port layer katmanıdır. Daha teknik açıdan baktığımızda, docker’ın libcontainer katmanına benzer bir görev yapar, dolayısı ile ileride farklı kimliklerin de desteklenmesini bekleyebiliriz.

Container VMs: VIC-engine tarafından oluşturulmuş ve içerisinde sadece tek bir konteyner çalıştıran, işletim sistemi PhotonOS olan minimal sanal sunuculardır. İndirdiğimiz VIC klasörü içerisinde yer alan bootstrap.iso ile PhotonOS’in mini versiyonu başlatılır, üzerine ilgili docker imajı gönderilir ve konteyner bu imajdan ayağa kaldırılır. Tüm bu işlem birkaç saniye içerisinde tamamlanır.

vic1

VCH kurulumunu gerçekleştirmek için, My VMware üzerinden paketi indirip, uygun bir sistem üzerinde açmamız gerekir. Bu paketin içeriği aşağıdaki gibi olacaktır.


root@demophoton [ ~/vic ]# ls -lh
total 377M
-rw-r----- 1 root root 205K Dec 3 19:29 LICENSE
-rw-r----- 1 root root 57 Dec 3 19:29 README
drwxr-x--- 2 root root 4.0K Dec 29 11:37 VCH01
-rw-r----- 1 root root 122M Dec 3 19:30 appliance.iso
-rw-r----- 1 root root 63M Dec 3 19:30 bootstrap.iso
drwxr-x--- 5 root root 4.0K Dec 28 12:33 ui
-rw-r----- 1 root root 34M Dec 3 19:29 vic-machine-darwin
-rwxr-x--- 1 root root 34M Dec 3 19:29 vic-machine-linux
-rw-r----- 1 root root 34M Dec 3 19:29 vic-machine-windows.exe
-rw-r----- 1 root root 35K Jan 6 07:37 vic-machine.log
-rw-r----- 1 root root 31M Dec 3 19:29 vic-ui-darwin
-rwxr-x--- 1 root root 31M Dec 3 19:29 vic-ui-linux
-rw-r----- 1 root root 31M Dec 3 19:29 vic-ui-windows.exe

Burada farklı işletim sistemleri için kullanılması gereken çalıştırılabilir dosyaları görebiliriz. Ben vic-machine olarak PhotonOS tercih ettiğimden dolayı, linux etiketli komutları kullanacağım. Bu komut ile birlikte VCH yaratma, silme, listeleme, inceleme gibi işlemleri yapabiliriz.

Bir VCH yaratmak istediğimizde, VIC’in yapacağı şey bir vApp ve bu vApp içerisine VCH Endpoint VM oluşturmak olacaktır. Yukarıdaki dosyalar arasında yer alan appliance.iso VCH VM’i, bootstrap.iso ise konteyner sanal sunucularını ayağa kaldırmak için kullanılır.

Bir VCH yaratabilmek için, vic-machine-linux komutunu, çok fazla parametre ile birlikte çalıştırmamız gerekiyor. Bu parametre setleri içerisinde vSphere tanımları, güvenlik, network, disk, özel registry, ip havuzları, kaynak yönetimi gibi bir çok kategoride parametre bulunmaktadır. Parametrelerin tüm listesine buradan erişebilirsiniz. Kendi ortamımda örnek olarak kullandığım komut seti aşağıdaki gibi oldu;


./vic-machine-linux create \
--name=demovch01 \
--target=demovc.demo.local/DEMO.Datacenter \
--thumbprint="E6:C9:E2:6E:90:9D:DB:5B:48:AA:F6:F6:0E:5D:16:16:4E:52:32:D7" \
--user=orcunuso \
--compute-resource=DEMO.Cluster/DEMO.Vic \
--image-store=datastore1/demovch01 \
--volume-store=datastore1/demovch01:default \
--bridge-network=DPG.Vlan200 \
--public-network=DPG.Vlan100 \
--client-network=DPG.Vlan100 \
--management-network=DPG.Vlan100 \
--dns-server=10.1.94.10 \
--public-network-ip=10.1.93.24 \
--public-network-gateway=10.1.93.1/24 \
--bridge-network-range=172.16.0.0/12 \
--no-tls \
--registry-ca=/root/vic/ca.crt \
--appliance-cpu=2 \
--appliance-memory=4096

VCH kurulumu aşamasında karşılaşabileceğimiz hatalar:

  • İlk denemede 4 numaralı satırda yazılan, vCenter sunucusunun SSL sertifikasının parmak izini bilemiyor olabiliriz. Bunu öğrenmek için ilk komutu –thumbprint olmadan çalıştırıp, alınan hata içerisinden parmak izini öğrenebiliriz.
  • İlgili ESXi sunucularında dışarıya doğru TCP/2377 portunun açık olması gerekmektedir. Eğer değilse, kurulum devam etmeyecektir.

Kurulum parametrelerinde bir hatamız yok ise, uzun bir çıktı sonrasında VCH’ımız hazır hale gelecektir.

vic2

Burada bize 3 konuda nasihat vermiş görünüyor. Birincisi, VCH operasyonları için kurulumu yaptığımız kullanıcının haricinde bir kullanıcı oluşturmamızı ve –ops-user parametresi ile belirtmemiz gerektiğini söylüyor. İkincisi, –no-tls parametremize kızıyor ve güvensiz bağlantılar konusunda uyarıyor. Üçüncüsünde ise, konteyner ve volume’lerin barınacağı diskin paylaşımlı olmadığını ve diğer ESXi sunucuların erişemeyeceğini söylüyor. Bence üçünde de son derece haklı :))

vCenter tarafından da kontrol ettiğimizde, seçtiğimiz küme ve resource pool içerisinde bir adet vApp ve endpoint görevi görecek bir adet VM oluşturulduğunu görebiliriz.

vic3

Bir sonraki yazıda ise VCH üzerinde temel docker operasyonlarını nasıl yapabileceğimizi göreceğiz.

 

Kategoriler:VMware Etiketler:,

228: Project Harbor 0.5.0

23.12.2016 3 yorum

harbor1

En son vSphere Integrated Containers (VIC) yapısından ve bileşenlerinden bahsetmiştik, buradan erişebilirsiniz. Bugün ise, ister VIC ile istersek de kendi başına kullanabileceğimiz bir ürün olan Harbor Projesi’nden bahsedeceğim.

Harbor, Docker imajlarını depolamamızı ve yaygınlaştırmamızı sağlayan, enterprise seviyesinde özellikleri içerisinde barındıran bir registry sunucusudur. Normalde docker istemcileri, varsayılan olarak Docker’ın genel erişime açık registry hizmetini kullanır (https://index.docker.io/v1/). Ancak kurumsal ihtiyaçları düşündüğümüzde, bu her zaman en iyi çözüm olmayacaktır ve kendi ağımız içerisinde özel bir registry sunucusuna ihtiyaç duyacağız. Harbor, bu ihtiyacı gidermek adına geliştirilen açık kaynak bir projedir.

Kurumsal özelliklerden bahsetmişken, bunların ne olduklarına kısaca değinmekte fayda var;

  • Rol tanımlı erişim kontrolü
  • İmajları ikinci bir sunucuya replike edebilme
  • LDAP/AD desteği
  • GUI destekli arayüz
  • İşlemlerin loglanması
  • RESTful API desteği

Eğer Enterprise Plus lisansınız var ise, My VMware portalinden, OVA formatında indirilebilir ve hazır bir şekilde kurulabilir durumda. Eğer bu pakete ulaşamıyorsanız, manuel kurulum için projenin GitHub sayfasına başvurabilirsiniz.

OVA üzerinden hızlı bir kurulum yapmak istediğimizi varsayarsak, kurulum aşamasında vermemiz gereken en önemli karar, kimlik doğrulamasının nasıl yapılacağı, alternatifler LDAP/AD entegre bir şekilde veya veritabanı üzerinden. Önemli çünkü bunu sadece kurulum aşamasında belirleyebiliyoruz. Burada tavsiye, LDAP üzerinden olması yönünde olacaktır, bu bizi kullanıcı yönetiminden muaf tutacaktır ancak kurulum esnasında LDAP ile ilgili bilgileri doğru bir şekilde yazmamız gerekecektir. Örnek olarak;

  • Authentication Mode: ldap_auth
  • LDAP URL: ldap://domaincontroller.domain.lokal
  • LDAP Search DN: CN=AramaYapacakKullanıcı,OU=Users,DC=domain,DC=lokal
  • LDAP Search Password: Yukarıda verilen kullanıcının şifresi
  • LDAP Base DN: OU=KullanıcılarınAranacağıOU,DC=domain,DC=lokal
  • LDAP UID: Kullanıcı aramasının hangi özellik üzerinden yapılacağı bilgisi; uid, cn, email, sAMAccountName veya başka bir değer olabilir.

Kurulum tamamlandıktan sonra, “Permit Root Login” değerini “true” olarak belirtmişsek, sunucuya SSH yapabiliriz demektir. Harbor’un bileşenlerini listelediğimizde, 6 adet bileşenin sunucu üzerinde, docker-compose ile oluşturulmuş konteynerler olarak çalıştığını görebiliriz.

harbor2

Mimari olarak da topoloji aşağıdaki gibi olacaktır.

harbor3

Şimdi bu bileşenleri kısaca inceleyelim;

  • Proxy: Registry ve temel servisler bir reverse-proxy arkasından çalışır ve bu bileşen nginx tarafından sağlanır. İstemcilerden ve tarayıcılardan gelen talepleri, arka plandaki servislere iletir.
  • Registry:  Docker imajlarımızı depolar ve pull/push komutlarımıza cevap verir. Docker’ın resmi registry imajından türetilmiştir.
  • Core Services: Birden fazla servisi bir arada çalıştıran bir yapısı vardır. Bu servislerden en önemlileri, web arayüzü sağlayan UI servisi ve kimlik doğrulaması sonucu kullanıcıların erişimlerini şekillendiren token servisidir. Ps komutunda harbor_ui adı ile görülür.
  • Database: Resmi MySql imajından üretilmiştir ve tüm konfigürasyon verilerini tutar.
  • Job Services: Diğer Harbor sunucularına imaj replikasyonunu gerçekleştiren servistir.
  • Log Collector: Çalışan diğer konteyner servislerinden log toplamaya yarar, içerisinde rsyslogd çalıştırır.

Çalışan konteynerler ile ilgili daha fazla detaya sahip olmak istiyorsak, konteyner adı ile aşağıdaki komutu çalıştırmamız yeterli olacaktır.

docker inspect nginx

Örnek olarak, bu komutun çıktısında, hangi mount noktalarını kullandığını görebiliriz. Burada, “source” olarak görünen klasörün, “destination” olarak konteyner içerisinde read/write modunda mount edildiğini görebiliyoruz. Bu klasör altında da, nginx.conf dosyası içerisinde nginx servisinin konfigürasyon detaylarını görebiliriz. Benzer şekilde diğer servislerin de konfigürasyon detaylarına erişebiliriz.

harbor5

Harbor’ın yapısını temel olarak incelediğimiz bu yazıdan sonra, Day2 operasyonlarını nasıl yapabileceğimizden bahsedeceğim.

Kategoriler:VMware Etiketler:, ,

227: “Containers as VMs” stratejisi ve VIC

19.12.2016 3 yorum

Konteyner yapıları son derece revaçta çünkü herkes çok seviyor, en azından barındırdığı olanakları. Yazılımcılar, esnek olabilmeyi ve ürettikleri yazılımları bir paket olarak kolay bir şekilde yaygınlaştırabilmeyi seviyor. DevOps ve IT çalışanları ise verimliliklerini ve belli seviyelerde getirdiği kolaylıkları seviyor. Daha önceden de var olan bu konteyner yapılarının son 2-3 yıl içerisinde popüler olmasını, Docker’ın sunucu seviyesinde uygulama geliştirme metodolojilerini, iPhone’un istemci seviyesinde uygulamalarının yapısını değiştirmesine benzer şekilde değiştiriyor olmasına da bağlayabiliriz.

Ancak konteynerleri uygulama ile eş tutmamak gerekir, daha çok bir yazılımın belli bir parçasını izole ve bağımlılıklardan arınmış bir şekilde çalıştırabilmek olarak tanımlayabiliriz. Bunun için sistem kaynaklarını yönetebilmek adına cgroups (control groups) ve çalışan konteynerlerin birbirleri ile iletişimini izole edebilmek adına da “kernel namespace”leri kullanır.

Konteyner yapılarını savunan bir çok kişi, sanal sunucuların artık kaynak yönetimi açısından çok pahalı olduklarını, yavaş açıldıklarını ve konteynerlerin bu alanlarda çok daha verimli olduklarını savunur. Genel karşı-argüman ise, kernel seviyesindeki izolasyon yeteneklerinin ne kadar olgun ve güvenli olduğudur ve sistem kullanımlarının, dış dünyaya çok görünür olmamasıdır.

Peki, tek yöntem bu mudur?

Containers as VMs” stratejisi bu soruyu adresleyen bir yaklaşım. VMware 2015’de Bonneville Proje‘sini başlattı ve bu temel olarak bizlere bir Linux üzerinde birden fazla konteyner çalıştırmak yerine, ESXi üzerinde bir VM ile birlikte bir konteyner çalıştırma şansını veriyor, yani 1:1 bir ilişki modeli ile. Bu modelin en büyük avantajı, güvenlik ve izolasyon adına kendini ispatlamış bir platform üzerinde konteynerleri çalıştırmak, beraberinde de hem devops ekiplerine hem de vSphere sistem yöneticilerine görünürlük sağlamak.

Ancak burada elbette bir soru aklımıza geliyor, VM’ler ağır ve pahalı olmayacaklar mıdır? Bu konu üzerinde çalışan üreticiler var ve VMware de bunlardan bir tanesi. İşletim sistemi seviyesinde Photon OS tercih edilir durumda ve Photon OS VMware’ın konteyner yapılarını çalıştırabilmek üzere optimize ettiği tamamen minimal bir linux türevi. Dolayısı ile çok hızlı açılabilen ve çok düşüz ayakizi ile çalışabilen bir yapıya sahip. Intel de, konu ile ilgili farklı bir proje geliştiriyor ve 2015 yılında KVM üzerinde yaptığı testlerde 150 ms’lik bir zaman diliminde konteyner çalıştırabildiğini ve 18-20MB aralığında bellek kullandığını test etmiş ve daha alınacak çok yolu olduğunu ifade ediyor.

Bonneville Proje’sinin devamı niteliğinde olan vSphere Integrated Containers (VIC) ise yakın zamanda GA oldu ve Enterprise Plus lisansa sahip müşteriler tarafından kullanılabilir durumda. Böylelikle vSphere, artık sadece sistem yöneticilerine değil, uygulama geliştirme dünyasına yönelik olarak da bir özelliği devreye alıyor.

vSphere Integrated Containers dediğimizde hangi bileşenler söz konusu, kısaca göz atalım.

bonneville2

VIC Engine:

vSphere API’ları üzerinde docker kimliğinin barındırılmasını sağlayan katman olarak değerlendirebiliriz. Bir vSphere yöneticisi, vic-machine adı verilen bir araç ile, vSphere platformu üzerine VCH (virtual container host) konumlandırabilir. Bu VCH, vSphere açısından baktığımızda bir vApp’e tekabül eder ve bu açıdan kaynak yönetimini bildiğimiz yöntemler ile yapabiliriz. Bu VCH içerisine ilk aşamada bir VM kurulur ve bu VM, docker-API’ları için bir end-point görevi görür, tıpkı linux bir sunucuda konteyner çalıştırırken olduğu gibi. Ancak konteynerler bu VM üzerinde çalışmazlar, vApp içerisinde birbirinden bağımsız VM’ler olarak çalışırlar.

Harbor:

Kurumsal bir Docker registry olarak görev yapar. Temelinde, Docker repolarından da indirip kurabileceğimiz registry bileşenlerini kullanır. İçeride konumlandırılmış olması, LDAP/AD desteğinin olması, kullanıcı bazında yetkilendirilmesi, imajların replike edilebilmesi gibi özelliklerinden dolayı kurumsal ortamlar için daha uygundur. Şu anda 0.5.0 versiyonundadır.

Admiral:

VIC Engine bizlere bir noktaya kadar yönetim ve kurulum imkanı sağlıyor ancak Admiral, konteynerlerin tüm yaşam döngülerini yönetmeyi ve otomasyonunu adresleyen bir konteyner yönetim platformu olarak karşımıza çıkıyor. Kendisi de konteyner olarak çalışabilen Admiral, bu vesile ile, düşük ayakizine, esnek bir şekilde ölçeklenebilir ve hızlı olma özelliklerine sahip.

Kendi halinde de kullanılabilir olan Admiral’ın bir amacı da, vRealize Automation 7.2 için bir eklenti görevi görüp konteyner desteği sağlamaktır. An itibari ile beta sürümü mevcuttur. GitHub üzerindeki projesine buradan erişebilirsiniz.

Sonuç olarak konteyner yapılarını VM seviyesinde çalıştırabiliyor olmak, bizlere aynı zamanda NSX, vSAN ve vRealize Suite gibi teknolojileri, özel bir efor sarketmeden entegre edebilmemizi sağlayacaktır. Halen gelişmekte olan bu “Containers as VMs” stratejisinin “Containers in VMs” stratejisine göre üstünlük sağlayıp sağlayamayacağını gerçekten çok merak ediyorum, günün sonunda bunu zaman gösterecek ancak şimdiden piyasada ilgi toplamaya başlamış görünüyor.

bonneville1

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