Search:

DockerCon16 Deneyimlerimiz

DevOps bakış açısıyla DockerCon16

Category: Docker DevOps Cloud
Category: Docker DevOps Cloud

DockerCon16 Deneyimlerimiz - kloia Blog

kloia olarak davet edildiğimiz DockerCon16 konferansı 19-21 Haziran tarihlerinde Seattle'da gerçekleşti. Docker ve ekosistemi oyuncularının olduğu konferans, DevOps bakış açısıyla ulaşılacak uç boyutlardan örnekler yansıtıyordu.
Konferans boyunca aynı zamanda Cloud servisimizin altyapısındaki konteyner ve replikasyon sihrini yapan Virtuozzo ekibi ile "deep dive" sohbetlere girme fırsatı bulduk.

 0_fsglP8OyG1KBq_7g
 



Öncelikle konferansa özel bir mobil uygulama ile tüm programın takibi, anlık bildirimler ve sosyalleşme sağlandı. Bunun üzerine bir de oyunlaştırma(Gamification) teknikleri kullanılarak interaktivite arttırılmaya çalışıldı. Bileklik sayesinde konferans sırasında tanıştığınız bir kişi ile bilekliklerinizi tokuşturarak puan topluyorsunuz ve kontaklarınızı paylaşabiliyorsunuz!

Konferans programını altta görebilirsiniz:

0_X9BPH0Gc_0yecZl2



Docker'daki Beta, Experimental ve 1.12 ile gelen özellikler arasında:

1- Docker for Mac & Docker for Windows: Linux dışındaki işletim sistemlerinde Docker çalıştırmak için eskiden Kitematic ve boot2docker gibi araçlar kullanmanız gerekiyordu ve makinanız içinde açılan bir sanal makina(VM) aslında sizin Docker sunucunuz oluyordu. VM açmak için de VirtualBox gibi bir ek araca ihtiyaç duyuluyordu ve bunun yanında Kitematic&boot2docker gibi ek araçlar kullanmak gerekiyordu. Artık VirtualBox-Kitematic-boot2docker ı bigisayarınızdan silebilirsiniz, fakat native gibi çalışsa da aslında HyperKit ile çok daha lightweight bir VM arkada açıyor ama size tamamen transparan. Yani Docker Engine OSX de değil aslında, bu da altta zaten belli ediyor kendini:

dsezen$ docker version

Client:

Version:      1.12.0-rc3

API version:  1.24

Go version:   go1.6.2

Git commit:   91e29e8

Built:        Sat Jul  2 00:09:24 2016

OS/Arch:      darwin/amd64

Experimental: true

 


Server:

Version:      1.12.0-rc3

API version:  1.24

Go version:   go1.6.2

Git commit:   876f3a7

Built:        Tue Jul  5 02:20:13 2016

OS/Arch:      linux/amd64

Experimental: true

Mac&Windows download linkerine buradan erişebilirsiniz.

2- Docker for AWS & Docker for Azure: Nasıl Docker for Mac&Windows yazılımcılar için ise, Docker for AWS&Azure da operasyon takımlarının işini kolaylaştırmak ve otomasyonu arttırmak için ortaya çıktı. Docker tek başına bir yazılımı AWS veya Azure'da ayağa kaldırmaya yetmediği için, diğer gereksinimler olan yük dağıtıcı(LB), LB lerin yeni aktive olan konteynerler ile trafik yönlendirme güncellemeleri, güvenlik grupları(Security Groups), sanal ağlar(virtual networks) bileşenleri AWS Cloudformation ve Azure Resources Manager kullanılarak artık deploy etmek mümkün. Henüz private Beta olduğundan erişim talep etmeniz gerekiyor.

3- Routing Mesh: Doğası gereği yük dağıtıcılar (Load Balancers) konteynerden ziyade, üzerindeki çalıştığı makina(host) odaklı yönlendirme(routing) yaparlar. Her eklenen konteyner için, ilgili host a yönlendirme yapması için ilgili yük dağıtıcısının(LB) config dosyasını editlemek, tekrar yükletmek, reload etmek gibi, otomasyonu zahmetli işler gerekir.
Routing Mesh ile tüm swarm ı kapsayan bir port u, örnek 80, rezerve ederek üzerinde ilgili konteyner çalışsın çalışmasın, tüm makinalar 80 portuna gelen istekleri kabul ediyor ve DNS SRV ile ilgili servisi bularak, ilgili konteyner a yönlendiriyor. Yani LB nin artık hangi makinaya yönlendireceğinin yönetilmesine gerek kalmıyor. Bu yönlendirme, Linux kernel'da kendini ıspatlamış IPVS kullanılarak yapılıyor. Optimum bir çözüm mü? Optimumdan ziyade tam bir mühendislik kararı, yani artısı da var, eksisi de. Bence artısı şu aşamada bir tık ön planda gözüküyor.

