Moien alleguer! Mäin Numm ass Pavel Agaletsky. Ech schaffen als Teamleader an engem Team dat de Lamoda Liwwersystem entwéckelt. Am Joer 2018 hunn ech op der HighLoad++ Konferenz geschwat, an haut wëll ech en Transkript vu mengem Bericht presentéieren.

Mäin Thema ass fir d'Erfahrung vun eiser Firma gewidmet fir Systemer a Servicer a verschiddenen Ëmfeld z'installéieren. Vun eiser prehistorescher Zäit unzefänken, wéi mir all Systemer an gewéinlech virtuelle Serveren ofgesat hunn, mat dem graduellen Iwwergang vun Nomad op Kubernetes ofgeschloss. Ech soen Iech firwat mir et gemaach hunn a wéi eng Problemer mir am Prozess haten.

Uwendungen op VM ofsetzen

Fänke mer mat der Tatsaach un datt virun 3 Joer all d'Systemer a Servicer vun der Firma op regelméisseg virtuelle Serveren ofgesat goufen. Technesch war et esou organiséiert datt all Code fir eis Systemer gespäichert a versammelt gouf mat automateschen Montage-Tools, mat Jenkins. Mat Ansible gouf et vun eisem Versiounskontrollsystem op virtuelle Serveren ausgerullt. Ausserdeem gouf all System, deen eis Firma hat, op mindestens 2 Server ofgesat: ee vun hinnen um Kapp, deen zweeten um Schwanz. Dës zwee Systemer waren absolut identesch mateneen an all hiren Astellungen, Kraaft, Konfiguratioun, etc. Deen eenzegen Ënnerscheed tëscht hinnen war datt de Kapp de Benotzerverkéier krut, während de Schwanz ni de Benotzerverkéier krut.

Firwat gouf dat gemaach?

Wa mir nei Verëffentlechunge vun eiser Applikatioun ofgesat hunn, wollte mir eng nahtlos Rollout garantéieren, dat heescht ouni merkbare Konsequenze fir d'Benotzer. Dëst gouf erreecht wéinst der Tatsaach datt déi nächst kompiléiert Verëffentlechung mat Ansible op de Schwanz gerullt gouf. Do konnten déi Leit, déi um Deployment involvéiert waren, kucken a kucken, datt alles gutt ass: all Metriken, Sektiounen an Applikatiounen funktionnéieren; déi néideg Scripte ginn lancéiert. Eréischt nodeems se iwwerzeegt waren datt alles an der Rei war, gouf de Verkéier ëmgewandelt. Et huet ugefaang op de Server ze goen deen virdru Schwanz war. An deen, dee virdru de Kapp war, ass ouni Benotzerverkéier bliwwen, wärend nach ëmmer déi viregt Versioun vun eiser Applikatioun drop huet.

Also et war nahtlos fir d'Benotzer. Well de Wiessel ass momentan, well et einfach de Balancer schalt. Dir kënnt ganz einfach op déi viregt Versioun zréckrollen andeems Dir einfach de Balancer zréck wiesselt. Mir konnten och verifizéieren datt d'Applikatioun fäeg war ze produzéieren och ier se de Benotzerverkéier krut, wat ganz bequem war.

Wéi eng Virdeeler hu mir an all deem gesinn?

1. Als éischt geet et duer et funktionnéiert just. Jidderee versteet wéi esou en Deployment Schema funktionnéiert, well déi meescht Leit jeemools op regelméisseg virtuelle Serveren ofgesat hunn.
2. Dëst ass genuch zouverlässeg, well d'Deployment Technologie einfach ass, vun Dausende vu Firmen getest. Millioune Servere ginn op dës Manéier ofgesat. Et ass schwéier eppes ze briechen.
3. An endlech konnte mir kréien atomarer Deployment. Deployments déi gläichzäiteg fir Benotzer geschéien, ouni eng merkbar Etapp vum Wiessel tëscht der aler Versioun an der neier.

Awer mir hunn och e puer Defiziter an all deem gesinn:

1. Zousätzlech zu der Produktiounsëmfeld, dem Entwécklungsëmfeld, ginn et aner Ëmfeld. Zum Beispill qa a Preproduktioun. Zu där Zäit hate mir vill Serveren an ongeféier 60 Servicer. Aus dësem Grond war et néideg fir all Service, erhalen déi neisten Versioun fir et virtuell Maschinn. Ausserdeem, wann Dir Bibliothéike wëllt aktualiséieren oder nei Ofhängegkeeten installéiere wëllt, musst Dir dat an all Ëmfeld maachen. Dir musst och d'Zäit synchroniséieren wann Dir déi nächst nei Versioun vun Ärer Applikatioun ofsetzt mat der Zäit wou devops déi néideg Ëmfeld Astellunge mécht. An dësem Fall ass et einfach an eng Situatioun ze kommen, wou eis Ëmfeld an all Ëmfeld gläichzäiteg e bëssen anescht wäert sinn. Zum Beispill, an engem QA Ëmfeld ginn et e puer Versioune vu Bibliothéiken, an an engem Produktiounsëmfeld ginn et verschidden, wat zu Probleemer féiert.
2. Schwieregkeeten Ofhängegkeeten ze aktualiséieren Är Demande. Et hänkt net vun Iech of, mee vun der anerer Equipe. Nämlech vum Devops Team dat d'Serveren ënnerhält. Dir musst hinnen eng passende Aufgab ginn an eng Beschreiwung vun deem wat Dir maache wëllt.
3. Mir wollten deemools och déi grouss grouss Monolithen, déi mir haten, an getrennte kleng Servicer opdeelen, well mir verstanen hunn, datt et der ëmmer méi ginn. Deemools hate mer schonn iwwer 100. Fir all neie Service war et néideg eng separat nei virtuell Maschinn ze schafen, déi och erhale muss an agesat ginn. Zousätzlech, braucht Dir net een Auto, mä op d'mannst zwee. Zousätzlech zu all dëst ass d'QA Ëmfeld. Dëst verursaacht Problemer a mécht et méi schwéier fir Iech nei Systemer ze bauen an ze lafen. komplex, deier a laange Prozess.

Dofir hu mir décidéiert datt et méi bequem wier vun der Ofsetzung vun reguläre virtuelle Maschinnen ze plënneren fir eis Uwendungen an engem Docker Container z'installéieren. Wann Dir Docker hutt, braucht Dir e System deen d'Applikatioun an engem Cluster ka lafen, well Dir kënnt net nëmmen e Container erhéijen. Normalerweis wëllt Dir verfollegen wéi vill Container opgehuewe ginn, sou datt se automatesch ophiewen. Aus dësem Grond musse mir e Kontrollsystem auswielen.

Mir hu laang geduecht, wéi ee mir kéinten huelen. D'Tatsaach ass, datt deemools dësen Deployment Stack op normale virtuelle Serveren e bëssen ausgeglach war, well se net déi lescht Versioune vu Betribssystemer hunn. Irgendwann gouf et souguer FreeBSD, wat net ganz bequem war ze ënnerstëtzen. Mir hu verstanen datt mir sou séier wéi méiglech op den Docker musse migréieren. Eis Devops hunn hir existent Erfahrung mat verschiddene Léisunge gekuckt an e System wéi Nomad gewielt.

Wiesselt op Nomad

Nomad ass e Produkt vun HashiCorp. Si sinn och bekannt fir hir aner Léisungen:

"Konsul" ass en Tool fir Service Entdeckung.

"Terraform" - e System fir Serveren ze managen, deen Iech erlaabt se duerch Konfiguratioun ze konfiguréieren, déi sougenannte Infrastruktur-als-Code.

"Vagrant" erlaabt Iech virtuell Maschinnen lokal oder an der Wollek iwwer spezifesch Konfiguratiounsdateien z'installéieren.

Nomad huet deemools eng zimlech einfach Léisung geschéngt, op déi séier ëmgewiesselt ka ginn ouni déi ganz Infrastruktur ze änneren. Zousätzlech ass et relativ einfach ze léieren. Dofir hu mir et als Filtratiounssystem fir eise Container gewielt.

Wat braucht Dir fir Äre System op Nomad z'installéieren?

1. Éischt vun all Dir braucht docker Bild Är Demande. Dir musst et bauen an et am Docker Image Repository placéieren. An eisem Fall ass dëst eng Artifactory - e System deen Iech erlaabt verschidden Artefakte vu verschiddenen Typen anzedrécken. Et kann Archiven, Docker Biller, Komponist PHP Packagen, NPM Packagen, a sou weider späicheren.
2. Och néideg Konfiguratiounsdatei, déi dem Nomad soen wat, wou a wéi eng Quantitéit Dir wëllt ofsetzen.

