Kumusta tanan! Ako si Pavel Agaletsky. Nagtrabaho ko isip usa ka team leader sa usa ka team nga nagpalambo sa Lamoda delivery system. Sa 2018, namulong ko sa HighLoad ++ nga komperensya, ug karon gusto nakong ipresentar ang usa ka transcript sa akong report.

Ang akong hilisgutan gipahinungod sa kasinatian sa among kompanya sa pag-deploy sa mga sistema ug serbisyo sa lainlaing mga palibot. Sugod sa atong prehistoric nga mga panahon, sa dihang atong gi-deploy ang tanang sistema ngadto sa ordinaryo nga virtual servers, nga nagtapos sa anam-anam nga transisyon gikan sa Nomad ngadto sa Kubernetes deployment. Isulti ko kanimo kung ngano nga gibuhat namon kini ug kung unsa ang among mga problema sa proseso.

I-deploy ang mga aplikasyon sa VM

Magsugod kita sa kamatuoran nga 3 ka tuig na ang milabay ang tanan nga mga sistema ug serbisyo sa kompanya gi-deploy sa ordinaryong mga virtual server. Sa teknikal nga paagi, kini giorganisar sa paagi nga ang tanan nga code sa among mga sistema nahimutang ug gitigum gamit ang mga himan sa awtomatik nga asembliya, gamit ang jenkins. Sa tabang sa Ansible, gilukot na kini gikan sa among version control system ngadto sa mga virtual server. Sa parehas nga oras, ang matag sistema nga naa sa among kompanya gi-deploy sa labing menos 2 nga mga server: usa niini - sa ulo, ang ikaduha - sa ikog. Kining duha ka mga sistema hingpit nga managsama sa usag usa sa tanan nilang mga setting, gahum, configuration ug uban pa. Ang bugtong kalainan tali kanila mao nga ang ulo nakadawat sa trapiko sa tiggamit, samtang ang ikog wala makadawat sa trapiko sa tiggamit alang sa iyang kaugalingon.

Para sa unsa kadto?

Kung nag-deploy kami mga bag-ong pagpagawas sa among aplikasyon, gusto namon nga masiguro ang posibilidad nga hapsay nga pag-deploy, kana, nga wala’y mamatikdan nga sangputanan alang sa mga tiggamit. Nakab-ot kini tungod sa kamatuoran nga ang sunod nga gihugpong nga pagpagawas gamit ang Ansible gilukot sa ikog. Didto, ang mga tawo nga nalambigit sa deployment makasusi ug makasiguro nga ang tanan maayo: ang tanan nga metrics, seksyon ug aplikasyon nagtrabaho; ang gikinahanglan nga mga script gilunsad. Human lang sila nakombinsir nga OK ra ang tanan, nibalhin ang trapiko. Nagsugod siya sa pag-adto sa server nga ikog kaniadto. Ug ang usa nga kaniadto ang ulo nagpabilin nga wala’y trapiko sa gumagamit, samtang ang miaging bersyon sa among aplikasyon magamit niini.

Mao nga kini hapsay alang sa mga tiggamit. Tungod kay ang pagbalhin dayon, tungod kay kini usa lamang ka balanse nga pagbalhin. Sayon ra nga ibalik ang nauna nga bersyon pinaagi lamang sa pagbalhin sa balanse. Mahimo usab namon nga masiguro nga ang aplikasyon andam na alang sa produksiyon bisan sa wala pa ang trapiko sa gumagamit moadto niini, nga dali ra.

Unsang mga hiyas ang atong makita niining tanan?

Una sa tanan, igo na nagtrabaho lang. Ang tanan nakasabut kung giunsa ang ingon nga pamaagi sa pag-deploy, tungod kay kadaghanan sa mga tawo naka-deploy na sa ordinaryong mga virtual server.
Kini igo na kasaligan, tungod kay ang teknolohiya sa pag-deploy simple, gisulayan sa liboan ka mga kompanya. Minilyon nga mga server ang gipakatap niining paagiha. Lisud ang pagbungkag sa usa ka butang.
Ug sa katapusan mahimo namong makuha atomic deployments. Mga deployment nga dungan nga mahitabo alang sa mga tiggamit, nga walay usa ka mamatikdan nga yugto sa pagbalhin tali sa daan nga bersyon ug sa bag-o.

Apan nakita usab namo ang daghang mga kakulangan niining tanan:

