Prvi korak uvajanja v Kubernetes je namestitev vaše aplikacije v vsebnik. V tej seriji si bomo ogledali, kako lahko ustvarite majhno, varno sliko vsebnika.
Zahvaljujoč Dockerju ustvarjanje slik vsebnikov še nikoli ni bilo lažje. Določite osnovno sliko, dodajte svoje spremembe in ustvarite vsebnik.
Čeprav je ta tehnika odlična za začetek, lahko uporaba privzetih osnovnih slik povzroči nevarno delo z velikimi slikami, polnimi ranljivosti.
Poleg tega večina slik v Dockerju uporablja Debian ali Ubuntu za osnovno sliko, in čeprav to zagotavlja odlično združljivost in enostavno prilagajanje (datoteka Docker zavzame samo dve vrstici kode), lahko osnovne slike vašemu vsebniku dodajo na stotine megabajtov dodatne obremenitve. Na primer, preprosta datoteka node.js za aplikacijo Go "hello-world" je velika približno 700 megabajtov, medtem ko je vaša dejanska aplikacija velika le nekaj megabajtov.
Vsa ta dodatna delovna obremenitev je torej izguba digitalnega prostora in odlično skrivališče za varnostne ranljivosti in hrošče. Oglejmo si torej dva načina za zmanjšanje velikosti slike vsebnika.
Prvi je uporaba majhnih osnovnih slik, drugi pa je uporaba vzorca graditelja. Uporaba manjših osnovnih slik je verjetno najlažji način za zmanjšanje velikosti vsebnika. Najverjetneje jezik ali sklad, ki ga uporabljate, zagotavlja izvirno sliko aplikacije, ki je veliko manjša od privzete slike. Oglejmo si naš vsebnik node.js.
Privzeto v Dockerju je velikost osnovne slike vozlišča:8 670 MB, velikost slike vozlišča:8-alpine pa le 65 MB, kar je 10-krat manjša. Z uporabo manjše slike podnožja Alpine boste znatno zmanjšali velikost vaše posode. Alpine je majhna in lahka distribucija Linuxa, ki je zelo priljubljena med uporabniki Dockerja, ker je združljiva s številnimi aplikacijami, hkrati pa ohranja majhne vsebnike. Za razliko od standardne Dockerjeve slike "node", "node:alpine" odstrani veliko servisnih datotek in programov, pusti le tiste, ki zadostujejo za zagon vaše aplikacije.
Če se želite premakniti na manjšo osnovno sliko, preprosto posodobite Dockerfile, da začnete delati z novo osnovno sliko:
Zdaj morate za razliko od stare slike onbuild kopirati svojo kodo v vsebnik in namestiti morebitne odvisnosti. V novi datoteki Dockerfile se vsebnik začne s sliko node:alpine, nato ustvari imenik za kodo, namesti odvisnosti z uporabo upravitelja paketov NPM in na koncu zažene server.js.
Rezultat te nadgradnje je vsebnik, ki je 10-krat manjši. Če vaš programski jezik ali sklad nima funkcije zmanjšanja osnovne slike, uporabite Alpine Linux. Zagotovil bo tudi možnost popolnega upravljanja vsebine vsebnika. Uporaba majhnih osnovnih slik je odličen način za hitro ustvarjanje majhnih vsebnikov. Toda še večje zmanjšanje je mogoče doseči z uporabo vzorca Builder.
V interpretiranih jezikih se izvorna koda najprej posreduje tolmaču in nato neposredno izvede. V prevedenih jezikih se izvorna koda najprej pretvori v prevedeno kodo. Vendar prevajanje pogosto uporablja orodja, ki dejansko niso potrebna za izvajanje kode. To pomeni, da lahko ta orodja popolnoma odstranite iz končnega vsebnika. Za to lahko uporabite Builder Pattern.
Koda je ustvarjena v prvem vsebniku in prevedena. Prevedena koda se nato zapakira v končni vsebnik brez prevajalnikov in orodij, potrebnih za prevajanje te kode. Zaženimo aplikacijo Go skozi ta postopek. Najprej se bomo premaknili s slike onbuild na Alpine Linux.
V novi datoteki Dockerfile se vsebnik začne s sliko golang:alpine. Nato ustvari imenik za kodo, jo prekopira v izvorno kodo, sestavi to izvorno kodo in zažene aplikacijo. Ta vsebnik je precej manjši od vsebnika onbuild, vendar še vedno vsebuje prevajalnik in druga orodja Go, ki jih pravzaprav ne potrebujemo. Torej ekstrahirajmo prevedeni program in ga dajmo v svoj vsebnik.
V tej datoteki Docker boste morda opazili nekaj čudnega: vsebuje dve vrstici FROM. Prvi razdelek s 4 vrsticami je videti popolnoma enako kot prejšnji Dockerfile, le da uporablja ključno besedo AS za poimenovanje te stopnje. Naslednji razdelek ima novo vrstico FROM za začetek nove slike, kjer bomo namesto slike golang:alpine kot osnovno sliko uporabili Raw alpine.
Raw Alpine Linux nima nameščenih potrdil SSL, kar bo povzročilo neuspeh večine klicev API prek HTTPS, zato namestimo nekaj korenskih potrdil CA.
Zdaj prihaja zabavni del: za kopiranje prevedene kode iz prvega vsebnika v drugega lahko preprosto uporabite ukaz COPY, ki se nahaja v 5. vrstici drugega razdelka. Kopiral bo samo eno datoteko aplikacije in ne bo vplival na orodja pripomočka Go. Nova večstopenjska datoteka Docker bo vsebovala sliko vsebnika, ki bo velika le 12 megabajtov, v primerjavi s prvotno sliko vsebnika, ki je imela 700 megabajtov, kar je velika razlika!
Torej sta uporaba majhnih osnovnih slik in vzorca Builder odlična načina za ustvarjanje veliko manjših vsebnikov brez veliko dela.
Možno je, da glede na sklad aplikacij obstajajo dodatni načini za zmanjšanje velikosti slike in vsebnika, toda ali imajo majhni vsebniki res merljivo korist? Poglejmo dve področji, kjer so majhni zabojniki izjemno učinkoviti – zmogljivost in varnost.
Če želite oceniti povečanje zmogljivosti, upoštevajte trajanje postopka ustvarjanja vsebnika, njegovega vstavljanja v register (potiskanje) in nato pridobivanja od tam (vlečenje). Vidite lahko, da ima manjši zabojnik izrazito prednost pred večjim zabojnikom.
Docker bo predpomnil plasti, tako da bodo naslednje gradnje zelo hitre. Vendar pa številni sistemi CI, ki se uporabljajo za gradnjo in preskušanje vsebnikov, ne predpomnijo plasti, zato je prihranek časa precejšen. Kot lahko vidite, je čas za izdelavo velikega vsebnika, odvisno od moči vašega stroja, od 34 do 54 sekund, pri uporabi vsebnika pa se zmanjša z uporabo vzorca Builder - od 23 do 28 sekund. Pri tovrstnih operacijah bo povečanje produktivnosti 40-50%. Zato samo pomislite, kolikokrat sestavite in preizkusite svojo kodo.
Ko je vsebnik zgrajen, morate njegovo sliko (sliko potisnega vsebnika) potisniti v register vsebnikov, da jo lahko nato uporabite v svoji gruči Kubernetes. Priporočam uporabo Google Container Registry.
Z Google Container Registry (GCR) plačate samo za neobdelano shranjevanje in povezovanje v omrežje, dodatnih stroškov za upravljanje vsebnikov pa ni. Je zaseben, varen in zelo hiter. GCR uporablja številne trike za pospešitev postopka vleke. Kot lahko vidite, bo vstavljanje vsebnika Docker Container Image s programom go:onbuild trajalo od 15 do 48 sekund, odvisno od zmogljivosti računalnika, ista operacija z manjšim vsebnikom pa bo trajala od 14 do 16 sekund in za manj produktivne stroje prednost v hitrosti delovanja se poveča za 3-krat. Za večje stroje je čas približno enak, saj GCR uporablja globalni predpomnilnik za skupno bazo slik, kar pomeni, da vam jih sploh ni treba naložiti. V računalniku z nizko porabo energije je CPE ozko grlo, zato je prednost uporabe majhnih vsebnikov tukaj veliko večja.
Če uporabljate GCR, toplo priporočam uporabo Google Container Builder (GCB) kot dela vašega gradbenega sistema.
Kot lahko vidite, vam njegova uporaba omogoča doseganje veliko boljših rezultatov pri skrajšanju trajanja operacije Build+Push kot celo produktivni stroj - v tem primeru je postopek gradnje in pošiljanja vsebnikov gostitelju skoraj 2-krat hitrejši. Poleg tega vsak dan dobite 120 brezplačnih minut gradnje, kar v večini primerov pokrije vaše potrebe po gradnji kontejnerjev.
Sledi najpomembnejša metrika uspešnosti – hitrost pridobivanja ali nalaganja Pull vsebnikov. In če vam ni veliko mar za čas, porabljen za operacijo potiskanja, potem ima dolžina postopka vlečenja resen vpliv na celotno delovanje sistema. Recimo, da imate gručo treh vozlišč in eno od njih odpove. Če uporabljate sistem za upravljanje, kot je Google Kubernetes Engine, bo samodejno zamenjal mrtvo vozlišče z novim. Vendar bo to novo vozlišče popolnoma prazno in vanj boste morali povleči vse svoje vsebnike, da bo začelo delovati. Če postopek vleke traja dovolj dolgo, bo vaša gruča ves čas delovala z nižjo zmogljivostjo.
Obstaja veliko primerov, ko se to lahko zgodi: dodajanje novega vozlišča v gručo, nadgradnja vozlišč ali celo preklop na nov vsebnik za uvajanje. Tako zmanjševanje časa izvleka postane ključni dejavnik. Nesporno je, da se majhen vsebnik prenese veliko hitreje kot velik. Če uporabljate več vsebnikov v gruči Kubernetes, so lahko prihranki časa občutni.
Oglejte si to primerjavo: operacija vleke na majhnih vsebnikih traja 4-9-krat manj časa, odvisno od moči stroja, kot ista operacija z go:onbuild. Uporaba deljenih osnovnih slik majhnega vsebnika znatno pospeši čas in hitrost, s katero je mogoče razmestiti in vzpostaviti splet novih vozlišč Kubernetes.
Poglejmo vprašanje varnosti. Manjše posode veljajo za veliko varnejše od večjih, ker imajo manjšo napadalno površino. Je res? Ena najbolj uporabnih funkcij Googlovega registra vsebnikov je zmožnost samodejnega skeniranja vaših vsebnikov za ranljivosti. Pred nekaj meseci sem ustvaril vsebnike onbuild in multistage, zato poglejmo, ali so tam kakšne ranljivosti.
Rezultat je neverjeten: v majhnem vsebniku so bile odkrite le 3 srednje ranljivosti, v velikem vsebniku pa 16 kritičnih in 376 drugih ranljivosti. Če pogledamo vsebino velikega vsebnika, vidimo, da večina varnostnih težav nima nobene zveze z našo aplikacijo, ampak so povezane s programi, ki jih niti ne uporabljamo. Torej, ko ljudje govorijo o veliki napadalni površini, to mislijo.
Zaključek je jasen: zgradite majhne vsebnike, ker vašemu sistemu zagotavljajo resnično učinkovitost in varnost.
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com