Saluton al ĉiuj! Mia nomo estas Pavel Agaletsky. Mi laboras kiel teamgvidanto en teamo, kiu disvolvas la liversistemon Lamoda. En 2018, mi parolis ĉe la HighLoad++-konferenco, kaj hodiaŭ mi ŝatus prezenti transskribon de mia raporto.

Mia temo estas dediĉita al la sperto de nia kompanio pri deplojado de sistemoj kaj servoj al malsamaj medioj. Komencante de niaj prahistoriaj tempoj, kiam ni deplojis ĉiujn sistemojn en ordinarajn virtualajn servilojn, finiĝante kun la laŭpaŝa transiro de Nomad al deplojo en Kubernetes. Mi diros al vi kial ni faris ĝin kaj kiajn problemojn ni havis en la procezo.

Deplojante aplikojn al VM

Ni komencu per tio, ke antaŭ 3 jaroj ĉiuj sistemoj kaj servoj de la kompanio estis deplojitaj sur regulajn virtualajn servilojn. Teknike, ĝi estis organizita tiel, ke la tuta kodo por niaj sistemoj estis konservita kaj kunmetita per aŭtomataj kunigiloj, uzante jenkins. Uzante Ansible, ĝi estis lanĉita de nia versio-kontrolsistemo al virtualaj serviloj. Krome, ĉiu sistemo, kiun nia kompanio havis, estis deplojita al almenaŭ 2 serviloj: unu el ili sur la kapo, la dua sur la vosto. Ĉi tiuj du sistemoj estis absolute identaj unu al la alia en ĉiuj siaj agordoj, potenco, agordo ktp. La nura diferenco inter ili estis, ke kapo ricevis uzanttrafikon, dum vosto neniam ricevis uzanttrafikon.

Kial ĉi tio estis farita?

Kiam ni deplojis novajn eldonojn de nia aplikaĵo, ni volis certigi senjuntan lanĉon, tio estas, sen rimarkindaj sekvoj por uzantoj. Tio estis atingita pro la fakto ke la venonta kompilita eldono uzanta Ansible estis lanĉita al vosto. Tie, la homoj kiuj estis implikitaj en la deplojo povis kontroli kaj certigi ke ĉio estas bona: ĉiuj metrikoj, sekcioj kaj aplikoj funkciis; la necesaj skriptoj estas lanĉitaj. Nur post kiam ili konvinkiĝis, ke ĉio estas en ordo, la trafiko estis ŝanĝita. Ĝi komencis iri al la servilo kiu antaŭe estis vosto. Kaj tiu, kiu antaŭe estis la kapo, restis sen uzanttrafiko, dum ankoraŭ havis la antaŭan version de nia aplikaĵo sur ĝi.

Do ĝi estis senjunta por la uzantoj. Ĉar la ŝanĝado estas tuja, ĉar ĝi simple ŝanĝas la ekvilibron. Vi povas tre facile reveni al la antaŭa versio simple ŝanĝante la ekvilibron reen. Ni ankaŭ povis kontroli, ke la aplikaĵo kapablas produkti eĉ antaŭ ol ĝi ricevis uzanttrafikon, kio estis sufiĉe oportuna.

Kiajn avantaĝojn ni vidis en ĉio ĉi?

1. Antaŭ ĉio, sufiĉas ĝi nur funkcias. Ĉiuj komprenas kiel tia deplojskemo funkcias, ĉar la plej multaj homoj iam deplojiĝis al regulaj virtualaj serviloj.
2. Ĉi tio sufiĉas fidinde, ĉar la disfalda teknologio estas simpla, provita de miloj da kompanioj. Milionoj da serviloj estas deplojitaj tiel. Estas malfacile rompi ion.
3. Kaj finfine ni povis akiri atomdeplojoj. Deplojoj kiuj okazas samtempe por uzantoj, sen rimarkinda etapo de ŝanĝado inter la malnova versio kaj la nova.

Sed ni ankaŭ vidis plurajn mankojn en ĉio ĉi:

