Salaam wote! Jina langu ni Pavel Agaletsky. Ninafanya kazi kama kiongozi wa timu katika timu inayotengeneza mfumo wa utoaji wa Lamoda. Mnamo 2018, nilizungumza kwenye mkutano wa HighLoad++, na leo ningependa kuwasilisha nakala ya ripoti yangu.

Mada yangu imejitolea kwa uzoefu wa kampuni yetu katika kupeleka mifumo na huduma kwa mazingira tofauti. Kuanzia nyakati zetu za awali, tulipoweka mifumo yote kwenye seva pepe za kawaida, na kuishia na mabadiliko ya taratibu kutoka Nomad hadi kutumwa Kubernetes. Nitakuambia kwa nini tulifanya hivyo na ni matatizo gani tulikuwa nayo katika mchakato huo.

Kutuma maombi kwa VM

Wacha tuanze na ukweli kwamba miaka 3 iliyopita mifumo na huduma zote za kampuni ziliwekwa kwenye seva za kawaida za kawaida. Kitaalam, ilipangwa kwa njia ambayo kanuni zote za mifumo yetu zilihifadhiwa na kukusanywa kwa kutumia zana za kusanyiko za kiotomatiki, kwa kutumia jenkins. Kwa kutumia Ansible, ilitolewa kutoka kwa mfumo wetu wa udhibiti wa toleo hadi seva pepe. Zaidi ya hayo, kila mfumo ambao kampuni yetu ilikuwa nao ulipelekwa kwa seva angalau 2: moja juu ya kichwa, ya pili kwenye mkia. Mifumo hii miwili ilikuwa sawa kabisa kwa kila mmoja katika mipangilio yao yote, nguvu, usanidi, nk. Tofauti pekee kati yao ilikuwa kwamba kichwa kilipokea trafiki ya watumiaji, wakati mkia haukupokea trafiki ya watumiaji.

Kwa nini hili lilifanyika?

Tulipotuma matoleo mapya ya programu yetu, tulitaka kuhakikisha uchapishaji wa programu bila mpangilio, yaani, bila madhara yanayoonekana kwa watumiaji. Hii iliafikiwa kwa sababu toleo lililofuata lililokusanywa kwa kutumia Ansible lilitolewa hadi mkia. Huko, watu waliohusika katika kupelekwa wanaweza kuangalia na kuhakikisha kuwa kila kitu kilikuwa sawa: metrics zote, sehemu na maombi yalikuwa yakifanya kazi; maandishi muhimu yanazinduliwa. Tu baada ya kushawishika kuwa kila kitu kiko sawa, trafiki ilibadilishwa. Ilianza kwenda kwa seva ambayo hapo awali ilikuwa mkia. Na ile ambayo hapo awali ilikuwa kichwa ilibaki bila trafiki ya watumiaji, wakati bado ina toleo la awali la programu yetu juu yake.

Kwa hivyo ilikuwa imefumwa kwa watumiaji. Kwa sababu ubadilishaji ni wa papo hapo, kwani ni kubadili tu kusawazisha. Unaweza kurudi kwa toleo la awali kwa urahisi sana kwa kubadilisha tu sawazisha nyuma. Pia tunaweza kuthibitisha kwamba programu ilikuwa na uwezo wa kuzalisha hata kabla ya kupokea trafiki ya watumiaji, ambayo ilikuwa rahisi sana.

Je, tuliona faida gani katika haya yote?

1. Kwanza kabisa, inatosha inafanya kazi tu. Kila mtu anaelewa jinsi mpango kama huo wa kusambaza unavyofanya kazi, kwa sababu watu wengi wamewahi kutumwa kwa seva za kawaida za kawaida.
2. Hii inatosha kwa uhakika, kwa kuwa teknolojia ya kupeleka ni rahisi, iliyojaribiwa na maelfu ya makampuni. Mamilioni ya seva hutumwa kwa njia hii. Ni vigumu kuvunja kitu.
3. Na hatimaye tunaweza kupata usambazaji wa atomiki. Usambazaji unaotokea wakati huo huo kwa watumiaji, bila hatua inayoonekana ya kubadili kati ya toleo la zamani na jipya.

Lakini pia tuliona mapungufu kadhaa katika haya yote:

