Hi almal! My naam is Pavel Agaletsky. Ek werk as 'n spanleier in 'n span wat die Lamoda-afleweringstelsel ontwikkel. In 2018 het ek by die HighLoad ++-konferensie gepraat, en vandag wil ek 'n transkripsie van my verslag aanbied.

My onderwerp is gewy aan die ervaring van ons maatskappy in die implementering van stelsels en dienste na verskillende omgewings. Vanaf ons prehistoriese tye, toe ons alle stelsels in gewone virtuele bedieners ontplooi het, eindig met 'n geleidelike oorgang van Nomad na Kubernetes-ontplooiing. Ek sal jou vertel hoekom ons dit gedoen het en watter probleme ons in die proses gehad het.

Ontplooi toepassings na VM

Kom ons begin met die feit dat 3 jaar gelede al die stelsels en dienste van die maatskappy op gewone virtuele bedieners ontplooi is. Tegnies is dit so georganiseer dat al die kode van ons stelsels lê en saamgestel is met behulp van outomatiese monteergereedskap, met behulp van jenkins. Met die hulp van Ansible is dit reeds van ons weergawebeheerstelsel na virtuele bedieners uitgerol. Terselfdertyd is elke stelsel wat in ons maatskappy was, na ten minste 2 bedieners ontplooi: een van hulle - op kop, die tweede - op stert. Hierdie twee stelsels was absoluut identies aan mekaar in al hul instellings, krag, konfigurasie ensovoorts. Die enigste verskil tussen hulle was dat kop gebruikersverkeer ontvang het, terwyl stert nooit gebruikersverkeer vir homself ontvang het nie.

Waarvoor was dit?

Toe ons nuwe vrystellings van ons toepassing ontplooi het, wou ons naatloos uitrol, dit wil sê sonder merkbare gevolge vir gebruikers. Dit is bereik as gevolg van die feit dat die volgende saamgestelde vrystelling met behulp van Ansible na die stert uitgerol is. Daar kon die mense wat by die ontplooiing betrokke was, kyk en seker maak dat alles reg is: alle maatstawwe, afdelings en toepassings werk; die nodige skrifte word geloods. Eers nadat hulle oortuig was dat alles reg is, het die verkeer oorgeskakel. Hy het begin om na die bediener te gaan wat voorheen stert was. En die een wat voorheen die hoof was, het sonder gebruikersverkeer gebly, terwyl die vorige weergawe van ons toepassing daarop beskikbaar was.

Dit was dus naatloos vir gebruikers. Omdat die oorskakeling oombliklik is, aangesien dit net 'n balanseerderskakeling is. Dit is baie maklik om terug te draai na die vorige weergawe deur eenvoudig die balanseerder terug te skakel. Ons kon ook seker maak dat die toepassing gereed was vir produksie nog voordat die gebruikersverkeer daarnatoe gegaan het, wat redelik gerieflik was.

Watter deugde sien ons in dit alles?

1. Eerstens is dit genoeg werk net. Almal verstaan ​​hoe so 'n ontplooiingskema werk, want die meeste mense het al ooit na gewone virtuele bedieners ontplooi.
2. Dit is genoeg veilig, aangesien die ontplooiingstegnologie eenvoudig is, getoets deur duisende maatskappye. Miljoene bedieners word op hierdie manier ontplooi. Dit is moeilik om iets te breek.
3. En uiteindelik kon ons kry atoomontplooiings. Ontplooiings wat gelyktydig vir gebruikers plaasvind, sonder 'n merkbare stadium van omskakeling tussen die ou weergawe en die nuwe een.

Maar ons het ook verskeie tekortkominge in hierdie alles gesien:

1. Benewens die produksie-omgewing, die ontwikkelingsomgewing, is daar ander omgewings. Byvoorbeeld, qa en voorproduksie. Op daardie tydstip het ons baie bedieners en ongeveer 60 dienste gehad. Om hierdie rede moes dit vir elke diens, handhaaf die nuutste weergawe daarvoor virtuele masjien. Verder, as jy biblioteke wil opdateer of nuwe afhanklikhede wil installeer, moet jy dit in alle omgewings doen. Dit was ook nodig om die tyd wanneer jy die volgende nuwe weergawe van jou toepassing gaan ontplooi te sinchroniseer met die tyd wanneer devops die nodige omgewingsinstellings uitvoer. In hierdie geval is dit maklik om in 'n situasie te kom waar ons omgewing op een slag ietwat anders sal wees in alle omgewings in 'n ry. Byvoorbeeld, in 'n QA-omgewing sal daar sommige weergawes van biblioteke wees, en in produksie - ander, wat tot probleme sal lei.
2. Moeilik om afhanklikhede op te dateer jou aansoek. Dit hang nie van jou af nie, maar van die ander span. Naamlik van die devops-span wat die bedieners onderhou. Jy moet hulle 'n gepaste taak gee en beskryf wat jy wil doen.
3. Op daardie stadium wou ons ook die groot groot monoliete wat ons gehad het in aparte klein dienste verdeel, aangesien ons verstaan ​​het dat daar meer en meer van hulle sou wees. Op daardie stadium het ons reeds meer as 100 van hulle gehad.Dit was nodig om 'n aparte nuwe virtuele masjien vir elke nuwe diens te skep, wat ook gediens en ontplooi moes word. Daarbenewens het jy nie een motor nodig nie, maar ten minste twee. Hierby word alles 'n QA-omgewing gevoeg. Dit veroorsaak probleme en maak dit vir jou moeiliker om nuwe stelsels te bou en te bestuur. komplekse, duur en lang proses.

Daarom het ons besluit dat dit geriefliker sou wees om van die ontplooiing van gewone virtuele masjiene na die implementering van ons toepassings in 'n dokhouer te beweeg. As jy docker het, het jy 'n stelsel nodig wat die toepassing in 'n groep kan laat loop, aangesien jy nie net 'n houer net so kan oprig nie. Gewoonlik wil jy tred hou met hoeveel houers opgelig word sodat dit outomaties opgelig word. Om hierdie rede moes ons 'n beheerstelsel kies.

Ons het lank en hard gedink watter een om te neem. Die feit is dat hierdie ontplooiingsstapel op daardie tydstip na gewone virtuele bedieners ietwat verouderd was, aangesien daar nie die nuutste weergawes van bedryfstelsels was nie. Op 'n stadium was selfs FreeBSD daar, wat nie baie gerieflik was om te onderhou nie. Ons het verstaan ​​dat ons so gou moontlik na docker moes migreer. Ons devops het na hul ervaring met verskillende oplossings gekyk en 'n stelsel soos Nomad gekies.

Skakel oor na Nomad

Nomad is 'n produk van HashiCorp. Hulle is ook bekend vir hul ander oplossings:

Konsul is 'n hulpmiddel vir diensontdekking.

"Terraform" - 'n stelsel vir die bestuur van bedieners wat jou toelaat om hulle te konfigureer deur 'n konfigurasie, die sogenaamde infrastruktuur-as-'n-kode.

Swerwer laat jou toe om virtuele masjiene plaaslik of in die wolk te ontplooi deur spesifieke konfigurasielêers.

Nomad het destyds na 'n redelik eenvoudige oplossing gelyk waarna jy vinnig kan oorskakel sonder om die hele infrastruktuur te verander. Boonop is dit redelik maklik om te leer. Daarom het ons dit as die filterstelsel vir ons houer gekies.

Wat het u nodig om u stelsel in Nomad te ontplooi?

