Alkoi 10. elokuuta Slurmissa , jossa analysoimme sen kokonaan - perusabstraktioista verkkoparametreihin.
Tässä artikkelissa puhumme Dockerin historiasta ja sen tärkeimmistä abstraktioista: Image, Cli, Dockerfile. Luento on tarkoitettu aloittelijoille, joten se ei todennäköisesti kiinnosta kokeneita käyttäjiä. Ei tule verta, umpilisäystä tai syvää upotusta. Ihan perusasiat.
Mikä on Docker
Katsotaanpa Dockerin määritelmää Wikipediasta.
Docker on ohjelmisto, joka automatisoi sovellusten käyttöönoton ja hallinnan konttiympäristöissä.
Tästä määritelmästä ei tule mitään selvää. Erityisen epäselvää on, mitä "konttia tukevassa ympäristössä" tarkoittaa. Selvittääksemme, palataan ajassa taaksepäin. Aloitetaan aikakaudesta, jota kutsun perinteisesti "monoliittiseksi aikakaudeksi".
Monoliittinen aikakausi
Monoliittinen aikakausi on 2000-luvun alkua, jolloin kaikki sovellukset olivat monoliittisia, ja niissä oli joukko riippuvuuksia. Kehitys kesti kauan. Samaan aikaan palvelimia ei ollut paljon, me kaikki tunsimme ne nimeltä ja seurasimme niitä. Siinä on hauska vertailu:
Lemmikit ovat kotieläimiä. Monoliittisella aikakaudella kohtelimme palvelimiamme kuin lemmikkejä, hoidettiin ja vaalittiin, puhaltaen pois pölyhiukkasia. Ja parempaan resurssien hallintaan käytimme virtualisointia: otimme palvelimen ja leikkasimme sen useisiin virtuaalikoneisiin, mikä varmisti ympäristön eristäytymisen.
Hypervisor-pohjaiset virtualisointijärjestelmät
Kaikki ovat luultavasti kuulleet virtualisointijärjestelmistä: VMware, VirtualBox, Hyper-V, Qemu KVM jne. Ne tarjoavat sovellusten eristämisen ja resurssien hallinnan, mutta niissä on myös haittoja. Virtualisointiin tarvitaan hypervisor. Ja hypervisori on ylimääräinen resurssi. Ja itse virtuaalikone on yleensä kokonainen kolossi - raskas kuva, joka sisältää käyttöjärjestelmän, Nginxin, Apachen ja mahdollisesti MySQL:n. Kuva on suuri ja virtuaalikoneen käyttö hankalaa. Tämän seurauksena virtuaalikoneiden kanssa työskentely voi olla hidasta. Tämän ongelman ratkaisemiseksi luotiin virtualisointijärjestelmiä ydintasolla.
Ydintason virtualisointijärjestelmät
Ydintason virtualisointia tukevat OpenVZ-, Systemd-nspawn- ja LXC-järjestelmät. Silmiinpistävä esimerkki tällaisesta virtualisoinnista on LXC (Linux Containers).
LXC on käyttöjärjestelmätason virtualisointijärjestelmä useiden erillisten Linux-käyttöjärjestelmän esiintymien ajamiseen yhdessä solmussa. LXC ei käytä virtuaalikoneita, vaan luo virtuaalisen ympäristön, jossa on oma prosessitila ja verkkopino.
Pohjimmiltaan LXC luo säiliöitä. Mitä eroa on virtuaalikoneiden ja säiliöiden välillä?
Säiliö ei sovellu prosessien eristämiseen: virtualisointijärjestelmissä on ydintasolla haavoittuvuuksia, joiden avulla ne pääsevät säiliöstä isäntään. Siksi, jos sinun on eristettävä jotain, on parempi käyttää virtuaalikonetta.
Erot virtualisoinnin ja konteioinnin välillä näkyvät kaaviossa.
On laitteistohypervisoreita, käyttöjärjestelmän päällä olevia hypervisoreita ja säiliöitä.
Laitteiston hypervisorit ovat siistejä, jos haluat todella eristää jotain. Koska se on mahdollista eristää muistisivujen ja prosessorien tasolla.
On olemassa hypervisoreita ohjelmana, ja on kontteja, ja puhumme niistä lisää. Konttijärjestelmissä ei ole hypervisoria, mutta on olemassa Container Engine, joka luo ja hallitsee kontteja. Tämä esine on kevyempi, joten ytimen kanssa työskentelyn vuoksi ylimääräistä on vähemmän tai ei ollenkaan.
Mitä käytetään säilöntämiseen ydintasolla
Tärkeimmät tekniikat, joiden avulla voit luoda muista prosesseista eristetyn säilön, ovat nimiavaruudet ja ohjausryhmät.
Nimiavaruudet: PID, Networking, Mount ja User. Niitä on enemmänkin, mutta ymmärtämisen helpottamiseksi keskitymme näihin.
PID-nimiavaruus rajoittaa prosesseja. Kun esimerkiksi luodaan PID-nimiavaruus ja sijoitetaan sinne prosessi, siitä tulee PID 1. Yleensä järjestelmissä PID 1 on systemd tai init. Vastaavasti kun sijoitamme prosessin uuteen nimiavaruuteen, se saa myös PID 1:n.
Verkkonimiavaruuden avulla voit rajoittaa/eristää verkkoa ja sijoittaa siihen omia liitäntöjä. Mount on tiedostojärjestelmän rajoitus. Käyttäjä — rajoitus käyttäjille.
Ohjausryhmät: Muisti, CPU, IOPS, Verkko - yhteensä noin 12 asetusta. Muuten niitä kutsutaan myös C-ryhmiksi ("C-ryhmät").
Ohjausryhmät hallitsevat säilön resursseja. Ohjausryhmien kautta voimme sanoa, että kontti ei saa kuluttaa enemmän kuin tietty määrä resursseja.
Jotta kontti toimisi täysin, käytetään lisätekniikoita: Ominaisuudet, Kopioi-kirjoitus ja muut.
Valmiudet ovat sitä, kun kerromme prosessille, mitä se voi tehdä ja mitä ei. Ytimen tasolla nämä ovat yksinkertaisesti bittikarttoja, joissa on monia parametreja. Esimerkiksi pääkäyttäjällä on täydet oikeudet ja hän voi tehdä kaiken. Aikapalvelin voi muuttaa järjestelmän aikaa: sillä on ominaisuudet Time Capsulessa, ja siinä se. Oikeuksien avulla voit joustavasti määrittää rajoituksia prosesseille ja siten suojata itseäsi.
Copy-on-write -järjestelmän avulla voimme työskennellä Docker-kuvien kanssa ja käyttää niitä tehokkaammin.
Dockerilla on tällä hetkellä yhteensopivuusongelmia Cgroups v2:n kanssa, joten tämä artikkeli keskittyy erityisesti Cgroups v1:een.
Mutta palataanpa historiaan.
Kun virtualisointijärjestelmät ilmestyivät ydintasolle, niitä alettiin käyttää aktiivisesti. Hypervisorin yläraja hävisi, mutta joitain ongelmia säilyi:
- suuret kuvat: ne työntävät käyttöjärjestelmän, kirjastot, joukon erilaisia ohjelmistoja samaan OpenVZ:hen, ja lopulta kuva osoittautuu silti melko suureksi;
- Pakkaamiselle ja toimitukselle ei ole olemassa normaalia standardia, joten riippuvuuksien ongelma on edelleen olemassa. On tilanteita, joissa kaksi koodin osaa käyttää samaa kirjastoa, mutta eri versioilla. Niiden välillä voi olla ristiriita.
Kaikkien näiden ongelmien ratkaisemiseksi on tullut seuraava aikakausi.
Konttien aikakausi
Kun konttien aikakausi saapui, heidän kanssaan työskentelyn filosofia muuttui:
- Yksi prosessi - yksi säiliö.
- Toimitamme kaikki prosessin tarvitsemat riippuvuudet konttiinsa. Tämä edellyttää monoliittien leikkaamista mikropalveluiksi.
- Mitä pienempi kuva, sitä parempi - mahdollisia haavoittuvuuksia on vähemmän, se tulee nopeammin esiin ja niin edelleen.
- Tapauksista tulee lyhytaikaisia.
Muistatko mitä sanoin lemmikeistä vs karjasta? Aiemmin tapaukset olivat kuin kotieläimet, mutta nyt niistä on tullut kuin karjaa. Aiemmin oli monoliitti - yksi sovellus. Nyt se on 100 mikropalvelua, 100 konttia. Joissakin säilöissä voi olla 2–3 kopiota. Meidän on vähemmän tärkeää hallita jokaista konttia. Meille tärkeämpää on itse palvelun saatavuus: mitä tämä konttisarja tekee. Tämä muuttaa lähestymistapoja seurantaan.
Vuosina 2014-2015 Docker kukoisti - tekniikka, josta puhumme nyt.
Docker muutti filosofiaa ja standardoi sovelluspakkauksia. Dockerin avulla voimme pakata sovelluksen, lähettää sen arkistoon, ladata sen sieltä ja ottaa sen käyttöön.
Laitamme kaiken tarvitsemamme Docker-konttiin, joten riippuvuusongelma on ratkaistu. Docker takaa toistettavuuden. Luulen, että monet ovat kohdanneet uusintamattomuuden: kaikki toimii sinulle, työnnät sen tuotantoon, ja siellä se lakkaa toimimasta. Dockerin avulla tämä ongelma poistuu. Jos Docker-konttisi käynnistyy ja tekee sen, mitä sen pitää tehdä, se käynnistyy suurella todennäköisyydellä tuotannon ja tekee samoin siellä.
Poikkeama yleiskustannuksista
Yleiskuluista on aina kiistoja. Jotkut uskovat, että Docker ei kanna ylimääräistä kuormaa, koska se käyttää Linux-ydintä ja kaikkia sen konttia varten tarvittavia prosesseja. Kuten "jos sanot, että Docker on yläpuolella, niin Linux-ydin on yläpuolella."
Toisaalta, jos mennään syvemmälle, Dockerissa on todellakin useita asioita, joiden voidaan venyneenä sanoa olevan yläpuolella.
Ensimmäinen on PID-nimiavaruus. Kun sijoitamme prosessin nimiavaruuteen, sille annetaan PID 1. Samaan aikaan tällä prosessilla on toinen PID, joka sijaitsee isäntänimiavaruudessa kontin ulkopuolella. Esimerkiksi käynnistimme Nginxin kontissa, siitä tuli PID 1 (master process). Ja isännässä sen PID 12623. Ja on vaikea sanoa, kuinka paljon se on.
Toinen asia on Cgroups. Otetaan C-ryhmät muistin mukaan, eli kyky rajoittaa kontin muistia. Kun se on käytössä, laskurit ja muistikirjanpito aktivoidaan: ytimen on ymmärrettävä kuinka monta sivua on varattu ja kuinka monta on vielä vapaana tälle säilölle. Tämä on mahdollisesti yleiskustannuksia, mutta en ole nähnyt tarkkoja tutkimuksia siitä, miten se vaikuttaa suorituskykyyn. Enkä itse huomannut, että Dockerissa käynnissä olevan sovelluksen suorituskyky heikkeni yhtäkkiä jyrkästi.
Ja vielä yksi huomio suorituskyvystä. Jotkut ytimen parametrit välitetään isännästä säilöön. Erityisesti jotkin verkkoparametrit. Siksi, jos haluat ajaa jotain erittäin suorituskykyistä Dockerissa, esimerkiksi jotain, joka käyttää aktiivisesti verkkoa, sinun on ainakin säädettävä näitä parametreja. Jotkin nf_conntrack, esimerkiksi.
Tietoja Docker-konseptista
Docker koostuu useista osista:
- Docker Daemon on sama Container Engine; laukaisee kontteja.
- Docker CII on Dockerin hallintaapuohjelma.
- Dockerfile - ohjeet kuvan rakentamiseen.
- Kuva — kuva, josta säiliö rullataan ulos.
- Kontti.
- Docker-rekisteri on kuvavarasto.
Kaavamaisesti se näyttää suunnilleen tältä:
Docker-daemon toimii Docker_hostilla ja käynnistää säilöjä. Siellä on asiakasohjelma, joka lähettää komennot: rakenna kuva, lataa kuva, käynnistä säilö. Docker-daemon menee rekisteriin ja suorittaa ne. Docker-asiakas voi käyttää sekä paikallisesti (Unix-liitäntään) että TCP:n kautta etäisännästä.
Käydään läpi jokainen komponentti.
Docker-daemon - tämä on palvelinosa, se toimii isäntäkoneella: lataa kuvia ja käynnistää niistä säilöjä, luo verkon säilöjen välille, kerää lokeja. Kun sanomme "luo kuva", myös demoni tekee niin.
Docker CLI — Docker-asiakasosa, konsoliapuohjelma demonin kanssa työskentelemiseen. Toistan, se voi toimia paitsi paikallisesti myös verkon yli.
Peruskomennot:
docker ps - näytä säilöjä, jotka ovat tällä hetkellä käynnissä Docker-isännässä.
telakointikuvat - näytä paikallisesti ladatut kuvat.
docker search <> - etsi kuva rekisteristä.
docker pull <> - lataa kuva rekisteristä koneeseen.
telakka rakentaa < > - kerää kuva.
docker run <> - käynnistä kontti.
docker rm <> - poista säiliö.
telakointilokit <> - konttilokit
docker start/stop/restart <> - työskentelee kontin kanssa
Jos hallitset nämä komennot ja olet varma niiden käytössä, pidä itsesi 70 % Dockerin taitamisesta käyttäjätasolla.
Dockerfile - ohjeet kuvan luomiseen. Lähes jokainen käskykomento on uusi kerros. Katsotaanpa esimerkkiä.
Dockerfile näyttää tältä: komennot vasemmalla, argumentit oikealla. Jokainen tässä oleva komento (ja yleensä Docker-tiedostoon kirjoitettu) luo uuden kerroksen Image-tiedostoon.
Jopa katsomalla vasemmalle puolelle, voit karkeasti ymmärtää mitä tapahtuu. Sanomme: "luo meille kansio" - tämä on yksi kerros. "Tee kansiosta toimiva" on toinen kerros ja niin edelleen. Kerroskakku helpottaa elämää. Jos luon toisen Docker-tiedoston ja muutan jotain viimeisellä rivillä - suoritan jotain muuta kuin "python" "main.py" tai asenna riippuvuuksia toisesta tiedostosta - aiempia kerroksia käytetään uudelleen välimuistina.
Kuva - tämä on konttipakkausta; kontit laukaistaan kuvasta. Jos katsomme Dockeria paketinhallinnan näkökulmasta (ikään kuin työskentelisimme deb- tai rpm-pakettien kanssa), kuva on pohjimmiltaan rpm-paketti. Yum-asennuksen avulla voimme asentaa sovelluksen, poistaa sen, löytää sen arkistosta ja ladata sen. Se on suunnilleen sama täällä: säilöt käynnistetään kuvasta, ne tallennetaan Docker-rekisteriin (samanlainen kuin yum, arkistossa), ja jokaisessa kuvassa on SHA-256-tiiviste, nimi ja tagi.
Kuva on rakennettu Dockerfilen ohjeiden mukaan. Jokainen Docker-tiedoston käsky luo uuden kerroksen. Kerroksia voidaan käyttää uudelleen.
Dockerin rekisteri on Docker-kuvavarasto. Kuten käyttöjärjestelmässä, Dockerissa on julkinen standardirekisteri - dockerhub. Mutta voit rakentaa oman arkiston, oman Docker-rekisterin.
Kontti - mitä kuvasta käynnistetään. Rakensimme kuvan Dockerfile-tiedoston ohjeiden mukaan, minkä jälkeen käynnistämme sen tästä kuvasta. Tämä säilö on eristetty muista säilöistä, ja sen tulee sisältää kaikki sovelluksen toimintaan tarvittava. Tässä tapauksessa yksi säiliö - yksi prosessi. Tapahtuu, että sinun on suoritettava kaksi prosessia, mutta tämä on jossain määrin vastoin Docker-ideologiaa.
"Yksi säiliö, yksi prosessi" -vaatimus liittyy PID-nimiavaruuteen. Kun prosessi, jossa on PID 1, alkaa nimiavaruudessa, jos se yhtäkkiä kuolee, myös koko säilö kuolee. Jos siellä on käynnissä kaksi prosessia: toinen on elossa ja toinen on kuollut, kontti jatkaa edelleen elämäänsä. Mutta tämä on kysymys parhaista käytännöistä, puhumme niistä muissa materiaaleissa.
Tutustuaksesi kurssin ominaisuuksiin ja koko ohjelmaan tarkemmin, seuraa linkkiä: “'.
Kirjoittaja: Marcel Ibraev, sertifioitu Kubernetes-järjestelmänvalvoja, Southbridgen harjoitteleva insinööri, puhuja ja Slurm-kurssien kehittäjä.
Lähde: will.com