Kamusta kayong lahat! Ang pangalan ko ay Pavel Agaletsky. Nagtatrabaho ako bilang isang team lead sa isang team na bumuo ng Lamoda delivery system. Noong 2018, nagsalita ako sa HighLoad++ conference, at ngayon gusto kong magpakita ng transcript ng aking ulat.

Ang aking paksa ay nakatuon sa karanasan ng aming kumpanya sa pag-deploy ng mga system at serbisyo sa iba't ibang kapaligiran. Simula sa ating mga sinaunang panahon, nang i-deploy namin ang lahat ng system sa mga ordinaryong virtual server, na nagtatapos sa unti-unting paglipat mula sa Nomad patungo sa pag-deploy sa Kubernetes. Sasabihin ko sa iyo kung bakit namin ginawa ito at kung ano ang mga problema namin sa proseso.

Pag-deploy ng mga application sa VM

Magsimula tayo sa katotohanan na 3 taon na ang nakakaraan ang lahat ng mga sistema at serbisyo ng kumpanya ay na-deploy sa mga regular na virtual server. Sa teknikal na paraan, ito ay inayos sa paraang ang lahat ng code para sa aming mga system ay iniimbak at binuo gamit ang mga awtomatikong kagamitan sa pagpupulong, gamit ang jenkins. Gamit ang Ansible, inilunsad ito mula sa aming version control system patungo sa mga virtual server. Bukod dito, ang bawat system na mayroon ang aming kumpanya ay na-deploy sa hindi bababa sa 2 server: isa sa mga ito sa ulo, ang pangalawa sa buntot. Ang dalawang sistemang ito ay ganap na magkapareho sa bawat isa sa lahat ng kanilang mga setting, kapangyarihan, pagsasaayos, atbp. Ang tanging pagkakaiba sa pagitan nila ay ang ulo ay nakatanggap ng trapiko ng gumagamit, habang ang buntot ay hindi nakatanggap ng trapiko ng gumagamit.

Bakit ito ginawa?

Noong nag-deploy kami ng mga bagong release ng aming application, gusto naming matiyak ang tuluy-tuloy na paglulunsad, iyon ay, nang walang kapansin-pansing kahihinatnan para sa mga user. Nakamit ito dahil sa ang katunayan na ang susunod na pinagsama-samang release gamit ang Ansible ay inilunsad sa buntot. Doon, maaaring suriin ng mga taong kasangkot sa deployment at tiyaking maayos ang lahat: gumagana ang lahat ng sukatan, seksyon at application; ang mga kinakailangang script ay inilunsad. Pagkatapos lamang nilang makumbinsi na ok na ang lahat, napalitan ang trapiko. Nagsimula itong pumunta sa server na dati ay buntot. At ang isa na dating pinuno ay nanatiling walang trapiko ng gumagamit, habang mayroon pa ring nakaraang bersyon ng aming aplikasyon dito.

Kaya ito ay walang putol para sa mga gumagamit. Dahil ang paglipat ay madalian, dahil ito ay simpleng paglipat ng balancer. Madali kang makakabalik sa nakaraang bersyon sa pamamagitan lamang ng pagpapalit ng balancer pabalik. Maaari din naming i-verify na ang application ay may kakayahang gumawa kahit na bago pa ito makatanggap ng trapiko ng user, na medyo maginhawa.

Anong mga pakinabang ang nakita natin sa lahat ng ito?

1. Una sa lahat, sapat na gumagana lang. Naiintindihan ng lahat kung paano gumagana ang naturang deployment scheme, dahil karamihan sa mga tao ay nag-deploy na sa mga regular na virtual server.
2. Tama na ito ligtas, dahil simple ang teknolohiya sa pag-deploy, na sinubok ng libu-libong kumpanya. Milyun-milyong mga server ang na-deploy sa ganitong paraan. Mahirap masira ang isang bagay.
3. At sa wakas makukuha na namin atomic deployment. Mga deployment na nangyayari nang sabay-sabay para sa mga user, nang walang kapansin-pansing yugto ng paglipat sa pagitan ng lumang bersyon at ng bago.

Ngunit nakita rin namin ang ilang mga pagkukulang sa lahat ng ito:

