Pershendetje te gjitheve! Emri im është Pavel Agaletsky. Unë punoj si drejtues ekipi në një ekip që zhvillon sistemin e shpërndarjes Lamoda. Në vitin 2018, fola në konferencën HighLoad++ dhe sot do të doja të paraqes një transkript të raportit tim.

Tema ime i kushtohet përvojës së kompanisë sonë në vendosjen e sistemeve dhe shërbimeve në mjedise të ndryshme. Duke filluar nga kohët tona parahistorike, kur ne vendosëm të gjitha sistemet në serverë të zakonshëm virtualë, duke përfunduar me kalimin gradual nga Nomad në vendosjen në Kubernetes. Unë do t'ju tregoj pse e bëmë dhe çfarë problemesh patëm në këtë proces.

Vendosja e aplikacioneve në VM

Le të fillojmë me faktin se 3 vjet më parë të gjitha sistemet dhe shërbimet e kompanisë u vendosën në serverë të rregullt virtual. Teknikisht, ai u organizua në atë mënyrë që i gjithë kodi për sistemet tona ruhej dhe grumbullohej duke përdorur mjete montimi automatike, duke përdorur jenkins. Duke përdorur Ansible, ai u shpërnda nga sistemi ynë i kontrollit të versionit në serverët virtualë. Për më tepër, çdo sistem që kishte kompania jonë ishte vendosur në të paktën 2 serverë: njëri prej tyre në kokë, i dyti në bisht. Këto dy sisteme ishin absolutisht identike me njëri-tjetrin në të gjitha cilësimet e tyre, fuqinë, konfigurimin, etj. I vetmi ndryshim midis tyre ishte se koka merrte trafikun e përdoruesit, ndërsa bishti nuk merrte kurrë trafikun e përdoruesit.

Pse u bë kjo?

Kur vendosëm lëshimet e reja të aplikacionit tonë, donim të siguronim një prezantim pa probleme, domethënë pa pasoja të dukshme për përdoruesit. Kjo u arrit për shkak të faktit se versioni tjetër i përpiluar duke përdorur Ansible u lëshua në fund. Atje, njerëzit që ishin të përfshirë në vendosjen mund të kontrollonin dhe të siguroheshin që gjithçka ishte në rregull: të gjitha metrikat, seksionet dhe aplikacionet po funksiononin; lansohen skriptet e nevojshme. Vetëm pasi u bindën se gjithçka ishte në rregull, u ndërrua trafiku. Filloi të shkonte te serveri që më parë ishte bisht. Dhe ai që ishte më parë kreu mbeti pa trafikun e përdoruesve, ndërsa kishte ende versionin e mëparshëm të aplikacionit tonë në të.

Pra, ishte e qetë për përdoruesit. Sepse ndërrimi është i menjëhershëm, pasi është thjesht ndërrimi i balancuesit. Mund të ktheheni shumë lehtë te versioni i mëparshëm thjesht duke e kthyer balancuesin përsëri. Ne gjithashtu mund të verifikonim që aplikacioni ishte i aftë të prodhohej edhe para se të merrte trafikun e përdoruesve, gjë që ishte mjaft e përshtatshme.

Çfarë avantazhesh pamë në gjithë këtë?

1. Para së gjithash, mjafton thjesht funksionon. Të gjithë e kuptojnë se si funksionon një skemë e tillë vendosjeje, sepse shumica e njerëzve janë vendosur ndonjëherë në serverë të rregullt virtual.
2. Kjo mjafton në mënyrë të sigurt, pasi teknologjia e vendosjes është e thjeshtë, e testuar nga mijëra kompani. Miliona serverë janë vendosur në këtë mënyrë. Është e vështirë të thyesh diçka.
3. Dhe më në fund ne mund të merrnim vendosjet atomike. Vendosjet që ndodhin njëkohësisht për përdoruesit, pa një fazë të dukshme të kalimit midis versionit të vjetër dhe atij të ri.

Por ne pamë edhe disa mangësi në gjithë këtë:

1. Përveç mjedisit të prodhimit, mjedisit të zhvillimit, ka mjedise të tjera. Për shembull, qa dhe paraprodhimi. Në atë kohë kishim shumë serverë dhe rreth 60 shërbime. Për këtë arsye ishte e nevojshme për çdo shërbim, mbani versionin më të fundit për të Makine virtuale. Për më tepër, nëse dëshironi të përditësoni bibliotekat ose të instaloni varësi të reja, duhet ta bëni këtë në të gjitha mjediset. Ju duhej gjithashtu të sinkronizoni kohën kur do të vendosni versionin tjetër të ri të aplikacionit tuaj me kohën kur devops kryen cilësimet e nevojshme të mjedisit. Në këtë rast, është e lehtë të futemi në një situatë ku mjedisi ynë do të jetë disi i ndryshëm në të gjitha mjediset menjëherë. Për shembull, në një mjedis QA do të ketë disa versione të bibliotekave, dhe në një mjedis prodhimi do të ketë të ndryshme, të cilat do të çojnë në probleme.
2. Vështirësi në përditësimin e varësive aplikimin tuaj. Nuk varet nga ju, por nga ekipi tjetër. Gjegjësisht, nga ekipi devops që mirëmban serverët. Ju duhet t'u jepni atyre një detyrë të përshtatshme dhe një përshkrim të asaj që dëshironi të bëni.
3. Në atë kohë, ne donim t'i ndanim edhe monolitët e mëdhenj të mëdhenj që kishim në shërbime të vogla të veçanta, pasi e kuptonim që do të kishte gjithnjë e më shumë. Në atë kohë, ne kishim më shumë se 100. Për çdo shërbim të ri, ishte e nevojshme të krijohej një makinë e re virtuale e veçantë, e cila gjithashtu duhej të mirëmbahej dhe vendosej. Për më tepër, nuk keni nevojë për një makinë, por të paktën dy. Kësaj i shtohet edhe mjedisi QA. Kjo shkakton probleme dhe e bën më të vështirë për ju ndërtimin dhe ekzekutimin e sistemeve të reja. proces kompleks, i shtrenjtë dhe i gjatë.

Prandaj, vendosëm që do të ishte më e përshtatshme të kalonim nga vendosja e makinave të rregullta virtuale në vendosjen e aplikacioneve tona në një kontejner docker. Nëse keni docker, ju nevojitet një sistem që mund të ekzekutojë aplikacionin në një grup, pasi nuk mund të ngrini thjesht një kontejner. Zakonisht dëshironi të mbani gjurmët se sa kontejnerë janë ngritur në mënyrë që të ngrihen automatikisht. Për këtë arsye, na duhej të zgjidhnim një sistem kontrolli.

Menduam për një kohë të gjatë se cilin mund të merrnim. Fakti është se në atë kohë kjo pirg vendosjeje në serverët e zakonshëm virtualë ishte disi e vjetëruar, pasi ata nuk kishin versionet më të fundit të sistemeve operative. Në një moment, kishte edhe FreeBSD, i cili nuk ishte shumë i përshtatshëm për t'u mbështetur. Kuptuam se duhej të migronim në doker sa më shpejt që të ishte e mundur. Zhvilluesit tanë shikuan përvojën e tyre ekzistuese me zgjidhje të ndryshme dhe zgjodhën një sistem si Nomad.

Kalo te Nomad

Nomad është një produkt i HashiCorp. Ata janë të njohur edhe për zgjidhjet e tyre të tjera:

"Konsulli" është një mjet për zbulimin e shërbimit.

"Terraform" - një sistem për menaxhimin e serverëve që ju lejon t'i konfiguroni ato përmes konfigurimit, të ashtuquajturit infrastrukturë-si-kod.

"Endacak" ju lejon të vendosni makina virtuale në nivel lokal ose në cloud përmes skedarëve specifikë të konfigurimit.

Nomad në atë kohë dukej si një zgjidhje mjaft e thjeshtë që mund të kalohej shpejt pa ndryshuar të gjithë infrastrukturën. Përveç kësaj, është mjaft e lehtë për t'u mësuar. Kjo është arsyeja pse ne e zgjodhëm atë si sistemin e filtrimit për enën tonë.

Çfarë ju nevojitet për të vendosur sistemin tuaj në Nomad?

1. Para së gjithash ju duhet imazh doker aplikimin tuaj. Ju duhet ta ndërtoni atë dhe ta vendosni në depon e imazhit docker. Në rastin tonë, ky është një artifakturë - një sistem që ju lejon të futni objekte të ndryshme të llojeve të ndryshme në të. Mund të ruajë arkivat, imazhet e dokerit, paketat PHP të kompozitorit, paketat NPM, etj.
2. Gjithashtu kërkohet skedari i konfigurimit, i cili do t'i tregojë Nomadit se çfarë, ku dhe në çfarë sasie dëshironi të vendosni.

