Ang "Cloud native" o simpleng "cloud" na mga application ay partikular na nilikha upang gumana sa mga imprastraktura ng cloud. Karaniwang itinatayo ang mga ito bilang isang hanay ng mga maluwag na pinagsamang microservice na nakabalot sa mga lalagyan, na pinamamahalaan naman ng isang cloud platform. Ang mga naturang application ay inihanda para sa mga pagkabigo bilang default, na nangangahulugang gumagana ang mga ito nang maaasahan at sukat kahit na sa kaganapan ng mga malubhang pagkabigo sa antas ng imprastraktura. Ang kabilang panig ng barya ay ang mga hanay ng mga paghihigpit (mga kontrata) na ipinapataw ng cloud platform sa mga application ng container upang awtomatikong mapangasiwaan ang mga ito.
Bagama't lubos na nalalaman ang pangangailangan at kahalagahan ng paglipat sa mga cloud-based na application, maraming organisasyon ang hindi pa rin alam kung saan magsisimula. Sa post na ito, titingnan natin ang ilang mga prinsipyo na, kung susundin kapag bumubuo ng mga containerized na application, ay magbibigay-daan sa iyong mapagtanto ang potensyal ng mga cloud platform at makamit ang maaasahang operasyon at pag-scale ng mga application kahit na sa kaganapan ng mga malubhang pagkabigo sa IT infrastructure. antas. Ang pinakalayunin ng mga prinsipyong nakabalangkas dito ay upang matutunan kung paano bumuo ng mga application na maaaring awtomatikong pamahalaan ng mga cloud platform gaya ng Kubernetes.
Mga Prinsipyo sa Disenyo ng Software
Sa mundo ng programming, ang mga prinsipyo ay tumutukoy sa medyo pangkalahatang mga panuntunan na dapat sundin kapag bumubuo ng software. Magagamit ang mga ito kapag nagtatrabaho sa anumang programming language. Ang bawat prinsipyo ay may sariling mga layunin, ang mga tool para sa pagkamit na karaniwang mga template at kasanayan. Mayroon ding ilang pangunahing mga prinsipyo para sa paglikha ng mataas na kalidad na software, kung saan dumadaloy ang lahat ng iba pa. Narito ang ilang halimbawa ng mga pangunahing prinsipyo:
- (Panatilihin itong simple, hangal) - huwag gawing kumplikado;
- (Huwag ulitin ang iyong sarili) - huwag ulitin ang iyong sarili;
- (You aren't gonna need it) - huwag lumikha ng isang bagay na hindi agad kailangan;
- Paghihiwalay ng mga alalahanin - magbahagi ng mga responsibilidad.
Tulad ng nakikita mo, ang mga prinsipyong ito ay hindi nagtatakda ng anumang partikular na mga panuntunan, ngunit nabibilang sa kategorya ng tinatawag na mga pagsasaalang-alang sa sentido komun batay sa praktikal na karanasan, na ibinabahagi ng maraming mga developer at kung saan sila ay regular na tinutukoy.
Bilang karagdagan, mayroong β Isang set ng unang limang prinsipyo ng object-oriented na programming at disenyo, na binuo ni Robert Martin. Kasama sa SOLID ang malawak, bukas, komplementaryong mga prinsipyo naβkapag inilapat nang magkasamaβnakakatulong na lumikha ng mas mahuhusay na software system at mas mapanatili ang mga ito sa mahabang panahon.
Ang mga SOLID na prinsipyo ay nabibilang sa larangan ng OOP at binuo sa wika ng mga konsepto at konsepto tulad ng mga klase, interface at mana. Sa pamamagitan ng pagkakatulad, ang mga prinsipyo ng pag-unlad ay maaari ding bumalangkas para sa mga aplikasyon ng ulap, tanging ang pangunahing elemento dito ay hindi isang klase, ngunit isang lalagyan. Sa pamamagitan ng pagsunod sa mga prinsipyong ito, makakagawa ka ng mga containerized na application na mas nakakatugon sa mga layunin at layunin ng mga cloud platform tulad ng Kubernetes.
Mga lalagyan ng cloud-native: ang diskarte sa Red Hat
Sa ngayon, halos anumang aplikasyon ay madaling mai-package sa mga lalagyan. Ngunit para maging epektibong awtomatiko at ma-orkestra ang mga application sa loob ng cloud platform tulad ng Kubernetes, kailangan ng karagdagang pagsisikap.
Ang batayan para sa mga ideyang nakabalangkas sa ibaba ay ang pamamaraan at marami pang ibang gawa sa iba't ibang aspeto ng pagbuo ng mga web application, mula sa pamamahala ng source code hanggang sa mga modelo ng pag-scale. Nalalapat lang ang mga prinsipyong inilarawan sa pagbuo ng mga containerized na application na binuo sa ibabaw ng mga microservice at idinisenyo para sa mga cloud platform gaya ng Kubernetes. Ang pangunahing elemento sa aming talakayan ay ang imahe ng container, at ang target na runtime ng container ay ang container orchestration platform. Ang layunin ng mga iminungkahing prinsipyo ay lumikha ng mga lalagyan kung saan ang pag-iiskedyul, pag-scale, at pagsubaybay sa mga gawain ay maaaring awtomatiko sa karamihan ng mga platform ng orkestrasyon. Ang mga prinsipyo ay ipinakita sa walang partikular na pagkakasunud-sunod.
Single Concern Principle (SCP)
Ang prinsipyong ito ay sa maraming paraan katulad ng Single Responsibility Principle. ), na bahagi ng SOLID set at nagsasaad na ang bawat bagay ay dapat magkaroon ng isang responsibilidad, at ang responsibilidad na iyon ay dapat na ganap na nakapaloob sa isang klase. Ang punto ng SRP ay ang bawat responsibilidad ay isang dahilan para sa pagbabago, at ang isang klase ay dapat magkaroon ng isa at isa lamang na dahilan para sa pagbabago.
Sa SCP, ginagamit namin ang salitang "pag-aalala" sa halip na ang salitang "responsibilidad" upang ipahiwatig ang mas mataas na antas ng abstraction at mas malawak na layunin ng isang container kumpara sa isang klase ng OOP. At kung ang layunin ng SRP ay magkaroon lamang ng isang dahilan para sa pagbabago, sa likod ng SCP ay ang pagnanais na palawakin ang kakayahang muling gamitin at palitan ang mga lalagyan. Sa pamamagitan ng pagsunod sa SRP at paggawa ng container na lumulutas sa iisang problema at ginagawa ito sa isang kumpletong paraan, pinapataas mo ang mga pagkakataong muling gamitin ang larawan ng container na iyon sa iba't ibang konteksto ng application.
Ang prinsipyo ng SCP ay nagsasaad na ang bawat lalagyan ay dapat malutas ang isang solong problema at gawin ito nang maayos. Bukod dito, ang SCP sa mundo ng lalagyan ay mas madaling makamit kaysa sa SRP sa mundo ng OOP, dahil ang mga lalagyan ay karaniwang nagpapatakbo ng isang proseso, at kadalasan ang prosesong ito ay nalulutas ang isang gawain.
Kung kailangang lutasin ng ilang microservice ng container ang ilang problema nang sabay-sabay, maaari itong hatiin sa mga single-task na container at pagsamahin sa loob ng isang pod (isang unit ng container platform deployment) gamit ang sidecar at init na mga template ng container. Bilang karagdagan, ginagawang madali ng SCP na palitan ang isang lumang container (gaya ng isang web server o message broker) ng bago na lumulutas sa parehong problema ngunit mas pinalawak ang functionality o scale.
High Observability Principle (HOP)
Kapag ang mga lalagyan ay ginamit bilang isang pinag-isang paraan upang mag-package at magpatakbo ng mga application, ang mga application mismo ay itinuturing bilang isang black box. Gayunpaman, kung ito ay mga cloud container, dapat silang magbigay ng mga espesyal na API sa runtime upang masubaybayan ang kalusugan ng mga container at, kung kinakailangan, gumawa ng naaangkop na pagkilos. Kung wala ito, hindi posible na pag-isahin ang automation ng pag-update ng mga lalagyan at pamamahala ng kanilang ikot ng buhay, na, naman, ay magpapalala sa katatagan at kakayahang magamit ng software system.
Sa pagsasagawa, ang isang containerized na application ay dapat, sa pinakamababa, ay may API para sa iba't ibang uri ng mga pagsusuri sa kalusugan: mga pagsusuri sa liveness at mga pagsusuri sa kahandaan. Kung ang isang aplikasyon ay nag-aangkin na gumawa ng higit pa, dapat itong magbigay ng iba pang paraan ng pagsubaybay sa estado nito. Halimbawa, ang pag-log ng mahahalagang kaganapan sa pamamagitan ng STDERR at STDOUT para sa pagsasama-sama ng log gamit ang Fluentd, Logstash at iba pang katulad na mga tool. Pati na rin ang pagsasama sa pagsubaybay at mga aklatan ng koleksyon ng sukatan, gaya ng OpenTracing, Prometheus, atbp.
Sa pangkalahatan, maaari pa ring ituring ang application bilang isang black box, ngunit dapat itong ibigay kasama ng lahat ng API na kailangan ng platform upang masubaybayan at pamahalaan ito sa pinakamahusay na posibleng paraan.
Life-cycle Conformance Principle (LCP)
Ang LCP ay ang antithesis ng HOP. Habang sinasabi ng HOP na dapat ilantad ng container ang mga read API sa platform, hinihiling ng LCP na makatanggap ng impormasyon ang application mula sa platform. Bukod dito, ang lalagyan ay hindi lamang dapat makatanggap ng mga kaganapan, ngunit umangkop din, sa madaling salita, tumugon sa kanila. Kaya ang pangalan ng prinsipyo, na maaaring ituring bilang isang kinakailangan upang mabigyan ang platform ng mga API sa pagsusulat.
Ang mga platform ay may iba't ibang uri ng mga kaganapan upang makatulong na pamahalaan ang lifecycle ng isang container. Ngunit nasa aplikasyon mismo ang magpasya kung alin sa kanila ang mapapansin at kung paano magre-react.
Malinaw na ang ilang mga kaganapan ay mas mahalaga kaysa sa iba. Halimbawa, kung hindi pinahintulutan ng isang application ang pag-crash nang maayos, dapat itong tumanggap ng signal: wakasan (SIGTERM) na mga mensahe at simulan ang routine ng pagwawakas nito sa lalong madaling panahon upang makuha ang signal: patayin (SIGKILL) na darating pagkatapos ng SIGTERM.
Bilang karagdagan, ang mga kaganapan tulad ng PostStart at PreStop ay maaaring maging mahalaga sa lifecycle ng isang application. Halimbawa, pagkatapos maglunsad ng application, maaaring mangailangan ito ng ilang oras ng warm-up bago ito makatugon sa mga kahilingan. O ang application ay dapat maglabas ng mga mapagkukunan sa ilang espesyal na paraan kapag nagsasara.
Ang Image Immutability Principle (IIP)
Karaniwang tinatanggap na ang mga containerized na application ay dapat manatiling hindi nagbabago pagkatapos maitayo, kahit na ang mga ito ay pinapatakbo sa iba't ibang mga kapaligiran. Nangangailangan ito ng pangangailangang i-externalize ang storage ng data sa runtime (sa madaling salita, para gumamit ng mga external na tool para dito) at umasa sa mga external, runtime-specific na configuration, sa halip na baguhin o lumikha ng mga natatanging container para sa bawat environment. Pagkatapos ng anumang mga pagbabago sa application, ang imahe ng container ay dapat na muling itayo at i-deploy sa lahat ng mga environment na ginamit. Sa pamamagitan ng paraan, kapag namamahala sa mga IT system, isang katulad na prinsipyo ang ginagamit, na kilala bilang ang prinsipyo ng immutability ng mga server at imprastraktura.
Ang layunin ng IIP ay pigilan ang paglikha ng hiwalay na mga imahe ng lalagyan para sa iba't ibang runtime na kapaligiran at gamitin ang parehong larawan sa lahat ng dako kasama ng naaangkop na configuration na partikular sa kapaligiran. Ang pagsunod sa prinsipyong ito ay nagbibigay-daan sa iyo na ipatupad ang mga mahahalagang kasanayan mula sa punto ng view ng automation ng mga cloud system bilang roll-back at roll-forward ng mga update sa application.
Prinsipyo ng Disposability ng Proseso (PDP)
Ang isa sa pinakamahalagang katangian ng isang container ay ang ephemerality nito: ang isang instance ng container ay madaling gawin at madaling sirain, kaya madali itong mapalitan ng isa pang instance anumang oras. Maaaring maraming dahilan para sa naturang pagpapalit: pagkabigo ng isang pagsubok sa kakayahang magamit, pag-scale ng aplikasyon, paglipat sa ibang host, pagkaubos ng mga mapagkukunan ng platform, o iba pang mga sitwasyon.
Bilang resulta, dapat panatilihin ng mga containerized na application ang kanilang estado gamit ang ilang panlabas na paraan, o gumamit ng mga panloob na ipinamamahaging scheme na may redundancy para dito. Bilang karagdagan, ang application ay dapat magsimula nang mabilis at mabilis na isara, at maging handa para sa biglaang nakamamatay na pagkabigo ng hardware.
Ang isang kasanayan na tumutulong sa pagpapatupad ng prinsipyong ito ay ang panatilihing maliit ang mga lalagyan. Maaaring awtomatikong pumili ang mga cloud environment ng host kung saan maglulunsad ng instance ng container, kaya kung mas maliit ang container, mas mabilis itong magsisimula - mas mabilis itong makokopya sa target na host sa network.
Prinsipyo sa Pagpipigil sa Sarili (S-CP)
Ayon sa prinsipyong ito, sa yugto ng pagpupulong, ang lahat ng kinakailangang sangkap ay kasama sa lalagyan. Ang lalagyan ay dapat itayo sa pagpapalagay na ang system ay mayroon lamang purong Linux kernel, kaya ang lahat ng kinakailangang karagdagang mga aklatan ay dapat ilagay sa mismong lalagyan. Dapat din itong maglaman ng mga bagay tulad ng runtime para sa kaukulang programming language, ang application platform (kung kinakailangan), at iba pang dependency na kakailanganin habang tumatakbo ang container application.
Ang mga pagbubukod ay ginawa para sa mga configuration na nag-iiba-iba sa bawat kapaligiran at dapat ibigay sa runtime, halimbawa sa pamamagitan ng Kubernetes ConfigMap.
Ang isang application ay maaaring magsama ng ilang containerized na bahagi, halimbawa, isang hiwalay na DBMS container sa loob ng containerized na web application. Ayon sa prinsipyo ng S-CP, ang mga lalagyan na ito ay hindi dapat pagsamahin sa isa, ngunit dapat gawin upang ang lalagyan ng DBMS ay naglalaman ng lahat ng kailangan para sa pagpapatakbo ng database, at ang lalagyan ng web application ay naglalaman ng lahat ng kailangan para sa pagpapatakbo ng web application, ang parehong web server . Bilang resulta, sa runtime ang lalagyan ng web application ay magdedepende sa lalagyan ng DBMS at maa-access ito kung kinakailangan.
Runtime Confinement Principle (RCP)
Tinutukoy ng prinsipyo ng S-CP kung paano dapat gawin ang lalagyan at kung ano ang dapat na nilalaman ng binary ng imahe. Ngunit ang isang lalagyan ay hindi lamang isang "itim na kahon" na may isang katangian lamang - laki ng file. Sa panahon ng pagpapatupad, ang container ay tumatagal sa iba pang mga dimensyon: ang dami ng memory na ginamit, oras ng CPU, at iba pang mapagkukunan ng system.
At narito ang prinsipyo ng RCP ay madaling gamitin, ayon sa kung saan dapat putulin ng lalagyan ang mga kinakailangan nito para sa mga mapagkukunan ng system at ilipat ang mga ito sa platform. Sa mga profile ng mapagkukunan ng bawat container (kung gaano karaming CPU, memory, network, at mga mapagkukunan ng disk ang kailangan nito), ang platform ay mahusay na makakapagsagawa ng pag-iiskedyul at autoscaling, pamahalaan ang kapasidad ng IT, at mapanatili ang mga antas ng SLA para sa mga container.
Bilang karagdagan sa pagtugon sa mga kinakailangan sa mapagkukunan ng lalagyan, mahalaga din para sa aplikasyon na huwag lumampas sa sarili nitong mga hangganan. Kung hindi, kapag nagkaroon ng kakulangan sa mapagkukunan, mas malamang na isama ito ng platform sa listahan ng mga application na kailangang wakasan o i-migrate.
Kapag pinag-uusapan natin ang pagiging cloud-first, pinag-uusapan natin ang paraan ng ating pagtatrabaho.
Sa itaas, bumuo kami ng ilang pangkalahatang prinsipyo na nagtatakda ng metodolohikal na pundasyon para sa pagbuo ng mga de-kalidad na application ng container para sa mga cloud environment.
Tandaan na bilang karagdagan sa mga pangkalahatang prinsipyong ito, kakailanganin mo rin ng mga karagdagang advanced na pamamaraan at diskarte para sa pagtatrabaho sa mga lalagyan. Bilang karagdagan, mayroon kaming ilang maiikling rekomendasyon na mas partikular at dapat ilapat (o hindi ilapat) depende sa sitwasyon:
- Subukang bawasan ang laki ng mga larawan: tanggalin ang mga pansamantalang file at huwag mag-install ng mga hindi kinakailangang pakete - mas maliit ang sukat ng lalagyan, mas mabilis itong tipunin at kinopya sa target na host sa network.
- Tumutok sa mga arbitrary na User-ID: huwag gamitin ang sudo command o anumang espesyal na userid upang ilunsad ang iyong mga container.
- Markahan ang mahahalagang port: Maaari kang magtakda ng mga numero ng port sa runtime, ngunit mas mainam na tukuyin ang mga ito gamit ang EXPOSE command - gagawin nitong mas madali para sa ibang tao at program na gamitin ang iyong mga larawan.
- Mag-imbak ng patuloy na data sa mga volume: Ang data na dapat manatili pagkatapos sirain ang container ay dapat na nakasulat sa mga volume.
- Sumulat ng metadata ng larawan: pinadadali ng mga tag, label at anotasyon ang mga larawang gamitin - magpapasalamat sa iyo ang ibang mga developer.
- I-synchronize ang host at mga larawan: Ang ilang containerized na application ay nangangailangan ng container na mag-sync sa host sa ilang partikular na attribute, gaya ng time o machine ID.
- Sa konklusyon, nagbabahagi kami ng mga template at pinakamahusay na kagawian na makakatulong sa iyong mas epektibong ipatupad ang mga prinsipyong nakalista sa itaas:
Hunyo 11 sa 11.00
Ano ang matututuhan mo:
- Hindi nababagong Red Hat Enterprise Linux CoreOS
- OpenShift service mesh
- Framework ng operator
- Knative na balangkas
Pinagmulan: www.habr.com