Salut à tutti ! Mi chjamu Pavel Agaletsky. U travagliu cum'è un capu di squadra in una squadra chì sviluppa u sistema di consegna Lamoda. In 2018, aghju parlatu à a cunferenza HighLoad ++, è oghje vogliu presentà una trascrizione di u mo rapportu.

U mo tema hè dedicatu à l'esperienza di a nostra cumpagnia in implementazione di sistemi è servizii à diversi ambienti. Partendu da i nostri tempi preistorichi, quandu avemu implementatu tutti i sistemi in i servitori virtuali ordinali, finiscinu cù una transizione graduale da Nomad à implementazione Kubernetes. Vi dicu perchè l'avemu fattu è chì prublemi avemu avutu in u prucessu.

Implementa applicazioni in VM

Cuminciamu cù u fattu chì 3 anni fà tutti i sistemi è i servizii di a cumpagnia sò stati implementati nantu à i servitori virtuali ordinali. Tecnicamente, hè stata urganizata in tale manera chì tuttu u codice di i nostri sistemi stende è era assemblatu cù arnesi d'assemblea automatica, usendu jenkins. Cù l'aiutu di Ansible, hè statu digià rializatu da u nostru sistema di cuntrollu di versione à i servitori virtuali. À u listessu tempu, ogni sistema chì era in a nostra cumpagnia hè stata implementata à almenu 2 servitori: unu di elli - in capu, u sicondu - in tail. Questi dui sistemi eranu assulutamente identici l'un à l'altru in tutti i so paràmetri, putenza, cunfigurazione è cusì. L'unica diffarenza trà elli era chì u capu hà ricevutu u trafficu di l'utilizatori, mentre chì a cuda ùn hà mai ricevutu u trafficu d'utilizatori per ellu stessu.

Chì era per ?

Quandu avemu implementatu novi versioni di a nostra applicazione, avemu vulutu esse capace di stende senza saldatura, vale à dì, senza cunsequenze notevuli per l'utilizatori. Questu hè stata ottenuta per via di u fattu chì a prossima versione compilata cù Ansible hè stata lanciata à a cuda. Quì, e persone chì anu participatu à a implementazione puderanu verificà è assicuratevi chì tuttu hè bè: tutte e metriche, rùbbriche è applicazioni sò travagliendu; i scripts necessarii sò lanciati. Solu dopu ch'elli eranu cunvinti chì tuttu era bè, u trafficu hà cambiatu. Cuminciò à andà à u servitore chì era cuda prima. È quellu chì prima era u capu hè stata senza trafficu di l'utilizatori, mentre chì cù a versione precedente di a nostra applicazione dispunibule nantu à questu.

Dunque era senza saldatura per l'utilizatori. Perchè u cambiamentu hè istantaneu, postu chì hè solu un cambiamentu di balancer. Hè assai faciule di rinvià à a versione precedente semplicemente cambiendu u balancer. Pudemu ancu assicurà chì l'applicazione era pronta per a pruduzzione ancu prima chì u trafficu di l'utilizatori si n'andò, chì era abbastanza cunvene.

Chì virtù vedemu in tuttu questu ?

1. Prima di tuttu, hè abbastanza funziona solu. Tutti capiscenu cumu funziona un tali schema di implementazione, perchè a maiò parte di a ghjente hà mai implementatu à i servitori virtuali ordinali.
2. Questu hè abbastanza sicuramente, postu chì a tecnulugia di implementazione hè simplice, pruvata da millaie di cumpagnie. Milioni di servitori sò implementati in questu modu. Hè difficiule di rompe qualcosa.
3. È infine pudemu avè implementazioni atomiche. Impiegazioni chì si verificanu simultaneamente per l'utilizatori, senza una tappa notevuli di cambià trà a versione vechja è a nova.

Ma avemu vistu ancu parechje difetti in tuttu questu:

1. In più di l'ambiente di produzzione, l'ambiente di sviluppu, ci sò altri ambienti. Per esempiu, qa è preproduzione. À quellu tempu, avemu avutu assai servitori è circa 60 servizii. Per questu mutivu hà avutu per ogni serviziu, mantene l'ultima versione per questu macchina virtuale. Inoltre, se vulete aghjurnà e biblioteche o installà novi dipendenze, avete bisognu di fà questu in tutti l'ambienti. Era ancu necessariu di sincronizà l'ora quandu avete da implementà a prossima nova versione di a vostra applicazione cù u tempu quandu Devops realiza i paràmetri di l'ambiente necessarii. In questu casu, hè faciule d'entra in una situazione induve u nostru ambiente serà un pocu sfarente à una volta in tutti l'ambienti in una fila. Per esempiu, in un ambiente QA ci sarà qualchi versioni di biblioteche, è in pruduzzione - altri, chì portanu à prublemi.
2. Difficultà à aghjurnà e dipendenze a vostra applicazione. Ùn dipende micca di voi, ma di l'altru squadra. Vale à dì da a squadra di devops chì mantene i servitori. Duvete dà li un compitu appropritatu è discrive ciò chì vulete fà.
3. À quellu tempu, avemu ancu vulsutu sparte i grandi monoliti grossi chì avemu avutu in servizii chjuchi separati, cum'è avemu capitu chì ci seranu più è più di elli. À quellu tempu, avemu digià avutu più di elli 100. Era necessariu di creà una nova macchina virtuale separata per ogni novu serviziu, chì hà ancu bisognu à esse servitu è ​​implementatu. Inoltre, ùn avete micca bisognu di una vittura, ma almenu dui. À questu tuttu hè aghjuntu un ambiente QA. Questu causa prublemi è rende più difficiule per voi di custruisce è eseguite novi sistemi. prucessu cumplessu, costosu è longu.

Dunque, avemu decisu chì saria più còmuda di passà da implementà e macchine virtuali ordinarie à implementà e nostre applicazioni in un containeru docker. Se tenete docker, avete bisognu di un sistema chì pò eseguisce l'applicazione in un cluster, postu chì ùn pudete micca ghjustu un containeru cusì cusì. Di solitu vulete tene traccia di quanti cuntenituri sò alzati in modu chì sò alzati automaticamente. Per quessa, avemu avutu a sceglie un sistema di cuntrollu.

Avemu pensatu longu è duramente à quale piglià. U fattu hè chì in quellu tempu sta stack di implementazione à i servitori virtuali ordinali era un pocu obsoleta, postu chì ùn ci era micca l'ultime versioni di sistemi operativi. À un certu puntu, ancu FreeBSD era quì, chì ùn era micca assai cunvenutu per sustene. Avemu capitu chì avemu bisognu di migrà à docker u più prestu pussibule. I nostri devops anu vistu a so sperienza cù diverse suluzioni è hà sceltu un sistema cum'è Nomad.

Passendu à Nomad

Nomad hè un pruduttu di HashiCorp. Sò ancu cunnisciuti per e so altre soluzioni:

Consul hè un strumentu per a scuperta di serviziu.

"Terraform" - un sistema per a gestione di i servitori chì permette di cunfigurà elli attraversu una cunfigurazione, a chjamata infrastruttura-as-a-code.

Vagabondu permette di implementà e macchine virtuali in u locu o in u nuvulu attraversu schedarii di cunfigurazione specifichi.

Nomad à quellu tempu pareva una soluzione abbastanza simplice chì pudete cambià rapidamente senza cambià l'infrastruttura sana. In più, hè abbastanza faciule d'amparà. Dunque, avemu sceltu cum'è u sistema di filtrazione per u nostru containeru.

Chì avete bisognu per implementà u vostru sistema in Nomad?