Gawas pa sa palibot sa produksiyon, ang palibot sa pag-uswag, adunay uban pang mga palibot. Pananglitan, qa ug preproduction. Niadtong panahona, kami adunay daghang mga server ug mga 60 ka serbisyo. Tungod niini nga hinungdan kinahanglan kini alang sa matag serbisyo, ipadayon ang pinakabag-o nga bersyon alang niini virtual nga makina. Dugang pa, kung gusto nimo nga i-update ang mga librarya o i-install ang mga bag-ong dependency, kinahanglan nimo nga buhaton kini sa tanan nga mga palibot. Kinahanglan usab nga i-synchronize ang oras kung kanus-a nimo i-deploy ang sunod nga bag-ong bersyon sa imong aplikasyon sa oras nga gihimo sa mga devops ang kinahanglan nga mga setting sa palibot. Sa kini nga kaso, dali nga makasulod sa usa ka sitwasyon diin ang atong palibot mahimong magkalainlain sa usa ka higayon sa tanan nga mga palibot sa usa ka laray. Pananglitan, sa usa ka palibot sa QA adunay pipila nga mga bersyon sa mga librarya, ug sa produksiyon - ang uban, nga mosangpot sa mga problema.
Kalisud sa pag-update sa mga dependency imong aplikasyon. Kini wala magdepende kanimo, apan sa laing team. Nga mao, gikan sa devops team nga nagmintinar sa mga server. Kinahanglang hatagan nimo sila ug tukma nga buluhaton ug ihulagway kung unsa ang gusto nimong buhaton.
Niadtong panahona, gusto usab namo nga bahinon ang dagkong dagkong mga monolith nga among nabatonan ngadto sa bulag nga gagmayng serbisyo, kay among nasabtan nga modaghan pa sila. Nianang panahona, aduna na kami'y labaw pa sa 100. Kinahanglan nga maghimo usa ka lahi nga bag-ong virtual machine alang sa matag bag-ong serbisyo, nga kinahanglan usab nga serbisyohan ug ipakaylap. Dugang pa, kinahanglan nimo dili usa ka awto, apan labing menos duha. Niini ang tanan gidugang usa ka palibot sa QA. Nagpahinabo kini og mga problema ug nagpalisud kanimo sa pagtukod ug pagpadagan sa mga bag-ong sistema. komplikado, mahal ug taas nga proseso.

Busa, nakahukom kami nga mas sayon ang paglihok gikan sa pag-deploy sa ordinaryong mga virtual machine ngadto sa pag-deploy sa among mga aplikasyon sa usa ka docker container. Kung ikaw adunay docker, kinahanglan nimo ang usa ka sistema nga makapadagan sa aplikasyon sa usa ka kumpol, tungod kay dili ka mahimo nga magpataas sa usa ka sudlanan nga ingon niana. Kasagaran gusto nimo nga masubay kung pila ka mga sudlanan ang giisa aron kini awtomatiko nga maalsa. Tungod niini nga hinungdan, kinahanglan namon nga mopili usa ka sistema sa pagkontrol.

Naghunahuna kami pag-ayo kung kinsa ang kuhaon. Ang tinuod mao nga niadtong panahona kini nga deployment stack ngadto sa ordinaryo nga virtual servers medyo karaan na, tungod kay walay pinakabag-o nga bersyon sa operating system. Sa pila ka punto, bisan ang FreeBSD naa didto, nga dili kaayo kombenyente sa pagpadayon. Nasabtan namo nga kinahanglan namong molalin sa pantalan sa labing madali nga panahon. Gitan-aw sa among mga devop ang ilang kasinatian sa lainlaing mga solusyon ug gipili ang usa ka sistema sama sa Nomad.

Pagbalhin sa Nomad

Ang Nomad usa ka produkto sa HashiCorp. Nailhan usab sila sa ilang ubang mga solusyon:

Konsul usa ka himan alang sa pagdiskobre sa serbisyo.

"Terraform" - usa ka sistema sa pagdumala sa mga server nga nagtugot kanimo sa pag-configure niini pinaagi sa usa ka configuration, ang gitawag nga infrastructure-as-a-code.

Vagrant nagtugot kanimo sa pag-deploy sa mga virtual nga makina sa lokal o sa panganod pinaagi sa piho nga mga file sa pag-configure.

Ang Nomad niadtong panahona ingon og usa ka medyo yano nga solusyon nga dali nimo mabalhin nga wala’y pagbag-o sa tibuuk nga imprastraktura. Dugang pa, kini sayon nga makat-on. Busa, gipili namo kini isip sistema sa pagsala sa among sudlanan.

Unsa ang imong kinahanglan aron ma-deploy ang imong sistema sa Nomad?

Una sa tanan, kinahanglan nimo imahe sa pantalan imong aplikasyon. Kinahanglan nimo nga tukuron kini ug ibutang kini sa tindahan sa imahe sa docker. Sa among kaso, kini usa ka artifactory - usa ka sistema nga nagtugot kanimo sa pagduso sa lainlaing mga artifact sa lainlaing mga lahi niini. Makatipig kini sa mga archive, mga imahe sa docker, mga pakete sa kompositor sa PHP, mga pakete sa NPM, ug uban pa.
Gikinahanglan usab configuration file, nga isulti sa Nomad kung unsa, asa ug unsa ka daghan ang gusto nimo i-deploy.

