Hvað er Docker: stutt skoðunarferð um sögu og grunnútdrátt

Byrjaði 10. ágúst í Slurmi Docker myndbandsnámskeið, þar sem við greinum það algjörlega - frá grunnútdrætti til netbreyta.

Í þessari grein munum við tala um sögu Docker og helstu útdrætti þess: Image, Cli, Dockerfile. Fyrirlesturinn er ætlaður byrjendum og er því ólíklegt að hann veki áhuga reyndra notenda. Það verður ekkert blóð, botnlanga eða djúp dýfing. Mjög grunnatriði.

Hvað er Docker

Við skulum skoða skilgreininguna á Docker frá Wikipedia.

Docker er hugbúnaður til að gera sjálfvirkan dreifingu og stjórnun forrita í gámaumhverfi.

Ekkert er skýrt út frá þessari skilgreiningu. Það er sérstaklega óljóst hvað „í umhverfi sem styður gámavæðingu“ þýðir. Til að komast að því skulum við fara aftur í tímann. Við skulum byrja á tímum sem ég kalla venjulega „einlitatímann“.

Monolithic tímabil

Einhæfa tímabilið er snemma á 2000. áratugnum, þegar öll forrit voru einhæf, með fullt af ósjálfstæði. Þróunin tók langan tíma. Á sama tíma voru ekki margir netþjónar; við þekktum þá allir með nafni og fylgdumst með þeim. Það er svo fyndinn samanburður:

Gæludýr eru húsdýr. Á einlita tímum komum við fram við netþjóna okkar eins og gæludýr, snyrtir og þykja vænt um, blásum burt rykflekkum. Og fyrir betri auðlindastjórnun notuðum við sýndarvæðingu: við tókum miðlara og skiptum honum í nokkrar sýndarvélar og tryggðum þar með einangrun umhverfisins.

Hypervisor-undirstaða sýndarvæðingarkerfi

Allir hafa sennilega heyrt um sýndarvæðingarkerfi: VMware, VirtualBox, Hyper-V, Qemu KVM o.s.frv. Þau veita einangrun forrita og auðlindastjórnun en hafa líka ókosti. Til að gera sýndarvæðingu þarftu hypervisor. Og hypervisor er auðlindakostnaður. Og sýndarvélin sjálf er yfirleitt heill kólossur - þung mynd sem inniheldur stýrikerfi, Nginx, Apache og hugsanlega MySQL. Myndin er stór og sýndarvélin er óþægileg í notkun. Þar af leiðandi getur verið hægt að vinna með sýndarvélar. Til að leysa þetta vandamál voru sýndarkerfi búin til á kjarnastigi.

Sýndarkerfi á kjarnastigi

Sýndarvæðing á kjarnastigi er studd af OpenVZ, Systemd-nspawn, LXC kerfum. Sláandi dæmi um slíka sýndarvæðingu er LXC (Linux Containers).

LXC er sýndarvæðingarkerfi á stýrikerfisstigi til að keyra mörg einangruð tilvik af Linux stýrikerfinu á einum hnút. LXC notar ekki sýndarvélar heldur býr til sýndarumhverfi með eigin vinnslurými og netstafla.

Í meginatriðum býr LXC til gáma. Hver er munurinn á sýndarvélum og gámum?

Gámurinn hentar ekki til að einangra ferla: veikleikar finnast í sýndarvæðingarkerfum á kjarnastigi sem gerir þeim kleift að flýja úr gámnum til hýsilsins. Þess vegna, ef þú þarft að einangra eitthvað, er betra að nota sýndarvél.

Mismuninn á sýndarvæðingu og gámavæðingu má sjá á skýringarmyndinni.
Það eru vélbúnaðarstýringar, yfirsýnarar ofan á stýrikerfið og gámar.

Vélbúnaðarstýringar eru flottir ef þú vilt virkilega einangra eitthvað. Vegna þess að það er hægt að einangra á stigi minni síðna og örgjörva.

