Kubernetesisse juurutamise esimene samm on rakenduse paigutamine konteinerisse. Selles seerias vaatleme, kuidas saate luua väikese ja turvalise konteineri kujutise.
Tänu Dockerile pole konteineripiltide loomine kunagi olnud lihtsam. Määrake põhipilt, lisage muudatused ja looge konteiner.
Kuigi see tehnika sobib alustamiseks suurepäraselt, võib vaikepõhipiltide kasutamine kaasa tuua ebaturvalise töö suurte, haavatavust täis piltidega.
Lisaks kasutavad enamik Dockeri pilte põhipildina Debianit või Ubuntut ning kuigi see tagab suurepärase ühilduvuse ja hõlpsa kohandamise (Dokkeri fail võtab vaid kaks koodirida), võivad põhipildid teie konteinerile lisada sadu megabaite lisakoormust. Näiteks Go "hello-world" rakenduse lihtne node.js fail on umbes 700 megabaiti, samas kui teie tegelik rakendus on vaid mõne megabaidi suurune.
Seega on kogu see lisatöökoormus digitaalse ruumi raiskamine ja suurepärane peidupaik turvaaukude ja vigade jaoks. Nii et vaatame kahte võimalust konteineri kujutise suuruse vähendamiseks.
Esimene on väikeste aluspiltide kasutamine, teine on Builder Pattern kasutamine. Väiksemate aluspiltide kasutamine on ilmselt lihtsaim viis konteineri suuruse vähendamiseks. Tõenäoliselt pakub kasutatav keel või virn algse rakenduse kujutist, mis on palju väiksem kui vaikekujutis. Vaatame oma node.js konteinerit.
Vaikimisi on Dockeris node:8 põhipildi suurus 670 MB ja node: 8-alpine pildi suurus vaid 65 MB, st 10 korda väiksem. Väiksemat Alpine aluspilti kasutades vähendate oluliselt oma konteineri suurust. Alpine on väike ja kerge Linuxi distributsioon, mis on Dockeri kasutajate seas väga populaarne, kuna see ühildub paljude rakendustega, hoides konteinerid väiksena. Erinevalt tavalisest Dockeri "sõlme" kujutisest eemaldab "node:alpine" palju teenusefaile ja programme, jättes alles ainult need, millest piisab teie rakenduse käivitamiseks.
Väiksema põhipildi juurde liikumiseks värskendage lihtsalt Dockeri faili, et alustada tööd uue põhipildiga:
Nüüd, erinevalt vanast onbuildi pildist, peate oma koodi konteinerisse kopeerima ja installima kõik sõltuvused. Uues Dockerfile'is alustab konteiner kujutisega node:alpine, seejärel loob koodi jaoks kataloogi, installib NPM-i paketihalduri abil sõltuvused ja lõpuks käivitab serveri.js.
Selle täienduse tulemuseks on konteiner, mis on 10 korda väiksem. Kui teie programmeerimiskeelel või pinul puudub põhikujutise vähendamise funktsioon, kasutage Alpine Linuxi. See annab ka võimaluse konteineri sisu täielikult hallata. Väikeste aluspiltide kasutamine on suurepärane viis väikeste konteinerite kiireks loomiseks. Kuid veelgi suuremat vähendamist on võimalik saavutada, kasutades Builder Patternit.
Tõlgitud keeltes edastatakse lähtekood esmalt tõlgile ja seejärel käivitatakse otse. Kompileeritud keeltes teisendatakse lähtekood kõigepealt kompileeritud koodiks. Kompileerimisel kasutatakse aga sageli tööriistu, mida tegelikult koodi käitamiseks vaja pole. See tähendab, et saate need tööriistad lõplikust konteinerist täielikult eemaldada. Selleks saate kasutada Builder Patternit.
Kood luuakse esimeses konteineris ja kompileeritakse. Seejärel pakitakse koostatud kood lõplikku konteinerisse ilma selle koodi kompileerimiseks vajalike kompilaatorite ja tööriistadeta. Käivitame selle protsessi käigus rakenduse Go. Esiteks liigume onbuildi pildilt Alpine Linuxile.
Uues Dockerfile'is algab konteiner kujutisega golang:alpine. Seejärel loob see koodi jaoks kataloogi, kopeerib selle lähtekoodi, koostab selle lähtekoodi ja käivitab rakenduse. See konteiner on palju väiksem kui onbuildi konteiner, kuid sisaldab siiski kompilaatorit ja muid Go tööriistu, mida me tegelikult ei vaja. Ekstrakteerime siis kompileeritud programmi ja paneme selle oma konteinerisse.
Selles Dockeri failis võite märgata midagi kummalist: see sisaldab kahte rida FROM. Esimese neljarealine jaotis näeb välja täpselt sama, mis eelmine Dockerfile, välja arvatud see, et see kasutab selle etapi nimetamiseks AS-i märksõna. Järgmises jaotises on uue pildi alustamiseks uus rida FROM, kus golang:alpine pildi asemel kasutame põhipildina Raw alpine.
Raw Alpine Linuxile ei ole installitud ühtegi SSL-sertifikaati, mis põhjustab enamiku HTTPS-i kaudu tehtavate API-kõnede nurjumise, seega installime mõned juur-CA sertifikaadid.
Nüüd tuleb lõbus osa: kompileeritud koodi kopeerimiseks esimesest konteinerist teise saate lihtsalt kasutada teise jaotise real 5 asuvat käsku COPY. See kopeerib ainult ühe rakendusefaili ega mõjuta Go utiliidi tööriistu. Uus mitmeastmeline Dockeri fail sisaldab konteineri kujutist, mis on vaid 12 megabaidi suur, võrreldes algse konteineri kujutisega, mis oli 700 megabaiti, mis on suur erinevus!
Seega on väikeste aluspiltide ja Builder Pattern kasutamine suurepärane võimalus luua palju väiksemaid konteinereid ilma palju tööd tegemata.
Võimalik, et olenevalt rakenduste pinust on pildi ja konteineri suuruse vähendamiseks täiendavaid võimalusi, kuid kas väikestel konteineritel on tõesti mõõdetavat kasu? Vaatame kahte valdkonda, kus väikesed konteinerid on äärmiselt tõhusad – jõudlus ja turvalisus.
Toimivuse kasvu hindamiseks võtke arvesse konteineri loomise, selle registrisse sisestamise (tõuke) ja sealt allalaadimise (tõmbamise) protsessi kestust. Näete, et väiksemal konteineril on selge eelis suurema konteineri ees.
Docker salvestab kihid vahemällu, nii et järgnevad järgud on väga kiired. Kuid paljud konteinerite ehitamiseks ja testimiseks kasutatavad CI-süsteemid ei salvesta kihte vahemällu, seega säästetakse oluliselt aega. Nagu näete, on suure konteineri ehitamiseks kuluv aeg olenevalt teie masina võimsusest 34 kuni 54 sekundit ja konteineri kasutamisel lüheneb Builder Pattern - 23 sekundilt 28 sekundile. Seda tüüpi toimingute puhul on tootlikkuse kasv 40-50%. Nii et mõelge lihtsalt sellele, mitu korda oma koodi koostate ja testite.
Pärast konteineri loomist peate selle kujutise (tõuke konteineri kujutis) lükkama konteineri registrisse, et saaksite seda seejärel oma Kubernetese klastris kasutada. Soovitan kasutada Google'i konteineriregistrit.
Google'i konteineriregistri (GCR) abil maksate ainult töötlemata salvestusruumi ja võrgu loomise eest ning täiendavaid konteineri haldustasusid pole. See on privaatne, turvaline ja väga kiire. GCR kasutab tõmbamise kiirendamiseks palju nippe. Nagu näete, võtab Docker Container Image konteineri sisestamine go:onbuildi abil olenevalt arvuti jõudlusest 15 kuni 48 sekundit ja sama toiming väiksema konteineriga 14 kuni 16 sekundit ja vähem tootlike masinate puhul. töökiiruse eelis suureneb 3 korda. Suuremate masinate puhul on aeg umbes sama, kuna GCR kasutab jagatud piltide andmebaasi jaoks globaalset vahemälu, mis tähendab, et te ei pea neid üldse laadima. Väikese võimsusega arvutis on kitsaskohaks protsessor, seega on väikeste konteinerite kasutamise eelis siin palju suurem.
Kui kasutate GCR-i, soovitan tungivalt kasutada Google Container Builderit (GCB) oma ehitussüsteemi osana.
Nagu näete, võimaldab selle kasutamine Build+Push operatsiooni kestuse lühendamisel saavutada palju paremaid tulemusi kui isegi tootlik masin – sellisel juhul kiireneb konteinerite ehitamine ja hostile saatmine peaaegu 2 korda. . Lisaks saate iga päev 120 tasuta ehitusminutit, mis katab enamikul juhtudel teie konteinerite ehitamise vajadused.
Järgmiseks tuleb kõige olulisem jõudlusnäidik – Pull konteinerite allalaadimise või allalaadimise kiirus. Ja kui te ei hooli tõuketoimingule kuluvast ajast, mõjutab tõmbamisprotsessi pikkus tõsiselt süsteemi üldist jõudlust. Oletame, et teil on kolmest sõlmest koosnev klaster ja üks neist ebaõnnestub. Kui kasutate haldussüsteemi, näiteks Google Kubernetes Engine, asendab see surnud sõlme automaatselt uuega. See uus sõlm on aga täiesti tühi ja peate kõik oma konteinerid sinna lohistama, et see tööle hakkaks. Kui tõmbamine võtab piisavalt kaua aega, töötab teie klaster kogu aeg madalama jõudlusega.
See võib juhtuda paljudel juhtudel: klastrisse uue sõlme lisamine, sõlmede täiendamine või isegi juurutamiseks uuele konteinerile üleminek. Seega saab võtmeteguriks tõmbamise ekstraheerimisaja minimeerimine. On vaieldamatu, et väike konteiner laadib alla palju kiiremini kui suur. Kui kasutate Kubernetese klastris mitut konteinerit, võib aja kokkuhoid olla märkimisväärne.
Vaadake seda võrdlust: väikeste konteinerite tõmbamine võtab olenevalt masina võimsusest 4–9 korda vähem aega kui sama toiming go:onbuildi abil. Jagatud väikeste konteineripõhiste kujutiste kasutamine kiirendab märkimisväärselt uute Kubernetese sõlmede juurutamise ja võrku jõudmise aega ja kiirust.
Vaatame turvalisuse küsimust. Väiksemaid konteinereid peetakse palju ohutumaks kui suuremaid, kuna neil on väiksem ründepind. Kas tõesti? Google'i konteineriregistri üks kasulikumaid funktsioone on võimalus teie konteinereid turvaaukude tuvastamiseks automaatselt skannida. Paar kuud tagasi lõin nii onbuild- kui ka mitmeastmelised konteinerid, nii et vaatame, kas seal on turvaauke.
Tulemus on hämmastav: väikeses konteineris tuvastati vaid 3 keskmist turvaauku ning suurest konteinerist leiti 16 kriitilist ja 376 muud turvaauku. Kui vaatame suure konteineri sisu, siis näeme, et enamikul turbeprobleemidest pole meie rakendusega mingit pistmist, vaid need on seotud programmidega, mida me isegi ei kasuta. Nii et kui inimesed räägivad suurest rünnakupinnast, siis seda nad mõtlevadki.
See on selge: ehitage väikesed konteinerid, sest need pakuvad teie süsteemile tõelist jõudlust ja turvalisust.
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com