Kur flasim për Nomad, ai përdor gjuhën HCL si formatin e skedarit të informacionit, që nënkupton Gjuha e konfigurimit të HashiCorp. Ky është një superset i Yaml që ju lejon të përshkruani shërbimin tuaj në terma Nomad.

Kjo ju lejon të thoni sa kontejnerë dëshironi të vendosni, nga të cilat imazhe t'u kaloni parametra të ndryshëm gjatë vendosjes. Kështu, ju ia jepni këtë skedar Nomad-it dhe ai lëshon kontejnerë në prodhim sipas tij.

Në rastin tonë, kuptuam se thjesht shkrimi i skedarëve absolutisht identikë HCL për secilin shërbim nuk do të ishte shumë i përshtatshëm, sepse ka shumë shërbime dhe ndonjëherë ju dëshironi t'i përditësoni ato. Ndodh që një shërbim të shpërndahet jo në një shembull, por në një larmi të ndryshme. Për shembull, një nga sistemet që kemi në prodhim ka më shumë se 100 raste në prodhim. Ato funksionojnë nga të njëjtat imazhe, por ndryshojnë në cilësimet e konfigurimit dhe skedarët e konfigurimit.

Prandaj, vendosëm që do të ishte e përshtatshme për ne që të ruanim të gjithë skedarët tanë të konfigurimit për t'u vendosur në një depo të përbashkët. Në këtë mënyrë ato ishin të dukshme: ishin të lehta për t'u mirëmbajtur dhe ne mund të shihnim se çfarë sistemesh kishim. Nëse është e nevojshme, është gjithashtu e lehtë të përditësoni ose ndryshoni diçka. Shtimi i një sistemi të ri nuk është gjithashtu i vështirë - thjesht duhet të krijoni një skedar konfigurimi brenda drejtorisë së re. Brenda tij janë skedarët e mëposhtëm: service.hcl, i cili përmban një përshkrim të shërbimit tonë, dhe disa skedarë env që lejojnë konfigurimin e këtij shërbimi, duke u vendosur në prodhim.

Megjithatë, disa nga sistemet tona janë vendosur në prodhim jo në një kopje, por në disa menjëherë. Prandaj, vendosëm që do të ishte e përshtatshme për ne të ruanim jo konfigurimet në formën e tyre të pastër, por në formën e tyre të shabllonit. Dhe ne zgjodhëm xhinja 2. Në këtë format, ne ruajmë si konfigurimet e vetë shërbimit ashtu edhe skedarët env të nevojshëm për të.

Përveç kësaj, ne kemi vendosur në depo një skript vendosjeje të përbashkët për të gjitha projektet, i cili ju lejon të nisni dhe shpërndani shërbimin tuaj në prodhim, në mjedisin e dëshiruar, në objektivin e dëshiruar. Në rastin kur ne e kthyem konfigurimin tonë HCL në një shabllon, atëherë skedari HCL, i cili më parë ishte një konfigurim i rregullt Nomad, në këtë rast filloi të dukej pak më ndryshe.

Kjo do të thotë, ne zëvendësuam disa variabla të vendndodhjes së konfigurimit me ndryshore të futura që janë marrë nga skedarët env ose burime të tjera. Për më tepër, ne morëm mundësinë për të mbledhur skedarë HCL në mënyrë dinamike, domethënë, ne mund të përdorim jo vetëm futje të zakonshme të variablave. Meqenëse jinja mbështet sythe dhe kushte, mund të krijoni gjithashtu skedarë konfigurimi atje, të cilët ndryshojnë në varësi të vendit ku saktësisht i vendosni aplikacionet tuaja.

Për shembull, ju dëshironi të shpërndani shërbimin tuaj në para-prodhim dhe prodhim. Le të themi se në para-prodhim nuk dëshironi të ekzekutoni skriptet cron, por thjesht dëshironi të shihni shërbimin në një domen të veçantë për t'u siguruar që ai funksionon. Për këdo që vendos shërbimin, procesi duket shumë i thjeshtë dhe transparent. E tëra çfarë ju duhet të bëni është të ekzekutoni skedarin deploy.sh, të specifikoni se cilin shërbim dëshironi të vendosni dhe në cilin objektiv. Për shembull, ju dëshironi të vendosni një sistem të caktuar në Rusi, Bjellorusi ose Kazakistan. Për ta bërë këtë, thjesht ndryshoni një nga parametrat dhe do të keni skedarin e saktë të konfigurimit.