1. Mbali na mazingira ya uzalishaji, mazingira ya maendeleo, kuna mazingira mengine. Kwa mfano, qa na preproduction. Wakati huo tulikuwa na seva nyingi na karibu huduma 60. Kwa sababu hii ilikuwa ni lazima kwa kila huduma, tunza toleo jipya zaidi kwa ajili yake mashine virtual. Zaidi ya hayo, ikiwa unataka kusasisha maktaba au kusakinisha vitegemezi vipya, unahitaji kufanya hivi katika mazingira yote. Pia ulihitaji kusawazisha wakati utakapotuma toleo jipya la programu yako na wakati ambapo devops hutekeleza mipangilio muhimu ya mazingira. Katika kesi hii, ni rahisi kuingia katika hali ambayo mazingira yetu yatakuwa tofauti katika mazingira yote mara moja. Kwa mfano, katika mazingira ya QA kutakuwa na baadhi ya matoleo ya maktaba, na katika mazingira ya uzalishaji kutakuwa na tofauti, ambayo itasababisha matatizo.
2. Ugumu wa kusasisha utegemezi maombi yako. Inategemea sio wewe, lakini kwa timu nyingine. Yaani, kutoka kwa timu ya devops ambayo inadumisha seva. Lazima uwape kazi inayofaa na maelezo ya kile unachotaka kufanya.
3. Wakati huo, tulitaka pia kugawanya monoliths kubwa kubwa tuliyokuwa nayo katika huduma ndogo tofauti, kwa kuwa tulielewa kuwa kutakuwa na zaidi na zaidi. Wakati huo, tayari tulikuwa na zaidi ya 100. Kwa kila huduma mpya, ilikuwa ni lazima kuunda mashine mpya tofauti ya virtual, ambayo pia ilihitaji kudumishwa na kupelekwa. Kwa kuongeza, huhitaji gari moja, lakini angalau mbili. Imeongezwa kwa haya yote ni mazingira ya QA. Hii husababisha matatizo na kufanya iwe vigumu kwako kujenga na kuendesha mifumo mipya. mchakato mgumu, wa gharama kubwa na mrefu.

Kwa hivyo, tuliamua kuwa itakuwa rahisi zaidi kuhama kutoka kwa kupeleka mashine za kawaida za kawaida hadi kupeleka programu zetu kwenye kontena la docker. Ikiwa unayo docker, unahitaji mfumo ambao unaweza kuendesha programu kwenye nguzo, kwani huwezi tu kuinua chombo. Kawaida unataka kufuatilia ni vyombo ngapi vimeinuliwa ili viinue kiotomatiki. Kwa sababu hii, tulihitaji kuchagua mfumo wa udhibiti.

Tulifikiria kwa muda mrefu ni ipi tunaweza kuchukua. Ukweli ni kwamba wakati huo safu hii ya kupeleka kwenye seva za kawaida za kawaida ilikuwa imepitwa na wakati, kwani hawakuwa na matoleo ya hivi karibuni ya mifumo ya uendeshaji. Wakati fulani, kulikuwa na hata FreeBSD, ambayo haikuwa rahisi sana kusaidia. Tulielewa kuwa tulihitaji kuhamia docker haraka iwezekanavyo. Washiriki wetu waliangalia uzoefu wao uliopo na masuluhisho tofauti na wakachagua mfumo kama Nomad.

Badili hadi Nomad

Nomad ni bidhaa ya HashiCorp. Pia wanajulikana kwa suluhisho zao zingine:

"Balozi" ni chombo cha ugunduzi wa huduma.

"Terraform" - mfumo wa kudhibiti seva ambayo hukuruhusu kuzisanidi kupitia usanidi, kinachojulikana kama miundombinu-kama-msimbo.

"Mzururaji" hukuruhusu kupeleka mashine pepe ndani ya nchi au kwenye wingu kupitia faili mahususi za usanidi.

Nomad wakati huo ilionekana kama suluhisho rahisi ambalo linaweza kubadilishwa haraka bila kubadilisha miundombinu yote. Kwa kuongeza, ni rahisi sana kujifunza. Ndiyo maana tuliichagua kama mfumo wa kuchuja kwa kontena letu.

Unahitaji nini kupeleka mfumo wako kwa Nomad?

