ProHoster > Blogs > Administrācija > Kas ir Docker: īsa ekskursija vēsturē un pamata abstrakcijās

Kas ir Docker: īsa ekskursija vēsturē un pamata abstrakcijās

Sākās 10. augustā Slurm Docker video kurss, kurā mēs to analizējam pilnībā - no pamata abstrakcijām līdz tīkla parametriem.

Å ajā rakstā mēs runāsim par Docker vēsturi un tās galvenajām abstrakcijām: Image, Cli, Dockerfile. Lekcija paredzēta iesācējiem, tāpēc diez vai tā varētu interesēt pieredzējuÅ”us lietotājus. NebÅ«s asiņu, aklās zarnas vai dziļas iegremdÄ“Å”anas. PaÅ”i pamati.

Kas ir Docker: īsa ekskursija vēsturē un pamata abstrakcijās

Kas ir Docker

Apskatīsim Docker definīciju no Wikipedia.

Docker ir programmatÅ«ra lietojumprogrammu izvietoÅ”anas un pārvaldÄ«bas automatizÄ“Å”anai konteinerizētās vidēs.

No Ŕīs definÄ«cijas nekas nav skaidrs. ÄŖpaÅ”i nav skaidrs, ko nozÄ«mē ā€œvidēs, kas atbalsta konteinerizācijuā€. Lai to uzzinātu, atgriezÄ«simies laikā. Sāksim ar laikmetu, ko es parasti saucu par ā€œmonolÄ«tu laikmetuā€.

Monolīta laikmets

MonolÄ«ta laikmets ir 2000. gadu sākums, kad visas lietojumprogrammas bija monolÄ«tas ar daudzām atkarÄ«bām. AttÄ«stÄ«ba prasÄ«ja ilgu laiku. Tajā paŔā laikā serveru nebija daudz; mēs tos visus zinājām pēc vārda un uzraudzÄ«jām. Ir tāds jocÄ«gs salÄ«dzinājums:

MājdzÄ«vnieki ir mājdzÄ«vnieki. MonolÄ«tā laikmetā mēs pret saviem serveriem izturējāmies kā pret mājdzÄ«vniekiem, koptiem un lolotiem, izpÅ«Å”ot putekļu plankumus. Un labākai resursu pārvaldÄ«bai izmantojām virtualizāciju: paņēmām serveri un sagriezām to vairākās virtuālajās maŔīnās, tādējādi nodroÅ”inot vides izolāciju.

Uz hipervizoriem balstītas virtualizācijas sistēmas

Ikviens droÅ”i vien ir dzirdējis par virtualizācijas sistēmām: VMware, VirtualBox, Hyper-V, Qemu KVM uc Tās nodroÅ”ina lietojumprogrammu izolāciju un resursu pārvaldÄ«bu, taču tām ir arÄ« trÅ«kumi. Lai veiktu virtualizāciju, jums ir nepiecieÅ”ams hipervizors. Un hipervizors ir papildu resurss. Un pati virtuālā maŔīna parasti ir vesels koloss - smags attēls, kurā ir operētājsistēma, Nginx, Apache un, iespējams, MySQL. Attēls ir liels, un virtuālās maŔīnas darbÄ«ba ir neērta. Rezultātā darbs ar virtuālajām maŔīnām var bÅ«t lēns. Lai atrisinātu Å”o problēmu, tika izveidotas virtualizācijas sistēmas kodola lÄ«menÄ«.

Kodola līmeņa virtualizācijas sistēmas

Kodola lÄ«meņa virtualizāciju atbalsta OpenVZ, Systemd-nspawn, LXC sistēmas. Spilgts Ŕādas virtualizācijas piemērs ir LXC (Linux Containers).

LXC ir operētājsistēmas lÄ«meņa virtualizācijas sistēma vairāku izolētu Linux operētājsistēmas gadÄ«jumu darbināŔanai vienā mezglā. LXC neizmanto virtuālās maŔīnas, bet veido virtuālo vidi ar savu procesu telpu un tÄ«kla steku.