1. Bilang karagdagan sa kapaligiran ng produksyon, ang kapaligiran sa pag-unlad, mayroong iba pang mga kapaligiran. Halimbawa, qa at preproduction. Noong panahong iyon marami kaming server at humigit-kumulang 60 serbisyo. Para sa kadahilanang ito ito ay kinakailangan para sa bawat serbisyo, panatilihin ang pinakabagong bersyon para dito virtual machine. Bukod dito, kung gusto mong mag-update ng mga aklatan o mag-install ng mga bagong dependency, kailangan mong gawin ito sa lahat ng kapaligiran. Kailangan mo ring i-synchronize ang oras kung kailan mo ide-deploy ang susunod na bagong bersyon ng iyong application sa oras kung kailan ginagawa ng devops ang mga kinakailangang setting ng kapaligiran. Sa kasong ito, madaling mapunta sa isang sitwasyon kung saan ang ating kapaligiran ay magiging medyo naiiba sa lahat ng mga kapaligiran nang sabay-sabay. Halimbawa, sa isang kapaligiran ng QA ay magkakaroon ng ilang mga bersyon ng mga aklatan, at sa isang kapaligiran ng produksyon ay magkakaroon ng iba't ibang mga bersyon, na hahantong sa mga problema.
2. Kahirapan sa pag-update ng mga dependencies iyong aplikasyon. Hindi ito nakasalalay sa iyo, ngunit sa kabilang koponan. Ibig sabihin, mula sa devops team na nagpapanatili ng mga server. Dapat mong bigyan sila ng angkop na gawain at paglalarawan ng gusto mong gawin.
3. Sa oras na iyon, nais din naming hatiin ang malalaking malalaking monolith na mayroon kami sa magkakahiwalay na maliliit na serbisyo, dahil naiintindihan namin na parami nang parami ang mga ito. Sa oras na iyon, mayroon na kaming higit sa 100. Para sa bawat bagong serbisyo, kinakailangan na lumikha ng isang hiwalay na bagong virtual machine, na kailangan ding mapanatili at i-deploy. Bilang karagdagan, hindi mo kailangan ng isang kotse, ngunit hindi bababa sa dalawa. Idinagdag sa lahat ng ito ang kapaligiran ng QA. Nagdudulot ito ng mga problema at ginagawang mas mahirap para sa iyo na bumuo at magpatakbo ng mga bagong system. kumplikado, mahal at mahabang proseso.

Samakatuwid, nagpasya kami na magiging mas maginhawang lumipat mula sa pag-deploy ng mga regular na virtual machine patungo sa pag-deploy ng aming mga application sa isang docker container. Kung mayroon kang docker, kailangan mo ng system na maaaring magpatakbo ng application sa isang cluster, dahil hindi ka maaaring magtaas ng container. Karaniwang gusto mong subaybayan kung gaano karaming mga lalagyan ang itinataas upang awtomatiko itong iangat. Para sa kadahilanang ito, kailangan naming pumili ng isang control system.

Matagal kaming nag-isip kung alin ang maaari naming kunin. Ang katotohanan ay sa oras na iyon ang deployment stack na ito sa mga regular na virtual server ay medyo luma na, dahil wala silang mga pinakabagong bersyon ng mga operating system. Sa ilang mga punto, mayroon ding FreeBSD, na hindi masyadong maginhawa upang suportahan. Naunawaan namin na kailangan naming lumipat sa docker sa lalong madaling panahon. Ang aming mga devops ay tumingin sa kanilang kasalukuyang karanasan sa iba't ibang mga solusyon at pumili ng isang sistema tulad ng Nomad.

Lumipat sa Nomad

Ang Nomad ay produkto ng HashiCorp. Kilala rin sila para sa kanilang iba pang mga solusyon:

"Consul" ay isang tool para sa pagtuklas ng serbisyo.

"Terraform" - isang sistema para sa pamamahala ng mga server na nagbibigay-daan sa iyong i-configure ang mga ito sa pamamagitan ng pagsasaayos, ang tinatawag na imprastraktura-bilang-isang-code.

"Vagrant" nagbibigay-daan sa iyong mag-deploy ng mga virtual machine nang lokal o sa cloud sa pamamagitan ng mga partikular na configuration file.

Ang Nomad sa oras na iyon ay tila isang medyo simpleng solusyon na maaaring mabilis na ilipat nang hindi binabago ang buong imprastraktura. Bilang karagdagan, ito ay medyo madaling matutunan. Kaya naman pinili namin ito bilang sistema ng pagsasala para sa aming lalagyan.

Ano ang kailangan mong i-deploy ang iyong system sa Nomad?

1. Una sa lahat kailangan mo larawan ng docker iyong aplikasyon. Kailangan mong buuin ito at ilagay sa repositoryo ng imahe ng docker. Sa aming kaso, ito ay isang artifactory - isang sistema na nagpapahintulot sa iyo na itulak ang iba't ibang mga artifact ng iba't ibang uri dito. Maaari itong mag-imbak ng mga archive, docker na imahe, composer PHP packages, NPM packages, at iba pa.
2. Kailangan din configuration file, na magsasabi kay Nomad kung ano, saan at sa anong dami ang gusto mong i-deploy.