1. Prima di tuttu, avete bisognu imagine docker a vostra applicazione. Avete bisognu di custruisce è mette in u magazinu di l'imaghjini docker. In u nostru casu, questu hè un artifactory - un sistema chì vi permette di spinghje diversi artefatti di varii tipi. Puderà almacenà archivi, imagine docker, pacchetti di cumpusitori PHP, pacchetti NPM, etc.
2. Hè ancu necessariu schedariu di cunfigurazione, chì dicerà à Nomad ciò chì, induve è quantu vulete implementà.

Quandu parlemu di Nomad, usa a lingua HCL cum'è un furmatu di u schedariu d'infurmazione, chì significa Lingua di cunfigurazione HashiCorp. Hè un superset di Yaml chì vi permette di discrive u vostru serviziu in termini di Nomad.

Permette di dì quanti cuntenituri vulete implementà, da quale l'imaghjini per trasfirià parechji paràmetri à elli durante a implementazione. Allora alimentate stu schedariu à Nomad, è lancia cuntenituri à a pruduzzione secondu questu.

In u nostru casu, avemu capitu chì ghjustu scrive esattamente u listessu, i schedari HCL idèntica per ogni serviziu ùn saria assai còmuda, perchè ci sò assai servizii è à volte vulete aghjurnà. Succede chì un serviziu hè implementatu micca in un casu, ma in una varietà di diversi. Per esempiu, unu di i sistemi chì avemu in produzzione hà più di 100 casi in produzzione. Eseguinu da e stesse imagine, ma sò diffirenti in i paràmetri di cunfigurazione è i schedarii di cunfigurazione.

Dunque, avemu decisu chì seria cunvene per noi di almacenà tutti i nostri fugliali di cunfigurazione per a implementazione in un repositoriu cumuni. In questu modu, diventenu visibili: eranu faciuli di mantene è pudete vede chì tipu di sistemi avemu. Se necessariu, hè ancu faciule d'aghjurnà o cambià qualcosa. Aghjunghje un novu sistema ùn hè ancu micca difficiule - basta aghjunghje un schedariu di cunfigurazione in u novu cartulare. Dentru ci sò i schedarii: service.hcl, chì cuntene una descrizzione di u nostru serviziu, è certi schedarii env chì permettenu à stu serviziu, chì hè implementatu in a produzzione, per esse cunfigurati.

Tuttavia, alcuni di i nostri sistemi sò implementati in a produzzione micca in una copia, ma in parechje à una volta. Per quessa, avemu decisu chì saria cunvene per noi di almacenà micca i cunfigurazioni in a so forma pura, ma a so forma template. È cum'è a lingua di mudellu avemu sceltu jinja 2. In questu formatu, guardemu sia i cunfigurazioni di u serviziu stessu è i schedarii env necessarii per questu.

Inoltre, avemu postu in u repository un script di implementazione chì hè cumunu per tutti i prughjetti, chì vi permette di lancià è implementà u vostru serviziu in a pruduzzione, in l'ambienti ghjustu, in u scopu ghjustu. In u casu quandu avemu turnatu a nostra cunfigurazione HCL in un mudellu, dopu u schedariu HCL, chì prima era u solitu Nomad config, in questu casu hà cuminciatu à vede un pocu sfarente.

Vale à dì, avemu rimpiazzatu alcune variabili di u locu di cunfigurazione cù inseriti variabili chì sò pigliati da i schedarii env o da altre fonti. Inoltre, avemu avutu a capacità di custruisce i schedarii HCL dinamicamente, vale à dì, pudemu usà micca solu l'inserzioni variabili di solitu. Siccomu jinja sustene i cicli è e cundizioni, pudete ancu mette i fugliali di cunfigurazione quì, chì cambianu secondu induve esattamente implementate e vostre applicazioni.