1. Eerstens moet jy docker beeld jou aansoek. U moet dit bou en in die docker-beeldwinkel plaas. In ons geval is dit artifactory - 'n stelsel wat jou toelaat om verskeie artefakte van verskillende soorte daarin te druk. Dit kan argiewe, docker-beelde, PHP-komponispakkette, NPM-pakkette, ensovoorts stoor.
2. Ook nodig konfigurasie lêer, wat vir Nomad sal vertel wat, waar en hoeveel jy wil ontplooi.

As ons oor Nomad praat, gebruik dit die HCL-taal as 'n inligtinglêerformaat, wat staan ​​vir HashiCorp-konfigurasietaal. Dit is 'n superset van Yaml wat jou toelaat om jou diens in terme van Nomad te beskryf.

Dit laat jou toe om te sê hoeveel houers jy wil ontplooi, van watter beelde om verskeie parameters na hulle oor te dra tydens ontplooiing. So jy voer hierdie lêer aan Nomad, en dit begin houers na produksie daarvolgens.

In ons geval het ons besef dat dit nie baie gerieflik sou wees om presies dieselfde, identiese HCL-lêers vir elke diens te skryf nie, want daar is baie dienste en soms wil jy dit opdateer. Dit gebeur dat een diens nie in een geval ontplooi word nie, maar in 'n verskeidenheid verskillendes. Byvoorbeeld, een van die stelsels wat ons in produksie het, het meer as 100 gevalle in produksie. Hulle loop vanaf dieselfde beelde, maar verskil in konfigurasie-instellings en konfigurasielêers.

Daarom het ons besluit dat dit vir ons gerieflik sou wees om al ons konfigurasielêers vir ontplooiing in een gemeenskaplike bewaarplek te stoor. Op hierdie manier het hulle sigbaar geword: hulle was maklik om te onderhou en jy kon sien watter soort stelsels ons het. Indien nodig, is dit ook maklik om iets op te dateer of te verander. Om 'n nuwe stelsel by te voeg is ook nie moeilik nie - voeg net 'n konfigurasielêer binne die nuwe gids by. Binne-in is lêers: service.hcl, wat 'n beskrywing van ons diens bevat, en sommige env-lêers wat toelaat dat hierdie einste diens, wat in produksie ontplooi word, gekonfigureer word.

Sommige van ons stelsels word egter nie in een kopie in produksie ontplooi nie, maar in verskeie gelyktydig. Daarom het ons besluit dat dit vir ons gerieflik sou wees om konfigurasies nie in hul suiwer vorm te stoor nie, maar hul sjabloonvorm. En as die sjabloontaal wat ons gekies het jinja 2. In hierdie formaat stoor ons beide die konfigurasies van die diens self en die env-lêers wat daarvoor nodig is.

Daarbenewens het ons 'n ontplooiingskrip in die bewaarplek geplaas wat algemeen is vir alle projekte, wat jou toelaat om jou diens in produksie, in die regte omgewing, in die regte teiken te begin en te ontplooi. In die geval toe ons ons HCL-konfigurasie in 'n sjabloon verander het, het die HCL-lêer, wat voorheen die gewone Nomad-konfigurasie was, in hierdie geval 'n bietjie anders begin lyk.

Dit wil sê, ons het 'n paar konfigurasie plek veranderlikes vervang met veranderlike invoegings wat geneem is van env lêers of van ander bronne. Daarbenewens het ons die vermoë gekry om HCL-lêers dinamies te bou, dit wil sê, ons kan nie net die gewone veranderlike insetsels gebruik nie. Aangesien jinja siklusse en toestande ondersteun, kan u ook konfigurasielêers daar plaas, wat verander na gelang van presies waar u u toepassings ontplooi.

Byvoorbeeld, jy wil jou diens na voorproduksie en produksie ontplooi. Kom ons sê dat jy in voorproduksie nie cron-skripte wil laat loop nie, maar net die diens op 'n aparte domein wil sien om seker te maak dit werk. Vir enigiemand wat 'n diens ontplooi, is die proses baie eenvoudig en deursigtig. Dit is genoeg om die deploy.sh-lêer uit te voer, spesifiseer watter diens jy wil ontplooi en na watter teiken. U wil byvoorbeeld een of ander stelsel na Rusland, Wit-Rusland of Kazakstan ontplooi. Om dit te doen, verander eenvoudig een van die parameters, en jy sal die korrekte konfigurasielêer hê.