1. Kwanza kabisa unahitaji picha ya docker maombi yako. Unahitaji kuijenga na kuiweka kwenye hazina ya picha ya kizimbani. Kwa upande wetu, hii ni artifactory - mfumo unaokuwezesha kushinikiza mabaki mbalimbali ya aina tofauti ndani yake. Inaweza kuhifadhi kumbukumbu, picha za docker, vifurushi vya PHP vya mtunzi, vifurushi vya NPM, na kadhalika.
2. Inahitajika pia faili ya usanidi, ambayo itamwambia Nomad nini, wapi na kwa kiasi gani unataka kupeleka.

Tunapozungumza juu ya Nomad, hutumia lugha ya HCL kama umbizo la faili ya habari, ambayo inasimamia Lugha ya Usanidi wa HashiCorp. Hiki ni kikundi kikuu cha Yaml kinachokuruhusu kuelezea huduma yako kwa maneno ya Nomad.

Inakuwezesha kusema ni vyombo ngapi unataka kupeleka, kutoka kwa picha gani kupitisha vigezo mbalimbali kwao wakati wa kupeleka. Kwa hivyo, unalisha faili hii kwa Nomad, na inazindua vyombo katika uzalishaji kulingana nayo.

Kwa upande wetu, tuligundua kuwa kuandika faili za HCL zinazofanana kabisa kwa kila huduma haitakuwa rahisi sana, kwa sababu kuna huduma nyingi na wakati mwingine unataka kuzisasisha. Inatokea kwamba huduma moja haitumiki kwa mfano mmoja, lakini kwa aina tofauti tofauti. Kwa mfano, moja ya mifumo ambayo tunayo katika uzalishaji ina zaidi ya matukio 100 katika uzalishaji. Wanakimbia kutoka kwa picha sawa, lakini hutofautiana katika mipangilio ya usanidi na faili za usanidi.

Kwa hiyo, tuliamua kwamba itakuwa rahisi kwetu kuhifadhi faili zetu zote za usanidi kwa ajili ya kupelekwa kwenye hifadhi moja ya kawaida. Kwa njia hii zilionekana: zilikuwa rahisi kutunza na tuliweza kuona ni mifumo gani tulikuwa nayo. Ikiwa ni lazima, pia ni rahisi kusasisha au kubadilisha kitu. Kuongeza mfumo mpya pia sio ngumu - unahitaji tu kuunda faili ya usanidi ndani ya saraka mpya. Ndani yake kuna faili zifuatazo: service.hcl, ambayo ina maelezo ya huduma yetu, na faili zingine za env zinazoruhusu huduma hii hii, ikitumwa katika uzalishaji, kusanidiwa.

Hata hivyo, baadhi ya mifumo yetu inatumika katika uzalishaji si katika nakala moja, lakini katika kadhaa mara moja. Kwa hivyo, tuliamua kuwa itakuwa rahisi kwetu kuhifadhi sio usanidi katika fomu yao safi, lakini fomu yao ya kiolezo. Na tulichagua jinja 2. Katika umbizo hili, tunahifadhi usanidi wa huduma yenyewe na faili za env zinazohitajika kwa ajili yake.

Zaidi ya hayo, tumeweka katika hifadhi hati ya upelekaji inayofanana na miradi yote, ambayo inakuruhusu kuzindua na kupeleka huduma yako katika uzalishaji, katika mazingira unayotaka, katika lengo unalotaka. Katika kesi tulipogeuza usanidi wetu wa HCL kuwa template, basi faili ya HCL, ambayo hapo awali ilikuwa usanidi wa kawaida wa Nomad, katika kesi hii ilianza kuonekana tofauti kidogo.

Hiyo ni, tulibadilisha anuwai za eneo la usanidi na anuwai zilizoingizwa ambazo huchukuliwa kutoka kwa faili za env au vyanzo vingine. Kwa kuongeza, tulipata fursa ya kukusanya faili za HCL kwa nguvu, yaani, tunaweza kutumia sio tu uingizaji wa kawaida wa kutofautiana. Kwa kuwa jinja inasaidia vitanzi na masharti, unaweza pia kuunda faili za usanidi hapo, ambazo hubadilika kulingana na mahali unapopeleka programu zako.