1. Krom la produktadmedio, la evolumedio, ekzistas aliaj medioj. Ekzemple, qa kaj antaŭproduktado. Tiutempe ni havis multajn servilojn kaj ĉirkaŭ 60 servojn. Tial ĝi estis necesa por ĉiu servo, konservu la lastan version por ĝi virtuala maŝino. Krome, se vi volas ĝisdatigi bibliotekojn aŭ instali novajn dependecojn, vi devas fari tion en ĉiuj medioj. Vi ankaŭ bezonis sinkronigi la tempon, kiam vi estos disfaldi la sekvan novan version de via aplikaĵo kun la tempo, kiam devops plenumas la necesajn medio-agordojn. En ĉi tiu kazo, estas facile eniri situacion kie nia medio estos iom malsama en ĉiuj medioj samtempe. Ekzemple, en QA-medio estos iuj versioj de bibliotekoj, kaj en produkta medio estos malsamaj, kiuj kondukos al problemoj.
2. Malfacilaĵo ĝisdatigi dependecojn via aplikaĵo. Ĝi dependas ne de vi, sed de la alia teamo. Nome, de la devops-teamo, kiu prizorgas la servilojn. Vi devas doni al ili taŭgan taskon kaj priskribon de tio, kion vi volas fari.
3. Tiam ni ankaŭ volis dividi la grandajn grandajn monolitojn, kiujn ni havis, en apartajn malgrandajn servojn, ĉar ni komprenis, ke estos pli kaj pli da ili. Tiutempe ni jam havis pli ol 100. Por ĉiu nova servo necesis krei apartan novan virtualan maŝinon, kiu ankaŭ bezonis esti konservita kaj deplojita. Krome, vi bezonas ne unu aŭton, sed almenaŭ du. Al ĉio ĉi aldoniĝas la QA-medio. Ĉi tio kaŭzas problemojn kaj malfaciligas al vi konstrui kaj funkciigi novajn sistemojn. kompleksa, multekosta kaj longa procezo.

Sekve, ni decidis, ke estus pli oportune moviĝi de deplojado de regulaj virtualaj maŝinoj al deplojado de niaj aplikoj en docker-ujo. Se vi havas docker, vi bezonas sistemon, kiu povas ruli la aplikaĵon en areto, ĉar vi ne povas simple levi ujon. Kutime vi volas konservi trakon de kiom da ujoj estas levitaj por ke ili aŭtomate leviĝu. Tial ni bezonis elekti kontrolsistemon.

Ni longe pensis pri kiun ni povus preni. La fakto estas, ke tiutempe ĉi tiu disfalda stako sur regulaj virtualaj serviloj estis iom malmoderna, ĉar ili ne havis la lastajn versiojn de operaciumoj. En iu momento, ekzistis eĉ FreeBSD, kiu ne estis tre oportuna por subteni. Ni komprenis, ke ni bezonas migri al docker kiel eble plej rapide. Niaj devopoj rigardis sian ekzistantan sperton kun malsamaj solvoj kaj elektis sistemon kiel Nomad.

Ŝanĝu al Nomado

Nomad estas produkto de HashiCorp. Ili ankaŭ estas konataj pro siaj aliaj solvoj:

"Konsulo" estas ilo por serva malkovro.

"Teraformo" - sistemo por administri servilojn, kiu ebligas al vi agordi ilin per agordo, la tiel nomata infrastrukturo-kiel-kodo.

"Vagresulo" permesas vin disfaldi virtualajn maŝinojn loke aŭ en la nubo per specifaj agordaj dosieroj.

Nomad tiutempe ŝajnis sufiĉe simpla solvo, al kiu oni povus rapide ŝanĝi sen ŝanĝi la tutan infrastrukturon. Krome, ĝi estas sufiĉe facile lernebla. Tial ni elektis ĝin kiel la filtran sistemon por nia ujo.

Kion vi bezonas por deploji vian sistemon al Nomad?