Wanneer die Nomad-diens reeds in u groepering ontplooi is, lyk dit so.

Om mee te begin, benodig u 'n lasbalanseerder van buite, wat alle gebruikersverkeer in homself sal neem. Dit sal saam met Consul werk en daaruit leer waar, op watter nodus, op watter IP-adres 'n spesifieke diens geleë is, wat ooreenstem met 'n bepaalde domeinnaam. Dienste in Consul kom van Nomad self. Aangesien dit produkte van dieselfde maatskappy is, is hulle goed verbind. Ons kan sê dat Nomad uit die boks alle dienste wat daarin bekendgestel is, binne Consul kan registreer.

Nadat jou eksterne balanseerder weet na watter diens om verkeer te stuur, herlei dit dit na die toepaslike houer of veelvuldige houers wat by jou toepassing pas. Natuurlik is dit nodig om ook aan veiligheid te dink. Alhoewel alle dienste op dieselfde virtuele masjiene in houers werk, vereis dit gewoonlik dat enige diens gratis toegang tot enige ander geweier word. Ons het dit bereik deur segmentering. Elke diens is in sy eie virtuele netwerk bekendgestel, waarop roeteerreëls en reëls geskryf is om toegang tot ander stelsels en dienste toe te laat/weier. Hulle kan beide binne hierdie groep en daarbuite wees. As jy byvoorbeeld wil verhoed dat 'n diens aan 'n spesifieke databasis koppel, kan dit gedoen word deur op netwerkvlak te segmenteer. Dit wil sê, selfs per ongeluk kan jy nie per ongeluk van die toetsomgewing na jou produksiebasis koppel nie.

Hoeveel het die oorgang ons gekos in terme van menslike hulpbronne?

Ongeveer 5-6 maande het die oorgang van die hele maatskappy na Nomad geneem. Ons het diens-vir-diens geskuif, maar teen 'n redelik vinnige pas. Elke span moes hul eie dienshouers skep.

Ons het so 'n benadering aangeneem dat elke span onafhanklik verantwoordelik is vir die koppelaarbeelde van hul stelsels. Devops, aan die ander kant, verskaf die algemene infrastruktuur wat nodig is vir ontplooiing, dit wil sê ondersteuning vir die cluster self, ondersteuning vir die CI-stelsel, ensovoorts. En op daardie tydstip het ons meer as 60 stelsels na Nomad laat verskuif, wat blykbaar ongeveer 2 duisend houers was.

DevOps is verantwoordelik vir die algehele infrastruktuur van alles wat met ontplooiing verband hou, met bedieners. En elke ontwikkelingspan is op sy beurt verantwoordelik vir die implementering van houers vir hul spesifieke stelsel, aangesien dit die span is wat weet wat dit oor die algemeen in 'n spesifieke houer benodig.

Redes om Nomad te verlaat

Watter voordele het ons gekry deur ook oor te skakel na ontplooiing deur Nomad en docker te gebruik?

