Arşiv

Posts Tagged ‘Docker’

234: PhotonOS üzerine docker-compose kurulumu

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

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

dockercompose1

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

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

dockercompose2

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

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

Kategoriler:VMware Etiketler:,

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

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

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

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

Proxy tanımlamaları:

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

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

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

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

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

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

systemctl daemon-reload
systemctl restart docker

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

systemctl show –property Environment docker

Tarball olarak taşımak:

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

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

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

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

docker-portability2

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

 

Kategoriler:Docker, VMware Etiketler:,

209: PowerCLI ve çoklu platform desteği

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

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

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

docker pull vmware/powerclicore

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

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

powerclicore2

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

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

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

PowerCLI Core Fling

Kategoriler:Docker, VMware Etiketler:, ,

208: PhotonOS ile Powershell

11.10.2016 1 yorum

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

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

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

powershell1

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

docker run -it centos/powershell

powershell2

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

 

 

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