Kapag pinag-uusapan natin ang tungkol sa Nomad, ginagamit nito ang wikang HCL bilang format ng file ng impormasyon nito, na nangangahulugang Wika ng Configuration ng HashiCorp. Ito ay isang superset ng Yaml na nagbibigay-daan sa iyong ilarawan ang iyong serbisyo sa mga termino ng Nomad.

Binibigyang-daan ka nitong sabihin kung gaano karaming mga container ang gusto mong i-deploy, kung saan ang mga larawan ay magpapasa ng iba't ibang mga parameter sa kanila sa panahon ng pag-deploy. Kaya, pinapakain mo ang file na ito sa Nomad, at naglulunsad ito ng mga lalagyan sa produksyon ayon dito.

Sa aming kaso, napagtanto namin na ang simpleng pagsusulat ng ganap na magkaparehong mga file ng HCL para sa bawat serbisyo ay hindi magiging masyadong maginhawa, dahil maraming mga serbisyo at kung minsan ay gusto mong i-update ang mga ito. Ito ay nangyayari na ang isang serbisyo ay na-deploy hindi sa isang pagkakataon, ngunit sa isang iba't ibang mga iba't ibang mga. Halimbawa, ang isa sa mga system na mayroon tayo sa produksyon ay may higit sa 100 mga pagkakataon sa produksyon. Ang mga ito ay tumatakbo mula sa parehong mga larawan, ngunit naiiba sa mga setting ng pagsasaayos at mga file ng pagsasaayos.

Samakatuwid, napagpasyahan namin na magiging maginhawa para sa amin na iimbak ang lahat ng aming mga configuration file para sa pag-deploy sa isang karaniwang imbakan. Sa paraang ito ay nakikita sila: madali silang mapanatili at nakikita namin kung anong mga sistema ang mayroon kami. Kung kinakailangan, madali ring i-update o baguhin ang isang bagay. Ang pagdaragdag ng isang bagong sistema ay hindi rin mahirap - kailangan mo lamang lumikha ng isang configuration file sa loob ng bagong direktoryo. Sa loob nito ay ang mga sumusunod na file: service.hcl, na naglalaman ng paglalarawan ng aming serbisyo, at ilang env file na nagpapahintulot sa mismong serbisyong ito, na na-deploy sa produksyon, na ma-configure.

Gayunpaman, ang ilan sa aming mga system ay na-deploy sa produksyon hindi sa isang kopya, ngunit sa ilan nang sabay-sabay. Samakatuwid, napagpasyahan namin na magiging maginhawa para sa amin na iimbak hindi ang mga config sa kanilang purong anyo, ngunit ang kanilang template na anyo. At kami ang pumili jinja 2. Sa format na ito, iniimbak namin ang parehong mga config ng serbisyo mismo at ang mga env file na kailangan para dito.

Bilang karagdagan, naglagay kami sa repositoryo ng script ng deployment na karaniwan sa lahat ng proyekto, na nagbibigay-daan sa iyong ilunsad at i-deploy ang iyong serbisyo sa produksyon, sa nais na kapaligiran, sa nais na target. Sa kaso nang ginawa naming template ang aming HCL config, pagkatapos ay ang HCL file, na dati ay isang regular na Nomad config, sa kasong ito ay nagsimulang magmukhang medyo naiiba.

Ibig sabihin, pinalitan namin ang ilang mga variable ng lokasyon ng config ng mga inilagay na variable na kinuha mula sa mga env file o iba pang mga source. Bilang karagdagan, nakakuha kami ng pagkakataon na mangolekta ng mga file ng HCL nang pabago-bago, iyon ay, maaari naming gamitin hindi lamang ang mga ordinaryong variable na pagpapasok. Dahil sinusuportahan ng jinja ang mga loop at kundisyon, maaari ka ring lumikha ng mga configuration file doon, na nagbabago depende sa kung saan mo eksaktong i-deploy ang iyong mga application.

Halimbawa, gusto mong i-deploy ang iyong serbisyo sa pre-production at production. Sabihin natin na sa pre-production ay hindi mo gustong magpatakbo ng mga cron script, ngunit gusto mo lang makita ang serbisyo sa isang hiwalay na domain upang matiyak na ito ay gumagana. Para sa sinumang nag-deploy ng serbisyo, ang proseso ay mukhang napaka-simple at transparent. Ang kailangan mo lang gawin ay i-execute ang deploy.sh file, tukuyin kung aling serbisyo ang gusto mong i-deploy at kung aling target. Halimbawa, gusto mong mag-deploy ng isang partikular na system sa Russia, Belarus o Kazakhstan. Upang gawin ito, baguhin lamang ang isa sa mga parameter, at magkakaroon ka ng tamang configuration file.