Kur shërbimi Nomad është vendosur tashmë në grupin tuaj, duket kështu.

Së pari, keni nevojë për një lloj balancuesi jashtë, i cili do të marrë të gjithë trafikun e përdoruesve. Ai do të punojë së bashku me Konsullin dhe do të zbulojë prej tij se ku, në cilën nyje, në cilën adresë IP ndodhet një shërbim specifik që korrespondon me një emër domaini të caktuar. Shërbimet në Konsullin vijnë nga vetë Nomad. Meqenëse këto janë produkte nga e njëjta kompani, ato janë mjaft të lidhura me njëra-tjetrën. Mund të themi se Nomad nga kutia mund të regjistrojë të gjitha shërbimet e lançuara në të brenda Konsullit.

Pasi balancuesi juaj i ngarkesës së pjesës së përparme e di se në cilin shërbim të dërgojë trafikun, ai e përcjell atë në kontejnerin e duhur ose në kontejnerët e shumtë që përputhen me aplikacionin tuaj. Natyrisht, është gjithashtu e nevojshme të mendoni për sigurinë. Edhe pse të gjitha shërbimet funksionojnë në të njëjtat makina virtuale në kontejnerë, kjo zakonisht kërkon parandalimin e aksesit të lirë nga çdo shërbim në çdo shërbim tjetër. Këtë e arritëm përmes segmentimit. Secili shërbim u lançua në rrjetin e tij virtual, mbi të cilin u përshkruan rregullat dhe rregullat e rrugëzimit për lejimin/refuzimin e aksesit në sisteme dhe shërbime të tjera. Ato mund të vendosen si brenda këtij grupi ashtu edhe jashtë tij. Për shembull, nëse dëshironi të parandaloni lidhjen e një shërbimi me një bazë të dhënash specifike, kjo mund të bëhet përmes segmentimit në nivel rrjeti. Kjo do të thotë, edhe gabimisht, nuk mund të lidheni aksidentalisht nga mjedisi i testimit në bazën e të dhënave tuaja të prodhimit.

Sa na kushtoi tranzicioni në aspektin e burimeve njerëzore?

Kalimi i të gjithë kompanisë në Nomad zgjati afërsisht 5-6 muaj. Lëvizëm shërbim pas shërbimi, por me një ritëm mjaft të shpejtë. Secili ekip duhej të krijonte kontejnerët e tij për shërbimet.

Ne kemi miratuar një qasje të tillë që çdo ekip të jetë përgjegjës për imazhet e dokerit të sistemeve të tyre në mënyrë të pavarur. DevOps ofrojnë infrastrukturën e përgjithshme të nevojshme për vendosjen, domethënë mbështetje për vetë grupin, mbështetje për sistemin CI, etj. Dhe në atë kohë, ne kishim më shumë se 60 sisteme të zhvendosura në Nomad, të cilat arrinin në rreth 2 mijë kontejnerë.

Devops është përgjegjës për infrastrukturën e përgjithshme të gjithçkaje që lidhet me vendosjen dhe serverët. Dhe çdo ekip zhvillimi, nga ana tjetër, është përgjegjës për zbatimin e kontejnerëve për sistemin e tij specifik, pasi është ekipi që e di se çfarë i nevojitet në përgjithësi në një kontejner të veçantë.

Arsyet e braktisjes së Nomad

Çfarë avantazhesh morëm duke kaluar në vendosje duke përdorur Nomad dhe docker, ndër të tjera?

