Mis on Docker: lühike ülevaade ajaloost ja peamistest abstraktsioonidest

10. augustil käivitus Slõrmis videokursus Dockerist, kus käsitleme seda täielikult — alates põhialustest kuni võrgu parameetriteni.

Selles artiklis räägime Docker'i ajaloo ja selle peamistest abstraktsioonidest: Image, Cli, Dockerfile. Loeng on suunatud algajatele, seega ei pruugi see kogenud kasutajatele huvi pakkuda. Siin ei tule verd, apendekti ning sügavat sukeldumist. Ainult kõige alused.

Mis on Docker

Vaadakem Docker'i määratlust Vikipeediast.

Docker on tarkvara rakenduste automatiseeritud juurutamiseks ja haldamiseks konteineritoetavates keskkondades.

Selle määratlemisest ei ole midagi selgelt mõistetav. Eriti ei ole arusaadav, mida tähendab „konteineritoetavates keskkondades“. Selleks, et aru saada, naaseme minevikku. Alustame ajastust, mida ma tinglikult nimetan „Monoliitse ajastuks“.

Monoliitne aeg

Monoliitne aeg on 2000. aastate algus, kui kõik rakendused olid monoliitsed, millega kaasnes hulk sõltuvusi. Arendamine oli aeglane. Sel ajal ei olnud servereid palju, me tundsime neid kõiki nimedega ja jälgisime neid. On üks toredaid võrdlusi:

Lemmikloomad — need on koduloomad. Monoliitses ajas suhtusime oma serveritesse nagu lemmikloomadesse, hoolitsedes ja hellitades ning hoolitsedes, et need oleksid puhtad. Ja parema ressursihalduse jaoks kasutasime virtualiseerimist: võtsime serveri ja jagasime selle mitmeks virtuaalseks masinaks, tagades sellega keskkonna isolatsiooni.

Hüperviisori baasil töötavad virtualiseerimissüsteemid

Virtualiseerimissüsteemidest on kindlasti kõik kuulnud: VMware, VirtualBox, Hyper-V, Qemu KVM jne. Need tagavad rakenduste isolatsiooni ja ressursihalduse, kuid neil on ka puudusi. Virtualiseerimiseks on vajalik hüperviisor. Ja hüperviisor on ressursside ülempiir. Lisaks on virtuaalne masin tavaliselt suur — raske pilt, millel on operatsioonisüsteem, Nginx, Apache ja võib-olla ka MySQL. Pilt on suur ja virtuaalse masinaga on ebamugav opereerida. Tulemuseks on see, et töötamine virtuaalmasinatega võib olla aeglane. Selle probleemi lahendamiseks loodi tuuma tasemel virtualiseerimissüsteemid.

Tuuma tasemel virtualiseerimissüsteemid

Tuuma taseme virtualiseerimist toetavad süsteemid on OpenVZ, Systemd-nspawn, LXC. Selge näide sellisest virtualiseerimisest on LXC (Linux Containers).

LXC on operatsioonisüsteemi tasemel virtualiseerimissüsteem, mis võimaldab käitada mitmeid isoleeritud Linuxi operatsioonisüsteemi eksemplare ühes sõlmes. LXC ei kasuta virtuaalmasinaid, vaid loob virtuaalse keskkonna oma protsesside ruumi ja võrgu pöörisega.

Tegelikult loob LXC konteinerid. Mis on erinevus virtuaalmasinate ja konteinerite vahel?

Konteiner ei sobi protsesside isoleerimiseks: tuuma taseme virtualiseerimissüsteemides leitakse nõrkusi, mis võimaldavad konteinerist hosti välja pääseda. Seega, kui peate midagi isoleerima, on parem kasutada virtuaalmasinat.

Differentiate virtualiseerimise ja konteineriseerimise vahel saab graafikul näha.
On füüsilisi hüperviisoreid, hüperviisoreid operatsioonisüsteemi peal ja konteinerid.