Wa mir iwwer Nomad schwätzen, benotzt se d'HCL Sprooch als säin Informatiounsdateiformat, dat steet fir HashiCorp Konfiguratiounssprooch. Dëst ass e Superset vu Yaml deen Iech erlaabt Äre Service an Nomad Begrëffer ze beschreiwen.

Et erlaabt Iech ze soen wéivill Container Dir wëllt ofsetzen, aus wéi eng Biller fir verschidde Parameteren hinnen während der Deployment weiderginn. Also fiddert Dir dës Datei un Nomad, an et lancéiert Container no der Produktioun.

An eisem Fall hu mir gemierkt datt einfach absolut identesch HCL Dateien fir all Service schreiwen net ganz bequem wier, well et vill Servicer gëtt an heiansdo wëllt Dir se aktualiséieren. Et geschitt datt ee Service net an enger Instanz agesat gëtt, awer a ville verschiddene. Zum Beispill, ee vun de Systemer, déi mir an der Produktioun hunn, huet méi wéi 100 Instanzen an der Produktioun. Si lafen aus deene selwechte Biller, awer ënnerscheede sech an Konfiguratiounsastellungen a Konfiguratiounsdateien.

Dofir hu mir décidéiert datt et praktesch wier fir eis all eis Konfiguratiounsdateien fir d'Deployment an engem gemeinsame Repository ze späicheren. Esou waren se siichtbar: si waren einfach ze pflegen a mir konnten gesinn wéi eng Systemer mir haten. Wann néideg, ass et och einfach eppes ze aktualiséieren oder z'änneren. En neie System bäizefügen ass och net schwéier - Dir musst just eng Konfiguratiounsdatei am neie Verzeechnes erstellen. Dobannen sinn déi folgend Dateien: service.hcl, déi eng Beschreiwung vun eisem Service enthält, an e puer Env-Dateien, déi et erlaben, dëse Service, deen an der Produktioun agesat gëtt, ze konfiguréieren.

Wéi och ëmmer, e puer vun eise Systemer ginn an der Produktioun net an enger Kopie ofgesat, awer a verschiddene gläichzäiteg. Dofir hu mir décidéiert datt et praktesch wier fir eis net d'Konfiguratiounen an hirer purer Form ze späicheren, mee hir Schablounform. A mir hu gewielt jinj 2. An dësem Format späichere mir souwuel d'Konfiguratioun vum Service selwer an d'Env Dateien déi dofir gebraucht ginn.

Zousätzlech hu mir am Repository en Deployment Skript gesat, deen all Projeten gemeinsam ass, wat Iech erlaabt Äre Service an d'Produktioun ze lancéieren an z'installéieren, an dat gewënscht Ëmfeld, an dat gewënschte Zil. Am Fall wou mir eis HCL Config an eng Schabloun ëmgewandelt hunn, dann huet d'HCL Datei, déi virdrun eng regulär Nomad Config war, an dësem Fall ugefaang e bëssen anescht ze kucken.

Dat ass, mir hunn e puer Konfiguratiounsplazvariablen ersat mat agebaute Variabelen déi aus env Dateien oder aner Quelle geholl ginn. Zousätzlech hu mir d'Méiglechkeet HCL-Dateien dynamesch ze sammelen, dat heescht, mir kënnen net nëmmen gewéinlech Variabel Insertiounen benotzen. Zënter datt jinja Loops a Konditioune ënnerstëtzt, kënnt Dir och do Konfiguratiounsdateien erstellen, déi änneren ofhängeg vu wou genau Dir Är Uwendungen ofsetzt.

Zum Beispill wëllt Dir Äre Service op Pre-Produktioun a Produktioun ofsetzen. Loosst eis soen datt Dir an der Pre-Produktioun keng Cron-Skripte wëllt ausféieren, awer just de Service op engem separaten Domain ze gesinn fir sécher ze sinn datt et funktionnéiert. Fir jiddereen deen de Service ofsetzt, gesäit de Prozess ganz einfach an transparent aus. Alles wat Dir maache musst ass d'Datei deploy.sh auszeféieren, spezifizéieren wéi ee Service Dir wëllt ofsetzen a wéi en Zil. Zum Beispill wëllt Dir e bestëmmte System a Russland, Wäissrussland oder Kasachstan ofsetzen. Maachen dëst, änneren einfach ee vun de Parameteren, an Dir wäert déi richteg Configuratiounsdatei hunn.