Kung maghisgot kami bahin sa Nomad, gigamit niini ang HCL nga lengguwahe ingon usa ka format sa file sa impormasyon, nga nagpasabut HashiCorp Configuration Language. Kini usa ka superset sa Yaml nga nagtugot kanimo sa paghulagway sa imong serbisyo sa termino sa Nomad.

Gitugotan ka niini nga isulti kung pila ka mga sudlanan ang gusto nimo i-deploy, diin ang mga imahe ibalhin ang lainlaing mga parameter sa kanila sa panahon sa pag-deploy. Mao nga gipakaon nimo kini nga file sa Nomad, ug naglansad kini mga sulud sa produksiyon sumala niini.

Sa among kaso, among naamgohan nga ang pagsulat lang sa eksakto nga parehas, parehas nga HCL nga mga file alang sa matag serbisyo dili kaayo kombenyente, tungod kay adunay daghang mga serbisyo ug usahay gusto nimo nga i-update kini. Nahitabo nga ang usa ka serbisyo gi-deploy dili sa usa ka higayon, apan sa lainlaing lahi. Pananglitan, ang usa sa mga sistema nga naa kanato sa produksiyon adunay sobra sa 100 nga mga higayon sa produksiyon. Nagdagan sila gikan sa parehas nga mga imahe, apan lahi sa mga setting sa pag-configure ug mga file sa pag-configure.

Busa, nakahukom kami nga sayon alang kanamo ang pagtipig sa tanan namong mga file sa pag-configure alang sa pag-deploy sa usa ka komon nga repositoryo. Niining paagiha, nahimo silang makita: dali ra silang mapadayon ug makita nimo kung unsang mga sistema ang naa kanamo. Kung gikinahanglan, sayon usab nga i-update o usbon ang usa ka butang. Dili usab lisud ang pagdugang og bag-ong sistema - pagdugang lang og configuration file sulod sa bag-ong direktoryo. Sa sulod niini adunay mga file: service.hcl, nga adunay usa ka paghulagway sa among serbisyo, ug pipila ka mga env file nga nagtugot niini nga serbisyo, nga gipakatap sa produksiyon, nga ma-configure.

Bisan pa, ang pipila sa among mga sistema gi-deploy sa produksiyon dili sa usa ka kopya, apan sa daghang sa usa ka higayon. Busa, nakahukom kami nga sayon alang kanamo nga tipigan dili ang mga config sa ilang puro nga porma, apan ang ilang templated nga porma. Ug isip templating nga pinulongan nga among gipili jinja 2. Sa kini nga format, among gitipigan ang mga config sa serbisyo mismo ug ang mga env file nga gikinahanglan alang niini.

Dugang pa, gibutang namon sa repository ang usa ka script sa pag-deploy nga kasagaran sa tanan nga mga proyekto, nga nagtugot kanimo sa paglansad ug pag-deploy sa imong serbisyo sa produksiyon, sa husto nga palibot, sa husto nga target. Sa kaso sa dihang gihimo namo ang among HCL config ngadto sa usa ka template, unya ang HCL file, nga kaniadto mao ang naandan nga Nomad config, sa niini nga kaso nagsugod sa pagtan-aw sa usa ka gamay nga lain-laing mga.

Kana mao, gipulihan namo ang pipila ka mga config place variables nga adunay variable inserts nga gikuha gikan sa env files o gikan sa ubang mga tinubdan. Dugang pa, nakuha namon ang abilidad sa paghimo sa HCL nga mga file nga dinamikong, nga mao, mahimo namon gamiton dili lamang ang naandan nga mga pagsal-ot nga variable. Tungod kay gisuportahan sa jinja ang mga cycle ug kondisyon, mahimo usab nimo ibutang ang mga file sa pag-configure didto, nga magbag-o depende kung diin nimo i-deploy ang imong mga aplikasyon.

Pananglitan, gusto nimong i-deploy ang imong serbisyo sa pre-production ug production. Ingnon ta nga sa pre-production dili nimo gusto nga modagan ang mga script sa cron, apan gusto lang nga makita ang serbisyo sa usa ka lahi nga domain aron masiguro nga kini nagdagan. Alang sa bisan kinsa nga nag-deploy sa usa ka serbisyo, ang proseso yano kaayo ug transparent. Igo na nga ipatuman ang deploy.sh file, ipiho kung unsang serbisyo ang gusto nimo i-deploy ug kung asa nga target. Pananglitan, gusto nimong i-deploy ang pipila ka sistema sa Russia, Belarus o Kazakhstan. Aron mahimo kini, usba lang ang usa sa mga parameter, ug makabaton ka sa husto nga file sa pag-configure.