1. Antaŭ ĉio vi bezonas docker bildo via aplikaĵo. Vi devas konstrui ĝin kaj meti ĝin en la docker-bilddeponejon. En nia kazo, ĉi tio estas artefakto - sistemo, kiu permesas vin puŝi diversajn artefaktojn de malsamaj tipoj en ĝin. Ĝi povas stoki arkivojn, docker-bildojn, komponistojn PHP-pakaĵojn, NPM-pakaĵojn, ktp.
2. Ankaŭ bezonata agorda dosiero, kiu diros al Nomad kion, kie kaj en kia kvanto vi volas deploji.

Kiam ni parolas pri Nomad, ĝi uzas la HCL-lingvon kiel sian informdosierformaton, kiu signifas HashiCorp Agorda Lingvo. Ĉi tio estas superaro de Yaml, kiu ebligas al vi priskribi vian servon en nomadaj terminoj.

Ĝi permesas vin diri kiom da ujoj vi volas deploji, de kiuj bildoj transdoni diversajn parametrojn al ili dum deplojo. Tiel, vi nutras ĉi tiun dosieron al Nomad, kaj ĝi lanĉas ujojn en produktadon laŭ ĝi.

En nia kazo, ni rimarkis, ke simple skribi absolute identajn HCL-dosierojn por ĉiu servo ne estus tre oportuna, ĉar ekzistas multaj servoj kaj foje vi volas ĝisdatigi ilin. Okazas, ke unu servo estas deplojita ne en unu okazo, sed en diversaj malsamaj. Ekzemple, unu el la sistemoj, kiujn ni havas en produktado, havas pli ol 100 okazojn en produktado. Ili funkcias de la samaj bildoj, sed malsamas en agordaj agordoj kaj agordaj dosieroj.

Tial ni decidis, ke estus oportune por ni stoki ĉiujn niajn agordajn dosierojn por disfaldiĝo en unu komuna deponejo. Tiel ili estis videblaj: ili estis facile konserveblaj kaj ni povis vidi kiajn sistemojn ni havis. Se necese, estas ankaŭ facile ĝisdatigi aŭ ŝanĝi ion. Aldoni novan sistemon ankaŭ ne estas malfacila - vi nur bezonas krei agordan dosieron ene de la nova dosierujo. Ene de ĝi estas la sekvaj dosieroj: service.hcl, kiu enhavas priskribon de nia servo, kaj kelkaj env-dosieroj, kiuj ebligas agordi ĉi tiun propran servon, estante deplojita en produktado.

Tamen, kelkaj el niaj sistemoj estas deplojitaj en produktado ne en unu kopio, sed en pluraj samtempe. Tial ni decidis, ke estus oportune por ni konservi ne la agordojn en ilia pura formo, sed ilian ŝablonon. Kaj ni elektis jinja 2. En ĉi tiu formato, ni stokas kaj la agordojn de la servo mem kaj la env-dosierojn necesajn por ĝi.

Krome, ni metis en la deponejon disvastigan skripton komunan al ĉiuj projektoj, kiu ebligas al vi lanĉi kaj disfaldi vian servon en produktadon, en la deziratan medion, en la deziratan celon. En la kazo, kiam ni transformis nian HCL-agordon en ŝablonon, tiam la HCL-dosiero, kiu antaŭe estis regula Nomad-agordo, en ĉi tiu kazo komencis aspekti iomete alie.

Tio estas, ni anstataŭigis kelkajn agordajn lokajn variablojn per enmetitaj variabloj, kiuj estas prenitaj el env-dosieroj aŭ aliaj fontoj. Krome, ni ricevis la ŝancon kolekti HCL-dosierojn dinamike, tio estas, ni povas uzi ne nur ordinarajn variajn enmetojn. Ĉar jinja subtenas buklojn kaj kondiĉojn, vi ankaŭ povas krei agordajn dosierojn tie, kiuj ŝanĝiĝas depende de kie precize vi deplojas viajn aplikojn.

Ekzemple, vi volas disfaldi vian servon al antaŭproduktado kaj produktado. Ni diru, ke en antaŭproduktado vi ne volas ruli cron-skriptojn, sed nur volas vidi la servon sur aparta domajno por certigi, ke ĝi funkcias. Por ĉiu, kiu deplojas la servon, la procezo aspektas tre simpla kaj travidebla. Ĉio, kion vi bezonas fari, estas ekzekuti la dosieron deploy.sh, specifi kiun servon vi volas disfaldi kaj al kiu celo. Ekzemple, vi volas disfaldi certan sistemon al Rusio, Belorusio aŭ Kazaĥio. Por fari tion, simple ŝanĝu unu el la parametroj, kaj vi havos la ĝustan agordan dosieron.