Būtībā LXC izveido konteinerus. Kāda ir atŔķirība starp virtuālajām maŔīnām un konteineriem?

Kas ir Docker: īsa ekskursija vēsturē un pamata abstrakcijās

Konteiners nav piemērots procesu izolÄ“Å”anai: virtualizācijas sistēmās kodola lÄ«menÄ« tiek atrastas ievainojamÄ«bas, kas ļauj tām izkļūt no konteinera uz saimniekdatoru. Tāpēc, ja jums ir nepiecieÅ”ams kaut ko izolēt, labāk ir izmantot virtuālo maŔīnu.

AtŔķirÄ«bas starp virtualizāciju un konteinerizāciju var redzēt diagrammā.
Ir aparatūras hipervizori, hipervizori virs OS un konteineri.

Kas ir Docker: īsa ekskursija vēsturē un pamata abstrakcijās

AparatÅ«ras hipervizori ir lieliski, ja patieŔām vēlaties kaut ko izolēt. Jo ir iespējams izolēt atmiņas lapu un procesoru lÄ«menÄ«.

Ir hipervizori kā programma, un ir konteineri, un mēs par tiem runāsim tālāk. Konteineru sistēmām nav hipervizora, bet ir konteineru dzinējs, kas izveido un pārvalda konteinerus. Šī lieta ir vieglāka, tāpēc, strādājot ar kodolu, ir mazāks pieskaitījums vai to nav vispār.

Kas tiek izmantots konteinerizācijai kodola līmenī

Galvenās tehnoloģijas, kas ļauj izveidot no citiem procesiem izolētu konteineru, ir Namespaces un Control Groups.

Vārdtelpas: PID, Networking, Mount un User. Ir arī vairāk, taču, lai būtu vieglāk saprast, mēs koncentrēsimies uz tiem.

PID nosaukumvieta ierobežo procesus. Kad, piemēram, izveidojam PID nosaukumvietu un ievietojam tur procesu, tas kļūst ar PID 1. Parasti sistēmās PID 1 ir systemd vai init. AttiecÄ«gi, ievietojot procesu jaunā nosaukumvietā, tas saņem arÄ« PID 1.

Networking Namespace ļauj ierobežot/izolēt tÄ«klu un ievietot tajā savas saskarnes. Mount ir failu sistēmas ierobežojums. Lietotājs ā€” lietotāju ierobežojums.

VadÄ«bas grupas: atmiņa, centrālais procesors, IOPS, tÄ«kls - kopā aptuveni 12 iestatÄ«jumi. Citādi tos sauc arÄ« par C grupām (ā€œC grupāmā€).

Vadības grupas pārvalda konteinera resursus. Izmantojot kontroles grupas, mēs varam teikt, ka konteineram nevajadzētu patērēt vairāk par noteiktu resursu daudzumu.

Lai konteinerizācija darbotos pilnvērtīgi, tiek izmantotas papildu tehnoloģijas: Iespējas, Copy-on-write un citas.

Iespējas ir tad, kad mēs procesam sakām, ko tas var un ko nevar. Kodola lÄ«menÄ« tās ir vienkārÅ”i bitkartes ar daudziem parametriem. Piemēram, root lietotājam ir visas privilēģijas un viņŔ var darÄ«t visu. Laika serveris var mainÄ«t sistēmas laiku: tam ir Time Capsule iespējas, un tas arÄ« viss. Izmantojot privilēģijas, varat elastÄ«gi konfigurēt procesu ierobežojumus un tādējādi aizsargāt sevi.

Sistēma Copy-on-Write ļauj mums strādāt ar Docker attēliem un izmantot tos efektīvāk.

Docker paÅ”laik ir saderÄ«bas problēmas ar Cgroups v2, tāpēc Å”is raksts ir Ä«paÅ”i vērsts uz Cgroups v1.