Wann den Nomad Service schonn op Äre Cluster ofgesat ass, gesäit et esou aus.

Als éischt braucht Dir eng Zort Balancer dobaussen, deen all Benotzerverkéier kritt. Et wäert zesumme mam Consul schaffen an erausfannen, wou, op wéi engem Node, op wéi enger IP Adress e spezifesche Service läit, deen zu engem bestëmmten Domain Numm entsprécht. Servicer am Consul kommen aus Nomad selwer. Well dës Produkter vun der selwechter Firma sinn, si si ganz matenee verbonnen. Mir kënne soen datt Nomad aus der Këscht all d'Servicer, déi an der Konsul lancéiert goufen, aschreiwen.

Wann Äre Front-End Load Balancer weess wéi ee Service de Traffic schéckt, fiert et an de passenden Container oder verschidde Container déi mat Ärer Applikatioun passen. Et ass natierlech och néideg iwwer Sécherheet ze denken. Och wann all Servicer op déiselwecht virtuell Maschinnen a Container lafen, erfuerdert dëst normalerweis de gratis Zougang vun all Service op all aner ze verhënneren. Mir hunn dëst duerch Segmentéierung erreecht. All Service gouf a sengem eegene virtuelle Netzwierk lancéiert, op deem Routingregelen a Reegele fir Zougang zu anere Systemer a Servicer z'erlaben / ze refuséieren verschriwwen goufen. Si kéinte souwuel bannent dësem Stärekoup an dobaussen lokaliséiert ginn. Zum Beispill, wann Dir wëllt verhënneren, datt e Service mat enger spezifescher Datebank verbënnt, kann dat duerch Netzniveau Segmentatioun gemaach ginn. Dat ass, och duerch Feeler, Dir kënnt net zoufälleg aus dem Testëmfeld mat Ärer Produktiounsdatenbank verbannen.

Wéi vill huet den Iwwergang eis a punkto mënschleche Ressourcen kascht?

Den Iwwergank vun der ganzer Firma op Nomad huet ongeféier 5-6 Méint gedauert. Mir sinn op enger Service-vun-Service Basis geplënnert, awer an engem zimlech schnelle Tempo. All Equipe huet hir eege Container fir d'Servicer ze schafen.

Mir hunn esou eng Approche ugeholl datt all Team onofhängeg verantwortlech ass fir Docker-Biller vun hire Systemer. DevOps bitt déi allgemeng Infrastruktur déi néideg ass fir den Deployment, dat heescht Ënnerstëtzung fir de Cluster selwer, Ënnerstëtzung fir den CI System, asw. An deemools hu mir méi wéi 60 Systemer op Nomad geplënnert, déi ongeféier 2 dausend Container ausgaange sinn.

Devops ass verantwortlech fir d'allgemeng Infrastruktur vun allem am Zesummenhang mat Deployment a Serveren. An all Entwécklungsteam ass am Tour verantwortlech fir Container fir säi spezifesche System ëmzesetzen, well et ass d'Team dat weess wat et allgemeng an engem bestëmmte Container brauch.

Grënn fir Nomad opzeginn

Wéi eng Virdeeler hu mir kritt andeems mir ënner anerem op d'Deployment mat Nomad an Docker wiesselen?

