Silav hemû! Navê min Pavel Agaletsky e. Ez di tîmek ku pergala radestkirina Lamoda pêş dixe de wekî pêşengek tîmê dixebitim. Di sala 2018-an de, min di konferansa HighLoad++ de axivî, û îro ez dixwazim ji raporta xwe re belgeyek pêşkêşî bikim.

Mijara min ji ezmûna pargîdaniya me re di bicîhkirina pergal û karûbaran de li hawîrdorên cihêreng ve girêdayî ye. Ji demên xwe yên pêşdîrokî dest pê dike, dema ku me hemî pergalên di serverên virtual yên asayî de bicîh kirin, bi veguheztina hêdî-hêdî ji Nomad ber bi cîhkirina li Kubernetes ve bi dawî bû. Ez ê ji we re bibêjim ku me çima kir û di pêvajoyê de çi pirsgirêkên me hebûn.

Sazkirina sepanan li VM

Ka em bi vê rastiyê dest pê bikin ku 3 sal berê hemî pergal û karûbarên pargîdaniyê li ser serverên virtual yên birêkûpêk hatine bicîh kirin. Ji hêla teknîkî ve, ew bi vî rengî hate organîze kirin ku hemî kodên pergalên me bi karanîna amûrên komkirina otomatîkî, bi karanîna jenkins, hilanîn û berhev kirin. Bi karanîna Ansible, ew ji pergala meya kontrolkirina guhertoyê berbi serverên virtual ve hate derxistin. Wekî din, her pergala ku pargîdaniya me hebû bi kêmî ve li ser 2 serveran hate bicîh kirin: yek ji wan li ser serê, ya duyemîn li dûv. Van her du pergal di hemî mîhengên xwe, hêz, veavakirina, hwd de bi tevahî bi hevûdu re wekhev bûn. Cûdahiya wan tenê ev bû ku serî seyrûsefera bikarhêner werdigirt, dema ku dûvik qet seyrûsefera bikarhêner wernegirt.

Ji bo çi bû?

Dema ku me serbestberdanên nû yên serîlêdana xwe bi cih kir, me xwest ku pêvekek bêkêmasî misoger bikin, ango bêyî encamên berbiçav ji bo bikarhêneran. Ev ji ber vê yekê hate bidestxistin ku serbestberdana berhevkirî ya paşîn ku bi karanîna Ansible ve hatî bikar anîn ber bi dûvikê ve hate derxistin. Li wir, kesên ku beşdarî veqetandinê bûne dikarin kontrol bikin û piştrast bikin ku her tişt baş e: hemî metrîk, beş û serîlêdan dixebitin; senaryoyên pêwîst têne destpêkirin. Tenê piştî ku ew piştrast bûn ku her tişt baş e, seyrûsefer hate guhertin. Ew dest pê kir ku diçe servera ku berê dûvik bû. Û ya ku berê serê xwe bû bêyî seyrûsefera bikarhêner ma, di heman demê de hîn jî guhertoya berê ya serîlêdana me li ser wê bû.

Ji ber vê yekê ew ji bo bikarhêneran bêkêmasî bû. Ji ber ku veguheztin tavilê ye, ji ber ku ew bi tenê hevsengiyê diguhezîne. Hûn dikarin bi hêsanî bi veguheztina balanserê vegere guhertoya berê. Di heman demê de em dikarin verast bikin ku serîlêdan hêj berî ku ew seyrûsefera bikarhêner werdigire, ku pir rehet bû, hilberand.

Di van hemûyan de me çi avantaj dît?

1. Berî her tiştî bes e ew tenê dixebite. Her kes fêm dike ka nexşeyek bi vî rengî ya bicîhkirinê çawa dixebite, ji ber ku pir kesan her dem li ser serverên virtual yên birêkûpêk bicîh kirine.
2. Ev bes e bi pêbawerî, ji ber ku teknolojiya bicîhkirinê hêsan e, ji hêla hezaran pargîdaniyan ve hatî ceribandin. Bi mîlyonan server bi vî rengî têne bicîh kirin. Zehmet e ku tiştek bişkîne.
3. Û di dawiyê de em dikarin bibin bicihkirina atomî. Sazkirinên ku bi hevdemî ji bo bikarhêneran pêk tên, bêyî qonaxek berbiçav a guheztina di navbera guhertoya kevn û ya nû de.

Lê me di van hemûyan de çend kêmasî jî dîtin:

