Docker- ja konttioptimointi: täydellinen suorituskykyopas

Informatec Digital » Resurssit » Docker- ja konttioptimointi: täydellinen suorituskykyopas

Seuraavilta riveiltä löydät kattavan oppaan Docker-käyttöönottosi muuttamiseen paljon nopeammaksi, kevyemmäksi, turvallisemmaksi ja helpommin hallittavaksi ympäristöksi . Se on suunniteltu sekä nuoremmille kehittäjille että kokeneille DevOps-ammattilaisille, jotka haluavat tarkastella parhaita käytäntöjä, keskeisiä mittareita, Dockerfile-vinkkejä ja -niksejä, verkkoa, tallennusta, valvontaa ja hyödyllisiä komentoja, jotka tekevät todellisen eron päivittäisessä toiminnassa.

Miksi Docker-optimointi kannattaa viedä äärirajoille

Dockerin lupaus on selvä: pakkaat sovelluksesi kaikella tarvittavalla ja ajat sitä samalla tavalla missä tahansa, mutta saavuttaaksesi tämän hyvällä suorituskyvyllä sinun on hallittava huolellisesti, miten rakennat, ajat ja valvot säilöjäsi . Naiivin ja optimoidun lähestymistavan välinen ero voi olla valtava.

Dokumentoidussa tosielämän tapauksessa huonosti viritettyä toteutusta parannettiin vähitellen, mikä johti 36-kertaiseen rakennusajan lyhenemiseen ja 42-kertaiseen kuvan koon pienenemiseen . Tämä kaikki johtui päätöksistä, kuten paremman peruskuvan valitsemisesta, välimuistin paremmasta hyödyntämisestä, tasojen uudelleenjärjestelystä ja monivaiheisten koontien käytöstä. Ei käytetty mustaa magiaa, vain hyvin sovellettuja parhaita käytäntöjä.

Optimointi ei tarkoita pelkästään nopeutta: se tarkoittaa myös pienempää suorittimen ja RAM-muistin käyttöä VPS:lläsi, vähemmän verkkoliikennettä levykuvia haettaessa/työnnettäessä , nopeampia käynnistysaikoja, pienempää hyökkäyspintaa ja paljon tehokkaampaa CI/CD-sykliä. Toisin sanoen, sillä on suora vaikutus kustannuksiin, luotettavuuteen ja käyttökokemukseen.

Lisäksi hyvin optimoitu Docker-ympäristö sopii paremmin VPS- ja pilvialustoille , joissa on jo valmiiksi valvontatyökalut, SSD-tallennustila ja matalan latenssin verkot . Saat enemmän irti infrastruktuuristasi ilman jatkuvaa ylimitoitusta.

Lisäksi hyvin optimoitu Docker-ympäristö sopii paremmin VPS- ja pilvialustoille, joissa on jo valmiiksi valvontatyökalut, SSD-tallennustila ja matalan latenssin verkot . Saat enemmän irti infrastruktuuristasi ilman jatkuvaa ylimitoitusta.

Keskeiset mittarit konttiesi suorituskyvyn mittaamiseen

Ennen kuin alat muokata Dockerfiles-tiedostoja tai daemon-parametreja, sinun on oltava selvää, mitä aiot mitata ja miten tiedät, teetkö todella parannuksia . Ilman mittareita on mahdotonta havaita pullonkauloja tai varmistaa muutostesi vaikutusta.

Docker-konteissa seurattavia perusmittareita ovat suoritin, muisti, levyn I/O, verkko ja käynnistysaika . Näistä voit perehtyä sovellustason yksityiskohtiin (latenssi, läpimenoaika, virheet jne.).

Joitakin tärkeitä Dockerin suorituskykymittareita, joita on tärkeää seurata, ovat suorittimen käyttö konttia kohden, RAM- ja swap-muistin kulutus , tallennustilan luku-/kirjoitustoiminnot, verkon kaistanleveys, pakettien määrä sekunnissa ja aika, joka kuluu kontin käyttöönottoon käynnistyksen jälkeen.

Näiden tietojen keräämiseen käytössäsi on sekä sisäänrakennettuja työkaluja että kehittyneempiä havainnointiratkaisuja. Konsolitasolla komento docker stats Se näyttää reaaliaikaisia ​​tilastoja käynnissä olevista säilöistä. Tarkempaa tietoa varten cAdvisor näyttää yksityiskohtaiset mittarit säilökohtaisesti ja Prometheus yhdistettynä Grafanaan, on tosiasiallinen standardi koontinäyttöjen, hälytysten ja aikasarjojen rakentamiseen koko ympäristössä.