Per esempiu, vulete implementà u vostru serviziu à a pre-produzione è a produzzione. Diciamu chì in pre-produzione ùn vulete micca eseguisce script cron, ma solu vulete vede u serviziu nantu à un duminiu separatu per assicurà chì hè in esecuzione. Per qualchissia chì implementa un serviziu, u prucessu hè assai simplice è trasparente. Hè abbastanza per eseguisce u schedariu deploy.sh, specificate quale serviziu vulete implementà è à quale destinazione. Per esempiu, vulete implementà qualchì sistema in Russia, Bielorussia o Kazakhstan. Per fà questu, cambiate solu unu di i paràmetri, è avete u schedariu di cunfigurazione curretta.

Quandu u serviziu Nomad hè digià implementatu in u vostru cluster, pare cusì.

Per principià, avete bisognu di un equilibratore di carica da l'esternu, chì pigliarà tuttu u trafficu di l'utilizatori in sè stessu. Ci hà da travaglià inseme cun Consul è amparà da induve, nantu à quale node, à quale indirizzu IP hè situatu un serviziu particulari, chì currisponde à un nome di duminiu particulare. I servizii in Consul venenu da Nomad stessu. Siccomu questi sò prudutti di a listessa cumpagnia, sò bè ​​cunnessi. Pudemu dì chì fora di a scatula Nomad hè capaci di registrà tutti i servizii lanciati in questu in Consul.

Dopu chì u vostru equilibratore esternu sapi à quale serviziu mandà u trafficu, u reindirizza à u cuntainer appropritatu o à parechji cuntenituri chì currispondenu à a vostra applicazione. Naturalmente, hè necessariu di pensà ancu à a sicurità. Ancu s'è tutti i servizii funzionanu nantu à e stesse macchine virtuali in cuntenituri, questu generalmente richiede chì vi ricusate l'accessu liberu da qualsiasi serviziu à qualsiasi altru. Avemu ottenutu questu attraversu a segmentazione. Ogni serviziu hè stata lanciata in a so propria reta virtuale, nantu à quale sò state scritte e regule di routing è e regule per permette / nigà l'accessu à altri sistemi è servizii. Puderanu esse sia in questu cluster sia fora di questu. Per esempiu, sè vo vulete impedisce à un serviziu di cunnette à una basa di dati particulari, questu pò esse fattu per segmentà à u livellu di a rete. Questu hè, ancu per sbagliu, ùn pudete micca cunnette accidentalmente da l'ambiente di prova à a vostra basa di produzzione.

Quantu ci costava a transizione in termini di risorse umane ?

Circa 5-6 mesi hà pigliatu a transizione di tutta a cumpagnia à Nomad. Avemu spustatu serviziu per serviziu, ma à un ritmu abbastanza veloce. Ogni squadra avia da creà i so cuntenituri di serviziu.

Avemu aduttatu un tali approcciu chì ogni squadra hè rispunsevule per l'imaghjini docker di i so sistemi indipindente. Devops, invece, furnisce l'infrastruttura generale necessaria per a implementazione, vale à dì, supportu per u cluster stessu, supportu per u sistema CI, etc. È à quellu tempu, avemu avutu più di 60 sistemi trasfirìu à Nomad, chì hè diventatu circa 2 mila cuntainer.

DevOps hè rispunsevuli di l'infrastruttura generale di tuttu ciò chì riguarda l'implementazione, cù i servitori. È ogni squadra di sviluppu, à u turnu, hè rispunsevuli di implementà cuntenituri per u so sistema specificu, postu chì hè a squadra chì sà ciò chì generalmente hà bisognu in un containeru particulari.

Motivi per lascià Nomad

Chì vantaghji avemu avutu per passà à implementazione cù Nomad è docker ancu?