1. Ons is dieselfde voorwaardes verskaf vir alle omgewings. In ontwikkeling, QA-omgewing, voorproduksie, produksie, word dieselfde houerbeelde gebruik, met dieselfde afhanklikhede. Gevolglik het jy feitlik geen kans dat iets anders as wat jy voorheen plaaslik of op 'n toetsomgewing getoets het in produksie sal uitdraai nie.
2. Ons het ook gevind dat dit genoeg is maklik om 'n nuwe diens by te voeg. Enige nuwe stelsels in terme van ontplooiing word baie eenvoudig bekendgestel. Dit is genoeg om na die bewaarplek te gaan wat die konfigurasies stoor, die volgende konfigurasie vir jou stelsel daar by te voeg, en jy is gereed. U kan u stelsel na produksie ontplooi sonder ekstra moeite van devops.
3. Alle konfigurasie lêers in een gedeelde bewaarplek blyk oorgesien te word. Op die oomblik toe ons ons stelsels met behulp van virtuele bedieners ontplooi het, het ons Ansible gebruik, waarin die konfigurasies in dieselfde bewaarplek was. Vir die meeste ontwikkelaars was dit egter 'n bietjie moeiliker om mee te werk. Hier het die volume konfigurasies en kode wat u moet byvoeg om die diens te ontplooi baie kleiner geword. Plus vir devops is dit baie maklik om dit reg te maak of te verander. In die geval van oorgange, byvoorbeeld, na 'n nuwe weergawe van Nomad, kan hulle al die bedryfslêers wat op dieselfde plek lê, op groot skaal opdateer.

Maar ons het ook verskeie nadele teëgekom:

Dit het geblyk dat ons kon nie naatlose ontplooiings bereik nie in die geval van Nomad. Wanneer houers uit verskillende toestande uitgerol word, kon dit gebeur dat dit blyk te loop, en Nomad het dit beskou as 'n houer wat gereed is om verkeer te ontvang. Dit het gebeur nog voordat die toepassing daarin tyd gehad het om te begin. Om hierdie rede het die stelsel vir 'n kort tyd 500 foute begin uitreik, omdat die verkeer na die houer begin gaan het, wat nog nie gereed was om dit te aanvaar nie.

Ons het 'n paar teëgekom goggas. Die belangrikste fout is dat Nomad nie 'n groot groepie baie goed hanteer as jy baie stelsels en houers het nie. Wanneer jy een van die bedieners wat by die Nomad-groepering ingesluit is in diens wil neem, is daar 'n redelike groot waarskynlikheid dat die groep nie baie goed sal voel en uitmekaar val nie. Sommige houers kan byvoorbeeld val en nie styg nie - dit sal jou later baie kos as al jou stelsels in produksie in 'n Nomad-bestuurde groep geleë is.

Daarom het ons besluit om te dink waarheen ons volgende moet gaan. Op daardie tydstip het ons baie meer bewus geword van wat ons wil bereik. Ons wil naamlik betroubaarheid hê, 'n bietjie meer kenmerke as wat Nomad gee, en 'n meer volwasse, meer stabiele stelsel.

In hierdie verband het ons keuse geval op Kubernetes as die gewildste platform vir die bestuur van groepe. Veral gegewe dat die grootte en aantal van ons houers groot genoeg was. Vir sulke doeleindes het Kubernetes gelyk na die mees geskikte stelsel van dié waarna ons kon kyk.

Verhuis na Kubernetes

Ek sal 'n bietjie praat oor wat die basiese konsepte van Kubernetes is en hoe dit van Nomad verskil.

Eerstens, die mees basiese konsep in Kubernetes is die konsep van peul. Pod is 'n groep van een of meer houers wat altyd saam begin. En hulle werk asof altyd streng op dieselfde virtuele masjien. Hulle is vir mekaar beskikbaar deur IP-adres 127.0.0.1 op verskillende poorte.

Kom ons sê jy het 'n PHP-toepassing wat bestaan ​​uit nginx en php-fpm - die klassieke patroon. Heel waarskynlik sal jy wil hê dat beide nginx- en php-fpm-houers altyd bymekaar moet wees. Kubernetes laat jou toe om dit te bereik deur hulle as een algemene peul te beskryf. Dit is presies wat ons nie met Nomad kon kry nie.

Die tweede konsep is ontplooiing. Die punt is dat die peul self 'n kortstondige ding is, dit begin en verdwyn. Of jy nou eers al jou vorige houers wil doodmaak, en dan dadelik nuwe weergawes wil bekendstel, of jy dit geleidelik wil uitrol – dit is juis die konsep van ontplooiing wat vir hierdie proses verantwoordelik is. Dit beskryf hoe jy jou peule ontplooi, hoeveel en hoe om hulle op te dateer.