Kwa mfano, ungependa kupeleka huduma yako kwenye utayarishaji wa awali na uzalishaji. Wacha tuseme kwamba katika utayarishaji wa awali hutaki kuendesha hati za cron, lakini unataka tu kuona huduma kwenye kikoa tofauti ili kuhakikisha kuwa inafanya kazi. Kwa mtu yeyote anayepeleka huduma, mchakato unaonekana rahisi sana na wa uwazi. Unachohitaji kufanya ni kutekeleza faili ya deploy.sh, taja ni huduma gani unataka kupeleka na kwa lengo lipi. Kwa mfano, unataka kupeleka mfumo fulani kwa Urusi, Belarus au Kazakhstan. Ili kufanya hivyo, badilisha tu moja ya vigezo, na utakuwa na faili sahihi ya usanidi.

Wakati huduma ya Nomad tayari imetumwa kwa nguzo yako, inaonekana hivi.

Kwanza, unahitaji aina fulani ya kusawazisha nje, ambayo itapokea trafiki yote ya watumiaji. Itafanya kazi pamoja na Balozi na kujua kutoka kwayo wapi, kwenye nodi gani, kwa anwani gani ya IP huduma maalum iko ambayo inalingana na jina fulani la kikoa. Huduma katika Balozi hutoka kwa Nomad yenyewe. Kwa kuwa hizi ni bidhaa kutoka kwa kampuni moja, zinahusiana kabisa na kila mmoja. Tunaweza kusema kwamba Nomad nje ya boksi anaweza kusajili huduma zote zilizozinduliwa ndani yake ndani ya Balozi.

Pindi kisawazisha chako cha upakiaji wa sehemu ya mbele kinapojua ni huduma gani ya kutuma trafiki, huipeleka kwenye kontena inayofaa au vyombo vingi vinavyolingana na programu yako. Kwa kawaida, ni lazima pia kufikiri juu ya usalama. Ingawa huduma zote zinaendeshwa kwa mashine zile zile za mtandaoni kwenye vyombo, kwa kawaida hii inahitaji kuzuia ufikiaji wa bure kutoka kwa huduma yoyote kwenda nyingine yoyote. Tulifanikiwa hili kupitia sehemu. Kila huduma ilizinduliwa katika mtandao wake wa mtandaoni, ambapo sheria za uelekezaji na sheria za kuruhusu/kukataa ufikiaji wa mifumo na huduma zingine ziliwekwa. Wanaweza kupatikana ndani ya nguzo hii na nje yake. Kwa mfano, ikiwa unataka kuzuia huduma kuunganishwa kwenye hifadhidata maalum, hii inaweza kufanywa kupitia mgawanyiko wa kiwango cha mtandao. Hiyo ni, hata kwa makosa, huwezi kuunganisha kwa bahati mbaya kutoka kwa mazingira ya jaribio hadi hifadhidata yako ya uzalishaji.

Je, mpito ulitugharimu kiasi gani katika suala la rasilimali watu?

Mpito wa kampuni nzima kwenda Nomad ulichukua takriban miezi 5-6. Tulihamia kwa msingi wa huduma kwa huduma, lakini kwa kasi ya haraka. Kila timu ililazimika kuunda vyombo vyake vya huduma.

Tumechukua mbinu kama hii kwamba kila timu inawajibika kwa picha za docker za mifumo yao kwa kujitegemea. DevOps hutoa miundombinu ya jumla muhimu kwa kupelekwa, ambayo ni, msaada kwa nguzo yenyewe, msaada kwa mfumo wa CI, na kadhalika. Na wakati huo, tulikuwa na mifumo zaidi ya 60 iliyohamishiwa kwa Nomad, ambayo ilifikia takriban vyombo elfu 2.

Devops inawajibika kwa miundombinu ya jumla ya kila kitu kinachohusiana na usambazaji na seva. Na kila timu ya maendeleo, kwa upande wake, ina jukumu la kutekeleza makontena kwa mfumo wake maalum, kwa kuwa ni timu inayojua kile kinachohitaji kwa ujumla katika kontena fulani.

Sababu za kuachana na Nomad

Je! tulipata faida gani kwa kubadili matumizi kwa kutumia Nomad na docker, miongoni mwa zingine?