Það eru hypervisors sem forrit og það eru gámar og við munum tala um þá frekar. Gámakerfi eru ekki með yfirvisara, en það er gámavél sem býr til og stjórnar gámum. Þessi hlutur er léttari, þannig að vegna þess að vinna með kjarna er minna kostnaður eða ekkert.

Hvað er notað fyrir gámavæðingu á kjarnastigi

Helstu tækni sem gerir þér kleift að búa til ílát einangraðan frá öðrum ferlum eru nafnarými og stjórnhópar.

Nafnarými: PID, netkerfi, fjall og notandi. Það eru fleiri, en til að auðvelda skilning munum við einbeita okkur að þessum.

PID nafnrými takmarkar ferla. Þegar við til dæmis búum til PID nafnrými og setjum ferli þar, verður það með PID 1. Venjulega í kerfum er PID 1 systemd eða init. Í samræmi við það, þegar við setjum ferli í nýtt nafnrými, fær það einnig PID 1.

Netnafnarými gerir þér kleift að takmarka/einangra netið og setja þitt eigið viðmót inni. Mount er takmörkun á skráarkerfi. Notandi—takmörkun á notendum.

Stjórnhópar: Minni, CPU, IOPS, Net - um 12 stillingar alls. Annars eru þeir einnig kallaðir Cgroups ("C-hópar").

Stjórnhópar stjórna tilföngum fyrir gám. Í gegnum Control Groups getum við sagt að ílátið ætti ekki að neyta meira en ákveðið magn af auðlindum.

Til að gámavæðing virki að fullu er notuð viðbótartækni: Hæfileiki, Copy-on-write og fleira.

Hæfni er þegar við segjum ferli hvað það getur og getur ekki gert. Á kjarnastigi eru þetta einfaldlega punktamyndir með mörgum breytum. Til dæmis hefur rótnotandinn full réttindi og getur gert allt. Tímaþjónninn getur breytt kerfistímanum: hann hefur möguleika á Time Capsule, og það er það. Með því að nota forréttindi geturðu stillt takmarkanir fyrir ferla á sveigjanlegan hátt og þar með vernda þig.

Copy-on-write kerfið gerir okkur kleift að vinna með Docker myndir og nota þær á skilvirkari hátt.

Docker hefur eins og er samhæfnisvandamál við Cgroups v2, þannig að þessi grein fjallar sérstaklega um Cgroups v1.

En snúum okkur aftur að sögunni.

Þegar sýndarvæðingarkerfi birtust á kjarnastigi var farið að nota þau á virkan hátt. Yfirbyggingin á yfirsýnarnum hvarf, en nokkur vandamál voru eftir:

• stórar myndir: þær ýta stýrikerfi, bókasöfnum, fullt af mismunandi hugbúnaði inn í sama OpenVZ, og á endanum reynist myndin samt vera frekar stór;
• Það er enginn eðlilegur staðall fyrir pökkun og afhendingu, þannig að vandamálið með ósjálfstæði er enn. Það eru aðstæður þar sem tvö stykki af kóða nota sama bókasafn, en með mismunandi útgáfum. Það getur verið ágreiningur á milli þeirra.

Til að leysa öll þessi vandamál er næsta tímabil runnið upp.

Gámatímabil

Þegar tímabil gámanna kom breyttist hugmyndafræðin um að vinna með þeim:

• Eitt ferli - einn ílát.
• Við skilum öllum ósjálfstæðum sem ferlið þarf í ílátið sitt. Þetta krefst þess að klippa einlita í örþjónustur.
• Því minni sem myndin er, því betra - það eru færri mögulegir veikleikar, hún rúllar út hraðar og svo framvegis.
• Tilvik verða skammvinn.

Manstu hvað ég sagði um gæludýr vs nautgripi? Áður voru tilvik eins og húsdýr en nú eru þau orðin eins og nautgripir. Áður var monolith - ein umsókn. Núna eru það 100 örþjónustur, 100 gámar. Sumir ílát geta verið með 2-3 eftirlíkingar. Það verður minna mikilvægt fyrir okkur að stjórna öllum gámum. Það sem er mikilvægara fyrir okkur er framboð á þjónustunni sjálfri: hvað þetta sett af gámum gerir. Þetta breytir aðferðum við eftirlit.