Kung ang serbisyo sa Nomad na-deploy na sa imong cluster, ingon niini.

Sa pagsugod, kinahanglan nimo ang pila ka balanse sa pagkarga gikan sa gawas, nga magdala sa tanan nga trapiko sa tiggamit sa iyang kaugalingon. Magtinabangay kini kauban ang Consul ug makakat-on gikan niini kung diin, kung asa nga node, kung unsang IP address ang usa ka partikular nga serbisyo nahimutang, nga katumbas sa usa ka partikular nga domain name. Ang mga serbisyo sa Consul gikan mismo sa Nomad. Tungod kay kini mga produkto sa parehas nga kompanya, maayo sila nga konektado. Mahimo natong isulti nga gikan sa kahon ang Nomad makahimo sa pagparehistro sa tanan nga mga serbisyo nga gilunsad niini sulod sa Consul.

Human mahibal-an sa imong external balancer kung asa nga serbisyo ipadala ang trapiko, i-redirect kini sa angay nga sudlanan o daghang mga sudlanan nga mohaum sa imong aplikasyon. Natural, kinahanglan nga maghunahuna usab bahin sa kaluwasan. Bisan kung ang tanan nga mga serbisyo nagdagan sa parehas nga virtual nga mga makina sa mga sulud, kasagaran kini nanginahanglan nga ipanghimakak nimo ang libre nga pag-access gikan sa bisan unsang serbisyo sa bisan unsang lain. Nakab-ot namo kini pinaagi sa pagbahinbahin. Ang matag serbisyo gilusad sa kaugalingon nga virtual network, diin gisulat ang mga lagda sa ruta ug mga lagda alang sa pagtugot / pagdumili sa pag-access sa ubang mga sistema ug serbisyo. Mahimo silang duha sa sulod niini nga pungpong ug sa gawas niini. Pananglitan, kung gusto nimo mapugngan ang usa ka serbisyo gikan sa pagkonektar sa usa ka partikular nga database, mahimo kini pinaagi sa pagbahin sa lebel sa network. Kana mao, bisan sa sayup, dili ka aksidente nga makonektar gikan sa palibot sa pagsulay sa imong base sa produksiyon.

Unsa ka dako ang gasto sa transisyon bahin sa mga kahinguhaan sa tawo?

Gibana-bana nga 5-6 ka bulan ang pagbalhin sa tibuuk nga kompanya sa Nomad. Gibalhin namo ang service-by-service, pero sa medyo paspas nga tulin. Ang matag team kinahanglang maghimo ug kaugalingong mga sudlanan sa serbisyo.

Gisagop namo ang ingon nga pamaagi nga ang matag team responsable sa mga imahe sa docker sa ilang mga sistema nga independente. Ang Devops, sa laing bahin, naghatag sa kinatibuk-ang imprastraktura nga gikinahanglan alang sa pag-deploy, nga mao, suporta alang sa cluster mismo, suporta alang sa CI system, ug uban pa. Ug niadtong panahona, kami adunay labaw pa sa 60 nga mga sistema nga gibalhin sa Nomad, nga nahimong mga 2 ka libo nga mga sudlanan.

Ang DevOps ang responsable sa kinatibuk-ang imprastraktura sa tanan nga may kalabutan sa pag-deploy, nga adunay mga server. Ug ang matag development team, sa baylo, responsable sa pagpatuman sa mga sudlanan alang sa ilang piho nga sistema, tungod kay kini ang team nga nahibal-an kung unsa ang kasagaran nga kinahanglan niini sa usa ka partikular nga sudlanan.

Mga hinungdan sa pagbiya sa Nomad

Unsa nga mga bentaha ang among nakuha pinaagi sa pagbalhin sa pag-deploy gamit ang Nomad ug docker usab?

Kita naghatag sa samang mga kondisyon para sa tanang palibot. Sa pag-uswag, ang QA-environment, pre-production, production, parehas nga mga imahe sa sudlanan gigamit, nga adunay parehas nga dependency. Tungod niini, halos wala ka'y kahigayon nga ang usa ka butang nga lahi sa imong gisulayan kaniadto sa lokal o sa usa ka palibot sa pagsulay nga mogawas sa produksiyon.
Nakita usab namo nga kini igo na dali nga makadugang ug bag-ong serbisyo. Ang bisan unsang bag-ong sistema sa termino sa pag-deploy kay yano ra kaayo. Igo na ang pag-adto sa repository nga nagtipig sa mga config, idugang ang sunod nga config alang sa imong sistema didto, ug andam ka na. Mahimo nimong i-deploy ang imong sistema sa produksiyon nga wala’y dugang nga paningkamot gikan sa mga devops.
Ang tanan nga mga file sa pag-configure sa usa ka shared repository nahimo nga nataligam-an. Sa higayon nga among gi-deploy ang among mga sistema gamit ang mga virtual server, among gigamit ang Ansible, diin ang mga config naa sa parehas nga repository. Bisan pa, alang sa kadaghanan sa mga developer, kini usa ka gamay nga mas lisud nga pagtrabaho. Dinhi ang gidaghanon sa mga config ug code nga kinahanglan nimong idugang aron ma-deploy ang serbisyo nahimong labi ka gamay. Dugang pa alang sa mga devops dali ra kaayo nga ayohon o usbon kini. Sa kaso sa mga transisyon, pananglitan, sa usa ka bag-ong bersyon sa Nomad, mahimo nila nga makuha ug mabag-o ang tanan nga mga operating file nga nahimutang sa parehas nga lugar.