Bet atgriezīsimies vēsturē.

Kad virtualizācijas sistēmas parādījās kodola līmenī, tās sāka aktīvi izmantot. Hipervizora pieskaitāmās izmaksas pazuda, bet dažas problēmas saglabājās:

  • lieli attēli: tajā paŔā OpenVZ iespiež operētājsistēmu, bibliotēkas, dažādas programmatÅ«ras, un galu galā attēls joprojām izrādās diezgan liels;
  • Nav normālu standartu iepakoÅ”anai un piegādei, tāpēc atkarÄ«bu problēma paliek. Pastāv situācijas, kad divas koda daļas izmanto vienu un to paÅ”u bibliotēku, bet ar dažādām versijām. Starp viņiem var rasties konflikts.

Lai atrisinātu visas Ŕīs problēmas, ir pienācis nākamais laikmets.

Konteineru laikmets

Kad pienāca konteineru laikmets, darba ar tiem filozofija mainījās:

  • Viens process - viens konteiners.
  • Mēs piegādājam visas procesam nepiecieÅ”amās atkarÄ«bas tā konteinerā. Tas prasa monolÄ«tu sagrieÅ”anu mikropakalpojumos.
  • Jo mazāks attēls, jo labāk - ir mazāk iespējamo ievainojamÄ«bu, tas izrullē ātrāk utt.
  • GadÄ«jumi kļūst Ä«slaicÄ«gi.

Atcerieties, ko es teicu par mājdzÄ«vniekiem pret liellopiem? IepriekÅ” gadÄ«jumi bija kā mājdzÄ«vnieki, bet tagad tie ir kļuvuÅ”i par liellopiem. IepriekÅ” bija monolÄ«ts - viens pieteikums. Tagad tie ir 100 mikropakalpojumi, 100 konteineri. Dažiem konteineriem var bÅ«t 2ā€“3 kopijas. Mums kļūst mazāk svarÄ«gi kontrolēt katru konteineru. Mums svarÄ«gāka ir paÅ”a pakalpojuma pieejamÄ«ba: ko dara Å”is konteineru komplekts. Tas maina pieejas monitoringam.

2014.ā€“2015. gadā uzplauka Docker ā€” tehnoloÄ£ija, par kuru mēs tagad runāsim.

Docker mainīja filozofiju un standartizēja lietojumprogrammu iepakojumu. Izmantojot Docker, mēs varam iepakot lietojumprogrammu, nosūtīt to uz repozitoriju, lejupielādēt no turienes un izvietot to.

Mēs ievietojam visu nepiecieÅ”amo Docker konteinerā, tāpēc atkarÄ«bas problēma ir atrisināta. Docker garantē reproducējamÄ«bu. Es domāju, ka daudzi cilvēki ir saskāruÅ”ies ar neproducējamÄ«bu: viss darbojas jÅ«su labā, jÅ«s to nospiežat uz ražoÅ”anu, un tur tas pārstāj darboties. Izmantojot Docker, Ŕī problēma pazÅ«d. Ja jÅ«su Docker konteiners sāk darboties un dara to, kas tam jādara, tad ar lielu varbÅ«tÄ«bas pakāpi tas sāks ražoÅ”anu un darÄ«s to paÅ”u.

Atkāpe par pieskaitāmajām izmaksām

Par pieskaitāmajām izmaksām vienmēr ir strÄ«di. Daži cilvēki uzskata, ka Docker nenes papildu slodzi, jo tas izmanto Linux kodolu un visus tā konteinerizÄ“Å”anai nepiecieÅ”amos procesus. Piemēram, "ja sakāt, ka Docker ir virs galvas, tad Linux kodols ir virs galvas."

No otras puses, ja iedziļināties, Docker patieŔām ir vairākas lietas, par kurām var teikt, ka tās ir virs galvas.

