MĂ« 10 gusht filloi nĂ« SlyĂ«rm , nĂ« tĂ« cilin e shqyrtojmĂ« PlotĂ«sisht â nga abstraksionet kryesore deri te parametrat e rrjetit.
Në këtë artikull do të flasim për historinë e shfaqjes së Docker dhe abstraksionet e tij kryesore: Imazhi, Cli, Dockerfile. Kjo ligjëratë është e destinuar për fillestarët, ndaj rrallëherë do të jetë interesante për përdoruesit me përvojë. Këtu nuk do të ketë gjak, apendiks dhe përfshirje të thellë. Vetëm të dhënat e para.
ĂfarĂ« Ă«shtĂ« Docker
Le të shohim definimin e Docker nga Wikipedia.
Docker është një softuer për automatizimin e shpërndarjes dhe menaxhimit të aplikacioneve në mjedise me mbështetje për kontejnerizimin.
Nga kjo përkufizim nuk kuptohet asgjë. Veçanërisht nuk është e qartë se çfarë do të thotë "në mjedise me mbështetje për kontejnerizimin". Për t'u sqaruar, le të kthehemi në të kaluarën. Le të fillojmë me epokën, të cilën unë e quaj "Epoka Monolitike".
Epoka Monolitike
Epoka Monolitike është fillimi i viteve 2000, kur të gjitha aplikacionet ishin monolitike, me shumë varësi. Zhvillimi shkonte ngadalë. Në këtë kohë, serverët nuk ishin aq të shumtë, ne i njihnim gjithashtu me emra dhe i monitoronim. Ka një krahasim interesante:
KafshĂ« shtĂ«piake â janĂ« kafshĂ«t qĂ« jetojnĂ« nĂ« shtĂ«pi. NĂ« epokĂ«n monolitike i trajtonim serverĂ«t tanĂ« si kafshĂ« shtĂ«piake, i kujdesnim dhe i pĂ«rkĂ«dhelnim, duke fryrĂ« pluhurin. PĂ«r menaxhimin mĂ« tĂ« mirĂ« tĂ« burimeve, pĂ«rdornim virtualizimin: merrnim njĂ« server dhe e ndanim nĂ« disa makina virtuale, duke siguruar kĂ«shtu izolimin e mjedisit.
Sistemet e virtualizimit bazuar në hipervizor
PĂ«r sistemet e virtualizimit sigurisht qĂ« tĂ« gjithĂ« kanĂ« dĂ«gjuar: VMware, VirtualBox, Hyper-V, Qemu KVM etj. Ato ofrojnĂ« izolimin e aplikacioneve dhe menaxhimin e burimeve, por kanĂ« dhe disavantazhe. PĂ«r tĂ« realizuar virtualizimin, nevojitet njĂ« hipervizor. Dhe hipervizori Ă«shtĂ« njĂ« ngarkesĂ« pĂ«r burimet. Gjithashtu, makina virtuale shpesh Ă«shtĂ« njĂ« masĂ« e madhe â njĂ« imazh i rĂ«ndĂ«, mbi tĂ« Ă«shtĂ« sistemi operativ, Nginx, Apache, ndoshta edhe MySQL. Imazhi Ă«shtĂ« i madh, Ă«shtĂ« e vĂ«shtirĂ« tĂ« operosh me makinĂ«n virtuale. Si rezultat, puna me virtualizimet mund tĂ« jetĂ« e ngadalshme. PĂ«r tĂ« zgjidhur kĂ«tĂ« problem, u krijuan sistemet e virtualizimit nĂ« nivelin e bĂ«rthamĂ«s.
Sistemet e virtualizimit në nivelin e bërthamës
Virtualizimi në nivelin e bërthamës mbështetet nga sistemet OpenVZ, Systemd-nspawn, LXC. Një shembull i kësaj virtualizimi është LXC (Kontejnerët Linux).
LXC është një sistem virtualizimi në nivelin e sistemit operativ për të drejtuar disa kopje të izoluara të sistemit operativ Linux në një nod. LXC nuk përdor makina virtuale, por krijon një mjedis virtual me hapësirën e tij të proceseve dhe një stek rrjeti.
NĂ« thelb, LXC krijon kontejnerĂ«. ĂfarĂ« Ă«shtĂ« diferenca midis makineve virtuale dhe kontejnerĂ«ve?
Kontejneri nuk është i përshtatshëm për izolimin e proceseve: në sistemet e virtualizimit në nivelin e bërthamës gjenden dobësi që lejojnë daljen nga kontejneri në host. Prandaj, nëse keni nevojë për izolim, është më mirë të përdorni një makinë virtuale.
Dallimet midis virtualizimit dhe kontejnerizimit mund të shihen në diagram.
Ka hipervizorë harduerikë, hipervizorë mbi OS dhe kontejnerë.
Hipervizorët 'harduerë' janë një gjë e shkëlqyer nëse vërtet dëshironi të izoloni diçka. Sepse atje ka mundësinë për të izoluar në nivelin e faqeve të memories dhe procesorëve.
Ekzistojnë hypervizorë si program, dhe ka konteinerë, për ta do të flasim më pas. Në sistemet e konteinerizimit nuk ka hypervizor, por ka Container Engine, i cili krijon dhe menaxhon kontejnerët. Kjo është më e lehtë, kështu që për shkak të funksionimit me bërthamën, mbingarkesa është më e vogël, ose nuk ekziston fare.
ĂfarĂ« pĂ«rdoret pĂ«r konteinerizim nĂ« nivel bĂ«rthamor
Teknologjitë kryesore që lejojnë krijimin e një kontejneri të izoluar nga proceset e tjera janë Namespaces dhe Control Groups.
Namespaces: PID, Networking, Mount dhe User. Ka edhe të tjera, por për thjeshtësinë e kuptimit do të ndalemi te këto.
PID Namespace kufizon proceset. Kur krijojmë një PID Namespace dhe vendosim një proces atje, ai bëhet me PID 1. Zakonisht në sistemet, PID 1 është systemd ose init. Prandaj, kur e vendosim procesin në një namespace të ri, ai merr gjithashtu PID 1.
Networking Namespace lejon kufizimin/izolimin e rrjetit dhe brenda tij shpërndajmë ndërfaqet tona. Mount është një kufizim për sistemin e skedarëve. User është kufizim për përdoruesit.
Control Groups: Memory, CPU, IOPS, Network â gjithsej rreth 12 cilĂ«sime. Ndryshe i quajnĂ« edhe Cgroups ("C- grupe").
Grupet e Kontrollit menaxhojnë burimet për kontejnerin. Përmes Grupet e Kontrollit ne mund të themi se kontejneri nuk duhet të konsumojë më shumë sesa një sasi e caktuar burimesh.
Për të siguruar funksionimin e plotë të kontejnerizimit, përdoren teknologji shtesë: Kapacitetet, Kopje-në-shkrim dhe të tjera.
Kapacitetet janë ato kur i themi procesit se çfarë mund dhe çfarë nuk mund të bëjë. Në nivelin e bërthamës, kjo është thjesht një harta bitore me shumë parametra. Për shembull, përdoruesi root ka privilegje të plota, mund të bëjë gjithçka. Serveri i kohës mund të ndryshojë kohën sistemike: ai ka kapacitete për Capsule të Kohës, dhe mjafton. Me anë të privilegjeve mund të konfigurohen fleksibilisht kufizimet për proceset, duke siguruar kështu mbrojtje.
Sistemi Kopje-në-shkrim na lejon të punojmë me imazhet Docker, duke i përdorur ato në mënyrë më efikase.
Aktualisht, Docker ka probleme me kompatibilitetin e Cgroups v2, prandaj në këtë artikull shqyrtohen pikërisht Cgroups v1.
Por le të kthehemi në histori.
Kur u shfaqën sistemet e virtualizimit në nivelin e bërthamës, ato filluan të përdoren masivisht. Overhead-i në hipervizor u zhduk, por disa probleme mbetën:
- imazhe të mëdha: në të njëjtën OpenVZ shtyhet sistemi operativ, bibliotekat, një mori softuerësh të ndryshëm, dhe në fund imazhi përfundon duke u bërë akoma i madh.
- nuk ka një standard normal për paketimin dhe dorëzimin, kështu që problemi i varësive mbetet. Ka raste kur dy copë kodi përdorin një bibliotekë, por me versione të ndryshme. Ndërmjet tyre mund të ndodhë një konflikt.
Për të zgjidhur të gjitha këto probleme, erdhi epoka e ardhshme.
Epoka e kontejnerëve
Kur erdhi Epoka e kontejnerëve, u ndryshua filozofia e punës me to:
- NjĂ« proces â njĂ« kontejner.
- Të gjitha varësitë e nevojshme për procesin dërgohen në kontejnerin e tij. Kjo kërkon ndarjen e monoliteve në mikrosherbime.
- Sa mĂ« i vogĂ«l tĂ« jetĂ« imazhi, aq mĂ« mirĂ« â mĂ« pak mundĂ«si pĂ«r dobĂ«si, shpejtĂ«si mĂ« tĂ« madhe nĂ« implementim dhe kĂ«shtu me radhĂ«.
- Instancat bëhen efemerale.
A e dini, unĂ« thashĂ« pĂ«r kafshĂ«t shtĂ«piake dhe lopĂ«t? Disa kohĂ« mĂ« parĂ«, instancat ishin si kafshĂ«t shtĂ«piake, ndĂ«rsa tani janĂ« si lopĂ«t â bagĂ«ti. Disa kohĂ« mĂ« parĂ«, kishte njĂ« monolit â njĂ« aplikacion tĂ« vetĂ«m. Tani ka 100 mikroshĂ«rbime, 100 kontejnerĂ«. Disa nga kĂ«ta kontejnerĂ« mund tĂ« kenĂ« 2-3 replika. Nuk Ă«shtĂ« kaq e rĂ«ndĂ«sishme tĂ« kontrollojmĂ« çdo kontejner. E rĂ«ndĂ«sishme Ă«shtĂ« disponueshmĂ«ria e shĂ«rbimit: asaj qĂ« bĂ«jnĂ« kĂ«to grupe kontejnerĂ«sh. Kjo ndryshon qasjen tonĂ« nĂ« monitorim.
NĂ« vitet 2014-2015, ndodhi lulĂ«zimi i Docker â asaj teknologjie pĂ«r tĂ« cilĂ«n do tĂ« flasim tani.
Docker ndryshoi filozofinë dhe standardizoi paketimin e aplikacioneve. Me ndihmën e Docker, ne mund të paketojmë aplikacionin, ta dërgojmë në një depo, ta shkarkojmë nga aty dhe ta vendosim.
Në kontejnerin Docker ne përfshijmë gjithçka që nevojitet, kështu që problemi i varësive zgjidhet. Docker garanton riprodhueshmërinë. Mendoj se shumë janë përballur me mosriprodhueshmërinë: gjithçka funksionon, e shtyjmë në prodhim, dhe atje fillon të mos funksionojë. Me Docker, ky problem zhduket. Nëse kontejneri yt Docker niset dhe bën atë që duhet të bëjë, atëherë me një probabilitet të madh ai do të niset në prodhim dhe do të bëjë të njëjtën gjë atje.
Një shpjegim mbi overhead-in
Për overhead-in vazhdimisht ka polemika. Disa mendojnë se Docker nuk sjell ngarkesë shtesë, pasi përdor bërthamën Linux dhe të gjitha proceset e saj që janë të nevojshme për kontejnerizimin. Siç thonë, "nëse thoni se Docker është overhead, atëherë edhe bërthama Linux është overhead".
Nga ana tjetër, nëse thellohemi, në Docker vërtet ka disa gjëra për të cilat me një tërheqje mund të thuhet se janë overhead.
E para â Ă«shtĂ« PID namespace. Kur ne vendosim njĂ« proces nĂ« namespace, atij i caktohet PID 1. NdĂ«rkohĂ«, kjo proces ka njĂ« PID tjetĂ«r, i cili ndodhet nĂ« host namespace, jashtĂ« enĂ«ve. PĂ«r shembull, ne nisim Nginx nĂ« enĂ«, ai bĂ«het PID 1 (procesi master). NdĂ«rsa nĂ« host, ai ka PID 12623. Dhe Ă«shtĂ« e vĂ«shtirĂ« tĂ« thuash se sa Ă«shtĂ« ky overhead.
GjĂ«ja e dytĂ« â janĂ« Cgroups. TĂ« marrim Cgroups pĂ«r memorie, qĂ« do tĂ« thotĂ« mundĂ«sia pĂ«r tĂ« kufizuar memorinĂ« e enĂ«s. Kur ajo aktivizohet, aktivizohen numĂ«ruesit, memory accounting: bĂ«rthama duhet tĂ« kuptojĂ« sa faqe janĂ« ndarĂ« dhe sa janĂ« ende tĂ« lira pĂ«r kĂ«tĂ« enĂ«. Kjo mund tĂ« jetĂ« overhead, por nuk kam hasur ndonjĂ« studim tĂ« saktĂ« se si ndikon nĂ« performancĂ«. Dhe vetĂ« nuk kam vĂ«nĂ« re se njĂ« aplikacion i nisur nĂ« Docker papritur humbte shumĂ« nĂ« performancĂ«.
Dhe një vërejtje tjetër për performancën. Disa parametra të bërthamës kalojnë nga hosti në kontejner. Saktësisht, disa parametra rrjeti. Prandaj, nëse dëshironi të ekzekutoni diçka me performancë të lartë në Docker, si për shembull diçka që do të përdorë aktivisht rrjetin, duhet të përshtatni së paku këta parametra. Një parametër si nf_conntrack, për shembull.
Rreth konceptit të Docker
Docker përbëhet nga disa komponentë:
- Docker Daemon â ai Ă«shtĂ« motor kontenieri; ekzekuton kontejnerĂ«t.
- Docker CLI â utilitari pĂ«r menaxhimin e Docker.
- Dockerfile â udhĂ«zimi pĂ«r si tĂ« ndĂ«rtohet imazhi.
- Image â imazhi nga i cili krijohet kontejneri.
- Kontejner.
- Docker registry â depo imazhesh.
Përshtypja e kësaj duket afërsisht kështu:
Në Docker_host funksionon Docker daemon, i cili ekzekuton kontejnerët. Ka një klient, i cili dërgon komanda: ndërto imazh, shkarko imazh, ekzekuto kontejner. Docker daemon shkon në registry dhe i realizon ato. Klienti Docker mund të drejtohet edhe lokalisht (në soketin unix) dhe përmes TCP nga një host i largët.
Le të shohim çdo komponent.
Docker daemon (demon) â Ă«shtĂ« komponenti server, ai funksionon nĂ« makinĂ«n e host-it: shkarkon imazhe dhe i nis ato nĂ« konteinerĂ«, krijon njĂ« rrjet midis konteinerĂ«ve, mbledh loget. Kur themi "krijo imazh", kjo Ă«shtĂ« gjithashtu nĂ« duar tĂ« demonit.
Docker CLI â Ă«shtĂ« komponenti klient i Docker-it, njĂ« utilitar nĂ« konsolĂ« pĂ«r tĂ« punuar me demonin. Po e pĂ«rsĂ«ris, ai mund tĂ« funksionojĂ« jo vetĂ«m lokal, por edhe pĂ«rmes rrjetit.
Commands bazike:
docker ps â tregoni konteinerĂ«t qĂ« janĂ« aktualisht nĂ« funksion nĂ« host-in Docker.
docker images â tregoni imazhet e shkarkuara lokalisht.
docker search <> â kĂ«rkoni njĂ« imazh nĂ« registry.
docker pull <> â shkarkoni njĂ« imazh nga registry nĂ« makinĂ«.
docker build <</path/to/dir>> â ndihmoni nĂ« ndĂ«rtimin e njĂ« imazhi.
docker run <> â nisni njĂ« konteiner.
docker rm <> â fshini njĂ« konteiner.
docker logs <> â loget e konteinerit
docker start/stop/restart <> â punoni me konteinerin
Nëse e zotëroni këto komanda dhe do t'i përdorni me besim, atëherë llogaritni se keni mësuar Docker në nivelin e përdoruesit me 70%.
Dockerfile â udhĂ«zimi pĂ«r tĂ« krijuar njĂ« imazh. Pothuajse çdo komandĂ« nĂ« udhĂ«zim Ă«shtĂ« njĂ« shtresĂ« e re. Le tĂ« shohim nĂ«pĂ«rmjet njĂ« shembulli.
Kjo Ă«shtĂ« si duket njĂ« Dockerfile: nga ana e majtĂ« komandat, nga ana e djathtĂ« â argumentet. Ădo komandĂ« qĂ« Ă«shtĂ« kĂ«tu (dhe nĂ« fakt shkruhet nĂ« Dockerfile) krijon njĂ« sloj tĂ« ri nĂ« Image.
Madje duke parĂ« pjesĂ«n e majtĂ«, mund tĂ« kuptojmĂ« pĂ«rafĂ«rsisht se çfarĂ« po ndodh. Ne po themi: "krijo na njĂ« dosje" â ky Ă«shtĂ« njĂ« sloj. "BĂ«je dosjen punuese" â ky Ă«shtĂ« njĂ« sloj tjetĂ«r, dhe kĂ«shtu me radhĂ«. Torta me shtresa e thjeshton jetĂ«n. NĂ«se krijoj njĂ« Dockerfile tjetĂ«r dhe nĂ« rreshtin e fundit ndryshoj diçka â nuk do ta ekzekutoj "python" "main.py", por diçka tjetĂ«r, ose do tĂ« instaloj varĂ«si nga njĂ« skedar tjetĂ«r â atĂ«herĂ« slojet e mĂ«parshme do tĂ« rishfrytĂ«zohen, si cache.
Image â kjo Ă«shtĂ« paketa e kontejnerit, nga imazhi fillojnĂ« kontejnerĂ«t. NĂ«se e shohim Docker nga kĂ«ndvĂ«shtrimi i menaxherit tĂ« paketave (si tĂ« punojmĂ« me deb ose rpm-paketat), atĂ«herĂ« imazhi â Ă«shtĂ« nĂ« thelb njĂ« rpm-paketĂ«. PĂ«rmes yum install mund tĂ« vendosim aplikacionin, ta fshijmĂ«, ta gjejmĂ« nĂ« depo, ta shkarkojmĂ«. KĂ«tu Ă«shtĂ« pĂ«rafĂ«rsisht e njĂ«jta gjĂ«: nga imazhi fillojnĂ« kontejnerĂ«t, ata ruhen nĂ« Docker registry (po ashtu si me yum, nĂ« depo), dhe çdo imazh ka njĂ« hash SHA-256, emĂ«r dhe tag.
Imazhi krijohet sipas udhĂ«zimeve nĂ« Dockerfile. Ădo udhĂ«zim nga Dockerfile krijon njĂ« shtresĂ« tĂ« re. Shtresat mund tĂ« rishfrytĂ«zohen.
Docker registry â Ă«shtĂ« njĂ« depo e imazheve Docker. NĂ« ngjashmĂ«ri me OS-nĂ«, Docker ka njĂ« regjistĂ«r publik standard â dockerhub. Por Ă«shtĂ« e mundur tĂ« krijoni regjistrin tuaj, Docker registry tuaj.
Konteineri â Ă«shtĂ« ajo qĂ« ekzekutohet nga imazhi. Nga udhĂ«zimi nĂ« Dockerfile krijuam imazhin, pastaj ne e ekzekutojmĂ« nga ky imazh. Ky kontejner Ă«shtĂ« i izoluar nga kontejnerĂ«t e tjerĂ« dhe duhet tĂ« pĂ«rmbajĂ« gjithçka tĂ« nevojshme pĂ«r funksionimin e aplikacionit. Gjithashtu, njĂ« kontejner â njĂ« proces. Ndodhin raste qĂ« duhet tĂ« krijoni dy procese, por kjo Ă«shtĂ« pak nĂ« kundĂ«rshtim me ideologjinĂ« e Docker.
KĂ«rkesa "njĂ« kontejner â njĂ« proces" lidhet me PID Namespace. Kur njĂ« proces startup me PID 1 nĂ« Namespace, nĂ«se ai ndalon papritur, atĂ«herĂ« i gjithĂ« kontejneri ndalon gjithashtu. NĂ«se aty janĂ« aktivizuar dy procese: njĂ« mbijeton, ndĂ«rsa tjetri ka vdekur, kontejneri do tĂ« vazhdojĂ« tĂ« jetojĂ«. Por kjo Ă«shtĂ« nĂ« lidhje me Praktikat mĂ« tĂ« Mira, ne do tĂ« flasim pĂ«r to nĂ« materiale tĂ« tjera.
Për të studiuar më në detaje veçoritë dhe programin e plotë të kursit, mund të ndiqni lidhjen: "».
Autori: Marsel Ibajev, administrator i certifikuar Kubernetes, inxhinier praktik në kompaninë Southbridge, folës dhe zhvillues kursesh në Slërm.
Burimi: habr.com