Monet nykyaikaiset VPS-alustat integroivat nyt kojelaudat Docker-mittareihin, hälytyksiin ja käyttövalmiisiin kaavioihin , mikä alentaa merkittävästi kynnystä vakavasti otettavaan valvontaan. On yleistä löytää kojelaudoista tietoja, jotka näyttävät suorittimen, RAM-muistin, levyn, verkon käytön ja säilön tilan suoraan palvelimen ohjauspaneelista.

Docker-levykuvista: gigatavumonstereista kevyisiin ja turvallisiin versioihin

Hyvän säilön suorituskyvyn kulmakivi on hyvin suunnitellut kuvat: pienet, toistettavat ja helposti päivitettävät . Tässä on yleensä eniten parantamisen varaa ja muutokset ovat hyödyllisimpiä.

Käännöstyökaluilla, pakettivälimuisteilla ja väliaikaistiedostoilla paisutettu levykuva voi helposti ylittää yhden gigatavun , kun taas oikeilla tekniikoilla sen voi pienentää vain muutamaan kymmeneen megatavuun. Aiemmin mainitsemassamme esimerkissä koko putosi 1,42 gigatavusta noin 34 megatavuun kaikkien optimointien jälkeen.

Tämä progressiivinen optimointi osoitti selvästi, miten jokainen vaihe lisäsi arvoa: valitse tietty ja vaalea pohjakuva Se lyhensi rakennusaikaa yli 350 sekunnista hieman yli 38 sekuntiin; kerrosten välimuistin hyödyntäminen laski sen 24 sekuntiin; kerrosten uudelleenjärjestely sääti sen noin 18 sekuntiin; ja strategisesti uudelleenjärjestämällä... COPY Se putosi noin 10 sekuntiin, ja lopulta monivaiheiset rakennukset mahdollistivat ajan pitämisen noin 10 sekunnissa, mutta lopullinen kuvan koko vain 34 Mt.

Kaikki tämä perustuu useisiin keskeisiin ajatuksiin: minimaaliset peruskuvat (Alpine, Debian Slim, Scratch)Erota selkeästi koonti- ja suoritusaikainen toiminta, vähennä kerrosten määrää, puhdista riippuvuudet ja välimuistit samasta kerroksesta, jossa ne luodaan, ja käytä hyvää .dockerignore välttääkseen roskasisällön lataamisen rakennuskontekstiin.

Työkalut, kuten DockerSlim tai dive, auttavat analysoimaan kunkin tason sisältöä, näkemään, mikä vie tilaa, ja ymmärtämään, miksi kuva on juuri tietyn kokoinen. On myös hyvä idea integroida työnkulkuusi tietoturvaskanneri (Docker Scan, Trivy jne.), jotta voidaan havaita peruskuvien ja riippuvuuksien haavoittuvuudet.

Perussäiliökuvien valitseminen ja jäsentäminen

Yksi tyypillisimmistä virheistä Dockerin kanssa aloitettaessa on käyttää yleisiä ja raskaita peruskuvia kaikkeen: täydellistä Ubuntua tai Debiania palveluille, jotka voisivat täydellisesti sijaita paljon pienemmässäkin.

Hyvin kevyille palveluille tai mikropalveluille, jotka suorittavat hyvin spesifin tehtävän, Alpine Linux, jonka koko on noin 5–6 Mt , on erinomainen vaihtoehto . Se sopii ihanteellisesti yksinkertaisiin sovelluksiin, vaikkakin se käyttää musl-kirjastoa glibc:n sijaan, mikä joskus vaatii pieniä muutoksia joihinkin kirjastoihin.

Jos etsit kompromissia koon ja kätevyyden välillä, Debian Slim (noin 60–70 Mt) on yleensä erittäin tasapainoinen valinta: saatavilla on enemmän paketteja kuin Alpinella, mutta ilman täyden jakelun aiheuttamaa paisutusta.

Staattisten binääritiedostojen ja erittäin suljettujen palveluiden kanssa voit mennä vielä pidemmälle Scratchin avulla, joka on kirjaimellisesti tyhjä levykuva . Sinun tarvitsee lisätä vain käännetyn binääritiedoston ja välttämättömät resurssit saadaksesi sen toimimaan, mikä johtaa minimaaliseen kokoon, mutta se joutuu rakentamaan kaiken itse.

Peruslevykuvaa valittaessa on koon lisäksi otettava huomioon myös tietoturvapäivitysten tiheys, käyttämiesi riippuvuuksien ( järjestelmäkirjastot , koontityökalut jne.) yhteensopivuus ja käyttöönottoympäristön resurssirajoitukset (esimerkiksi pieni VPS).