„Raud“ hüperviisorid on lahedad, kui soovite midagi tõeliselt isoleerida. Sest seal on võimalus isoleerida mälu lehekülgede ja propageerijate tasemel.

On hüperviisoreid kui programme ja on konteinerid, millest me edasi räägime. Konteinerimise süsteemides ei ole hüperviisorid, vaid on Container Engine, mis loob ja haldab konteinerite. See on kergem, seega järelikult on tuuma töö tõttu ülekoormus väiksem või puudub see täielikult.

Mida kasutatakse konteinerimise taseme isoleerimiseks.

Peamised tehnoloogiad, mis võimaldavad luua teistest protsessidest isoleeritud konteineri, on Namespaces ja Control Groups.

Namespaces: PID, Networking, Mount ja User. On veel ka teisi, aga lihtsustamise huvides peatume nendele.

PID Namespace piirab protsesse. Kui me näiteks loome PID Namespaces ja paneme sinna protsessi, siis saab see PID 1. Tavaliselt on süsteemides PID 1 systemd või init. Seega, kui paneme protsessi uude namespace'i, saadab see samuti PID 1.

Networking Namespace võimaldab piirata/isoleerida võrku ja seal sees juba paigutada oma liidesed. Mount on piirang failisüsteemi osas. User on piirang kasutajate osas.

Control Groups: Memory, CPU, IOPS, Network — kokku ligikaudu 12 seadistust. Neid tuntakse ka kui Cgroups („C-grupid“).

Control Groups haldavad konteineri ressursse. Control Groups'i kaudu saame öelda, et konteiner ei tohiks tarbida rohkem kui mingi ressursside hulk.

Ette, et konteineriseerimine toimiks tõhusalt, kasutatakse täiendavaid tehnoloogiaid: Capabilities, Copy-on-write ja teised.

Capabilities tähendab, et me ütleme protsessile, mida ta tohib teha ja mida mitte. Süsteemi tasandil on need lihtsalt bitikaardid, millel on palju parameetreid. Näiteks root-kasutajal on täielikud õigused, ta võib teha kõike. Aja teenus saab muuta süsteemi aega: tal on capabilities Time Capsule'i osas, ja kõik. Lubade abil saab paindlikult seadistada piiranguid protsessidele, tagades seeläbi enda turvalisuse.

Copy-on-write süsteem võimaldab meil töötada Docker-piltidega ja kasutada neid efektiivsemalt.

Praegu on Dockeril probleeme Cgroups v2 ühilduvusega, seetõttu räägime artiklis just Cgroups v1-st.

Aga naaseme ajalukku.

Kui tuumikutasemel virtualiseerimissüsteemid ilmusid, hakati neid aktiivselt rakendama. Hüppervääri kulu kadus, kuid mõned probleemid jäid:

• suured pildid: OpenVZ-sse surutakse operatsioonisüsteem, raamatukogud ja hulgaliselt erinevat tarkvara ning lõpuks on pilt ikka veel üsna suur;
• puudub normaalne pakendi ja kohaletoimetamise standard, seega jääb alles sõltuvuste probleem. On olukordi, kus kaks kooditükki kasutavad ühte raamatukogu, kuid erinevate versioonidega. Nende vahel võib tekkida konflikt.

Kuna kõik need probleemid lahendada, tuli järgmine ajastu.

Konteinerite ajastu

Konteinerite ajastu tõi kaasa uue filosoofia nende kasutamiseks:

• Üks protsess — üks konteiner.
• Kohandame kõik vajaliku protsessi sõltuvused tema konteinerisse. See tähendab, et monoliidid tuleb jagada mikroteenusteks.
• Mida väiksem on pilt, seda parem — vähem võimalikke haavatavusi, kiiremini laienev ja nii edasi.
• Instantsid muutuvad efektiivseteks.