1. Мы furnite e stesse cundizioni per tutti l'ambienti. In u sviluppu, QA-ambienti, pre-produzione, pruduzzione, i stessi imagine di cuntainer sò usati, cù i stessi dependenzii. Di conseguenza, ùn avete praticamente nisuna chance chì qualcosa di sfarente di ciò chì avete prima pruvatu in u locu o in un ambiente di prova diventerà in produzzione.
2. Avemu ancu trovu chì hè abbastanza faciule aghjunghje un novu serviziu. Ogni novu sistema in termini di implementazione hè lanciatu assai simplice. Hè abbastanza per andà in u repository chì guarda i cunfigurazioni, aghjunghje a prossima cunfigurazione per u vostru sistema quì, è site tuttu. Pudete implementà u vostru sistema à a produzzione senza sforzu extra da i devops.
3. tutte i schedarii di cunfigurazione in un repositoriu spartutu risultava esse trascuratu. À u mumentu chì avemu implementatu i nostri sistemi cù servitori virtuali, avemu usatu Ansible, in quale i cunfigurazioni eranu in u stessu repository. Tuttavia, per a maiò parte di i sviluppatori, questu era un pocu più difficiule di travaglià. Quì u voluminu di cunfigurazione è codice chì avete bisognu à aghjunghje per implementà u serviziu hè diventatu assai più chjucu. In più per i devops, hè assai faciule di riparà o cambià. In u casu di transizzioni, per esempiu, à una nova versione di Nomad, ponu piglià è aghjurnà massivamente tutti i schedarii operativi chì si trovanu in u stessu locu.

Ma avemu ancu scontru parechji svantaghji:

Hè risultatu chì noi fiascatu à ottene implementazioni senza saldatura in u casu di Nomad. Quandu si stende cuntenituri da diverse cundizioni, puderia esce ch'ellu hè diventatu in esecuzione, è Nomad hà percivutu cum'è un cuntinuu prontu à riceve u trafficu. Questu hè accadutu ancu prima chì l'applicazione dentru hà avutu u tempu di inizià. Per quessa, u sistema hà cuminciatu à emette 500 errori per un pocu tempu, perchè u trafficu hà cuminciatu à andà in u cuntinuu, chì ùn era ancu pronta per accettà.

Avemu scontru alcuni bugs. U bug più significativu hè chì Nomad ùn tratta micca bè un grande cluster si avete assai sistemi è cuntenituri. Quandu vulete piglià unu di i servitori chì hè inclusu in u cluster Nomad in serviziu, ci hè una probabilità abbastanza alta chì u cluster ùn si senti micca assai bè è fallu. Certi cuntenituri pò, per esempiu, falà è micca risurrezzione - questu vi costarà assai più tardi se tutti i vostri sistemi in produzzione sò situati in un cluster gestionatu da Nomad.

Allora avemu decisu di pensà à induve duvemu andà dopu. À quellu tempu, avemu diventatu assai più cuscenti di ciò chì vulemu ottene. Vale à dì: vulemu affidabilità, un pocu di più funziunalità chì Nomad dà, è un sistema più maturu, più stabile.

In questu sensu, a nostra scelta hè cascata nantu à Kubernetes cum'è a piattaforma più famosa per l'esecuzione di clusters. In particulare datu chì a dimensione è u numeru di i nostri cuntenituri era abbastanza grande. Per tali scopi, Kubernetes pareva esse u sistema più adattatu di quelli chì pudemu vede.

Trasferimentu à Kubernetes

Parlaraghju un pocu di ciò chì sò i cuncetti basi di Kubernetes è cumu si differenzianu da Nomad.

Prima di tuttu, u cuncettu più basu in Kubernetes hè u cuncettu di pod. U pudellu hè un gruppu di unu o più cuntenituri chì cumincianu sempre inseme. È travaglianu cum'è sempre strettu nantu à a stessa macchina virtuale. Sò dispunibuli per l'altri per l'indirizzu IP 127.0.0.1 in diversi porti.

Diciamu chì avete una applicazione PHP chì si compone di nginx è php-fpm - u mudellu classicu. Hè assai prubabile, vulete chì i cuntenituri nginx è php-fpm sò sempre inseme. Kubernetes vi permette di ottene questu discrittendu cum'è un pod cumuni. Questu hè esattamente ciò chì ùn pudemu micca uttene cù Nomad.