Árið 2014-2015 blómstraði Docker - tæknin sem við munum tala um núna.

Docker breytti hugmyndafræðinni og stöðluðum umsóknarumbúðum. Með því að nota Docker getum við pakkað forriti, sent það í geymslu, hlaðið því niður þaðan og sett það í notkun.

Við setjum allt sem við þurfum í Docker gáminn, þannig að ósjálfstæðisvandamálið er leyst. Docker tryggir endurgerðanleika. Ég held að margir hafi lent í því að vera ekki hægt að endurtaka: allt virkar fyrir þig, þú ýtir því í framleiðslu og þar hættir það að virka. Með Docker hverfur þetta vandamál. Ef Docker gámurinn þinn byrjar og gerir það sem hann þarf að gera, þá mun hann með miklum líkum byrja í framleiðslu og gera það sama þar.

Fráhvarf um kostnaður

Það eru alltaf deilur um kostnaður. Sumir telja að Docker beri ekki viðbótarálag, þar sem það notar Linux kjarnann og alla ferla hans sem eru nauðsynlegir fyrir gámavæðingu. Eins og, "ef þú segir að Docker sé kostnaður, þá er Linux kjarninn kostnaður."

Á hinn bóginn, ef þú ferð dýpra, þá eru vissulega nokkrir hlutir í Docker sem, með teygju, má segja að sé yfir höfuð.

Hið fyrra er PID nafnrými. Þegar við setjum ferli í nafnrými er því úthlutað PID 1. Á sama tíma hefur þetta ferli annað PID, sem er staðsett á hýsilnafnarýminu, utan ílátsins. Til dæmis settum við af stað Nginx í gámi, það varð PID 1 (meistaraferli). Og á hýsingaraðilanum er PID 12623. Og það er erfitt að segja hversu mikil kostnaður það er.

Annað atriðið er Cgroups. Tökum Cgroups eftir minni, það er getu til að takmarka minni íláts. Þegar það er virkt eru teljarar og minnisbókhald virkjað: kjarninn þarf að skilja hversu mörgum síðum hefur verið úthlutað og hversu margar eru enn lausar fyrir þennan gám. Þetta er hugsanlega kostnaður, en ég hef ekki séð neinar nákvæmar rannsóknir á því hvernig það hefur áhrif á frammistöðu. Og sjálfur tók ég ekki eftir því að forritið sem keyrir í Docker varð skyndilega fyrir miklum afköstum.

Og enn ein athugasemd um frammistöðu. Sumar kjarnafæribreytur eru sendar frá hýsilnum yfir í ílátið. Sérstaklega sumir netbreytur. Þess vegna, ef þú vilt keyra eitthvað afkastamikið í Docker, til dæmis eitthvað sem mun nota netið virkan, þá þarftu að minnsta kosti að stilla þessar breytur. Sumt nf_conntrack, til dæmis.

Um Docker hugmyndina

Docker samanstendur af nokkrum hlutum:

1. Docker Daemon er sama gámavélin; kynnir gáma.
2. Docker CII er Docker stjórnunartól.
3. Dockerfile - leiðbeiningar um hvernig á að búa til mynd.
4. Mynd — myndin sem ílátið er rúllað út úr.
5. Ílát.
6. Docker registry er myndgeymsla.

Skipulega lítur það einhvern veginn svona út:

Docker púkinn keyrir á Docker_host og ræsir gáma. Það er viðskiptavinur sem sendir skipanir: byggðu myndina, halaðu niður myndinni, ræstu ílátið. Docker púkinn fer í skrárinn og keyrir þá. Docker viðskiptavinurinn getur fengið aðgang bæði á staðnum (í Unix fals) og í gegnum TCP frá ytri gestgjafa.

Við skulum fara í gegnum hvern þátt.

Docker púkinn - þetta er miðlarahlutinn, hann virkar á hýsingarvélinni: hleður niður myndum og ræsir gáma úr þeim, býr til net á milli gáma, safnar annálum. Þegar við segjum „búa til mynd,“ er púkinn að gera það líka.

