Changes

Docker volume orchestration

1,814 bytes added, 20:16, 17 February 2019

→‎Swarm service

Az úgynevezett volume orkesztráció kulcsfontosságú a konténeres cluster építésben. Orchestration alatt azt érjük, hogy a több VM-en futó, sok konténerből álló cluster-en az egyes konténerek (amiket "random" telepít fel a swarm valamelyik szabad kapacitású VM-re) hogyan férnek hozzá a futásukhoz szükséges perzisztens tárolóhoz, ahol a konfigurációs állományuk van. Pl. a Portainer-nek hozzá kell férnie egy olyan perzisztens tárolóhoz, ahol az adatbázisát, beállításait tárolni tudja. Ha a Portainer-t swarm service-ként telepítjük fel, akkor nem tudjuk előre megmondani, hogy a swarm melyik node-ra fogja feltelepíteni. Bárhova is telepíti föl, ott rendelkezésre kell álljon a neki szükséges perzisztens állomány. Két fő csapásirány közül választhatunk:

===Network file share on the Mount VMfileshare to container===Valamilyen network file system-et mount-unk minden egyes VM-re, ami részt vesz a cluster-ben. (pl NFS vagy Samba). Aztán a VM-en létrejött megosztásnak a tetejére NFS vagy Samba megosztásra mount-oljuk a konténer megfelelő egyik mappáját'''bind moun'''t-al. Ezzel több baj is van, ez produckicós környezetben csak nagyon kis cluster-en működőképes. # Egy bizonyos cluster méret felett nem igazán lehet ugyan azt a network megosztást (pl NFS) minden egyes VM-re mount-olni (sávszélesség, sebesség, erőforrás igény) # Mivel a swarm "random" módon telepíti fel a konténereket, a VM-ek és nem is lesz szükség egyáltalán a megosztásra, feleslegesen foglalja majd ez az erőforrást. Tehát ez így nagyon favágó ajánlott módszer. (Mivel nem tudjuk hol lesz tegyük oda mindenhova) 

===docker volume plugin===

Használhatunk úgynevezett '''docker volume plugin'''-eket, amik lehetőév teszik, hogy on-demand alapon közvetlen a konténerre mount-oljuk föl a network fájlrendszer megfelelő megosztását(Pl Netshare vagy REX-ray) vagy a VM-re mount-olt network megosztást használhassuk volume-ként a konténer számára transzparnes módon (Pl Convoy ) . Nagyon sokféle volume plugin elérhető a docker-hez, amikkel NFS, AWS, Azure és még sok más network fájlrendszert tudunk közvetlen a konténerbe bekötni. A volume plugin használatakor pont úgy kell megadni a volume-ot mint ha az a lokális VM-en lenne. A plugin elfedi előlünk a network filesystem-hez való csatlakozás komplexitását.

Mikor egy volume-ot megadunk akár a '''docker run''', akár a '''docker service create''' parancsban, akkor igazából mindig megadjuk a volume driver típusát a '''volume-driver''' paraméterben. Ha külön nem definiáljuk, akkor a '''local''' driver-t fogja használni, amivel a volume a lokális VM-en fog létrejönni. Ha nem a lokális driver-t akarjuk használni, akkor két dolgunk van.

# Fel kell telepíteni a kiválasztott volume plugin-t.

# A service definiálásakor a mount parancsban meg kell adni a '''volume-driver ''' paraméterrel a használni kívánt driver nevét.

Mivel Lista az elérhető hivatalosan támogatott plugin-ekről: https://docs.docker.com/engine/extend/legacy_plugins/ <br>Bizonyos pluginek benne fent vannak a docker hub-on, így a '''docker plugin install''' paranccsal automatikusan telepíthetőek.   ===Volume plugin vs storage driver===A '''docker volume plugin'''-eket nem szabad összekeverni a '''storage driver''' témakörrel (https://docs.docker.com/storage/storagedriver/#copying-makes-containers-efficient). A '''storage driver'''-ek a konténer tetején található vékony írható réteget kezelik, míg a volume plugin-ek a megosztás konténerbe felcsatolt volume-ok kezeléséért felelősek.  A konténerek felső vékony írható rétege nem perzisztens, az csak azon arra való, hogy a VMkonténer futása közben módosított image fájlokat tárolja vagy az esetlegesen létrehozott új fájlokat, amik benne sem voltak az image-en jön létreban. Mikor a konténer hozzá akar férni vagy módosítani akar egy fájlt, ahol tényleg szükség van ráakkor a '''storage driver''' megpróbálja azt megkeresni a konténert felépítő (nem írható) image rétegekben fentről lefelé. Azt hogy ezt pontosan milyen algoritmussal csinálja, ez és hogy milyen hatásfokkal az egyetlen járható út nagyobb clustera storage driver-ek esetébentől függ.