Apan nakasugat usab kami daghang mga disbentaha:

Nahitabo nga kami napakyas sa pagkab-ot sa seamless deployments sa kaso sa Nomad. Kung ang pag-roll out sa mga sudlanan gikan sa lainlaing mga kondisyon, mahimo’g mahitabo nga kini nagdagan, ug nahibal-an ni Nomad nga kini usa ka sudlanan nga andam nga makadawat sa trapiko. Nahitabo kini bisan sa wala pa ang aplikasyon sa sulod niini adunay oras sa pagsugod. Tungod niini nga hinungdan, ang sistema nagsugod sa pag-isyu sa 500 nga mga sayup sa mubo nga panahon, tungod kay ang trapiko nagsugod sa pag-adto sa sudlanan, nga dili pa andam sa pagdawat niini.

Naa miy nasugatan mga bug. Ang labing hinungdanon nga bug mao nga ang Nomad dili maayo nga pagdumala sa usa ka dako nga kumpol kung adunay ka daghang mga sistema ug mga sudlanan. Kung gusto nimo nga kuhaon ang usa sa mga server nga gilakip sa Nomad cluster sa serbisyo, adunay usa ka taas nga posibilidad nga ang cluster dili mobati nga maayo ug mahulog. Ang ubang mga sudlanan mahimo, pananglitan, mahulog ug dili mobangon - kini gasto kanimo sa ulahi kung ang tanan nimo nga mga sistema sa produksiyon nahimutang sa usa ka cluster nga gidumala sa Nomad.

Mao nga nakahukom kami nga maghunahuna kung asa kami sunod nga moadto. Nianang panahona, mas nahibal-an namon kung unsa ang gusto namon nga makab-ot. Sa ato pa: gusto namon ang kasaligan, labi pa nga mga bahin kaysa gihatag sa Nomad, ug usa ka labi ka hamtong, mas lig-on nga sistema.

Niining bahina, ang among gipili nahulog sa Kubernetes isip pinakapopular nga plataporma alang sa pagpadagan sa mga cluster. Ilabi na nga gihatag nga ang gidak-on ug gidaghanon sa among mga sudlanan igo ra. Alang sa ingon nga mga katuyoan, ang Kubernetes ingon ang labing angay nga sistema sa mga mahimo naton tan-awon.

Pagbalhin sa Kubernetes

Maghisgot ako gamay bahin sa kung unsa ang sukaranan nga mga konsepto sa Kubernetes ug kung giunsa kini lahi sa Nomad.

Una sa tanan, ang labing sukaranan nga konsepto sa Kubernetes mao ang konsepto sa pod. Pod usa ka grupo sa usa o daghang mga sudlanan nga kanunay magsugod nga magkauban. Ug nagtrabaho sila ingon nga kanunay nga estrikto sa parehas nga virtual machine. Anaa sila sa usag usa pinaagi sa IP address 127.0.0.1 sa lainlaing mga pantalan.

Ingnon ta nga ikaw adunay aplikasyon sa PHP nga naglangkob sa nginx ug php-fpm - ang klasiko nga sumbanan. Lagmit, gusto nimo nga ang mga sudlanan sa nginx ug php-fpm kanunay nga mag-uban. Gitugotan ka sa Kubernetes nga makab-ot kini pinaagi sa paghulagway kanila isip usa ka komon nga pod. Mao gyud kini ang dili namo makuha sa Nomad.

Ang ikaduha nga konsepto mao ang pagpadala. Ang punto mao nga ang pod mismo usa ka ephemeral nga butang, kini nagsugod ug nawala. Kung gusto nimo nga patyon una ang tanan nimong mga naunang sudlanan, ug dayon ilunsad ang mga bag-ong bersyon, o gusto nimo nga hinay-hinay nga i-roll out - mao gyud kini ang konsepto sa pag-deploy nga responsable sa kini nga proseso. Gihubit niini kung giunsa nimo pag-deploy ang imong mga pod, pila, ug kung giunsa kini pag-update.