1. Mir sinn gläiche Konditioune virgesinn fir all Ëmfeld. An der Entwécklung, QA Ëmfeld, Pre-Produktioun, Produktioun, déi selwecht Container Biller sinn benotzt, mat der selwechter Ofhängegkeeten. Deementspriechend hutt Dir quasi keng Chance datt dat wat an der Produktioun ophalen ass net dat wat Dir virdru lokal oder an Ärem Testëmfeld getest hutt.
2. Mir hunn och fonnt datt et duer geet einfach en neie Service ze addéieren. Aus enger Deployment Siicht ginn all nei Systemer ganz einfach lancéiert. Gitt einfach an de Repository deen d'Konfiguratioun späichert, füügt eng aner Konfiguratioun fir Äre System do un, an Dir sidd alles fäerdeg. Dir kënnt Äre System op d'Produktioun ofsetzen ouni zousätzlech Ustrengung vun Devops.
3. all Konfiguratiounsdateien an engem gemeinsame Repository huet sech ënner Iwwerpréiwung erausgestallt. Zu där Zäit wou mir eis Systemer mat virtuelle Serveren ofgesat hunn, hu mir Ansible benotzt, an deem d'Konfiguratiounen am selwechte Repository waren. Wéi och ëmmer, fir déi meescht Entwéckler war dëst e bësse méi schwéier mat ze schaffen. Hei ass de Volume vun de Configuratiounen a Code, déi Dir braucht fir de Service z'installéieren, vill méi kleng ginn. Plus, et ass ganz einfach fir Devops et ze fixéieren oder z'änneren. Am Fall vun Iwwergäng, zum Beispill, op eng nei Versioun vum Nomad, kënne se all d'Operatiounsdateien op der selwechter Plaz huelen a bulk aktualiséieren.

Awer mir hunn och e puer Nodeeler begéint:

Et huet sech erausgestallt, datt mir konnt net nahtlos Deployementer erreechen am Fall vun Nomad. Wann Dir Container ënner verschiddene Konditiounen ausrullt, kéint et erauskommen, datt se lafen, an Nomad huet et als Container ugesinn, prett fir Traffic ze kréien. Dëst ass geschitt ier d'Applikatioun dobannen och eng Chance hat fir ze starten. Aus dësem Grond huet de System ugefaang 500 Feeler fir eng kuerz Zäit ze produzéieren, well de Verkéier ugefaang huet an e Container ze goen deen nach net bereet war et ze akzeptéieren.

Mir hunn e puer begéint Käfere. De bedeitendsten Feeler ass datt Nomad net e grousse Stärekoup ganz gutt handhabt wann Dir vill Systemer a Container hutt. Wann Dir ee vun de Serveren eraushuele wëllt, déi am Nomad Cluster fir Ënnerhalt abegraff ass, ass et eng zimlech héich Wahrscheinlechkeet datt de Cluster net ganz gutt fillt a wäert auserneen falen. E puer Container kënnen zum Beispill falen an net eropgoen - dëst wäert Iech méi spéit kaschten, wann all Är Produktiounssystemer an engem Cluster sinn, dee vum Nomad geréiert gëtt.

Also hu mir beschloss ze denken, wou mir nächste solle goen. Zu deem Zäitpunkt si mir vill méi bewosst ginn, wat mir wollten erreechen. Nämlech: Mir wëllen Zouverlässegkeet, e bësse méi Funktiounen wéi Nomad bitt, an e méi reife, méi stabile System.

An dëser Hisiicht ass eise Choix op Kubernetes gefall als déi populärste Plattform fir Cluster ze lancéieren. Besonnesch well d'Gréisst an d'Zuel vun eise Container grouss genuch war. Fir esou Zwecker schéngt Kubernetes dee gëeegentste System ze sinn, dee mir kéinte kucken.

Iwwergank zu Kubernetes

Ech soen Iech e bëssen iwwer d'Basiskonzepter vu Kubernetes a wéi se vun Nomad ënnerscheeden.

Als éischt ass dat meescht Basiskonzept a Kubernetes d'Konzept vum Pod. Pod ass e Grupp vun engem oder méi Container déi ëmmer zesummen lafen. A si schaffen ëmmer wéi strikt op enger virtueller Maschinn. Si sinn zougänglech fir all aner iwwer IP 127.0.0.1 op verschiddene Häfen.

Loosst eis unhuelen datt Dir eng PHP Applikatioun hutt déi aus nginx a php-fpm besteet - de klassesche Schema. Wahrscheinlech wëllt Dir souwuel nginx wéi och php-fpm Container zu all Moment zesummen halen. Kubernetes erlaabt Iech dëst z'erreechen andeems se se als ee gemeinsame Pod beschreiwen. Dat ass genee wat mir mat Nomad net konnten kréien.

