Labels Constraints Systemd Docker Secret

X firmasindayiz , firmanin bir IT ekibi var birde developer ekibi . X firmasi cok onemli bir yazilim gelistiriyor , tum ortam docker uzerinde kosuyor , microservice mimarisi mevcut, test staging ve production ortamlari var ve containerlari yonetmek icinde docker swarm mode kullaniliyor. (label,constraint anlatmak icin illa swarm mode gerekli degil, standalone docker daemon icinde ayni sey gecerli)

Soru :  Bu cluster’daki tum containerlarin uzerinde kostugu sanal ve/veya fiziksel makineler homojen mi olmali ? Cesitli gereksinimlerde dolayi farklilik gostermesi gereken container nodelari var midir veya olmalimidir ?

Cevap tabiki olmalidir , cluster icersinde birbirinde farkli isler kosan uygulamalar olabilir mesela biri cpu tabanli isler yaparken digeri daha cok memory ihtiyaci duyabilir , bazilari ssd gibi cok hizli disklerde kosmasi gerekirken , ayni uygulamanin gelistirmeleri ssd uzerinde olmayabilir veya verinin external bir storage sistemi uzerinde tutulmasi gereken bir container olabilir.

Diger guzel bir ornek ise arastiriken Couchbase blogunda buldum, Interstellar filmini seyredeniz var ise Cocuhbase tam size gore 🙂 Multidimensional Scaling sagliyormus kendileri , ilgili blokta Query gibi yusek CPU isteyen . index gibi ssd’e ihtiyac duyan bilesenlerini docker swarm uzerinde nasil farkli node’lar uzerinde kosturursunuz onu yazmis, gayet guzel. Fakat ilgili makale benim icin farkli seyleri aramama sebep oldu.

Bunlar docker daemon calistirilirken nasil label atanir , systemd ortaminda bu tanim nasil yapilir , illa docker daemon’i restart etmeye gerek var mi bu isler icin , dockerd daemon.json ne ? ve docker swarm da farkli bir etiketleme olayi mi var ?  Birde araya Docker secrets kaynadi 🙂

Baslamadan once tam olarak ortusmesede bunu VMware ve Hyper-V adminleri gozunden bakicak olur isek DRS Affinity Rule, vSphere Storage Policy Based Management , Virtual Machine placement and Rating in VMM dedigimizde onlar anlayacaktir ne oldugunu direkt.

Burada karsimiza label denilen sey cikiyor. Label tum Docker objelerini etiketlemek icin kullanilan bir metadata bilgisi. Herseyi diyorum tum docker imajlarini , containerlari ,  networkleri , volumleri , swarm node ve servislerini etiketliyebiliyorsunuz bu sayede hem kullandiginiz docker objelerini organize etmis hemde birbirleri ile arasinda olan iliskileri tanimlama firsatiniz doguyor.

Mesela birazdan bir master iki slave’den olusan swarm mode clusterimin bir nodu’nu ssd diger nodunu ise yuksek cpu gucu isteyen isler icin farkli etiketlerle isaretleyip yaratacagim servislerin sadece isaretledigim ilgili node’larda acilacagini ornekleyecegim.

Ilgili orneklemeye gecmeden once bilinmesi gereken birkac konu daha var ;

Birincisi label key ve value seklinde set ediliyorlar , mesela storage = ssd gibi. Herhangi bir objeye birden fazla label set edebilirsiniz. Label deger olarak <string> icermekte ve tekil olmakta , aksi taktirde tekrarlayan son key’e ait degeri alacaktir.

Labellari artirabiliriz, mesela swarm clusterindaki nodelardan birine cpu = kuvvetli , storagedriver = netapp , ortam = test baska bir nodea ise cpu =  orta , ortam = production , konum = denizmanzarali gibi etiketler koyabilirim.

Gordugum kadariyla bu metadata bilgisinide boyle benim gibi kargacik burgacik olmasin bir duzen icersinde olsun diye buna bir standart getirmeye baslamislar label-schema.org‘da bir draft mevcut, ek olarak bir makale var yazilan. Sanirim ya java’ci veya oracle’ci yaratanlar veya her ikiside ayni zaten 🙂 klasik reverse dns tabiyayinda bu isi yapmaya calisiyorlar. Yukardaki ornegi buna gore guncellersek label soyle olacakti com.<domain_adiniz>.storage=ssd gibi

Ikincisi kafa karistirici bir nokta oldugu , etiketlemenin engine ve node label olarak ikiye ayrildigi.

Simdi , docker swarm uyesi olan “swarmslave2” node’u uzerinde docker info komutunu calitirip Lable degerini okuyacagim

noroot@swarmslave2:~$ sudo docker info | grep -A1 Labels

WARNING: No swap limit support

Labels:

provider=generic

Gordugunuz gibi provider adinda bir label ve generic diye bir deger atanmis , aslinda bu sunu gosteriyor ben docker-machine ile create ettigimde provider olarak generic secmisim ve docker daemon’a calistirilirken bu deger atanarak basliyor. Peki bu deger nerede ?

