Det första steget för att distribuera i Kubernetes Àr att placera din applikation i en container. I den hÀr serien kommer vi att titta pÄ hur man kan skapa en bild av en liten och sÀker container.
Med Docker har skapandet av containerbilder aldrig varit enklare. Ange en grundlÀggande bild, lÀgg till dina Àndringar och skapa containern.
Ăven om detta tillvĂ€gagĂ„ngssĂ€tt Ă€r utmĂ€rkt för att komma igĂ„ng, kan anvĂ€ndningen av standardbasbilder leda till osĂ€ker drift med stora bilder som Ă€r fulla av sĂ„rbarheter.
Dessutom anvÀnder de flesta bilder i Docker antingen Debian eller Ubuntu som basbild, och Àven om det ger utmÀrkt kompatibilitet och enkel anpassning (Docker-filen innehÄller bara tvÄ kodrader), kan basbilder lÀgga till hundratals megabyte extra last i din container. Till exempel kan en enkel node.js-applikation Go "hello-world" vara omkring 700 megabyte, medan storleken pÄ sjÀlva din applikation bara Àr nÄgra megabyte.
SÄledes Àr all denna extra belastning en slöseri med digitalt utrymme och en utmÀrkt gömstÀlle för sÄrbarheter och sÀkerhetsfel. DÀrför ska vi titta pÄ tvÄ sÀtt att minska storleken pÄ containerbilden.
Det första Àr att anvÀnda smÄ basbilder, det andra Àr att anvÀnda designmönstret Builder Pattern. Att anvÀnda mindre basbilder Àr förmodligen det enklaste sÀttet att minska storleken pÄ din container. Sannolikt tillhandahÄller ditt sprÄk eller din teknik som du anvÀnder en originalapplikationsbild som Àr mycket mindre Àn standardbilden. LÄt oss ta en titt pÄ vÄr node.js-container.
Som standard Àr storleken pÄ Docker-basen node:8 670 MB, medan node:8-alpine bara Àr 65 MB, vilket Àr 10 gÄnger mindre. Genom att anvÀnda den mindre basbilden Alpine minskar du avsevÀrt storleken pÄ din container. Alpine Àr en liten och lÀtt Linux-distribution som Àr mycket populÀr bland Docker-anvÀndare eftersom den Àr kompatibel med mÄnga applikationer, samtidigt som den hÄller containerns storlek liten. Till skillnad frÄn den standard Docker-basen "node", tar "node:alpine" bort mÄnga hjÀlpfiler och program, och lÀmnar endast de som behövs för att köra din applikation.
För att byta till en mindre basbild, uppdatera Docker-filen för att börja arbeta med den nya basbilden:
Nu, till skillnad frÄn den gamla onbuild-bilden, behöver du kopiera din kod till containern och installera eventuella beroenden. I den nya Docker-filen börjar containern med bilden node:alpine, skapar sedan en katalog för koden, installerar beroenden med hjÀlp av pakethanteraren NPM och slutligen kör server.js.
Med denna uppdatering fÄr du en container som Àr 10 gÄnger mindre i storlek. Om ditt programmeringssprÄk eller din teknikstack inte har en funktion för att minska basbilden, anvÀnd Alpine Linux. Det ger ocksÄ möjlighet att fullt ut kontrollera innehÄllet i containern. Att anvÀnda smÄ basbilder Àr ett utmÀrkt sÀtt att snabbt skapa smÄ containrar. Men du kan uppnÄ Ànnu större reduktion genom att anvÀnda Builder Pattern.
I tolkade sprÄk ges kÀllkoden först till tolken, och sedan körs den direkt. I kompilatoriska sprÄk omvandlas kÀllkoden först till kompilatorisk kod. Vid denna process anvÀnds ofta verktyg som faktiskt inte behövs för att köra koden. Det betyder att du kan ta bort dessa verktyg helt frÄn den slutliga containern. För detta kan du anvÀnda Builder Pattern.
Koden skapas i den första containern och kompileras. Sedan packas den kompilerade koden ner i den slutliga containern utan kompilatorer och verktyg som behövs för att kompilera denna kod. LÄt oss gÄ igenom denna process med en Go-applikation. Först gÄr vi frÄn onbuild-bilden till Alpine Linux.
I den nya Docker-filen börjar containern med bilden golang:alpine. Den skapar sedan en katalog för koden, kopierar den till kÀllkoden, kompilerar koden och kör applikationen. Denna container Àr mycket mindre Àn onbuild-containern, men den innehÄller fortfarande kompilatorn och andra Go-verktyg som vi faktiskt inte behöver. LÄt oss dÀrför bara extrahera den kompilerade programvaran och packa den i vÄr egen container.
Du kan mÀrka nÄgot konstigt i denna Docker-fil: den innehÄller tvÄ FROM-rader. Den första delen av de fyra raderna ser precis ut som den föregÄende Docker-filen förutom att den anvÀnder nyckelordet AS för att ge ett namn till detta steg. I den nÀsta delen finns en ny FROM-rad som gör det möjligt att pÄbörja en ny bild, och istÀllet för att anvÀnda bilden golang:alpine som basbild kommer vi att anvÀnda Raw alpine.
Raw Alpine Linux har inga installerade SSL-certifikat, vilket kommer att leda till att de flesta API-anrop via HTTPS misslyckas, sÄ lÄt oss installera nÄgra rotcertifikat frÄn CA.
Och nu det mest intressanta: för att kopiera den kompilerade koden frÄn den första containern till den andra kan vi enkelt anvÀnda COPY-kommandot, som ligger pÄ den femte raden av den andra delen. Det kommer att kopiera bara en enkel applikationsfil och beröra inga Go-verktyg. Den nya flertrÄdade Docker-filen kommer att innehÄlla en containerbild som endast Àr 12 megabyte, medan den ursprungliga containerbilden var 700 megabyte, vilket Àr en stor skillnad!
SÄledes Àr anvÀndning av smÄ basbilder och Builder Pattern utmÀrkta sÀtt att skapa containrar av mycket mindre storlek utan mycket arbete.
Det kan hĂ€nda att det finns ytterligare sĂ€tt att minska storleken pĂ„ bilden och containern beroende pĂ„ applikationens stack, men ger verkligen smĂ„ containrar nĂ„gon mĂ€tbar fördel? LĂ„t oss titta pĂ„ tvĂ„ aspekter dĂ€r smĂ„ containrar Ă€r extremt effektiva â det handlar om prestanda och sĂ€kerhet.
För att bedöma prestandaökningen, lÄt oss titta pÄ hur lÄng tid det tar att skapa en container, skicka den till registret (push) och sedan hÀmta den dÀrifrÄn (pull). Du kan se att en mindre container har en tydlig fördel jÀmfört med en större container.
Docker kommer att cacha lager, sÄ efterföljande byggen kommer att ske mycket snabbt. Men i mÄnga CI-system som anvÀnds för att bygga och testa containrar cachas inte lagren, sÄ hÀr finns en betydande tidsbesparing. Som du kan se, tar bygget av en stor container beroende pÄ din dators kraft mellan 34 och 54 sekunder, medan anvÀndningen av en mindre container med hjÀlp av Builder Pattern tar mellan 23 och 28 sekunder. För den hÀr typen av operationer kan prestandaförbÀttringen uppgÄ till 40-50%. SÄ tÀnk bara pÄ hur mÄnga gÄnger du bygger och testar din kod.
NÀr containern Àr byggd behöver du skicka dess bild (push container image) till containerregistret för att sedan anvÀnda den i din Kubernetes-kluster. Jag rekommenderar att du anvÀnder Google Container Registry.
Genom att anvÀnda Google Container Registry (GCR) betalar du endast för "rÄ" lagring och nÀtverk, och en extra avgift för hantering av containrar tas inte ut. Det Àr konfidentiellt, sÀkert och mycket snabbt. GCR anvÀnder mÄnga trick för att snabba upp pull-operationer. Som du ser, tar inskickandet av Docker Container Image med go:onbuild, beroende pÄ datorns prestanda, mellan 15 och 48 sekunder, medan samma operation med en mindre container tar mellan 14 och 16 sekunder, och för mindre kraftfulla maskiner ökar hastighetsfördelen tre gÄnger. För kraftfulla maskiner Àr tiden ungefÀr densamma, eftersom GCR anvÀnder global cache för den gemensamma bildbasen, vilket innebÀr att du överhuvudtaget inte behöver ladda upp dem. I en lÄgt presterande dator Àr CPU det begrÀnsande faktorn, sÄ fördelen med att anvÀnda smÄ containrar Àr hÀr mycket mer mÀrkbar.
Om du anvÀnder GCR rekommenderar jag starkt att du anvÀnder Google Container Builder (GCB) som en del av ditt byggsystem.
Som ni ser gör anvĂ€ndningen av detta det möjligt att uppnĂ„ mycket bĂ€ttre resultat nĂ€r det kommer till att minska tiden för operationen Build+Push, Ă€n Ă€ven med en kraftfull maskin â i det hĂ€r fallet accelereras processen för att bygga och skicka containrar till vĂ€rden nĂ€stan med 50 procent. Dessutom fĂ„r ni varje dag 120 minuter byggtid gratis, vilket i de flesta fall tillfredsstĂ€ller behoven av att skapa containrar.
DĂ€refter kommer den viktigaste prestandametriken â hastigheten för att hĂ€mta, eller ladda ner, containrar (Pull). Och om ni inte riktigt bryr er om tiden som tas för push-operationen, sĂ„ pĂ„verkar lĂ€ngden pĂ„ pull-processen allvarligt den totala systemprestandan. Anta att ni har en kluster med tre noder och en av dem gĂ„r ner. Om ni anvĂ€nder ett hanteringssystem, som Google Kubernetes Engine, sĂ„ kommer det automatiskt att ersĂ€tta den defekta noden med en ny. Men den nya noden kommer att vara helt tom, och ni mĂ„ste överföra alla era containrar dit för att den ska börja fungera. Om pull-operationen tar tillrĂ€ckligt lĂ„ng tid, kommer er kluster att arbeta med minskad prestanda under hela tiden.
Det finns mÄnga situationer dÀr nÄgot liknande kan hÀnda: detta inkluderar att lÀgga till en ny nod till klustret, uppdateringsprocesser för noder eller till och med övergÄng till en ny container för distribution. SÄledes blir minimering av pull-extraktions tiden en avgörande faktor. Det Àr obestridligt att en liten container laddas ner mycket snabbare Àn en stor. Om ni anvÀnder flera containrar i ett Kubernetes-kluster kan tidsbesparingen bli betydande.
Titta pÄ den jÀmförelse som ges: pull-operationen nÀr den arbetar med smÄ containrar tar 4-9 gÄnger mindre tid beroende pÄ maskinens kapacitet, jÀmfört med samma operation med go:onbuild. AnvÀndningen av gemensamma basbilder för containrar av liten storlek pÄskyndar avsevÀrt tiden och hastigheten med vilken nya Kubernetes-noder kan distribueras och gÄ online.
LĂ„t oss titta pĂ„ sĂ€kerhetsfrĂ„gan. Det anses att mindre containrar Ă€r mycket sĂ€krare Ă€n stora, eftersom de har en mindre attackyta. Ăr det verkligen sĂ„? En av de mest anvĂ€ndbara funktionerna i Google Container Registry Ă€r möjligheten att automatiskt skanna dina containrar för sĂ„rbarheter. För nĂ„gra mĂ„nader sedan skapade jag bĂ„de onbuild- och flertrinscontainrar, sĂ„ lĂ„t oss se om det finns nĂ„gra sĂ„rbara punkter dĂ€r.
Resultatet Àr imponerande: det har endast hittats 3 medelstora sÄrbarheter i den lilla containern, medan den stora hade 16 kritiska och 376 andra sÄrbarheter. Om vi granskar innehÄllet i den stora containern, kan vi se att de flesta sÀkerhetsproblem inte har nÄgot att göra med vÄr applikation, utan handlar om program som vi inte ens anvÀnder. SÄ nÀr folk pratar om en stor attackyta, menar de just detta.
Slutsatsen Àr tydlig: skapa smÄ containrar, eftersom de ger verkliga fördelar nÀr det gÀller prestanda och sÀkerhet för ditt system.
Lite reklam đ
Tack för att ni stannar kvar hos oss. Gillar ni vÄra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en bestÀllning eller rekommendera oss till era vÀnner, , en unik motsvarighet till entry-level servrar som vi har skapat för er: (alternativ med RAID1 och RAID10 finns tillgÀngliga, upp till 24 kÀrnor och upp till 40GB DDR4).
Dell R730xd Ă€r tvĂ„ gĂ„nger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss i NederlĂ€nderna! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â frĂ„n $99! LĂ€s om
KĂ€lla: habr.com