Pirmā ir PID nosaukumvieta. Kad mēs ievietojam procesu nosaukumvietā, tam tiek pieŔķirts PID 1. Tajā paŔā laikā Å”im procesam ir cits PID, kas atrodas resursdatora nosaukumvietā ārpus konteinera. Piemēram, mēs palaižām Nginx konteinerā, tas kļuva par PID 1 (galvenais process). Un resursdatorā tam ir PID 12623. Un ir grÅ«ti pateikt, cik lielas tās ir.

Otra lieta ir Cgrupas. Ņemsim Cgrupas pēc atmiņas, tas ir, spēju ierobežot konteinera atmiņu. Kad tas ir iespējots, tiek aktivizēti skaitÄ«tāji un atmiņas uzskaite: kodolam ir jāsaprot, cik lapas Å”im konteineram ir pieŔķirtas un cik vēl ir brÄ«vas. Tas, iespējams, ir pieskaitāmas izmaksas, taču es neesmu redzējis precÄ«zus pētÄ«jumus par to, kā tas ietekmē veiktspēju. Un es pats nepamanÄ«ju, ka lietojumprogramma, kas darbojas Docker, pēkŔņi piedzÄ«voja strauju veiktspējas zudumu.

Un vēl viena piezÄ«me par veiktspēju. Daži kodola parametri tiek nodoti no resursdatora uz konteineru. Jo Ä«paÅ”i daži tÄ«kla parametri. Tāpēc, ja vēlaties Docker palaist kaut ko augstas veiktspējas, piemēram, kaut ko tādu, kas aktÄ«vi izmantos tÄ«klu, tad jums vismaz ir jāpielāgo Å”ie parametri. Piemēram, daži nf_conntrack.

Par Docker koncepciju

Docker sastāv no vairākiem komponentiem:

  1. Docker Daemon ir tas pats Container Engine; palaiž konteinerus.
  2. Docker CII ir Docker pārvaldības utilīta.
  3. Dockerfile ā€” instrukcijas, kā izveidot attēlu.
  4. Attēls ā€” attēls, no kura tiek izritināts konteiners.
  5. Konteiners.
  6. Docker reģistrs ir attēlu repozitorijs.

Shematiski tas izskatās apmēram Ŕādi:

Kas ir Docker: īsa ekskursija vēsturē un pamata abstrakcijās

Docker dēmons darbojas vietnē Docker_host un palaiž konteinerus. Ir klients, kas sūta komandas: izveidojiet attēlu, lejupielādējiet attēlu, palaidiet konteineru. Docker dēmons dodas uz reģistru un izpilda tos. Docker klients var piekļūt gan lokāli (Unix ligzdai), gan caur TCP no attālā resursdatora.

Apskatīsim katru komponentu.

Docker dēmons - Ŕī ir servera daļa, tā darbojas resursdatorā: lejupielādē attēlus un palaiž no tiem konteinerus, izveido tÄ«klu starp konteineriem, apkopo žurnālus. Kad mēs sakām ā€œizveidi tēluā€, to dara arÄ« dēmons.

Docker CLI ā€” Docker klienta daļa, konsoles utilÄ«ta darbam ar dēmonu. Es atkārtoju, tas var darboties ne tikai lokāli, bet arÄ« tÄ«klā.

Pamatkomandas:

docker ps ā€” parādÄ«t konteinerus, kas paÅ”laik darbojas Docker resursdatorā.
docker images ā€” rādÄ«t lokāli lejupielādētos attēlus.
docker search <> - meklējiet attēlu reģistrā.
docker pull <> ā€” lejupielādējiet attēlu no reÄ£istra uz maŔīnu.
docker build < > - savāc attēlu.
docker palaist <> - palaidiet konteineru.
docker rm <> - izņemiet konteineru.
docker logs <> - konteineru baļķi
docker start/stop/restart <> - darbs ar konteineru

Ja apgÅ«stat Ŕīs komandas un esat pārliecināts par to lietoÅ”anu, uzskatiet, ka esat par 70% lietpratējs Docker lietotāja lÄ«menÄ«.

