Fyrsta skrefið við að dreifa til Kubernetes er að setja forritið þitt í gám. Í þessari seríu munum við skoða hvernig þú getur búið til litla, örugga gámamynd.
Þökk sé Docker hefur aldrei verið auðveldara að búa til gámamyndir. Tilgreindu grunnmynd, bættu við breytingunum þínum og búðu til ílát.
Þó að þessi tækni sé frábær til að byrja, getur notkun sjálfgefna grunnmynda leitt til óöruggrar vinnu með stórar myndir fullar af veikleikum.
Að auki nota flestar myndir í Docker Debian eða Ubuntu fyrir grunnmyndina, og þó að þetta veiti framúrskarandi eindrægni og auðvelda aðlögun (Docker skrá tekur aðeins tvær línur af kóða), geta grunnmyndir bætt hundruðum megabæta af viðbótarálagi við ílátið þitt. Til dæmis er einföld node.js skrá fyrir Go "hello-world" forrit um 700 megabæti, en raunverulegt forrit þitt er aðeins nokkur megabæt að stærð.
Svo allt þetta auka vinnuálag er sóun á stafrænu rými og frábær felustaður fyrir öryggisveikleika og villur. Svo skulum við skoða tvær leiðir til að minnka stærð gámamyndar.
Hið fyrra er notkun lítilla grunnmynda, hið síðara er notkun Builder Pattern. Að nota smærri grunnmyndir er líklega auðveldasta leiðin til að minnka stærð ílátsins. Líklegast er að tungumálið eða staflan sem þú notar gefur upprunalega forritamynd sem er mun minni en sjálfgefna myndin. Við skulum kíkja á node.js gáminn okkar.
Sjálfgefið er í Docker, grunnstærð hnút: 8 er 670 MB og hnútur: 8 alpa myndastærð er aðeins 65 MB, það er 10 sinnum minni. Með því að nota minni Alpine grunnmyndina minnkarðu umtalsvert stærð ílátsins. Alpine er lítil og létt Linux dreifing sem er mjög vinsæl meðal Docker notenda vegna þess að hún er samhæf við mörg forrit en heldur litlum ílátum. Ólíkt venjulegu Docker „node“ myndinni fjarlægir „node:alpine“ mikið af þjónustuskrám og forritum og skilur aðeins eftir þær sem nægja til að keyra forritið þitt.
Til að fara yfir í minni grunnmynd skaltu einfaldlega uppfæra Dockerfile til að byrja að vinna með nýju grunnmyndina:
Nú, ólíkt gömlu onbuild myndinni, þarftu að afrita kóðann þinn í ílátið og setja upp hvaða ósjálfstæði sem er. Í nýrri Dockerfile byrjar gámurinn með node:alpine mynd, býr síðan til möppu fyrir kóðann, setur upp ósjálfstæði með því að nota NPM pakkastjórann og keyrir loks server.js.
Þessi uppfærsla leiðir til gáms sem er 10 sinnum minni að stærð. Ef forritunarmálið þitt eða stafli er ekki með grunnvirkni ímyndarskerðingar skaltu nota Alpine Linux. Það mun einnig veita getu til að stjórna innihaldi ílátsins að fullu. Að nota litlar grunnmyndir er frábær leið til að búa til litla ílát fljótt. En enn meiri lækkun er hægt að ná með því að nota Builder Pattern.
Í túlkuðum tungumálum er frumkóði fyrst sendur til túlksins og síðan keyrður beint út. Í samsettum tungumálum er frumkóðanum fyrst breytt í samsettan kóða. Hins vegar notar samantekt oft verkfæri sem eru í raun ekki nauðsynleg til að keyra kóðann. Þetta þýðir að þú getur alveg fjarlægt þessi verkfæri úr lokaílátinu. Þú getur notað Builder Pattern fyrir þetta.
Kóðinn er búinn til í fyrsta gámnum og settur saman. Samsetta kóðanum er síðan pakkað í endanlegt ílát án þýðenda og tóla sem þarf til að setja saman þann kóða. Við skulum keyra Go forrit í gegnum þetta ferli. Í fyrsta lagi förum við frá onbuild myndinni yfir í Alpine Linux.
Í nýju Dockerfile byrjar gámurinn á golang:alpine mynd. Það býr síðan til möppu fyrir kóðann, afritar hann inn í frumkóðann, smíðar þann frumkóða og keyrir forritið. Þessi gámur er miklu minni en innbyggður gámurinn, en hann inniheldur samt þýðanda og önnur Go verkfæri sem við þurfum í rauninni ekki. Svo skulum við bara draga saman forritið og setja það í eigin ílát.
Þú gætir tekið eftir einhverju undarlegu í þessari Docker skrá: hún inniheldur tvær FROM línur. Fyrsti 4 línuhlutinn lítur nákvæmlega eins út og fyrri Dockerfile nema að hann notar AS lykilorðið til að nefna þetta stig. Næsti hluti hefur nýja FROM línu til að hefja nýja mynd, þar sem í stað golang:alpine myndarinnar munum við nota Raw alpine sem grunnmynd.
Raw Alpine Linux er ekki með nein SSL vottorð uppsett, sem veldur því að flest API símtöl yfir HTTPS mistakast, svo við skulum setja upp nokkur rót CA vottorð.
Nú kemur skemmtilegi hlutinn: til að afrita samansetta kóðann frá fyrsta ílátinu yfir í það seinni geturðu einfaldlega notað COPY skipunina sem er staðsett á línu 5 í öðrum hluta. Það mun aðeins afrita eina forritaskrá og hefur ekki áhrif á Go tól. Nýja fjölþrepa Docker skráin mun innihalda gámamynd sem er aðeins 12 megabæti að stærð, samanborið við upprunalegu gámamyndina sem var 700 megabæti, sem er mikill munur!
Svo að nota litlar grunnmyndir og Builder Pattern eru frábærar leiðir til að búa til miklu smærri ílát án mikillar vinnu.
Það er hugsanlegt að það séu fleiri leiðir til að minnka mynd og ílát, allt eftir umsóknarstafla, en hafa lítil ílát raunverulega mælanlegan ávinning? Við skulum skoða tvö svæði þar sem litlir ílát eru einstaklega áhrifarík - afköst og öryggi.
Til að meta frammistöðuaukninguna skaltu íhuga tímalengd ferlisins við að búa til gám, setja það inn í skrárinn (ýta) og síðan sækja það þaðan (draga). Þú getur séð að minni gámur hefur ákveðna kosti fram yfir stærri gám.
Docker mun geyma lögin í skyndiminni þannig að síðari smíðin verður mjög hröð. Hins vegar eru mörg CI kerfi sem notuð eru til að byggja og prófa gáma ekki skyndiminni lög, svo það er umtalsverður tímasparnaður. Eins og þú sérð er tíminn til að smíða stóran gám, allt eftir krafti vélarinnar þinnar, frá 34 til 54 sekúndur, og þegar gámur er notaður minnkaður með því að nota Builder Pattern - úr 23 til 28 sekúndum. Fyrir rekstur af þessu tagi verður framleiðniaukningin 40-50%. Svo hugsaðu bara um hversu oft þú byggir og prófar kóðann þinn.
Eftir að gámurinn er byggður þarftu að ýta myndinni (ýta gámamynd) inn í gámaskrána svo þú getir notað hana í Kubernetes þyrpingunni þinni. Ég mæli með því að nota Google Container Registry.
Með Google Container Registry (GCR) greiðir þú aðeins fyrir hráa geymslu og netkerfi, og það eru engin viðbótargjöld fyrir gámastjórnun. Það er einkarekið, öruggt og mjög hratt. GCR notar mörg brellur til að flýta fyrir togaðgerðinni. Eins og þú sérð mun það taka frá 15 til 48 sekúndur að setja inn Docker Container Image gám með því að nota go:onbuild, allt eftir afköstum tölvunnar, og sama aðgerð með minni ílát mun taka frá 14 til 16 sekúndur og fyrir afkastaminni vélar kosturinn í vinnsluhraða eykst um 3 sinnum. Fyrir stærri vélar er tíminn um það bil sá sami, þar sem GCR notar alþjóðlegt skyndiminni fyrir sameiginlegan gagnagrunn með myndum, sem þýðir að þú þarft alls ekki að hlaða þeim. Í lítilli afltölvu er örgjörvinn flöskuhálsinn þannig að kosturinn við að nota litla ílát er miklu meiri hér.
Ef þú ert að nota GCR mæli ég eindregið með því að nota Google Container Builder (GCB) sem hluta af byggingarkerfinu þínu.
Eins og þú sérð gerir notkun þess þér kleift að ná mun betri árangri við að draga úr lengd Build+Push aðgerðarinnar heldur en jafnvel afkastamikil vél - í þessu tilviki er ferlið við að byggja og senda gáma til gestgjafans flýtt um næstum 2 sinnum . Auk þess færðu 120 ókeypis smíðismínútur á hverjum degi, sem dekkir gámabyggingarþarfir þínar í flestum tilfellum.
Næst kemur mikilvægasta frammistöðumælingin - hraðinn við að sækja, eða hlaða niður, draga ílát. Og ef þér er ekki alveg sama um þann tíma sem fer í ýtaaðgerð, þá hefur lengd togferlisins alvarleg áhrif á heildarafköst kerfisins. Segjum að þú sért með þyrping af þremur hnútum og einn þeirra mistekst. Ef þú ert að nota stjórnunarkerfi eins og Google Kubernetes Engine mun það sjálfkrafa skipta um dauða hnút fyrir nýjan. Hins vegar verður þessi nýi hnútur alveg tómur og þú verður að draga alla ílátin þín inn í hann til að hann fari að virka. Ef togaðgerðin tekur nógu langan tíma mun klasinn þinn keyra með minni afköst allan tímann.
Það eru mörg tilvik þar sem þetta getur gerst: að bæta nýjum hnút við þyrping, uppfæra hnúta, eða jafnvel skipta yfir í nýjan gáma til dreifingar. Þannig að lágmarka útdráttartíma verður lykilatriði. Það er óumdeilt að lítill gámur hleður niður miklu hraðar en stór. Ef þú ert að keyra marga gáma í Kubernetes klasa getur tímasparnaðurinn verið umtalsverður.
Skoðaðu þennan samanburð: Togaðgerð á litlum gámum tekur 4-9 sinnum styttri tíma, allt eftir afli vélarinnar, en sama aðgerð með go:onbuild. Með því að nota sameiginlegar, litlar gámagrunnmyndir flýtir verulega fyrir þeim tíma og hraða sem hægt er að nota nýja Kubernetes hnúta og koma á netið.
Lítum á öryggismálið. Minni gámar eru taldir mun öruggari en stærri vegna þess að þeir hafa minna árásarflöt. Er það virkilega? Einn af gagnlegustu eiginleikum Google Container Registry er hæfileikinn til að skanna gámana þína sjálfkrafa fyrir varnarleysi. Fyrir nokkrum mánuðum bjó ég til bæði innbyggða og fjölþrepa gáma, svo við skulum sjá hvort það sé einhver veikleiki þar.
Niðurstaðan er ótrúleg: aðeins 3 miðlungs veikleikar fundust í litlum gámi og 16 mikilvægir og 376 aðrir veikleikar fundust í stórum gámi. Ef við skoðum innihald stórs íláts getum við séð að flest öryggisvandamálin hafa ekkert með forritið okkar að gera heldur tengjast forritum sem við notum ekki einu sinni. Svo þegar fólk talar um stórt sóknarflöt, þá er það það sem það meinar.
Afgreiðslan er skýr: byggðu litla gáma vegna þess að þeir veita kerfinu þínu raunverulegan árangur og öryggisávinning.
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com