Tasot, monivaiheiset koonnukset ja välimuistin hallinta

Konttikuva-arkkitehtuuri perustuu päällekkäin pinottuihin muuttumattomiin kerroksiin, joiden ylin kerros on ajonaikaisesti kirjoitettava, ja johon kontin muutokset tallennetaan. Tämän ymmärtäminen on olennaista sekä koon että koontiaikojen optimoimiseksi.

Voimme erottaa useita erityyppisiä kerroksia: peruskerroksen, joka sisältää käyttöjärjestelmätiedostot, sovelluskerroksen, joka sisältää oman koodisi , riippuvuuskerroksen (kirjastot, ajonaikaiset ympäristöt, paketit) ja konfigurointikerroksen. Peruskerroksella ja riippuvuuskerroksella on suurin vaikutus kokoon.

Hyvä strategia sisältää yhdistää komennot yhdeksi RUN ketjuttamalla &&Tällä tavoin luot vähemmän tasoja ja siivoat kaiken, mitä ei tarvita myöhemmin (paketinhallinnan välimuistit, väliaikaiset tiedostot jne.), samassa vaiheessa. Jos sinulla on kolme RUN Jos seuraat niitä, jotka voitaisiin yhdistää, luot todennäköisesti ylimääräisiä kerroksia.

Monivaiheisilla koonneilla on keskeinen rooli: ensimmäisessä vaiheessa (koontiohjelmassa) asennetaan kaikki artefaktin luomiseen tarvittavat koontityökalut, SDK:t ja riippuvuudet (binaarit, front bundlet jne.), ja toisessa vaiheessa kopioidaan vain tulos paljon kevyempään peruskuvaan, joka on tarkoitettu vain suoritusta varten. Kannattaa myös harkita vaihtoehtoisia ajonaikaisia ​​ympäristöjä, kuten Podmania.

Tämä lähestymistapa mahdollistaa puhtaan lopputuloksen ilman työkaluketjuja tai kehityskirjastoja ja hyödyntää tasojen välimuistia älykkäällä tavalla: jos järjestelmän riippuvuudet eivät muutu, niitä sisältävää tasoa käytetään uudelleen ja vain ne osat, jotka ovat tosiasiallisesti muuttuneet (usein sovelluskoodi), rakennetaan uudelleen.

Suorittimen ja muistin hallinta: Älä anna minkään säilön syödä VPS:ääsi

Kun kuvat ovat enemmän tai vähemmän hallinnassa, seuraava tärkeä vaihe on määrittää, miten Docker allokoi suorittimen ja RAM-muistin konttien kesken . Jos et aseta rajoja, epärehellinen palvelu voi ylikuormittaa isännän ja kaataa loput.

Docker tarjoaa useita työkaluja suorittimien tasolla: voit määrittää suhteellisia suorittimien kiintiöitä, jotta joillakin konteilla on enemmän resursseja kuin toisilla , asettaa enimmäiskäyttörajoituksia ja jopa määrittää kontit tietyille ytimille suoritinjoukkojen avulla. Tämä on erittäin hyödyllistä kriittisille palveluille tai silloin, kun haluat eristää raskaita työkuormia.

Muistikuvasi ovat seuraavat: kovat rajat (--memory) estääkseen säilön ylittämästä tiettyä RAM-määrää, varaukset (--memory-reservation) taatakseen vähimmäisarvon tärkeille palveluille ja swap-parametreille estääkseen levyn villin sivutuksen.

Tämän alueen peruskäytäntöihin kuuluvat resurssien käytön jatkuva seuranta konttikohtaisesti , kohtuullisten rajoitusten asettaminen ei-kriittisille palveluille ja jonkin verran pelivaran jättäminen isännälle, jotta se ei aina aja 100 %:n kuormituksella.

Jos arkkitehtuurisi monimutkaistuu, orkestrointityökalut, kuten Docker Swarm tai Kubernetes, mahdollistavat kehittyneemmän resurssienhallinnan: varaukset, takuut, pod-kohtaiset rajoitukset, horisontaalisen automaattisen skaalauksen ja rikkaammat palvelun laatukäytännöt kuin yksittäisen, yksinkertaisen isännän vastaavat.

Docker-verkot: latenssi, verkkotilat ja palvelun löytäminen

Verkkoyhteydet unohdetaan usein, kunnes ilmenee viiveongelmia, aikakatkaisuja tai pullonkauloja mikropalveluiden välillä. Docker tarjoaa useita verkko-ohjaimia, jotka vaikuttavat merkittävästi konttien suorituskykyyn ja eristäytymiseen .