Kapag ang serbisyo ng Nomad ay na-deploy na sa iyong cluster, ganito ang hitsura.

Una, kailangan mo ng ilang uri ng balancer sa labas, na tatanggap ng lahat ng trapiko ng user. Makikipagtulungan ito sa Consul at alamin mula dito kung saan, sa anong node, sa anong IP address matatagpuan ang isang partikular na serbisyo na tumutugma sa isang partikular na domain name. Ang mga serbisyo sa Consul ay nagmula sa Nomad mismo. Dahil ang mga ito ay mga produkto mula sa parehong kumpanya, sila ay lubos na nauugnay sa isa't isa. Masasabi nating ang Nomad out of the box ay maaaring magrehistro ng lahat ng mga serbisyong inilunsad dito sa loob ng Consul.

Kapag alam na ng iyong front-end load balancer kung aling serbisyo ang magpapadala ng trapiko, ipapasa ito sa naaangkop na container o maraming container na tumutugma sa iyong aplikasyon. Naturally, kailangan ding isipin ang tungkol sa kaligtasan. Kahit na ang lahat ng mga serbisyo ay tumatakbo sa parehong mga virtual machine sa mga lalagyan, ito ay karaniwang nangangailangan ng pagpigil sa libreng pag-access mula sa anumang serbisyo sa anumang iba pa. Nakamit namin ito sa pamamagitan ng segmentation. Ang bawat serbisyo ay inilunsad sa sarili nitong virtual network, kung saan inireseta ang mga panuntunan sa pagruruta at mga panuntunan para sa pagpapahintulot/pagtanggi ng access sa ibang mga system at serbisyo. Maaari silang matatagpuan sa loob ng cluster na ito at sa labas nito. Halimbawa, kung gusto mong pigilan ang isang serbisyo mula sa pagkonekta sa isang partikular na database, maaari itong gawin sa pamamagitan ng network-level segmentation. Iyon ay, kahit na hindi sinasadya, hindi mo sinasadyang kumonekta mula sa kapaligiran ng pagsubok sa iyong database ng produksyon.

Magkano ang halaga ng paglipat sa mga tuntunin ng human resources?

Ang paglipat ng buong kumpanya sa Nomad ay tumagal ng humigit-kumulang 5-6 na buwan. Lumipat kami sa isang service-by-service na batayan, ngunit sa medyo mabilis na bilis. Ang bawat koponan ay kailangang lumikha ng kanilang sariling mga lalagyan para sa mga serbisyo.

Gumamit kami ng ganitong paraan na ang bawat koponan ay may pananagutan para sa mga docker na larawan ng kanilang mga system nang nakapag-iisa. Nagbibigay ang DevOps ng pangkalahatang imprastraktura na kinakailangan para sa pag-deploy, iyon ay, suporta para sa cluster mismo, suporta para sa CI system, at iba pa. At sa oras na iyon, mayroon kaming higit sa 60 mga sistema na inilipat sa Nomad, na umabot sa halos 2 libong mga lalagyan.

Responsable ang Devops para sa pangkalahatang imprastraktura ng lahat ng bagay na nauugnay sa pag-deploy at mga server. At ang bawat development team, sa turn, ay may pananagutan sa pagpapatupad ng mga container para sa partikular na system nito, dahil ito ang team na nakakaalam kung ano ang karaniwang kailangan nito sa isang partikular na container.

Mga dahilan ng pag-abandona sa Nomad

Anong mga pakinabang ang nakuha namin sa pamamagitan ng paglipat sa deployment gamit ang Nomad at docker, bukod sa iba pa?

1. Kami nagbigay ng pantay na kondisyon para sa lahat ng kapaligiran. Sa pag-unlad, QA environment, pre-production, production, ang parehong mga imahe ng lalagyan ay ginagamit, na may parehong dependencies. Alinsunod dito, halos wala kang pagkakataon na kung ano ang hahantong sa produksyon ay hindi kung ano ang dati mong sinubukan sa lokal o sa iyong kapaligiran sa pagsubok.
2. Nalaman din namin na ito ay sapat na madaling magdagdag ng bagong serbisyo. Mula sa isang deployment point of view, ang anumang mga bagong system ay inilunsad nang napakasimple. Pumunta lang sa repository na nag-iimbak ng mga config, magdagdag ng isa pang config para sa iyong system doon, at handa ka na. Maaari mong i-deploy ang iyong system sa produksyon nang walang anumang karagdagang pagsisikap mula sa devops.
3. lahat configuration file sa isang karaniwang imbakan under review pala. Noong panahong inilagay namin ang aming mga system gamit ang mga virtual na server, ginamit namin ang Ansible, kung saan ang mga config ay nasa parehong repositoryo. Gayunpaman, para sa karamihan ng mga developer na ito ay medyo mas mahirap gamitin. Narito ang dami ng mga config at code na kailangan mong idagdag upang i-deploy ang serbisyo ay naging mas maliit. Dagdag pa, napakadali para sa mga devop na ayusin o baguhin ito. Sa kaso ng mga paglipat, halimbawa, sa isang bagong bersyon ng Nomad, maaari nilang kunin at maramihang i-update ang lahat ng mga operating file na matatagpuan sa parehong lugar.

