Kubernetes-en inplementatzeko lehen urratsa zure aplikazioa edukiontzi batean jartzea da. Serie honetan, edukiontzien irudi txiki eta segurua nola sor dezakezun ikusiko dugu.
Dockerri esker, edukiontzien irudiak sortzea ez da inoiz erraza izan. Zehaztu oinarrizko irudi bat, gehitu zure aldaketak eta sortu edukiontzi bat.
Teknika hau hasteko bikaina den arren, oinarrizko irudi lehenetsiak erabiltzeak lan segurua ekar dezake ahuleziaz betetako irudi handiekin.
Gainera, Docker-eko irudi gehienek Debian edo Ubuntu erabiltzen dute oinarrizko irudirako, eta honek bateragarritasun bikaina eta pertsonalizazio erraza eskaintzen badu ere (Docker fitxategi batek bi kode-lerro baino ez ditu hartzen), oinarrizko irudiek ehunka megabyte gehi ditzakete zure edukiontziari. Adibidez, Go "hello-world" aplikazio baterako node.js fitxategi soil batek 700 megabyte ingurukoa da, eta zure benetako aplikazioak megabyte batzuk baino ez ditu.
Beraz, aparteko lan-karga hori guztia espazio digitala xahutzea da eta segurtasun ahultasun eta akatsen ezkutaleku bikaina da. Beraz, ikus ditzagun edukiontzi-irudi baten tamaina murrizteko bi modu.
Lehenengoa oinarrizko irudi txikien erabilera da, bigarrena Builder Pattern erabiltzea. Oinarrizko irudi txikiagoak erabiltzea da seguruenik zure edukiontziaren tamaina murrizteko modurik errazena. Seguruenik, erabiltzen ari zaren hizkuntzak edo pilak jatorrizko aplikazioaren irudia eskaintzen du, lehenetsitako irudia baino askoz txikiagoa dena. Ikus dezagun gure node.js edukiontziari.
Docker-en lehenespenez, nodo:8 oinarrizko irudiaren tamaina 670 MB da, eta nodoa: 8-alpine irudiaren tamaina 65 MB baino ez da, hau da, 10 aldiz txikiagoa. Oinarrizko irudi txikiagoa erabiliz, zure edukiontziaren tamaina nabarmen murriztuko duzu. Alpine Linux banaketa txiki eta arina da, Docker erabiltzaileen artean oso ezaguna dena, aplikazio askorekin bateragarria delako edukiontziak txikiak mantentzen dituen bitartean. Docker "nodo" irudi estandarrak ez bezala, "node:alpine" zerbitzu-fitxategi eta programa asko kentzen ditu, zure aplikazioa exekutatzeko nahikoak direnak bakarrik utziz.
Oinarrizko irudi txikiago batera joateko, besterik gabe eguneratu Dockerfile oinarrizko irudi berriarekin lanean hasteko:
Orain, onbuild irudi zaharra ez bezala, zure kodea edukiontzian kopiatu eta edozein mendekotasun instalatu behar duzu. Dockerfile berri batean, edukiontzia nodo:alpino irudi batekin hasten da, ondoren kodearen direktorio bat sortzen du, mendekotasunak instalatzen ditu NPM pakete-kudeatzailea erabiliz eta, azkenik, server.js exekutatzen du.
Bertsio honek tamaina 10 aldiz txikiagoa den edukiontzi bat lortzen du. Zure programazio-lengoaia edo pilak ez badu oinarrizko irudiak murrizteko funtzionaltasunik, erabili Alpine Linux. Edukiontziaren edukia guztiz kudeatzeko gaitasuna ere emango du. Oinarrizko irudi txikiak erabiltzea ontzi txikiak azkar sortzeko modu bikaina da. Baina are murrizketa handiagoa lor daiteke Builder Pattern erabiliz.
Interpretatutako hizkuntzetan, iturburu-kodea lehenik interpreteari pasatzen zaio eta, ondoren, zuzenean exekutatzen da. Konpilatutako lengoaietan, iturburu-kodea lehenik konpilatutako kode bihurtzen da. Hala ere, konpilazioak askotan kodea exekutatzeko beharrezkoak ez diren tresnak erabiltzen ditu. Horrek esan nahi du tresna hauek erabat kendu ditzakezula azken edukiontzitik. Eraikitzaile eredua erabil dezakezu horretarako.
Kodea lehenengo edukiontzian sortu eta konpilatzen da. Ondoren, konpilatutako kodea azken edukiontzi batean sartzen da kode hori konpilatzeko behar diren konpilatzaile eta tresnarik gabe. Exekutatu dezagun Go aplikazio bat prozesu honen bidez. Lehenik eta behin, onbuild iruditik Alpine Linuxera pasatuko gara.
Dockerfile berrian, edukiontzia golang:alpine irudi batekin hasten da. Ondoren, kodearen direktorio bat sortzen du, iturburu-kodean kopiatzen du, iturburu-kode hori eraikitzen du eta aplikazioa exekutatzen du. Edukiontzi hau onbuild edukiontzia baino askoz txikiagoa da, baina oraindik behar ez ditugun konpilatzailea eta beste Go tresna batzuk ditu. Beraz, atera dezagun konpilatutako programa eta jar dezagun bere edukiontzian.
Docker fitxategi honetan zerbait arraroa nabarituko duzu: bi FROM lerro ditu. Lehen 4 lerroko atalak aurreko Dockerfilearen itxura berdina du, etapa hau izendatzeko AS gako-hitza erabiltzen duela izan ezik. Hurrengo atalean FROM lerro berri bat dauka irudi berri bat hasteko, non golang:alpine irudiaren ordez Raw alpine erabiliko dugun oinarrizko irudi gisa.
Raw Alpine Linux-ek ez du SSL ziurtagiririk instalatuta, eta horrek HTTPS bidezko API dei gehienek huts egingo dute, beraz, instala ditzagun root CA ziurtagiri batzuk.
Orain zati dibertigarria dator: konpilatutako kodea lehen edukiontzitik bigarrenera kopiatzeko, bigarren ataleko 5. lerroan dagoen COPY komandoa besterik ez duzu erabili. Aplikazio-fitxategi bakarra kopiatuko du eta ez die eragingo Go utilitate-tresnetan. Etapa anitzeko Docker fitxategi berriak 12 megabyte baino ez dituen edukiontzi-irudia edukiko du, 700 megabyte-ko jatorrizko edukiontziaren irudiarekin alderatuta, eta hori alde handia da!
Beraz, oinarrizko irudi txikiak eta Builder Pattern erabiltzea modu bikainak dira edukiontzi askoz txikiagoak sortzeko lan askorik gabe.
Baliteke aplikazio-pilaren arabera irudia eta edukiontziaren tamaina murrizteko beste modu batzuk egotea, baina edukiontzi txikiek benetan onura neurgarria dute? Ikus ditzagun edukiontzi txikiak oso eraginkorrak diren bi eremu: errendimendua eta segurtasuna.
Errendimenduaren igoera ebaluatzeko, kontuan hartu edukiontzi bat sortzeko prozesuaren iraupena, erregistroan txertatzeko (push) eta, ondoren, handik berreskuratzeko (pull). Ikusten duzu ontzi txikiago batek abantaila nabarmena duela edukiontzi handiago baten aldean.
Docker-ek geruzak gordeko ditu, beraz, ondorengo eraikuntzak oso azkarrak izango dira. Hala ere, edukiontziak eraikitzeko eta probatzeko erabiltzen diren CI sistema askok ez dituzte geruzak gordetzen, beraz, denbora aurrezteko nabarmena da. Ikus dezakezunez, edukiontzi handi bat eraikitzeko denbora, zure makinaren potentziaren arabera, 34 eta 54 segundo bitartekoa da, eta Builder Pattern erabiliz murriztutako edukiontzi bat erabiltzen denean - 23 eta 28 segundo. Mota honetako eragiketetarako, produktibitatearen igoera %40-50ekoa izango da. Beraz, pentsatu zenbat aldiz eraiki eta probatu zure kodea.
Edukiontzia eraiki ondoren, bere irudia (push edukiontziaren irudia) edukiontzien erregistroan sartu behar duzu, gero zure Kubernetes klusterrean erabili ahal izateko. Google Container Registry erabiltzea gomendatzen dut.
Google Container Registry-rekin (GCR), biltegiratze gordina eta sarean ordaintzen dituzu soilik, eta ez dago edukiontzien kudeaketa kuota gehigarririk. Pribatua, segurua eta oso azkarra da. GCR-k trikimailu asko erabiltzen ditu tira eragiketa bizkortzeko. Ikus dezakezunez, go:onbuild erabiliz Docker Container Image edukiontzi bat txertatzeak 15 eta 48 segundo bitartekoa izango du, ordenagailuaren errendimenduaren arabera, eta edukiontzi txikiago batekin eragiketa bera 14 eta 16 segundo bitartekoa izango da, eta ekoizpen gutxiagoko makinetan. funtzionamendu-abiaduran abantaila 3 aldiz handitzen da. Makina handiagoetarako, denbora gutxi gorabehera berdina da, GCR-k cache global bat erabiltzen baitu irudien datu-base partekatu baterako, hau da, ez dituzu batere kargatu beharrik. Potentzia gutxiko ordenagailu batean, CPUa da botila-lepoa, beraz, ontzi txikiak erabiltzearen abantaila askoz handiagoa da hemen.
GCR erabiltzen ari bazara, gomendatzen dut Google Container Builder (GCB) erabiltzea zure eraikuntza-sistemaren parte gisa.
Ikus dezakezun bezala, bere erabilerak emaitza askoz hobeak lortzeko aukera ematen du Eraiki+Push eragiketaren iraupena murrizteko makina produktibo batek baino - kasu honetan, edukiontziak ostalarira eraikitzeko eta bidaltzeko prozesua ia 2 aldiz bizkortzen da. . Gainera, 120 doako eraikitzeko minutu lortzen dituzu egunero, eta horrek zure edukiontzien eraikuntza-beharrak estaltzen ditu kasu gehienetan.
Ondoren, errendimendu-neurririk garrantzitsuena dator: Pull edukiontziak berreskuratzeko edo deskargatzeko abiadura. Eta push eragiketa batean emandako denborari buruz asko axola ez bazaizu, tira-prozesuaren iraupenak eragin handia du sistemaren errendimendu orokorrean. Demagun hiru nodoko multzo bat duzula eta horietako batek huts egiten duela. Kubernetes Engine bezalako kudeaketa sistema bat erabiltzen ari bazara, automatikoki ordezkatuko du hildako nodoa berri batekin. Hala ere, nodo berri hau guztiz hutsik egongo da eta zure ontzi guztiak arrastatu beharko dituzu bertara funtzionatzen hasteko. Tiraketa eragiketak nahikoa luzea hartzen badu, zure klusterrak errendimendu baxuagoan funtzionatuko du denbora osoan.
Hori gerta daitekeen kasu asko daude: kluster bati nodo berri bat gehitzea, nodoak berritzea edo edukiontzi berri batera aldatzea ere zabaltzeko. Beraz, tira-erauzketa denbora gutxitzea funtsezko faktore bihurtzen da. Ukaezina da edukiontzi txiki batek handi batek baino askoz azkarrago deskargatzen duela. Kubernetes kluster batean hainbat edukiontzi exekutatzen ari bazara, denbora aurreztea garrantzitsua izan daiteke.
Begiratu konparazio honi: ontzi txikietan tiratzeko eragiketa batek 4-9 aldiz denbora gutxiago behar du, makinaren potentziaren arabera, go:onbuild erabiliz eragiketa bera baino. Partekatutako edukiontzi txikien oinarriko irudiak erabiltzeak nabarmen bizkortzen ditu Kubernetes nodo berriak inplementatzeko eta sarean jartzeko denbora eta abiadura.
Ikus dezagun segurtasunaren gaia. Edukiontzi txikiagoak handiagoak baino askoz seguruagotzat jotzen dira, eraso-azalera txikiagoa dutelako. Benetan al da? Google Container Registry-ren ezaugarririk erabilgarrienetako bat zure edukiontziak automatikoki eskaneatzeko gaitasuna da ahultasunen bila. Duela hilabete batzuk onbuild eta etapa anitzeko edukiontziak sortu nituen, ea ahultasunik dagoen.
Emaitza harrigarria da: edukiontzi txiki batean 3 ahultasun ertain baino ez dira detektatu, eta edukiontzi handi batean 16 ahultasun kritiko eta beste 376 aurkitu dira. Edukiontzi handi baten edukiari erreparatzen badiogu, ikus dezakegu segurtasun arazo gehienek ez dutela zerikusirik gure aplikazioarekin, baizik eta erabiltzen ez ditugun programekin lotuta daudela. Beraz, jendeak eraso azalera handi bati buruz hitz egiten duenean, horixe esan nahi du.
Eramatea argia da: eraiki edukiontzi txikiak zure sistemari benetako errendimendu eta segurtasun onurak ematen dizkiolako.
Iragarki batzuk π
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com