1. Sisi ilitoa masharti sawa kwa mazingira yote. Katika maendeleo, mazingira ya QA, uzalishaji wa awali, uzalishaji, picha za chombo sawa hutumiwa, na tegemezi sawa. Ipasavyo, kwa hakika huna nafasi kwamba kile kitakachoishia katika uzalishaji si kile ulichojaribu hapo awali ndani ya nchi au katika mazingira yako ya majaribio.
2. Pia tuligundua kuwa inatosha rahisi kuongeza huduma mpya. Kutoka kwa mtazamo wa kupeleka, mifumo yoyote mpya inazinduliwa kwa urahisi sana. Nenda tu kwenye hazina ambayo huhifadhi usanidi, ongeza usanidi mwingine wa mfumo wako hapo, na mko tayari. Unaweza kusambaza mfumo wako kwa uzalishaji bila juhudi zozote za ziada kutoka kwa watoa huduma.
3. Wote faili za usanidi katika hazina moja ya pamoja iligeuka kuwa chini ya ukaguzi. Wakati tuliposambaza mifumo yetu kwa kutumia seva pepe, tulitumia Ansible, ambapo usanidi ulikuwa kwenye hazina sawa. Walakini, kwa watengenezaji wengi hii ilikuwa ngumu zaidi kufanya kazi nayo. Hapa kiasi cha usanidi na msimbo ambao unahitaji kuongeza ili kupeleka huduma imekuwa ndogo zaidi. Zaidi ya hayo, ni rahisi sana kwa devops kurekebisha au kuibadilisha. Katika kesi ya mabadiliko, kwa mfano, kwa toleo jipya la Nomad, wanaweza kuchukua na kusasisha faili zote za uendeshaji ziko katika sehemu moja.

Lakini pia tulikutana na hasara kadhaa:

Ilibadilika kuwa sisi haikuweza kufikia upelekaji bila mshono kwa upande wa Nomad. Wakati wa kusambaza vyombo chini ya hali tofauti, inaweza kugeuka kuwa inaendeshwa, na Nomad aliiona kama chombo kilicho tayari kupokea trafiki. Hii ilitokea kabla ya programu ndani yake hata kupata nafasi ya kuzindua. Kwa sababu hii, mfumo ulianza kutoa makosa 500 kwa muda mfupi, kwa sababu trafiki ilianza kwenda kwenye kontena ambayo haikuwa tayari kuikubali.

Tulikutana na baadhi mende. Mdudu muhimu zaidi ni kwamba Nomad haishughulikii nguzo kubwa vizuri ikiwa una mifumo na vyombo vingi. Unapotaka kutoa mojawapo ya seva ambazo zimejumuishwa kwenye nguzo ya Nomad kwa ajili ya matengenezo, kuna uwezekano mkubwa kwamba nguzo hiyo haitajisikia vizuri na itatengana. Baadhi ya vyombo vinaweza, kwa mfano, kuanguka na kutopanda - hii itakugharimu baadaye sana ikiwa mifumo yako yote ya uzalishaji iko katika kundi linalosimamiwa na Nomad.

Kwa hiyo tuliamua kufikiria ni wapi tunapaswa kwenda. Wakati huo, tulifahamu zaidi kile tunachotaka kufikia. Yaani: tunataka kutegemewa, utendaji zaidi kidogo kuliko Nomad hutoa, na mfumo uliokomaa zaidi, thabiti zaidi.

Katika suala hili, chaguo letu liliangukia Kubernetes kama jukwaa maarufu zaidi la kuzindua vikundi. Hasa kutokana na kwamba ukubwa na idadi ya vyombo vyetu vilikuwa vya kutosha. Kwa madhumuni kama haya, Kubernetes ilionekana kuwa mfumo unaofaa zaidi ambao tunaweza kuangalia.

Mpito hadi Kubernetes

Nitakuambia kidogo juu ya dhana za kimsingi za Kubernetes na jinsi zinavyotofautiana na Nomad.

Kwanza kabisa, dhana ya msingi zaidi katika Kubernetes ni dhana ya pod. Pod ni kundi la chombo kimoja au zaidi ambacho hutembea pamoja kila wakati. Na kila wakati hufanya kazi kana kwamba kwenye mashine moja ya kawaida. Zinapatikana kwa kila mmoja kupitia IP 127.0.0.1 kwenye bandari tofauti.

Wacha tuchukue kuwa unayo programu tumizi ya PHP ambayo inajumuisha nginx na php-fpm - mpango wa kawaida. Uwezekano mkubwa zaidi, utataka kuweka vyombo vyote vya nginx na php-fpm pamoja wakati wote. Kubernetes hukuruhusu kufanikisha hili kwa kuwaelezea kama ganda moja la kawaida. Hili ndilo hasa ambalo hatukuweza kupata na Nomad.