Kas sa mäletad, kuidas ma rääkisin koduloomadest vs kasvatustest? Varem olid instantsid nagu koduloomad, nüüd on nad nagu loomakarja. Varem oli monoliit — üks rakendus. Nüüd on see 100 mikroteenust, 100 konteinerit. Mõnel konteineril võib olla 2-3 koopiat. Meile ei ole enam nii oluline kontrollida iga konteinerit. Meie jaoks on tähtsam teenuse kättesaadavus: see, mida see konteinerite komplekt teeb. See muudab jälgimismeetodeid.

2014-2015. aastal toimus Docker'i tõus — tehnoloogia, millest me nüüd räägime.

Docker on muutnud filosoofiat ja standardiseerinud rakenduste pakkimise. Dockeriga saame rakenduse pakkida, saata selle registrisse, laadida sealt alla ja käivitada.

Docker-konteinerisse paneme kõik vajaliku, mistõttu lahendame sõltuvuste probleemi. Docker tagab korduvuse. Ma arvan, et paljud on kogenud olukordi, kus kõik töötab, aga kui tõukate tootmisse, siis see enam ei tööta. Dockeriga see probleem kaob. Kui teie Docker-konteiner käivitub ja teeb seda, mida on vaja, siis on tõenäoliselt, et see käivitub ka tootmises ja teeb seal samu toiminguid.

Käreduse üle vaidlused

Käreduse üle on pidevalt vaieldud. Mõned arvavad, et Docker ei too kaasa täiendavat koormust, kuna kasutab Linuxi tuuma ja kõiki selle konteinerimiseks vajalikke protsesse. Nagu öeldakse: "Kui ütlete, et Docker on koormus, siis on ka Linuxi tuum koormus."

Teisest küljest, kui süübida, on Dockeris tõepoolest mõned asjad, mida võib venitada, et neid võiks pidada koormuseks.

Esiteks on see PID namespace. Kui paneme mingi protsessi namespace'i, antakse sellele PID 1. Samas on sellel protsessil veel üks PID, mis asub hosti namespace'is, konteinerist väljaspool. Näiteks, kui käivitame Nginx'i konteineris, siis saab see PID 1 (peaprosess). Ja hostil on sellel PID 12623. Ja on keeruline öelda, kui suur koormus see on.

Teine asi on Cgroups. Võtame Cgroups'i mälu põhjal, st võime piirata konteinerile mälu. Selle sisselülitamisel aktiveeritakse arvestid, mälu arvestus: tuum peab mõistma, kui palju lehti on eraldatud ja kui palju on selle konteineri jaoks veel vaba. See võib olla koormus, kuid ma ei ole näinud täpseid uuringuid selle kohta, kuidas see mõjutab jõudlust. Ja ma ise ei ole märganud, et rakendus, mis on Dockeris käivitatud, kaotaks äkki jõudlust.

Ja veel üks märkuse jõudluse kohta. Teatud tuuma parameetrid edastatakse hostist konteinerisse. Eriti mõned võrguparameetrid. Seetõttu, kui soovite Dockeris käivitada midagi kõrge jõudlusega, näiteks midagi, mis kasutab aktiivselt võrku, peate vähemalt neid parameetreid kohandama. Näiteks nf_conntrack.

Docker'i kontseptsioonist

Docker koosneb mitmest komponendist:

1. Docker Daemon — see on Container Engine; käivitab konteinerid.
2. Docker CII — tööriist Docker'i haldamiseks.
3. Dockerfile — juhis, kuidas pilti koguda.
4. Image — pilt, millest konteiner turvaliselt jooksma pannakse.
5. Konteiner.
6. Docker registry — piltide hoidla.

Skeemiliselt näeb see välja umbes nii:

Docker_hostil töötab Docker daemon, mis käivitab konteinerid. On olemas Client, mis edastab käske: kogu pilt, laadi pilt, käivita konteiner. Docker daemon käib registry's ja täidab neid. Docker-cliendi võib pöörduda nii kohalikult (unix-soketile) kui ka TCP kaudu eemalt.

Vaatame igat komponenti.

Docker daemon (demon) — see on serveripool, see töötab host-masinal: laeb pilte ja käivitab nendest konteinerid, loob konteinerite vahel võrgu, kogub logisid. Kui me ütleme "loo pilt", tegeleb sellega ka demon.

Docker CLI — Docker'i kliendipool, konsooli tööriist demoni korraldamiseks. Kordan, see võib töötada mitte ainult kohalikult, vaid ka võrgus.

Põhikäsud:

docker ps — kuvab konteinerid, mis praegu on käivitatud Docker-hostis.
docker images — kuvab kohalikult allalaaditud pildid.
docker search <> — pildi otsing registry's.
docker pull <> — laadi pilt registry'st masinasse alla.
docker build <<\/path\/to\/dir>> — koguge pilt.
docker run <> — käivita konteiner.
docker rm <> — kustuta konteiner.
docker logs <> — konteineri logid
docker start/stop/restart <> — töödelge konteinerit

Kui olete need käsud selgeks saanud ja hakkate neid kindlalt kasutama, siis arvestage, et olete 70% Dockerist kasutaja tasemel omandanud.

Dockerfile — juhis pildi loomiseks. Peaaegu iga käsu juhises — uus kiht. Vaadake näite järgi.

Umbes nii näeb Dockerfile välja: vasakul käsud, paremal — argumendid. Iga käsk, mis siin on (ja üldiselt kirjutatakse Dockerfile's), loob uue kihi Image'i sees.

Isegi vasaku osa vaadates võib umbkaudu aru saada, mis toimub. Ütleme: "loo me kaust" — see on üks kiht. "Muuda kaust töökeskkonnaks" — see on veel üks kiht, ja nii edasi. Kihtide kook lihtsustab elu. Kui ma loon veel ühe Dockerfile'i ja viimases reas midagi muudan — käivitan mitte "python" "main.py", vaid midagi muud, või installin sõltuvusi teisest failist — siis eelnevaid kihte kasutatakse kärg-struktuuri kaudu.

Pilt — see on konteineri pakett, millest käivitatakse konteinerid. Kui vaadata Dockerit nagu pakkemanagerit (nagu töötaksime deb või rpm-pakkidega), siis image on põhimõtteliselt rpm-pakk. Yumi installimise kaudu saame rakenduse paigaldada, selle eemaldada, leida hoidlast, alla laadida. Siin on sama: konteinerid käivitatakse pildist, need salvestatakse Docker registry's (analoogina toaga) ja iga image'il on SHA-256 hash, nimi ja silt.

Image koostatakse Dockerfile'i juhiste järgi. Iga juhis Dockerfile'is loob uue kihi. Kihti saab taaskasutada.

Docker registry — on Docker'i piltide hoidla. Analoogina operatsioonisüsteemidele, on Dockeril avalik standardne registri — dockerhub. Kuid võite luua oma hoidla, oma Docker registry.

Konteiner — see, mis käivitatakse pildist. Koostasime pildi Dockerfile'i juhiste järgi, seejärel käivitame me selle pildist. See konteiner on teistest konteineritest isoleeritud, see peab sisaldama kõike vajalikku rakenduse töötamiseks. Samuti tähendab see, et üks konteiner — üks protsess. On juhtumeid, kus tuleb teha kaks protsessi, kuid see on veidi vastuolus Docker'i ideoloogiaga.

Nõue "üks konteiner — üks protsess" on seotud PID Namespace'iga. Kui Namespace'is käivitatakse protsess PID 1-ga ja kui see äkki sureb, siis sureb kogu konteiner samuti. Kui seal käivitatakse kaks protsessi: üks elab, teine sureb, jätkab konteiner kuidagi elamist. Kuid see puudutab parimaid tavasid, neist räägime teistes materjalides.

Rohkem teavet kursuse eripärade ja täieliku programmi kohta leiate lingilt: «Videokursuse Dockerist».

Autor: Marcel Ibiraev, sertifitseeritud Kubernetes'i administraator, praktiseeriv insener Southbridge'is, esineja ja Slõrmi kursuste arendaja.

Allikas: habr.com