Ang ikatulo nga konsepto mao ang nga pag-alagad. Ang imong serbisyo mao ang imong sistema nga mokuha sa pipila ka trapiko ug dayon idirekta kini sa usa o daghan pa nga mga pod nga katumbas sa imong serbisyo. Sa ato pa, gitugotan ka nga isulti nga ang tanan nga umaabot nga trapiko sa ingon ug ingon nga serbisyo nga adunay ingon ug ingon nga ngalan kinahanglan ipadala sa mga partikular nga pod. Ug sa samang higayon, naghatag kini kanimo sa pagbalanse sa trapiko. Kana mao, mahimo nimong ipadagan ang duha ka pod sa imong aplikasyon, ug ang tanan nga umaabot nga trapiko mahimong parehas nga balanse tali sa mga pod nga may kalabotan sa kini nga serbisyo.

Ug ang ikaupat nga batakang konsepto - Ingress. Kini usa ka serbisyo nga nagdagan sa usa ka Kubernetes cluster. Naglihok kini isip external load balancer nga mokuha sa tanang hangyo. Pinaagi sa Kubernetes API, matino ni Ingress kung asa kini nga mga hangyo ipadala. Ug siya naghimo niini nga flexible kaayo. Mahimo nimong isulti nga ang tanan nga mga hangyo alang niini nga host ug ingon ug ingon nga URL gipadala sa kini nga serbisyo. Ug kini nga mga hangyo nga moabut sa kini nga host ug sa lain nga URL gipadala sa lain nga serbisyo.

Ang labing cool nga butang gikan sa punto sa panglantaw sa usa ka tawo nga nagpalambo sa usa ka aplikasyon mao nga ikaw makahimo sa pagdumala sa tanan sa imong kaugalingon. Pinaagi sa pagtakda sa Ingress config, mahimo nimong ipadala ang tanan nga trapiko nga moabut sa ingon ug ingon nga usa ka API sa pagbulag sa mga sudlanan, narehistro, pananglitan, sa Go. Apan kini nga trapiko nga moabut sa parehas nga domain, apan sa usa ka lahi nga URL, gipadala sa mga sulud nga gisulat sa PHP, diin adunay daghang lohika, apan dili kaayo paspas.

Kung atong itandi ang tanan nga kini nga mga konsepto sa Nomad, nan makaingon kita nga ang una nga tulo nga mga konsepto managsama nga Serbisyo. Ug ang katapusan nga konsepto wala sa Nomad mismo. Gigamit namon ang usa ka external balancer ingon nga kini: kini mahimong haproxy, nginx, nginx + ug uban pa. Sa kaso sa usa ka cube, dili nimo kinahanglan nga ipaila kini nga dugang nga konsepto nga gilain. Bisan pa, kung imong tan-awon ang Ingress sa sulod, nan kini usa ka nginx, o haproxy, o traefik, apan, ingon nga kini, gitukod sa Kubernetes.

Ang tanan nga mga konsepto nga akong gihulagway, sa tinuud, mga kapanguhaan nga anaa sa sulod sa usa ka Kubernetes cluster. Aron ihulagway kini sa cube, gigamit ang yaml format, nga mas mabasa ug pamilyar kay sa mga file sa HCL sa kaso sa Nomad. Apan structurally, sila naghulagway sa sama nga butang sa kaso sa, alang sa panig-ingnan, sa usa ka pod. Giingon nila - Gusto nako nga i-deploy ang ingon ug ingon nga mga pod didto, nga adunay ingon ug ingon nga mga imahe, sa ingon ug ingon nga gidaghanon.

Dugang pa, nahibal-an namon nga dili namon gusto nga mano-mano ang paghimo sa matag indibidwal nga kapanguhaan: pag-deploy, mga serbisyo, Ingress, ug uban pa. Hinoon, gusto namong ihulagway ang among matag sistema sa termino sa Kubernetes atol sa pag-deploy, aron dili na namo kinahanglan nga mano-mano nga maghimo pag-usab sa tanang gikinahanglan nga mga dependency sa kapanguhaan sa hustong han-ay. Gipili ang Helm isip ingon nga sistema nga nagtugot kanamo sa pagbuhat niini.

Pangunang mga konsepto sa Helm