Varsayili olarak yaratilan ve “/etc/default/docker” dosyasina baktiginizda  DOCKER_OPTS degiskenine atsanmis provider=generic gibi bir label yok. Bu dosyada bizim dikkat etmemiz gereken sey su ibare “THIS FILE DOES NOT APPLY TO SYSTEMD” . Simdi systemd de hem provider label degerinin nerede set edildigini hemde ek engine level label nasil ekleyecegimizi gorelim.

noroot@swarmslave1:~$ systemd-delta 

[EXTENDED]   /lib/systemd/system/docker.service → /etc/systemd/system/docker.service.d/10-machine.conf

[EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

[EXTENDED]   /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf

3 overridden configuration files found.

systemd-delta bize var olan systemd unit dosyalarinin guncellemis yardimci dosyalari gosterecek , buna gore docker unit dosyasina bir goz atalim. (eger systemV konusuyor olsa idik /etc/default/docker veya herhangi bir init script dosyasindan bahsedecektik)

noroot@swarmslave2:~$ cat /etc/systemd/system/docker.service.d/10-machine.conf

[Service]

ExecStart=

ExecStart=/usr/bin/docker daemon -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock –storage-driver aufs –tlsverify –tlscacert /etc/docker/ca.pem –tlscert /etc/docker/server.pem –tlskey /etc/docker/server-key.pem –label provider=generic 

Environment=

Not : sudo systemctl status docker komutu kullanarakda gorebilirsiniz.

Iste bulduk , hadi buraya bir eklenti yapalim , ilgili satirin sonuna –label ortam=test ekleyelim .

Docker unit dosyasinda degisiklik yaptigimiz icin reload edelim

noroot@swarmslave2:~$ sudo systemctl daemon-reload

noroot@swarmslave2:~$ sudo systemctl restart docker

ve

noroot@swarmslave2:~$ sudo docker info | grep -A2 Labels

WARNING: No swap limit support

Labels:

provider=generic

ortam=test

Simdi bir bakalim bu etiketleri swarmmaster uzerinde gorebilecekmiyiz

noroot@swarmmaster:~$ sudo docker node ls –filter label=ortam

ID                         HOSTNAME     STATUS  AVAILABILITY  MANAGER STATUS

esabe22n1ka5yfbwh3ubuve2c  swarmslave2  Ready   Active

Evet goruyoruz. 

Simdi birde node label ekleyelim , node label kullandigimizda docker daemon restart etmemize gerek yok

noroot@swarmmaster:~$ sudo docker node update –label-add konum=denizmanzarali swarmslave2

swarmslave2

Not: Burada belirtmekte fayda var , standalone docker daemon icinde bir yol var, o da daemon.json dosyasini aktive etmek ki production icin onerilen o , ilgili config dosyasinda degisiklik yapildiginda containerlari restart etmeye gerek kalmadan daemon reload edilebilir.)

Not : Node etiketlerini node kendi basina set edemez, sadece ve sadece swarm manager tarafindan set edilebilir.

Bakalim iligili etiket ilgili node’a eklenmis mi ? 

noroot@swarmmaster:~$ sudo docker node inspect swarmslave2 -f “{{.Spec}}”

{{ map[konum:denizmanzarali]} worker active}

Guzel eklenmis birde soyle sorgulayalim

noroot@swarmmaster:~$ sudo docker node ls -f label=konum

ID  HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS

Aaa ooo , bombos , bunu sebebi swarmkit henuz filtreleme icin sadece ve sadece engine label kullaniyor , ilgili github issue linkleri 1,2

ve bakalim servis yarattigimizda neler olacak.

noroot@swarmmaster:~$ sudo docker service create –name S1 –constraint konum==denizmanzarali redis

86yqpxwh71m70buzb22shlazc

Constraint parametresi ile esitligi == kullanarak belirtik ve asagidaki gibi bir sonuca vardik 😦

noroot@swarmmaster:~$ sudo docker service ps 86yqpxwh71m7

ID            NAME  IMAGE         NODE  DESIRED STATE  CURRENT STATE          ERROR  PORTS

ombhqw6l3r1c  S1.1  redis:latest        Running        Pending 2 minutes ago

Calisan birsey yok 

noroot@swarmmaster:~$ sudo docker service create –name S1 –constraint ‘node.labels.konum==denizmanzarali’ redis

pu5i2ezof45ecn5rjg13qextm

Dikkat ederseniz node.labels olarak belirttik ve calisti, burada bir bilgi daha eger node yerine engine yazmis olsa idi bu durumda engine uzerinden gelen etiketler dikkate alinacakti.

Simdi test edelim, birden fazla servis yaratalim , hepside swarmslave2 uzerinde acilmali

noroot@swarmslave2:~$ sudo docker ps

CONTAINER ID        IMAGE                                                                           COMMAND                  CREATED              STATUS              PORTS               NAMES

6ede8c861621        redis@sha256:1b358a2b0dc2629af3ed75737e2f07e5b3408eabf76a8fa99606ec0c276a93f8   “docker-entrypoint…”   33 seconds ago       Up 33 seconds       6379/tcp            S5.1.rs3zhvnrs7280sq1la0yi2zkb