1. Ne ofruar kushte të barabarta per te gjitha ambjentet. Në zhvillim, mjedisi QA, para-prodhimi, prodhimi, përdoren të njëjtat imazhe të kontejnerëve, me të njëjtat varësi. Prandaj, praktikisht nuk keni asnjë shans që ajo që do të përfundojë në prodhim nuk është ajo që keni testuar më parë në nivel lokal ose në mjedisin tuaj të testimit.
2. Ne gjithashtu zbuluam se mjafton lehtë për të shtuar një shërbim të ri. Nga pikëpamja e vendosjes, çdo sistem i ri lëshohet shumë thjesht. Thjesht shkoni te depoja që ruan konfigurimet, shtoni një konfigurim tjetër për sistemin tuaj atje dhe jeni gati. Ju mund ta vendosni sistemin tuaj në prodhim pa ndonjë përpjekje shtesë nga devops.
3. Të gjithë skedarët e konfigurimit në një depo të përbashkët rezultoi se ishte në shqyrtim. Në kohën kur ne vendosëm sistemet tona duke përdorur serverë virtualë, ne përdorëm Ansible, në të cilin konfigurimet ishin në të njëjtin depo. Sidoqoftë, për shumicën e zhvilluesve kjo ishte pak më e vështirë për t'u punuar. Këtu vëllimi i konfigurimeve dhe kodit që duhet të shtoni për të vendosur shërbimin është bërë shumë më i vogël. Plus, është shumë e lehtë për devops ta rregullojë ose ndryshojë atë. Në rast të kalimeve, për shembull, në një version të ri të Nomad, ata mund të marrin dhe përditësojnë në masë të gjithë skedarët operativë të vendosur në të njëjtin vend.

Por kemi hasur edhe disa disavantazhe:

Doli që ne nuk mund të arrinte vendosje pa probleme në rastin e Nomad. Kur nxirrte kontejnerë në kushte të ndryshme, mund të rezultonte se po funksiononte, dhe Nomad e perceptoi atë si një kontejner të gatshëm për të marrë trafik. Kjo ndodhi përpara se aplikacioni brenda tij të kishte një shans për të nisur. Për këtë arsye, sistemi filloi të prodhonte 500 gabime për një periudhë të shkurtër kohore, sepse trafiku filloi të shkonte në një kontejner që ende nuk ishte gati ta pranonte.

Ne hasëm disa nga kënetat. Gabimi më domethënës është se Nomad nuk trajton shumë mirë një grup të madh nëse keni shumë sisteme dhe kontejnerë. Kur doni të hiqni një nga serverët që përfshihet në grupin Nomad për mirëmbajtje, ekziston një probabilitet mjaft i lartë që grupi të mos ndihet shumë mirë dhe të shpërbëhet. Disa kontejnerë, për shembull, mund të bien dhe të mos ngrihen - kjo do t'ju kushtojë shumë më vonë nëse të gjitha sistemet tuaja të prodhimit janë të vendosura në një grup të menaxhuar nga Nomad.

Kështu që vendosëm të mendonim se ku duhet të shkonim më pas. Në atë pikë, ne u bëmë shumë më të vetëdijshëm për atë që donim të arrinim. Domethënë: ne duam besueshmëri, pak më shumë funksione sesa ofron Nomad, dhe një sistem më të pjekur, më të qëndrueshëm.

Në këtë drejtim, zgjedhja jonë ra në Kubernetes si platforma më e njohur për nisjen e grupimeve. Sidomos duke pasur parasysh se madhësia dhe numri i kontejnerëve tanë ishte mjaft i madh. Për qëllime të tilla, Kubernetes dukej se ishte sistemi më i përshtatshëm që ne mund të shikonim.

Kalimi në Kubernetes

Unë do t'ju tregoj pak për konceptet themelore të Kubernetes dhe si ndryshojnë ato nga Nomad.

Para së gjithash, koncepti më themelor në Kubernetes është koncepti i pod. Bishtajë është një grup prej një ose më shumë kontejnerëve që qarkullojnë gjithmonë së bashku. Dhe ata gjithmonë punojnë sikur rreptësisht në një makinë virtuale. Ato janë të aksesueshme me njëri-tjetrin nëpërmjet IP 127.0.0.1 në porte të ndryshme.

Le të supozojmë se ju keni një aplikacion PHP që përbëhet nga nginx dhe php-fpm - skema klasike. Me shumë mundësi, do të dëshironi të mbani të dyja kontejnerët nginx dhe php-fpm së bashku në çdo kohë. Kubernetes ju lejon ta arrini këtë duke i përshkruar ato si një pod të përbashkët. Kjo është pikërisht ajo që nuk mundëm të merrnim me Nomad.