Kiam la Nomad-servo jam estas deplojita al via areto, ĝi aspektas tiel.

Unue, vi bezonas ian ekvilibron ekstere, kiu ricevos la tutan uzanttrafikon. Ĝi laboros kune kun Konsulo kaj ekscios de ĝi kie, sur kiu nodo, ĉe kiu IP-adreso troviĝas specifa servo, kiu respondas al aparta domajna nomo. Servoj en Konsulo venas de Nomad mem. Ĉar ĉi tiuj estas produktoj de la sama kompanio, ili estas sufiĉe rilataj unu al la alia. Ni povas diri, ke Nomad el la skatolo povas registri ĉiujn servojn lanĉitajn en ĝi ene de Konsulo.

Post kiam via antaŭfina ŝarĝbalancilo scias al kiu servo sendi trafikon, ĝi plusendas ĝin al la taŭga ujo aŭ al pluraj ujoj, kiuj kongruas kun via aplikaĵo. Nature, ankaŭ necesas pensi pri sekureco. Kvankam ĉiuj servoj funkcias per la samaj virtualaj maŝinoj en ujoj, ĉi tio kutime postulas malhelpi liberan aliron de iu ajn servo al iu ajn alia. Ni atingis ĉi tion per segmentado. Ĉiu servo estis lanĉita en sia propra virtuala reto, sur kiu vojreguloj kaj reguloj por permesi/nei aliron al aliaj sistemoj kaj servoj estis preskribitaj. Ili povus troviĝi kaj ene de ĉi tiu areto kaj ekster ĝi. Ekzemple, se vi volas malhelpi servon konektiĝi al specifa datumbazo, tio povas esti farita per retnivela segmentado. Tio estas, eĉ erare, vi ne povas hazarde konekti de la testa medio al via produktada datumbazo.

Kiom kostis al ni la transiro laŭ homaj rimedoj?

La transiro de la tuta firmao al Nomad daŭris proksimume 5-6 monatojn. Ni moviĝis laŭ servo-post-servo, sed je sufiĉe rapida ritmo. Ĉiu teamo devis krei siajn proprajn ujojn por la servoj.

Ni adoptis tian aliron, ke ĉiu teamo respondecas pri docker-bildoj de siaj sistemoj sendepende. DevOps disponigas la ĝeneralan infrastrukturon necesan por deplojo, tio estas subteno por la areto mem, subteno por la CI-sistemo, ktp. Kaj tiutempe ni havis pli ol 60 sistemojn translokigitajn al Nomad, kio sumiĝis al ĉirkaŭ 2 mil ujoj.

Devops respondecas pri la ĝenerala infrastrukturo de ĉio rilata al deplojo kaj serviloj. Kaj ĉiu evoluiga teamo, siavice, respondecas pri efektivigo de ujoj por sia specifa sistemo, ĉar ĝi estas la teamo, kiu scias, kion ĝi ĝenerale bezonas en aparta ujo.

Kialoj por forlasi Nomad

Kiajn avantaĝojn ni ricevis ŝanĝante al deplojo uzante Nomad kaj docker, inter aliaj?

