Hapi i parë i vendosjes në Kubernetes është vendosja e aplikacionit tuaj në një kontejner. Në këtë seri, ne do të shikojmë se si mund të krijoni një imazh të vogël e të sigurt kontejneri.
Falë Docker, krijimi i imazheve të kontejnerëve nuk ka qenë kurrë më i lehtë. Specifikoni një imazh bazë, shtoni ndryshimet tuaja dhe krijoni një enë.
Ndërsa kjo teknikë është e shkëlqyeshme për të filluar, përdorimi i imazheve bazë të paracaktuar mund të çojë në punë të pasigurt me imazhe të mëdha plot dobësi.
Për më tepër, shumica e imazheve në Docker përdorin Debian ose Ubuntu për imazhin bazë, dhe ndërsa kjo siguron përputhshmëri të shkëlqyer dhe personalizim të lehtë (një skedar Docker merr vetëm dy rreshta kodi), imazhet bazë mund të shtojnë qindra megabajt ngarkesë shtesë në kontejnerin tuaj. Për shembull, një skedar i thjeshtë node.js për një aplikacion Go "hello-world" është rreth 700 megabajt, ndërsa aplikacioni juaj aktual është vetëm disa megabajt në madhësi.
Pra, e gjithë kjo ngarkesë shtesë e punës është një humbje e hapësirës dixhitale dhe një vend i mrekullueshëm për t'u fshehur për dobësitë e sigurisë dhe defektet. Pra, le të shohim dy mënyra për të zvogëluar madhësinë e një imazhi të kontejnerit.
E para është përdorimi i imazheve të vogla bazë, e dyta është përdorimi i modelit Builder. Përdorimi i imazheve bazë më të vogla është ndoshta mënyra më e lehtë për të zvogëluar madhësinë e kontejnerit tuaj. Me shumë mundësi, gjuha ose grupi që po përdorni ofron një imazh origjinal të aplikacionit që është shumë më i vogël se imazhi i paracaktuar. Le të hedhim një vështrim në kontejnerin tonë node.js.
Si parazgjedhje në Docker, madhësia e imazhit bazë të node:8 është 670 MB dhe madhësia e nyjes: 8-alpine është vetëm 65 MB, domethënë 10 herë më e vogël. Duke përdorur imazhin më të vogël të bazës Alpine, ju do të zvogëloni ndjeshëm madhësinë e kontejnerit tuaj. Alpine është një shpërndarje e vogël dhe e lehtë Linux që është shumë e popullarizuar në mesin e përdoruesve të Docker sepse është e pajtueshme me shumë aplikacione duke i mbajtur kontejnerët të vegjël. Ndryshe nga imazhi standard i Docker "node", "node:alpine" heq shumë skedarë dhe programe shërbimi, duke lënë vetëm ato që janë të mjaftueshme për të ekzekutuar aplikacionin tuaj.
Për të kaluar në një imazh bazë më të vogël, thjesht përditësoni Dockerfile për të filluar punën me imazhin e ri bazë:
Tani, ndryshe nga imazhi i vjetër i ndërtuar, duhet të kopjoni kodin tuaj në kontejner dhe të instaloni çdo varësi. Në një Dockerfile të ri, kontejneri fillon me një imazh node:alpine, më pas krijon një direktori për kodin, instalon varësitë duke përdorur menaxherin e paketave NPM dhe në fund ekzekuton server.js.
Ky përmirësim rezulton në një enë që është 10 herë më e vogël në madhësi. Nëse gjuha ose staku juaj i programimit nuk ka funksionalitet bazë të reduktimit të imazhit, përdorni Alpine Linux. Ai gjithashtu do të sigurojë mundësinë për të menaxhuar plotësisht përmbajtjen e kontejnerit. Përdorimi i imazheve të vogla bazë është një mënyrë e shkëlqyer për të krijuar shpejt kontejnerë të vegjël. Por reduktim edhe më i madh mund të arrihet duke përdorur Modelin e Ndërtuesit.
Në gjuhët e interpretuara, kodi burim fillimisht i kalohet përkthyesit dhe më pas ekzekutohet drejtpërdrejt. Në gjuhët e përpiluara, kodi burim fillimisht konvertohet në kod të përpiluar. Megjithatë, përpilimi shpesh përdor mjete që nuk janë të nevojshme për të ekzekutuar kodin. Kjo do të thotë që ju mund t'i hiqni plotësisht këto mjete nga ena përfundimtare. Ju mund të përdorni Builder Pattern për këtë.
Kodi krijohet në kontejnerin e parë dhe përpilohet. Kodi i përpiluar më pas paketohet në një kontejner përfundimtar pa përpiluesit dhe mjetet e nevojshme për përpilimin e atij kodi. Le të ekzekutojmë një aplikacion Go përmes këtij procesi. Së pari, ne do të kalojmë nga imazhi i ndërtuar në Alpine Linux.
Në skedarin e ri Docker, kontejneri fillon me një imazh golang:alpin. Më pas krijon një direktori për kodin, e kopjon atë në kodin burimor, e ndërton atë kod burimor dhe ekzekuton aplikacionin. Ky kontejner është shumë më i vogël se kontejneri i ndërtuar, por gjithsesi përmban përpiluesin dhe mjete të tjera Go që nuk na duhen vërtet. Pra, le të nxjerrim programin e përpiluar dhe ta vendosim në kontejnerin e vet.
Mund të vëreni diçka të çuditshme në këtë skedar Docker: ai përmban dy rreshta FROM. Seksioni i parë me 4 rreshta duket saktësisht i njëjtë me Dockerfile-in e mëparshëm, përveç që përdor fjalën kyçe AS për të emërtuar këtë fazë. Seksioni tjetër ka një linjë të re FROM për të filluar një imazh të ri, ku në vend të imazhit golang:alpine do të përdorim Raw alpine si imazh bazë.
Raw Alpine Linux nuk ka të instaluar asnjë certifikatë SSL, gjë që do të bëjë që shumica e thirrjeve API përmes HTTPS të dështojnë, kështu që le të instalojmë disa certifikata CA rrënjësore.
Tani vjen pjesa argëtuese: për të kopjuar kodin e përpiluar nga kontejneri i parë në të dytin, thjesht mund të përdorni komandën COPY që ndodhet në rreshtin 5 të seksionit të dytë. Ai do të kopjojë vetëm një skedar aplikacioni dhe nuk do të ndikojë në mjetet e shërbimeve Go. Skedari i ri Docker me shumë faza do të përmbajë një imazh të kontejnerit që është vetëm 12 megabajt në madhësi, krahasuar me imazhin origjinal të kontejnerit që ishte 700 megabajt, që është një ndryshim i madh!
Pra, përdorimi i imazheve të vogla bazë dhe Modeli i Ndërtuesit janë mënyra të shkëlqyera për të krijuar kontejnerë shumë më të vegjël pa shumë punë.
Është e mundur që në varësi të grupit të aplikacionit, ka mënyra shtesë për të zvogëluar madhësinë e imazhit dhe kontejnerit, por a kanë vërtet kontejnerët e vegjël një përfitim të matshëm? Le të shohim dy fusha ku kontejnerët e vegjël janë jashtëzakonisht efektivë - performanca dhe siguria.
Për të vlerësuar rritjen e performancës, merrni parasysh kohëzgjatjen e procesit të krijimit të një kontejneri, futjen e tij në regjistër (shtytje) dhe më pas marrjen e tij prej andej (tërheq). Ju mund të shihni se një enë më e vogël ka një avantazh të veçantë mbi një enë më të madhe.
Docker do të ruajë memorien e shtresave, kështu që ndërtimet e mëvonshme do të jenë shumë të shpejta. Megjithatë, shumë sisteme CI të përdorura për të ndërtuar dhe testuar kontejnerët nuk i ruajnë shtresat në memorie, kështu që ka kursime të konsiderueshme në kohë. Siç mund ta shihni, koha për të ndërtuar një enë të madhe, në varësi të fuqisë së makinës suaj, është nga 34 në 54 sekonda, dhe kur përdorni një enë zvogëlohet duke përdorur Modelin e Ndërtuesit - nga 23 në 28 sekonda. Për operacione të këtij lloji, rritja e produktivitetit do të jetë 40-50%. Pra, vetëm mendoni se sa herë e ndërtoni dhe testoni kodin tuaj.
Pasi të ndërtohet kontejneri, duhet ta shtyni imazhin e tij (imazhin e kontejnerit të shtyrë) në regjistrin e kontejnerit në mënyrë që të mund ta përdorni më pas në grupin tuaj Kubernetes. Unë rekomandoj përdorimin e Regjistrit të kontejnerëve të Google.
Me Google Container Registry (GCR), ju paguani vetëm për ruajtjen e papërpunuar dhe rrjetëzimin dhe nuk ka tarifa shtesë për menaxhimin e kontejnerëve. Është privat, i sigurt dhe shumë i shpejtë. GCR përdor shumë truke për të shpejtuar operacionin e tërheqjes. Siç mund ta shihni, futja e një kontejneri Docker Container Image duke përdorur go:onbuild do të zgjasë nga 15 deri në 48 sekonda, në varësi të performancës së kompjuterit, dhe i njëjti operacion me një kontejner më të vogël do të zgjasë nga 14 deri në 16 sekonda, dhe për makinat më pak produktive avantazhi në shpejtësinë e funksionimit rritet me 3 herë. Për makinat më të mëdha, koha është pothuajse e njëjtë, pasi GCR përdor një memorie të fshehtë globale për një bazë të dhënash të përbashkët të imazheve, që do të thotë se nuk keni nevojë t'i ngarkoni ato fare. Në një kompjuter me fuqi të ulët, CPU është pengesa, kështu që avantazhi i përdorimit të kontejnerëve të vegjël është shumë më i madh këtu.
Nëse jeni duke përdorur GCR, unë rekomandoj shumë përdorimin e Google Container Builder (GCB) si pjesë e sistemit tuaj të ndërtimit.
Siç mund ta shihni, përdorimi i tij ju lejon të arrini rezultate shumë më të mira në reduktimin e kohëzgjatjes së funksionimit Build+Push sesa edhe një makinë produktive - në këtë rast, procesi i ndërtimit dhe dërgimit të kontejnerëve tek hosti përshpejtohet pothuajse 2 herë. . Plus, ju merrni 120 minuta ndërtimi falas çdo ditë, që mbulon nevojat tuaja për ndërtimin e kontejnerëve në shumicën e rasteve.
Më pas vjen metrika më e rëndësishme e performancës – shpejtësia e marrjes ose shkarkimit të kontejnerëve të tërhequr. Dhe nëse nuk ju intereson shumë koha e shpenzuar në një operacion shtytjeje, atëherë kohëzgjatja e procesit të tërheqjes ka një ndikim serioz në performancën e përgjithshme të sistemit. Le të themi se keni një grup prej tre nyjeve dhe njëra prej tyre dështon. Nëse jeni duke përdorur një sistem menaxhimi si Google Kubernetes Engine, ai automatikisht do të zëvendësojë nyjen e vdekur me një të re. Sidoqoftë, kjo nyje e re do të jetë plotësisht bosh dhe do t'ju duhet të tërhiqni të gjithë kontejnerët tuaj në të që ajo të fillojë të funksionojë. Nëse operacioni i tërheqjes zgjat mjaftueshëm, grupi juaj do të funksionojë me performancë më të ulët gjatë gjithë kohës.
Ka shumë raste kur kjo mund të ndodhë: shtimi i një nyje të re në një grup, përmirësimi i nyjeve ose edhe kalimi në një kontejner të ri për vendosje. Kështu, minimizimi i kohës së nxjerrjes së tërheqjes bëhet një faktor kyç. Është e pamohueshme që një kontejner i vogël shkarkohet shumë më shpejt se një i madh. Nëse po përdorni kontejnerë të shumtë në një grup Kubernetes, kursimi i kohës mund të jetë i konsiderueshëm.
Hidhini një sy këtij krahasimi: një operacion tërheqjeje në kontejnerë të vegjël kërkon 4-9 herë më pak kohë, në varësi të fuqisë së makinës, sesa i njëjti operacion duke përdorur go:onbuild. Përdorimi i imazheve të përbashkëta, bazë të kontejnerëve të vegjël përshpejton ndjeshëm kohën dhe shpejtësinë me të cilën nyjet e reja Kubernetes mund të vendosen dhe të vijnë në internet.
Le të shohim çështjen e sigurisë. Kontejnerët më të vegjël konsiderohen shumë më të sigurt se ato më të mëdhenj, sepse ato kanë një sipërfaqe më të vogël sulmi. A është me të vërtetë? Një nga veçoritë më të dobishme të Google Container Registry është aftësia për të skanuar automatikisht kontejnerët tuaj për dobësi. Disa muaj më parë krijova kontejnerë të ndërtuar dhe shumëfazor, kështu që le të shohim nëse ka ndonjë dobësi atje.
Rezultati është i mahnitshëm: vetëm 3 dobësi mesatare u zbuluan në një enë të vogël, dhe 16 dobësi kritike dhe 376 dobësi të tjera u gjetën në një enë të madhe. Nëse shikojmë përmbajtjen e një kontejneri të madh, mund të shohim se shumica e problemeve të sigurisë nuk kanë të bëjnë fare me aplikacionin tonë, por kanë të bëjnë me programe që ne as nuk i përdorim. Pra, kur njerëzit flasin për një sipërfaqe të madhe sulmi, kjo është ajo që ata nënkuptojnë.
Arritja është e qartë: ndërtoni kontejnerë të vegjël sepse ato ofrojnë performancë reale dhe përfitime sigurie për sistemin tuaj.
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com