Pirmais Kubernetes ieviešanas solis ir lietojumprogrammas ievietošana konteinerā. Šajā sērijā mēs aplūkosim, kā izveidot nelielu un drošu konteinera attēlu.
Pateicoties Docker, konteinera attēlu izveide vēl nekad nav bijusi tik vienkārša. Norādiet bāzes attēlu, pievienojiet izmaiņas un izveidojiet konteineru.
Lai gan šī metode ir lieliska sākumam, noklusējuma bāzes attēlu izmantošana var radīt nedrošību, strādājot ar lieliem attēliem, kas ir pilni ar ievainojamībām.
Turklāt lielākā daļa attēlu pakalpojumā Docker tiek izmantoti kā bāzes attēls Debian vai UbuntuLai gan tas nodrošina lielisku saderību un vienkāršu pielāgošanu (Docker failam nepieciešamas tikai divas koda rindiņas), bāzes attēli var pievienot konteineram simtiem megabaitu papildu slodzes. Piemēram, vienkāršs node.js fails Go "hello-world" lietojumprogrammai aizņem aptuveni 700 megabaitus, pat ja jūsu faktiskā lietojumprogramma ir tikai dažu megabaitu liela.
Tātad, visas šīs papildu izmaksas ir digitālās telpas izšķiešana un ideāla slēptuve ievainojamībām un drošības kļūdām. Apskatīsim divus veidus, kā samazināt konteinera attēla izmēru.
Pirmais ir mazu bāzes attēlu izmantošana, otrais — veidotāja modeļa izmantošana. Mazāku bāzes attēlu izmantošana, iespējams, ir vienkāršākais veids, kā samazināt konteinera izmēru. Visticamāk, jūsu valoda vai steks ģenerē vietējo lietojumprogrammas attēlu, kas ir daudz mazāks nekā noklusējuma attēls. Apskatīsim mūsu Node.js konteineru.
Pēc noklusējuma node:8 bāzes attēla lielums Docker vidē ir 670 MB, savukārt node:8-alpine — tikai 65 MB, kas ir 10 reizes mazāk. Izmantojot mazāku Alpine bāzes attēlu, ievērojami samazināsies konteinera lielums. Alpine ir mazs un viegls distributīvs. Linux, kas ir ļoti populārs Docker lietotāju vidū, jo tas ir saderīgs ar daudzām lietojumprogrammām, vienlaikus saglabājot mazus konteineru izmērus. Atšķirībā no standarta Docker "mezgla" attēla, "node:alpine" noņem daudzus pakalpojumu failus un programmas, atstājot tikai tos, kas nepieciešami lietojumprogrammas palaišanai.
Lai pārietu uz mazāku bāzes attēlu, vienkārši atjauniniet Dockerfile, lai sāktu ar jauno bāzes attēlu:
Tagad, atšķirībā no vecā onbuild attēla, kods ir jākopē konteinerā un jāinstalē visas atkarības. Jaunajā Dockerfile konteiners sākas ar attēlu node:alpine, pēc tam izveido direktoriju kodam, instalē atkarības, izmantojot NPM pakotņu pārvaldnieku, un visbeidzot palaiž server.js.
Šis atjauninājums samazina konteinera izmēru 10 reizes. Ja jūsu programmēšanas valoda vai steks neatbalsta bāzes attēla samazināšanu, izmantojiet Alpine. LinuxTas arī nodrošinās pilnīgu kontroli pār konteinera saturu. Mazu bāzes attēlu izmantošana ir lielisks veids, kā ātri izveidot mazus konteinerus. Taču vēl lielāku izmēra samazinājumu var panākt, izmantojot veidotāja paraugu.
Interpretētās valodās pirmkods vispirms tiek nodots interpretētājam un pēc tam izpildīts. Kompilētās valodās pirmkods vispirms tiek pārveidots par kompilētu kodu. Kompilācijā bieži tiek izmantoti rīki, kas faktiski nav nepieciešami koda palaišanai. Tas nozīmē, ka šos rīkus var pilnībā noņemt no galīgā konteinera. Šim nolūkam var izmantot veidotāja paraugu.
Kods tiek izveidots pirmajā konteinerā un kompilēts. Pēc tam kompilētais kods tiek iepakots galīgajā konteinerā bez kompilatoriem un rīkiem, kas nepieciešami koda kompilēšanai. Apskatīsim šo procesu Go lietojumprogrammai. Vispirms mēs migrēsim no onbuild attēla uz Alpine. Linux.
Jaunajā Docker failā konteiners sākas ar attēlu golang:alpine. Pēc tam tas izveido koda direktoriju, kopē to avota kodā, kompilē šo avota kodu un palaiž lietojumprogrammu. Šis konteiners ir daudz mazāks nekā onbuild konteiners, taču tajā joprojām ir kompilators un citi Go rīki, kas mums īsti nav nepieciešami. Tāpēc vienkārši izvilksim kompilēto programmu un ievietosim to atsevišķā konteinerā.
Jūs varētu pamanīt kaut ko dīvainu šajā Dockerfile failā: tajā ir divas FROM rindas. Pirmā četru rindiņu sadaļa izskatās tieši tāpat kā iepriekšējais Dockerfile fails, izņemot to, ka šī posma nosaukšanai tiek izmantots atslēgvārds AS. Nākamajā sadaļā ir jauna FROM rinda, kas ļauj mums sākt jaunu attēlu. Tā vietā, lai kā bāzes attēlu izmantotu golang:alpine attēlu, mēs izmantosim Raw alpine.
Neapstrādāts Alpu Linux nav instalēts neviens SSL sertifikāts, kā rezultātā lielākā daļa API izsaukumu, izmantojot HTTPS, neizdosies, tāpēc instalēsim dažus saknes sertificēšanas sertifikātus.
Un tagad sākas jautrā daļa: lai kopētu kompilēto kodu no pirmā konteinera uz otro, varat vienkārši izmantot komandu COPY, kas atrodas otrās sadaļas 5. rindā. Tas kopēs tikai vienu lietojumprogrammas failu un neietekmēs Go utilītprogrammas rīkus. Jaunais daudzpakāpju Dockerfile saturēs tikai 12 megabaitu lielu konteinera attēlu, salīdzinot ar sākotnējā konteinera attēla izmēru 700 megabaiti — liela atšķirība!
Tātad, mazu bāzes attēlu un veidotāja modeļa izmantošana ir lieliski veidi, kā bez liela darba izveidot daudz mazākus konteinerus.
Atkarībā no lietojumprogrammu komplekta var būt papildu veidi, kā samazināt attēlu un konteineru izmēru, bet vai mazi konteineri tiešām sniedz izmērāmu labumu? Apskatīsim divas jomas, kurās mazi konteineri ir ārkārtīgi efektīvi: veiktspēja un drošība.
Lai novērtētu veiktspējas pieaugumu, ņemiet vērā laiku, kas nepieciešams konteinera izveidei, ievietošanai reģistrā (push) un pēc tam tā izgūšanai (pull). Var redzēt, ka mazākam konteineram ir izteiktas priekšrocības salīdzinājumā ar lielāku.
Docker kešatmiņā saglabās slāņus, tāpēc turpmākās būvēšanas būs ļoti ātras. Tomēr daudzas CI sistēmas, ko izmanto konteineru veidošanai un testēšanai, slāņus kešatmiņā nesaglabā, tāpēc tas nodrošina ievērojamu laika ietaupījumu. Kā redzat, liela konteinera veidošana aizņem no 34 līdz 54 sekundēm atkarībā no jūsu datora veiktspējas, savukārt, izmantojot konteineru, kas ir samazināts, izmantojot Builder Pattern, tas aizņem no 23 līdz 28 sekundēm. Šādām darbībām veiktspējas pieaugums ir 40–50%. Tāpēc vienkārši padomājiet par to, cik bieži jūs veidojat un testējat savu kodu.
Kad konteiners ir izveidots, tā attēls ir jāievieto konteinera reģistrā, lai to izmantotu savā Kubernetes klasterī. Es iesaku izmantot Google konteineru reģistru.
Izmantojot Google Container Registry (GCR), jūs maksājat tikai par neapstrādātu datu krātuvi un tīklošanu, bez papildu konteineru pārvaldības maksas. Tas ir privāts, drošs un neticami ātrs. GCR izmanto daudzus trikus, lai paātrinātu izvilkšanas darbības. Kā redzat, Docker konteinera attēla ievietošana, izmantojot go:onbuild, aizņem no 15 līdz 48 sekundēm atkarībā no datora veiktspējas, savukārt tā pati darbība ar mazāku konteineru aizņem no 14 līdz 16 sekundēm, un ātruma priekšrocība mazākas veiktspējas datoros palielinās trīs reizes. Lielākās datoros laiks ir aptuveni vienāds, jo GCR koplietotajai attēlu datubāzei izmanto globālu kešatmiņu, kas nozīmē, ka tie vispār nav jālejupielādē. Datorā ar mazu enerģijas patēriņu centrālais procesors ir sašaurinājums, tāpēc mazāku konteineru izmantošanas priekšrocība ir daudz pamanāmāka.
Ja izmantojat GCR, ļoti iesaku izmantot Google Container Builder (GCB) kā daļu no savas būvēšanas sistēmas.
Kā redzat, tā izmantošana ļauj sasniegt ievērojami labākus rezultātus Build+Push darbības laika samazināšanā nekā pat ar augstas veiktspējas iekārtu – šajā gadījumā konteineru veidošanas un nosūtīšanas process uz resursdatoru ir gandrīz 2 reizes ātrāks. Turklāt jūs katru dienu saņemat 120 minūtes bezmaksas veidošanas laika, kas apmierina lielāko daļu konteineru izveides vajadzību.
Tālāk seko vissvarīgākais veiktspējas rādītājs — konteineru lejupielādes ātrums. Lai gan jūs īpaši neuztrauc laiks, kas nepieciešams nosūtīšanai, nosūtīšanas procesa ilgums nopietni ietekmē sistēmas kopējo veiktspēju. Pieņemsim, ka jums ir trīs mezglu klasteris, un viens no tiem neizdodas. Ja izmantojat pārvaldības sistēmu, piemēram, Google Kubernetes Engine, tā automātiski aizstās neizdevušos mezglu ar jaunu. Tomēr šis jaunais mezgls būs pilnīgi tukšs, un, lai to atsāktu darboties, jums būs jāpārsūta visi konteineri. Ja nosūtīšanas darbība aizņem ilgu laiku, klastera veiktspēja šajā laikā samazināsies.
Ir daudz scenāriju, kā tas var notikt: jauna mezgla pievienošana klasterim, mezglu atjaunināšana vai pat pārslēgšanās uz jaunu konteineru izvietošanai. Tāpēc ir svarīgi samazināt ielādes laiku. Neapstrīdami, ka mazs konteiners tiek lejupielādēts daudz ātrāk nekā liels. Ja Kubernetes klasterī darbinat vairākus konteinerus, laika ietaupījums var būt ievērojams.
Apskatiet tālāk sniegto salīdzinājumu: vilkšanas operācija ar maziem konteineriem aizņem 4–9 reizes ātrāk, atkarībā no datora veiktspējas, nekā tā pati operācija, izmantojot go:onbuild. Izmantojot koplietotus, mazus konteineru bāzes attēlus, ievērojami tiek paātrināts laiks un ātrums, ar kādu jaunus Kubernetes mezglus var izvietot un aktivizēt.
Apskatīsim drošības jautājumu. Pastāv uzskats, ka mazāki konteineri ir daudz drošāki nekā lieli, jo tiem ir mazāka uzbrukuma virsma. Vai tā tiešām ir taisnība? Viena no Google Container Registry noderīgākajām funkcijām ir tā spēja automātiski skenēt konteinerus, lai atrastu ievainojamības. Pirms dažiem mēnešiem es izveidoju gan onbuild, gan daudzpakāpju konteinerus, tāpēc apskatīsim, vai ir kādas ievainojamības.
Rezultāti ir pārsteidzoši: mazajā konteinerā tika atrastas tikai 3 vidējas pakāpes ievainojamības, savukārt lielajā — 16 kritiskas un 376 citas ievainojamības. Aplūkojot lielā konteinera saturu, ir skaidrs, ka lielākajai daļai drošības problēmu nav nekāda sakara ar mūsu lietojumprogrammu, bet gan ar programmām, kuras mēs pat neizmantojam. Tāpēc, kad cilvēki runā par lielu uzbrukuma virsmu, viņi to arī domā.
Secinājums ir skaidrs: veidojiet mazus konteinerus, jo tie nodrošina reālas veiktspējas un drošības priekšrocības jūsu sistēmai.
Dažas reklāmas 🙂
Paldies, ka palikāt kopā ar mums. Vai jums patīk mūsu raksti? Vai vēlaties redzēt interesantāku saturu? Atbalsti mūs, pasūtot vai iesakot draugiem, , unikāls sākuma līmeņa serveru analogs, ko mēs jums izgudrojām: (pieejams ar RAID1 un RAID10, līdz 24 kodoliem un līdz 40 GB DDR4).
Dell R730xd 2x lētāk Equinix Tier IV datu centrā Amsterdamā? Tikai šeit Nīderlandē! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB — no 99 USD! Lasīt par
Avots: www.habr.com