4- Cryptographic Node Security: Artık mutual end2end TLS konteynerler arası mümkün ve Docker'daki güvenlik çekincelerinin biri çözülmüş oluyor. Arka planda kullanılan ise Notary ve TUF kullanarak bunu yapıyor. Sertifika oluşması ve konteynerlerin birbiri ile şifreli olarak haberleşmesi için yazılım seviyesinde birşey yapılmasına gerek yok.

5- Orchestration built-in&Services: Orchestation artık Docker'ın içerisinde geliyor. "Swarm Mode" aktive etmek için ana makina üzerinde 
docker swarm init
Swarm a katılmak isteyen diğer makinalar üzerinde
docker swarm join <swarm init yapılan IP>:2377 
yazmak yeterli, yani sadece 2 komut.
Bunun yanında uygulamamızın olması gereken state ini belirtmek mümkün. Örnek olarak app01 uygulamasını appnet ağı içerisinde 4 konteyner içerecek şekilde açmak için
docker service create –replicas 4 –name app01 –network appnet –publish 8080:8080/tcp app01_image:latest
yazıyoruz. 4 node u daha sonra yük dağıtımı (load balancing) için kullanıyor olacağız.
appnet ağını Docker'da yaratmak için
docker network create appnet
yazmak yeterli.
Örnek olarak redis servisini swarm a eklemek için.
docker service create –name redis –network appnet redis:latest
yazıyoruz.
Eğer ki app01 için belirtmiş olduğumuz 4 adet nodeun çalıştığı makinalardan bir şekilde down olan olursa, docker istenilen state 4'e ulaşmak için yeni nodeları mevcut makinalarda ayağa kaldıracaktır.

6- Scaling: 5 numaları bölümden referans alarak, eğer ki app01'imizin 6 node a çıkmasını istiyorsak,
docker service scale app01=6
yazmamız yeterli.

7- Service Discovery: Gene 5 numaralı bölümden referans olarak, eğer app01 uygulamamız redis ile çalışıyor olduğunu varsayalım, ama app01 redis endpoint ini bilmiyor. Docker DNS SRV seviyesinde yaptığı servis bulma (service discovery) sayesinde app01 in redis e ulaşması için hostname olarak "redis" yazması yeterli.

8- Global Services: Eğer ki tüm makinalarda çalışması gereken bir servis varsa, bunu global modunu kullanarak yapabiliyoruz. Buna örnek olarak makina üzerinde log ve metriklerin toplandığı bir uygulama olabilir. Bunu yapmak için:
docker service create –mode=global –name newrelic tutum/newrelc-agent
Böylece newrelic konteynerinin tüm makinalar üzerinde 1 kopyası çalışıyor oluyor.

8- Constraints: Belli bir makina veya makina grubunu belirli bir özelliğine(hardware, lokasyon, …) göre etiketleyerek, belirli tip etiketlere göre politika belirleyebiliriz. Örnek olarak belirli tip bir servisin sadece ssd disklere sahip makinada çalışmasını sağlayabiliriz. Veya konteynerler arası performans farkını düşürmek amaçlı, belirli tip bir batch işlemi, sadece belli tip serverlarda çalıştırmak isteyebilriiz.
Öncelikle etiketlemek için:
docker daemon –label storage="ssd"
Uygulamamızın sadece ssd diskli makinalarda çalışması için:
docker service create –replicas 4 –name app01 –network appnet –publish 8080:8080/tcp –constraint storage="ssd" app01_image:latest

9- Distributed Application Bundle: Artık birçok uygulama tek bir konteynerden ziyade, birçok konteynerin birlikte çalışmasını gerektirmekte. Bunu tanımlamak için docker compose daha önce kullanmaktaydık ama bu deployment için yeteli değildi. 
Experimental olarak yayınlanan bu özellik ile yazılım stack inizi .dab uzantılı text dosyası ile tanımlayabiliyosuz. Nasıl docker image ları Dockerfile kullanılarak oluşturuluyorsa, dab dosyaları da docker-compose.yml kullanılarak oluşturuluyor. Format olarak JSON olan dab dosyasında, uygulama için gereken tüm servisler, imagelar, port ve network bilgileri bulunmakta, yani Operasyon takımına deployment ı handover yapmak için birebir! 
dab dosyası oluşturmak için
docker-compose build
docker compose push
docker-compase bundle
Ops takımı için deploy etmek için ise
docker deploy file.dab
Eğer farklı uygulamalar için docker-compose.yml dosyalarımız varsa, örnek olarak micro services ortamlarında, bu komplex stack imizi tek bir dab dosyasında birleştirebiliyoruz.

Derya (Dorian) Sezen

Derya, a.k.a. Dorian, ex-CTO of an amazon.com subsidiary, is currently working as Cloud and DevOps Consultant at kloia.