La unua paŝo de deplojiĝo al Kubernetes estas meti vian aplikaĵon en ujo. En ĉi tiu serio, ni rigardos kiel vi povas krei malgrandan, sekuran ujbildon.
Danke al Docker, krei ujajn bildojn neniam estis pli facila. Specifu bazan bildon, aldonu viajn ŝanĝojn kaj kreu ujon.
Kvankam ĉi tiu tekniko estas bonega por komenci, uzi defaŭltajn bazajn bildojn povas konduki al nesekura laboro kun grandaj bildoj plenaj de vundeblecoj.
Aldone, plej multaj bildoj en Docker uzas Debian aŭ Ubuntu por la baza bildo, kaj kvankam ĉi tio provizas bonegan kongruecon kaj facilan personigon (Docker-dosiero prenas nur du liniojn de kodo), bazaj bildoj povas aldoni centojn da megabajtoj da plia ŝarĝo al via ujo. Ekzemple, simpla node.js dosiero por Go "hello-world" aplikaĵo estas proksimume 700 megabajtoj, dum via reala aplikaĵo estas nur kelkaj megabajtoj.
Do ĉi tiu ekstra laborŝarĝo estas malŝparo de cifereca spaco kaj bonega kaŝejo por sekurecaj vundeblecoj kaj cimoj. Do ni rigardu du manierojn redukti la grandecon de uja bildo.
La unua estas la uzo de malgrandaj bazaj bildoj, la dua estas la uzo de la Konstruisto-Ŝablono. Uzi pli malgrandajn bazajn bildojn verŝajne estas la plej facila maniero redukti la grandecon de via ujo. Plej verŝajne, la lingvo aŭ stako, kiun vi uzas, provizas originalan aplikaĵon, kiu estas multe pli malgranda ol la defaŭlta bildo. Ni rigardu nian ujon node.js.
Defaŭlte en Docker, la nodo:8 baza bildo grandeco estas 670 MB, kaj la nodo: 8-alpa bildo grandeco estas nur 65 MB, tio estas, 10 fojojn pli malgranda. Uzante la pli malgrandan Alpan bazan bildon, vi signife reduktos la grandecon de via ujo. Alpine estas malgranda kaj malpeza Linukso-distribuo, kiu estas tre populara inter Docker-uzantoj ĉar ĝi estas kongrua kun multaj aplikoj konservante ujojn malgrandaj. Male al la norma "nodo"-bildo de Docker, "node:alpine" forigas multajn servajn dosierojn kaj programojn, lasante nur tiujn, kiuj sufiĉas por ruli vian aplikaĵon.
Por moviĝi al pli malgranda baza bildo, simple ĝisdatigu la Dockerfile por komenci labori kun la nova baza bildo:
Nun, male al la malnova onbuild-bildo, vi devas kopii vian kodon en la ujon kaj instali ajnajn dependecojn. En nova Dockerfile, la ujo komenciĝas per nodo:alpa bildo, poste kreas dosierujon por la kodo, instalas dependencojn uzante la pakaĵmanaĝeron de NPM, kaj fine rulas server.js.
Ĉi tiu ĝisdatigo rezultas en ujon kiu estas 10 fojojn pli malgranda en grandeco. Se via programlingvo aŭ stako ne havas bazan bildreduktan funkcion, uzu Alpine Linukso. Ĝi ankaŭ provizos la kapablon plene administri la enhavon de la ujo. Uzi malgrandajn bazajn bildojn estas bonega maniero por rapide krei malgrandajn ujojn. Sed eĉ pli granda redukto povas esti atingita uzante la Builder Pattern.
En interpretitaj lingvoj, la fontkodo unue estas transdonita al la interpretisto kaj poste rekte efektivigita. En kompilitaj lingvoj, la fontkodo unue estas konvertita en kompilitan kodon. Tamen, kompilo ofte uzas ilojn kiuj ne estas fakte bezonataj por ruli la kodon. Ĉi tio signifas, ke vi povas tute forigi ĉi tiujn ilojn el la fina ujo. Vi povas uzi Builder Pattern por ĉi tio.
La kodo estas kreita en la unua ujo kaj kompilita. La kompilita kodo tiam estas enpakita en finan ujon sen la kompililoj kaj iloj necesaj por kompili tiun kodon. Ni rulu Go-aplikaĵon tra ĉi tiu procezo. Unue, ni translokiĝos de la onbuild-bildo al Alpine Linukso.
En la nova Dockerfile, la ujo komenciĝas per golang:alpa bildo. Ĝi tiam kreas dosierujon por la kodo, kopias ĝin en la fontkodon, konstruas tiun fontkodon kaj rulas la aplikaĵon. Ĉi tiu ujo estas multe pli malgranda ol la onbuild-ujo, sed ĝi ankoraŭ enhavas la kompililon kaj aliajn Go-iloj, kiujn ni ne vere bezonas. Do ni simple eltiru la kompilitan programon kaj metu ĝin en sian propran ujon.
Vi eble rimarkos ion strangan en ĉi tiu Docker-dosiero: ĝi enhavas du FROM-liniojn. La unua 4-linia sekcio aspektas ekzakte same kiel la antaŭa Dockerfile krom ke ĝi uzas la ŝlosilvorton AS por nomi ĉi tiun etapon. La sekva sekcio havas novan FROM-linion por komenci novan bildon, kie anstataŭ la golang:alpine bildo ni uzos Raw alpine kiel la baza bildo.
Raw Alpine Linux ne havas iujn ajn SSL-atestilojn instalitajn, kio kaŭzos malsukceson de la plej multaj API-vokoj per HTTPS, do ni instalu iujn radikajn CA-atestilojn.
Nun venas la amuza parto: por kopii la kompilitan kodon de la unua ujo al la dua, vi povas simple uzi la komandon COPY situantan sur la linio 5 de la dua sekcio. Ĝi nur kopios unu aplikaĵdosieron kaj ne influos Go-utilajn ilojn. La nova plurstadia Docker-dosiero enhavos ujan bildon, kiu havas nur 12 megabajtojn, kompare kun la originala ujbildo, kiu estis 700 megabajtoj, kio estas granda diferenco!
Do uzi malgrandajn bazajn bildojn kaj Builder Pattern estas bonegaj manieroj krei multe pli malgrandajn ujojn sen multe da laboro.
Eblas ke depende de la aplika stako, ekzistas pliaj manieroj redukti bildon kaj ujgrandecon, sed ĉu malgrandaj ujoj vere havas mezureblan avantaĝon? Ni rigardu du areojn kie malgrandaj ujoj estas ekstreme efikaj - rendimento kaj sekureco.
Por taksi la pliiĝon de rendimento, konsideru la daŭron de la procezo krei ujon, enmeti ĝin en la registron (puŝo), kaj poste preni ĝin de tie (tiri). Vi povas vidi, ke pli malgranda ujo havas klaran avantaĝon super pli granda ujo.
Docker konservos la tavolojn do postaj konstruoj estos tre rapidaj. Tamen, multaj CI-sistemoj uzataj por konstrui kaj testi ujojn ne konservas tavolojn, do estas gravaj tempoŝparoj. Kiel vi povas vidi, la tempo por konstrui grandan ujon, depende de la potenco de via maŝino, estas de 34 ĝis 54 sekundoj, kaj kiam vi uzas ujon reduktita per la Builder Pattern - de 23 ĝis 28 sekundoj. Por operacioj de ĉi tiu speco, la pliiĝo de produktiveco estos 40-50%. Do nur pensu kiom da fojoj vi konstruas kaj testas vian kodon.
Post kiam la ujo estas konstruita, vi devas puŝi ĝian bildon (puŝu ujon-bildon) en la ujan registron por ke vi tiam povu uzi ĝin en via Kubernetes-grupo. Mi rekomendas uzi Google Container Registry.
Kun Google Container Registry (GCR), vi nur pagas por kruda stokado kaj interkonektado, kaj ne estas pliaj ujadministradkotizoj. Ĝi estas privata, sekura kaj tre rapida. GCR uzas multajn lertaĵojn por akceli la tiran operacion. Kiel vi povas vidi, enmeti ujon de Docker Container Image per go:onbuild daŭros de 15 ĝis 48 sekundoj, depende de la komputila rendimento, kaj la sama operacio kun pli malgranda ujo daŭros de 14 ĝis 16 sekundoj, kaj por malpli produktivaj maŝinoj. la avantaĝo en operacio rapideco pliiĝas je 3 fojojn. Por pli grandaj maŝinoj, la tempo estas proksimume la sama, ĉar GCR uzas tutmondan kaŝmemoron por komuna datumbazo de bildoj, tio signifas, ke vi tute ne bezonas ŝargi ilin. En malalta potenco komputilo, la CPU estas la botelkolo, do la avantaĝo uzi malgrandajn ujojn estas multe pli granda ĉi tie.
Se vi uzas GCR, mi tre rekomendas uzi Google Container Builder (GCB) kiel parto de via konstrusistemo.
Kiel vi povas vidi, ĝia uzo permesas al vi atingi multe pli bonajn rezultojn reduktante la daŭron de la operacio Build+Push ol eĉ produktiva maŝino - en ĉi tiu kazo, la procezo de konstruado kaj sendo de ujoj al la gastiganto akceliĝas preskaŭ 2 fojojn. . Krome, vi ricevas 120 senpagajn konstruminutojn ĉiutage, kiuj kovras viajn ujajn konstruajn bezonojn en la plej multaj kazoj.
Poste venas la plej grava agado-metriko - la rapideco de reakiro, aŭ elŝuto, Tiru ujojn. Kaj se vi ne multe zorgas pri la tempo elspezita en puŝo-operacio, tiam la longeco de la tira procezo havas gravan efikon sur la entuta sistema rendimento. Ni diru, ke vi havas areton de tri nodoj kaj unu el ili malsukcesas. Se vi uzas administran sistemon kiel Google Kubernetes Engine, ĝi aŭtomate anstataŭigos la mortintan nodon per nova. Tamen, ĉi tiu nova nodo estos tute malplena kaj vi devos treni ĉiujn viajn ujojn en ĝin por ke ĝi ekfunkciu. Se la tira operacio daŭras sufiĉe longe, via areto funkcios kun pli malalta rendimento la tutan tempon.
Estas multaj kazoj, kie tio povas okazi: aldoni novan nodon al areto, ĝisdatigi nodojn aŭ eĉ ŝanĝi al nova ujo por deplojo. Tiel, minimumigi tiran eltiran tempon iĝas ŝlosila faktoro. Estas nekontesteble, ke malgranda ujo elŝutas multe pli rapide ol granda. Se vi funkcias plurajn ujojn en Kubernetes-areo, la tempoŝparo povas esti signifa.
Rigardu ĉi tiun komparon: tira operacio sur malgrandaj ujoj prenas 4-9 fojojn malpli da tempo, depende de la potenco de la maŝino, ol la sama operacio per go:onbuild. Uzado de komunaj, malgrandaj ujbazbildoj signife plirapidigas la tempon kaj rapidecon, je kiuj novaj Kubernetes-nodoj povas esti deplojitaj kaj enretiĝi.
Ni rigardu la aferon de sekureco. Pli malgrandaj ujoj estas konsideritaj multe pli sekuraj ol pli grandaj ĉar ili havas pli malgrandan ataksurfacon. Ĉu vere? Unu el la plej utilaj funkcioj de Google Container Registry estas la kapablo aŭtomate skani viajn ujojn por vundeblecoj. Antaŭ kelkaj monatoj mi kreis ambaŭ surkonstruajn kaj plurstaĝajn ujojn, do ni vidu ĉu ekzistas vundeblecoj tie.
La rezulto estas mirinda: nur 3 mezaj vundeblecoj estis detektitaj en malgranda ujo, kaj 16 kritikaj kaj 376 aliaj vundeblecoj estis trovitaj en granda ujo. Se ni rigardas la enhavon de granda ujo, ni povas vidi, ke la plej multaj el la sekurecaj problemoj havas nenion komunan kun nia aplikaĵo, sed rilatas al programoj, kiujn ni eĉ ne uzas. Do kiam homoj parolas pri granda ataksurfaco, tion ili celas.
La preskribo estas klara: konstruu malgrandajn ujojn ĉar ili provizas realan rendimenton kaj sekurecajn avantaĝojn al via sistemo.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com