Begin op 10 Augustus in Slurm , waarin ons dit volledig ontleed - van basiese abstraksies tot netwerkparameters.
In hierdie artikel sal ons praat oor die geskiedenis van Docker en sy belangrikste abstraksies: Image, Cli, Dockerfile. Die lesing is bedoel vir beginners, so dit is onwaarskynlik dat dit vir ervare gebruikers van belang sal wees. Daar sal geen bloed, blindederm of diep onderdompeling wees nie. Die heel basiese.
Wat is Docker
Kom ons kyk na die definisie van Docker van Wikipedia.
Docker is sagteware vir die outomatisering van die ontplooiing en bestuur van toepassings in houeromgewings.
Niks is duidelik uit hierdie definisie nie. Dit is veral onduidelik wat "in omgewings wat containerisering ondersteun" beteken. Om uit te vind, kom ons gaan terug in tyd. Kom ons begin met die era wat ek konvensioneel die "monolitiese era" noem.
Monolitiese era
Die monolitiese era is die vroeë 2000's, toe alle toepassings monolities was, met 'n klomp afhanklikhede. Ontwikkeling het lank geneem. Terselfdertyd was daar nie baie bedieners nie; ons het almal hulle by die naam geken en hulle gemonitor. Daar is so 'n snaakse vergelyking:
Troeteldiere is huisdiere. In die monolitiese era het ons ons bedieners soos troeteldiere behandel, versorg en gekoester, terwyl ons stofkolle wegwaai. En vir beter hulpbronbestuur het ons virtualisering gebruik: ons het 'n bediener geneem en dit in verskeie virtuele masjiene gesny, en sodoende isolasie van die omgewing verseker.
Hypervisor-gebaseerde virtualisasiestelsels
Almal het seker al gehoor van virtualisasiestelsels: VMware, VirtualBox, Hyper-V, Qemu KVM, ens. Hulle verskaf toepassingsisolasie en hulpbronbestuur, maar hulle het ook nadele. Om virtualisering te doen, benodig jy 'n hipervisor. En die hypervisor is 'n hulpbronbokoste. En die virtuele masjien self is gewoonlik 'n hele kolos - 'n swaar beeld wat 'n bedryfstelsel, Nginx, Apache, en moontlik MySQL bevat. Die beeld is groot en die virtuele masjien is ongerieflik om te bedryf. As gevolg hiervan kan dit stadig wees om met virtuele masjiene te werk. Om hierdie probleem op te los, is virtualisasiestelsels op kernvlak geskep.
Kernvlak-virtualiseringstelsels
Kernel-vlak virtualisering word ondersteun deur OpenVZ, Systemd-nspawn, LXC stelsels. 'n Treffende voorbeeld van sulke virtualisering is LXC (Linux Containers).
LXC is 'n bedryfstelselvlak-virtualiseringstelsel om verskeie geïsoleerde gevalle van die Linux-bedryfstelsel op 'n enkele nodus te laat loop. LXC gebruik nie virtuele masjiene nie, maar skep 'n virtuele omgewing met sy eie prosesruimte en netwerkstapel.
In wese skep LXC houers. Wat is die verskil tussen virtuele masjiene en houers?
Die houer is nie geskik om prosesse te isoleer nie: kwesbaarhede word gevind in virtualiseringstelsels op kernvlak wat hulle toelaat om van die houer na die gasheer te ontsnap. Daarom, as jy iets moet isoleer, is dit beter om 'n virtuele masjien te gebruik.
Die verskille tussen virtualisering en houerisering kan in die diagram gesien word.
Daar is hardeware hipervisors, hipervisors bo-op die OS, en houers.
Hardeware-hipervisors is gaaf as jy iets regtig wil isoleer. Omdat dit moontlik is om te isoleer op die vlak van geheue bladsye en verwerkers.
Daar is hiperviseerders as 'n program, en daar is houers, en ons sal verder daaroor praat. Houerstelsels het nie 'n hypervisor nie, maar daar is 'n Container Engine wat houers skep en bestuur. Hierdie ding is meer liggewig, so as gevolg van die werk met die kern is daar minder oorhoofse of glad nie.
Wat word gebruik vir containerisering op kernvlak
Die belangrikste tegnologieë wat jou toelaat om 'n houer te skep wat van ander prosesse geïsoleer is, is Naamruimtes en Beheergroepe.
Naamruimtes: PID, Netwerk, Mount en Gebruiker. Daar is meer, maar vir gemak van begrip sal ons hierop fokus.
PID-naamruimte beperk prosesse. Wanneer ons byvoorbeeld 'n PID Naamruimte skep en 'n proses daar plaas, word dit met PID 1. Gewoonlik in stelsels is PID 1 systemd of init. Gevolglik, wanneer ons 'n proses in 'n nuwe naamruimte plaas, ontvang dit ook PID 1.
Netwerknaamruimte laat jou toe om die netwerk te beperk/isoleer en jou eie koppelvlakke binne te plaas. Mount is 'n lêerstelselbeperking. Gebruiker—beperking op gebruikers.
Beheergroepe: Geheue, SVE, IOPS, Netwerk - ongeveer 12 instellings in totaal. Andersins word hulle ook C-groepe ("C-groepe") genoem.
Beheergroepe bestuur hulpbronne vir 'n houer. Deur Control Groups kan ons sê dat die houer nie meer as 'n sekere hoeveelheid hulpbronne moet verbruik nie.
Vir containerisering om ten volle te werk, word bykomende tegnologieë gebruik: vermoëns, Kopieer-op-skryf en ander.
Vermoëns is wanneer ons 'n proses vertel wat dit kan en nie kan doen nie. Op kernvlak is dit bloot bitmaps met baie parameters. Byvoorbeeld, die wortelgebruiker het volle voorregte en kan alles doen. Die tydbediener kan die stelseltyd verander: dit het vermoëns op die Time Capsule, en dit is dit. Deur gebruik te maak van voorregte, kan jy buigsaam beperkings vir prosesse instel, en sodoende jouself beskerm.
Die Kopieer-op-skryf-stelsel stel ons in staat om met Docker-beelde te werk en dit meer doeltreffend te gebruik.
Docker het tans versoenbaarheidsprobleme met Cgroups v2, so hierdie artikel fokus spesifiek op Cgroups v1.
Maar kom ons keer terug na die geskiedenis.
Toe virtualisasiestelsels op kernvlak verskyn het, het dit aktief begin gebruik word. Die oorhoofse koste op die hipervisor het verdwyn, maar 'n paar probleme het gebly:
- groot beelde: hulle druk 'n bedryfstelsel, biblioteke, 'n klomp verskillende sagteware in dieselfde OpenVZ, en op die ou end blyk die beeld nog steeds redelik groot te wees;
- Daar is geen normale standaard vir verpakking en aflewering nie, so die probleem van afhanklikhede bly steeds. Daar is situasies wanneer twee stukke kode dieselfde biblioteek gebruik, maar met verskillende weergawes. Daar kan 'n konflik tussen hulle wees.
Om al hierdie probleme op te los, het die volgende era aangebreek.
Houer-era
Toe die Era van Houers aanbreek, het die filosofie van werk met hulle verander:
- Een proses - een houer.
- Ons lewer al die afhanklikhede wat die proses nodig het aan sy houer. Dit vereis dat monoliete in mikrodienste gesny word.
- Hoe kleiner die beeld, hoe beter – daar is minder moontlike kwesbaarhede, dit rol vinniger uit, ensovoorts.
- Gevalle word kortstondig.
Onthou jy wat ek gesê het oor troeteldiere vs beeste? Voorheen was gevalle soos huisdiere, maar nou het hulle soos beeste geword. Voorheen was daar 'n monoliet - een toepassing. Nou is dit 100 mikrodienste, 100 houers. Sommige houers kan 2-3 replikas hê. Dit word vir ons minder belangrik om elke houer te beheer. Wat vir ons belangriker is, is die beskikbaarheid van die diens self: wat hierdie stel houers doen. Dit verander benaderings tot monitering.
In 2014-2015 het Docker gefloreer - die tegnologie waaroor ons nou sal praat.
Docker het die filosofie en gestandaardiseerde toepassingsverpakking verander. Deur Docker te gebruik, kan ons 'n toepassing verpak, dit na 'n bewaarplek stuur, dit van daar af aflaai en dit ontplooi.
Ons sit alles wat ons nodig het in die Docker-houer, sodat die afhanklikheidsprobleem opgelos is. Docker waarborg reproduceerbaarheid. Ek dink baie mense het onreproduceerbaarheid teëgekom: alles werk vir jou, jy druk dit na produksie, en daar hou dit op om te werk. Met Docker gaan hierdie probleem weg. As jou Docker-houer begin en doen wat dit moet doen, sal dit met 'n hoë mate van waarskynlikheid in produksie begin en dieselfde daar doen.
Afwyking oor bokoste
Daar is altyd dispute oor bokoste. Sommige mense glo dat Docker nie 'n bykomende vrag dra nie, aangesien dit die Linux-kern en al sy prosesse wat nodig is vir containerisering gebruik. Soos, "as jy sê dat Docker oorhoofs is, dan is die Linux-kern oorhoofs."
Aan die ander kant, as jy dieper gaan, is daar inderdaad verskeie dinge in Docker wat, met 'n rek, gesê kan word dat dit oorhoofs is.
Die eerste is PID-naamruimte. Wanneer ons 'n proses in 'n naamruimte plaas, word dit PID 1 toegeken. Terselfdertyd het hierdie proses 'n ander PID, wat op die gasheernaamruimte geleë is, buite die houer. Ons het byvoorbeeld Nginx in 'n houer bekendgestel, dit het PID 1 (meesterproses) geword. En op die gasheer het dit PID 12623. En dit is moeilik om te sê hoeveel van 'n oorhoofse koste dit is.
Die tweede ding is Cgroups. Kom ons neem Cgroups deur geheue, dit wil sê die vermoë om die geheue van 'n houer te beperk. Wanneer dit geaktiveer is, word tellers en geheuerekeningkunde geaktiveer: die kern moet verstaan hoeveel bladsye toegewys is en hoeveel nog vry is vir hierdie houer. Dit is moontlik 'n oorhoofse koste, maar ek het geen presiese studies gesien oor hoe dit prestasie beïnvloed nie. En ek self het nie opgemerk dat die toepassing wat in Docker loop, skielik 'n skerp verlies in prestasie ervaar het nie.
En nog 'n opmerking oor prestasie. Sommige kernparameters word van die gasheer na die houer oorgedra. In die besonder, sommige netwerk parameters. As u dus iets met hoë werkverrigting in Docker wil laat loop, byvoorbeeld iets wat die netwerk aktief sal gebruik, moet u ten minste hierdie parameters aanpas. Sommige nf_conntrack, byvoorbeeld.
Oor die Docker-konsep
Docker bestaan uit verskeie komponente:
- Docker Daemon is dieselfde Container Engine; houers bekendstel.
- Docker CII is 'n Docker-bestuursprogram.
- Dockerfile - instruksies oor hoe om 'n prent te bou.
- Beeld — die beeld waaruit die houer uitgerol word.
- Houer.
- Docker-register is 'n beeldbewaarplek.
Skematies lyk dit so iets:
Docker daemon loop op Docker_host en loods houers. Daar is 'n kliënt wat opdragte stuur: bou die prent, laai die prent af, begin die houer. Docker daemon gaan na die register en voer dit uit. Die Docker-kliënt kan beide plaaslik (na 'n Unix-sok) en via TCP vanaf 'n afgeleë gasheer toegang verkry.
Kom ons gaan deur elke komponent.
Docker daemon - dit is die bedienerdeel, dit werk op die gasheermasjien: laai beelde af en loods houers daaruit, skep 'n netwerk tussen houers, versamel logs. Wanneer ons sê "skep 'n beeld", doen die demoon dit ook.
Docker CLI - Docker-kliëntdeel, konsolehulpmiddel om met die daemon te werk. Ek herhaal, dit kan nie net plaaslik werk nie, maar ook oor die netwerk.
Basiese opdragte:
docker ps - wys houers wat tans op die Docker-gasheer loop.
docker-beelde - wys beelde wat plaaslik afgelaai is.
docker-soektog <> - soek vir 'n prent in die register.
docker pull <> - laai 'n prent van die register af na die masjien.
docker bou < > - versamel die beeld.
docker run <> - begin die houer.
docker rm <> - verwyder die houer.
docker logs <> - houer logs
docker begin/stop/herbegin <> - werk met die houer
As jy hierdie opdragte bemeester en selfversekerd is om dit te gebruik, beskou jouself as 70% vaardig in Docker op gebruikersvlak.
dockerfile - instruksies vir die skep van 'n beeld. Byna elke instruksieopdrag is 'n nuwe laag. Kom ons kyk na 'n voorbeeld.
Dit is hoe die Dockerfile lyk: opdragte aan die linkerkant, argumente aan die regterkant. Elke opdrag wat hier is (en oor die algemeen in die Dockerfile geskryf is) skep 'n nuwe laag in Beeld.
Selfs as jy na die linkerkant kyk, kan jy min of meer verstaan wat aan die gebeur is. Ons sê: "skep 'n gids vir ons" - dit is een laag. "Maak die gids werk" is 'n ander laag, ensovoorts. Laagkoek maak die lewe makliker. As ek 'n ander Dockerfile skep en iets in die laaste reël verander - ek hardloop iets anders as "python" "main.py", of installeer afhanklikhede vanaf 'n ander lêer - dan sal die vorige lae as 'n kas hergebruik word.
Image - dit is houerverpakking; houers word vanaf die prent geloods. As ons na Docker kyk vanuit die oogpunt van 'n pakketbestuurder (asof ons met deb- of rpm-pakkette werk), dan is beeld in wese 'n rpm-pakket. Deur yum install kan ons die toepassing installeer, dit uitvee, dit in die bewaarplek vind en dit aflaai. Dit is omtrent dieselfde hier: houers word vanaf die prent bekendgestel, hulle word in die Docker-register gestoor (soortgelyk aan yum, in 'n bewaarplek), en elke prent het 'n SHA-256-hash, 'n naam en 'n merker.
Beeld is gebou volgens die instruksies van die Dockerfile. Elke instruksie van die Dockerfile skep 'n nuwe laag. Lae kan hergebruik word.
Docker-register is 'n Docker-beeldbewaarplek. Soortgelyk aan die bedryfstelsel, het Docker 'n publieke standaardregister - dockerhub. Maar u kan u eie bewaarplek bou, u eie Docker-register.
Houer - wat vanaf die beeld geloods word. Ons het 'n prent gebou volgens die instruksies van die Dockerfile, dan begin ons dit vanaf hierdie prent. Hierdie houer is geïsoleer van ander houers en moet alles bevat wat nodig is vir die toepassing om te funksioneer. In hierdie geval, een houer - een proses. Dit gebeur dat jy twee prosesse moet doen, maar dit is ietwat in stryd met die Docker-ideologie.
Die "een houer, een proses"-vereiste hou verband met die PID-naamruimte. Wanneer 'n proses met PID 1 in Naamruimte begin, as dit skielik doodgaan, dan sterf die hele houer ook. As twee prosesse daar loop: een lewe en die ander is dood, dan sal die houer steeds bly lewe. Maar dit is 'n kwessie van beste praktyke, ons sal daaroor praat in ander materiaal.
Om die kenmerke en volledige program van die kursus in meer besonderhede te bestudeer, volg asseblief die skakel: "".
Skrywer: Marcel Ibraev, gesertifiseerde Kubernetes-administrateur, praktiserende ingenieur by Southbridge, spreker en ontwikkelaar van Slurm-kursusse.
Bron: will.com