Ngunit nakatagpo din kami ng ilang mga disadvantages:

Kami pala hindi makamit ang tuluy-tuloy na pag-deploy sa kaso ng Nomad. Kapag naglulunsad ng mga container sa ilalim ng iba't ibang kundisyon, maaari itong lumabas na tumatakbo, at naisip ito ng Nomad bilang isang container na handang tumanggap ng trapiko. Nangyari ito bago pa man magkaroon ng pagkakataong ilunsad ang application sa loob nito. Para sa kadahilanang ito, ang system ay nagsimulang gumawa ng 500 mga error para sa isang maikling panahon, dahil ang trapiko ay nagsimulang pumunta sa isang lalagyan na hindi pa handang tanggapin ito.

May nakasalubong kami sa pamamagitan ng mga lusak. Ang pinakamahalagang bug ay ang Nomad ay hindi humahawak ng isang malaking cluster nang napakahusay kung mayroon kang maraming mga system at container. Kapag gusto mong kunin ang isa sa mga server na kasama sa cluster ng Nomad para sa pagpapanatili, mayroong isang medyo mataas na posibilidad na ang cluster ay hindi masyadong makaramdam ng magandang at magwawasak. Ang ilang mga container ay maaaring, halimbawa, ay bumagsak at hindi tumaas - ito ay magastos sa iyo sa ibang pagkakataon kung ang lahat ng iyong mga sistema ng produksyon ay matatagpuan sa isang cluster na pinamamahalaan ng Nomad.

Kaya napagdesisyunan naming pag-isipan kung saan kami susunod na pupunta. Sa puntong iyon, mas naging aware kami sa gusto naming makamit. Lalo na: gusto namin ng pagiging maaasahan, mas maraming function kaysa sa ibinibigay ng Nomad, at mas mature, mas matatag na sistema.

Kaugnay nito, ang aming pinili ay nahulog sa Kubernetes bilang pinakasikat na platform para sa paglulunsad ng mga kumpol. Lalo na kung ang laki at bilang ng aming mga lalagyan ay sapat na malaki. Para sa gayong mga layunin, ang Kubernetes ay tila ang pinakaangkop na sistema na maaari naming tingnan.

Paglipat sa Kubernetes

Sasabihin ko sa iyo ng kaunti ang tungkol sa mga pangunahing konsepto ng Kubernetes at kung paano sila naiiba sa Nomad.

Una sa lahat, ang pinakapangunahing konsepto sa Kubernetes ay ang konsepto ng pod. Supot ng buto ay isang pangkat ng isa o higit pang mga lalagyan na palaging tumatakbo nang magkasama. At palagi silang gumagana na parang mahigpit sa isang virtual machine. Maa-access ang mga ito sa isa't isa sa pamamagitan ng IP 127.0.0.1 sa iba't ibang port.

Ipagpalagay natin na mayroon kang PHP application na binubuo ng nginx at php-fpm - ang klasikong pamamaraan. Malamang, gugustuhin mong panatilihing magkasama ang mga lalagyan ng nginx at php-fpm sa lahat ng oras. Binibigyang-daan ka ng Kubernetes na makamit ito sa pamamagitan ng paglalarawan sa kanila bilang isang karaniwang pod. Ito ang eksaktong hindi namin makuha sa Nomad.

Ang pangalawang konsepto ay paglawak. Ang katotohanan ay ang pod mismo ay isang ephemeral na bagay; ito ay nagsisimula at nawawala. Gusto mo bang patayin muna ang lahat ng iyong nakaraang container, at pagkatapos ay ilunsad ang mga bagong bersyon nang sabay-sabay, o gusto mo bang ilunsad ang mga ito nang paunti-unti? Ito ang proseso kung saan responsable ang konsepto ng deployment. Inilalarawan nito kung paano mo i-deploy ang iyong mga pod, sa kung anong dami at kung paano i-update ang mga ito.