1. Ji bilî hawirdora hilberînê, hawirdora pêşveçûnê, hawirdorên din hene. Mînak qa û pêşhilberîn. Wê demê gelek server û nêzî 60 xizmetên me hebûn. Ji ber vê sedemê pêwîst bû ji bo her karûbarê, guhertoya herî dawî ji bo wê biparêzin makîneya virtual. Wekî din, heke hûn dixwazin pirtûkxaneyan nûve bikin an girêdanên nû saz bikin, hûn hewce ne ku vê yekê di hemî hawîrdoran de bikin. Di heman demê de hewce bû ku hûn dema ku hûn ê guhertoya nû ya paşîn a serîlêdana xwe bicîh bikin bi dema ku devops mîhengên hawîrdorê yên pêwîst pêk tîne re hevdeng bikin. Di vê rewşê de, hêsan e ku meriv bikeve rewşek ku hawîrdora me di hemî hawîrdoran de bi carekê de hinekî cûda be. Mînakî, di hawîrdorek QA de dê hin guhertoyên pirtûkxaneyan hebin, û di hawîrdorek hilberînê de dê yên cûda hebin, ku dê bibe sedema pirsgirêkan.
2. Zehmetiya nûvekirina pêwendiyan serlêdana we. Ew ne bi we, lê bi tîmê din ve girêdayî ye. Ango, ji tîmê devops ku serveran diparêze. Pêdivî ye ku hûn peywirek guncan û ravekirina tiştê ku hûn dixwazin bikin bidin wan.
3. Di wê demê de, me jî dixwest ku monolîtên mezin ên ku me hebûn di nav karûbarên piçûk ên cihêreng de dabeş bikin, ji ber ku me fêm kir ku dê ji wan bêtir û bêtir hebin. Di wê demê de, me ji niha ve zêdetirî 100 ji wan hebûn. Ji bo her karûbarek nû, pêdivî bû ku makîneyek nû ya nû ya veqetandî were afirandin, ku ew jî pêdivî bû ku were parastin û bicîh kirin. Wekî din, hûn ne hewce ne yek otomobîl, lê bi kêmî ve du. Li van hemûyan jî hawirdora QA tê zêdekirin. Ev dibe sedema pirsgirêkan û avakirina û meşandina pergalên nû ji we re dijwartir dike. pêvajoya aloz, biha û dirêj.

Ji ber vê yekê, me biryar da ku ew ê hêsantir be ku em ji bicîhkirina makîneyên virtual yên birêkûpêk berbi bicîhkirina serîlêdanên xwe di konteynerek dokerê de biçin. Ger we docker hebe, we pêdivî bi pergalek heye ku karibe serîlêdanê di komekê de bimeşîne, ji ber ku hûn nekarin tenê konteynerek rakin. Bi gelemperî hûn dixwazin bişopînin ka çend konteyneran têne rakirin da ku ew bixweber hilkişin. Ji bo vê yekê, me hewce kir ku pergala kontrolê hilbijêre.

Demek dirêj em fikirîn ku em dikarin kîjanê bigirin. Rastî ev e ku di wê demê de ev stûna bicîhkirinê li ser serverên virtual yên normal hinekî kevnar bû, ji ber ku wan guhertoyên herî paşîn ên pergalên xebitandinê tune bûn. Di hin xalan de, tewra FreeBSD jî hebû, ku piştgirî ne pir hêsan bû. Me fêm kir ku pêdivî ye ku em bi lez û bez koçî dokerê bikin. Devokên me bi çareseriyên cihêreng li ezmûna xwe ya heyî mêze kirin û pergalek mîna Nomad hilbijart.

Biçe Nomad

Nomad hilberek HashiCorp e. Ew ji bo çareseriyên xwe yên din jî têne zanîn:

"Sefîr" amûrek ji bo vedîtina xizmetê ye.

"Terraform" - pergalek ji bo birêvebirina pêşkêşkeran ku destûrê dide te ku hûn wan bi konfigurasyonê vesaz bikin, bi navê binesaziya-wek-kod.

"Berger" destûrê dide te ku hûn makîneyên virtual bi navgîniya pelên vesazkirinê yên taybetî ve li cîhê an ewr de bicîh bikin.

Nomad di wê demê de wekî çareseriyek pir hêsan xuya bû ku meriv dikare zû veguhezîne bêyî guheztina tevahiya binesaziyê. Wekî din, fêrbûna wê pir hêsan e. Ji ber vê yekê me ew ji bo konteynera xwe wekî pergala filtrasyonê hilbijart.

Ma hûn çi hewce ne ku hûn pergala xwe li Nomad bicîh bikin?

1. Berî her tiştî hûn hewce ne wêneya docker serlêdana we. Pêdivî ye ku hûn wê ava bikin û wê di depoya wêneya docker de bi cîh bikin. Di doza me de, ev artifactory e - pergalek ku dihêle hûn cûrbecûr celebên cûrbecûr têxin nav wê. Ew dikare arşîv, wêneyên docker, pakêtên PHP-ê çêker, pakêtên NPM, û hwd hilîne.
2. Her weha pêdivî ye pelê veavakirinê, ya ku dê ji Nomad re bêje ka hûn dixwazin çi, li ku û bi kîjan hejmarê bicîh bikin.

Dema ku em li ser Nomad diaxivin, ew zimanê HCL-ê wekî forma pelê agahdariya xwe, ku tê de radiweste, bikar tîne Zimanê Veavakirinê HashiCorp. Ev supersetek Yaml e ku dihêle hûn karûbarê xwe bi şertên Nomad vebêjin.

Ew dihêle hûn bibêjin ka hûn dixwazin çend konteyneran bi cîh bikin, ji kîjan wêneyan di dema danînê de parametreyên cihêreng ji wan re derbas bikin. Bi vî rengî, hûn vê pelê ji Nomad re dihêlin, û ew li gorî wê konteyneran dide hilberînê.

Di doza me de, me fêm kir ku bi tenê nivîsandina pelên HCL-ê yên bêkêmasî yên ji bo her karûbar dê ne pir hêsan be, ji ber ku gelek karûbar hene û carinan hûn dixwazin wan nûve bikin. Wusa diqewime ku yek karûbar ne di yek nimûneyê de, lê di cûrbecûr cûrbecûr de tête bikar anîn. Mînakî, yek ji pergalên ku me di hilberînê de heye di hilberînê de zêdetirî 100 mînak hene. Ew ji heman wêneyan dimeşin, lê di mîhengên vesazkirinê û pelên vesazkirinê de cûda dibin.

Ji ber vê yekê, me biryar da ku ew ê ji me re hêsan be ku em hemî pelên mîhengê xwe ji bo bicîhkirinê di yek depoyek hevpar de hilînin. Bi vî rengî ew xuya bûn: parastina wan hêsan bû û me dikaribû bibînin ka kîjan pergalên me hene. Ger hewce be, nûvekirin an guheztina tiştek jî hêsan e. Zêdekirina pergalek nû jî ne dijwar e - hûn tenê hewce ne ku pelek mîhengê di hundurê pelrêça nû de biafirînin. Di hundurê wê de pelên jêrîn hene: service.hcl, ku danasîna karûbarê me vedihewîne, û hin pelên env ên ku destûrê didin vê karûbarê, ku di hilberînê de tê bicîh kirin, were mîheng kirin.

Lêbelê, hin pergalên me di hilberînê de ne di yek kopiyek de, lê di çend caran de têne bicîh kirin. Ji ber vê yekê, me biryar da ku ew ê ji me re rehet be ku em konfigurasyonan ne di forma xweya paqij, lê forma wan a şablonê de hilînin. Û me hilbijart jinja 2. Di vê formatê de, em hem mîhengên karûbarê bixwe hem jî pelên env yên ku ji bo wê hewce ne hilînin.

Digel vê yekê, me di depoyê de skrîptek bicîhkirinê ya ku ji bo hemî projeyan hevpar e, ku dihêle hûn karûbarê xwe di hilberînê de, li hawîrdora xwestinê, di hedefa xwestinê de bidin destpêkirin û bi cîh bikin. Di vê rewşê de gava ku me veavakirina HCL-ya xwe veguherand şablonek, wê hingê pelê HCL, ku berê vesazek ​​Nomad a birêkûpêk bû, di vê rewşê de dest pê kir hinekî cûda xuya dike.

Ango, me hin guhêrbarên cîhê mîhengê bi guhêrbarên ku ji pelên env an çavkaniyên din têne girtin veguhezand. Digel vê yekê, me fersendek peyda kir ku em pelên HCL bi dînamîkî berhev bikin, ango, em dikarin ne tenê têketina guhêrbar a asayî bikar bînin. Ji ber ku jinja loop û şertan piştgirî dike, hûn dikarin pelên mîhengê jî li wir biafirînin, ku li gorî cîhê ku hûn tam serlêdanên xwe bicîh dikin diguhezin.

Mînakî, hûn dixwazin karûbarê xwe li pêş-hilberîn û hilberînê bi cih bikin. Ka em bibêjin ku di pêş-hilberînê de hûn nexwazin skrîptên cron bimeşînin, lê tenê dixwazin karûbar li ser domainek cûda bibînin da ku pê ewle bibin ku ew kar dike. Ji bo her kesê ku karûbarê bicîh dike, pêvajo pir hêsan û zelal xuya dike. Tiştê ku divê hûn bikin ev e ku pelê deploy.sh bicîh bikin, diyar bikin ka hûn dixwazin kîjan karûbarê bişopînin û ji kîjan armancê re dixwazin. Mînakî, hûn dixwazin pergalek diyarkirî li Rûsya, Belarûs an Qazaxistanê bicîh bikin. Ji bo vê yekê, tenê yek ji parametreyan biguherînin, û hûn ê pelê veavakirina rast hebe.

Gava ku karûbarê Nomad jixwe li koma we hatî bicîh kirin, bi vî rengî xuya dike.

Pêşîn, hûn hewceyê cûreyek balansek li derve ne, ku dê hemî seyrûsefera bikarhêner werbigire. Ew ê bi Konsul re bi hev re bixebite û jê fêr bibe ku karûbarek taybetî ya ku bi navek domainek taybetî re têkildar e li ku derê, li ser kîjan nodê, li kîjan navnîşana IP-yê heye. Xizmetên li Konsulê ji Nomad bixwe tê. Ji ber ku ev hilberên heman pargîdaniyê ne, ew bi hevûdu re têkildar in. Em dikarin bibêjin ku Nomad li derveyî sindoqê dikare hemî karûbarên ku tê de hatine destpêkirin di hundurê Konsulê de tomar bike.

Gava ku balansa barkirina pêşîn a we zanibe ku dê ji kîjan karûbar re seyrûseferê bişîne, ew wê berbi konteynera guncan an pir konteynerên ku bi serîlêdana we re têkildar in dişîne. Bi xwezayî, pêdivî ye ku meriv li ser ewlehiyê jî bifikire. Her çend hemî karûbar li ser heman makîneyên virtual di konteyneran de têne xebitandin, ev bi gelemperî hewce dike ku pêşî li gihîştina belaş ji her karûbarek din bigire. Me ev yek bi parçekirinê pêk anî. Her karûbar di tora xweya virtual de hate destpêkirin, ku li ser wê rêgez û rêgezên rêgirtinê ji bo destûr / redkirina gihîştina pergal û karûbarên din hatine destnîşan kirin. Ew dikarin hem li hundurê vê komê û hem jî li derveyî wê bi cih bibin. Mînakî, heke hûn dixwazin rê li ber girêdana karûbarek bi databasek taybetî bigirin, ev dikare bi dabeşkirina asta torê were kirin. Ango, tewra bi xeletî, hûn nekarin bi xeletî ji hawîrdora ceribandinê bi databasa hilberîna xwe ve girêdin.

Di warê çavkaniyên mirovî de derbasbûnê çiqas mesrefa me kir?

Veguheztina tevahiya pargîdaniyê bo Nomad bi qasî 5-6 mehan girt. Em li ser bingehek karûbar-bi-karûbar, lê bi lezek pir bilez tevgeriyan. Her tîm neçar bû ku ji bo karûbaran konteynerên xwe biafirîne.

Me nêzîkatiyek wusa pejirand ku her tîm ji wêneyên docker ên pergalên xwe serbixwe berpirsiyar e. DevOps binesaziya giştî ya ku ji bo bicîhkirinê hewce dike peyda dike, ango piştgirî ji bo komê bixwe, piştgirî ji bo pergala CI, û hwd. Û wê demê zêdetirî 60 sîstemên me yên koçî Nomadê kiribûn, ku nêzîkî 2 hezar konteynir bûn.

Devops berpirsiyariya binesaziya giştî ya her tiştê ku bi danîn û pêşkêşkeran ve girêdayî ye berpirsiyar e. Û her tîmek pêşkeftinê, di encamê de, berpirsiyar e ku konteyneran ji bo pergala xweya taybetî bicîh bike, ji ber ku ew tîm e ku dizane bi gelemperî di konteynerek taybetî de çi hewce dike.

Sedemên terikandina Koçer

Di nav yên din de, me bi guheztina veguheztina bi karanîna Nomad û docker re çi feydeyên me girt?

1. Em in şert û mercên wekhev pêşkêş kirin ji bo hemî hawîrdoran. Di pêşkeftinê de, hawîrdora QA, pêş-hilberîn, hilberandin, heman wêneyên konteynerê, bi heman girêdanan têne bikar anîn. Li gorî vê yekê, hema tu şansê we tune ku ya ku dê di hilberînê de biqede ne ya ku we berê li herêmê an jî di hawîrdora ceribandina xwe de ceribandî ye.
2. Me jî dît ku bes e hêsan e ku meriv karûbarek nû lê zêde bike. Ji xala bicîhkirinê, her pergalên nû pir hêsan têne destpêkirin. Tenê biçin depoya ku mîhengan hildide, ji bo pergala xwe vesazkirinek din li wir zêde bike, û hûn hemî amade ne. Hûn dikarin pergala xwe bêyî hewildanek zêde ya devops li hilberînê bicîh bikin.
3. gişt pelên veavakirinê di depoyek hevpar de derket holê ku di bin çavan de ye. Di wê demê de ku me pergalên xwe bi karanîna pêşkêşkerên virtual bi kar anî, me Ansible bikar anî, ku tê de konfigurasyon di heman depoyê de bûn. Lêbelê, ji bo piraniya pêşdebiran ev kar hinekî dijwartir bû. Li vir qebareya mîheng û koda ku hûn hewce ne ku lê zêde bikin da ku karûbarê bicîh bikin pir piçûktir bûye. Zêdeyî, ji bo devops pir hêsan e ku wê rast bikin an biguhezînin. Di bûyera veguheztinê de, mînakî, guhertoyek nû ya Nomad, ew dikarin hemî pelên xebitandinê yên ku li heman cîhî ne bigirin û bi girseyî nûve bikin.

Lê em rastî çend kêmasiyan jî hatin:

Derket holê ku em nikarîbû bigihêje seferên bêkêmasî di meseleya Nomad de. Dema ku konteyneran di bin şert û mercên cihêreng de hildiweşîne, ew dikaribû bizivire, û Nomad ew wekî konteynirek amade kir ku seyrûseferê werbigire. Ev qewimî berî ku serîlêdana di hundurê wê de jî şansek dest pê bike. Ji ber vê yekê, pergalê ji bo demek kurt dest bi çêkirina 500 xeletiyan kir, ji ber ku seyrûsefer dest pê kir ber bi konteynirek ku hîna ne amade bû ku wê qebûl bike.

Em bi hinekan re hatin bugs. Xeletiya herî girîng ev e ku Nomad komek mezin pir baş rê nade ger ku we gelek pergal û konteynir hebin. Gava ku hûn dixwazin yek ji serverên ku di nav koma Nomad de ye ji bo lênihêrînê derxînin, îhtîmalek pir zêde heye ku kom pir xwe baş hîs neke û ji hev veqete. Mînakî, dibe ku hin konteynir dakevin û ne rabin - heke hemî pergalên hilberîna we di nav komek ku ji hêla Nomad ve tê rêvebirin de cîh bigirin ev ê paşê we pir biha bide.

Ji ber vê yekê me biryar da ku em bifikirin ku em ê paşê biçin ku derê. Di wê demê de, em pir bêtir agahdar bûn ku em dixwazin bigihîjin. Ango: em pêbaweriyê, fonksiyonên piçûktir ji ya ku Nomad peyda dike, û pergalek mazintir, aramtir dixwazin.

Di vî warî de, bijartina me ket ser Kubernetes wekî platforma herî populer a destpêkirina koman. Bi taybetî ku mezinahî û hejmara konteynerên me têra xwe mezin bû. Ji bo mebestên weha, Kubernetes pergala herî maqûl a ku em lê binihêrin xuya bû.

Veguhastina Kubernetes

Ez ê hinekî li ser têgînên bingehîn ên Kubernetes ji we re bibêjim û ew çawa ji Nomad cûda dibin.

Berî her tiştî, têgeha herî bingehîn a Kubernetes têgeha pod e. Pod komek ji yek an çend konteynerên ku her gav bi hev re dimeşin e. Û ew her gav mîna ku bi hişkî li ser yek makîneyek virtual dixebitin dixebitin. Ew bi IP 127.0.0.1 li ser portên cihêreng bi hevûdu re têne gihîştin.

Ka em texmîn bikin ku we serîlêdanek PHP-ê heye ku ji nginx û php-fpm pêk tê - pilana klasîk. Bi îhtîmalek mezin, hûn ê bixwazin ku her gav hem konteynerên nginx û php-fpm bi hev re bihêlin. Kubernetes dihêle hûn bi danasîna wan wekî yek podek hevpar vê yekê bi dest bixin. Ya ku me bi Nomad re nekarî bi dest bixista ev e.

