Arşiv

Posts Tagged ‘CNA’

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:,

230: Harbor kurulumu sonrası konfig değişikliği

harbor0Harbor’ı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.

unauthorized: authentication required

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.

harbor10

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.


##By default the auth mode is db_auth, i.e. the credentials are stored in a local database.
#Set it to ldap_auth if you want to verify a user's credentials against an LDAP server.
auth_mode = ldap_auth

#The url for an ldap endpoint.
ldap_url = ldaps://demodc.demo.local

#A user's DN who has the permission to search the LDAP/AD server.
#If your LDAP/AD server does not support anonymous search, you should configure this DN and ldap_search_pwd.
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
Stopping nginx ... done
Stopping harbor-jobservice ... done
Stopping registry ... done
Stopping harbor-db ... done
Stopping harbor-ui ... done
Stopping harbor-log ... done
Removing nginx ... done
Removing harbor-jobservice ... done
Removing registry ... done
Removing harbor-db ... done
Removing harbor-ui ... done
Removing harbor-log ... done
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

[Step 0]: checking installation environment ...

Note: docker version: 1.12.1

Note: docker-compose version: 1.7.1
[Step 1]: preparing environment ...
loaded secret key
Clearing the configuration file: ./common/config/jobservice/env
Clearing the configuration file: ./common/config/jobservice/app.conf
Clearing the configuration file: ./common/config/nginx/cert/server.crt
Clearing the configuration file: ./common/config/nginx/cert/server.key
Clearing the configuration file: ./common/config/nginx/nginx.conf
Clearing the configuration file: ./common/config/db/env
Clearing the configuration file: ./common/config/ui/private_key.pem
Clearing the configuration file: ./common/config/ui/env
Clearing the configuration file: ./common/config/ui/app.conf
Clearing the configuration file: ./common/config/registry/config.yml
Clearing the configuration file: ./common/config/registry/root.crt
Generated configuration file: ./common/config/nginx/nginx.conf
Generated configuration file: ./common/config/ui/env
Generated configuration file: ./common/config/ui/app.conf
Generated configuration file: ./common/config/registry/config.yml
Generated configuration file: ./common/config/db/env
Generated configuration file: ./common/config/jobservice/env
Generated configuration file: ./common/config/jobservice/app.conf
Generated configuration file: ./common/config/ui/private_key.pem
Generated configuration file: ./common/config/registry/root.crt
The configuration files are ready, please use docker-compose to start the service.
[Step 2]: checking existing instance of Harbor ...
[Step 3]: starting Harbor ...
Creating network "harbor_default" with the default driver
Creating harbor-log
Creating harbor-ui
Creating harbor-db
Creating registry
Creating harbor-jobservice
Creating nginx

----Harbor has been installed and started successfully.----

Now you should be able to visit the admin portal at https://demoharbor.demo.local.
For more details, please visit https://github.com/vmware/harbor .

Kategoriler:VMware Etiketler:, ,

229: Harbor ile ikinci gün operasyonları

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.

harbor6

İ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.

Username does not exist

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.

harbor7

  • Admin menüsü altından sertifikayı ca.crt olarak kaydedelim.
  • Bu sertifikayı scp ile aşağıdaki şekilde kopyalayalım.
    • /etc/docker/certs.d/harbor_IP/ca.crt
    • /etc/docker/certs.d/harbor_FQDN/ca.crt

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.

harbor8

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.

harbor9

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:, ,

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:, ,
%d blogcu bunu beğendi: