Përshëndetje gjithëve! Emri im është Pavel Agaletki. Unë punoj si lider i ekipit që zhvillon sistemin e shpërndarjes së Lamoda. Në vitin 2018, kam marrë pjesë në konferencën HighLoad++, dhe sot dua të paraqes transkriptin e prezantimit tim.
Tema ime i dedikohet përvojës së kompanisë sonë për shpërndarjen e sistemeve dhe shërbimeve në ambiente të ndryshme. Duke filluar nga koha jonë prehistorike, kur ne shpërndanim të gjitha sistemet në servera virtualë të zakonshëm, deri në kalimin graduel nga Nomad në shpërndarjen në Kubernetes. Do të flas për arsyet pse e bëmë këtë dhe për problemet që patëm gjatë procesit.
Shpërndarja e aplikacioneve në VM
Fillimisht, para 3 vjetĂ«sh, tĂ« gjitha sistemet dhe shĂ«rbimet e kompanisĂ« u vendosĂ«n nĂ« serverĂ« virtualĂ« tĂ« zakonshĂ«m. Teknikisht, ishte organizuar nĂ« mĂ«nyrĂ« qĂ« tĂ« gjithĂ« kodi i sistemeve tona tĂ« ruhej dhe tĂ« ndĂ«rtohej nĂ«pĂ«rmjet mjeteve tĂ« automatizimit, duke pĂ«rdorur jenkins. Me anĂ« tĂ« Ansible, ai shpĂ«rndahej nga sistemi ynĂ« i kontrollit tĂ« versioneve nĂ« serverĂ«t virtualĂ«. Ădo sistem qĂ« kishte kompaninĂ« tonĂ« u vendos nĂ« tĂ« paktĂ«n 2 serverĂ«: njĂ«ri prej tyre ishte head, ndĂ«rsa tjetra ishte tail. KĂ«to dy sisteme ishin plotĂ«sisht identike nĂ« tĂ« gjitha parametrat, fuqinĂ«, konfigurimin dhe tĂ« tjera. Diferenca mes tyre ishte vetĂ«m se head merrte trafik pĂ«rdoruesish, ndĂ«rsa tail kurrĂ« nuk merrte trafik pĂ«rdoruesish mbi vete.
Për çfarë ishte bërë kjo?
Kur ne bëmë deploy-in e lëshimeve të reja të aplikacionit tonë, dëshironim të siguroheshim për një kalim pa probleme, pa pasur pasoja të dukshme për përdoruesit. Kjo arrihej përmes lançimit të një lëshimi të ndërtuar me Ansible në tail. Aty, ata që merreshin me deploy-in mund të kontrollonin dhe të siguroheshin që gjithçka ishte në rregull: të gjitha metrikat, seksionet dhe aplikacionet funksiononin; skenaret e nevojshme fillonin. Vetëm pas konfirmimit që gjithçka ishte në rregull, trafiku do të kalonte. Ai fillonte të shkonte në atë server që më parë ishte tail. Ai që më parë ishte head, mbetej pa trafik përdoruesish, përveç versionit të mëparshëm të aplikacionit tonë që kishte mbi të.
KĂ«shtu, pĂ«r pĂ«rdoruesit, kjo ishte pa probleme. Sepse kalimi ishte ĐŒĐŸĐŒĐ”ĐœŃal, pasi ishte thjesht njĂ« kalim i balancuesit. Mjafton tĂ« ktheheshim nĂ« versionin e mĂ«parshĂ«m, thjesht duke e kthyer balancuesin mbrapsht. Gjithashtu mundĂ«m tĂ« siguroheshim pĂ«r kapacitetin e aplikacionit nĂ« prodhim edhe para se tĂ« fillonte trafik pĂ«rdoruesish, qĂ« ishte shumĂ« e pĂ«rshtatshme.
ĂfarĂ« pĂ«rfitimesh pamĂ« nĂ« gjithĂ« kĂ«tĂ«?
- Para fillin, është mjaft thjesht funksionon. Të gjithëve u është e qartë se si funksionon një sistem i tillë implementimi, sepse shumica e njerëzve ndonjëherë e kanë implementuar në servera virtualë të zakonshëm.
- Kjo Ă«shtĂ« mjaft e besueshme, pasi teknologjia e implementimit Ă«shtĂ« e thjeshtĂ«, e provuar nga mijĂ«ra kompani. Miliona servera implementohen nĂ« kĂ«tĂ« mĂ«nyrĂ«. ĂshtĂ« e vĂ«shtirĂ« ta dĂ«mtojmĂ« diçka.
- Dhe në fund, ne mundëm të merrnim implementime atomike. Implementime, të cilat për përdoruesit ndodhin njëkohësisht, pa një fazë të dukshme kalimi midis versionit të vjetër dhe atij të ri.
Por në gjithë këtë ne gjithashtu pamë disa disavantazhe:
- PĂ«rveç mjedisit tĂ« prodhimit, ka edhe mjedise zhvillimi tĂ« tjera. PĂ«r shembull, qa dhe para-prodhim. NĂ« atĂ« kohĂ«, kishim shumĂ« servera dhe rreth 60 shĂ«rbime. PĂ«r kĂ«tĂ« arsye duhej tĂ« mbajmĂ« njĂ« version tĂ« pĂ«rditĂ«suar pĂ«r secilin shĂ«rbim. makinĂ«s virtuale. NĂ« rast se dĂ«shironi tĂ« pĂ«rditĂ«soni bibliotekat ose tĂ« instaloni varĂ«si tĂ« reja, duhet tâi bĂ«ni kĂ«to nĂ« tĂ« gjitha ambientet. Gjithashtu, duhet tĂ« sinkronizoni orarin kur planifikoni tĂ« lançoni versionin e ri tĂ« aplikacionit tuaj me kohĂ«n kur devops do tĂ« kryejĂ« konfigurimet e nevojshme tĂ« ambientit. NĂ« kĂ«tĂ« rast, Ă«shtĂ« e lehtĂ« tĂ« pĂ«rfundoni nĂ« njĂ« situatĂ« ku ambientet do tĂ« ndryshojnĂ« ndjeshĂ«m menjĂ«herĂ« nĂ« tĂ« gjitha ambientet. PĂ«r shembull, nĂ« ambientin QA do tĂ« ketĂ« versione tĂ« ndryshme tĂ« bibliotekave, ndĂ«rsa nĂ« prodhim do tĂ« jenĂ« tĂ« tjera, gjĂ« qĂ« do tĂ« çojĂ« nĂ« probleme.
- Vështirësia në përditësimin e varësive të aplikacionit tuaj. Kjo nuk varet nga ju, por nga një tjetër ekip. Ata janë ekipi i devops, i cili mbështet serverat. Duhet t'i jepni atyre një detyrë përkatëse dhe të jepni një përshkrim të asaj që dëshironi të bëni.
- Në atë kohë, ne gjithashtu dëshironim të ndanin monolitët tanë të mëdhenj në shërbime të veçanta të vogla, pasi kuptonim se do të kishte gjithnjë e më shumë prej tyre. Në atë fazë, ne tashmë kishim më shumë se 100 shërbime të tilla. Ishte e nevojshme të krijonim një makinë virtuale të re për çdo shërbim të ri, e cila gjithashtu duhej mirëmbajtur dhe vendosur. Përveç kësaj, ne na nevojiteshin të paktën dy makina. Kësaj i shtohet gjithashtu një mjedis të QA-së. Kjo shkakton probleme dhe e bën krijimin dhe lançimin e sistemeve të reja për ju më të ndërlikuar, të shtrenjtë dhe të gjatë.
Prandaj, ne morëm vendimin se do të ishte më e lehtë të kalonim nga vendosja e makinave virtuale të zakonshme në vendosjen e aplikacioneve tona në kontejnerin docker. Me praninë e docker-it, na nevoitet një sistem që mund të lançojë aplikacionin në një klaster, pasi nuk mund të ngrini thjesht një kontejner. Zakonisht dëshirojmë të ndjekim se sa kontejnerë janë ngritur, që ata të ngrihen automatikisht. Për këtë arsye, na duhej të zgjidhim një sistem menaxhimi.
Kemi menduar pĂ«r njĂ« kohĂ« tĂ« gjatĂ« se cilin variant tĂ« zgjidhim. Problemi Ă«shtĂ« se nĂ« atĂ« kohĂ« ky stack i deploy-it nĂ« serverat virtualĂ« tĂ« zakonshĂ«m ishte disi i vjetruar, pasi kishte versione jo tĂ« reja tĂ« sistemeve operative. NĂ« njĂ« moment atje madje kishte FreeBSD, e cila ishte pak e vĂ«shtirĂ« pĂ«r tâu mbĂ«shtetur. Ne kuptonim se duhej tĂ« migronim sa mĂ« shpejt nĂ« docker. DevOps-Ă«t tanĂ« e shqyrtuan pĂ«rvojĂ«n e tyre me zgjidhje tĂ« ndryshme dhe zgjodhĂ«n njĂ« sistem si Nomad.
Kalimi në Nomad
Nomad â Ă«shtĂ« njĂ« produkt i kompanisĂ« âHashiCorpâ. Ata janĂ« gjithashtu tĂ« njohur pĂ«r zgjidhjet e tjera:
«Consul» â Ă«shtĂ« njĂ« mjet pĂ«r zbulimin e shĂ«rbimeve.
«Terraform» â Ă«shtĂ« njĂ« sistem pĂ«r menaxhimin e serverĂ«ve, i cili ju lejon tâi konfiguroni ato nĂ«pĂ«rmjet njĂ« konfigurimi, tĂ« njohur si infrastructure-as-a-code.
«Vagrant» lejon të zhvilloni makina virtuale lokalish ose në cloud përmes disa skedave konfigurimi.
Nomad na atë moment dukej një zgjidhje mjaft e thjesht për të cilën mund të kaloni shpejt pa ndryshuar tërë infrastrukturën. Për më tepër, është mjaft e lehtë për t'u zotëruar. Prandaj, ne e zgjodhëm atë si sistemin e filtrimit për kontejnerin tonë.
ĂfarĂ« nevojitet pĂ«r tĂ« shpĂ«rndarĂ« sistemin tuaj nĂ« Nomad?
- SĂ« pari, nevojitet docker image i aplikacionit tuaj. ĂshtĂ« e nevojshme ta ndĂ«rtoni atĂ« dhe ta vendosni nĂ« depozitat e imazheve docker. NĂ« rastin tonĂ«, kjo Ă«shtĂ« artifactory â njĂ« sistem qĂ« lejon tĂ« shtoni nĂ« tĂ« artefakte tĂ« ndryshme tĂ« llojeve tĂ« ndryshme. Ajo ka aftĂ«sinĂ« tĂ« ruajĂ« arkiva, imazhe docker, pacakĂ« composer PHP, pacakĂ« NPM dhe kĂ«shtu me radhĂ«.
- Gjithashtu është e nevojshme konfigurues, i cili do t'i tregojë Nomad se çfarë, ku dhe në cilat sasi dëshironi të shpërndani.
Kur flasim për Nomad, formati i skedarit informativ përdor gjuhën HCL, e cila shkruhet si HashiCorp Configuration Language. Kjo është një nëngrup mbi Yaml, që ju lejon të përshkruani shërbimin tuaj në terma të Nomad.
Ai lejon të thuash sa kontejnerë dëshiron të deploosh, nga cilat imazhe t'i kalosh atyre parametrat e ndryshëm gjatë deplikimit. Kështu, e ushqen këtë skedë Nomad, dhe ai fillon kontejnerët në përputhje me të në produksion.
NĂ« rastin tonĂ«, ne kuptuam se thjesht tĂ« shkruash skedarĂ« HCL identik pĂ«r çdo shĂ«rbim nuk do tĂ« ishte shumĂ« e pĂ«rshtatshme, sepse kemi shumĂ« shĂ«rbime dhe ndonjĂ«herĂ« duam tâi pĂ«rditĂ«sojmĂ« ato. NdonjĂ«herĂ« ndodh qĂ« njĂ« shĂ«rbim Ă«shtĂ« deploar jo si njĂ« kopje, por nĂ« varianta tĂ« ndryshme. PĂ«r shembull, njĂ« nga sistemet qĂ« kemi nĂ« produksion ka mĂ« shumĂ« se 100 instanca nĂ« prodhim. Ato nisin nga tĂ« njĂ«jtat imazhe, por ndryshojnĂ« nĂ« konfigurimet dhe skedarĂ«t e konfigurimit.
Prandaj vendosĂ«m qĂ« tĂ« ishte e pĂ«rshtatshme tĂ« ruanim tĂ« gjitha skedat tona konfiguruese pĂ«r zhvillimin nĂ« njĂ« depo tĂ« pĂ«rbashkĂ«t. KĂ«shtu, ato bĂ«heshin tĂ« lexueshme: ishte e lehtĂ« t'i mbash dhe mund tĂ« shihje se cilat sisteme kishim. NĂ« rast nevoje, gjithashtu nuk ishte e vĂ«shtirĂ« tĂ« pĂ«rditĂ«soje ose tĂ« ndryshoje diçka. Shtimi i njĂ« sistemi tĂ« ri gjithashtu nuk do tĂ« ishte e vĂ«shtirĂ« â mjafton tĂ« krijosh njĂ« skedĂ« konfiguruese brenda njĂ« katalogu tĂ« ri. Brenda saj ndodhen skedat: service.hcl, qĂ« pĂ«rmban pĂ«rshkrimin e shĂ«rbimit tonĂ«, dhe disa skeda env, qĂ« lejojnĂ« qĂ« ky shĂ«rbim, kur Ă«shtĂ« vendosur nĂ« prodhim, tĂ« konfigurohet.
Megjithatë, disa nga sistemet tona janë vendosur në prodhim jo në një ekzemplar, por në disa menjëherë. Prandaj vendosëm që të ishte më e përshtatshme të ruanim jo konfigurimet në formën e tyre të pastër, por pamjen e tyre të templatuar. Dhe si gjuhë templatuar ne zgjodhëm jinja 2. Në këtë format ruhen si konfigurimet e shërbimit vetë, ashtu edhe skedat env që nevojiten për të.
Përveç kësaj, ne kemi vendosur në depo një skript-deploy të përbashkët për të gjitha projektet, i cili lejon që të lançoni dhe të deployoni shërbimin tuaj në prodhim, në ambientin e duhur, në targetin e duhur. Në rastin kur e kemi kthyer konfigurimin tonë HCL në një shabllon, atëherë ai HCL-fail që më parë ishte një konfigurim i zakonshëm Nomad, tani duket ndryshe.
Do të thotë se ne kemi zëvendësuar disa variabla të konfigurimit me insertime variablash, të cilat merren nga skedarët env ose nga burime të tjera. Përveç kësaj, kemi fituar mundësinë për të ndërtuar dinamike HCL-failat, që do të thotë se mund të aplikojmë jo vetëm insertime të zakonshme variablash. Duke qenë se jinja mbështet ciklet dhe kushtet, aty gjithashtu mund të krijohen skedarë konfigurimi që ndryshojnë në varësi të vendndodhjes ku po deployoni aplikacionet tuaja.
Për shembull, do të dëshironit të deploy shërbimin tuaj në preprod-hap dhe në prod-hap. Le të themi se në preprod-hap nuk doni të vendosni skriptet cron, por thjesht dëshironi të shihni shërbimin në një domen të veçuar, për të siguruar që ai funksionon. Për këdo që deploy shërbimin, procesi duket shumë i thjeshtë dhe i qartë. Mjafton të ekzekutoni skedarin deploy.sh, të tregoni se cili shërbim dëshironi të deploy dhe në cilin target. Për shembull, dëshironi të deploy një sistem në Rusi, Bjellorusi ose Kazakistan. Mjafton të ndryshoni një nga parametrat, dhe do të krijohet skedari i duhur i konfigurimit.
Kur shërbimi Nomad është deploy dhe ndodhet në klusterin tuaj, ai duket si më poshtë.
Në fillim, ju nevojitet një load balancer jashtë, i cili do të pranojë të gjithë trafikun e përdoruesve. Ai do të punojë së bashku me Consul dhe do të mësojë prej tij se ku, në cilën nod, sipas cilit adresën IP ekziston një shërbim specifik që korrespondon me një emër domaini të caktuar. Shërbimet në Consul shfaqen nga Nomad. Duke qenë se këto janë produkte të të njëjtit kompani, ato janë të lidhura mirë me njëra-tjetrën. Mund të thuhet se Nomad, nga vetë natyra, di të regjistrojë të gjitha shërbimet që fillohen në të brenda Consul.
Pasi qĂ« balancuesi juaj i jashtĂ«m tĂ« mĂ«sojĂ« se nĂ« cilin shĂ«rbim duhet tĂ« dĂ«rgojĂ« trafik, ai e drejton atĂ« nĂ« kontejnerin pĂ«rkatĂ«s ose nĂ« disa kontejnerĂ« qĂ« i pĂ«rkasin aplikacionit tuaj. Natyrisht, gjatĂ« kĂ«tij procesi duhet tĂ« mendojmĂ« gjithashtu pĂ«r sigurinĂ«. PavarĂ«sisht se tĂ« gjitha shĂ«rbimet ekzekutohen nĂ« tĂ« njĂ«jtin makinĂ« virtuale nĂ« konteinerĂ«, zakonisht kĂ«rkohet tĂ« ndalohet qasja e lirĂ« nga çdo shĂ«rbim nĂ« ndonjĂ« shĂ«rbim tjetĂ«r. Ne e arritĂ«m kĂ«tĂ« pĂ«rmes segmentimit. Ădo shĂ«rbim ekzekutohej nĂ« rrjetin e tij virtual, ku ishin tĂ« pĂ«rcaktuara rregullat e ruteve dhe rregullat pĂ«r lejesh/enjohje pĂ«r qasje nĂ« sistemet dhe shĂ«rbimet e tjera. Ato mund tĂ« ishin brenda kĂ«tij klasteri ose jashtĂ« tij. PĂ«r shembull, nĂ«se dĂ«shironi tĂ« ndaloni njĂ« shĂ«rbim qĂ« tĂ« lidhet me njĂ« bazĂ« tĂ« dhĂ«nash tĂ« caktuar, kjo mund tĂ« bĂ«het nĂ«pĂ«rmjet segmentimit nĂ« nivelin e rrjetit. Pra, as pĂ«r shkak tĂ« njĂ« gabimi, nuk mund tĂ« lidhesh rastĂ«sisht nga mjedisi i testimit me bazĂ«n tuaj tĂ« dhĂ«nash tĂ« prodhimit.
Sa na ka kushtuar procesi i kalimit në aspektin e burimeve njerëzore?
Kalon 5-6 muaj ka zgjatur kalimi i gjithĂ« kompanisĂ« nĂ« Nomad. Ne kaluam shĂ«rbim pas shĂ«rbimi, por me njĂ« ritĂ«m mjaft tĂ« shpejtĂ«. Ădo ekip duhej tĂ« krijonte kontejnerĂ«t e vet pĂ«r shĂ«rbimet.
Ne kemi pranuar një qasje të tillë, që çdo ekip është përgjegjës për imazhet docker të sistemeve të tij vetjakisht. DevOps-i siguron infrastrukturën e përbashkët të nevojshme për vendosjen, që do të thotë mbështetje të vetë klasterit, përkrahjen e sistemit CI dhe kështu me radhë. Dhe në atë kohë, mbi 60 sisteme ishin transferuar në Nomad, duke rezultuar në rreth 2,000 kontejnerë.
DevOps-i është përgjegjës për infrastrukturën e përgjithshme të gjithçkaje që lidhet me vendosjen, me serverët. Ndërsa çdo ekip zhvillimi është përgjegjës për realizimin e kontejnerëve për sistemin e tyre specifik, pasi ekipi vetë e di se çfarë i nevojitet në atë apo këtë kontejner.
Arsyet për heqjen dorë nga Nomad
ĂfarĂ« pĂ«rfitimesh fituam duke kaluar nĂ« vendosjen me ndihmĂ«n e Nomad dhe docker-it po ashtu?
- Ne siguruam kushte të njëjta për të gjitha mjediset. Në zhvillim, ambientin e QA, para-prodhim, prodhim përdoren të njëjtat imazhe të kontejnerëve, me të njëjtat varësi. Si pasojë, ju nuk keni pothuajse asnjë shans që në prodhim të dalë ndonjë gjë që keni testuar më parë lokalisht ose në ambientin e testimit.
- Po ashtu, ne e zbuluam se mjafton lehtĂ« tĂ« shtoni njĂ« shĂ«rbim tĂ« ri. Ădo sistem i ri nga kĂ«ndvĂ«shtrimi i shpĂ«rndarjes fillon shumĂ« thjesht. Mjafton tĂ« shkoni nĂ« depo, qĂ« ruan konfigurimet, tĂ« shtoni aty njĂ« konfigurim tĂ« ri pĂ«r sistemin tuaj, dhe jeni gjithçka gati. Ju mund tĂ« shpĂ«rndani sistemin tuaj nĂ« prodhim pa pĂ«rpjekje tĂ« tjera nga DevOps.
- Të gjitha skedarët e konfigurimit në një depo të përbashkët u vunë në rregull. Në momentin kur po shpërndanim sistemet tona duke përdorur serverëve virtualë, ne kemi përdorur Ansible, ku konfigurimet ndodheshin në të njëjtin depo. Megjithatë, për shumicën e zhvilluesve, kishte disa vështirësi për të punuar me të. Këtu, volumi i konfigurimeve dhe kodit që ju nevojitet për të shpërndarë shërbimin ka rënë në mënyrë të konsiderueshme. Plus, për DevOps është shumë e lehtë të ndryshojë ose të modifikojë atë. Në rastin e kalimeve, për shembull, për një version të ri të Nomad, ata mund të marrin dhe të përditësojnë masivisht të gjitha skedarët operativë që ndodhen në të njëjtin vend.
Por ne gjithashtu u përballëm me disa mangësi:
Doli se ne nuk arritëm të arrijmë pa probleme në shpërndarje në rastin e Nomad. Kur konteinerët u lançuan nga kushte të ndryshme, mund të ndodhte që ai të ishte aktiv, dhe Nomad e perceptonte atë si gati për të pranuar trafik. Kjo ndodhte para se aplikacioni brenda tij të kishte kohë të aktivizohej. Për këtë arsye, sistemi fillonte të jepte gabime 500, sepse trafiku fillonte të drejtohej në konteinerin që ende nuk ishte gati ta priste.
Ne pĂ«rjetuam disa defekte. Problemi mĂ« i rĂ«ndĂ«sishĂ«m Ă«shtĂ« se Nomad nuk e menaxhon mirĂ« njĂ« klaster tĂ« madh nĂ«se keni shumĂ« sisteme dhe kontejnerĂ«. Kur dĂ«shironi tĂ« nxirrni nĂ« shĂ«rbim njĂ« nga serverĂ«t qĂ« Ă«shtĂ« pjesĂ« e klasterit Nomad, ka njĂ« probabilitet tĂ« konsiderueshĂ«m qĂ« klasteri tĂ« ndjehet keq dhe tĂ« shpĂ«rbĂ«het. Disa kontejnerĂ« mund, pĂ«r shembull, tĂ« bien dhe tĂ« mos ngrihen mĂ« â kjo do t'ju kushtojĂ« shumĂ«, nĂ«se tĂ« gjithĂ« sistemet tuaja prodhuese ndodhen nĂ« klasterin e menaxhuar nga Nomad.
Prandaj, ne vendosëm të mendojmë se ku duam të shkojmë më tej. Në atë kohë, ne filluam të kuptojmë më mirë se çfarë donim të arrinim. Domethënë: kemi nevojë për besueshmëri, pak më shumë funksionalitet se sa ofron Nomad, dhe një sistem më të pjekur dhe më të qëndrueshëm.
Në këtë kuptim, ne zgjedhëm Kubernetes si platformën më të njohur për të drejtuar klasterët. Sidomos duke marrë parasysh se madhësia dhe numri i kontejnerëve tanë ishin mjaft të mëdha. Për këtë qëllim, Kubernetes na duket sistemi më i përshtatshëm nga ato që kishim shqyrtuar.
Kalimi në Kubernetes
Do të flas pak rreth konceptëve të bazës së Kubernetes dhe se si ndryshojnë nga Nomad.
SĂ« pari, koncepti mĂ« themelor nĂ« Kubernetes Ă«shtĂ« koncepti i pod. Pod â Ă«shtĂ« njĂ« grup i njĂ« ose mĂ« shumĂ« kontejnerĂ«ve qĂ« gjithmonĂ« fillojnĂ« sĂ« bashku. Dhe ata punojnĂ« sikur tĂ« ishin gjithmonĂ« nĂ« njĂ« makinĂ« virtuale. Ata janĂ« tĂ« aksesueshĂ«m njĂ«ri nga tjetri me adresĂ«n IP 127.0.0.1 nĂ« porta tĂ« ndryshme.
Supozoni se keni njĂ« aplikacion PHP qĂ« pĂ«rbĂ«het nga nginx dhe php-fpm â njĂ« skemĂ« klasike. NĂ« tĂ« gjitha gjasat, do tĂ« dĂ«shironit qĂ« kontejnerĂ«t nginx dhe php-fpm tĂ« ishin gjithmonĂ« sĂ« bashku. Kubernetes lejon qĂ« kjo tĂ« arrihet duke i pĂ«rshkruar ato si njĂ« pod tĂ« pĂ«rbashkĂ«t. Kjo Ă«shtĂ« ajo qĂ« ne nuk mund ta marrim me Nomad.
Koncepti i dytĂ« Ă«shtĂ« deployment. Faktikisht, pod vetĂ« Ă«shtĂ« njĂ« gjĂ« efemere, ai nis dhe zhduket. A dĂ«shironi tĂ« vrisni tĂ« gjitha kontejnerĂ«t tuaj tĂ« mĂ«parshĂ«m dhe pastaj tĂ« nisni menjĂ«herĂ« versionet e reja, apo do tĂ« dĂ«shironit t'i lansoni ata gradualisht â pikĂ«risht pĂ«r kĂ«tĂ« proces pĂ«rgjigjet koncepti i deployment. Ai pĂ«rshkruan se si i deplojoni podĂ«t tuaj, nĂ« cilat sasi dhe si t'i pĂ«rditĂ«soni.
Koncepti i tretë është service. Shërbimi juaj është në thelb sistemi juaj, i cili pranon një trafik dhe e drejton atë në një ose disa pod-e, që i përkasin shërbimit tuaj. Kjo do të thotë se ai ju lejon të deklaroni se gjithë trafiku hyrës për një shërbim të caktuar me një emër të caktuar duhet të dërgohet në këto pod-e specifike. Për më tepër, ai ju siguron balancimin e trafikut. Kështu, mund të nisni dy pod-e të aplikacionit tuaj, dhe i gjithë trafiku hyrës do të balancohet një mënyrë të barabartë midis pod-eve të lidhura me këtë shërbim.
Dhe koncepti i katĂ«rt themelor â Ingress. Ky Ă«shtĂ« njĂ« shĂ«rbim qĂ« ekzekutohet nĂ« klasterin Kubernetes. Ai funksionon si njĂ« balancues ngarkese i jashtĂ«m, i cili merr tĂ« gjitha kĂ«rkesat. FalĂ« API-sĂ« sĂ« Kubernetes Ingress, mund tĂ« pĂ«rcaktohet se ku duhet dĂ«rguar kĂ«to kĂ«rkesa. PĂ«r mĂ« tepĂ«r, ai e bĂ«n kĂ«tĂ« nĂ« njĂ« mĂ«nyrĂ« shumĂ« fleksibile. Mund tĂ« thoni se tĂ« gjitha kĂ«rkesat pĂ«r kĂ«tĂ« host dhe kĂ«tĂ« URL dĂ«rgohen nĂ« kĂ«tĂ« shĂ«rbim. NdĂ«rsa kĂ«to kĂ«rkesa, qĂ« vijnĂ« pĂ«r kĂ«tĂ« host dhe njĂ« URL tjetĂ«r, dĂ«rgohen nĂ« njĂ« shĂ«rbim tjetĂ«r.
Ajo më e mrekullueshme për ata që krijojnë aplikacione është se ju jeni në gjendje t'i menaxhoni këto gjithçka vetë. Duke vendosur konfigurimin e Ingress, mund të dërgoni gjithë trafikun që vjen në një API të caktuar në konteiner të veçantë, të shkruar, për shembull, në Go. Ndërsa ky trafik, që vjen në të njëjtën domen, por në një URL tjetër, dërgohet në konteiner të shkruar në PHP, ku ka shumë logjikë, por ato nuk janë shumë të shpejta.
NĂ«se krahasoni tĂ« gjitha kĂ«to koncepte me Nomad, mund tĂ« thuhet se tre konceptet e para â janĂ« sĂ« bashku njĂ« ShĂ«rbim. NdĂ«rsa koncepti i fundit mungon nĂ« Nomad. Ne e kemi pĂ«rdorur njĂ« balancues tĂ« jashtĂ«m: mund tĂ« jetĂ« haproxy, nginx, nginx+ etj. NĂ« rastin e kubit, nuk keni nevojĂ« ta futni kĂ«tĂ« koncept tĂ« shtuar veçmas. MegjithatĂ«, nĂ«se shikoni brenda Ingress, atĂ«herĂ« Ă«shtĂ« ose nginx, ose haproxy, ose traefik, por siç do tĂ« thoshte, e ndĂ«rtuar brenda Kubernetes.
TĂ« gjitha konceptet qĂ« pĂ«rmenda janĂ« nĂ« thelb burime qĂ« ekzistojnĂ« brenda njĂ« klasteri Kubernetes. PĂ«r pĂ«rshkrimin e tyre nĂ« kube, pĂ«rdoret formati yaml, mĂ« i lexueshĂ«m dhe i njohur se skedarĂ«t HCL nĂ« rastin e Nomad. Por strukturorisht, ata pĂ«rshkruajnĂ« pĂ«r shembull pĂ«r podin tĂ« njĂ«jtĂ«n gjĂ«. Ata thonĂ« â dua tĂ« deplojoj disa pod-e aty, me imazhe tĂ« caktuara, nĂ« njĂ« numĂ«r tĂ« caktuar.
Përveç kësaj, ne kuptuam se nuk donim të krijonim me dorë çdo burim të veçantë: deployments, shërbime, Ingress dhe të tjera. Në vend të kësaj, ne donim që gjatë depolimit të përshkruanim çdo sistem tonin që ekzistonte në terma Kubernetes, në mënyrë që të mos ishte e nevojshme të rindërtonim manualisht të gjitha varësitë e nevojshme të burimeve në rendin e duhur. Si një sistem që na lejoj rreth kësaj ishte zgjedhur Helm.
Koncepte kryesore në Helm
Helm është menaxheri i paketave për Kubernetes. Ai është shumë i ngjashëm me mënyrën si funksionojnë menaxherët e paketave në gjuhët e programimit. Ata ju lejojnë të ruani një shërbim, që përbëhet, për shembull, nga deployment nginx, deployment php-fpm, konfigurimi për Ingress, configmaps (kjo është një entitet që ju lejon të përcaktoni env dhe parametra të tjerë për sistemin tuaj) në formën e ashtuquajturave chart. Në këtë mënyrë, Helm punon mbi Kubernetes. Domethënë, nuk është ndonjë sistem që qëndron jashtë, përkundrazi, është një shërbim tjetër që ekzekutohet brenda kubit. Ju komunikoni me të përmes API-së së tij përmes komandës në konsolë. Komforti dhe bukuria e tij qëndron në faktin se, edhe në se helm dështën ose e hiqni atë nga klasteri, shërbimet tuaja nuk do të zhduken, pasi helm shërben në thelb vetëm për lançimin e sistemit. Për funksionimin dhe gjendjen e shërbimeve kujdeset vetë Kubernetes.
Po ashtu, ne kuptuam se tematizimi, të cilën deri më tani ishim të detyruar ta bënim vetë përmes integrimit të jinja në konfigurimet tona, është një nga funksionalitetet kryesore të helm. Të gjitha konfigurimet që krijoni për sistemet tuaja ruhen në helm si shabllone, të ngjashme pak me jinja, por në të vërtetë përdorin shabllonizimin e gjuhës Go, në të cilën është shkruar helm, ashtu si Kubernetes.
Helm na shton disa koncepte të tjera shtesë.
Chart â Ă«shtĂ« pĂ«rshkrimi i shĂ«rbimit tuaj. NĂ« menaxherĂ« tĂ« tjerĂ« paketash do ta quajnĂ« paketĂ«, bundle ose diçka tĂ« ngjashme. KĂ«tu quhet chart.
Values â janĂ« variablat qĂ« dĂ«shironi tĂ« pĂ«rdorni pĂ«r tĂ« ndĂ«rtuar konfigurimet tuaja nga shabllonĂ«t.
Release. Për çdo herë shërbimi që është vendosur përmes helm merr një version incremental të lëshimit. Helm e mban mend se çfarë ka qenë konfigurimi i shërbimit gjatë lëshimeve të mëparshme. Prandaj, nëse duhet të riktheheni, mjafton të ekzekutoni komandën helm callback, duke i treguar versionin e mëparshëm të lëshimit. Edhe nëse në momentin e rikthimit konfigurimi përkatës në repositorin tuaj nuk është i disponueshëm, helm prapë e mban mend se çfarë ka qenë dhe do ta rikthejë sistemin tuaj në gjendjen në të cilën ishte gjatë lëshimit të mëparshëm.
Në rastin kur përdorim helm, konfigurimet e zakonshme për Kubernetes gjithashtu shndërrohen në shabllone, ku ka mundësi për të përdorur variabla, funksione dhe për të aplikuar operacione të kushtëzuara. Kështu, mund të krijoni konfigurimin e shërbimit tuaj në varësi të mjedisit.
Në praktikë, ne vendosëm të veprojmë pak ndryshe nga ajo që bëmë në rastin e Nomad. Ndryshe nga Nomad, ku në një depo ruheshin dhe konfigurimet për vendosjen, si dhe variablat n që ne na duheshin për të vendosur shërbimin tonë, këtu ne vendosëm t'i ndajmë ato në dy depote të veçanta. Në depo «deploy» ruhen vetëm variablat n që janë të nevojshëm për vendosjen, ndërsa në depo «helm» ruhen konfigurimet apo chartet.
ĂfarĂ« na dha kjo?
Megjithëse në vetë skedarët e konfigurimit ne nuk ruajmë ndonjë të dhënë që është vërtet e ndjeshme. Për shembull, fjalëkalimet për bazat e të dhënave. Ato ruhen si sekrete në Kubernetes, por megjithatë, aty ka disa gjëra të veçanta, për të cilat ne nuk duam të japim akses për të gjithë. Prandaj, aksesin në depot «deploy» është më i kufizuar, ndërsa depoja «helm» përmban thjesht përshkrimin e shërbimit. Për këtë arsye, atij mund t'i jepet akses në mënyrë të sigurt më shumë njerëzve.
Duke kemi jo vetĂ«m prodhimin, por edhe ambiente tĂ« tjera, kjo ndarje na lejon tĂ« ripĂ«rdorim helm-chart-et tona pĂ«r tĂ« instaluar shĂ«rbime jo vetĂ«m nĂ« prodhim, por edhe, pĂ«r shembull, nĂ« ambientin QA. Edhe pĂ«r ta krijuar ato lokalisht, duke pĂ«rdorur Minikube â kjo Ă«shtĂ« njĂ« mjet pĂ«r ekzekutimin lokal tĂ« Kubernetes.
Brenda çdo repozitori e kemi bĂ«rĂ« ndarjen nĂ« drejtoni tĂ« veçanta pĂ«r çdo shĂ«rbim. KĂ«shtu, brenda çdo direktorie ndodhin shabllone tĂ« lidhura me chart-in pĂ«rkatĂ«s dhe qĂ« pĂ«rshkruajnĂ« burimet qĂ« nevojiten pĂ«r tĂ« instaluar sistemin tonĂ«. NĂ« repozitorin âdeployâ kemi mbetur vetĂ«m me enĂ«. NĂ« kĂ«tĂ« rast, ne nuk e kemi pĂ«rdorur shabllonizimin me jinja, sepse helm ofron vetĂ« shabllonizimin nga kutia â kjo Ă«shtĂ« njĂ« nga funksionet e tij kryesore.
Ne kemi lĂ«nĂ« njĂ« skript pĂ«r deploy â deploy.sh, i cili e thjeshton dhe stanardizon nisjen pĂ«r implementimin me helm. KĂ«shtu, pĂ«r kĂ«do qĂ« do tĂ« bĂ«jĂ« implementimin, ndĂ«rfaqja e implementimit duket njĂ«soj siç ishte nĂ« rastin e implementimit pĂ«rmes Nomad. I njĂ«jti deploy.sh, emri i shĂ«rbimit tuaj dhe vendi ku dĂ«shironi ta implementoni. Kjo rezulton nĂ« aktivizimin e helm brenda. Ai, nga ana e tij, mbledh konfigurime nga shabllonet, zĂ«vendĂ«son nĂ« to skedarĂ«t e nevojshĂ«m tĂ« values, e mĂ« pas implementon, duke i dĂ«rguar nĂ« Kubernetes.
PĂ«rfundimet
Shërbimi Kubernetes duket më i komplikuar se Nomad.
Këtu, trafiku i daljes vjen në Ingress. Ky është pikërisht kontrolluesi i përparmë që merr të gjitha kërkesat dhe më pas i dërgon ato në shërbimet përkatëse sipas të dhënave të kërkesës. Ai i përcakton ato në bazë të konfigurimeve, të cilat janë pjesë e përshkrimit të aplikacionit tuaj në helm dhe të cilat zhvilluesit i vendosin vetë. Shërbimi dërgon kërkesat në pod-et e tij, pra në kontejnerët specifikë, duke balancuar trafikun e ardhshëm mes të gjithë kontejnerëve që i përkasin këtij shërbimi. Sigurisht, nuk duhet të harrojmë se nga siguria në nivel të rrjetit, ne nuk duhet të largohemi. Prandaj, në klasterin Kubernetes, funksionon segmentimi, i cili është i bazuar në etiketimin. Të gjithë shërbimet kanë etiketa të caktuara, të cilat lidhen me të drejtat e aksesit të shërbimeve në burime të ndryshme brenda ose jashtë klasterit.
Gjatë migrimit, ne pamë se Kubernetes ka të gjitha mundësitë e Nomad, që kemi përdorur më parë, dhe gjithashtu shton shumë të reja. Mund të zgjerohet përmes plugin-eve, dhe në të vërtetë përmes llojeve të personalizuara të burimeve. Kjo do të thotë se keni mundësinë jo vetëm të përdorni diçka që vjen me Kubernetes nga kutia, por të krijoni burimin tuaj dhe shërbimin që do ta lexojë burimin tuaj. Kjo ofron mundësi të shtuara për zgjerimin e sistemit tuaj pa pasur nevojë për rinstalim të Kubernetes dhe pa nevojë për ndryshime.
Një shembull i tillë përdorimi është Prometheus, i cili ekzekutohet brenda klasterit Kubernetes. Për ta filluar mbledhjen e metrikave nga një shërbim të caktuar, ne duhet të shtojmë në përshkrimin e shërbimit një tip të shtesë burimi, të ashtuquajturin shërbim-monitor. Prometheus, për shkak se di të lexojë dhe është aktivizuar në Kubernetes, fillon automatikisht të mbledhë metrika nga sistemi i ri. Kjo është mjaft e përshtatshme.
Deployimi i parë që bëmë në Kubernetes ishte në mars të vitit 2018. Dhe gjatë këtij kohë, kurrë nuk kemi pasur probleme me të. Ai funksionon mjaft stabilisht pa defekte të rëndësishme. Për më tepër, mund ta zgjerojmë më tej. Aktualisht, kemi mjaft mundësi brenda tij dhe ne na pëlqen shumë ritmi i zhvillimit të Kubernetes. Në këtë moment, më shumë se 3000 konteinerë janë në Kubernetes. Klasteri përmban disa Node. Ai është menaxhuar, stabil dhe shumë i kontrolluar.
Burimi: habr.com