Docker CLI — Docker biðlarahluti, stjórnborðsforrit til að vinna með púkann. Ég endurtek, það getur virkað ekki aðeins á staðnum heldur einnig yfir netið.

Grunnskipanir:

docker ps - sýndu gáma sem eru í gangi á Docker vélinni.
Docker myndir - sýna myndir sem hlaðið er niður á staðnum.
docker leit <> - leitaðu að mynd í skránni.
docker pull <> - hlaðið niður mynd úr skránni í vélina.
bryggjusmíði < > - safnaðu myndinni.
docker run <> - ræstu ílátið.
docker rm <> - fjarlægðu ílátið.
docker logs <> - gáma logs
docker start/stop/restart <> - vinna með ílátið

Ef þú tileinkar þér þessar skipanir og ert öruggur í að nota þær, teldu þig vera 70% færan í Docker á notendastigi.

Dockerfil - leiðbeiningar til að búa til mynd. Næstum sérhver leiðbeiningaskipun er nýtt lag. Við skulum líta á dæmi.

Svona lítur Dockerfile út: skipanir til vinstri, rök til hægri. Hver skipun sem er hér (og almennt skrifuð í Dockerfile) býr til nýtt lag í mynd.

Jafnvel þegar þú horfir á vinstri hliðina geturðu nokkurn veginn skilið hvað er að gerast. Við segjum: "búið til möppu fyrir okkur" - þetta er eitt lag. „Láttu möppuna virka“ er annað lag og svo framvegis. Lagkaka gerir lífið auðveldara. Ef ég bý til aðra Dockerfile og breyti einhverju í síðustu línu - ég keyri eitthvað annað en "python" "main.py", eða set upp ósjálfstæði frá annarri skrá - þá verða fyrri lög endurnotuð sem skyndiminni.

Mynd - þetta eru gámaumbúðir; gámar eru settir af stað frá myndinni. Ef við lítum á Docker frá sjónarhóli pakkastjóra (eins og við værum að vinna með deb eða rpm pakka), þá er myndin í raun rpm pakki. Í gegnum yum install getum við sett upp forritið, eytt því, fundið það í geymslunni og hlaðið því niður. Það er um það sama hér: gámar eru settir af stað úr myndinni, þeir eru geymdir í Docker skránni (svipað og yum, í geymslu) og hver mynd hefur SHA-256 kjötkássa, nafn og merki.

Myndin er byggð samkvæmt leiðbeiningunum frá Dockerfile. Hver kennsla frá Dockerfile býr til nýtt lag. Hægt er að endurnýta lög.

Docker skrásetning er Docker myndageymsla. Líkt og stýrikerfið er Docker með opinbera staðlaða skráningu - dockerhub. En þú getur byggt upp þína eigin geymslu, þína eigin Docker skrásetningu.

Container - hvað er hleypt af stokkunum frá myndinni. Við byggðum mynd samkvæmt leiðbeiningunum frá Dockerfile, síðan ræsum við hana frá þessari mynd. Þetta ílát er einangrað frá öðrum ílátum og verður að innihalda allt sem þarf til að forritið virki. Í þessu tilviki, einn ílát - eitt ferli. Það kemur fyrir að þú þarft að gera tvö ferli, en þetta er nokkuð andstætt Docker hugmyndafræðinni.

Krafan um „einn ílát, eitt ferli“ tengist PID nafnrýminu. Þegar ferli með PID 1 byrjar í Namespace, ef það deyr skyndilega, þá deyr allt ílátið líka. Ef tvö ferli eru í gangi þar: annar er á lífi og hinn er dauður, þá mun gámurinn áfram lifa. En þetta er spurning um bestu starfsvenjur, við munum tala um þær í öðru efni.

Til að kanna eiginleika og fulla dagskrá námskeiðsins nánar, vinsamlegast fylgdu hlekknum: "Docker myndbandsnámskeið'.

Höfundur: Marcel Ibraev, löggiltur Kubernetes stjórnandi, starfandi verkfræðingur hjá Southbridge, ræðumaður og þróunaraðili Slurm námskeiða.

Heimild: www.habr.com