1. Ni provizis egalajn kondiĉojn por ĉiuj medioj. En evoluo, QA-medio, antaŭproduktado, produktado, la samaj ujbildoj estas uzataj, kun la samaj dependecoj. Sekve, vi preskaŭ ne havas ŝancon, ke tio, kio finiĝos en produktado, ne estas tio, kion vi antaŭe testis loke aŭ en via testa medio.
2. Ni ankaŭ trovis, ke ĝi sufiĉas facile aldoni novan servon. De deploja vidpunkto, ĉiuj novaj sistemoj estas lanĉitaj tre simple. Nur iru al la deponejo, kiu stokas agordojn, aldonu alian agordon por via sistemo tie, kaj vi estas preta. Vi povas disfaldi vian sistemon al produktado sen aldona peno de devops.
3. ĉiuj agordaj dosieroj en unu komuna deponejo montriĝis sub revizio. En la tempo, kiam ni disfaldis niajn sistemojn uzante virtualajn servilojn, ni uzis Ansible, en kiu la agordoj estis en la sama deponejo. Tamen, por plej multaj programistoj, ĉi tio estis iom pli malfacile labori. Ĉi tie la volumo de agordoj kaj kodo, kiujn vi devas aldoni por disfaldi la servon, fariĝis multe pli malgranda. Krome, estas tre facile por devopoj ripari aŭ ŝanĝi ĝin. En kazo de transiroj, ekzemple, al nova versio de Nomad, ili povas preni kaj amase ĝisdatigi ĉiujn operaciajn dosierojn situantajn en la sama loko.

Sed ni ankaŭ renkontis plurajn malavantaĝojn:

Montriĝis, ke ni ne povis atingi senjuntajn deplojojn en la kazo de Nomad. Dum la disvolvado de ujoj sub malsamaj kondiĉoj, ĝi povus rezulti funkcii, kaj Nomad perceptis ĝin kiel ujon preta por ricevi trafikon. Ĉi tio okazis antaŭ ol la aplikaĵo en ĝi eĉ havis ŝancon lanĉi. Tial la sistemo komencis produkti 500 erarojn dum mallonga tempo, ĉar trafiko komencis iri al ujo, kiu ankoraŭ ne estis preta akcepti ĝin.

Ni renkontis kelkajn cimoj. La plej grava cimo estas, ke Nomad ne tre bone pritraktas grandan areton se vi havas multajn sistemojn kaj ujojn. Kiam vi volas elpreni unu el la serviloj, kiuj estas inkluzivitaj en la Nomad-grupo por prizorgado, estas sufiĉe alta probablo, ke la areto ne sentos tre bone kaj disfalos. Iuj ujoj povas, ekzemple, fali kaj ne leviĝi - tio multe kostos vin poste se ĉiuj viaj produktadsistemoj troviĝas en areto administrita de Nomad.

Do ni decidis pripensi kien ni iru poste. Ĉe tiu punkto, ni iĝis multe pli konsciaj pri tio, kion ni volis atingi. Nome: ni volas fidindecon, iom pli da funkcioj ol Nomad provizas, kaj pli maturan, pli stabilan sistemon.

Ĉi-rilate, nia elekto falis sur Kubernetes kiel la plej populara platformo por lanĉi aretojn. Precipe pro tio, ke la grandeco kaj nombro de niaj ujoj estis sufiĉe grandaj. Por tiaj celoj, Kubernetes ŝajnis esti la plej taŭga sistemo, kiun ni povus rigardi.

Transiro al Kubernetes

Mi rakontos al vi iomete pri la bazaj konceptoj de Kubernetes kaj kiel ili diferencas de Nomad.

Antaŭ ĉio, la plej baza koncepto en Kubernetes estas la koncepto de pod. Pod estas grupo de unu aŭ pluraj ujoj, kiuj ĉiam funkcias kune. Kaj ili ĉiam funkcias kvazaŭ strikte sur unu virtuala maŝino. Ili estas alireblaj unu por la alia per IP 127.0.0.1 sur malsamaj havenoj.

Ni supozu, ke vi havas PHP-aplikaĵon kiu konsistas el nginx kaj php-fpm - la klasika skemo. Plej verŝajne, vi volos konservi ambaŭ nginx kaj php-fpm ujojn kune ĉiam. Kubernetes permesas vin atingi ĉi tion priskribante ilin kiel unu komunan balgon. Ĝuste tion ni ne povis akiri kun Nomad.

La dua koncepto estas deplojo. La fakto estas, ke la balgo mem estas efemera afero; ĝi komenciĝas kaj malaperas. Ĉu vi volas unue mortigi ĉiujn viajn antaŭajn ujojn, kaj poste lanĉi novajn versiojn tuj, aŭ ĉu vi volas disvolvi ilin iom post iom? Ĉi tiu estas la procezo, pri kiu respondecas la koncepto de deplojo. Ĝi priskribas kiel vi disvastigas viajn podojn, en kia kvanto kaj kiel ĝisdatigi ilin.