Helm kay tagdumala sa pakete para sa mga Kubernetes. Kini susama kaayo sa kung giunsa ang mga managers sa package nagtrabaho sa mga programming language. Gitugotan ka nila sa pagtipig sa usa ka serbisyo nga gilangkoban sa, pananglitan, pag-deploy nginx, pag-deploy php-fpm, config para sa Ingress, configmaps (kini usa ka entidad nga nagtugot kanimo sa pagtakda sa env ug uban pang mga parameter alang sa imong sistema) sa porma sa so- gitawag nga mga tsart. Sa samang higayon, si Helm midagan sa ibabaw sa Kubernetes. Sa ato pa, dili kini usa ka klase nga sistema nga nagtindog sa gawas, apan lain nga serbisyo nga nagdagan sa sulod sa cube. Nakig-interact ka niini pinaagi sa API niini pinaagi sa console command. Ang kasayon ug kaanyag niini mao nga bisan kung maguba ang timon o kuhaon nimo kini gikan sa kumpol, ang imong mga serbisyo dili mawala, tungod kay ang timon sa panguna nagsilbi lamang sa pagsugod sa sistema. Ang Kubernetes mismo ang dugang nga responsable sa kahimsog ug kahimtang sa mga serbisyo.

Nakaamgo sab mi niana pag-template, nga hangtod kaniadto kinahanglan namong buhaton sa among kaugalingon pinaagi sa pagpaila sa jinja sa among mga config, usa sa mga nag-unang bahin sa timon. Ang tanan nga mga configs nga imong gihimo alang sa imong mga sistema gitipigan sa timon ingon mga template, medyo sama sa jinja, apan sa tinuud gigamit ang template sa Go nga pinulongan diin ang timon gisulat, sama sa Kubernetes.

Ang Helm midugang og pipila ka dugang nga mga konsepto kanato.

Chart usa ka paghulagway sa imong serbisyo. Sa ubang mga managers sa package, tawgon kini nga bundle, bundle, o susama. Dinhi kini gitawag nga tsart.

nga mga Prinsipyo mao ang mga variable nga gusto nimong gamiton sa paghimo sa imong mga config gikan sa mga templates.

release. Matag higayon nga ang usa ka serbisyo nga nag-deploy gamit ang timon makakuha usa ka dugang nga bersyon sa pagpagawas. Nahinumdom si Helm kung unsa ang service config alang sa miaging pagpagawas, sa miaging tuig, ug uban pa. Busa, kung kinahanglan nimo nga i-roll back, padagana lang ang helm callback command, nga itudlo kini sa miaging bersyon sa pagpagawas. Bisan kung ang katugbang nga pag-configure sa imong repository dili magamit sa panahon sa pag-rollback, mahinumduman gihapon sa timon kung unsa kini ug ibalik ang imong sistema sa kahimtang sa miaging pagpagawas.

Sa kaso kung mogamit kami sa timon, ang naandan nga mga config para sa Kubernetes mahimo usab nga mga template diin posible nga mogamit mga variable, function, ug magamit ang mga kondisyon nga pahayag. Sa ingon, mahimo nimong kolektahon ang config sa imong serbisyo depende sa palibot.

Sa praktis, nakahukom kami nga buhaton ang mga butang nga lahi sa among gibuhat sa Nomad. Kung gitipigan ni Nomad ang duha nga mga configs sa pag-deploy ug mga n-variable nga gikinahanglan aron ma-deploy ang among serbisyo sa usa ka repository, nan dinhi kami nakahukom nga bahinon kini sa duha nga lahi nga mga repositoryo. Ang "deploy" nga repository nagtipig lamang sa mga n-variable nga gikinahanglan alang sa pagdeploy, samtang ang "helm" nga repository nagtipig sa mga config o mga tsart.

Unsa ang gihatag niini kanato?

Bisan pa sa kamatuoran nga wala kami magtipig bisan unsa nga sensitibo nga datos sa mga file sa pag-configure mismo. Pananglitan, ang mga password sa database. Gitipigan sila isip mga sekreto sa Kubernetes, apan bisan pa niana, aduna gihapoy bulag nga mga butang nga dili namo gusto nga hatagan og access ang tanan nga sunud-sunod. Busa, ang pag-access sa "deploy" nga repository mas limitado, ug ang "helm" repository adunay usa lamang ka paghulagway sa serbisyo. Tungod niini nga rason, kini mahimong mahatagan og access nga luwas sa mas dako nga sirkulo sa mga tawo.

Tungod kay kita adunay dili lamang sa produksyon, apan usab sa uban nga mga palibot, salamat sa niini nga panagbulag, kita makagamit pag-usab sa atong timon tsart sa pag-deploy sa mga serbisyo dili lamang sa produksyon, apan usab, alang sa panig-ingnan, sa usa ka QA palibot. Bisan sa pag-deploy kanila sa lokal nga paggamit Minikube - kini usa ka butang alang sa pagpadagan sa Kubernetes sa lokal.

Sa sulod sa matag repository, gibiyaan namo ang dibisyon ngadto sa lain nga mga direktoryo alang sa matag serbisyo. Sa ato pa, sulod sa matag direktoryo adunay mga templates nga may kalabutan sa katugbang nga tsart ug naghulagway sa mga kahinguhaan nga kinahanglang i-deploy aron ilunsad ang atong sistema. Sa "deploy" nga repository, kami nagbilin lamang sa kasina. Sa kini nga kaso, wala kami mogamit og jinja templating tungod kay ang timon naghatag og template nga wala sa kahon - kana ang usa sa mga nag-unang bahin niini.

