CNA | Orcunus.cOm
12.01.2017 OzanOrcunus	Yorum bırakın
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).
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 \
./vic-machine-linux delete \
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
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.
docker –tls run –name Nginx_Konteyner -d -p 8080:80 \
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.
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:CNA, VIC
07.01.2017 OzanOrcunus	1 yorum
Şu ana kadar genel olarak VIC (vSphere Integrated Containers) strate jisinden 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.
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
-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;
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.
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.
Bir sonraki yazıda ise VCH üzerinde temel docker operasyonlarını nasıl yapabileceğimizi göreceğiz.
03.01.2017 OzanOrcunus	Yorum bırakın
Harbor’ın kurulumu ve ikinci gün operasyonlarından sonra, bir noktada konfigürasyon değişikliği yapmamız gerektiğini farkedebiliriz. Benim senaryomda bu durum, ldap tanımlarını ldaps olarak yapmış olmam ve bunun sonucunda “docker login/logout” işlemlerinin aşağıdaki şekilde başarısız olması olarak gerçekleşti.
Elbette burada tavsiye edilen yöntem ldaps bağlantısını yapabilmek ancak demo ortamında tanımları ldap olarak güncellemek bana hız kazandıracaktır.
Eğer Harbor kurulumunu OVA üzerinden yapmışsak, girdiğimiz tüm parametreleri /harbor/harbor/harbor.cfg dosyası içerisinde bulabiliriz. Ldap URL tanımlamasını değiştirmek için ilk olarak yapmamız gereken, bu dosyayı uygun şekilde güncellemek.
auth_mode = ldap_auth
ldap_url = ldaps://demodc.demo.local
ldap_searchdn = CN=svcharbor,OU=Users,OU=DemoObjects,DC=demo,DC=local
Bu noktadan sonra tüm harbor servislerini bu doğrultuda güncellemek gerekecektir. Daha önceki yazıda, harbor sunucusu içerisinde çalışan konteynerlerden bahsetmiştik. Öncelikle, çalışan konteynerleri durdurup, yok etmemiz gerekiyor. Konteynerleri yok etmiş olmak, veri kaybına sebebiyet vermeyecektir çünkü tüm veriler farklı dizinlerden konteynerlara mount edilmiş durumdadır.
root@demoharbor [ /harbor/harbor ]# docker-compose down
Removing network harbor_default
Normalde docker-compose stop komutu ile konteynerleri durdurup yeniden başlatabilirdik ancak bu durumda aynı konfigürasyon ile ayağa kaldırabilecektik. Bu şekilde ise, konteynerler tamamen yok olup sonrasında varolan imajlardan yeniden oluşabilecek ve bizim ldap tanımlamamız da güncellenmiş olacak.
Not: Down komutu sonrasında “docker ps -a” ile her hangi bir konteyner görmememiz gerekiyor.
Bütün sistemi yeniden ayağa kaldırmak için, aynı dizin içerisinde hazırlanmış bir shell scripti bulunuyor, install.sh. Bunu çalıştırdığımız taktirde, tüm konteynerler yeni parametreler ile birlikte ayağa kalkacaktır.
Bu arada merak edenler için, install.sh içerisinde yapılan kontrollerden sonra çalıştırılan komut aşağıdaki gibidir.
docker-compose -f docker-compose*.yml up -d
root@demoharbor [ /harbor/harbor ]# ./install.sh
Note: docker version: 1.12.1
Note: docker-compose version: 1.7.1
Clearing the configuration file: ./common/config/nginx/cert/server.crt
Clearing the configuration file: ./common/config/nginx/cert/server.key
Generated configuration file: ./common/config/ui/private_key.pem
Generated configuration file: ./common/config/registry/root.crt
[Step 2]: checking existing instance of Harbor ...
Creating network "harbor_default" with the default driver
Now you should be able to visit the admin portal at https://demoharbor.demo.local.
Kategoriler:VMware Etiketler:CNA, Docker, Harbor
28.12.2016 OzanOrcunus	Yorum bırakın
Yakın zamanda, VMware’ın konteyner stratejini ve bu strateji içerisinde konteyner registry hizmeti veren Harbor ürününün yapısını incelemiştik (buradan ve buradan erişebilirsiniz), bugün ise kurulu bir Harbor üzerinde gerçekleştirebileceğimiz ikinci gün operasyonlarına göz atacağız.
Kurulum sonrasında karşınıza temel işlemleri gerçekleştirebileceğimiz web arayüzü çıkar. Kurulum esnasında oluşturduğumuz admin hesabı ile bağlantı kurabiliriz. Login sonrası sizi bir dashboard karşılar ve burada genel durumu, oluşturulmuş depoları ve imajlar üzerinde gerçekleştirilmiş operasyon loglarını görebiliriz.
İmajların kategorize bir şekilde saklanmalarını ve doğru yetkiler ile erişilmelerini sağlamak adına, ilk olarak ilgileneceğimiz kısım projeler olacaktır. Bir proje public ve private olarak tanımlanabilir. Public bir projeye erişim için “docker login” gerekmez, read hakları ile erişim sağlanabilir ancak public olmayan bir proje için login şarttır.
Kurulum sonrasında, normalde sadece bir adet projenin oluşturulmuş olduğunu görebiliriz, library ismi ile ve public bir şekilde. Bu proje altında da, photon:1.0 imajı yer almaktadır. Library her erişime açık olduğundan dolayı buraya OS gibi temel sayılabilecek imajların konumlandırılması anlamlı olacaktır.
Yeni bir proje oluşturmak, “+ New Project” butonuna tıklamak kadar kolaydır. Eğer private olarak oluşturursak, bir sonraki adımda kullanıcı eklememiz gerekecektir. Burada, kurulumu LDAP yetkilendirme ile yaptığım senaryoda dikkatimi çeken bir nokta oldu. LDAP içerisinde yer alan bir kullanıcıyı projeye eklemek istediğimde, kullanıcıyı bulamadığı ile ilgili hata verdi.
Burada farkettiğim, bir docker client üzerinden, önce sıradan bir “docker login” işlemi gerçekleştirmem, sonrasında arayüzden kullanıcıyı eklemem gerektiği oldu. İlerleyen sürümlerde bunun düzeltileceğini düşünüyorum.
Kullanıcı eklerken üç adet profilde ekleyebiliyoruz;
Project admin: Pull/push haklarına sahip, aynı zamanda kullanıcı yönetimi de yapabilir.
Developer: Pull/push haklarına sahip.
Guest: Sadece pull hakkına sahip.
Eğer ikinci bir harbor sunucunuz varsa, Admin Options altından replikasyon politikalarını oluşturabilir, sonrasında bu politikayı proje içerisinde aktif hale getirebilirsiniz.
Şimdi de yaratmış olduğumuz projeye bir photonOS üzerinden nasıl pull/push yapabiliyoruz, onu inceleyelim. Öncelikle Harbor SSL üzerinden iletişim kuracaktır ve photonOS varsayılan olarak bu SSL sertifikasına güvenmeyecektir. Bu yüzden SSL sertifikasını almak ve photonOS üzerine kopyalamak gerekecektir.
Admin menüsü altından sertifikayı ca.crt olarak kaydedelim.
Bu sertifikayı scp ile aşağıdaki şekilde kopyalayalım.
Bunun bir alternatifi –insecure-registry değerini kullanmak olacaktır ancak bu tüm erişimlerinizi güvensiz hale getireceğinden dolayı tavsiye edilen bir yöntem değildir.
Pull/Push talebi: Bir registry sunucusundan imaj çekmek için “docker pull” komutunu kullanırız. Normalde bu komut Docker’ın kendi sitesine yönlenir, biz ise bu amaç uğruna Harbor’ı kullanmak istediğimizden dolayı, komut içerisinde bunu da belirtmemiz gerekecektir. Burada public bir library kullandığımızdan dolayı pull yapabilmek için login işlemi gerçekleştirmemize gerek yok. Push için ise login/logout gerçekleştireceğiz.
docker pull harbor_FQDN/library/photon:1.0
Basit bir dockerfile ile photon:1.0 üzerine yeni bir imaj oluşturuyoruz ve 2.0 olarak etiketliyoruz.
docker build -t harbor_FQDN/project01/myimage:2.0 -f /root/myimage/Dockerfile
Push yapabilmek için login oluyoruz ve oluşturduğumuz imajı gönderiyoruz.
docker login harbor_FQDN
docker push 10.110.32.142/project01/myimage:2.0
docker logout harbor_FQDN
Tüm bu işlemler başarılı sonuçlanırsa, aşağıdaki gibi bir çıktı oluşmasını bekleyebiliriz.
Yeniden dönüp proje sayfamıza baktığımızda ise, en son 2.0 olarak etiketlediğimiz imajın burada kullanılabilir olduğu görebiliyoruz.
23.12.2016 OzanOrcunus	3 yorum
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
GUI destekli arayüz
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.
Mimari olarak da topoloji aşağıdaki gibi olacaktır.
Ş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.
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:CNA, Harbor, VIC
19.12.2016 OzanOrcunus	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.
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.
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.
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.
Kategoriler:VMware Etiketler:CNA, Docker, VIC