La tria koncepto estas servo. Via servo fakte estas via sistemo, kiu ricevas iom da trafiko kaj poste plusendas ĝin al unu aŭ pluraj podoj respondaj al via servo. Tio estas, ĝi permesas vin diri, ke ĉiu envenanta trafiko al tia kaj tia servo kun tia kaj tia nomo devas esti sendita al ĉi tiuj specifaj podoj. Kaj samtempe ĝi provizas al vi trafikan ekvilibron. Tio estas, vi povas lanĉi du podojn de via aplikaĵo, kaj la tuta envenanta trafiko estos egale ekvilibrigita inter la podoj rilataj al ĉi tiu servo.

Kaj la kvara baza koncepto estas Ingreso. Ĉi tio estas servo, kiu funkcias sur Kubernetes-grupo. Ĝi funkcias kiel ekstera ŝarĝbalancilo, kiu transprenas ĉiujn petojn. Uzante la Kubernetes API, Ingress povas determini kie ĉi tiuj petoj devas esti senditaj. Krome, li faras tion tre flekseble. Vi povas diri, ke ĉiuj petoj al ĉi tiu gastiganto kaj tia aŭ tia URL estas senditaj al ĉi tiu servo. Kaj ĉi tiuj petoj venantaj al ĉi tiu gastiganto kaj al alia URL estas senditaj al alia servo.

La plej bonega afero el la vidpunkto de iu, kiu disvolvas aplikaĵon, estas, ke vi kapablas administri ĉion mem. Agordante la Ingress-agordon, vi povas sendi la tutan trafikon venantan al tia aŭ tia API al apartaj ujoj skribitaj, ekzemple, en Go. Sed ĉi tiu trafiko, venanta al la sama domajno, sed al malsama URL, devus esti sendita al ujoj skribitaj en PHP, kie estas multe da logiko, sed ili ne estas tre rapidaj.

Se ni komparas ĉiujn ĉi tiujn konceptojn kun Nomad, ni povas diri, ke la unuaj tri konceptoj estas ĉiuj kune Servo. Kaj la lasta koncepto forestas en Nomad mem. Ni uzis eksteran balancilon kiel ĝi: ĝi povus esti haproxy, nginx, nginx+, ktp. En la kazo de kubo, vi ne bezonas enkonduki ĉi tiun aldonan koncepton aparte. Tamen, se vi rigardas Ingress interne, ĝi estas aŭ nginx, haproxy aŭ traefik, sed ia enkonstruita en Kubernetes.

Ĉiuj konceptoj, kiujn mi priskribis, estas fakte rimedoj, kiuj ekzistas ene de Kubernetes-grupo. Por priskribi ilin en la kubo, oni uzas yaml-formaton, kiu estas pli legebla kaj konata ol HCL-dosieroj en la kazo de Nomad. Sed strukture ili priskribas la samon en la kazo de, ekzemple, pod. Oni diras — mi volas tie disfaldi tiajn kaj tiajn podojn, kun tiaj kaj tiaj bildoj, en tia kaj tia kvanto.

Krome, ni rimarkis, ke ni ne volis krei ĉiun individuan rimedon permane: disfaldiĝo, servoj, Eniro, ktp. Anstataŭe, ni volis priskribi ĉiun el niaj sistemoj laŭ Kubernetes dum deplojo, por ke ni ne devus permane rekrei ĉiujn necesajn rimeddependecojn en la ĝusta ordo. Helm estis elektita kiel la sistemo kiu permesis al ni fari tion.

Bazaj konceptoj en Helm