Ang ikatlong konsepto ay serbisyo. Ang iyong serbisyo ay talagang iyong system, na tumatanggap ng ilang trapiko at pagkatapos ay ipinapasa ito sa isa o higit pang mga pod na naaayon sa iyong serbisyo. Iyon ay, pinapayagan ka nitong sabihin na ang lahat ng papasok na trapiko sa ganoon at ganoong serbisyo na may ganoon at ganoong pangalan ay dapat ipadala sa mga partikular na pod na ito. At kasabay nito ay nagbibigay ito sa iyo ng pagbabalanse ng trapiko. Iyon ay, maaari kang maglunsad ng dalawang pod ng iyong aplikasyon, at lahat ng papasok na trapiko ay magiging pantay na balanse sa pagitan ng mga pod na nauugnay sa serbisyong ito.

At ang pang-apat na pangunahing konsepto ay Pagpasok. Ito ay isang serbisyo na tumatakbo sa isang Kubernetes cluster. Ito ay gumaganap bilang isang external load balancer na tumatagal sa lahat ng mga kahilingan. Gamit ang Kubernetes API, matutukoy ng Ingress kung saan dapat ipadala ang mga kahilingang ito. Bukod dito, ginagawa niya ito nang napaka-flexible. Maaari mong sabihin na ang lahat ng mga kahilingan sa host na ito at ganoon at ganoong URL ay ipinadala sa serbisyong ito. At ang mga kahilingang ito na dumarating sa host na ito at sa isa pang URL ay ipinapadala sa ibang serbisyo.

Ang pinaka-cool na bagay mula sa punto ng view ng isang tao na bumuo ng isang application ay na maaari mong pamahalaan ang lahat ng ito sa iyong sarili. Sa pamamagitan ng pagtatakda ng config ng Ingress, maaari mong ipadala ang lahat ng trapikong dumarating sa ganoon at ganoong API sa paghiwalayin ang mga container na nakasulat, halimbawa, sa Go. Ngunit ang trapikong ito, na dumarating sa parehong domain, ngunit sa ibang URL, ay dapat ipadala sa mga lalagyan na nakasulat sa PHP, kung saan maraming lohika, ngunit hindi sila masyadong mabilis.

Kung ihahambing natin ang lahat ng konseptong ito sa Nomad, masasabi nating ang unang tatlong konsepto ay magkakasamang Serbisyo. At ang huling konsepto ay wala sa Nomad mismo. Gumamit kami ng external balancer bilang ito: maaaring ito ay haproxy, nginx, nginx+, at iba pa. Sa kaso ng isang kubo, hindi mo kailangang ipakilala ang karagdagang konsepto na ito nang hiwalay. Gayunpaman, kung titingnan mo ang Ingress sa loob, ito ay alinman sa nginx, haproxy, o traefik, ngunit uri ng built in sa Kubernetes.

Ang lahat ng mga konseptong inilarawan ko ay, sa katunayan, mga mapagkukunan na umiiral sa loob ng isang Kubernetes cluster. Upang ilarawan ang mga ito sa cube, isang yaml na format ang ginagamit, na mas nababasa at pamilyar kaysa sa mga HCL file sa kaso ng Nomad. Ngunit sa istruktura ay inilalarawan nila ang parehong bagay sa kaso ng, halimbawa, pod. Sabi nila - Gusto kong mag-deploy ng ganito at ganoong mga pod doon, na may ganito at ganoong mga imahe, sa ganito at ganoong dami.

Bilang karagdagan, napagtanto namin na hindi namin nais na lumikha ng bawat indibidwal na mapagkukunan sa pamamagitan ng kamay: pag-deploy, mga serbisyo, Ingress, atbp. Sa halip, gusto naming ilarawan ang bawat isa sa aming mga system sa mga tuntunin ng Kubernetes sa panahon ng pag-deploy, nang sa gayon ay hindi namin kailangang manu-manong muling likhain ang lahat ng kinakailangang mga dependency sa mapagkukunan sa tamang pagkakasunud-sunod. Napili ang Helm bilang sistema na nagbigay-daan sa amin na gawin ito.

Pangunahing konsepto sa Helm