Dat zweet Konzept ass Depliant. De Fakt ass datt de Pod selwer eng ephemeral Saach ass; et fänkt un a verschwënnt. Wëllt Dir fir d'éischt all Är virdrun Container ëmbréngen, an dann nei Versioune gläichzäiteg lancéieren, oder wëllt Dir se graduell ausrollen? Dëst ass de Prozess fir deen d'Konzept vun der Deployment verantwortlech ass. Et beschreift wéi Dir Är Pods ofsetzt, a wéi enger Quantitéit a wéi Dir se aktualiséieren.

Déi drëtt Konzept ass Service. Äre Service ass tatsächlech Äre System, deen e bësse Traffic kritt an et dann un een oder méi Pods weiderginn, déi mat Ärem Service entspriechen. Dat ass, et erlaabt Iech ze soen datt all erakommen Traffic op esou an esou e Service mat esou an esou engem Numm un dës spezifesch Pods geschéckt muss ginn. A gläichzäiteg gëtt et Iech Traffic Balance. Dat ass, Dir kënnt zwee Pods vun Ärer Applikatioun starten, an all erakommen Traffic gëtt gläichméisseg ausgeglach tëscht de Pods am Zesummenhang mat dësem Service.

An déi véiert Basiskonzept ass Ingress. Dëst ass e Service deen op engem Kubernetes Cluster leeft. Et handelt als externen Lastbalancer deen all Ufroen iwwerhëlt. Mat der Kubernetes API kann Ingress bestëmmen wou dës Ufroe geschéckt ginn. Ausserdeem mécht hien dat ganz flexibel. Dir kënnt soen datt all Ufro un dësen Host an esou an esou URLen un dëse Service geschéckt ginn. An dës Ufroen, déi un dësen Host an op eng aner URL kommen, ginn an en anere Service geschéckt.

Déi coolst Saach aus der Siicht vun engem deen eng Applikatioun entwéckelt ass datt Dir fäeg sidd alles selwer ze managen. Andeems Dir d'Ingress Config setzt, kënnt Dir all Traffic schécken, deen op esou an esou eng API kënnt, fir Container ze trennen, geschriwwen, zum Beispill an Go. Awer dësen Traffic, deen op déiselwecht Domain kënnt, awer op eng aner URL, sollt op Container geschriwwe ginn an PHP geschriwwe ginn, wou et vill Logik ass, awer si sinn net ganz séier.

Wa mir all dës Konzepter mat Nomad vergläichen, kënne mir soen, datt déi éischt dräi Konzepter sinn all zesummen Service. An dat lescht Konzept feelt bei Nomad selwer. Mir hunn en externen Balancer benotzt wéi et: et kéint Haproxy, nginx, nginx+, asw. Am Fall vun engem Wierfel braucht Dir dëst zousätzlech Konzept net separat aféieren. Wéi och ëmmer, wann Dir Ingress intern kuckt, ass et entweder nginx, Haproxy oder Traefik, awer Aart agebaut a Kubernetes.

All d'Konzepter, déi ech beschriwwen hunn, sinn tatsächlech Ressourcen déi an engem Kubernetes Cluster existéieren. Fir se am Cube ze beschreiwen, gëtt e Yaml Format benotzt, wat méi liesbar a vertraut ass wéi HCL Dateien am Fall vun Nomad. Awer strukturell beschreiwen se datselwecht am Fall vun zum Beispill Pod. Si soen - ech wëll esou an esou Pods do ofsetzen, mat esou an esou Biller, an esou an esou Quantitéiten.

Zousätzlech hu mir gemierkt datt mir net all eenzel Ressource mat der Hand kreéieren wëllen: Deployment, Servicer, Ingress, etc. Amplaz wollte mir jidderee vun eise Systemer a punkto Kubernetes wärend der Deployment beschreiwen, sou datt mir net all déi néideg Ressourceabhängegkeeten an der richteger Uerdnung manuell mussen nei erstellen. Helm gouf als System gewielt deen eis dëst erlaabt huet.

Basis Konzepter zu Helm

