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

226: VMUG etkinlik duyurusu – Ankara

vmug1Türkiye’de, VMware profesyonellerini tek bir çatı altında toplama hedefi ile uzun bir aradan sonra yeniden organize olan ve bu yeni organizyon bünyesinde etkinliklere webcast yayınları ile başlayan VMware Kullanıcı Grubu (VMUG) Türkiye, ilk toplantısını da 20 Aralık 2016 tarihinde, Ankara Mövenpick Oteli’nde organize ediyor olacak. Nutanix, Veeam, Trend Micro ve IBM’in sponsor olduğu ve çözümlerini paylaşacakları bu etkinlikte, güncel konularda VMware çalışanları ve VMUG üyeleri tarafından yapılacak sunumlar da ayrı bir renk katacaktır.

Her zamanki gibi sosyal iletişimin ve bilgi paylaşımının üst düzeyde olacağı bu etkinlikte, sizleri de aramızda görmekten mutluluk duyacağız. Detaylara ulaşmak ya da kayıt olabilmek için lütfen tıklayınız.

Ajandayı ve genel bilgileri aşağıda görebilirsiniz.

vmug2

Kategoriler:VMware Etiketler:

225: Snapshot’dan VM üretmek

Gerek vSphere Client olsun gerekse Web Client, VMware bazı özellikleri GUI üzerine koymamayı tercih ediyor, fakat API üzerinden bu özellikler kullanılabiliyor. Bunlardan bir tanesi de, snapshot’ını aldığımız bir sanal sunucudan, geçmişe yönelik klon üretmek.

Not: 6.5 ile birlikte de GUI üzerinde göremedim ancak bir yerlerde gizlenmiş olma ihtimalini açık bırakıyorum.

GUI üzerinden snapshot modunda olan bir sanal sunucunun klonunu almak istersek, sistemin yapacağı, arada geçen tüm snapshot’ları, yeni oluşturulacak VM ile birlikte konsolide etmek olacaktır. Bu durumda arada yer alan bir durumun klonunu oluşturamayacağız. Örnek olarak aşağıdaki sunucuyu düşünebiliriz.

snapclone

Yaptığım testte kolaylık olması açısından, sunucunun sadece vHW (sanal donanım seviyesi) değerini birer artırarak snapshot aldım. Bu arada, vHW seviyesini birer birer, istediğiniz seviyede artırmak da GUI üzerinden yapabileceğimiz bir aksiyon değil. ESXi sunucusu hangi seviyede ise, direk bizi o seviyeye çıkarır. Kontrollü gidebilmek için PowerCLI üzerinde aşağıdaki komutu kullandım.


$VM = Get-VM -Name PHOTON02
$VM.ExtensionData.UpgradeVM("vmx-10")
$VM.ExtensionData.UpgradeVM("vmx-11")

Gelelim işin klon kısmına. Bu işi gerçekleştiren, vSphere 6.0 API referans dokümanından da ulaşabileceğimiz, CloneVM_Task metodudur. Bu metod üç adet parametre kabul eder;

  • Folder: ManagedObjectReference tipinde
  • Name: Oluşacak klonun adı, string tipinde
  • Spec: VirtualMachineCloneSpec tipinde. Klonlama operasyonu ile ilgili tüm parametreleri girdiğimiz obje budur.

Spec objesi çok detaylı bir objedir. İçeriğini ve alt kırılımlarını incelediğimizde karşımıza diskMoveType isimli bir özellik çıkar ki bütün farkı yaratan bu özelliktir. Alabileceği beş adet değer bulunur:

  • createNewChildDiskBacking: Eğer linked klon üretmek istiyorsak, kullanabileceğimiz değer budur. Bu yöntem en hızlı klon alma yöntemidir ve bir anda onlarca klonu alıp, sunucuları hayata geçirebilirsiniz. Script içerisinde LinkedClone opsiyonu ile bu değeri kullandım.
  • moveAllDiskBackingsAndAllowSharing: Tüm delta dosyaların da kopyalanması ile birlikte full klon oluşturmayı tetikler ancak snapshot konfigürasyon dosyasını barındırmaz. Dolayısı ile klon alınmış sunucu, snapshot bilgilerini göremez.
  • moveAllDiskBackingsAndConsolidate: Tüm disklerin taşınıp, konsolide edildiği durum.
  • moveAllDiskBackingsAndDisallowSharing: vSphere Client üzerinden klon gerçekleştirdiğimizde kullanılan değer budur. Tüm delta disklerin konsolide edilmesini sağlar. Klon metodu içerisinde kullanıldığında, yukarıdaki opsiyon ile aynı görevi görür. Script içerisinde, LinkedClone talep edilmediği durumda bu değeri kullandım.
  • moveChildMostDiskBacking: Yine linked klon yapmamızı ancak tüm disklerin değil, en son deltanın kopyalanmasını tetikler.

Şimdi gelelim hem full klon hem de linked klon oluşturabileceğimiz fonksiyonumuza;