Ez a vékony írható réteg csak "gyenge" írási terhelésre van kitalálva, semmi képen sem arra, hogy egy adatbázis kezelő ott tárolja az adatbázis fájlokat. Erős írási terhelésre kifejezetten a docker volume-okat kell használni tipikusan valamelyik volume plugin-al együtt.

Elérhető storage diver-ek: '''aufs, devicemapper, overlay2, vfs'''<br>

Az alapértelmezett az overlay2.

<br>

<br>

=NFS mount on the VM=

Ahogy azt már Az itt leírtaknak még semmi köze a bevezetőben láthattukdocker volume plugin-ekhez. Itt annyit mutatok be, a leg fapadosabb megoldás az ha hogy lehet minden egyes guest VM-re (tehát nem a konténerbe) mountoljuk felcsatolni ugyanazt az összes olyan NFS megosztást, amire szüksége lehet valamelyik konténernek, amiket . Ez egy jó kiindulási alap. A guest VM-ekre felcsatolt NFS megosztásokat kétféle képen használhatják a konténerek: * Tovább mount-oljuk a konténer belsejébe b'''ind mount'''-al a swarm service létre fog hozni. De mivel nem tudjuk előre megmondanimegosztást (csak tesztelési célra, hogy melyik nodekis méretű cluster-ekre)* A megfelelő docker volume diver plugin-ra fognak kerülni, ezért minden szükséges megosztást minden nodeel volume-on létrehozunkokat hozunk létre az NFS megosztáson a konténer számára transzparens módon.(Convoy plugin)

Itt bemutatom, hogyan hozzunk létre A következőkben KVM/qemu VM-en futó boot2docker Lunux-ra fogunk felcsatolni egy NFS megosztást a hoszt-on, és hogyan csatoljuk föl azt a megosztást minden egyes VM-re boot2docker használatával. A példában a Portainer service számára fogunk létrehozni egy megosztást, ahol a /data mappáját perzisztens módon tudja tárolni, amiben a beállítások és felhasználó adatok vannak.

==NFS szerver telepítése==

<source lang="sh">

#!/bin/bash

 

# Usage: ./mountNFS.sh machine-name

 

machineName=$1

PORTA_HOST_DIR='/home/adam/docker/portainer/data'

PORTA_MOUNT_OPT='-o rw,async,noatime,rsize=32768,wsize=32768,proto=tcp'

#Mount NFS for this session docker-machine ssh mg$i machineName sudo mkdir /var/lib/boot2docker/portainerdata docker-machine ssh mg$i machineName sudo /usr/local/etc/init.d/nfs-client start docker-machine ssh mg$i machineName sudo mount 192.168.42.1:$PORTA_DATA_DIR $PORTA_GUEST_DIR $PORTA_MOUNT_OPT #Make the NFS mount boot persistentdocker-machine ssh $machineName sudo chmod 777 /var/lib/boot2docker/profiledocker-machine ssh $machineName "echo 'sudo /usr/local/etc/init.d/nfs-client start'"docker-machine ssh $machineName "echo 'sudo mount 192.168.42.1:$PORTA_DATA_DIR $PORTA_GUEST_DIR $PORTA_MOUNT_OPT' >> /var/lib/boot2docker/profile"

#Make the NFS mount boot persistent

docker-machine ssh mg$i sudo chmod 777 /var/lib/boot2docker/profile

docker-machine ssh mg$i "echo 'sudo /usr/local/etc/init.d/nfs-client start'"

docker-machine ssh mg$i "echo 'sudo mount 192.168.42.1:$PORTA_DATA_DIR $PORTA_GUEST_DIR $PORTA_MOUNT_OPT' >> /var/lib/boot2docker/profile"

done

</source>