Gibiyaan namo ang script sa deployment - deploy.sh, nga nagpasimple ug nag-standardize sa paglansad para sa deployment gamit ang timon. Sa ingon, alang sa bisan kinsa nga gusto nga mag-deploy, ang interface sa pag-deploy parehas nga hitsura sa kaso sa pag-deploy pinaagi sa Nomad. Ang parehas nga deploy.sh, ang ngalan sa imong serbisyo, ug kung diin nimo gusto i-deploy. Kini maoy hinungdan nga ang timon modagan sa sulod. Siya, sa baylo, nagkolekta sa mga configs gikan sa mga templates, gipuli ang gikinahanglan nga mga kantidad nga mga file ngadto kanila, dayon i-deploy kini, ilunsad kini ngadto sa Kubernetes.

kaplag

Ang serbisyo sa Kubernetes makita nga mas komplikado kaysa Nomad.

Dinhi diin ang paggawas nga trapiko moabut sa Ingress. Kini mao lamang ang atubangan controller, nga mokuha sa tanan nga mga hangyo ug sa ulahi ipadala kanila ngadto sa mga serbisyo nga katumbas sa hangyo data. Kini nagtino kanila base sa mga configs nga kabahin sa paghulagway sa imong aplikasyon sa timon ug nga ang mga developers nagtakda sa ilang kaugalingon. Ang serbisyo, sa laing bahin, nagpadala sa mga hangyo sa mga pod niini, nga mao, piho nga mga sudlanan, nagbalanse sa umaabot nga trapiko tali sa tanan nga mga sudlanan nga nahisakop niini nga serbisyo. Ug, siyempre, dili nato kalimtan nga dili kita moadto bisan asa gikan sa lebel sa seguridad sa network. Busa, ang pagbahinbahin naglihok sa Kubernetes cluster, nga gibase sa pag-tag. Ang tanan nga mga serbisyo adunay piho nga mga tag, diin ang mga katungod sa pag-access sa mga serbisyo sa pipila nga mga eksternal / internal nga kapanguhaan sa sulod o gawas sa cluster gilakip.

Sa among pagbalhin, among nakita nga ang Kubernetes adunay tanan nga mga bahin sa Nomad nga among gigamit hangtod karon, ug nagdugang usab daghang mga bag-ong butang. Mahimo kini mapalapad pinaagi sa mga plugins, ug sa tinuud pinaagi sa naandan nga mga tipo sa kapanguhaan. Kana mao, ikaw adunay oportunidad dili lamang sa paggamit sa usa ka butang nga kauban sa Kubernetes sa gawas sa kahon, apan sa paghimo sa imong kaugalingon nga kapanguhaan ug serbisyo nga mobasa sa imong kapanguhaan. Naghatag kini kanimo daghang mga kapilian sa pagpalapad sa imong sistema nga dili kinahanglan nga i-install pag-usab ang Kubernetes ug dili kinahanglan nga maghimo mga pagbag-o.

Usa ka pananglitan sa maong paggamit mao ang Prometheus, nga atong gipadagan sulod sa usa ka Kubernetes cluster. Aron kini magsugod sa pagkolekta sa mga sukatan gikan sa usa ka partikular nga serbisyo, kinahanglan namon nga idugang ang usa ka dugang nga tipo sa kapanguhaan sa paghulagway sa serbisyo, ang gitawag nga serbisyo sa monitor. Ang Prometheus, tungod sa kamatuoran nga kini makabasa, nga gilansad sa Kubernetes, usa ka naandan nga tipo sa kapanguhaan, awtomatiko nga nagsugod sa pagkolekta sa mga sukatan gikan sa bag-ong sistema. Kini igo nga kombenyente.

Ang una nga deployment nga among gihimo sa Kubernetes kaniadtong Marso 2018. Ug niining panahona wala gyud mi makasinati ug problema uban niya. Naglihok kini nga lig-on nga wala’y hinungdan nga mga bug. Dugang pa, mahimo naton kini nga mapalapad pa. Hangtod karon, igo na kami sa mga kapabilidad nga naa niini, ug ganahan kaayo kami sa dagan sa pag-uswag sa Kubernetes. Sa pagkakaron, labaw pa sa 3000 ka mga sudlanan ang naa sa Kubernetes. Ang cluster nag-okupar sa daghang Node. Sa parehas nga oras, kini magamit, lig-on ug kontrolado kaayo.

Source: www.habr.com

I-deploy ang mga aplikasyon sa VM, Nomad ug Kubernetes