Det første trinnet med å distribuere til Kubernetes er å plassere applikasjonen din i en beholder. I denne serien skal vi se på hvordan du kan lage et lite, sikkert beholderbilde.
Takket være Docker har det aldri vært enklere å lage containerbilder. Spesifiser et basisbilde, legg til endringene dine og lag en beholder.
Selv om denne teknikken er flott for å komme i gang, kan bruk av standard grunnbilder føre til usikkert arbeid med store bilder fulle av sårbarheter.
I tillegg bruker de fleste bilder i Docker Debian eller Ubuntu for basisbildet, og selv om dette gir utmerket kompatibilitet og enkel tilpasning (en Docker-fil tar bare to linjer med kode), kan basisbilder legge til hundrevis av megabyte ekstra belastning til beholderen din. For eksempel er en enkel node.js-fil for en Go "hello-world"-applikasjon omtrent 700 megabyte, mens den faktiske applikasjonen din bare er noen få megabyte stor.
Så all denne ekstra arbeidsmengden er sløsing med digital plass og et flott gjemmested for sikkerhetssårbarheter og feil. Så la oss se på to måter å redusere størrelsen på et beholderbilde på.
Den første er bruken av små basisbilder, den andre er bruken av Builder Pattern. Å bruke mindre basisbilder er sannsynligvis den enkleste måten å redusere størrelsen på beholderen på. Mest sannsynlig gir språket eller stabelen du bruker et originalt programbilde som er mye mindre enn standardbildet. La oss ta en titt på node.js-beholderen vår.
Som standard i Docker er node:8-grunnbildestørrelsen 670 MB, og noden: 8-alpine bildestørrelse er bare 65 MB, det vil si 10 ganger mindre. Ved å bruke det mindre Alpine basebildet vil du redusere størrelsen på beholderen din betraktelig. Alpine er en liten og lett Linux-distribusjon som er veldig populær blant Docker-brukere fordi den er kompatibel med mange applikasjoner samtidig som beholderne holdes små. I motsetning til standard Docker "node"-bilde, fjerner "node:alpine" mange tjenestefiler og programmer, og etterlater bare de som er tilstrekkelige til å kjøre applikasjonen din.
For å flytte til et mindre basisbilde, oppdater du bare Dockerfilen for å begynne å jobbe med det nye basisbildet:
Nå, i motsetning til det gamle onbuild-bildet, må du kopiere koden din inn i beholderen og installere eventuelle avhengigheter. I en ny Dockerfile starter containeren med et node:alpine-bilde, oppretter deretter en katalog for koden, installerer avhengigheter ved hjelp av NPM-pakkebehandlingen og kjører til slutt server.js.
Denne oppgraderingen resulterer i en container som er 10 ganger mindre i størrelse. Hvis programmeringsspråket eller stabelen ikke har grunnleggende bildereduksjonsfunksjonalitet, bruk Alpine Linux. Det vil også gi muligheten til å administrere innholdet i beholderen fullt ut. Å bruke små basisbilder er en fin måte å raskt lage små beholdere. Men enda større reduksjon kan oppnås ved å bruke Builder Pattern.
På tolkede språk sendes kildekoden først til tolken og kjøres deretter direkte. På kompilerte språk blir kildekoden først konvertert til kompilert kode. Imidlertid bruker kompilering ofte verktøy som faktisk ikke er nødvendig for å kjøre koden. Dette betyr at du kan fjerne disse verktøyene helt fra den endelige beholderen. Du kan bruke Builder Pattern for dette.
Koden opprettes i den første beholderen og kompileres. Den kompilerte koden pakkes deretter inn i en endelig beholder uten kompilatorene og verktøyene som trengs for å kompilere den koden. La oss kjøre en Go-applikasjon gjennom denne prosessen. Først går vi fra onbuild-bildet til Alpine Linux.
I den nye Dockerfilen starter beholderen med et golang:alpine-bilde. Deretter oppretter den en katalog for koden, kopierer den inn i kildekoden, bygger den kildekoden og kjører applikasjonen. Denne beholderen er mye mindre enn den innebygde beholderen, men den inneholder fortsatt kompilatoren og andre Go-verktøy som vi egentlig ikke trenger. Så la oss bare trekke ut det kompilerte programmet og legge det i sin egen beholder.
Du kan legge merke til noe merkelig i denne Docker-filen: den inneholder to FROM-linjer. Den første seksjonen med 4 linjer ser nøyaktig ut som den forrige Dockerfile bortsett fra at den bruker AS-nøkkelordet for å navngi dette stadiet. Neste seksjon har en ny FROM-linje for å starte et nytt bilde, hvor vi i stedet for golang:alpine-bildet vil bruke Raw alpine som basisbilde.
Raw Alpine Linux har ingen SSL-sertifikater installert, noe som vil føre til at de fleste API-kall over HTTPS mislykkes, så la oss installere noen rot-CA-sertifikater.
Nå kommer den morsomme delen: for å kopiere den kompilerte koden fra den første beholderen til den andre, kan du ganske enkelt bruke COPY-kommandoen på linje 5 i den andre delen. Det vil bare kopiere én programfil og vil ikke påvirke Go-verktøyverktøy. Den nye flertrinns Docker-filen vil inneholde et containerbilde som bare er 12 megabyte i størrelse, sammenlignet med det originale containerbildet som var på 700 megabyte, noe som er en stor forskjell!
Så å bruke små basisbilder og Builder Pattern er gode måter å lage mye mindre beholdere uten mye arbeid.
Det er mulig at det, avhengig av applikasjonsstabelen, finnes flere måter å redusere bilde- og beholderstørrelse på, men har små beholdere virkelig en målbar fordel? La oss se på to områder hvor små containere er ekstremt effektive – ytelse og sikkerhet.
For å evaluere ytelsesøkningen, vurder varigheten av prosessen med å lage en beholder, sette den inn i registret (push), og deretter hente den derfra (pull). Du kan se at en mindre beholder har en klar fordel fremfor en større beholder.
Docker vil cache lagene slik at påfølgende bygg vil være veldig raske. Mange CI-systemer som brukes til å bygge og teste beholdere, hurtigbufrer imidlertid ikke lag, så det er betydelige tidsbesparelser. Som du kan se, er tiden for å bygge en stor beholder, avhengig av kraften til maskinen din, fra 34 til 54 sekunder, og når du bruker en beholder redusert ved hjelp av Builder-mønsteret - fra 23 til 28 sekunder. For drift av denne typen vil produktivitetsøkningen være 40-50 %. Så bare tenk på hvor mange ganger du bygger og tester koden din.
Etter at containeren er bygget, må du skyve bildet (push container image) inn i containerregisteret slik at du kan bruke det i Kubernetes-klyngen. Jeg anbefaler å bruke Google Container Registry.
Med Google Container Registry (GCR) betaler du kun for rå lagring og nettverksbygging, og det er ingen ekstra gebyrer for containeradministrasjon. Det er privat, sikkert og veldig raskt. GCR bruker mange triks for å få fart på pull-operasjonen. Som du kan se, vil det ta fra 15 til 48 sekunder å sette inn en Docker Container Image-beholder med go:onbuild, avhengig av datamaskinens ytelse, og samme operasjon med en mindre beholder vil ta fra 14 til 16 sekunder, og for mindre produktive maskiner fordelen i driftshastighet øker med 3 ganger. For større maskiner er tiden omtrent den samme, siden GCR bruker en global cache for en delt database med bilder, noe som betyr at du ikke trenger å laste dem i det hele tatt. I en datamaskin med lite strøm er CPU-en flaskehalsen, så fordelen med å bruke små beholdere er mye større her.
Hvis du bruker GCR, anbefaler jeg på det sterkeste å bruke Google Container Builder (GCB) som en del av byggesystemet.
Som du kan se, lar bruken deg oppnå mye bedre resultater for å redusere varigheten av Build+Push-operasjonen enn til og med en produktiv maskin - i dette tilfellet akselereres prosessen med å bygge og sende containere til verten med nesten 2 ganger . I tillegg får du 120 gratis byggeminutter hver dag, som i de fleste tilfeller dekker behovene dine for containerbygging.
Deretter kommer den viktigste ytelsesberegningen – hastigheten på å hente, eller laste ned, Pull-beholdere. Og hvis du ikke bryr deg mye om tiden brukt på en push-operasjon, så har lengden på pull-prosessen en alvorlig innvirkning på den generelle systemytelsen. La oss si at du har en klynge med tre noder og en av dem mislykkes. Hvis du bruker et administrasjonssystem som Google Kubernetes Engine, vil det automatisk erstatte den døde noden med en ny. Imidlertid vil denne nye noden være helt tom, og du må dra alle beholderne inn i den for at den skal begynne å fungere. Hvis trekkoperasjonen tar lang nok, vil klyngen kjøre med lavere ytelse hele tiden.
Det er mange tilfeller der dette kan skje: legge til en ny node i en klynge, oppgradere noder eller til og med bytte til en ny beholder for distribusjon. Dermed blir minimering av pull-ekstraksjonstiden en nøkkelfaktor. Det er ubestridelig at en liten beholder lastes ned mye raskere enn en stor. Hvis du kjører flere beholdere i en Kubernetes-klynge, kan tidsbesparelsen være betydelig.
Ta en titt på denne sammenligningen: en trekkoperasjon på små containere tar 4-9 ganger kortere tid, avhengig av maskinens kraft, enn samme operasjon med go:onbuild. Ved å bruke delte, små containerbasebilder øker tiden og hastigheten som nye Kubernetes-noder kan distribueres og komme online med betydelig.
La oss se på spørsmålet om sikkerhet. Mindre containere anses som mye tryggere enn større fordi de har en mindre angrepsflate. Er det virkelig? En av de mest nyttige funksjonene i Google Container Registry er muligheten til å automatisk skanne containerne dine for sårbarheter. For noen måneder siden opprettet jeg både onbuild og flertrinns containere, så la oss se om det er noen sårbarheter der.
Resultatet er utrolig: bare 3 middels sårbarheter ble oppdaget i en liten beholder, og 16 kritiske og 376 andre sårbarheter ble funnet i en stor beholder. Hvis vi ser på innholdet i en stor beholder, kan vi se at de fleste sikkerhetsproblemene ikke har noe med applikasjonen vår å gjøre, men er relatert til programmer vi ikke en gang bruker. Så når folk snakker om en stor angrepsflate, er det det de mener.
Takeawayen er klar: bygg små containere fordi de gir reelle ytelses- og sikkerhetsfordeler til systemet ditt.
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com