U sicondu cuncettu hè spargeru. U puntu hè chì u podu stessu hè una cosa effimera, cumencia è sparisce. Sè vo vulete prima tumbà tutti i vostri cuntenituri precedenti, è poi lanciari e nuove versioni subitu subitu, o vulete sparghje gradualmente - questu hè precisamente u cuncettu di implementazione chì hè rispunsevule per stu prucessu. Descrive cumu implementate i vostri pods, quanti, è cumu aghjurnà.

U terzu cuncettu hè sirvizziu. U vostru serviziu hè veramente u vostru sistema chì piglia un pocu di trafficu è poi u dirige à unu o più pods chì currispondenu à u vostru serviziu. Hè per quessa, vi permette di dì chì tuttu u trafficu ingressu à un tali è un serviziu cù tali è un nome deve esse mandatu à questi podi specifichi. È à u stessu tempu, vi furnisce u equilibriu di u trafficu. Questu hè, pudete eseguisce dui pods di a vostra applicazione, è tuttu u trafficu entrante serà equilibratu in modu uniforme trà e pods ligati à stu serviziu.

È u quartu cuncettu di basa - Ingress. Questu hè un serviziu chì corre nantu à un cluster Kubernetes. Agisce cum'è un equilibratore di carica esterna chì piglia tutte e dumande. Per mezu di l'API Kubernetes, Ingress pò determinà induve queste dumande devenu esse mandate. È u face assai flexible. Pudete dì chì tutte e dumande per questu òspite è tali è tali URL sò mandati à stu serviziu. E sti dumande chì venenu à questu host è à un altru URL sò mandati à un altru serviziu.

A cosa più bella da u puntu di vista di qualcunu chì sviluppa una applicazione hè chì pudete gestisce tuttu da sè stessu. Fixendu a cunfigurazione Ingress, pudete mandà tuttu u trafficu chì vene à una tale è una tale API per separà i cuntenituri, registrati, per esempiu, in Go. Ma stu trafficu chì vene à u stessu duminiu, ma à un URL diversu, hè mandatu à cuntenituri scritti in PHP, induve ci hè assai logica, ma ùn sò micca assai veloci.

Sè noi paragunà tutti sti cuncetti cù Nomad, allura si pò dì chì i primi trè cuncetti sò tutti inseme Service. È l'ultimu cuncettu hè assente in Nomad stessu. Avemu usatu un balancer esternu cum'è: pò esse haproxy, nginx, nginx + è cusì. In u casu di un cubu, ùn avete micca bisognu di introduci stu cuncettu supplementu separatamente. Tuttavia, se fighjate à Ingress in l'internu, allora hè nginx, o haproxy, o traefik, ma, per esse, integratu in Kubernetes.

Tutti i cuncetti chì aghju descrittu sò, in fattu, risorse chì esistenu in un cluster Kubernetes. Per discrìviri in u cubu, u formatu yaml hè utilizatu, chì hè più leghjite è familiar chì i schedari HCL in u casu di Nomad. Ma strutturalmente, descrizanu a stessa cosa in u casu di, per esempiu, un pod. Dicenu - Vogliu displicà tali è tali baccelli quì, cù tali è tali imagine, in tale quantità.

Inoltre, avemu capitu chì ùn avemu micca vulutu creà manualmente ogni risorsa individuali: implementazione, servizii, Ingress, etc. Invece, avemu vulsutu discrive u nostru ogni sistema in termini di Kubernetes durante l'implementazione, per ùn avè micca bisognu di ricreà manualmente tutte e dipendenze di risorse necessarie in l'ordine ghjustu. Helm hè statu sceltu cum'è un tali sistema chì ci hà permessu di fà questu.

I cuncetti basi in Helm