Têgeha duyemîn e bicîh kirin. Rastî ev e ku pez bi xwe tiştek domdar e; dest pê dike û winda dibe. Ma hûn dixwazin pêşî hemî konteynerên xwe yên berê bikujin, û dûv re bi carekê ve guhertoyên nû bidin destpêkirin, an hûn dixwazin wan gav bi gav derxin? Ew diyar dike ku hûn çawa potanên xwe bi cîh dikin, bi çi qasê û çawa wan nûve dikin.

Têgeha sêyemîn e xizmetkar. Xizmeta we bi rastî pergala we ye, ku hin seyrûseferê werdigire û dûv re wê berbi yek an jî çend podên ku bi karûbarê we re têkildar in dişîne. Ango, ew dihêle hûn bibêjin ku hemî seyrûsefera hatina karûbarek wusa û bi navek wusa divê ji van podên taybetî re were şandin. Û di heman demê de ew ji we re hevsengiya trafîkê peyda dike. Ango, hûn dikarin du podên serîlêdana xwe bidin destpêkirin, û hemî seyrûsefera hatinê dê di navbera podên ku bi vê karûbarê ve girêdayî ne hevseng be.

Û çaremîn têgeha bingehîn e Ingress. Ev karûbarek e ku li ser komek Kubernetes dimeşîne. Ew wekî balansek barkirina derveyî ya ku hemî daxwazan digire tevdigere. Bi karanîna Kubernetes API-ê, Ingress dikare diyar bike ku divê ev daxwaz li ku derê bêne şandin. Wekî din, ew vê yekê pir nerm dike. Hûn dikarin bibêjin ku hemî daxwaznameyên vê mêvandar û URL-ya wusa û wusa ji vê karûbarê re têne şandin. Û ev daxwazên ku ji vê mêvandar û URL-a din re têne şandin ji karûbarek din re têne şandin.

Tiştê herî xweş ji nihêrîna kesê ku serîlêdanek pêşdixe ev e ku hûn bi xwe dikarin wê hemî rêve bibin. Bi danîna konfigurasyona Ingress, hûn dikarin hemî seyrûsefera ku tê API-ya wusa û wusa bişînin da ku ji hev veqetînin konteynerên ku, mînakî, di Go de hatine nivîsandin. Lê ev seyrûsefer, ku tê heman domainê, lê ji URLek cûda re, divê were şandin konteynerên ku bi PHP-ê hatine nivîsandin, ku tê de gelek mantiq heye, lê ew ne pir bilez in.

Ger em van hemû têgehan bi Nomad re bidin ber hev, em dikarin bibêjin ku sê têgînên pêşîn tev bi hev re Xizmet in. Û konsepta dawî di nav Nomad bixwe de tune ye. Me balansek derveyî wekî wê bikar anî: ew dikare haproxy, nginx, nginx+, û hwd. Di mijara kubê de, hûn ne hewce ne ku hûn vê têgeha zêde ji hev cuda bidin nasîn. Lêbelê, heke hûn li hundurê Ingress binêrin, ew an nginx, haproxy, an traefik e, lê bi rengek Kubernetes hatî çêkirin.

Hemî têgehên ku min diyar kir, bi rastî, çavkaniyên ku di nav komek Kubernetes de hene hene. Ji bo danasîna wan di kubê de, formatek yaml tê bikar anîn, ku ji pelên HCL-ê di doza Nomad de xwendîtir û nastir e. Lê ji hêla strukturî ve ew heman tiştî di doza, mînakî, pod de vedibêjin. Dibêjin - Ez dixwazim filan û wîn li wir, bi wêne û wêneyan, bi qas û bi vî rengî bi cih bikim.

Wekî din, me fêm kir ku me nedixwest ku her çavkaniyek kesane bi destan biafirînin: bicîhkirin, karûbar, Ingress, hwd. Di şûna wê de, me xwest ku em her pergalên xwe bi Kubernetes-ê di dema bicîhkirinê de binav bikin, da ku em neçar bimînin ku bi destan hemî girêdanên çavkaniyê yên pêwîst di rêza rast de ji nû ve biafirînin. Helm wekî pergala ku destûr da me ev hat hilbijartin.

Têgehên bingehîn li Helm