Die derde konsep is diens. Jou diens is eintlik jou stelsel wat 'n bietjie verkeer inneem en dit dan na een of meer peule stuur wat ooreenstem met jou diens. Dit wil sê, dit laat jou toe om te sê dat alle inkomende verkeer na so en so 'n diens met so en so 'n naam na hierdie spesifieke peule gestuur moet word. En terselfdertyd bied dit jou verkeersbalansering. Dit wil sê, jy kan twee peule van jou toepassing laat loop, en alle inkomende verkeer sal eweredig gebalanseer word tussen die peule wat met hierdie diens verband hou.

En die vierde basiese konsep - Ingang. Dit is 'n diens wat op 'n Kubernetes-kluster loop. Dit dien as 'n eksterne lasbalanseerder wat alle versoeke oorneem. Deur die Kubernetes API kan Ingress bepaal waarheen hierdie versoeke gestuur moet word. En hy doen dit baie buigsaam. Jy kan sê dat alle versoeke vir hierdie gasheer en so en so 'n URL na hierdie diens gestuur word. En hierdie versoeke wat na hierdie gasheer en na 'n ander URL kom, word na 'n ander diens gestuur.

Die coolste ding uit die oogpunt van iemand wat 'n toepassing ontwikkel, is dat jy dit alles self kan bestuur. Deur die Ingress-konfigurasie te stel, kan jy alle verkeer wat na so en so 'n API kom, na aparte houers stuur, byvoorbeeld geregistreer in Go. Maar hierdie verkeer wat na dieselfde domein kom, maar na 'n ander URL, word gestuur na houers wat in PHP geskryf is, waar daar baie logika is, maar hulle is nie baie vinnig nie.

As ons al hierdie konsepte met Nomad vergelyk, dan kan ons sê dat die eerste drie konsepte almal saam Diens is. En die laaste konsep is afwesig in Nomad self. Ons het 'n eksterne balanseerder soos dit gebruik: dit kan haproxy, nginx, nginx + en so aan wees. In die geval van 'n kubus hoef jy nie hierdie addisionele konsep afsonderlik bekend te stel nie. As jy egter na Ingress binne kyk, dan is dit óf nginx, óf haproxy, óf traefik, maar as 't ware in Kubernetes ingebou.

Al die konsepte wat ek beskryf het, is in werklikheid hulpbronne wat binne 'n Kubernetes-kluster bestaan. Om hulle in die kubus te beskryf, word die yaml-formaat gebruik, wat meer leesbaar en bekend is as HCL-lêers in die geval van Nomad. Maar struktureel beskryf hulle dieselfde ding in die geval van byvoorbeeld 'n peul. Hulle sê - ek wil sulke en sulke peule daar ontplooi, met sulke en sulke beelde, in so en sulke hoeveelheid.

Daarbenewens het ons besef dat ons nie elke individuele hulpbron met die hand wou skep nie: ontplooiing, dienste, Ingress, ensovoorts. In plaas daarvan wou ons ons elke stelsel beskryf in terme van Kubernetes tydens ontplooiing, sodat ons nie al die nodige hulpbronafhanklikhede handmatig in die regte volgorde hoef te herskep nie. Helm is gekies as so 'n stelsel wat ons toegelaat het om dit te doen.

Basiese konsepte in Helm