Koncepti i dytë është shpërndarje. Fakti është se vetë pod është një gjë kalimtare; ajo fillon dhe zhduket. Dëshironi të vrisni të gjithë kontejnerët tuaj të mëparshëm në fillim dhe më pas të lëshoni versionet e reja menjëherë, apo dëshironi t'i hapni ato gradualisht? Ky është procesi për të cilin është përgjegjës koncepti i vendosjes. Ai përshkruan se si i vendosni podet tuaja, në çfarë sasie dhe si t'i përditësoni ato.

Koncepti i tretë është shërbim. Shërbimi juaj është në fakt sistemi juaj, i cili merr pak trafik dhe më pas e përcjell atë në një ose më shumë pods që korrespondojnë me shërbimin tuaj. Kjo do të thotë, ju lejon të thoni që i gjithë trafiku hyrës në një shërbim të tillë me një emër të tillë duhet të dërgohet në këto pods specifike. Dhe në të njëjtën kohë ju siguron balancimin e trafikut. Kjo do të thotë, ju mund të nisni dy pods të aplikacionit tuaj dhe i gjithë trafiku në hyrje do të jetë i balancuar në mënyrë të barabartë midis pods që lidhen me këtë shërbim.

Dhe koncepti i katërt bazë është Hyrje. Ky është një shërbim që funksionon në një grup Kubernetes. Ai vepron si një balancues i jashtëm i ngarkesës që merr përsipër të gjitha kërkesat. Duke përdorur Kubernetes API, Ingress mund të përcaktojë se ku duhet të dërgohen këto kërkesa. Për më tepër, ai e bën këtë në mënyrë shumë fleksibël. Mund të thuash që të gjitha kërkesat për këtë host dhe URL-ja e tillë i dërgohen këtij shërbimi. Dhe këto kërkesa që vijnë në këtë host dhe në një URL tjetër dërgohen në një shërbim tjetër.

Gjëja më interesante nga këndvështrimi i dikujt që zhvillon një aplikacion është se ju jeni në gjendje t'i menaxhoni të gjitha vetë. Duke vendosur konfigurimin Ingress, ju mund të dërgoni të gjithë trafikun që vjen në një API të tillë në kontejnerë të veçantë të shkruar, për shembull, në Go. Por ky trafik, që vjen në të njëjtin domen, por në një URL tjetër, duhet të dërgohet në kontejnerë të shkruar në PHP, ku ka shumë logjikë, por nuk janë shumë të shpejtë.

Nëse i krahasojmë të gjitha këto koncepte me Nomad, mund të themi se tre konceptet e para janë të gjitha së bashku Shërbimi. Dhe koncepti i fundit mungon në vetë Nomad. Ne përdorëm një balancues të jashtëm si ai: mund të jetë haproksi, nginx, nginx+, e kështu me radhë. Në rastin e një kubi, nuk keni nevojë ta prezantoni veçmas këtë koncept shtesë. Sidoqoftë, nëse shikoni Ingress nga brenda, ai është ose nginx, haproksi ose traefik, por i integruar në Kubernetes.

Të gjitha konceptet që përshkrova janë, në fakt, burime që ekzistojnë brenda një grupi Kubernetes. Për t'i përshkruar ato në kub, përdoret një format yaml, i cili është më i lexueshëm dhe më i njohur se skedarët HCL në rastin e Nomad. Por strukturisht ata përshkruajnë të njëjtën gjë në rastin e, për shembull, pod. Ata thonë - Unë dua të vendos filan dhe atë pods atje, me imazhe të tilla e të tilla, në sasi të tilla e të tilla.

Për më tepër, ne kuptuam se nuk donim të krijonim çdo burim individual me dorë: vendosjen, shërbimet, hyrjen, etj. Në vend të kësaj, ne donim të përshkruanim secilin prej sistemeve tona në termat e Kubernetes gjatë vendosjes, në mënyrë që të mos na duhej të rikrijonim manualisht të gjitha varësitë e nevojshme të burimeve në rendin e duhur. Helm u zgjodh si sistemi që na lejoi ta bënim këtë.

Konceptet themelore në Helm