Oletusarvo on siltatila : kontit jakavat virtuaalisen sillan, ovat eristettyjä isännästä ja näkyvissä kartoitettujen porttien kautta. Yksinkertaisissa ympäristöissä tämä on yleensä täydellinen, mutta se voi aiheuttaa jonkin verran ylimääräistä kuormitusta.

Isäntätila puolestaan ​​poistaa kyseisen kerroksen ja saa säilön jakamaan isännän verkkopinon. Tämä vähentää yleiskuluja ja parantaa suorituskykyä joissakin suuren liikenteen tilanteissa, mutta jonkin verran eristäytymistä.

Kun sinun on kommunikoitava eri Docker-solmuissa sijaitsevien säilöjen välillä, käyttöön tulevat päällekkäisverkot ja ajurit, kuten Macvlan , joiden avulla voit määrittää jokaiselle säilölle oman MAC-osoitteen ja saada sen näkymään erillisenä fyysisenä laitteena verkossa.

Jotta järjestystä olisi jonkin verran, ihanteellista on luoda Räätälöidyt siltaverkot toisiinsa liittyville palveluryhmille (esimerkiksi taustajärjestelmä ja tietokanta), hienosäädä DNS-selvitystä käyttämällä vaihtoehtoa --dns tarvittaessa, ja sinulla on oltava palvelun etsintäjärjestelmä (Swarm, Consul jne.), joka estää sinua taistelemasta IP-osoitteiden kanssa manuaalisesti.

Tallennus ja I/O: Asemat, ajurit ja levyn suorituskyky

Suuria tietomääriä lukevat ja kirjoittavat sovellukset ovat erityisen herkkiä Docker-tallennustilan, taltioiden ja käytetyn tallennusajurin konfiguroinnille . Tämä voi vaikuttaa merkittävästi suorituskykyyn.

Useimmissa tapauksissa suositeltu ajuri on nykyään overlay2 , joka tarjoaa hyvän tasapainon vakauden ja suorituskyvyn välillä. Toiset, kuten DeviceMapper tai AUFS, on varattu tietyille tai vanhoille ympäristöille, ja kannattaa arvioida huolellisesti, tarvitsetko niitä todella.

Pysyvän datan käsittelyssä järkevin lähestymistapa on käyttää Docker-levyjä binding mount -levyjen sijaan. Levyjä on yleensä helpompi varmuuskopioida ja siirtää, ja ne toimivat johdonmukaisemmin eri isäntien ja käyttöjärjestelmien välillä.

Lyhytaikaisille tiedoille, jotka on käsiteltävä nopeasti (välimuistit, väliaikaiset tiedostot jne.), erittäin hyödyllinen temppu on käyttää kiinnikkeet tmpfsjotka tallentavat tiedot suoraan muistiin ja vähentävät levyn kuormitusta.

Voit myös parantaa asioita järjestämällä Dockerfile-tiedostosi ohjeet niin, että kerrosvälimuistin käyttö on mahdollisimman tehokasta, levylle kirjoitettavien tietojen määrä on rajattu ja erittäin intensiiviset säilöt eivät kuluta kaikkea kaistanleveyttä.

Valvonta, vianmääritys ja loppukäyttäjän kokemus

Docker-ympäristö, jossa ei ole hyvää havaittavuutta, on musta laatikko. Jotta voit toimia luotettavasti, sinun on seurattava sekä konttien sisällä tapahtuvaa että käyttäjän ulkopuolelta havaitsemaa.

Olemme jo maininneet Prometheuksen, Grafanan, cAdvisorin ja komennon docker statsjotka kattavat erittäin hyvin sisäiset tekniset mittarit (prosessori, muisti, sisäinen latenssi jne.). Tähän on suositeltavaa lisätä rekisteripino, kuten ELK (Elasticsearch, Logstash, Kibana) tai vastaavia SaaS-ratkaisuja lokien kokoamiseen ja analysointiin skaalautuvasti.

Komento docker events Se on loistava liittolainen virheenkorjaukseen: sen avulla voit nähdä reaaliajassa, mitä Docker-daemon tekee (käynnistyy, pysähtyy, aiheuttaa virheitä, käynnistyy uudelleen) ja verrata sitä mittareihisi ja lokeihisi.

Suoraan puhdistukseen tietyssä astiassa voit käyttää docker inspect nähdäksesi sen yksityiskohtaisen kokoonpanon, docker exec -it päästä kuoreen ja tarkistaa paikan päällä, mitä tapahtuu, tai docker network inspect yhteysongelmien ratkaisemiseksi.