Helm estas pakaĵmanaĝero por Kubernetes. Ĝi estas tre simila al kiel funkcias pakaj administrantoj en programlingvoj. Ili permesas vin stoki servon konsistantan el, ekzemple, deplojo nginx, deplojo php-fpm, agordo por Eniro, konfigmapoj (ĉi tio estas ento, kiu ebligas al vi agordi env kaj aliajn parametrojn por via sistemo) en la formo de so- nomitaj leteroj. Samtempe Helm kuras super Kubernetes. Tio estas, ĉi tio ne estas ia sistemo staranta flanken, sed nur alia servo lanĉita ene de la kubo. Vi interagas kun ĝi per ĝia API per konzola komando. Ĝia oportuno kaj beleco estas, ke eĉ se stirilo rompas aŭ vi forigas ĝin de la areto, viaj servoj ne malaperos, ĉar stirilo esence nur servas por komenci la sistemon. Kubernetes mem estas tiam respondeca pri la agado kaj stato de servoj.

Ni ankaŭ rimarkis tion ŝablonigo, kiun ni antaŭe estis devigitaj fari mem enkondukante jinja en niajn agordojn, estas unu el la ĉefaj trajtoj de helm. Ĉiuj agordoj, kiujn vi kreas por viaj sistemoj, estas konservitaj en helm en formo de ŝablonoj, iom similaj al jinja, sed, fakte, uzante la ŝablonon de la lingvo Go, en kiu helm estas skribita, kiel Kubernetes.

Helm aldonas kelkajn pliajn konceptojn por ni.

diagramo - ĉi tio estas priskribo de via servo. En aliaj pakaĵadministriloj ĝi estus nomita pakaĵo, pakaĵo aŭ io simila. Ĉi tie ĝi nomiĝas diagramo.

valoroj estas la variabloj, kiujn vi volas uzi por konstrui viajn agordojn el ŝablonoj.

ĵeto. Ĉiufoje kiam servo kiu estas deplojita uzante stirilon ricevas pliigan version de la eldono. Helm memoras, kio estis la servo-agordo en la antaŭa eldono, la eldono antaŭ tio, ktp. Sekve, se vi bezonas refari, simple rulu la helm-revokan komandon, indikante ĝin al la antaŭa eldono-versio. Eĉ se la responda agordo en via deponejo ne estas disponebla dum la restarigo, Helm ankoraŭ memoros kio ĝi estis kaj restarigos vian sistemon al la stato en kiu ĝi estis en la antaŭa eldono.

En la kazo, kiam ni uzas helm, regulaj agordoj por Kubernetes ankaŭ iĝas ŝablonoj, en kiuj eblas uzi variablojn, funkciojn kaj apliki kondiĉajn deklarojn. Tiel vi povas kolekti vian servokonfiguracion depende de la medio.

Praktike, ni decidis fari aferojn iomete malsame ol ni faris kun Nomad. Se en Nomad ambaŭ disfaldaj agordoj kaj n-variabloj, kiuj estis bezonataj por deploji nian servon, estis konservitaj en unu deponejo, ĉi tie ni decidis dividi ilin en du apartajn deponejojn. La "deploji" deponejo stokas nur n-variablojn necesajn por deplojo, kaj la "helmo" deponejo stokas agordojn aŭ diagramojn.

Kion ĉi tio donis al ni?

Malgraŭ tio, ke ni ne konservas iujn vere sentemajn datumojn en la agordaj dosieroj mem. Ekzemple, pasvortoj al datumbazoj. Ili estas konservitaj kiel sekretoj en Kubernetes, sed tamen ankoraŭ ekzistas iuj aferoj, al kiuj ni ne volas doni aliron al ĉiuj. Tial, aliro al la "deploji" deponejo estas pli limigita, kaj la "helm" deponejo simple enhavas priskribon de la servo. Tial, ĝi povas esti alirebla sekure de pli larĝa gamo da homoj.

Ĉar ni havas ne nur produktadon, sed ankaŭ aliajn mediojn, danke al ĉi tiu disiĝo ni povas reuzi niajn stirilojn por disfaldi servojn ne nur al produktado, sed ankaŭ, ekzemple, al QA-medio. Eĉ por disfaldi ilin loke uzante Minikube - ĉi tio estas afero por funkcii Kubernetes loke.

