Abuztuaren 10ean hasi zen Slurm-en , eta bertan guztiz aztertzen dugu - oinarrizko abstrakzioetatik sare-parametroetaraino.
Artikulu honetan Dockerren historiaz eta bere abstrakzio nagusiez hitz egingo dugu: Irudia, Cli, Dockerfile. Hitzaldia hasiberrientzat pentsatuta dago, beraz, nekez izango da interesgarria erabiltzaile esperientziadunentzat. Ez da odolik, apendizerik edo murgiltze sakonik izango. Oinarrizkoak oso.
Zer da Docker
Ikus dezagun Wikipediako Docker-en definizioa.
Docker edukiontzietako inguruneetan aplikazioen hedapena eta kudeaketa automatizatzeko softwarea da.
Definizio honetatik ez dago ezer argi. Bereziki ez dago argi zer esan nahi duen "edukiontziratzea onartzen duten inguruneetan". Jakiteko, atzera egin dezagun denboran. Has gaitezen normalean "Aro Monolitikoa" deitzen dudan arotik.
Aro monolitikoa
Aro monolitikoa 2000. hamarkadaren hasiera da, aplikazio guztiak monolitikoak zirenean, mendekotasun mordo batekin. Garapenak denbora luzea izan zuen. Aldi berean, zerbitzari asko ez zeuden; denok ezagutzen genituen izenez eta kontrolatzen genituen. Badago konparazio dibertigarri bat:
Animaliak etxeko animaliak dira. Aro monolitikoan, gure zerbitzariak maskotak bezala tratatzen genituen, apainduta eta kuttunak, hauts zatiak botaz. Eta baliabideak hobeto kudeatzeko, birtualizazioa erabili genuen: zerbitzari bat hartu eta hainbat makina birtualetan moztu genuen, horrela ingurunearen isolamendua bermatuz.
Hipervisorean oinarritutako birtualizazio sistemak
Seguruenik, denek entzun dute birtualizazio sistemen berri: VMware, VirtualBox, Hyper-V, Qemu KVM... Aplikazioen isolamendua eta baliabideen kudeaketa eskaintzen dute, baina desabantailak ere badituzte. Birtualizazioa egiteko, hipervisor bat behar duzu. Eta hipervisorea baliabide bat da. Eta makina birtuala bera koloso oso bat izan ohi da - sistema eragile bat, Nginx, Apache eta agian MySQL dituen irudi astun bat. Irudia handia da eta makina birtuala deserosoa da funtzionatzeko. Ondorioz, makina birtualekin lan egitea motela izan daiteke. Arazo hau konpontzeko, birtualizazio sistemak sortu ziren kernel mailan.
Kernel mailako birtualizazio sistemak
Kernel mailako birtualizazioa OpenVZ, Systemd-nspawn, LXC sistemek onartzen dute. Birtualizazio horren adibide deigarri bat LXC (Linux Containers) da.
LXC sistema eragilearen birtualizazio sistema bat da, Linux sistema eragilearen hainbat instantzia isolatu nodo bakarrean exekutatzeko. LXC-k ez ditu makina birtualak erabiltzen, baina ingurune birtual bat sortzen du bere prozesu-espazio eta sare-pilarekin.
Funtsean, LXC-k ontziak sortzen ditu. Zein da makina birtualen eta edukiontzien arteko aldea?
Edukiontzia ez da egokia prozesuak isolatzeko: kernel mailan birtualizazio sistemetan ahultasunak aurkitzen dira, edukiontzitik ostalarira ihes egiteko aukera ematen dutenak. Hori dela eta, zerbait isolatu behar baduzu, hobe da makina birtual bat erabiltzea.
Birtualizazioaren eta edukiontziaren arteko desberdintasunak diagraman ikus daitezke.
Hardwarearen hiperbissoreak, OSaren gainean hiperbissoreak eta edukiontziak daude.
Hardware-hipervisorak politak dira benetan zerbait isolatu nahi baduzu. Memoria orrien eta prozesadoreen mailan isolatzea posible delako.
Programa gisa hipervisoreak daude, eta edukiontziak daude, eta haiei buruz gehiago hitz egingo dugu. Edukiontzi-sistemek ez dute hiperbissorerik, baina bada edukiontzi-motor bat edukiontziak sortu eta kudeatzen dituena. Gauza hau arinagoa da, beraz, nukleoarekin lan egiteagatik gainkostu gutxiago edo batere ez dago.
Kernel mailan edukiontzirako erabiltzen dena
Beste prozesuetatik isolatuta dagoen edukiontzi bat sortzeko aukera ematen duten teknologia nagusiak Namespaces eta Kontrol Taldeak dira.
Izen-espazioak: PID, Networking, Mount eta User. Gehiago daude, baina ulertzeko erraztasunerako hauetan zentratuko gara.
PID Namespacek prozesuak mugatzen ditu. Adibidez, PID Namespace bat sortzen dugunean eta prozesu bat bertan jartzen dugunean, PID 1-arekin bihurtzen da. Normalean sistemetan PID 1 systemd edo init da. Horren arabera, prozesu bat izen-espazio berri batean jartzen dugunean, PID 1 ere jasotzen du.
Networking Namespace aukera ematen du sarea mugatu/isolatzeko eta zure interfazeak barruan jartzeko. Muntatzea fitxategi-sistemaren muga da. Erabiltzailea: erabiltzaileentzako murrizketa.
Kontrol-taldeak: Memoria, CPU, IOPS, Sarea - guztira 12 ezarpen inguru. Bestela Cgroups (Β«C-taldeakΒ») ere deitzen zaie.
Kontrol-taldeek edukiontzi baten baliabideak kudeatzen dituzte. Kontrol Taldeen bidez esan dezakegu edukiontziak ez duela baliabide kopuru bat baino gehiago kontsumitu behar.
Kontainerizazioak guztiz funtziona dezan, teknologia osagarriak erabiltzen dira: Gaitasunak, Copy-on-write eta beste batzuk.
Gaitasunak prozesu bati zer egin dezakeen eta zer ezin duen esaten dugunean dira. Kernel mailan, parametro asko dituzten bit-mapak besterik ez dira. Adibidez, root erabiltzaileak pribilegio osoak ditu eta dena egin dezake. Denbora zerbitzariak sistemaren ordua alda dezake: Time Capsule-n gaitasunak ditu, eta kitto. Pribilegioak erabiliz, prozesuetarako murrizketak malgutasunez konfigura ditzakezu eta, horrela, zure burua babestu.
Copy-on-write sistemak Docker irudiekin lan egin eta eraginkorrago erabiltzeko aukera ematen digu.
Une honetan Docker-ek Cgroups v2-rekin bateragarritasun arazoak ditu, beraz, artikulu hau Cgroups v1-en zentratzen da bereziki.
Baina itzul gaitezen historiara.
Birtualizazio sistemak nukleo mailan agertu zirenean, aktiboki erabiltzen hasi ziren. Hipervisoreko gainkostua desagertu egin zen, baina arazo batzuk geratu ziren:
- irudi handiak: sistema eragile bat, liburutegiak, software ezberdin mordoa OpenVZ berean bultzatzen dituzte, eta azkenean irudia nahiko handia izaten da oraindik;
- Ez dago ontziratzeko eta entregatzeko estandar normalik, beraz, menpekotasunen arazoak jarraitzen du. Egoerak daude kode bik liburutegi bera erabiltzen dutenean, baina bertsio ezberdinekin. Haien artean gatazka bat egon daiteke.
Arazo horiek guztiak konpontzeko, hurrengo aroa heldu da.
Edukiontzien garaia
Edukiontzien Garaia iritsi zenean, haiekin lan egiteko filosofia aldatu egin zen:
- Prozesu bat - edukiontzi bat.
- Prozesuak behar dituen menpekotasun guztiak bere edukiontzira entregatzen ditugu. Honek monolitoak mikrozerbitzuetan moztea eskatzen du.
- Irudia zenbat eta txikiagoa izan, orduan eta hobeto - ahultasun gutxiago daude, azkarrago zabaltzen da, etab.
- Instantziak iragankor bihurtzen dira.
Gogoratzen al duzu zer esan nuen maskotak eta ganaduak? Lehen, kasuak etxeko animaliak bezalakoak ziren, baina orain ganaduak bezala bihurtu dira. Aurretik, monolito bat zegoen - aplikazio bat. Orain 100 mikrozerbitzu, 100 edukiontzi dira. Edukiontzi batzuek 2-3 erreplika izan ditzakete. Gutxiago geratzen zaigu edukiontzi bakoitza kontrolatzea. Guretzat garrantzitsuagoa da zerbitzuaren beraren erabilgarritasuna: edukiontzi multzo horrek zer egiten duen. Horrek monitorizazioaren ikuspegiak aldatzen ditu.
2014-2015 urteetan, Docker-ek loratu egin zuen, orain hitz egingo dugun teknologia.
Docker-ek filosofia eta aplikazioen pakete estandarizatuak aldatu zituen. Docker erabiliz, aplikazio bat paketatu, biltegi batera bidali, handik deskargatu eta zabaldu dezakegu.
Behar dugun guztia Docker edukiontzian sartu dugu, menpekotasun arazoa konpondu da. Docker-ek erreproduzigarritasuna bermatzen du. Uste dut jende askok ekoizgarritasunarekin topo egin duela: denak funtzionatzen dizu, produkziora bultzatzen duzu eta hor gelditzen da lanean. Docker-ekin arazo hau desagertu egiten da. Zure Docker edukiontzia abiarazten bada eta egin behar duena egiten badu, probabilitate handiarekin produkzioan hasiko da eta bertan gauza bera egingo du.
Buruz buruko digresioa
Beti daude gastu orokorrak eztabaidak. Batzuek uste dute Docker-ek ez duela karga gehigarririk, Linux nukleoa eta edukiontzirako beharrezkoak diren prozesu guztiak erabiltzen baititu. Esaterako, "Docker gaina dela esaten baduzu, Linux nukleoa gaindikoa da".
Bestalde, sakonduz gero, Docker-en hainbat gauza daude, tarte batekin, goian daudela esan daitekeena.
Lehenengoa PID izen-espazioa da. Prozesu bat izen-espazio batean jartzen dugunean, PID 1 esleitzen zaio. Aldi berean, prozesu honek beste PID bat du, ostalariaren izen-espazioan dagoena, edukiontzitik kanpo. Adibidez, Nginx edukiontzi batean abiarazi genuen, PID 1 (prozesu nagusia) bihurtu zen. Eta ostalarian PID 12623 du. Eta zaila da esatea zenbateko gastua den.
Bigarren gauza Cgroups da. Har ditzagun Ctaldeak memoriaren arabera, hau da, edukiontzi baten memoria mugatzeko gaitasuna. Gaituta dagoenean, kontagailuak eta memoria-kontabilitatea aktibatzen dira: nukleoak ulertu behar du zenbat orrialde esleitu diren eta zenbat dauden libre edukiontzi honetarako. Hau agian gainkostua da, baina ez dut errendimenduari nola eragiten dion buruzko azterketa zehatzik ikusi. Eta nik neuk ez nuen ohartu Docker-en exekutatzen ari den aplikazioak bat-batean errendimenduaren galera handia izan zuenik.
Eta errendimenduari buruzko ohar bat gehiago. Nukleoaren parametro batzuk ostalaritik edukiontzira pasatzen dira. Bereziki, sareko parametro batzuk. Hori dela eta, Docker-en errendimendu handiko zerbait exekutatu nahi baduzu, adibidez, sarea aktiboki erabiliko duen zerbait, gutxienez parametro hauek egokitu beharko dituzu. nf_conntrack batzuk, adibidez.
Docker kontzeptuari buruz
Docker-ek hainbat osagai ditu:
- Docker Daemon Container Engine bera da; edukiontziak jaurtitzen ditu.
- Docker CII Docker kudeaketa-erabilgarri bat da.
- Dockerfile - irudi bat nola eraikitzeko argibideak.
- Irudia - edukiontzia ateratzen den irudia.
- Edukiontzia.
- Docker erregistroa irudi biltegi bat da.
Eskematikoki honelako itxura du:
Docker daemon Docker_host-en exekutatzen da eta edukiontziak abiarazten ditu. Komandoak bidaltzen dituen Bezero bat dago: irudia eraiki, irudia deskargatu, edukiontzia abiarazi. Docker daemon erregistrora doa eta exekutatzen ditu. Docker bezeroak lokalean (Unix socket batera) eta TCP bidez atzi dezake urruneko ostalari batetik.
Goazen osagai bakoitza.
Docker deabrua - hau zerbitzariaren zatia da, ostalari makinan funtzionatzen du: irudiak deskargatzen ditu eta edukiontziak haietatik abiarazten ditu, edukiontzien arteko sarea sortzen du, erregistroak biltzen ditu. "Sortu irudi bat" esaten dugunean, deabrua ere hori egiten ari da.
Docker CLI β Docker bezeroaren zatia, deabruarekin lan egiteko kontsolaren erabilgarritasuna. Berriro diot, lokalean ez ezik, sarean ere funtziona dezakeela.
Oinarrizko komandoak:
docker ps - erakutsi Docker ostalarian exekutatzen ari diren edukiontziak.
docker irudiak - lokalean deskargatutako irudiak erakutsi.
docker search <> - bilatu erregistroan irudi bat.
docker pull <> - deskargatu irudi bat erregistrotik makinara.
docker eraikitzea < > - bildu irudia.
docker run <> - abiarazi edukiontzia.
docker rm <> - kendu edukiontzia.
docker erregistroak <> - edukiontzien erregistroak
docker start/stop/berrabiar <> - edukiontziarekin lan egiten
Komando hauek menperatzen badituzu eta horiek erabiltzeko konfiantza baduzu, kontuan hartu zure burua % 70eko trebetasuna Docker-en erabiltzaile mailan.
Dockerfile - Irudi bat sortzeko argibideak. Ia instrukzio komando guztiak geruza berri bat dira. Ikus dezagun adibide bat.
Hau da Dockerfile-ren itxura: komandoak ezkerrean, argumentuak eskuinaldean. Hemen dagoen komando bakoitzak (eta, oro har, Dockerfile-n idatzita) geruza berri bat sortzen du Irudian.
Ezkerreko aldean begiratuta ere, gutxi gorabehera uler dezakezu zer gertatzen ari den. Esaten dugu: "sortu guretzako karpeta" - hau geruza bat da. "Karpeta funtzionatzea" beste geruza bat da, eta abar. Geruza tarta bizitza errazten du. Beste Dockerfile bat sortzen badut eta azken lerroan zerbait aldatzen badut - "python" "main.py" ez den beste zerbait exekutatzen badut edo beste fitxategi batetik menpekotasunak instalatzen baditut, aurreko geruzak cache gisa berrerabiliko dira.
Irudia - Hau ontzi-ontzia da; ontziak iruditik ateratzen dira. Docker pakete-kudeatzaile baten ikuspuntutik ikusten badugu (deb edo rpm paketeekin lan egingo bagenu bezala), orduan irudia rpm pakete bat da funtsean. yum install-en bidez aplikazioa instalatu, ezabatu, biltegian aurkitu eta deskargatu dezakegu. Hemen ere berdina da: edukiontziak iruditik abiarazten dira, Docker erregistroan gordetzen dira (yum antzera, biltegi batean), eta irudi bakoitzak SHA-256 hash bat, izen bat eta etiketa bat ditu.
Irudia Dockerfile-ko argibideen arabera eraikitzen da. Dockerfile-ko instrukzio bakoitzak geruza berri bat sortzen du. Geruzak berrerabili daitezke.
Docker erregistroa Docker irudi biltegi bat da. OSaren antzera, Docker-ek erregistro publiko estandarra du - dockerhub. Baina zure biltegia eraiki dezakezu, zure Docker erregistroa.
Edukiontzi - iruditik abiarazten dena. Irudi bat eraiki dugu Dockerfile-ko argibideen arabera, gero irudi honetatik abiarazten dugu. Edukiontzi hau beste ontzietatik isolatuta dago eta aplikazioak funtziona dezan beharrezko guztia eduki behar du. Kasu honetan, edukiontzi bat - prozesu bat. Gertatzen da bi prozesu egin behar dituzula, baina hau Docker ideologiaren kontrakoa da.
"Edukiontzi bat, prozesu bat" eskakizuna PID izen-espazioarekin lotuta dago. PID 1 duen prozesu bat Namespacen hasten denean, bat-batean hiltzen bada, edukiontzi osoa ere hiltzen da. Bertan bi prozesu exekutatzen ari badira: bata bizirik eta bestea hilik, orduan edukiontziak bizirik jarraituko du. Baina Praktika Onen kontua da hau, beste material batzuetan hitz egingo dugu.
Ikastaroaren ezaugarriak eta programa osoa xehetasun gehiagoz aztertzeko, jarraitu esteka: "'.
Egilea: Marcel Ibraev, Kuberneteseko administratzaile ziurtatua, Southbridge-ko ingeniari praktikatzailea, Slurm ikastaroen hizlari eta garatzailea.
Iturria: www.habr.com