Helm e rêveberê pakêtê ji bo Kubernetes. Ew pir dişibihe ka rêvebirên pakêtê yên di zimanên bernamekirinê de çawa dixebitin. Ew dihêlin ku hûn karûbarek ku ji, mînakî, bicihkirina nginx, bicihkirina php-fpm, veavakirina ji bo Ingress, configmaps pêk tê hilînin (ev saziyek e ku dihêle hûn env û pîvanên din ji bo pergala xwe bicîh bikin) bi vî rengî- bi navê charts. Di heman demê de Helm li ser Kubernetes direve. Ango, ev ne celebek pergalek e ku li kêlek sekinî ye, lê tenê karûbarek din e ku di hundurê kubê de hatî destpêkirin. Hûn bi API-ya wê re bi fermanek konsolê pê re têkilî daynin. Rehetî û bedewiya wê ev e ku her çend helm bişkîne an hûn wê ji komê derxînin, dê karûbarên we winda nebin, ji ber ku helm bi bingehîn tenê ji bo destpêkirina pergalê kar dike. Kubernetes bixwe wê hingê berpirsiyar e ji performans û rewşa karûbaran.

Me jî pê hesiya şablonkirin, ya ku em berê neçar bûn ku em bixwe bikin bi danasîna jinja di mîhengên xwe de, yek ji taybetmendiyên sereke yên helmê ye. Hemî mîhengên ku hûn ji bo pergalên xwe diafirînin di helmê de di forma şablonan de têne hilanîn, hinekî dişibin jinja, lê, bi rastî, şablona zimanê Go, ku tê de helm tê nivîsandin, mîna Kubernetes bikar tînin.

Helm çend têgehên din ji me re zêde dike.

Qebale - ev danasîna xizmeta we ye. Di rêveberên pakêtê yên din de wê jê re pakêtek, pakêt an tiştek mîna wî tê gotin. Li vir jê re chart tê gotin.

Nirxên guhêrbarên ku hûn dixwazin bikar bînin da ku mîhengên xwe ji şablonan ava bikin in.

Berdan. Her carê ku karûbarek ku bi karanîna helmê tête bicîh kirin guhertoyek zêde ya berdanê werdigire. Helm bi bîr tîne ku konfigurasyona karûbarê di berdana berê de, berdana berî wê, û hwd. Ji ber vê yekê, heke hûn hewce ne ku paşde bizivirin, tenê fermana vegerandina bangê ya helmê bimeşînin, wê nîşan bidin guhertoya berdana berê. Tewra ku veavakirina têkildar a di depoya we de di dema vegerandinê de peyda nebe jî, helm dê dîsa jî bi bîr bîne ku ew çi bû û dê pergala we vegerîne rewşa ku di berdana berê de tê de bû.

Di doza ku em helm bikar tînin, vesazên birêkûpêk ji bo Kubernetes di heman demê de vediguhere şablonan ku tê de gengaz e ku meriv guhêrbar, fonksiyonan bikar bîne û daxuyaniyên şertî bicîh bîne. Bi vî rengî hûn dikarin konfigurasyona karûbarê xwe li gorî jîngehê berhev bikin.

Di pratîkê de, me biryar da ku em tiştan ji ya ku bi Nomad re kir hinekî cûdatir bikin. Ger di Nomad de hem mîhengên bicîhkirinê û hem jî n-guhêrbarên ku ji bo bicihkirina karûbarê me hewce bûn di depoyek de hatin hilanîn, li vir me biryar da ku em wan li du depoyên cihê dabeş bikin. Depoya "deploy" tenê n-guhêrbarên ku ji bo bicîhkirinê hewce ne diparêze, û depoya "helm" mîheng an nexşeyan hildide.

Vê yekê çi da me?

Tevî vê rastiyê ku em di pelên mîhengê bixwe de daneyên bi rastî hesas hilnagirin. Mînakî, şîfreyên databases. Ew di Kubernetes de wekî veşartî têne hilanîn, lê dîsa jî, hîn jî hin tişt li wir hene ku em naxwazin her kes bigihîje wan. Ji ber vê yekê, gihîştina depoya "deploy" tixûbdartir e, û depoya "helm" bi tenê ravekirina karûbarê vedihewîne. Ji ber vê sedemê, ew dikare ji hêla gelek kesan ve bi ewlehî bigihîje.

Ji ber ku me ne tenê hilberandin, lê di heman demê de jîngehên din jî hene, bi saya vê veqetandinê em dikarin nexşeyên xwe yên helmê ji nû ve bikar bînin da ku karûbaran ne tenê ji hilberînê re, lê di heman demê de, mînakî, ji hawîrdorek QA-yê re jî bicîh bikin. Tewra ku wan bi karanîna herêmî bicîh bikin Minikube - ev tiştek ji bo xebitandina Kubernetes li herêmî ye.