Helm hè gestore di pacchetti per Kubernetes. Hè assai simili à cumu travaglianu i gestori di pacchetti in linguaggi di prugrammazione. Permettenu di almacenà un serviziu custituitu da, per esempiu, implementazione nginx, implementazione php-fpm, config for Ingress, configmaps (questa hè una entità chì vi permette di stabilisce env è altri paràmetri per u vostru sistema) in forma di so- chjamati charts. À u listessu tempu, Helm funziona sopra Kubernetes. Vale à dì, questu ùn hè micca un tipu di sistema chì si mette à parte, ma solu un altru serviziu chì funziona in u cubu. Interagisce cun ellu via a so API via un cumandamentu di cunsola. A so cunvenzione è l'incantu hè chì ancu s'ellu si rompe u timone o si sguassate da u cluster, i vostri servizii ùn spariranu micca, postu chì u timone serve essenzialmente solu per inizià u sistema. Kubernetes stessu hè ancu rispunsevule per a salute è a cundizione di i servizii.

Avemu ancu capitu chì mudellu, chì finu à quì avemu avutu da fà nantu à u nostru propiu attraversu l'intruduzioni di jinja in i nostri cunfigurazioni, hè una di e caratteristiche principali di helm. Tutte e cunfigurazioni chì create per i vostri sistemi sò guardati in helm cum'è mudelli, un pocu cum'è jinja, ma in realtà utilizendu u mudellu di a lingua Go in quale helm hè scrittu, cum'è Kubernetes.

Helm aghjusta uni pochi di cuncetti supplementari à noi.

Cartula hè una descrizzione di u vostru serviziu. In altri gestori di pacchetti, saria chjamatu bundle, bundle, o qualcosa simili. Quì hè chjamatu chart.

Values sò e variàbili chì vulete usà per custruisce e vostre cunfigurazioni da mudelli.

Release. Ogni volta chì un serviziu chì si implementa cù u timone riceve una versione incrementale di a liberazione. Helm ricorda ciò chì a cunfigurazione di u serviziu era per a versione precedente, l'annu prima l'ultimu, è cusì. Dunque, sè avete bisognu di retrocede, basta à eseguisce u cumandamentu di callback di timone, indicà à a versione precedente di a liberazione. Ancu s'è a cunfigurazione currispundente in u vostru repositoriu ùn hè micca dispunibule à u mumentu di u rollback, Helm hà sempre ricurdatu ciò chì era è rinvià u vostru sistema à u statu chì era in a versione precedente.

In u casu quandu avemu usatu helm, i cunfigurazioni abituali per Kubernetes si trasformanu ancu in mudelli in quale hè pussibule aduprà variàbili, funzioni, è applicà dichjarazioni cundiziunali. Cusì, pudete cullà a cunfigurazione di u vostru serviziu secondu l'ambiente.

In pratica, avemu decisu di fà e cose un pocu sfarente di ciò chì avemu fattu cù Nomad. Se Nomad hà guardatu e cunfigurazioni di implementazione è n-variabili chì sò necessarii per implementà u nostru serviziu in un repository, allora quì avemu decisu di dividisce in dui repositori separati. U repository "deploy" guarda solu e n-variabili necessarii per l'implementazione, mentre chì u repository "helm" guarda configs o charts.

Chì ci hà datu ?

Malgradu u fattu chì ùn avemu micca guardatu dati veramente sensibili in i schedarii di cunfigurazione stessi. Per esempiu, password di basa di dati. Sò guardati cum'è secreti in Kubernetes, ma in ogni modu, ci sò sempre cose separati chì ùn vulemu micca dà accessu à tutti in una fila. Dunque, l'accessu à u repository "deploy" hè più limitatu, è u repository "helm" cuntene solu una descrizzione di u serviziu. Per questu causa, pò esse datu accessu sicuru à un circulu più grande di persone.

Siccomu ùn avemu micca solu pruduzzione, ma ancu altri ambienti, grazia à sta divisione, pudemu reutilizà i nostri charts di timone per implementà servizii micca solu à a produzzione, ma ancu, per esempiu, à un ambiente QA. Ancu per implementà in u locu usendu Minikube - Questa hè una cosa per eseguisce Kubernetes in u locu.