Helm is pakketbestuurder vir Kubernetes. Dit is baie soortgelyk aan hoe pakketbestuurders in programmeertale werk. Hulle laat jou toe om 'n diens te stoor wat bestaan ​​uit, byvoorbeeld, ontplooiing nginx, ontplooiing php-fpm, config for Ingress, configmaps (dit is 'n entiteit wat jou toelaat om env en ander parameters vir jou stelsel te stel) in die vorm van so- kaarte genoem. Terselfdertyd, Helm loop bo-op Kubernetes. Dit wil sê, dit is nie 'n soort stelsel wat opsy staan ​​nie, maar net nog 'n diens wat binne die kubus loop. U kommunikeer daarmee via sy API via 'n konsole-opdrag. Die gerief en sjarme daarvan is dat selfs as die stuur breek of jy dit uit die groep verwyder, jou dienste nie sal verdwyn nie, aangesien die stuur in wese net dien om die stelsel te begin. Kubernetes self is verder verantwoordelik vir die gesondheid en toestand van dienste.

Ons het dit ook besef sjabloon, wat ons tot dan op ons eie moes doen deur die bekendstelling van jinja in ons konfigurasies, is een van die hoofkenmerke van helm. Al die konfigurasies wat jy vir jou stelsels skep, word in helm gestoor as sjablone, 'n bietjie soos jinja, maar gebruik eintlik die sjabloon van die Go-taal waarin helm geskryf is, net soos Kubernetes.

Helm voeg nog 'n paar bykomende konsepte by ons.

Grafiek is 'n beskrywing van jou diens. In ander pakketbestuurders sou dit bondel, bondel of iets soortgelyks genoem word. Hier word dit grafiek genoem.

Waardes is die veranderlikes wat jy wil gebruik om jou konfigurasies van sjablone te bou.

Release. Elke keer kry 'n diens wat met stuur ontplooi 'n inkrementele weergawe van die vrystelling. Helm onthou wat die diensopstelling was vir die vorige weergawe, voorverlede jaar, ensovoorts. Daarom, as jy moet terugrol, voer net die stuur terugbelopdrag uit en wys dit na die vorige weergawe van die vrystelling. Selfs as die ooreenstemmende konfigurasie in jou bewaarplek nie beskikbaar is ten tyde van die terugrol nie, sal helm steeds onthou wat dit was en jou stelsel terugrol na die toestand wat dit in die vorige weergawe was.

In die geval wanneer ons stuur gebruik, verander die gewone konfigurasies vir Kubernetes ook in sjablone waarin dit moontlik is om veranderlikes, funksies te gebruik en voorwaardelike stellings toe te pas. U kan dus die konfigurasie van u diens insamel, afhangende van die omgewing.

In die praktyk het ons besluit om dinge 'n bietjie anders te doen as wat ons met Nomad gedoen het. As Nomad beide ontplooiingskonfigurasies en n-veranderlikes gestoor het wat nodig is om ons diens in een bewaarplek te ontplooi, dan het ons hier besluit om dit in twee afsonderlike bewaarplekke te verdeel. Die "ontplooi"-bewaarplek stoor slegs die n-veranderlikes wat nodig is vir ontplooiing, terwyl die "helm"-bewaarplek konfigurasies of kaarte stoor.

Wat het dit vir ons gegee?

Ten spyte van die feit dat ons geen werklik sensitiewe data in die konfigurasielêers self stoor nie. Byvoorbeeld, databasis wagwoorde. Hulle word as geheime in Kubernetes gestoor, maar nietemin is daar steeds aparte goed wat ons nie vir almal in 'n ry wil toegang gee nie. Daarom is toegang tot die "ontplooi"-bewaarplek meer beperk, en die "helm"-bewaarplek bevat net 'n beskrywing van die diens. Om hierdie rede kan dit veilig toegang verleen word aan 'n groter kring mense.

Aangesien ons nie net produksie het nie, maar ook ander omgewings, danksy hierdie skeiding, kan ons ons stuurkaarte hergebruik om dienste nie net na produksie te ontplooi nie, maar ook byvoorbeeld na 'n QA-omgewing. Selfs om hulle plaaslik te ontplooi met behulp van Minikube - dit is so iets om Kubernetes plaaslik te bestuur.