Dhana ya pili ni kupelekwa. Ukweli ni kwamba ganda lenyewe ni jambo la ephemeral, linaanza na kutoweka. Je, unataka kuua kontena zako zote za awali kwanza, na kisha uzindue matoleo mapya mara moja, au unataka kuyasambaza taratibu? Huu ndio mchakato ambao dhana ya uwekaji inawajibika. Inafafanua jinsi unavyosambaza maganda yako, kwa idadi gani na jinsi ya kuzisasisha.

Dhana ya tatu ni huduma. Huduma yako kwa hakika ni mfumo wako, ambao hupokea trafiki fulani na kisha kuisambaza kwa ganda moja au zaidi zinazolingana na huduma yako. Hiyo ni, hukuruhusu kusema kwamba trafiki yote inayoingia kwa huduma kama hiyo na kama vile na jina kama hilo lazima ipelekwe kwa maganda haya maalum. Na wakati huo huo hukupa kusawazisha trafiki. Hiyo ni, unaweza kuzindua ganda mbili za programu yako, na trafiki yote inayoingia itakuwa sawa kati ya maganda yanayohusiana na huduma hii.

Na dhana ya nne ya msingi ni Ingress. Hii ni huduma inayoendeshwa kwenye kundi la Kubernetes. Inafanya kazi kama kisawazisha cha nje cha mzigo ambacho huchukua maombi yote. Kwa kutumia API ya Kubernetes, Ingress inaweza kuamua ni wapi maombi haya yanapaswa kutumwa. Zaidi ya hayo, anafanya hivyo kwa urahisi sana. Unaweza kusema kwamba maombi yote kwa seva pangishi hii na vile na vile URL hutumwa kwa huduma hii. Na maombi haya yanayokuja kwa mwenyeji huyu na kwa URL nyingine yanatumwa kwa huduma nyingine.

Jambo la kupendeza zaidi kutoka kwa mtazamo wa mtu ambaye hutengeneza programu ni kwamba unaweza kuisimamia mwenyewe. Kwa kuweka usanidi wa Ingress, unaweza kutuma trafiki yote inayokuja kwa vile na API ili kutenganisha vyombo vilivyoandikwa, kwa mfano, katika Go. Lakini trafiki hii, inayokuja kwenye kikoa sawa, lakini kwa URL tofauti, inapaswa kutumwa kwa vyombo vilivyoandikwa katika PHP, ambapo kuna mantiki nyingi, lakini sio haraka sana.

Ikiwa tutalinganisha dhana hizi zote na Nomad, tunaweza kusema kwamba dhana tatu za kwanza ziko pamoja Huduma. Na dhana ya mwisho haipo katika Nomad yenyewe. Tulitumia mizani ya nje kama ilivyo: inaweza kuwa haproxy, nginx, nginx+, na kadhalika. Katika kesi ya mchemraba, huna haja ya kuanzisha dhana hii ya ziada tofauti. Walakini, ukiangalia Ingress ndani, ni nginx, haproxy, au traefik, lakini ni aina iliyojengwa ndani ya Kubernetes.

Dhana zote nilizoelezea ni, kwa kweli, rasilimali ambazo zipo ndani ya nguzo ya Kubernetes. Ili kuzielezea katika mchemraba, umbizo la yaml hutumiwa, ambalo linasomeka zaidi na linajulikana zaidi kuliko faili za HCL katika kesi ya Nomad. Lakini kimuundo wanaelezea kitu kimoja katika kesi ya, kwa mfano, pod. Wanasema - nataka kupeleka maganda kama hayo na vile huko, na picha kama hizo, kwa idadi kama hiyo.

Kwa kuongeza, tuligundua kwamba hatukutaka kuunda kila rasilimali ya mtu binafsi kwa mkono: kupelekwa, huduma, Ingress, nk. Badala yake, tulitaka kuelezea kila moja ya mifumo yetu kulingana na Kubernetes wakati wa kusambaza, ili tusilazimike kuunda upya vitegemezi vyote muhimu vya rasilimali kwa mpangilio unaofaa. Helm ilichaguliwa kama mfumo ulioturuhusu kufanya hivi.

Dhana za kimsingi katika Helm