Dentru ogni repository, avemu lasciatu a divisione in cartulari separati per ogni serviziu. Vale à dì, in ogni repertoriu ci sò mudelli ligati à u graficu currispundente è chì descrizanu e risorse chì devenu esse implementate per lancià u nostru sistema. In u repository "deploy", avemu lasciatu solu invidia. In questu casu, ùn avemu micca usatu jinja templating perchè helm furnisce mudelli fora di a scatula - questu hè una di e so caratteristiche principali.

Avemu lasciatu u script di implementazione - deploy.sh, chì simplifica è standardizza u lanciamentu per a implementazione usendu helm. Cusì, per tutti quelli chì volenu implementà, l'interfaccia di implementazione s'assumiglia esattamente cum'è in u casu di implementazione attraversu Nomad. U stessu deploy.sh, u nome di u vostru serviziu, è induve vulete implementà. Questu face chì u timone curre internu. Ellu, à u turnu, raccoglie cunfigurazioni da mudelli, sustituisci i schedari di valori necessarii in elli, poi li implementa, lancianduli in Kubernetes.

scuperti

U serviziu Kubernetes pare esse più cumplessu chè Nomad.

Questu hè induve u trafficu in uscita vene in Ingress. Questu hè solu u controller di fronte, chì piglia tutte e dumande è dopu li manda à i servizii currispondenti à i dati di a dumanda. Li determina in basa di cunfigurazioni chì facenu parte di a descrizzione di a vostra applicazione in helm è chì i sviluppatori si stabiliscenu. U serviziu, invece, manda richieste à i so baccelli, vale à dì cuntenituri specifichi, equilibrendu u trafficu entrante trà tutti i cuntenituri chì appartenenu à stu serviziu. È, sicuru, ùn deve micca scurdatu chì ùn duvemu micca andà in ogni locu da a sicurità di a rete. Dunque, a segmentazione travaglia in u cluster Kubernetes, chì hè basatu annantu à l'etichettatura. Tutti i servizii anu certi tags, à i quali i diritti d'accessu di i servizii à certi risorse esterni / interni in o fora di u cluster sò attaccati.

Mentre avemu fattu a transizione, avemu vistu chì Kubernetes hà tutte e caratteristiche di u Nomad chì avemu usatu finu à avà, è aghjunghje ancu assai cose novi. Pò esse allargatu attraversu plugins, è in fattu per i tipi di risorse persunalizati. Questu hè, avete l'uppurtunità micca solu di utilizà qualcosa chì vene cù Kubernetes fora di a scatula, ma di creà u vostru propiu risorsu è serviziu chì leghje u vostru risorsu. Questu vi dà più opzioni per espansione u vostru sistema senza avè da reinstallà Kubernetes è senza avè da fà cambiamenti.

Un esempiu di tali usu hè Prometheus, chì eseguimu in un cluster Kubernetes. Per pudè cumincià à cullà metriche da un serviziu particulari, avemu bisognu di aghjunghje un tipu supplementu di risorsa à a descrizzione di u serviziu, u chjamatu serviziu di monitor. Prometheus, per via di u fattu chì pò leghje, esse lanciatu in Kubernetes, un tipu di risorsa persunalizata, cumencia automaticamente à cullà metriche da u novu sistema. Hè abbastanza cunvene.

A prima implementazione chì avemu fattu in Kubernetes hè stata in marzu 2018. È in questu tempu ùn avemu mai avutu prublemi cun ellu. Funziona abbastanza stabile senza bug significativi. Inoltre, pudemu espansione più. A data, avemu abbastanza di e capacità chì hà, è ci piace assai u ritmu di sviluppu di Kubernetes. À u mumentu, più di cuntenituri 3000 sò in Kubernetes. U cluster occupa parechji Node. À u listessu tempu, hè serviziu, stabile è assai cuntrullable.

Source: www.habr.com