Helm ass Package Manager fir Kubernetes. Et ass ganz ähnlech wéi Packagemanager a Programméierungssprooche funktionnéieren. Si erlaben Iech e Service ze späicheren, deen aus zum Beispill deployment nginx, deployment php-fpm, config for Ingress, configmaps besteet (dëst ass eng Entitéit déi Iech erlaabt env an aner Parameteren fir Äre System ze setzen) a Form vu sou- genannt Charts. Gläichzäiteg Helm leeft uewen op Kubernetes. Dat ass, dëst ass net eng Aart vu System, déi op der Säit steet, awer just en anere Service deen am Kubus gestart gëtt. Dir interagéiert mat him iwwer seng API iwwer e Konsol Kommando. Seng Komfort a Schéinheet ass datt och wann de Helm brécht oder Dir se aus dem Stärekoup läscht, Är Servicer net verschwannen, well Helm am Wesentlechen nëmmen déngt fir de System ze starten. Kubernetes selwer ass dann verantwortlech fir d'Leeschtung an den Zoustand vun de Servicer.

Dat hu mir och gemierkt templateization, déi mir virdru gezwongen waren eis selwer ze maachen andeems d'Jinja an eis Konfiguratioune aféieren, ass eng vun den Haaptmerkmale vum Helm. All d'Konfiguratiounen, déi Dir fir Är Systemer erstellt, ginn am Helm a Form vun Templates gespäichert, e bëssen ähnlech wéi Jinja, awer tatsächlech benotzt d'Schabloun vun der Go Sprooch, an där Helm geschriwwe gëtt, wéi Kubernetes.

Helm füügt e puer méi Konzepter fir eis.

Beräich — это описание вашего сервиса. В других пакетных менеджерах его назвали бы пакет, bundle или что-то подобное. Здесь это называется chart.

Wäerter sinn d'Variabelen déi Dir benotze wëllt fir Är Konfiguratiounen aus Templates ze bauen.

Verëffentlechung. All Kéier wann e Service deen mat Helm ofgesat gëtt, kritt eng inkrementell Versioun vun der Verëffentlechung. Den Helm erënnert sech un wat d'Servicekonfiguratioun an der viregter Verëffentlechung war, d'Verëffentlechung virun deem, a sou weider. Dofir, wann Dir musst zréckrollen, fuert just den Helm Callback Kommando aus, weist et op déi fréier Verëffentlechungsversioun. Och wann déi entspriechend Konfiguratioun an Ärem Repository net zur Zäit vum Réckroll verfügbar ass, wäert den Helm nach ëmmer drun erënneren wat et war a wäert Äre System zréckrollen an de Staat an deem et an der viregter Verëffentlechung war.

Am Fall wou mir Helm benotzen, ginn reegelméisseg Konfiguratioune fir Kubernetes och an Templates, an deenen et méiglech ass Variabelen, Funktiounen ze benotzen an bedingte Aussoen z'applizéieren. Op dës Manéier kënnt Dir Är Servicekonfiguratioun ofhängeg vun der Ëmwelt sammelen.

An der Praxis hu mir decidéiert d'Saachen e bëssen anescht ze maachen wéi mir mam Nomad gemaach hunn. Wann am Nomad souwuel Deploymentkonfiguratiounen an n-Variablen, déi gebraucht goufen fir eise Service z'installéieren, an engem Repository gespäichert goufen, hei hu mir décidéiert se an zwee separat Repositories opzedeelen. De "Deploy" Repository späichert nëmmen n-Variablen, déi fir den Deployment gebraucht ginn, an den "Helm" Repository späichert Konfiguratiounen oder Charts.

Wat huet dat eis ginn?

Trotz der Tatsaach datt mir keng wierklech sensibel Donnéeën an de Konfiguratiounsdateien selwer späicheren. Zum Beispill Passwierder fir Datenbanken. Si ginn als Geheimnisser a Kubernetes gespäichert, awer trotzdem ginn et nach verschidde Saachen do, op déi mir net jidderengem Zougang wëllen ginn. Dofir ass den Zougang zum "Deploy" Repository méi limitéiert, an de "Helm" Repository enthält einfach eng Beschreiwung vum Service. Aus dësem Grond kann et sécher vun enger méi breet Palette vu Leit zougänglech sinn.

Well mir net nëmmen d'Produktioun hunn, awer och aner Ëmfeld, dank dëser Trennung kënne mir eis Helm Charts weiderbenotzen fir Servicer net nëmme fir d'Produktioun z'installéieren, awer och, zum Beispill, an e QA Ëmfeld. Och fir se lokal ze benotzen Minikube - dëst ass eng Saach fir Kubernetes lokal ze lafen.

