De earste stap fan ynset nei Kubernetes is it pleatsen fan jo applikaasje yn in kontener. Yn dizze searje sille wy sjen hoe't jo in lyts, feilige kontenerôfbylding kinne meitsje.
Mei tank oan Docker hat it meitsjen fan kontenerôfbyldings nea makliker west. Spesifisearje in basisôfbylding, foegje jo wizigingen ta en meitsje in kontener.
Hoewol dizze technyk geweldich is om te begjinnen, kin it brûken fan standertbasisôfbyldings liede ta ûnfeilich wurk mei grutte ôfbyldings fol mei kwetsberens.
Derneist brûke de measte ôfbyldings yn Docker as basisôfbylding Debian of UbuntuHoewol dit poerbêste kompatibiliteit en maklike oanpassing biedt (in Docker-bestân nimt mar twa rigels koade yn beslach), kinne basisôfbyldings hûnderten megabytes oan ekstra lading tafoegje oan jo kontener. Bygelyks, in ienfâldich node.js-bestân foar in Go "hello-world"-applikaasje nimt sawat 700 megabytes yn beslach, sels as jo werklike applikaasje mar in pear megabytes grut is.
Dat al dizze ekstra wurkdruk is in fergriemerij fan digitale romte en in geweldich skûlplak foar feiligenskwetsberheden en bugs. Litte wy dus nei twa manieren sjen om de grutte fan in kontenerôfbylding te ferminderjen.
De earste is it gebrûk fan lytse basisôfbyldings, de twadde is it gebrûk fan it Builder Pattern. It brûken fan lytsere basisôfbyldings is wierskynlik de maklikste manier om de grutte fan jo kontener te ferminderjen. Meast wierskynlik leveret de taal of stapel dy't jo brûke in orizjinele applikaasjeôfbylding dy't folle lytser is as de standertôfbylding. Litte wy ris nei ús node.js-container sjen.
Standert is de basisôfbylding fan node:8 yn Docker 670 MB grut, wylst node:8-alpine mar 65 MB grut is, wat 10 kear lytser is. It brûken fan de lytsere basisôfbylding fan Alpine sil de grutte fan jo kontener flink ferminderje. Alpine is in lytse en lichtgewicht distribúsje. Linux, dat tige populêr is ûnder Docker-brûkers, om't it kompatibel is mei in protte applikaasjes, wylst de kontenergrutte lyts bliuwt. Oars as de standert Docker "node"-ôfbylding, ferwideret "node:alpine" in protte tsjinstbestannen en programma's, wêrtroch allinich dyjingen oerbliuwe dy't nedich binne om jo applikaasje út te fieren.
Om nei in lytsere basisôfbylding te ferpleatsen, aktualisearje de Dockerfile gewoan om te wurkjen mei de nije basisôfbylding:
No, yn tsjinstelling ta de âlde onbuild-ôfbylding, moatte jo jo koade kopiearje yn 'e kontener en alle ôfhinklikens ynstallearje. Yn in nije Dockerfile begjint de kontener mei in knooppunt: alpine-ôfbylding, makket dan in map foar de koade, ynstallearret ôfhinklikens mei de NPM-pakketbehearder, en rint úteinlik server.js.
Dizze update resultearret yn in kontener dy't 10 kear lytser is. As jo programmeartaal of stack it krimpen fan 'e basisôfbylding net stipet, brûk dan Alpine. LinuxIt sil ek folsleine kontrôle jaan oer de ynhâld fan 'e kontener. It brûken fan lytse basisôfbyldings is in geweldige manier om fluch lytse konteners te meitsjen. Mar jo kinne noch gruttere gruttefermindering berikke mei it Builder Pattern.
Yn ynterpretearre talen wurdt de boarnekoade earst trochjûn oan de tolk en dan direkt útfierd. Yn gearstalde talen wurdt de boarnekoade earst omset yn kompilearre koade. De kompilaasje brûkt lykwols faak ark dy't eins net nedich binne om de koade út te fieren. Dit betsjut dat jo dizze ark folslein kinne fuortsmite fan 'e definitive kontener. Jo kinne Builder Pattern foar dit brûke.
De koade wurdt makke yn 'e earste kontener en kompilearre. De kompilearre koade wurdt dan ynpakt yn 'e definitive kontener sûnder de kompilers en ark dy't nedich binne om de koade te kompilearjen. Litte wy dit proses foar in Go-applikaasje trochrinne. Earst sille wy migrearje fan 'e onbuild-ôfbylding nei Alpine. Linux.
Yn 'e nije Dockerfile begjint de kontener mei in golang: alpine-ôfbylding. It makket dan in map foar de koade, kopiearret it yn 'e boarnekoade, bout dy boarnekoade en rint de applikaasje út. Dizze kontener is folle lytser dan de onbuild-container, mar it befettet noch de kompilator en oare Go-ark dy't wy net echt nedich binne. Dat litte wy it kompilearre programma gewoan útpakke en it yn syn eigen kontener pleatse.
Jo kinne miskien wat nuver yn dit Docker-bestân besjen: it befettet twa FROM-rigels. De earste 4-line-seksje sjocht krekt itselde as de foarige Dockerfile, útsein dat it it AS-kaaiwurd brûkt om dit poadium te neamen. De folgjende seksje hat in nije FROM-rigel om in nije ôfbylding te begjinnen, wêr't wy ynstee fan 'e golang:alpine-ôfbylding Raw alpine sille brûke as basisôfbylding.
Rauwe Alpine Linux hat gjin SSL-sertifikaten ynstalleare, wat derfoar soarget dat de measte API-opropen oer HTTPS mislearje, dus litte wy wat root CA-sertifikaten ynstallearje.
No komt it leuke diel: om de kompilearre koade fan 'e earste kontener nei de twadde te kopiearjen, kinne jo gewoan it kommando COPY brûke op line 5 fan' e twadde seksje. It sil mar ien applikaasjebestân kopiearje en sil gjin ynfloed hawwe op Go-hulpprogramma's. De nije multi-stage Docker-bestân sil in kontenerôfbylding befetsje dy't mar 12 megabytes yn grutte is, yn ferliking mei it orizjinele kontenerôfbylding dat 700 megabytes wie, wat in grut ferskil is!
Dat it brûken fan lytse basisôfbyldings en Builder Pattern binne geweldige manieren om folle lytsere konteners te meitsjen sûnder in protte wurk.
It is mooglik dat d'r ôfhinklik fan 'e applikaasjestapel ekstra manieren binne om ôfbylding en kontenergrutte te ferminderjen, mar hawwe lytse konteners echt in mjitber foardiel? Litte wy nei twa gebieten sjen wêr't lytse konteners ekstreem effektyf binne - prestaasjes en feiligens.
Om de prestaasjesferheging te evaluearjen, beskôgje de doer fan it proses fan it meitsjen fan in kontener, ynfoegje it yn it register (push), en helje it dan fan dêrút (pull). Jo kinne sjen dat in lytsere kontener in dúdlik foardiel hat oer in gruttere kontener.
Docker sil de lagen cache, sadat folgjende builds heul rap sille wêze. In protte CI-systemen dy't brûkt wurde om konteners te bouwen en te testen, cache lagen lykwols net, dus d'r binne signifikante tiidbesparring. Sa't jo sjen kinne, is de tiid om in grutte kontener te bouwen, ôfhinklik fan 'e krêft fan jo masine, fan 34 oant 54 sekonden, en by it brûken fan in kontener fermindere mei it Builder Pattern - fan 23 oant 28 sekonden. Foar operaasjes fan dit soarte sil de produktiviteitsferheging 40-50% wêze. Tink dus gewoan oer hoefolle kearen jo jo koade bouwe en testje.
Nei't de kontener boud is, moatte jo syn ôfbylding (drukke kontenerôfbylding) yn it kontenerregister drukke, sadat jo it dan kinne brûke yn jo Kubernetes-kluster. Ik advisearje it brûken fan Google Container Registry.
Mei Google Container Registry (GCR) betelje jo allinich foar rau opslach en netwurking, en d'r binne gjin ekstra kontenerbehearkosten. It is privee, feilich en heul rap. GCR brûkt in protte trúkjes om de pull-operaasje te fersnellen. Lykas jo kinne sjen, sil it ynfoegjen fan in Docker Container Image-kontener mei go:onbuild fan 15 oant 48 sekonden duorje, ôfhinklik fan 'e kompjûterprestaasjes, en deselde operaasje mei in lytsere kontener sil fan 14 oant 16 sekonden duorje, en foar minder produktive masines it foardiel yn operaasje snelheid nimt ta mei 3 kear. Foar gruttere masines is de tiid sawat itselde, om't GCR in globale cache brûkt foar in dielde databank fan ôfbyldings, wat betsjut dat jo se hielendal net hoege te laden. Yn in komputer mei lege macht is de CPU de knelpunt, dus it foardiel fan it brûken fan lytse konteners is hjir folle grutter.
As jo GCR brûke, ried ik tige oan om Google Container Builder (GCB) te brûken as diel fan jo bouwsysteem.
Sa't jo sjen kinne, lit it gebrûk derfan folle bettere resultaten berikke by it ferminderjen fan de doer fan 'e Build+Push-operaasje dan sels in produktive masine - yn dit gefal wurdt it proses fan it bouwen en ferstjoeren fan konteners nei de host hast 2 kear fersneld. . Plus, jo krije elke dei 120 fergese bouminuten, dy't yn 'e measte gefallen jo behoeften foar containerbou dekt.
Folgjende komt de wichtichste prestaasjemetrik - de snelheid fan it opheljen, as ynladen, Pull-konteners. En as jo net skele folle oer de tiid bestege oan in push operaasje, dan hat de lingte fan de pull proses in serieuze ynfloed op de totale systeem prestaasje. Litte wy sizze dat jo in kluster hawwe fan trije knopen en ien fan har mislearret. As jo in behearsysteem brûke lykas Google Kubernetes Engine, sil it de deade knooppunt automatysk ferfange troch in nije. Dizze nije knooppunt sil lykwols folslein leech wêze en jo moatte al jo konteners deryn slepe om te begjinnen mei wurkjen. As de pull-operaasje lang genôch duorret, sil jo kluster de heule tiid mei legere prestaasjes rinne.
D'r binne in protte gefallen wêr't dit kin barre: in nij knooppunt tafoegje oan in kluster, knooppunten opwurdearje, of sels oerstappe nei in nije kontener foar ynset. Sa wurdt it minimalisearjen fan pull-ekstraksjetiid in wichtige faktor. It is ûnbestriden dat in lytse kontener folle rapper downloadt dan in grutte. As jo meardere konteners yn in Kubernetes-kluster útfiere, kin de tiidbesparring signifikant wêze.
Sjoch ris op dizze ferliking: in pull operaasje op lytse konteners nimt 4-9 kear minder tiid, ôfhinklik fan de masine syn macht, as deselde operaasje mei help fan go: onbuild. It brûken fan dielde, lytse kontenerbasisôfbyldings fersnelt de tiid en snelheid wêrop nije Kubernetes-knooppunten kinne wurde ynset en online komme signifikant.
Litte wy nei it probleem fan feiligens sjen. Lytsere konteners wurde beskôge as folle feiliger as gruttere omdat se in lytser oanfal oerflak hawwe. Is it echt? Ien fan 'e nuttichste funksjes fan Google Container Registry is de mooglikheid om jo konteners automatysk te scannen foar kwetsberens. In pear moanne lyn haw ik sawol onbuild- as multistage-containers makke, dus litte wy sjen oft d'r kwetsberens binne.
It resultaat is geweldich: allinich 3 medium kwetsberens waarden ûntdutsen yn in lytse kontener, en 16 krityske en 376 oare kwetsberens waarden fûn yn in grutte kontener. As wy nei de ynhâld fan in grutte kontener sjogge, kinne wy sjogge dat de measte feiligensproblemen neat hawwe mei ús applikaasje, mar relatearre binne oan programma's dy't wy net iens brûke. Dus as minsken prate oer in grut oanfalsflak, bedoele se dat.
De takeaway is dúdlik: bou lytse konteners om't se echte prestaasjes en feiligensfoardielen leverje oan jo systeem.
Guon advertinsjes 🙂
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com