Sisäisen näkökulman lisäksi on erittäin suositeltavaa integroida ulkoisia synteettisiä valvontatyökaluja, jotka simuloivat eri maantieteellisistä sijainneista tulevien todellisten käyttäjien käyttäytymistä . Dotcom-Monitorin kaltaiset alustat mahdollistavat saatavuuden, vasteaikojen ja tapahtumien onnistumisasteen tarkistukset, mikä tarjoaa kokonaisvaltaisen näkymän, joka täydentää hyvin Prometheusta ja vastaavia järjestelmiä.

Tietoturva, parhaat käytännöt ja Docker-komennot, joita käytät päivittäin

Suorituskyvyn optimointi ilman tietoturvan huomioimista on kuin ampuisi itseään jalkaan. Useimmat Dockerin parhaat käytännöt yhdistävät molemmat näkökohdat: pienet levykuvat tarkoittavat vähemmän hyökkäyspintaa ; vähemmän riippuvuuksia tarkoittaa vähemmän potentiaalisia haavoittuvuuksia.

Joitakin perussuosituksia: käytä Dockerfile-linttereitä vaarallisten kuvioiden havaitsemiseen , vältä prosessien suorittamista root-käyttäjänä säilön sisällä aina kun mahdollista, tarkista säännöllisesti levykuvia haavoittuvuuksien varalta ja käytä virallisia ja aktiivisesti ylläpidettyjä levykuvia.

On myös suositeltavaa automatisoida peruskuvan päivitykset CI/CD-putkissa, sisällyttää tietoturvaskannaukset pakolliseksi prosessin vaiheeksi ja estää kriittisiä haavoittuvuuksia sisältävät koontiversiot. On paljon parempi pysäyttää käyttöönotto ajoissa kuin joutua hallitsemaan tuotanto-ongelmia tunnetun CVE:n vuoksi.

Päivittäisessä käytössä Dockerin peruskomentotyökalupakki sisältää seuraavat: docker --version y docker info selvittääksesi, mitä olet asentanut ylös docker pull kuvien lataamiseen, docker run käynnistää interaktiivisia tai taustakontteja ja docker ps / docker ps -a nähdäksesi, mitkä säilöt ovat aktiivisia tai ei-aktiivisia.

Omien kuvien rakentamiseksi työskentelet jatkuvasti docker build -t ja versioidut Docker-tiedostot arkistossasiHallitaksesi jo aktiivisia säilöjä, docker stop, docker start, docker restart, docker logs y docker exec -it Ne ovat välttämättömiä.

Kun haluat viedä sinnikkyyden ja verkostoitumisen askeleen pidemmälle, tällaiset komennot tulevat avuksi. docker volume create y docker volume ls käsitellä tietoja tai docker network ls y docker network create määrittää hieman monimutkaisempia topologioita palveluidesi välille.

Projekteissa, joissa on useampi kuin yksi kontti (normaali tilanne kohtalaisen vakavassa sovelluksessa), Docker Composen käytöstä on tulossa lähes pakollista. Yksinkertaisella docker-compose up -d Nostat koko pinon ja docker-compose down Pysäytät sen ja siivoat siihen liittyvät resurssit. Siitä eteenpäin Compose-, BuildKit- ja buildx-profiilit avaavat oven usean arkkitehtuurin koonneille, edistyneelle välimuistin hallinnalle ja paljon hienostuneemmille käyttöönottoille.

Toiminnallisella tasolla on hyödyllistä omaksua tiettyjä tapoja: Merkitse kuvasi aina selkeillä tunnisteilla, älä kerää orpoja säilöjä ja kuvia (komentoja, kuten docker system prune, docker container prune o docker image prune auttaa pitämään ympäristön puhtaana) ja käytä syntaksia --mount Volyymeihin, kun haluat täydellistä ilmaisuvoimaisuutta ja vähemmän yllätyksiä kuin klassisessa -v.

Tämä koko tekniikoiden kokonaisuus – oikean peruskuvan valinnasta monivaiheisiin koonteihin, resurssien hallintaan, verkkoihin, tallennukseen, valvontaan ja tietoturvaan – mahdollistaa erittäin hienostuneiden Docker-ympäristöjen rakentamisen, jotka käynnistyvät nopeasti, kuluttavat minimaalisesti resursseja, ovat turvallisempia ja paljon helppokäyttöisempiä . Jos sisällytät ne vähitellen projekteihisi ja yhdistät ne hyvään VPS-infrastruktuuriin ja vankkaan havainnointistrategiaan, konttisi lakkaavat olemasta arvaamattomia mustia laatikoita ja niistä tulee vankka osa alustaasi.