Ene de ĉiu deponejo, ni lasis dividon en apartajn dosierujojn por ĉiu servo. Tio estas, ene de ĉiu dosierujo estas ŝablonoj rilataj al la responda diagramo kaj priskribanta la rimedojn kiuj devas esti deplojitaj por funkcii nian sistemon. Ni lasis nur envs en la "deploji" deponejo. En ĉi tiu kazo, ni ne uzis ŝablonojn per jinja, ĉar helm mem provizas ŝablonojn el la skatolo - ĉi tiu estas unu el ĝiaj ĉefaj funkcioj.

Ni lasis deplojan skripton - deploy.sh, kiu simpligas kaj normigas la lanĉon por deplojo uzante helm. Do, por ĉiuj, kiuj volas disfaldi, la disfalda interfaco aspektas ekzakte same kiel kiam ĝi estis deplojita per Nomad. La sama deploy.sh, la nomo de via servo, kaj kie vi volas deploji ĝin. Ĉi tio igas stirilon komenci interne. Ĝi, siavice, kolektas agordojn de ŝablonoj, enmetas la necesajn valordosierojn en ilin, poste disfaldas ilin, lanĉante ilin en Kubernetes.

trovoj

La Kubernetes-servo ŝajnas esti pli kompleksa ol Nomad.

Ĉi tie elira trafiko venas al Ingress. Ĉi tio estas nur la antaŭa regilo, kiu transprenas ĉiujn petojn kaj poste sendas ilin al la servoj respondaj al la petaj datumoj. Ĝi determinas ilin surbaze de agordoj kiuj estas parto de la priskribo de via aplikaĵo en helm kaj kiujn programistoj starigis memstare. La servo sendas petojn al siaj podoj, tio estas, specifaj ujoj, ekvilibrigante envenantan trafikon inter ĉiuj ujoj kiuj apartenas al ĉi tiu servo. Kaj, kompreneble, ni ne forgesu, ke ni ne devas iri ien de sekureco ĉe la reto-nivelo. Tial, segmentado funkcias en Kubernetes-areto, kiu baziĝas sur etikedado. Ĉiuj servoj havas certajn etikedojn al kiuj la alirrajtoj de la servoj al certaj eksteraj/internaj rimedoj ene aŭ ekster la areto estas asociitaj.

Dum ni faris la transiron, ni vidis, ke Kubernetes havis ĉiujn kapablojn de Nomad, kiujn ni antaŭe uzis, kaj ankaŭ aldonis multajn novajn aferojn. Ĝi povas esti vastigita per kromaĵoj, kaj fakte per kutimaj rimedotipoj. Tio estas, vi havas la ŝancon ne nur uzi ion, kio venas kun Kubernetes el la skatolo, sed krei vian propran rimedon kaj servon, kiu legos vian rimedon. Ĉi tio donas al vi pliajn eblojn por vastigi vian sistemon sen devi reinstali Kubernetes kaj sen postuli modifojn.

Ekzemplo de tia uzo estas Prometeo, kiu funkcias ene de nia Kubernetes-areo. Por ke ĝi komencu kolekti metrikojn de aparta servo, ni devas aldoni aldonan specon de rimedo, la tiel nomatan servomonitoron, al la priskribo de la servo. Prometheus, pro la fakto, ke ĝi povas legi kutiman rimedan tipon kiam ĝi estas lanĉita en Kubernetes, aŭtomate komencas kolekti metrikojn de la nova sistemo. Ĝi estas sufiĉe oportuna.

La unua deplojo, kiun ni faris al Kubernetes, estis en marto 2018. Kaj dum ĉi tiu tempo ni neniam spertis problemojn kun ĝi. Ĝi funkcias sufiĉe stabile sen gravaj cimoj. Krome, ni povas pligrandigi ĝin. Hodiaŭ ni havas sufiĉe da la kapabloj kiujn ĝi havas, kaj ni tre ŝatas la ritmon de disvolviĝo de Kubernetes. Nuntempe, pli ol 3000 ujoj estas en Kubernetes. La areto okupas plurajn Nodojn. Samtempe ĝi estas utila, stabila kaj tre kontrolebla.

fonto: www.habr.com