Dockerfile - instrukcijas attēla izveidoÅ”anai. GandrÄ«z katra instrukciju komanda ir jauns slānis. ApskatÄ«sim piemēru.

Kas ir Docker: īsa ekskursija vēsturē un pamata abstrakcijās

Šādi izskatās Dockerfile: komandas kreisajā pusē, argumenti labajā pusē. Katra komanda, kas ir Å”eit (un parasti rakstÄ«ta Dockerfile), izveido jaunu slāni attēlā.

Pat skatoties uz kreiso pusi, var aptuveni saprast, kas notiek. Mēs sakām: ā€œizveidojiet mums mapiā€ - tas ir viens slānis. ā€œPadariet mapi darba kārtÄ«bāā€ ir vēl viens slānis un tā tālāk. Kārta kÅ«ka atvieglo dzÄ«vi. Ja es izveidoju citu Dockerfile un mainu kaut ko pēdējā rindā ā€” es palaižu kaut ko citu, nevis ā€œpythonā€ ā€œmain.pyā€, vai instalēju atkarÄ«bas no cita faila, tad iepriekŔējie slāņi tiks atkārtoti izmantoti kā keÅ”atmiņa.

attēls - tas ir konteineru iepakojums; konteineri tiek palaisti no attēla. Ja skatāmies uz Docker no pakotņu pārvaldnieka viedokļa (it kā mēs strādātu ar deb vai rpm pakotnēm), tad attēls bÅ«tÄ«bā ir rpm pakotne. Izmantojot yum instalÄ“Å”anu, mēs varam instalēt lietojumprogrammu, izdzēst to, atrast to repozitorijā un lejupielādēt. Å eit ir apmēram tas pats: konteineri tiek palaisti no attēla, tie tiek glabāti Docker reÄ£istrā (lÄ«dzÄ«gi kā yum, repozitorijā), un katram attēlam ir SHA-256 jaucējvārds, nosaukums un atzÄ«me.

Attēls ir izveidots saskaņā ar instrukcijām no Dockerfile. Katrs Dockerfile norādījums izveido jaunu slāni. Slāņus var izmantot atkārtoti.

Docker reģistrs ir Docker attēlu repozitorijs. Līdzīgi kā OS, arī Docker ir publisks standarta reģistrs - dockerhub. Bet jūs varat izveidot savu repozitoriju, savu Docker reģistru.

Konteiners - kas tiek palaists no attēla. Mēs izveidojām attēlu saskaņā ar instrukcijām no Dockerfile, pēc tam palaižam to no Ŕī attēla. Å is konteiners ir izolēts no citiem konteineriem, un tajā ir jābÅ«t visam, kas nepiecieÅ”ams lietojumprogrammas darbÄ«bai. Å ajā gadÄ«jumā viens konteiners - viens process. Gadās, ka ir jāveic divi procesi, taču tas ir zināmā mērā pretrunā ar Docker ideoloÄ£iju.

PrasÄ«ba "viens konteiners, viens process" ir saistÄ«ta ar PID nosaukumvietu. Kad nosaukumvietā tiek sākts process ar PID 1, ja tas pēkŔņi nomirst, mirst arÄ« viss konteiners. Ja tur darbojas divi procesi: viens ir dzÄ«vs un otrs ir miris, tad konteiners joprojām turpinās dzÄ«vot. Bet tas ir paraugprakses jautājums, par to mēs runāsim citos materiālos.

Lai sÄ«kāk izpētÄ«tu kursa iespējas un pilnu programmu, lÅ«dzu, sekojiet saitei: ā€œDocker video kurss'.

Autors: Marcel Ibraev, sertificēts Kubernetes administrators, Southbridge praktizējoÅ”ais inženieris, runātājs un Slurm kursu izstrādātājs.

Avots: www.habr.com

Pievieno komentāru