function CreateVMFromSnap {
[CmdletBinding()]
Param ( [parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$SourceVMName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$CloneName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$SnapshotName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$ClusterName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$DatastoreName,
[parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][String]$FolderName,
[parameter(Mandatory=$false)][Switch]$LinkedClone
)

$SourceVM = Get-VM -Name $SourceVMName -ErrorAction:SilentlyContinue
if ($SourceVM) {
$Snapshots = Get-Snapshot -VM $SourceVM
$ResourcePoolMoRef = (Get-Cluster -Name $ClusterName | Get-ResourcePool -Name "Resources").ExtensionData.MoRef
$DatastoreMoRef = (Get-Datastore -Name $DatastoreName).ExtensionData.MoRef
$FolderMoRef = (Get-Folder -Name $FolderName -Type VM).ExtensionData.MoRef
if ($LinkedClone) { $CloneType = "createNewChildDiskBacking" }
else { $CloneType = "moveAllDiskBackingsAndDisallowSharing" }

$CloneSpec = New-Object Vmware.Vim.VirtualMachineCloneSpec
$CloneSpec.Snapshot = ($Snapshots | Where-Object {$_.Name -eq $SnapshotName}).ExtensionData.Snapshot
$CloneSpec.Location = New-Object Vmware.Vim.VirtualMachineRelocateSpec
$CloneSpec.Location.Pool = $ResourcePoolMoRef
$CloneSpec.Location.Datastore = $DatastoreMoRef
$CloneSpec.Location.DiskMoveType = [Vmware.Vim.VirtualMachineRelocateDiskMoveOptions]::$CloneType
$VITask = $SourceVM.ExtensionData.CloneVM_Task($FolderMoRef, $CloneName, $CloneSpec)

} else {
Write-Host ("{0} sanal sunucusu bulunamadi" -f $SourceVMName) -ForeGroundColor Red
}
}

Aşağıda LinkedClone oluşturabileceğimiz örnek bir komutu görebiliriz. Seçtiğimiz snapshot bellek bilgilerini de barındırıyor ise, arka planda her VM için bellek verisinin kopyalanması gerekecektir, bu da biraz daha zaman alacaktır. Diğer türlü, çok daha hızlı şekilde sunucuları açabiliriz (tabi açarken IP çakışması olabileceğini de atlamamamız gerekiyor).


for ($num=3; $num -le 10; $num++) {
CreateVMFromSnap -SourceVMName PHOTON02 -CloneName ("PHOTON{0}" -f $num) -SnapshotName VMX10_Acik_Belleksiz -ClusterName DC2.DemoCluster -DatastoreName Datastore02 -FolderName VMFolder -LinkedClone
#Start-VM -VM ("PHOTON{0}" -f $num)
}

Sonuç:

snapclone2

Kategoriler:VMware Etiketler:

224: SDDC vizyonu ve vSphere 6.5

SDDC (Software Defined Data Center), VMware’ın yıllar önce ortaya koyduğu bir strateji. Bu stratejiyi yorumlamadan önce, ortak bir paydada buluşabilmek adına, yazılım tanımlı olmak kavramının ne anlama geldiğini değerlendirmek daha anlamlı olacaktır çünkü her popüler jargon gibi, bunun da zaman içerisinde asıl anlamını kaybetme eğilimi içerisinde olduğunu düşünüyorum. Elbette bu tip kavramların, TDK karşılığı gibi somut ve tek bir açıklaması olmayacaktır ancak aşağıdaki ifade bence gayet tanımlayıcı:

Yazılım tanımlı veri merkezi, ihtiyaç duyulan sistemsel kaynakların, yazılım, standard ve politikalar aracılığı ile donanımdan bağımsız, ölçeklenebilir ve otomasyon destekli bir şekilde teslim edilmesini sağlayan metodolojidir.

Burada iki konunun altını çizmek gerekir, donanım bağımsız olması ve politikalar aracılığı ile sağlanması. Bunu özellikle belirtmek istememin sebebi, yazılım tanımlı olmanın, genelde, sadece otomasyon ile eş tutulması. Ancak otomasyon işin sadece bir alt başlığı niteliğinde.

vmug1SDDC vizyonu içerisinde bir çok ürün söz konusu ancak vSphere halen bu ailenin kalbinde yer alan ve amiral gemisi olarak tabir edebileceğimiz bir konumda. Yakın zamanda, VMUG (VMware User Group) içerisinde yaptığım bir sunumda, vSphere 6.5’in getirdiği yenilikleri anlatmaya çalıştım. Çok fazla madde olduğundan, beklediğimden uzun bir sunum oldu ancak umarım keyifli olmuştur, eğer katılamadıysanız YouTube üzerinden de izleyebilirsiniz.

Not: İlerleyen tarihlerdeki sunumlarda konuları özelleştirmeyi planlıyoruz, bu yüzden ilgi duyduğunuz konu başlıklarını iletebilirseniz bizim için de faydalı olacaktır.

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