Helm ay manager ng package para sa Kubernetes. Ito ay halos kapareho sa kung paano gumagana ang mga manager ng package sa mga programming language. Pinapayagan ka nilang mag-imbak ng isang serbisyo na binubuo ng, halimbawa, deployment nginx, deployment php-fpm, config para sa Ingress, configmaps (ito ay isang entity na nagpapahintulot sa iyo na magtakda ng env at iba pang mga parameter para sa iyong system) sa anyo ng so- tinatawag na mga tsart. Sabay Helm tumatakbo sa ibabaw ng Kubernetes. Iyon ay, ito ay hindi isang uri ng sistema na nakatayo sa isang tabi, ngunit isa lamang serbisyo na inilunsad sa loob ng kubo. Nakikipag-ugnayan ka dito sa pamamagitan ng API nito sa pamamagitan ng console command. Ang kaginhawahan at kagandahan nito ay kahit na masira ang timon o alisin mo ito sa cluster, hindi mawawala ang iyong mga serbisyo, dahil ang timon ay nagsisilbi lamang upang simulan ang system. Ang Kubernetes mismo ay responsable para sa pagganap at estado ng mga serbisyo.

Narealize din namin yun templateization, na dati naming pinilit na gawin ang aming sarili sa pamamagitan ng pagpasok ng jinja sa aming mga config, ay isa sa mga pangunahing tampok ng timon. Ang lahat ng mga config na nilikha mo para sa iyong mga system ay naka-imbak sa timon sa anyo ng mga template, medyo katulad ng jinja, ngunit, sa katunayan, gamit ang template ng Go language, kung saan nakasulat ang timon, tulad ng Kubernetes.

Nagdaragdag ang Helm ng ilang mga konsepto para sa amin.

Tsart - ito ay isang paglalarawan ng iyong serbisyo. Sa ibang mga manager ng package, tatawagin itong package, bundle o katulad nito. Dito ito ay tinatawag na tsart.

Halaga ng ay ang mga variable na gusto mong gamitin upang buuin ang iyong mga config mula sa mga template.

Bitawan. Sa bawat oras na ang isang serbisyo na na-deploy gamit ang timon ay makakatanggap ng incremental na bersyon ng release. Naaalala ng Helm kung ano ang service config sa nakaraang release, ang release bago iyon, at iba pa. Samakatuwid, kung kailangan mong i-rollback, patakbuhin lang ang helm callback command, na itinuro ito sa nakaraang bersyon ng release. Kahit na ang kaukulang configuration sa iyong repository ay hindi available sa oras ng rollback, maaalala pa rin ng timon kung ano ito at i-rollback ang iyong system sa estado kung saan ito nasa nakaraang release.

Sa kaso kapag gumagamit kami ng timon, ang mga regular na config para sa Kubernetes ay nagiging mga template din kung saan posibleng gumamit ng mga variable, function, at maglapat ng mga conditional statement. Sa ganitong paraan maaari mong kolektahin ang iyong config ng serbisyo depende sa kapaligiran.

Sa pagsasagawa, nagpasya kaming gumawa ng mga bagay na medyo naiiba kaysa sa ginawa namin sa Nomad. Kung sa Nomad parehong naka-imbak ang mga config ng deployment at n-variable na kailangan para i-deploy ang aming serbisyo sa isang repositoryo, dito namin napagpasyahan na hatiin ang mga ito sa dalawang magkahiwalay na repositoryo. Ang "deploy" na repository ay nag-iimbak lamang ng mga n-variable na kailangan para sa deployment, at ang "helm" na repository ay nag-iimbak ng mga config o chart.

Ano ang ibinigay nito sa atin?

Sa kabila ng katotohanan na hindi kami nag-iimbak ng anumang talagang sensitibong data sa mga configuration file mismo. Halimbawa, ang mga password sa mga database. Ang mga ito ay naka-imbak bilang mga lihim sa Kubernetes, ngunit gayunpaman, may ilang mga bagay pa rin doon na hindi namin gustong bigyan ng access ang lahat. Samakatuwid, ang pag-access sa "deploy" na repository ay mas limitado, at ang "helm" na repository ay naglalaman lamang ng isang paglalarawan ng serbisyo. Para sa kadahilanang ito, maaari itong ma-access nang ligtas ng mas malawak na hanay ng mga tao.

Dahil mayroon kaming hindi lamang produksyon, kundi pati na rin ang iba pang mga kapaligiran, salamat sa paghihiwalay na ito maaari naming muling gamitin ang aming mga chart ng timon upang mag-deploy ng mga serbisyo hindi lamang sa produksyon, kundi pati na rin, halimbawa, sa isang kapaligiran ng QA. Kahit na i-deploy ang mga ito nang lokal gamit Minikube - ito ay isang bagay para sa lokal na pagpapatakbo ng Kubernetes.