A script többi része megegyezik a [[/Docker_Swarm_Mode#Swarm_cluster_l.C3.A9trehoz.C3.A1sa|''Swarm cluster létrehozása'']] fejezetben leírtakkal. A fenti script-et futtatva három olyan VM-et kapunk, ahova ugyan az a NFS megosztás van felcsatolva a '''/var/lib/boot2docker/portainerdata''' mappába. A portainer docker konténer '''/data''' mappáját erre a mappára kell majd mount-olni, így bármelyik manager noder-ra is kerül majd a '''portainer''', ugyan azt a '''/data''' mappát fogja látni.

 

 

Itt a teljes módosított creatCluster.sh: File:

 

[[:File:CreateSwarmClusterOnKVMwithNFSmountWithPortainer.zip |CreateCluster.sh]]

 

 

 

==Portainer telepítése==

portainer/portainer -H unix:///var/run/docker.sock

</pre>

Ha a portainer-t swarm service-ként futtatjuk, akkor fontos, hogy command-nak is megadjuk a unix-docker socket használatát: {{note|A '''-H unix:/var/lib/varboot2docker/run/docker.sockportainerdata'''{{note|A command részben fontos, hogy VM mappába mount-oltuk a unix után három távol NFS megosztás '''/ jel van. Ebből aztán kettő lesz mire konténer lesz belőle, nem pontosan értem, hogy ha escape-elni kell, akkor miért nem négy kell, minden esetre ha csak kettőt írunk, akkor a home/runadam/docker.sock-ban fogja keresni a /varportainer/run/docker.sock helyett}}  Nézzük meg melyik manager nodedata''' mappáját, és erre mount-ra települt oltuk rá a portainer. <pre># docker swarm service ps portainer ID NAME IMAGE NODEjh04xrikkskh portainer.1 -ben a portainer'''/portainer:latest mg0 </pre>Láthatjuk hogy az mg0 manager node-ra került ki. data''' mappáját}}

<br>

=Netshare=

 

==Bemutatás==

http://netshare.containx.io/

:[[File:ClipCapIt-180830-002410.PNG]]

Mount A Netshare docker plugin-el háromféle network fájlrendszert mount-olhatunk közvetlen a docker konténerekbe. Ezek: * NFS v3/4, * AWS EFS or * CIFS

A Netshare a legegyszerűbb az itt bemutatott megoldások közül. Nem kell telepíteni, nem rendelkezik parancssoros interfésszel sem.  Támogat több docker cluster eszközt is: Mesos/Marathon and és Docker Swarm

==Installálás a boot2docker VM-en==

nfs.sock

</pre>

 

 

==Docker standalone==

 

<pre>

# docker run -i -t --name ubuntu --volume-driver=nfs -v 192.168.42.1/home/adam/Projects/DockerCourse/persistentstore/portainer/data/:/data ubuntu /bin/bash

</pre>

 ===Volume létrehozása===<pre># docker volume create -d nfs --name portainerdata -o share=192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/portainer/dataportainerdata</pre> <pre># docker volume lsDRIVER VOLUME NAMEnfs portainerdata</pre> Majd mount-oljuk föl az új nevesített volume-ot: <pre># docker run -i -t --name ubuntu --volume-driver=nfs -v portainerdata:/data ubuntu /bin/bashroot@5e82828c7a37:/#</pre>

==Swarm service==

--constraint 'node.role == manager' \

--mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \

--mount type=volume,volume-driver=nfs,src=192.168.42.1/home/adam/Projects/DockerCourse/persistentstore/portainer/data/,dst=/data,volume-driver=nfs \

portainer/portainer -H unix:///var/run/docker.sock

</pre>

docker-machine ssh $machineName "sudo tar -xvzf docker-volume-netshare_0.35_linux_amd64.tar.gz"

docker-machine ssh $machineName "sudo mv docker-volume-netshare_0.35_linux_amd64 /var/lib/boot2docker/"

docker-machine ssh $machineName "sudo mv chmod 777 /var/lib/boot2docker/docker-volume-netshare_0.35_linux_amd64 /var/lib/boot2docker/netshare"docker-machine ssh $machineName "sudo chmod 777 /var/lib/boot2docker/netshare/"

#Start NFS during system start up

docker-machine ssh $machineName "sudo chmod 777 /var/lib/boot2docker/profile"

docker-machine ssh $machineName "sudo echo 'cd /var/lib/boot2docker/netsharedocker-volume-netshare_0.35_linux_amd64' >> /var/lib/boot2docker/profile"

docker-machine ssh $machineName "sudo echo 'sudo nohup ./docker-volume-netshare nfs -v 3 &' >> /var/lib/boot2docker/profile"

#Restart the sytem for the modifications to take effect

#docker-machine restart $machineName

virsh shutdown $machineName

sleep 20s

virsh start $machineName

</source>

{{note|Fontos, hogy '''shutdown'''-al állítsuk le a VM-et, ne '''destroy'''-al (force off), mert akkor nem fogja tudni a boot2docker elmenteni a változtatásokat, és a netshare installációnk el fog veszni.}}

Sajnos a '''docker-machine ssh machine command''' paranccsal nem lehet valamiért elindítani a '''netshare'''-t. Tehát ez a formula nem működik:

installNetshare.sh futtatása az összes node-on.

<source lang=sh>

for machine in $(docker-machine ls -q); do

./installNetshare.sh $machine

done

</source>

 

 

Ellenőrizzük, hogy minden node-on elindult e a plugin:

<pre>

# docker-machine ssh mg0 ps -ef | grep netshare

1793 root ./docker-volume-netshare nfs -v 3

1833 root ./docker-volume-netshare nfs -v 3

</pre>

<br>

=Convoy=

https://github.com/rancher/convoy

 

A Convoy 4 féle volume kezelést támogat:

* Device Mapper

* NFS

* Amazon EBS

* Digital Ocean

 

 

Az NFS kezelése eltér a Netshare plugin-nál látottaktól, ugyanis nem közvetlen a konténerbe csatolja fel megosztást. A guest VM-en létre fel kell csatolni egy NFS megosztást, ahol a Convoy a volume-okat fogja tárolni a konténer számára transzparens módon.

=REX-Ray=

• ← Older edit

Adam

Bureaucrat, administrator

7,540

edits