6d093bcb8286        redis@sha256:1b358a2b0dc2629af3ed75737e2f07e5b3408eabf76a8fa99606ec0c276a93f8   “docker-entrypoint…”   38 seconds ago       Up 37 seconds       6379/tcp            S4.1.e55q7w10923d8tmdfp3o4y29h

ac92362e464d        redis@sha256:1b358a2b0dc2629af3ed75737e2f07e5b3408eabf76a8fa99606ec0c276a93f8   “docker-entrypoint…”   43 seconds ago       Up 42 seconds       6379/tcp            S3.1.f2yjmunlex6usdfxr758m70es

40c7f58a0afa        redis@sha256:1b358a2b0dc2629af3ed75737e2f07e5b3408eabf76a8fa99606ec0c276a93f8   “docker-entrypoint…”   47 seconds ago       Up 47 seconds       6379/tcp            S2.1.ln1eqbqewomd6i029z4qaxnwp

4d5f71f4a74c        redis@sha256:1b358a2b0dc2629af3ed75737e2f07e5b3408eabf76a8fa99606ec0c276a93f8   “docker-entrypoint…”   About a minute ago   Up About a minute   6379/tcp            S1.1.i3nmqgtjzu1enitv4v1j3h99s

Nitelim oyle oluyor , swarmslave1 uzerinde hicbirsey yok !

noroot@swarmslave1:~$ sudo docker ps

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

ve Docker Secret 

Tamamen olmasada kendisini HSM (Hardware Security Module ) benzetebiliriz , sifre , SSH private key,  SSL sertifikasi gibi verileri container imaj dosyasi veya source control uzerinde acik. erisilebilir olarak tutmaktansa blob data formatinda ve guvenli olarak key/value store’da tutulan, sadece belirtilen servislerin erisimine acik olan/olacak, bu veriyide servis kullanimi icinguvenli bir sekilde iletilen, Docker 1.13 ile beraber gelen bir ozellik.

Su anda sadece docker swarm servisler bu veriye erisebilir durumda, standalone docker daemon degil , sanirim ileride bu destekde gelecekmis.

Ufak bir ornekle bu makaleyi sonlandiralim , diyelim elimizde cok gizli diye bir dosya var , bunu docker swarm k/v store’a koyalim.

noroot@swarmmaster:~$ echo “cokcokgizli” > cokgizlidosya

gizlidosya1 adindabir kayit yaratiyoruz ve veri olarak cokgizlidosya yukluyoruz

noroot@swarmmaster:~$ sudo docker secret create gizlidosya1 cokgizlidosya

32ozcuy7nwznki7emdlbqh5wj

noroot@swarmmaster:~$ sudo docker secret ls

ID                          NAME                CREATED              UPDATED

32ozcuy7nwznki7emdlbqh5wj   gizlidosya1         About a minute ago   About a minute ago

nf2ib1wt3u6w2y4rlh0v6u999   gizli1              13 hours ago         13 hours ago

Makinenin nerede acildigini bulalim

noroot@swarmmaster:~$ sudo docker service ps confident_hugle

ID            NAME               IMAGE          NODE         DESIRED STATE  CURRENT STATE                   ERROR  PORTS

6bzockyg2v12  confident_hugle.1  ubuntu:latest  swarmslave1  Running        Running less than a second ago

Icine girelim

noroot@swarmslave1:~$ sudo docker exec -it e2f89147c6b1 bash

root@e2f89147c6b1:/#

Iste

root@e2f89147c6b1:/# cat /var/run/secrets/gizlidosya1

cokcokgizli

root@e2f89147c6b1:/#

Burada gozume carpan bir ibare var –> “To use this feature, consider adapting your container to run as a service with a scale of 1” buna dikkat etmek lazim.

Dikkat ederseniz ilgili gizli bilgi in-memory file system olarka mount edilmis olup , container durdugunda unmount olacaktir.

root@e2f89147c6b1:/# df -h

Filesystem                        Size  Used Avail Use% Mounted on

none                              105G  4.3G   96G   5% /

tmpfs                             2.0G     0  2.0G   0% /dev

tmpfs                             2.0G     0  2.0G   0% /sys/fs/cgroup

/dev/mapper/swarmslave1–vg-root  105G  4.3G   96G   5% /etc/hosts

shm                                64M     0   64M   0% /dev/shm

tmpfs                             2.0G  4.0K  2.0G   1% /run/secrets

tmpfs                             2.0G     0  2.0G   0% /sys/firmware

Ayni ornekleri ssl sertifikasi ,

Guzel Linkler 

How do I override or configure systemd services
Overwrite Systemd units and List Drop-in files
What is Upstart
Upstart vs Systemd
https://docs.docker.com/engine/reference/commandline/service_create/#specify-service-constraints—constraint
systemd vs sysVinit Linux Cheatsheet

Guzel Komutlar

systemd-delta
systemctl list-unit-files –type=service
systemctl status docker
sudo systemctl daemon-reload
systemd-analyze
systemd-analyze blame

noroot@swarmslave1:~$ systemctl is-enabled docker

enabled

Advertisements

Posted on 25/04/2017, in Docker and tagged , , , , , , , , , , , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: