Mis on Docker: lühike ajalooline ülevaade ja põhialused

10. augustil alustas Sloermis videokursus Dockerist, kus me käsitleme seda põhjalikult — alates põhialustest kuni võrguparameetriteni.

Selles artiklis räägime Docker'i ajalukku ja selle peamistest kontseptsioonidest: Image, Cli, Dockerfile. Loeng on suunatud algajatele, seega ei pruugi see huvi pakkuda kogenud kasutajatele. Siin ei ole verd, pimesoole ja sügavat sukeldumist. Kõige alus.

Mis on Docker

Vaadake Docker'i määratlust Vikipeediast.

Docker on tarkvara, mis automatiseerib rakenduste juurutamist ja haldamist konteineritootmiseks toetavates keskkondades.

Sellest määratlusest ei saa midagi aru. Eriti ei ole selge, mida tähendab "konteineritootmist toetavates keskkondades". Et paremini aru saada, naaseme tagasi minevikku. Alustame ajastust, mida ma tinglikult nimetaksin "Monoliitse ajastuks".

Monoliitne aeg

Monoliitne aeg on 2000. aastate algus, mil kõik rakendused olid monoliidsed, koos hulga sõltuvustega. Arendamine kestis kaua. Samuti ei olnud palju servereid, me tundsime neid kõiki nimedega ja jälgisime neid. On selline naljakas võrdlus:

Lemmikud — need on koduloomad. Monoliitsetera ajal kohtlesime oma servereid nagu koduloomi, hoolitsedes ja hellitades neid, сöljem tolmu. Parema ressursihaldamise nimel kasutasime virtualiseerimist: võtsime serveri ja lõikasime mitmeks virtuaalseks masinaks, tagades sellega keskkonna isoleerituse.

Hüpperviisoril põhinevad virtualiseerimissüsteemid

Tõenäoliselt olete kõik kuulnud virtualiseerimissüsteemidest nagu VMware, VirtualBox, Hyper-V, Qemu KVM jne. Need tagavad rakenduste isoleerimise ja ressursihalduse, kuid neil on ka puudusi. Virtualiseerimiseks on vajalik hüpperviisor. Hüpperviisor toob kaasa ressursitaseme ülekoormuse. Ja tavaliselt on virtuaalne masin suur ja raske — sellel on operatsioonisüsteem, Nginx, Apache ja võib-olla ka MySQL. Pilt on suur, virtuaalse masinaga on ebamugav opereerida. Seetõttu võib virtuaalmasinatega töötamine olla aeglane. Selle probleemi lahendamiseks loodi tuumatasandi virtualiseerimissüsteemid.

Tuumatasandi virtualiseerimissüsteemid

Tuumatasandi virtualiseerimist toetavad süsteemid nagu OpenVZ, Systemd-nspawn, LXC. Tüüpiline näide sellisest virtualiseerimisest on LXC (Linux Containers).

LXC — operatsioonisüsteemi tasemel virtualiseerimis süsteem, mis võimaldab käivitada mitu eraldatud Linuxi operatsioonisüsteemi instantsi ühel sõlmel. LXC ei kasutata virtuaalmasinaid, vaid loob virtuaalse keskkonna oma protsesside ruumiga ja võrgu tarkvaraga.

Sisuliselt loob LXC konteinerid. Milline on erinevus virtuaalmasinate ja konteinerite vahel?

Konteiner ei sobi protsesside isoleerimiseks: tuuma taseme virtualiseerimissüsteemides leitud haavatavused võimaldavad pääseda konteinerist välja hosti peale. Seetõttu, kui soovite midagi isoleerida, on parem kasutada virtuaalmasinat.

Erinevusi virtualiseerimise ja konteineriseerimise vahel on võimalik näha skeemilt.
Eksisteerivad riistvaralised hüperviisorid, hüperviisorid operatsioonisüsteemi peal ja konteinerid.

"Riistvaralised" hüperviisorid on suurepärane valik, kui soovite midagi tõeliselt isoleerida. Sest seal on võimalik isoleerida mälu lehekülgede ja protsessorite tasemel.

On olemas hüperviisoreid programmidena ja konteinerid, millest me edaspidi räägime. Konteinerimise süsteemides hüperviisorit ei ole, ent olemas on Container Engine, mis loob ja haldab konteinersid. See on kergem lahendus, mistõttu on tuumaga töötamisega seotud overhead väiksem või isegi puudub.

Mis on kasutusel konteinerimise tasemel tuumas?

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

Namespaces: PID, Networking, Mount ja User. On veel, kuid lihtsuse huvides peatume nendel.

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

Networking Namespace võimaldab piirata/isoleerida võrku ning sinna paigutada oma liidested. Mount – see on piirang failisüsteemis. User – piirangute seaded kasutajatele.

Control Groups: Memory, CPU, IOPS, Network – kokku umbes 12 seadistust. Neid tuntakse ka kui Cgroups ('C-groups').

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

Konteinerimise tõhusaks toimimiseks kasutatakse täiendavaid tehnoloogiaid: Capabilities, Copy-on-write ja teised.

Capabilities — see tähendab, et me ütleme protsessile, mida ta teha tohib ja mida mitte. Süsteemi tasemel on need lihtsalt bitikaardid, kus on palju parameetreid. Näiteks, kasutajal root on täisõigused, ta võib teha kõike. Aja server võib muuta süsteemi kellaaega: tal on Time Capsule'i capabilities ja kõik. Privileegide abil saab paindlikult seadistada protsesside piiranguid ja seeläbi end kaitsta.

Copy-on-write süsteem võimaldab meil töötada Docker'i piltidega, kasutades neid efektiivsemalt.

Praegu on Docker'il probleeme Cgroups v2 ühilduvusega, seetõttu käsitletakse artiklis Cgroups v1.

Kuid naaseme ajalukku.

Kui tuumatasandi virtualiseerimissüsteemid ilmusid, hakati neid aktiivselt rakendama. Hüperevisori ülekoormus kadus, kuid mõned probleemid jäid alles:

• suured pildid: sama OpenVZ-sse tõukatakse operatsioonisüsteem, raamatukogud, palju erinevat tarkvara, ja lõpuks on pilt ikkagi üsna suur;
• normaalset pakendamise ja tarne standardit ei ole, seetõttu jääb probleem sõltuvustele. On olukordi, kus kaks koodi osa kasutavad ühte ja sama raamatukogu, aga erinevate versioonidega. Nende vahel võivad tekkida konfliktid.

Nende probleemide lahendamiseks algas järgmine ajastu.

Konteinerite ajastu

Kui saabus konteinerite ajastu, muutus ka nende kasutamise filosoofia:

• Üks protsess — üks konteiner.
• Kohandame kõik protsessile vajalikud sõltuvused tema konteinerisse. See nõuab monoliitide jagamist mikroteenusteks.
• Mida väiksem on pilt, seda parem — vähem võimalikke haavatavusi, kiiremini paigaldatav jne.
• Instantsid muutuvad efemeerseteks.

Kas sa mäletad, kuidas ma rääkisin lemmikloomadest ja karjast? Varem olid instantsid sarnased lemmikloomadele, nüüd aga on nad nagu karja — veised. Varem oli monoliit — üks rakendus. Nüüd on see 100 mikroteenust, 100 konteinerit. Mõnel konteineril võib olla 2-3 koopiat. Me ei pea enam iga konteineri üle nii palju kontrollima. Meie jaoks on olulisem teenuse kättesaadavus: see, mida see konteinerite komplekt teeb. See muudab jälgimise lähenemist.

Aastatel 2014-2015 toimus Docker'i tõus — tehnoloogia, millest me praegu räägime.

Docker muutis filosoofiat ja standardiseeris rakenduste pakendamise. Docker'i abil saame pakendada rakenduse, saata selle hoidlasse, alla laadida sealt ja juurutada.

Docker-konteinerisse paneme kõik vajaliku, seega lahendab see sõltuvuste probleemi. Docker tagab reprodutseeritavuse. Ma arvan, et paljud on kokku puutunud olukordadega, kus kõik töötab, kuid kui lükkad selle tootmisse, enam ei tööta. Dockeriga kaob see probleem. Kui sinu Docker-konteiner käivitub ja teeb seda, mida peab tegema, siis on suure tõenäosusega, et see käivitub ka tootmises ja teeb seal sama.

Üks kõrvalepõige ooverheadi teemal

Ooverheadi osas käivad pidevalt vaidlused. Mõned arvavad, et Docker ei too täiendavat koormust, kuna kasutab Linuxi tuuma ja kõiki selle protsesse, mis on vajalikud konteinerimiseks. Nagu, "kui sa ütled, et Docker on ooverhead, siis on ka Linuxi tuum ooverhead."

Teisest küljest, kui süveneda, siis on Dockeris tõepoolest mõned asjad, mida võiks pingutades nimetada ooverheadiks.

Esimene on PID namespace. Kui paneme protsessi namespace'isse, antakse sellele PID 1. Samas on sellel protsessil ka teine PID, mis asub hosti namespace'is, konteineri väljaspool. Näiteks, kui käivitasime konteineris Nginxi, sai sellest PID 1 (master-protsess). Kuid hostis on selle PID 12623. Ja on keeruline öelda, kui suur see overhead on.

Teine asi on Cgroups. Vaatame Cgroups'i mälule, st võimalust piirata konteineri mälu. Kui see on sisse lülitatud, aktiveeritakse arvestid, memory accounting: kernel peab aru saama, kui palju lehti on eraldatud ja kui palju on veel saadaval selle konteineri jaoks. See võib olla overhead, kuid ma ei ole näinud täpset uurimist, kuidas see jõudlust mõjutab. Samuti ei ole ma märganud, et rakendus, mis on käivitatud Docker'is, kaotaks järsult jõudlust.

Ja veel üks tähelepanek jõudluse kohta. Teatud südamiku parameetrid edastatakse hostist konteinerisse. Eelkõige 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 need parameetrid kohandama. Näiteks nf_conntrack.

Docker kontseptsioonist

Docker koosneb mitmest komponendist:

1. Docker Daemon — see on Container Engine; käivitab konteinerid.
2. Docker CLI — Docker'i haldamise tööriist.
3. Dockerfile — juhis pildi koostamiseks.
4. Image — pilt, millest konteiner käivitatakse.
5. Container.
6. Docker registry — piltide hoidla.

Skeemiliselt näeb see välja umbes selline:

Docker_hostis töötab Docker daemon, mis käivitab konteinerid. On Client, mis edastab käske: kogu pilt, laadi pilt alla, käivita konteiner. Docker daemon läheb registrisse ja täidab need. Docker klient võib pöörduda nii kohalikult (Unix-soketi kaudu) kui ka TCP kaudu eemal asuvalt hostilt.

Käime läbi iga komponendi.

Docker daemon (daemon) — see server pool, which operates on the host machine: downloads images and starts containers, creates a network between containers, and collects logs. When we say 'create an image', this task is also carried out by the daemon.

Docker CLI — the client side of Docker, a console utility for interacting with the daemon. Let me emphasize, it can work not only locally but also over a network.

Basic commands:

docker ps — display the containers that are currently running on the Docker host.
docker images — display the images downloaded locally.
docker search — search for an image in the registry.
docker pull — download an image from the registry to the machine.
docker build <> — build an image.
docker run — run a container.
docker rm — remove a container.
docker logs — logs of the container.
docker start/stop/restart — manage the container.

If you master these commands and use them confidently, consider that you have mastered Docker at the user level by 70%.

Dockerfile — an instruction for creating an image. Almost every command in the instruction is a new layer. Let's look at an example.

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

Isegi vasakut poolt vaadates võib enam-vähem aru saada, mis toimub. Ütleme: "loo me kaust" — see on üks kiht. "Muuda kaust tööks" — see on veel üks kiht ja nii edasi. Kihtide kook lihtsustab elu. Kui ma teen veel ühe Dockerfile'i ja muudan viimases reas midagi — käivitan mitte "python" "main.py", vaid midagi muud või installin sõltuvused teisest failist — siis eelnevaid kihte kasutatakse uuesti, nagu vahemälu.

Image — see on konteineri pakendamine, piltidest käivitatakse konteinerid. Kui vaadata Dockerit nagu paketihaldurit (nagu töötaksime deb või rpm pakettidega), siis image on sisuliselt rpm-pakett. YUM installimise kaudu saame rakenduse paigaldada, selle eemaldada, leida repos, alla laadida. Siin on umbes sama: piltidest käivitatakse konteinerid, need on salvestatud Docker registry's (sarnaselt YUM-ile, repos) ja igal pildil on SHA-256 hash, nimi ja silt.

Pilt luuakse Dockerfile'i juhendi järgi. Iga juhend Dockerfile'is loob uue kihi. Kihti saab taaskasutada.

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

Konteiner on see, mis käivitatakse pildist. Dockerfile'i juhendi järgi koostasime pildi, nüüd käivitame selle pildi põhjal. See konteiner on isoleeritud teistest konteineritest ja peab sisaldama kõike vajalikku rakenduse töötamiseks. Samas üks konteiner — üks protsess. Juhtub, et tuleb luua kaks protsessi, kuid see läheb natuke vastuollu Docker'i ideoloogiaga.

Nõue «üks konteiner — üks protsess» on seotud PID nimelastega. Kui nimelaste sees käivitatakse protsess PID 1, siis kui see sureb, sureb ka kogu konteiner. Kui seal on käivitatud kaks protsessi: üks elab, teine on surnud, elab konteiner ikkagi edasi. Kuid see on parimate praktika küsimus, millest räägime teistes materjalides.

Kursuse omaduste ja täieliku programmi lähemalt uurimiseks võite klõpsata lingile: «Docker'i videokursus».

Autor: Marsel Ibrajev, sertifitseeritud Kubernetes administraator, praktikainsener Southbridge'is, esineja ja Slørmi kursuste arendaja.

Allikas: habr.com