Algas 10. augustil Slurmis , milles analüüsime seda täielikult – põhiabstraktsioonidest võrguparameetriteni.
Selles artiklis räägime Dockeri ajaloost ja selle peamistest abstraktsioonidest: Image, Cli, Dockerfile. Loeng on mõeldud algajatele, seega tõenäoliselt ei paku see kogenud kasutajatele huvi. Ei toimu verd, pimesoole ega sügavat keelekümblust. Päris põhitõed.
Mis on Docker
Vaatame Dockeri määratlust Wikipediast.
Docker on tarkvara rakenduste juurutamise ja haldamise automatiseerimiseks konteinerkeskkondades.
Sellest määratlusest ei selgu midagi. Eriti ebaselge on, mida tähendab "konteinereerimist toetavates keskkondades". Et seda teada saada, läheme ajas tagasi. Alustame ajastuga, mida ma tinglikult nimetan "monoliitikumiajastuks".
Monoliitne ajastu
Monoliitse ajastu on 2000. aastate algus, mil kõik rakendused olid monoliitsed ja paljude sõltuvustega. Areng võttis kaua aega. Samas servereid ei olnud palju, teadsime neid kõiki nimepidi ja jälgisime neid. Siin on selline naljakas võrdlus:
Lemmikloomad on koduloomad. Monoliitsel ajastul kohtlesime oma servereid nagu lemmikloomi, hoolitsesime ja hellitasime, puhudes minema tolmukübemed. Ja ressursside paremaks haldamiseks kasutasime virtualiseerimist: võtsime serveri ja lõikasime selle mitmeks virtuaalmasinaks, tagades sellega keskkonna isolatsiooni.
Hüperviisoripõhised virtualiseerimissüsteemid
Kõik on ilmselt kuulnud virtualiseerimissüsteemidest: VMware, VirtualBox, Hyper-V, Qemu KVM jne. Need pakuvad rakenduste isolatsiooni ja ressursside haldamist, kuid neil on ka puudusi. Virtualiseerimiseks on vaja hüperviisorit. Ja hüperviisor on üldressurss. Ja virtuaalne masin ise on tavaliselt terve koloss – raske pilt, mis sisaldab operatsioonisüsteemi, Nginxi, Apache'i ja võib-olla ka MySQL-i. Pilt on suur ja virtuaalmasina kasutamine ebamugav. Seetõttu võib virtuaalmasinatega töötamine olla aeglane. Selle probleemi lahendamiseks loodi virtualiseerimissüsteemid kerneli tasemel.
Kerneli tasemel virtualiseerimissüsteemid
Kerneli tasemel virtualiseerimist toetavad OpenVZ, Systemd-nspawn, LXC süsteemid. Sellise virtualiseerimise ilmekas näide on LXC (Linux Containers).
LXC on operatsioonisüsteemi tasemel virtualiseerimissüsteem Linuxi operatsioonisüsteemi mitme isoleeritud eksemplari käitamiseks ühes sõlmes. LXC ei kasuta virtuaalmasinaid, vaid loob virtuaalse keskkonna koos oma protsessiruumi ja võrgupinuga.
Põhimõtteliselt loob LXC konteinereid. Mis vahe on virtuaalmasinatel ja konteineritel?
Konteiner ei sobi protsesside isoleerimiseks: virtualiseerimissüsteemides leitakse kerneli tasemel turvaauke, mis võimaldavad neil konteinerist hosti pääseda. Seega, kui teil on vaja midagi isoleerida, on parem kasutada virtuaalset masinat.
Diagrammil on näha erinevusi virtualiseerimise ja konteineriseerimise vahel.
Seal on riistvara hüperviisorid, OS-i peal olevad hüperviisorid ja konteinerid.
Riistvaralised hüperviisorid on lahedad, kui soovite tõesti midagi isoleerida. Sest mälulehtede ja protsessorite tasemel on võimalik isoleerida.
Programmina on hüperviisorid ja on konteinerid ning me räägime neist lähemalt. Konteinersüsteemidel ei ole hüperviisorit, kuid on olemas konteinerite mootor, mis loob ja haldab konteinereid. See asi on kergem, nii et südamikuga töötamise tõttu on kulusid vähem või üldse mitte.
Mida kasutatakse konteineriseerimiseks tuuma tasemel
Peamised tehnoloogiad, mis võimaldavad luua muudest protsessidest eraldatud konteinerit, on nimeruumid ja juhtrühmad.
Nimeruumid: PID, Networking, Mount ja User. Neid on rohkem, kuid mõistmise hõlbustamiseks keskendume neile.
PID nimeruum piirab protsesse. Kui loome näiteks PID nimeruumi ja asetame sinna protsessi, saab sellest PID 1. Tavaliselt on süsteemides PID 1 systemd või init. Seega, kui asetame protsessi uude nimeruumi, saab see ka PID 1.
Võrgustiku nimeruum võimaldab teil võrku piirata/isoleerida ja sinna oma liidesed paigutada. Mount on failisüsteemi piirang. Kasutaja – kasutajate piirang.
Juhtrühmad: mälu, protsessor, IOPS, võrk - kokku umbes 12 seadet. Muidu nimetatakse neid ka C-rühmadeks (“C-rühmad”).
Juhtrühmad haldavad konteineri ressursse. Kontrollgruppide kaudu saame öelda, et konteiner ei tohiks tarbida rohkem kui teatud hulk ressursse.
Konteineriseerimise täielikuks toimimiseks kasutatakse täiendavaid tehnoloogiaid: võimalused, kopeerimine kirjutamisel ja muud.
Võimalused on see, kui me ütleme protsessile, mida see võib teha ja mida mitte. Kerneli tasemel on need lihtsalt paljude parameetritega bitmapid. Näiteks root kasutajal on täielikud õigused ja ta saab teha kõike. Ajaserver saab süsteemi aega muuta: sellel on Time Capsule'i võimalused ja see on kõik. Privileege kasutades saate paindlikult konfigureerida protsessidele piiranguid ja seeläbi ennast kaitsta.
Kopeerimis-kirjutamisel süsteem võimaldab meil töötada Dockeri piltidega ja neid tõhusamalt kasutada.
Dockeril on praegu ühilduvusprobleemid Cgroups v2-ga, seega keskendub see artikkel konkreetselt Cgroups v1-le.
Aga tuleme tagasi ajaloo juurde.
Kui virtualiseerimissüsteemid kerneli tasemel ilmusid, hakati neid aktiivselt kasutama. Hüpervisori üldkulud kadusid, kuid mõned probleemid jäid alles:
- suured pildid: suruvad samasse OpenVZ-sse operatsioonisüsteemi, teeke, hunniku erinevat tarkvara ja lõpuks osutub pilt ikka päris suureks;
- Pakendamisel ja tarnimisel pole normaalset standardit, seega jääb sõltuvuste probleem püsima. On olukordi, kus kaks kooditükki kasutavad sama teeki, kuid erinevate versioonidega. Nende vahel võib tekkida konflikt.
Kõigi nende probleemide lahendamiseks on saabunud järgmine ajastu.
Konteinerite ajastu
Kui konteinerite ajastu saabus, muutus nendega töötamise filosoofia:
- Üks protsess - üks konteiner.
- Tarnime kõik protsessi jaoks vajalikud sõltuvused oma konteinerisse. See nõuab monoliitide lõikamist mikroteenusteks.
- Mida väiksem pilt, seda parem – võimalikke turvaauke on vähem, see veereb kiiremini välja jne.
- Juhtumid muutuvad lühiajaliseks.
Kas mäletate, mida ma ütlesin lemmikloomade ja veiste kohta? Kui varem olid instantsid nagu koduloomad, siis nüüd on neist saanud nagu veised. Varem oli monoliit - üks rakendus. Nüüd on see 100 mikroteenust, 100 konteinerit. Mõnel konteineril võib olla 2–3 koopiat. Meie jaoks muutub iga konteineri kontrollimine vähem oluliseks. Meie jaoks on olulisem teenuse enda kättesaadavus: mida see konteinerite komplekt teeb. See muudab seire lähenemisviise.
Aastatel 2014–2015 õitses Docker - tehnoloogia, millest me nüüd räägime.
Docker muutis filosoofiat ja standardiseeritud rakenduste pakendit. Dockeri abil saame pakkida rakenduse, saata selle hoidlasse, sealt alla laadida ja juurutada.
Panime kõik vajaliku Dockeri konteinerisse, seega on sõltuvusprobleem lahendatud. Docker tagab reprodutseeritavuse. Ma arvan, et paljud inimesed on kohanud reprodutseerimatust: kõik töötab sinu heaks, lükkad selle tootmisse ja seal see lakkab töötamast. Dockeriga see probleem kaob. Kui teie Dockeri konteiner käivitub ja teeb seda, mida ta peab tegema, alustab see suure tõenäosusega tootmist ja teeb seal sama.
Kõrvalepõike üldkulude kohta
Üldkulude üle on alati vaidlusi. Mõned inimesed usuvad, et Docker ei kanna lisakoormust, kuna see kasutab Linuxi tuuma ja kõiki selle konteineriseerimiseks vajalikke protsesse. Näiteks: "Kui ütlete, et Docker on üldkulud, siis on Linuxi tuum üldkulud."
Teisest küljest, kui minna sügavamale, on Dockeris tõepoolest mitu asja, mille kohta võib öelda, et need on üleliigsed.
Esimene on PID-nimeruum. Kui asetame protsessi nimeruumi, määratakse sellele PID 1. Samal ajal on sellel protsessil teine PID, mis asub hosti nimeruumis väljaspool konteinerit. Näiteks käivitasime Nginxi konteineris, sellest sai PID 1 (master process). Ja hostis on selle PID 12623. Raske on öelda, kui suur see üldkulu on.
Teine asi on Cgrupid. Võtame C-rühmad mälu järgi, st võime piirata konteineri mälu. Kui see on lubatud, aktiveeritakse loendurid ja mäluarvestus: kernel peab aru saama, kui palju lehti on selle konteineri jaoks eraldatud ja kui palju on veel vaba. See võib olla üldkulu, kuid ma pole näinud täpseid uuringuid selle kohta, kuidas see toimivust mõjutab. Ja ma ise ei märganud, et Dockeris töötava rakenduse jõudlus järsku järsult vähenes.
Ja veel üks märkus jõudluse kohta. Mõned kerneli parameetrid edastatakse hostist konteinerisse. Eelkõige mõned võrguparameetrid. Seega, kui soovite Dockeris käivitada midagi suure jõudlusega, näiteks midagi, mis kasutab aktiivselt võrku, peate vähemalt neid parameetreid kohandama. Mõni nf_conntrack näiteks.
Dockeri kontseptsiooni kohta
Docker koosneb mitmest komponendist:
- Docker Daemon on sama konteinermootor; laseb vette konteinereid.
- Docker CII on Dockeri haldusutiliit.
- Dockerfile – juhised pildi koostamiseks.
- Pilt – pilt, millest konteiner välja rullitakse.
- Konteiner.
- Dockeri register on piltide hoidla.
Skemaatiliselt näeb see välja umbes selline:
Dockeri deemon töötab saidil Docker_host ja käivitab konteinerid. Seal on klient, mis saadab käske: loo pilt, laadige pilt alla, käivitage konteiner. Dockeri deemon läheb registrisse ja käivitab need. Dockeri klient pääseb juurde nii lokaalselt (Unixi pesasse) kui ka TCP kaudu kaughostist.
Vaatame läbi iga komponendi.
Dockeri deemon - see on serveriosa, see töötab hostmasinas: laadib alla pilte ja käivitab nendest konteinerid, loob konteinerite vahel võrgu, kogub logisid. Kui me ütleme "loo pilt", teeb seda ka deemon.
Dockeri CLI — Dockeri kliendiosa, konsooliutiliit deemoniga töötamiseks. Kordan, see võib töötada mitte ainult kohapeal, vaid ka võrgu kaudu.
Põhilised käsud:
docker ps – kuva konteinerid, mis praegu Dockeri hostis töötavad.
dokkimispildid – kuvage kohapeal allalaaditud pilte.
dockeri otsing <> – pildi otsimine registrist.
docker pull <> – laadige pilt registrist masinasse alla.
dokk ehitada < > - koguge pilt.
docker run <> – konteineri käivitamine.
docker rm <> – eemaldage konteiner.
dokkimispalgid <> – konteineri logid
docker start/stop/restart <> – konteineriga töötamine
Kui valdate neid käske ja kasutate neid kindlalt, pidage end kasutaja tasemel Dockeri 70% valdajaks.
dockerfile - juhised pildi loomiseks. Peaaegu iga käsukäsk on uus kiht. Vaatame näidet.
Selline näeb välja Dockerfile: käsud vasakul, argumendid paremal. Iga siin olev (ja üldiselt Dockerfile'i kirjutatud) käsk loob pildis uue kihi.
Isegi vasakut poolt vaadates saate umbkaudu aru, mis toimub. Me ütleme: "loo meile kaust" - see on üks kiht. "Tee kaust töötama" on veel üks kiht ja nii edasi. Kihiline kook teeb elu lihtsamaks. Kui loon teise Docker-faili ja muudan midagi viimasel real – käitan midagi muud kui “python” “main.py” või installin sõltuvused teisest failist –, siis kasutatakse eelmisi kihte vahemäluna.
pilt - see on konteinerpakend; konteinerid käivitatakse pildilt. Kui vaadata Dockerit paketihalduri vaatenurgast (nagu töötaksime deb- või rpm-pakettidega), siis on pilt sisuliselt rpm-pakett. Yum installi kaudu saame rakenduse installida, kustutada, leida hoidlast ja alla laadida. Siin on umbes sama: konteinerid käivitatakse pildilt, need salvestatakse Dockeri registrisse (sarnaselt yumiga hoidlasse) ja igal pildil on SHA-256 räsi, nimi ja silt.
Pilt on üles ehitatud Dockerfile'i juhiste järgi. Iga Dockerfile'i juhis loob uue kihi. Kihid saab uuesti kasutada.
Dockeri register on Dockeri pildihoidla. Sarnaselt OS-iga on Dockeril avalik standardregister - dockerhub. Kuid saate luua oma hoidla, oma Dockeri registri.
Konteiner - mis pildilt käivitatakse. Ehitasime pildi vastavalt Dockerfile'i juhistele, seejärel käivitame selle sellelt pildilt. See konteiner on isoleeritud teistest konteineritest ja peab sisaldama kõike, mis on rakenduse toimimiseks vajalik. Sel juhul üks konteiner - üks protsess. Juhtub, et peate tegema kaks protsessi, kuid see on mõnevõrra vastuolus Dockeri ideoloogiaga.
Nõue "üks konteiner, üks protsess" on seotud PID nimeruumiga. Kui nimeruumis käivitub protsess PID 1-ga, kui see äkki sureb, sureb ka kogu konteiner. Kui seal on käimas kaks protsessi: üks on elus ja teine on surnud, siis konteiner elab ikka edasi. Kuid see on parimate tavade küsimus, me räägime neist teistes materjalides.
Kursuse funktsioonide ja täieliku programmiga tutvumiseks järgige linki: “'.
Autor: Marcel Ibraev, Kubernetese sertifitseeritud administraator, Southbridge'i praktiseeriv insener, Slurmi kursuste esineja ja arendaja.
Allikas: www.habr.com