Bannen an all Repository hu mir eng Divisioun an separat Verzeichnisser fir all Service verlooss. Dat ass, an all Verzeechnes ginn et Templates am Zesummenhang mat der entspriechender Diagramm a beschreiwen d'Ressourcen déi agesat musse ginn fir eise System ze bedreiwen. Mir hunn nëmmen Envs am "deploy" Repository verlooss. An dësem Fall hu mir d'Schabloun net mat Jinja benotzt, well de Helm selwer Schabloun aus der Këscht ubitt - dëst ass eng vu sengen Haaptfunktiounen.

Mir hunn en Deployment Skript hannerlooss - deploy.sh, wat de Start fir d'Deployment vereinfacht a standardiséiert mat Helm. Also, fir jiddereen deen deployéiere wëllt, gesäit d'Deployment-Interface genau d'selwecht aus wéi se gemaach huet wann se duerch Nomad ofgebaut goufen. Deeselwechten deploy.sh, den Numm vun Ärem Service, a wou Dir et wëllt ofsetzen. Dëst verursaacht Helm fir intern ze starten. Et, ofwiesselnd, sammelt Configuratioune vu Templates, setzt déi néideg Wäerterdateien an hinnen, setzt se dann aus, lancéiert se a Kubernetes.

Conclusiounen

De Kubernetes Service schéngt méi komplex ze sinn wéi Nomad.

Hei kënnt den Ausgangsverkéier op Ingress. Dëst ass just de Frontcontroller, deen all Ufroen iwwerhëlt an se duerno un d'Servicer schéckt, déi den Ufrodaten entspriechen. Et bestëmmt se op Basis vu Konfiguratiounen, déi Deel vun der Beschreiwung vun Ärer Applikatioun am Helm sinn an déi Entwéckler eleng setzen. De Service schéckt Ufroe fir seng Pods, dat heescht spezifesch Container, balancéieren den Entréeën Traffic tëscht all Container déi zu dësem Service gehéieren. An, natierlech, solle mir net vergiessen, datt mir net iwwerall vun Sécherheet um Reseau Niveau goen soll. Dofir funktionnéiert d'Segmentatioun an engem Kubernetes Cluster, deen op Tagging baséiert. All Servicer hu bestëmmte Tags, mat deenen d'Zougangsrechter vun de Servicer zu bestëmmten externen / internen Ressourcen bannent oder ausserhalb vum Cluster verbonne sinn.

Wéi mir den Iwwergank gemaach hunn, hu mir gesinn datt Kubernetes all d'Fäegkeete vum Nomad haten, déi mir virdru benotzt hunn, an och vill nei Saachen bäigefüügt. Et kann duerch Plugins erweidert ginn, an tatsächlech duerch personaliséiert Ressourcentypen. Dat ass, Dir hutt d'Méiglechkeet net nëmmen eppes ze benotzen wat mat Kubernetes aus der Këscht kënnt, mee fir Är eege Ressource a Service ze kreéieren déi Är Ressource liesen. Dëst gëtt Iech zousätzlech Optiounen fir Äre System auszebauen ouni Kubernetes z'installéieren an ouni Ännerungen ze erfuerderen.

E Beispill vu sou enger Benotzung ass Prometheus, deen an eisem Kubernetes Cluster leeft. Fir datt et ufänken Metriken aus engem bestëmmte Service ze sammelen, musse mir eng zousätzlech Zort Ressource, de sougenannte Servicemonitor, an d'Servicebeschreiwung addéieren. Prometheus, wéinst der Tatsaach datt et e personaliséierte Ressourcentyp ka liesen wann se a Kubernetes lancéiert gëtt, fänkt automatesch Metriken aus dem neie System ze sammelen. Et ass ganz bequem.

Déi éischt Deployment, déi mir op Kubernetes gemaach hunn, war am Mäerz 2018. A während dëser Zäit hu mir ni Problemer mat et erlieft. Et funktionnéiert ganz stabil ouni bedeitend Bugs. Ausserdeem kënne mir et weider ausbauen. Haut hu mir genuch vun de Fäegkeeten déi et huet, a mir hu wierklech de Tempo vun der Entwécklung vu Kubernetes gär. De Moment sinn méi wéi 3000 Container a Kubernetes. De Stärekoup besetzt e puer Noden. Zur selwechter Zäit ass et servéierbar, stabil a ganz kontrolléierbar.

Source: will.com