Helm është menaxher i paketave për Kubernetes. Është shumë e ngjashme me mënyrën se si funksionojnë menaxherët e paketave në gjuhët e programimit. Ato ju lejojnë të ruani një shërbim të përbërë nga, për shembull, vendosja nginx, vendosja php-fpm, konfigurimi për Ingress, configmaps (ky është një ent që ju lejon të vendosni env dhe parametra të tjerë për sistemin tuaj) në formën e kështu- të quajtura tabela. Në të njëjtën kohë Helm shkon në krye të Kubernetes. Kjo do të thotë, ky nuk është një lloj sistemi që qëndron mënjanë, por thjesht një shërbim tjetër i nisur brenda kubit. Ju ndërveproni me të nëpërmjet API-së së tij nëpërmjet një komande tastierë. Komoditeti dhe bukuria e tij është se edhe nëse timoni prishet ose e hiqni atë nga grupi, shërbimet tuaja nuk do të zhduken, pasi timoni në thelb shërben vetëm për të nisur sistemin. Vetë Kubernetes është më pas përgjegjës për performancën dhe gjendjen e shërbimeve.

Këtë e kuptuam edhe ne shabllonizimi, të cilën më parë ishim të detyruar ta bënim vetë duke futur xhinxha në konfigurimet tona, është një nga tiparet kryesore të timonit. Të gjitha konfigurimet që krijoni për sistemet tuaja ruhen në krye në formën e shablloneve, pak të ngjashme me jinja, por, në fakt, duke përdorur shabllonin e gjuhës Go, në të cilën shkruhet helmi, si Kubernetes.

Helm shton disa koncepte të tjera për ne.

Chart - ky është një përshkrim i shërbimit tuaj. Në menaxherët e tjerë të paketave do të quhej një paketë, paketë ose diçka e ngjashme. Këtu quhet grafiku.

Vlerat janë variablat që dëshironi të përdorni për të ndërtuar konfigurimet tuaja nga shabllonet.

Lirimin. Çdo herë që një shërbim që vendoset duke përdorur timonin merr një version shtesë të lëshimit. Helm kujton se çfarë ishte konfigurimi i shërbimit në versionin e mëparshëm, lëshimi para kësaj, e kështu me radhë. Prandaj, nëse keni nevojë të riktheheni, thjesht ekzekutoni komandën e kthimit të thirrjes së timonit, duke e drejtuar atë në versionin e mëparshëm të lëshimit. Edhe nëse konfigurimi përkatës në depon tuaj nuk është i disponueshëm në kohën e rikthimit, drejtuesi do të vazhdojë të kujtojë se çfarë ishte dhe do ta kthejë sistemin tuaj në gjendjen në të cilën ishte në versionin e mëparshëm.

Në rastin kur përdorim helm, konfigurimet e rregullta për Kubernetes shndërrohen gjithashtu në shabllone në të cilat është e mundur të përdoren variabla, funksione dhe të aplikohen deklarata të kushtëzuara. Në këtë mënyrë ju mund të mbledhni konfigurimin e shërbimit tuaj në varësi të mjedisit.

Në praktikë, vendosëm t'i bënim gjërat pak më ndryshe nga sa bëmë me Nomad. Nëse në Nomad të dy konfigurimet e vendosjes dhe n-variablat që nevojiteshin për të vendosur shërbimin tonë ruheshin në një depo, këtu vendosëm t'i ndajmë në dy depo të veçanta. Depoja "deploy" ruan vetëm n-ndryshore të nevojshme për vendosjen dhe depoja "helm" ruan konfigurimet ose grafikët.

Çfarë na dha kjo?

Pavarësisht nga fakti se ne nuk ruajmë ndonjë të dhënë vërtet të ndjeshme në vetë skedarët e konfigurimit. Për shembull, fjalëkalimet në bazat e të dhënave. Ato ruhen si sekrete në Kubernetes, por megjithatë, ka ende disa gjëra atje që ne nuk duam t'u japim akses të gjithëve. Prandaj, qasja në depo "deploy" është më e kufizuar, dhe depoja "helm" thjesht përmban një përshkrim të shërbimit. Për këtë arsye, ai mund të aksesohet në mënyrë të sigurt nga një gamë më e gjerë njerëzish.

Meqenëse ne kemi jo vetëm prodhimin, por edhe mjedise të tjera, falë kësaj ndarjeje ne mund të ripërdorim tabelat tona të timonit për të vendosur shërbime jo vetëm në prodhim, por gjithashtu, për shembull, në një mjedis QA. Edhe për t'i vendosur ato në nivel lokal duke përdorur Minikube - kjo është një gjë për drejtimin lokal të Kubernetes.