Binne elke bewaarplek het ons die verdeling in aparte gidse vir elke diens gelaat. Dit wil sê, binne elke gids is daar sjablone wat verband hou met die ooreenstemmende grafiek en wat die hulpbronne beskryf wat ontplooi moet word om ons stelsel te begin. In die "ontplooi"-bewaarplek het ons net afguns gelaat. In hierdie geval het ons nie jinja-sjabloon gebruik nie, want die stuur verskaf sjabloon uit die boks - dit is een van sy hoofkenmerke.

Ons het die ontplooiingskrip verlaat - deploy.sh, wat die bekendstelling vir ontplooiing met behulp van stuur vereenvoudig en standaardiseer. Dus, vir almal wat wil ontplooi, lyk die ontplooiingskoppelvlak presies dieselfde as wat dit was in die geval van ontplooiing deur Nomad. Dieselfde deploy.sh, die naam van jou diens, en waar jy dit wil ontplooi. Dit veroorsaak dat die stuur intern loop. Op sy beurt versamel hy konfigurasies van sjablone, vervang die nodige waardelêers daarin, ontplooi dit dan en begin dit in Kubernetes.

Bevindinge

Die Kubernetes-diens blyk meer kompleks te wees as Nomad.

Dit is waar uitgaande verkeer in Ingress kom. Dit is net die voorste kontroleerder, wat alle versoeke oorneem en dit dan na die dienste stuur wat ooreenstem met die versoekdata. Dit bepaal hulle op grond van konfigurasies wat deel is van die beskrywing van jou toepassing in stuur en wat ontwikkelaars self stel. Die diens, aan die ander kant, stuur versoeke na sy peule, dit wil sê spesifieke houers, en balanseer inkomende verkeer tussen alle houers wat aan hierdie diens behoort. En natuurlik moet ons nie vergeet dat ons nêrens van netwerkvlaksekuriteit moet gaan nie. Daarom werk segmentering in die Kubernetes-groepering, wat op tagging gebaseer is. Alle dienste het sekere etikette, waaraan die toegangsregte van dienste tot sekere eksterne / interne hulpbronne binne of buite die groepering geheg is.

Soos ons oorgeskakel het, het ons gesien dat Kubernetes al die kenmerke van die Nomad het wat ons tot dusver gebruik het, en ook baie nuwe goed byvoeg. Dit kan uitgebrei word deur inproppe, en in werklikheid deur pasgemaakte hulpbrontipes. Dit wil sê, jy het die geleentheid om nie net iets te gebruik wat saam met Kubernetes kom nie, maar om jou eie hulpbron en diens te skep wat jou hulpbron sal lees. Dit gee jou meer opsies om jou stelsel uit te brei sonder om Kubernetes weer te installeer en sonder om veranderinge aan te bring.

'n Voorbeeld van so 'n gebruik is Prometheus, wat ons binne 'n Kubernetes-kluster laat loop. Om metrieke van 'n spesifieke diens te begin versamel, moet ons 'n bykomende soort hulpbron by die diensbeskrywing voeg, die sogenaamde monitordiens. Prometheus, as gevolg van die feit dat dit kan lees, begin in Kubernetes, 'n pasgemaakte soort hulpbron, outomaties metrieke van die nuwe stelsel insamel. Dit is gerieflik genoeg.

Die eerste ontplooiing wat ons in Kubernetes gedoen het, was in Maart 2018. En gedurende hierdie tyd het ons nooit enige probleme met hom ervaar nie. Dit werk redelik stabiel sonder noemenswaardige foute. Boonop kan ons dit verder uitbrei. Tot op datum het ons genoeg van die vermoëns wat dit het, en ons hou baie van die tempo van ontwikkeling van Kubernetes. Op die oomblik is meer as 3000 houers in Kubernetes. Die groep beslaan verskeie nodes. Terselfdertyd is dit diensbaar, stabiel en baie beheerbaar.

Bron: will.com