Helm ni meneja wa kifurushi kwa Kubernetes. Ni sawa na jinsi wasimamizi wa vifurushi katika lugha za programu hufanya kazi. Zinakuruhusu kuhifadhi huduma inayojumuisha, kwa mfano, nginx ya kupeleka, kupeleka php-fpm, usanidi wa Ingress, usanidi (hii ni chombo kinachokuruhusu kuweka env na vigezo vingine vya mfumo wako) katika mfumo wa so- inayoitwa chati. Wakati huo huo Helm inaendesha juu ya Kubernetes. Hiyo ni, hii sio aina fulani ya mfumo uliosimama kando, lakini huduma nyingine tu iliyozinduliwa ndani ya mchemraba. Unaingiliana nayo kupitia API yake kupitia amri ya koni. Urahisi na uzuri wake ni kwamba hata usukani ukivunjika au ukiondoa kwenye nguzo, huduma zako hazitatoweka, kwani usukani hutumika tu kuanzisha mfumo. Kubernetes yenyewe basi inawajibika kwa utendaji na hali ya huduma.

Pia tulitambua hilo kiolezo, ambayo hapo awali tulilazimishwa kufanya wenyewe kwa kuanzisha jinja kwenye usanidi wetu, ni moja wapo ya sifa kuu za usukani. Mipangilio yote unayounda kwa ajili ya mifumo yako huhifadhiwa kwenye usukani katika mfumo wa violezo, sawa na jinja, lakini, kwa kweli, kwa kutumia kiolezo cha lugha ya Go, ambayo helm imeandikwa, kama Kubernetes.

Helm inatuongezea dhana chache zaidi.

chati - hii ni maelezo ya huduma yako. Katika wasimamizi wengine wa vifurushi itaitwa kifurushi, kifungu au kitu sawa. Hapa inaitwa chati.

Maadili ni vigeuzo unavyotaka kutumia kuunda usanidi wako kutoka kwa violezo.

Achilia. Kila wakati huduma ambayo inatumwa kwa usukani inapokea toleo la nyongeza la toleo. Helm inakumbuka usanidi wa huduma ulikuwa nini katika toleo la awali, kutolewa kabla ya hapo, na kadhalika. Kwa hivyo, ikiwa unahitaji kurudisha nyuma, endesha tu amri ya kurudi nyuma, ukielekeza kwenye toleo la awali la toleo. Hata kama usanidi sambamba katika hazina yako haupatikani wakati wa kurejesha, helm bado itakumbuka ilivyokuwa na itarejesha mfumo wako katika hali uliyokuwa katika toleo la awali.

Katika kisa tunapotumia usukani, usanidi wa kawaida wa Kubernetes pia hubadilika kuwa violezo ambamo inawezekana kutumia viambajengo, vitendaji, na kutumia taarifa za masharti. Kwa njia hii unaweza kukusanya usanidi wako wa huduma kulingana na mazingira.

Kwa mazoezi, tuliamua kufanya mambo kwa njia tofauti kidogo kuliko tulivyofanya na Nomad. Ikiwa katika Nomad usanidi wote wa kupeleka na vigeu vya n ambavyo vilihitajika kupeleka huduma yetu vilihifadhiwa kwenye hazina moja, hapa tuliamua kuzigawanya katika hazina mbili tofauti. Hazina ya "peleka" huhifadhi vigeu vya n pekee vinavyohitajika kwa matumizi, na hazina ya "helm" huhifadhi mipangilio au chati.

Hii ilitupa nini?

Licha ya ukweli kwamba hatuhifadhi data yoyote nyeti katika faili za usanidi zenyewe. Kwa mfano, nywila kwa hifadhidata. Zimehifadhiwa kama siri katika Kubernetes, lakini hata hivyo, bado kuna mambo fulani ambayo hatutaki kumpa kila mtu ufikiaji. Kwa hivyo, ufikiaji wa hazina ya "kupeleka" ni mdogo zaidi, na hazina ya "helm" ina maelezo ya huduma. Kwa sababu hii, inaweza kufikiwa kwa usalama na anuwai ya watu.

Kwa kuwa hatuna uzalishaji tu, bali pia mazingira mengine, kutokana na utengano huu tunaweza kutumia tena chati zetu za usukani ili kupeleka huduma si tu kwa uzalishaji, bali pia, kwa mfano, kwa mazingira ya QA. Hata kuzipeleka ndani kwa kutumia Minikube - Hili ni jambo la kuendesha Kubernetes ndani ya nchi.