Brenda çdo depoje, ne lamë një ndarje në drejtori të veçanta për secilin shërbim. Kjo do të thotë, brenda çdo drejtorie ka shabllone që lidhen me grafikun përkatës dhe që përshkruajnë burimet që duhet të vendosen për të ekzekutuar sistemin tonë. Ne lamë vetëm envs në depon e "vendosjes". Në këtë rast, ne nuk kemi përdorur shabllon duke përdorur jinja, sepse vetë helmi ofron shabllon jashtë kutisë - ky është një nga funksionet e tij kryesore.

Ne lamë një skript vendosjeje - deploy.sh, i cili thjeshton dhe standardizon nisjen për vendosje duke përdorur timonin. Pra, për këdo që dëshiron të vendoset, ndërfaqja e vendosjes duket saktësisht e njëjtë me atë kur vendoset përmes Nomad. I njëjti deploy.sh, emri i shërbimit tuaj dhe ku dëshironi ta vendosni. Kjo bën që timoni të fillojë nga brenda. Ai, nga ana tjetër, mbledh konfigurime nga shabllonet, fut skedarët e vlerave të nevojshme në to, më pas i vendos ato, duke i lëshuar në Kubernetes.

Gjetjet

Shërbimi Kubernetes duket të jetë më kompleks se Nomad.

Këtu trafiku dalës vjen në Ingress. Ky është vetëm kontrolluesi i përparmë, i cili merr përsipër të gjitha kërkesat dhe më pas i dërgon ato në shërbimet që korrespondojnë me të dhënat e kërkesës. Ai i përcakton ato bazuar në konfigurimet që janë pjesë e përshkrimit të aplikacionit tuaj në krye dhe që zhvilluesit i vendosin vetë. Shërbimi dërgon kërkesa në podet e tij, domethënë kontejnerë të veçantë, duke balancuar trafikun hyrës midis të gjithë kontejnerëve që i përkasin këtij shërbimi. Dhe, sigurisht, nuk duhet të harrojmë se nuk duhet të shkojmë askund nga siguria në nivelin e rrjetit. Prandaj, segmentimi funksionon në një grup Kubernetes, i cili bazohet në etiketimin. Të gjitha shërbimet kanë etiketa të caktuara me të cilat lidhen të drejtat e aksesit të shërbimeve në burime të caktuara të jashtme/të brendshme brenda ose jashtë grupit.

Ndërsa bëmë tranzicionin, pamë që Kubernetes kishte të gjitha aftësitë e Nomad, të cilat ne i kishim përdorur më parë, dhe gjithashtu shtuam shumë gjëra të reja. Mund të zgjerohet përmes shtojcave, dhe në fakt përmes llojeve të burimeve të personalizuara. Kjo do të thotë, ju keni mundësinë jo vetëm të përdorni diçka që vjen me Kubernetes jashtë kutisë, por të krijoni burimin dhe shërbimin tuaj që do të lexojë burimin tuaj. Kjo ju jep mundësi shtesë për të zgjeruar sistemin tuaj pa pasur nevojë të riinstaloni Kubernetes dhe pa kërkuar modifikime.

Një shembull i një përdorimi të tillë është Prometheus, i cili funksionon brenda grupit tonë Kubernetes. Në mënyrë që ai të fillojë të mbledhë metrikë nga një shërbim i caktuar, ne duhet të shtojmë një lloj burimi shtesë, të ashtuquajturin monitor shërbimi, në përshkrimin e shërbimit. Prometheus, për shkak të faktit se mund të lexojë një lloj burimi të personalizuar kur lançohet në Kubernetes, fillon automatikisht të mbledhë metrikë nga sistemi i ri. Është mjaft i përshtatshëm.

Vendosja e parë që bëmë në Kubernetes ishte në mars 2018. Dhe gjatë kësaj kohe nuk kemi pasur kurrë ndonjë problem me të. Punon mjaft stabile pa defekte të rëndësishme. Përveç kësaj, ne mund ta zgjerojmë atë më tej. Sot kemi mjaft nga aftësitë që ka dhe na pëlqen shumë ritmi i zhvillimit të Kubernetes. Aktualisht, më shumë se 3000 kontejnerë janë në Kubernetes. Grupi zë disa Nyje. Në të njëjtën kohë, ai është i përdorshëm, i qëndrueshëm dhe shumë i kontrollueshëm.

Burimi: www.habr.com