Di hundurê her depoyê de, me ji bo her karûbar dabeşek li pelrêçiyên cihêreng hiştin. Ango, di hundurê her pelrêçekê de şablonên bi nexşeya têkildar ve girêdayî ne û çavkaniyên ku hewce ne ku werin bicîh kirin ji bo destpêkirina pergala me diyar dikin. Me tenê env di depoya "deploy" de hiştin. Di vê rewşê de, me bi karanîna jinja şablon bikar neanî, ji ber ku helm bixwe şablonê ji qutiyê peyda dike - ev yek ji fonksiyonên wê yên sereke ye.

Me skrîptek bicîhkirinê hişt - deploy.sh, ku destpêkirina ji bo bicîhkirinê bi karanîna helmê hêsan dike û standardîze dike. Ji ber vê yekê, ji bo her kesê ku dixwaze bi cih bike, pêwendiya bicîhkirinê tam mîna ku dema ku bi navgîniya Nomad ve hatî bicîh kirin xuya dike. Heman deploy.sh, navê karûbarê we, û cihê ku hûn dixwazin wê bicîh bikin. Ev dibe sedem ku helm di hundurê de dest pê bike. Ew, di encamê de, mîhengan ji şablonan berhev dike, pelên nirxên pêwîst têxe nav wan, dûv re wan bi cih dike, wan di Kubernetes de dide destpêkirin.

vebiguherin

Karûbarê Kubernetes ji Nomad tevlihevtir xuya dike.

Li vir seyrûsefera derketinê tê Ingress. Ev tenê kontrolkerê pêşîn e, ku hemî daxwazan digire û dûv re wan dişîne karûbarên ku bi daneyên daxwazê ​​re têkildar in. Ew wan li ser bingeha mîhengên ku beşek ji danasîna serîlêdana we ya di helmê de ne û yên ku pêşdebiran bi serê xwe saz dikin destnîşan dike. Karûbar daxwazan dişîne ser podên xwe, ango konteynerên taybetî, seyrûsefera hatinê di navbera hemî konteynerên ku girêdayî vê karûbarê ne hevseng dike. Û, bê guman, divê em ji bîr nekin ku divê em ji ewlehiyê di asta torê de neçin cîhek. Ji ber vê yekê, dabeşkirin di komek Kubernetes de, ku li ser bingeha nîşankirinê ye, dixebite. Hemî karûbar xwedan hin nîşanan in ku mafên gihîştina karûbaran ji hin çavkaniyên derveyî / hundurîn ên li hundur an derveyî komê re têkildar in.

Gava ku me veguheztin kir, me dît ku Kubernetes xwediyê hemî kapasîteyên Nomad bû, ku me berê bikar anîbû, û her weha gelek tiştên nû lê zêde kirin. Ew dikare bi pêvekan, û bi rastî jî bi cûreyên çavkaniyên xwerû ve were berfireh kirin. Ango, we fersendek heye ku ne tenê tiştek ku bi Kubernetes re ji qutikê tê bikar bînin, lê çavkanî û karûbarê xwe biafirînin ku dê çavkaniya we bixwîne. Ev ji we re vebijarkên din dide ku hûn pergala xwe berfireh bikin bêyî ku hûn Kubernetes ji nû ve saz bikin û bêyî hewcedariya guheztinê.

Mînaka karanîna weha Prometheus e, ku di hundurê koma meya Kubernetes de derbas dibe. Ji bo ku ew dest bi berhevkirina metrîkên ji karûbarek taybetî bike, pêdivî ye ku em celebek çavkaniyek din, bi navê çavdêriya karûbarê, li danasîna karûbarê zêde bikin. Prometheus, ji ber vê yekê ku ew dikare cûreyek çavkaniyek xwerû bixwîne dema ku li Kubernetes were destpêkirin, bixweber dest bi berhevkirina metrîkan ji pergala nû dike. Ew pir rehet e.

Yekem şandina ku me li Kubernetes çêkir di Adara 2018 de bû. Û di vê demê de me tu carî pirsgirêk bi wê re nedît. Ew bêyî xeletiyên girîng bi domdarî dixebite. Herweha, em dikarin wê bêtir berfireh bikin. Îro em têra xwe ji kapasîteyên wê hene, û em bi rastî ji leza pêşkeftina Kubernetes hez dikin. Niha, zêdetirî 3000 konteynir li Kubernetes hene. Komek çend Nod dagir dike. Di heman demê de, ew karûbar, stabîl û pir kontrol e.

Source: www.habr.com