Hatua ya kwanza ya kupeleka kwa Kubernetes ni kuweka programu yako kwenye kontena. Katika mfululizo huu, tutaangalia jinsi unavyoweza kuunda picha ya kontena ndogo na salama.
Shukrani kwa Docker, kuunda picha za chombo haijawahi kuwa rahisi. Bainisha picha ya msingi, ongeza mabadiliko yako na uunde chombo.
Ingawa mbinu hii ni nzuri kwa kuanza, kutumia picha za msingi kunaweza kusababisha kazi isiyo salama na picha kubwa zilizojaa udhaifu.
Zaidi ya hayo, picha nyingi kwenye Docker hutumia Debian au Ubuntu kwa picha ya msingi, na ingawa hii inatoa utangamano bora na ubinafsishaji rahisi (faili ya Docker inachukua mistari miwili tu ya msimbo), picha za msingi zinaweza kuongeza mamia ya megabytes ya mzigo wa ziada kwenye chombo chako. Kwa mfano, faili rahisi ya node.js ya programu ya Go "hello-world" ina takriban megabaiti 700, wakati programu yako halisi ina ukubwa wa megabaiti chache.
Kwa hivyo mzigo huu wote wa ziada ni kupoteza nafasi ya kidijitali na mahali pazuri pa kujificha kwa udhaifu na hitilafu za kiusalama. Kwa hiyo, hebu tuangalie njia mbili za kupunguza ukubwa wa picha ya chombo.
Ya kwanza ni matumizi ya picha ndogo za msingi, pili ni matumizi ya Muundo wa Wajenzi. Kutumia picha ndogo za msingi pengine ndiyo njia rahisi ya kupunguza ukubwa wa chombo chako. Uwezekano mkubwa zaidi, lugha au rafu unayotumia hutoa picha halisi ya programu ambayo ni ndogo zaidi kuliko picha chaguo-msingi. Hebu tuangalie chombo chetu cha node.js.
Kwa chaguo-msingi katika Docker, nodi: saizi ya picha ya msingi 8 ni 670 MB, na nodi: saizi ya picha ya 8-alpine ni 65 MB tu, ambayo ni, mara 10 ndogo. Kwa kutumia picha ndogo ya msingi wa Alpine, utapunguza kwa kiasi kikubwa ukubwa wa chombo chako. Alpine ni usambazaji mdogo na mwepesi wa Linux ambao ni maarufu sana kati ya watumiaji wa Docker kwa sababu unaendana na programu nyingi huku ukiweka vyombo vidogo. Tofauti na picha ya kawaida ya "nodi" ya Docker, "node:alpine" huondoa faili na programu nyingi za huduma, na kuacha tu zile zinazotosha kuendesha programu yako.
Ili kuhamia picha ndogo ya msingi, sasisha tu Dockerfile ili kuanza kufanya kazi na taswira mpya ya msingi:
Sasa, tofauti na picha ya zamani ya kujenga, unahitaji kunakili msimbo wako kwenye chombo na usakinishe vitegemezi vyovyote. Katika Dockerfile mpya, kontena huanza na nodi: picha ya alpine, kisha hutengeneza saraka ya msimbo, husakinisha vitegemezi kwa kutumia kidhibiti cha kifurushi cha NPM, na hatimaye huendesha server.js.
Uboreshaji huu husababisha kontena ambalo ni ndogo mara 10 kwa ukubwa. Ikiwa lugha yako ya programu au rafu haina utendaji wa msingi wa kupunguza picha, tumia Alpine Linux. Pia itatoa uwezo wa kusimamia kikamilifu yaliyomo kwenye kontena. Kutumia picha ndogo za msingi ni njia nzuri ya kuunda vyombo vidogo haraka. Lakini upunguzaji mkubwa zaidi unaweza kupatikana kwa kutumia Muundo wa Wajenzi.
Katika lugha zilizotafsiriwa, msimbo wa chanzo kwanza hupitishwa kwa mkalimani na kisha kutekelezwa moja kwa moja. Katika lugha zilizokusanywa, msimbo wa chanzo kwanza hubadilishwa kuwa msimbo uliokusanywa. Walakini, mkusanyiko mara nyingi hutumia zana ambazo hazihitajiki kabisa kutekeleza nambari. Hii ina maana kwamba unaweza kuondoa kabisa zana hizi kutoka kwenye chombo cha mwisho. Unaweza kutumia Muundo wa Wajenzi kwa hili.
Nambari imeundwa kwenye chombo cha kwanza na kukusanywa. Nambari iliyokusanywa basi huwekwa kwenye kontena la mwisho bila watunzi na zana zinazohitajika kuunda nambari hiyo. Wacha tuendeshe ombi la Go kupitia mchakato huu. Kwanza, tutahama kutoka kwa picha ya ujenzi hadi Alpine Linux.
Katika Dockerfile mpya, kontena huanza na picha ya golang:alpine. Kisha huunda saraka ya msimbo, kuinakili kwenye msimbo wa chanzo, huunda msimbo huo wa chanzo, na kuendesha programu. Chombo hiki ni kidogo zaidi kuliko chombo cha kujenga upya, lakini bado kina kikusanyaji na zana zingine za Go ambazo hatuzihitaji sana. Kwa hivyo, wacha tutoe programu iliyokusanywa na kuiweka kwenye chombo chake.
Unaweza kugundua kitu cha kushangaza kwenye faili hii ya Docker: ina mistari miwili ya FROM. Sehemu ya kwanza ya mstari 4 inaonekana sawa na Dockerfile iliyopita isipokuwa kwamba hutumia neno kuu la AS kutaja hatua hii. Sehemu inayofuata ina mstari mpya wa FROM ili kuanzisha picha mpya, ambapo badala ya picha ya golang:alpine tutatumia Alpine Ghafi kama taswira ya msingi.
Raw Alpine Linux haina vyeti vyovyote vya SSL vilivyosakinishwa, jambo ambalo litasababisha simu nyingi za API kupitia HTTPS kushindwa, kwa hivyo hebu tusakinishe baadhi ya vyeti vya CA.
Sasa inakuja sehemu ya kufurahisha: kunakili nambari iliyokusanywa kutoka kwa kontena la kwanza hadi la pili, unaweza kutumia amri ya COPY iliyoko kwenye mstari wa 5 wa sehemu ya pili. Itanakili faili moja ya programu tu na haitaathiri zana za matumizi ya Go. Faili mpya ya Docker ya hatua nyingi itakuwa na picha ya kontena ambayo ina ukubwa wa megabaiti 12 pekee, ikilinganishwa na picha ya kontena asilia iliyokuwa megabaiti 700, ambayo ni tofauti kubwa!
Kwa hivyo kutumia picha ndogo za msingi na Muundo wa Wajenzi ni njia nzuri za kuunda vyombo vidogo zaidi bila kazi nyingi.
Inawezekana kwamba kulingana na rundo la programu, kuna njia za ziada za kupunguza saizi ya picha na kontena, lakini je, vyombo vidogo vina faida inayoweza kupimika? Hebu tuangalie maeneo mawili ambapo vyombo vidogo ni bora sana - utendaji na usalama.
Ili kutathmini ongezeko la utendaji, fikiria muda wa mchakato wa kuunda chombo, ukiingiza kwenye Usajili (kushinikiza), na kisha uipate kutoka hapo (kuvuta). Unaweza kuona kwamba chombo kidogo kina faida tofauti juu ya chombo kikubwa.
Docker itahifadhi tabaka ili ujenzi unaofuata utakuwa haraka sana. Walakini, mifumo mingi ya CI inayotumiwa kuunda na kujaribu kontena haihifadhi safu, kwa hivyo kuna uokoaji mkubwa wa wakati. Kama unaweza kuona, wakati wa kujenga chombo kikubwa, kulingana na nguvu ya mashine yako, ni kutoka sekunde 34 hadi 54, na wakati wa kutumia chombo kilichopunguzwa kwa kutumia Mchoro wa Wajenzi - kutoka sekunde 23 hadi 28. Kwa shughuli za aina hii, ongezeko la tija litakuwa 40-50%. Kwa hivyo fikiria tu ni mara ngapi unaunda na kujaribu nambari yako.
Baada ya kontena kujengwa, unahitaji kusukuma picha yake (picha ya kontena ya kushinikiza) kwenye sajili ya chombo ili uweze kuitumia kwenye nguzo yako ya Kubernetes. Ninapendekeza kutumia Usajili wa Vyombo vya Google.
Ukiwa na Usajili wa Makontena ya Google (GCR), unalipia tu hifadhi ghafi na mtandao, na hakuna ada za ziada za udhibiti wa kontena. Ni ya faragha, salama na ya haraka sana. GCR hutumia hila nyingi ili kuharakisha operesheni ya kuvuta. Kama unavyoona, kuingiza kontena ya Picha ya Kontena ya Docker kwa kutumia go:onbuild itachukua kutoka sekunde 15 hadi 48, kulingana na utendakazi wa kompyuta, na operesheni sawa na kontena ndogo itachukua kutoka sekunde 14 hadi 16, na kwa mashine zinazozalisha kidogo. faida katika kasi ya operesheni huongezeka kwa mara 3. Kwa mashine kubwa, wakati ni sawa, kwani GCR hutumia kashe ya kimataifa kwa hifadhidata iliyoshirikiwa ya picha, kumaanisha kuwa hauitaji kuzipakia hata kidogo. Katika kompyuta yenye nguvu ya chini, CPU ni kizuizi, hivyo faida ya kutumia vyombo vidogo ni kubwa zaidi hapa.
Ikiwa unatumia GCR, ninapendekeza sana kutumia Google Container Builder (GCB) kama sehemu ya mfumo wako wa ujenzi.
Kama unavyoona, matumizi yake hukuruhusu kufikia matokeo bora zaidi katika kupunguza muda wa operesheni ya Kuunda+Push kuliko hata mashine inayozalisha - katika kesi hii, mchakato wa kujenga na kutuma vyombo kwa mwenyeji ni karibu mara 2 haraka. Pia, unapata dakika 120 za ujenzi bila malipo kila siku, ambayo inashughulikia mahitaji yako ya ujenzi wa kontena mara nyingi.
Kinachofuata ni kipimo muhimu zaidi cha utendakazi - kasi ya kurejesha, au kupakua, Vuta vyombo. Na ikiwa haujali sana wakati uliotumika kwenye operesheni ya kushinikiza, basi urefu wa mchakato wa kuvuta una athari kubwa kwa utendaji wa jumla wa mfumo. Wacha tuseme una nguzo ya nodi tatu na moja yao inashindwa. Ikiwa unatumia mfumo wa usimamizi kama vile Google Kubernetes Engine, utabadilisha kiotomatiki nodi iliyokufa na mpya. Walakini, nodi hii mpya itakuwa tupu kabisa na itabidi uburute vyombo vyako vyote ndani yake ili ianze kufanya kazi. Ikiwa operesheni ya kuvuta itachukua muda wa kutosha, nguzo yako itaendeshwa kwa utendaji wa chini wakati wote.
Kuna matukio mengi ambapo hii inaweza kutokea: kuongeza nodi mpya kwenye nguzo, nodi za kuboresha, au hata kubadili kwenye chombo kipya kwa ajili ya kupelekwa. Kwa hivyo, kupunguza wakati wa uchimbaji wa kuvuta inakuwa jambo kuu. Ni jambo lisilopingika kwamba chombo kidogo hupakuliwa kwa kasi zaidi kuliko kubwa. Ikiwa unaendesha vyombo vingi kwenye nguzo ya Kubernetes, uokoaji wa wakati unaweza kuwa muhimu.
Angalia ulinganisho huu: operesheni ya kuvuta kwenye vyombo vidogo inachukua muda mfupi mara 4-9, kulingana na nguvu ya mashine, kuliko operesheni sawa kwa kutumia go:onbuild. Kutumia picha za msingi za kontena ndogo zilizoshirikiwa huongeza kasi ya muda na kasi ambapo nodi mpya za Kubernetes zinaweza kutumwa na kuja mtandaoni.
Hebu tuangalie suala la usalama. Vyombo vidogo vinachukuliwa kuwa salama zaidi kuliko vile vikubwa kwa sababu vina sehemu ndogo ya mashambulizi. Je, ni kweli? Mojawapo ya vipengele muhimu vya Usajili wa Vyombo vya Google ni uwezo wa kuchanganua vyombo vyako kiotomatiki ili kubaini udhaifu. Miezi michache iliyopita niliunda kontena za onbuild na multistage, kwa hivyo wacha tuone ikiwa kuna udhaifu wowote hapo.
Matokeo yake ni ya kustaajabisha: udhaifu wa wastani 3 pekee ndio uliogunduliwa katika kontena ndogo, na udhaifu 16 muhimu na udhaifu mwingine 376 ulipatikana kwenye kontena kubwa. Ikiwa tunatazama yaliyomo kwenye chombo kikubwa, tunaweza kuona kwamba matatizo mengi ya usalama hayana uhusiano wowote na programu yetu, lakini yanahusiana na programu ambazo hata hatutumii. Kwa hivyo watu wanapozungumza juu ya eneo kubwa la shambulio, ndivyo wanamaanisha.
Kuchukua ni wazi: jenga vyombo vidogo kwa sababu vinatoa utendakazi halisi na manufaa ya usalama kwa mfumo wako.
Baadhi ya matangazo π
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com