Ensimmäinen vaihe Kubernetesin käyttöönotossa on sovelluksen sijoittaminen säilöön. Tässä sarjassa tarkastellaan, kuinka voit luoda pienen, suojatun säilökuvan.
Dockerin ansiosta säilökuvien luominen ei ole koskaan ollut helpompaa. Määritä peruskuva, lisää muutokset ja luo säilö.
Vaikka tämä tekniikka on loistava aloittamiseen, oletusperuskuvien käyttäminen voi johtaa vaaralliseen työskentelyyn suurten haavoittuvuuksia täynnä olevien kuvien kanssa.
Lisäksi useimmat Dockerin kuvat käyttävät Debiania tai Ubuntua perusvedoksena, ja vaikka tämä tarjoaa erinomaisen yhteensopivuuden ja helpon mukauttamisen (Docker-tiedosto vie vain kaksi riviä koodia), peruskuvat voivat lisätä säilöön satoja megatavuja lisäkuormitusta. Esimerkiksi yksinkertainen node.js-tiedosto Go "hello-world" -sovellukselle on noin 700 megatavua, kun varsinainen sovelluksesi on vain muutaman megatavun kokoinen.
Joten kaikki tämä ylimääräinen työmäärä on digitaalisen tilan tuhlausta ja loistava piilopaikka tietoturva-aukoille ja bugeille. Tarkastellaan siis kahta tapaa pienentää säilön kuvan kokoa.
Ensimmäinen on pienten peruskuvien käyttö, toinen on Builder Patternin käyttö. Pienempien peruskuvien käyttäminen on luultavasti helpoin tapa pienentää säilön kokoa. Todennäköisimmin käyttämäsi kieli tai pino tarjoaa alkuperäisen sovelluksen kuvan, joka on paljon pienempi kuin oletuskuva. Katsotaanpa node.js-säilöämme.
Oletuksena Dockerissa node:8-peruskuvan koko on 670 Mt ja node: 8-alpine -kuvan koko on vain 65 Mt, eli 10 kertaa pienempi. Käyttämällä pienempää Alpine-peruskuvaa pienennät konttisi kokoa merkittävästi. Alpine on pieni ja kevyt Linux-jakelu, joka on erittäin suosittu Docker-käyttäjien keskuudessa, koska se on yhteensopiva monien sovellusten kanssa pitäen kontit pieninä. Toisin kuin tavallinen Dockerin "node" -kuva, "node:alpine" poistaa paljon palvelutiedostoja ja ohjelmia, jättäen vain ne, jotka riittävät sovelluksesi suorittamiseen.
Voit siirtyä pienempään peruskuvaan päivittämällä Docker-tiedoston aloittaaksesi työskentelyn uuden peruskuvan kanssa:
Nyt, toisin kuin vanhassa onbuild-kuvassa, sinun on kopioitava koodisi säilöön ja asennettava kaikki riippuvuudet. Uudessa Dockerfile-tiedostossa säilö alkaa node:alpine-kuvalla, luo sitten koodille hakemiston, asentaa riippuvuudet NPM-paketinhallinnan avulla ja suorittaa lopuksi server.js:n.
Tämä päivitys johtaa säiliöön, joka on kooltaan 10 kertaa pienempi. Jos ohjelmointikielessäsi tai pinossasi ei ole peruskuvan pienennystoimintoa, käytä Alpine Linuxia. Se tarjoaa myös mahdollisuuden hallita täysin säiliön sisältöä. Pienten pohjakuvien käyttäminen on loistava tapa luoda nopeasti pieniä säiliöitä. Mutta vieläkin suurempi vähennys voidaan saavuttaa käyttämällä Builder Pattern -kuviota.
Tulkituilla kielillä lähdekoodi välitetään ensin tulkille ja suoritetaan sitten suoraan. Käännetyillä kielillä lähdekoodi muunnetaan ensin käännetyksi koodiksi. Kääntäminen käyttää kuitenkin usein työkaluja, joita ei itse asiassa tarvita koodin suorittamiseen. Tämä tarkoittaa, että voit poistaa nämä työkalut kokonaan lopullisesta säiliöstä. Voit käyttää Builder Patterniä tähän.
Koodi luodaan ensimmäiseen säilöön ja käännetään. Käännetty koodi pakataan sitten lopulliseen säiliöön ilman kääntäjiä ja työkaluja, joita koodin kääntämiseen tarvitaan. Suoritetaan Go-sovellus tämän prosessin läpi. Ensin siirrymme onbuild-kuvasta Alpine Linuxiin.
Uudessa Docker-tiedostossa säilö alkaa golang:alpine-kuvalla. Sitten se luo koodille hakemiston, kopioi sen lähdekoodiin, rakentaa lähdekoodin ja suorittaa sovelluksen. Tämä kontti on paljon pienempi kuin onbuild-säilö, mutta se sisältää silti kääntäjän ja muita Go-työkaluja, joita emme oikeastaan tarvitse. Puretaan siis käännetty ohjelma ja laitetaan se omaan säiliöönsä.
Saatat huomata jotain outoa tässä Docker-tiedostossa: se sisältää kaksi FROM-riviä. Ensimmäisen 4 rivin osa näyttää täsmälleen samalta kuin edellinen Dockerfile paitsi, että se käyttää AS-avainsanaa tämän vaiheen nimeämiseen. Seuraavassa osiossa on uusi FROM-rivi uuden kuvan aloittamiseksi, jossa golang:alpine-kuvan sijaan käytämme peruskuvana Raw alpine.
Raw Alpine Linuxiin ei ole asennettu SSL-varmenteita, mikä aiheuttaa useimmat API-kutsut HTTPS:n kautta epäonnistumaan, joten asennetaan joitain juuri CA-varmenteita.
Nyt tulee hauska osa: kopioidaksesi käännetyn koodin ensimmäisestä säilöstä toiseen, voit yksinkertaisesti käyttää COPY-komentoa, joka sijaitsee toisen osan rivillä 5. Se kopioi vain yhden sovellustiedoston eikä vaikuta Go-aputyökaluihin. Uusi monivaiheinen Docker-tiedosto sisältää vain 12 megatavun säilökuvan verrattuna alkuperäiseen 700 megatavun säilökuvaan, mikä on iso ero!
Pienten peruskuvien ja Builder Patternin käyttäminen on siis loistava tapa luoda paljon pienempiä säiliöitä ilman paljon työtä.
On mahdollista, että sovelluspinosta riippuen on olemassa muita tapoja pienentää kuvan ja säilön kokoa, mutta onko pienillä säiliöillä todella mitattavissa olevaa hyötyä? Tarkastellaan kahta aluetta, joilla pienet säiliöt ovat erittäin tehokkaita - suorituskyky ja turvallisuus.
Suorituskyvyn kasvun arvioimiseksi harkitse säilön luomisprosessin kestoa, sen lisäämistä rekisteriin (push) ja sen hakemista sieltä (pull). Voit nähdä, että pienemmällä säiliöllä on selvä etu suurempiin astioihin verrattuna.
Docker tallentaa kerrokset välimuistiin, joten seuraavat koontiversiot ovat erittäin nopeita. Monet konttien rakentamiseen ja testaamiseen käytetyt CI-järjestelmät eivät kuitenkaan tallenna kerroksia välimuistiin, joten aikaa säästyy huomattavasti. Kuten näet, aika suuren säiliön rakentamiseen on koneen tehosta riippuen 34-54 sekuntia, ja konttia käytettäessä se lyhenee Builder Patternilla - 23-28 sekuntia. Tällaisissa toiminnoissa tuottavuuden kasvu on 40-50 %. Joten ajattele vain, kuinka monta kertaa rakennat ja testaat koodisi.
Kun säilö on rakennettu, sinun on työnnettävä sen kuva (push container image) säilörekisteriin, jotta voit käyttää sitä Kubernetes-klusterissasi. Suosittelen käyttämään Google Container Registryä.
Google Container Registry (GCR) -sovelluksella maksat vain raakatallennustilasta ja verkottumisesta, eikä sinulla ole ylimääräisiä kontinhallintamaksuja. Se on yksityinen, turvallinen ja erittäin nopea. GCR käyttää monia temppuja nopeuttaakseen vetotoimintoa. Kuten näet, Docker Container Image -säilön lisääminen go:onbuild-komennolla kestää 15–48 sekuntia tietokoneen suorituskyvystä riippuen, ja sama toimenpide pienemmällä säiliöllä kestää 14–16 sekuntia ja vähemmän tuottavilla koneilla. käyttönopeuden etu kasvaa 3 kertaa. Suuremmissa koneissa aika on suunnilleen sama, koska GCR käyttää globaalia välimuistia jaettuun kuvatietokantaan, joten sinun ei tarvitse ladata niitä ollenkaan. Vähätehoisessa tietokoneessa prosessori on pullonkaula, joten pienten säiliöiden käytön etu on tässä paljon suurempi.
Jos käytät GCR:ää, suosittelen Google Container Builderin (GCB) käyttöä osana rakennusjärjestelmääsi.
Kuten näette, sen käytön avulla voit saavuttaa paljon parempia tuloksia Build+Push-toiminnan keston lyhentämisessä kuin jopa tuottava kone - tässä tapauksessa konttien rakentamis- ja lähettämisprosessi isännälle kiihtyy lähes 2 kertaa. . Lisäksi saat 120 ilmaista rakennusminuuttia joka päivä, mikä kattaa useimmissa tapauksissa konttirakennustarpeesi.
Seuraavaksi tulee tärkein suorituskykymittari – Pull-säiliöiden noudon tai lataamisen nopeus. Ja jos et välitä paljon työntötoimintoon käytetystä ajasta, vetoprosessin pituudella on vakava vaikutus järjestelmän yleiseen suorituskykyyn. Oletetaan, että sinulla on kolmen solmun klusteri ja yksi niistä epäonnistuu. Jos käytät hallintajärjestelmää, kuten Google Kubernetes Engine, se korvaa automaattisesti kuolleen solmun uudella. Tämä uusi solmu on kuitenkin täysin tyhjä, ja sinun on vedettävä kaikki säiliösi siihen, jotta se alkaa toimia. Jos vetotoiminto kestää tarpeeksi kauan, klusterisi toimii pienemmällä teholla koko ajan.
On monia tapauksia, joissa näin voi tapahtua: uuden solmun lisääminen klusteriin, solmujen päivittäminen tai jopa vaihtaminen uuteen säilöön käyttöönottoa varten. Siten vedonpoistoajan minimoimisesta tulee avaintekijä. On kiistatonta, että pieni kontti latautuu paljon nopeammin kuin suuri. Jos käytät useita säilöjä Kubernetes-klusterissa, ajansäästö voi olla merkittävä.
Katso tämä vertailu: vetotoiminto pienillä konteilla kestää koneen tehosta riippuen 4-9 kertaa vähemmän aikaa kuin sama toimenpide go:onbuild-toiminnolla. Jaettujen, pienten konttipohjakuvien käyttäminen nopeuttaa merkittävästi uusien Kubernetes-solmujen käyttöönottoa ja verkkoon pääsyä.
Katsotaanpa turvallisuuskysymystä. Pienempiä kontteja pidetään paljon turvallisempina kuin suurempia, koska niissä on pienempi hyökkäyspinta. Onko se todella? Yksi Google Container Registryn hyödyllisimmistä ominaisuuksista on kyky tarkistaa säilöistäsi automaattisesti haavoittuvuuksia. Muutama kuukausi sitten loin sekä onbuild- että monivaiheiset kontit, joten katsotaan onko siellä haavoittuvuuksia.
Tulos on hämmästyttävä: vain 3 keskikokoista haavoittuvuutta havaittiin pienestä säiliöstä ja 16 kriittistä ja 376 muuta haavoittuvuutta löydettiin suuresta säiliöstä. Jos katsomme suuren kontin sisältöä, voimme nähdä, että useimmat tietoturvaongelmat eivät liity mitenkään sovellukseemme, vaan liittyvät ohjelmiin, joita emme edes käytä. Joten kun ihmiset puhuvat suuresta hyökkäyspinnasta, sitä he tarkoittavat.
Takeaway on selvä: rakenna pieniä säiliöitä, koska ne tarjoavat todellisia suorituskyky- ja turvallisuusetuja järjestelmällesi.
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com