Ndani ya kila hazina, tuliacha mgawanyiko katika saraka tofauti kwa kila huduma. Hiyo ni, ndani ya kila saraka kuna violezo vinavyohusiana na chati inayolingana na kuelezea rasilimali zinazohitajika kutumwa ili kuzindua mfumo wetu. Tuliacha envs tu kwenye hazina ya "kupeleka". Katika kesi hii, hatukutumia templating kutumia jinja, kwa sababu helm yenyewe hutoa templating nje ya sanduku - hii ni moja ya kazi zake kuu.

Tuliacha hati ya kusambaza - deploy.sh, ambayo hurahisisha na kusawazisha uzinduzi kwa ajili ya kupelekwa kwa kutumia usukani. Kwa hivyo, kwa mtu yeyote anayetaka kupeleka, kiolesura cha kupeleka kinaonekana sawa kabisa na ilivyokuwa wakati wa kupeleka kupitia Nomad. deploy.sh sawa, jina la huduma yako, na mahali unapotaka kuipeleka. Hii inasababisha helm kuanza ndani. Yeye, kwa upande wake, hukusanya usanidi kutoka kwa templeti, huingiza faili za maadili muhimu ndani yao, kisha kuzipeleka, kuzizindua kwenye Kubernetes.

Matokeo

Huduma ya Kubernetes inaonekana kuwa ngumu zaidi kuliko Nomad.

Hapa trafiki inayotoka inakuja Ingress. Huyu ni mtawala wa mbele tu, ambaye huchukua maombi yote na kisha kuwatuma kwa huduma zinazolingana na data ya ombi. Huzibainisha kulingana na usanidi ambao ni sehemu ya maelezo ya programu yako kwenye usukani na ambayo wasanidi huiweka peke yao. Huduma hutuma maombi kwa maganda yake, ambayo ni, vyombo maalum, kusawazisha trafiki inayoingia kati ya vyombo vyote ambavyo ni vya huduma hii. Na, bila shaka, hatupaswi kusahau kwamba hatupaswi kwenda popote kutoka kwa usalama kwenye ngazi ya mtandao. Kwa hivyo, mgawanyiko hufanya kazi katika nguzo ya Kubernetes, ambayo inategemea kuweka lebo. Huduma zote zina lebo fulani ambazo haki za ufikiaji wa huduma kwa rasilimali fulani za nje/ndani ndani au nje ya nguzo zinahusishwa.

Tulipofanya mabadiliko, tuliona kwamba Kubernetes alikuwa na uwezo wote wa Nomad, ambao tulikuwa tumeutumia hapo awali, na pia tukaongeza mambo mengi mapya. Inaweza kupanuliwa kupitia programu-jalizi, na kwa kweli kupitia aina za rasilimali maalum. Hiyo ni, una fursa sio tu kutumia kitu kinachokuja na Kubernetes nje ya boksi, lakini kuunda rasilimali yako mwenyewe na huduma ambayo itasoma rasilimali yako. Hii inakupa chaguo za ziada za kupanua mfumo wako bila kusakinisha tena Kubernetes na bila kuhitaji marekebisho.

Mfano wa matumizi kama haya ni Prometheus, ambayo inaendesha ndani ya nguzo yetu ya Kubernetes. Ili ianze kukusanya vipimo kutoka kwa huduma fulani, tunahitaji kuongeza aina ya ziada ya rasilimali, kinachojulikana kama mfuatiliaji wa huduma, kwenye maelezo ya huduma. Prometheus, kutokana na ukweli kwamba inaweza kusoma aina ya rasilimali maalum inapozinduliwa katika Kubernetes, huanza kukusanya vipimo kiotomatiki kutoka kwa mfumo mpya. Inafaa kabisa.

Mara ya kwanza tulituma Kubernetes mnamo Machi 2018. Na wakati huu hatukuwahi kupata shida yoyote nayo. Inafanya kazi kwa utulivu bila mende muhimu. Kwa kuongeza, tunaweza kuipanua zaidi. Leo tuna uwezo wa kutosha, na tunapenda sana kasi ya maendeleo ya Kubernetes. Hivi sasa, zaidi ya kontena 3000 ziko Kubernetes. Nguzo inachukua Nodes kadhaa. Wakati huo huo, inaweza kutumika, imara na inaweza kudhibitiwa sana.

Chanzo: mapenzi.com