Sa loob ng bawat imbakan, nag-iwan kami ng dibisyon sa magkakahiwalay na mga direktoryo para sa bawat serbisyo. Ibig sabihin, sa loob ng bawat direktoryo ay may mga template na nauugnay sa kaukulang tsart at naglalarawan sa mga mapagkukunang kailangang i-deploy upang patakbuhin ang aming system. Mga env lang ang iniwan namin sa "deploy" na repository. Sa kasong ito, hindi kami gumamit ng templating gamit ang jinja, dahil ang timon mismo ay nagbibigay ng templating out of the box - isa ito sa mga pangunahing function nito.

Nag-iwan kami ng deployment script - deploy.sh, na nagpapasimple at nag-standardize sa paglulunsad para sa deployment gamit ang timon. Kaya, para sa sinumang gustong mag-deploy, ang interface ng deployment ay mukhang eksaktong kapareho ng ginawa nito noong nagde-deploy sa pamamagitan ng Nomad. Ang parehong deploy.sh, ang pangalan ng iyong serbisyo, at kung saan mo ito gustong i-deploy. Ito ay nagiging sanhi ng timon upang simulan ang panloob. Ito, sa turn, ay nangongolekta ng mga config mula sa mga template, ipinapasok ang mga kinakailangang halaga ng mga file sa kanila, pagkatapos ay i-deploy ang mga ito, ilulunsad ang mga ito sa Kubernetes.

Natuklasan

Mukhang mas kumplikado ang serbisyo ng Kubernetes kaysa sa Nomad.

Dito napupunta ang papalabas na trapiko sa Ingress. Ito lang ang front controller, na siyang pumapalit sa lahat ng mga kahilingan at pagkatapos ay ipinapadala ang mga ito sa mga serbisyong naaayon sa data ng kahilingan. Tinutukoy nito ang mga ito batay sa mga config na bahagi ng paglalarawan ng iyong application sa timon at kung aling mga developer ang nagtakda sa kanilang sarili. Nagpapadala ang serbisyo ng mga kahilingan sa mga pod nito, iyon ay, mga partikular na container, na binabalanse ang papasok na trapiko sa pagitan ng lahat ng container na kabilang sa serbisyong ito. At, siyempre, hindi natin dapat kalimutan na hindi tayo dapat pumunta saanman mula sa seguridad sa antas ng network. Samakatuwid, gumagana ang segmentation sa isang Kubernetes cluster, na nakabatay sa pag-tag. Ang lahat ng mga serbisyo ay may ilang partikular na tag kung saan nauugnay ang mga karapatan sa pag-access ng mga serbisyo sa ilang panlabas/panloob na mapagkukunan sa loob o labas ng cluster.

Habang ginagawa namin ang paglipat, nakita namin na nasa Kubernetes ang lahat ng kakayahan ng Nomad, na dati naming ginamit, at nagdagdag din ng maraming bagong bagay. Maaari itong palawakin sa pamamagitan ng mga plugin, at sa katunayan sa pamamagitan ng mga custom na uri ng mapagkukunan. Ibig sabihin, mayroon kang pagkakataon hindi lamang na gumamit ng isang bagay na kasama ng Kubernetes out of the box, ngunit upang lumikha ng iyong sariling mapagkukunan at serbisyo na magbabasa ng iyong mapagkukunan. Nagbibigay ito sa iyo ng mga karagdagang opsyon upang palawakin ang iyong system nang hindi kinakailangang muling i-install ang Kubernetes at nang hindi nangangailangan ng mga pagbabago.

Ang isang halimbawa ng naturang paggamit ay ang Prometheus, na tumatakbo sa loob ng aming Kubernetes cluster. Upang makapagsimula itong mangolekta ng mga sukatan mula sa isang partikular na serbisyo, kailangan naming magdagdag ng karagdagang uri ng mapagkukunan, ang tinatawag na monitor ng serbisyo, sa paglalarawan ng serbisyo. Ang Prometheus, dahil sa katotohanang nakakabasa ito ng custom na uri ng mapagkukunan kapag inilunsad sa Kubernetes, awtomatikong nagsisimulang mangolekta ng mga sukatan mula sa bagong system. Ito ay medyo maginhawa.

Ang unang deployment na ginawa namin sa Kubernetes ay noong Marso 2018. At sa panahong ito, hindi kami nakaranas ng anumang problema dito. Ito ay gumagana nang maayos nang walang makabuluhang mga bug. Bilang karagdagan, maaari pa nating palawakin ito. Sa ngayon, sapat na ang mga kakayahan nito, at talagang gusto namin ang bilis ng pag-unlad ng Kubernetes. Sa kasalukuyan, mahigit 3000 container ang nasa Kubernetes. Sinasakop ng cluster ang ilang Node. Kasabay nito, ito ay nagsisilbi, matatag at napakakokontrol.

Pinagmulan: www.habr.com