Ang unang hakbang ng pag-deploy sa Kubernetes ay ang paglalagay ng iyong application sa isang container. Sa seryeng ito, titingnan natin kung paano ka makakagawa ng maliit, secure na larawan ng lalagyan.
Salamat sa Docker, ang paggawa ng mga imahe ng lalagyan ay hindi naging mas madali. Tumukoy ng batayang larawan, idagdag ang iyong mga pagbabago, at gumawa ng container.
Bagama't mahusay ang diskarteng ito para sa pagsisimula, ang paggamit ng mga default na batayang larawan ay maaaring humantong sa hindi ligtas na trabaho na may malalaking larawang puno ng mga kahinaan.
Bukod pa rito, karamihan sa mga larawan sa Docker ay gumagamit ng Debian o Ubuntu para sa base na imahe, at habang nagbibigay ito ng mahusay na compatibility at madaling pag-customize (ang Docker file ay tumatagal lamang ng dalawang linya ng code), ang mga base na imahe ay maaaring magdagdag ng daan-daang megabytes ng karagdagang pag-load sa iyong lalagyan. Halimbawa, ang isang simpleng node.js file para sa isang Go "hello-world" na application ay humigit-kumulang 700 megabytes, habang ang iyong aktwal na application ay ilang megabytes lamang ang laki.
Kaya lahat ng dagdag na workload na ito ay isang pag-aaksaya ng digital space at isang magandang lugar ng pagtatago para sa mga kahinaan sa seguridad at mga bug. Kaya tingnan natin ang dalawang paraan upang bawasan ang laki ng imahe ng lalagyan.
Ang una ay ang paggamit ng maliliit na batayang imahe, ang pangalawa ay ang paggamit ng Pattern ng Tagabuo. Ang paggamit ng mas maliliit na batayang larawan ay marahil ang pinakamadaling paraan upang bawasan ang laki ng iyong lalagyan. Malamang, ang wika o stack na iyong ginagamit ay nagbibigay ng orihinal na larawan ng application na mas maliit kaysa sa default na larawan. Tingnan natin ang aming lalagyan ng node.js.
Bilang default sa Docker, ang node:8 base na laki ng imahe ay 670 MB, at ang node: 8-alpine na laki ng imahe ay 65 MB lamang, ibig sabihin, 10 beses na mas maliit. Sa pamamagitan ng paggamit ng mas maliit na Alpine base na imahe, makabuluhang bawasan mo ang laki ng iyong lalagyan. Ang Alpine ay isang maliit at magaan na pamamahagi ng Linux na napakasikat sa mga gumagamit ng Docker dahil tugma ito sa maraming application habang pinananatiling maliit ang mga container. Hindi tulad ng karaniwang imahe ng "node" ng Docker, ang "node:alpine" ay nag-aalis ng maraming mga file ng serbisyo at mga programa, na iniiwan lamang ang mga sapat upang patakbuhin ang iyong aplikasyon.
Upang lumipat sa isang mas maliit na base na imahe, i-update lamang ang Dockerfile upang magsimulang magtrabaho kasama ang bagong base na imahe:
Ngayon, hindi tulad ng lumang onbuild na imahe, kailangan mong kopyahin ang iyong code sa lalagyan at mag-install ng anumang mga dependency. Sa isang bagong Dockerfile, nagsisimula ang container sa isang node:alpine na imahe, pagkatapos ay gumagawa ng direktoryo para sa code, nag-i-install ng mga dependency gamit ang manager ng package ng NPM, at sa wakas ay nagpapatakbo ng server.js.
Ang pag-upgrade na ito ay nagreresulta sa isang lalagyan na 10 beses na mas maliit ang laki. Kung ang iyong programming language o stack ay walang base image reduction functionality, gamitin ang Alpine Linux. Magbibigay din ito ng kakayahang ganap na pamahalaan ang mga nilalaman ng lalagyan. Ang paggamit ng maliliit na batayang larawan ay isang mahusay na paraan upang mabilis na gumawa ng maliliit na lalagyan. Ngunit kahit na mas malaking pagbawas ay maaaring makamit gamit ang Builder Pattern.
Sa mga na-interpret na wika, ang source code ay unang ipinapasa sa interpreter at pagkatapos ay direktang ipapatupad. Sa mga pinagsama-samang wika, ang source code ay unang na-convert sa pinagsama-samang code. Gayunpaman, ang compilation ay madalas na gumagamit ng mga tool na hindi talaga kailangan para patakbuhin ang code. Nangangahulugan ito na maaari mong ganap na alisin ang mga tool na ito mula sa huling lalagyan. Maaari mong gamitin ang Builder Pattern para dito.
Ang code ay nilikha sa unang lalagyan at pinagsama-sama. Ang pinagsama-samang code ay pagkatapos ay naka-package sa isang pangwakas na lalagyan nang walang mga compiler at tool na kailangan upang i-compile ang code na iyon. Magpatakbo tayo ng Go application sa pamamagitan ng prosesong ito. Una, lilipat tayo mula sa onbuild na imahe patungo sa Alpine Linux.
Sa bagong Dockerfile, nagsisimula ang container sa isang golang:alpine na imahe. Pagkatapos ay gagawa ito ng direktoryo para sa code, kinokopya ito sa source code, bubuo ng source code na iyon, at pinapatakbo ang application. Ang container na ito ay mas maliit kaysa sa onbuild na container, ngunit naglalaman pa rin ito ng compiler at iba pang Go tool na hindi namin talaga kailangan. Kaya't i-extract na lang natin ang pinagsama-samang programa at ilagay ito sa sarili nitong lalagyan.
Maaaring may mapansin kang kakaiba sa Docker file na ito: naglalaman ito ng dalawang FROM lines. Ang unang 4 na seksyon ng linya ay mukhang eksaktong kapareho ng nakaraang Dockerfile maliban na ginagamit nito ang AS na keyword upang pangalanan ang yugtong ito. Ang susunod na seksyon ay may bagong FROM na linya upang magsimula ng bagong larawan, kung saan sa halip na golang:alpine na imahe ay gagamitin namin ang Raw alpine bilang batayang larawan.
Walang naka-install na SSL certificate ang Raw Alpine Linux, na magiging sanhi ng pagkabigo ng karamihan sa mga tawag sa API sa HTTPS, kaya mag-install tayo ng ilang root CA certificate.
Dumating na ngayon ang nakakatuwang bahagi: upang kopyahin ang pinagsama-samang code mula sa unang lalagyan hanggang sa pangalawa, maaari mo lamang gamitin ang COPY command na matatagpuan sa linya 5 ng pangalawang seksyon. Kokopya lang ito ng isang application file at hindi makakaapekto sa mga tool ng Go utility. Maglalaman ang bagong multi-stage na Docker file ng container image na 12 megabytes lang ang laki, kumpara sa orihinal na container na image na 700 megabytes, na isang malaking pagkakaiba!
Kaya't ang paggamit ng maliliit na batayang larawan at Pattern ng Tagabuo ay mahusay na paraan upang lumikha ng mas maliliit na lalagyan nang walang gaanong trabaho.
Posible na depende sa stack ng application, may mga karagdagang paraan upang bawasan ang laki ng larawan at lalagyan, ngunit mayroon ba talagang masusukat na benepisyo ang maliliit na lalagyan? Tingnan natin ang dalawang lugar kung saan napakabisa ang maliliit na lalagyan - pagganap at seguridad.
Upang suriin ang pagtaas ng pagganap, isaalang-alang ang tagal ng proseso ng paglikha ng isang lalagyan, pagpasok nito sa registry (push), at pagkatapos ay kunin ito mula doon (pull). Maaari mong makita na ang isang mas maliit na lalagyan ay may natatanging kalamangan kaysa sa isang mas malaking lalagyan.
I-cache ng Docker ang mga layer upang ang mga susunod na build ay magiging napakabilis. Gayunpaman, maraming mga CI system na ginagamit upang bumuo at sumubok ng mga container ay hindi nag-cache ng mga layer, kaya may makabuluhang pagtitipid sa oras. Tulad ng nakikita mo, ang oras upang bumuo ng isang malaking lalagyan, depende sa kapangyarihan ng iyong makina, ay mula 34 hanggang 54 segundo, at kapag gumagamit ng lalagyan ay binawasan gamit ang Pattern ng Tagabuo - mula 23 hanggang 28 segundo. Para sa mga operasyon ng ganitong uri, ang pagtaas ng produktibo ay magiging 40-50%. Kaya isipin lang kung gaano karaming beses kang bumuo at subukan ang iyong code.
Pagkatapos mabuo ang container, kailangan mong itulak ang larawan nito (push container image) sa registry ng container para magamit mo ito sa iyong Kubernetes cluster. Inirerekomenda ko ang paggamit ng Google Container Registry.
Sa Google Container Registry (GCR), magbabayad ka lang para sa raw storage at networking, at walang karagdagang bayad sa pamamahala ng container. Ito ay pribado, ligtas at napakabilis. Gumagamit ang GCR ng maraming trick para mapabilis ang pagpapatakbo ng pull. Gaya ng nakikita mo, ang paglalagay ng isang Docker Container Image container gamit ang go:onbuild ay aabutin ng 15 hanggang 48 segundo, depende sa performance ng computer, at ang parehong operasyon na may mas maliit na container ay aabutin mula 14 hanggang 16 na segundo, at para sa hindi gaanong produktibong makina. ang kalamangan sa bilis ng operasyon ay tumataas ng 3 beses. Para sa mas malalaking makina, ang oras ay halos pareho, dahil ang GCR ay gumagamit ng isang pandaigdigang cache para sa isang nakabahaging database ng mga larawan, ibig sabihin, hindi mo na kailangang i-load ang mga ito. Sa isang mababang-power na computer, ang CPU ang bottleneck, kaya ang bentahe ng paggamit ng maliliit na lalagyan ay mas malaki dito.
Kung gumagamit ka ng GCR, lubos kong inirerekomenda ang paggamit ng Google Container Builder (GCB) bilang bahagi ng iyong build system.
Tulad ng nakikita mo, ang paggamit nito ay nagbibigay-daan sa iyo upang makamit ang mas mahusay na mga resulta sa pagbawas ng tagal ng Build+Push operation kaysa sa isang produktibong makina - sa kasong ito, ang proseso ng pagbuo at pagpapadala ng mga lalagyan sa host ay pinabilis ng halos 2 beses . Dagdag pa rito, nakakakuha ka ng 120 libreng build minuto araw-araw, na sumasaklaw sa iyong mga pangangailangan sa paggawa ng container sa karamihan ng mga kaso.
Susunod ang pinakamahalagang sukatan ng pagganap β ang bilis ng pagkuha, o pag-download, ng mga Pull container. At kung hindi mo masyadong pinapahalagahan ang oras na ginugol sa isang push operation, kung gayon ang haba ng proseso ng paghila ay may malubhang epekto sa pangkalahatang pagganap ng system. Sabihin nating mayroon kang isang kumpol ng tatlong node at nabigo ang isa sa mga ito. Kung gumagamit ka ng sistema ng pamamahala tulad ng Google Kubernetes Engine, awtomatiko nitong papalitan ang patay na node ng bago. Gayunpaman, ang bagong node na ito ay magiging ganap na walang laman at kakailanganin mong i-drag ang lahat ng iyong mga lalagyan dito para magsimula itong gumana. Kung magtatagal ang pull operation, tatakbo ang iyong cluster sa mas mababang performance sa buong panahon.
Maraming mga kaso kung saan maaaring mangyari ito: pagdaragdag ng bagong node sa isang cluster, pag-upgrade ng mga node, o kahit na paglipat sa isang bagong container para sa pag-deploy. Kaya, ang pagliit ng oras ng pagkuha ng pull ay nagiging isang pangunahing kadahilanan. Hindi maikakaila na ang isang maliit na lalagyan ay nagda-download nang mas mabilis kaysa sa isang malaki. Kung nagpapatakbo ka ng maraming container sa isang Kubernetes cluster, maaaring malaki ang pagtitipid sa oras.
Tingnan ang paghahambing na ito: ang pull operation sa maliliit na container ay tumatagal ng 4-9 beses na mas kaunting oras, depende sa kapangyarihan ng makina, kaysa sa parehong operasyon gamit ang go:onbuild. Ang paggamit ng nakabahaging, maliliit na container base na mga imahe ay makabuluhang nagpapabilis sa oras at bilis kung saan maaaring i-deploy at mag-online ang mga bagong Kubernetes node.
Tingnan natin ang isyu ng seguridad. Ang mas maliliit na lalagyan ay itinuturing na mas ligtas kaysa sa mas malalaking lalagyan dahil mas maliit ang mga ito sa attack surface. Talaga ba? Isa sa mga pinakakapaki-pakinabang na feature ng Google Container Registry ay ang kakayahang awtomatikong i-scan ang iyong mga container para sa mga kahinaan. Ilang buwan na ang nakalipas gumawa ako ng parehong onbuild at multistage na mga lalagyan, kaya tingnan natin kung mayroong anumang mga kahinaan doon.
Ang resulta ay kamangha-mangha: 3 katamtamang kahinaan lamang ang natukoy sa isang maliit na lalagyan, at 16 na kritikal at 376 iba pang mga kahinaan ang nakita sa isang malaking lalagyan. Kung titingnan namin ang mga nilalaman ng isang malaking lalagyan, makikita namin na ang karamihan sa mga problema sa seguridad ay walang kinalaman sa aming aplikasyon, ngunit nauugnay sa mga programa na hindi namin ginagamit. Kaya kapag pinag-uusapan ng mga tao ang tungkol sa malaking pag-atake, iyon ang ibig nilang sabihin.
Malinaw ang takeaway: gumawa ng maliliit na container dahil nagbibigay ang mga ito ng tunay na performance at mga benepisyo sa seguridad sa iyong system.
Ilang ad π
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com