Hindi magiging mali na sabihin na ang pinakamahusay sa mga tao
makahanap ng kagalakan sa pamamagitan ng pagdurusa.
Ludwig van Beethoven
Ako si Sergey, nagtatrabaho sa Yandex.Money sa performance research team. Gusto kong ibahagi ang simula ng kuwento ng aming paglalakbay sa paggamit ng orkestrasyon—kung paano namin pinili ang mga tool at kung ano ang aming isinasaalang-alang. Ang lahat ng nasa artikulong ito ay nangyayari sa real time, kaya kayo, mahal na mga mambabasa, ay maaaring masubaybayan ang mga pag-unlad na halos live.
Bakit kailangan namin ng konduktor sa aming koponan?
Kaya, sino ang isang konduktor? Mula sa French diriger—upang pamahalaan, idirekta, o idirekta—sa mundo ng musika, ito ang taong namamahala sa pag-aaral at pagganap ng ensemble music. Sa aming kaso, ang papel na ito ay inookupahan ng orkestrasyon at mga sistema ng automation.
Ang kanilang tungkulin ay hindi naiiba sa isang konduktor sa musika - nariyan sila upang tulungan ang koponan, idirekta at ayusin ang pagganap nito.
Kadalasan, ang isang team ay may ilang partikular na hanay ng mga kakayahan—tawagin natin silang mga server—kung saan nila ipinapatupad ang kanilang mga proyekto.
Ang diskarte sa pagkuha at pagpapatakbo ng mga server na ito ay nag-iiba. Narito ang ilang halimbawa:
- Ang koponan ay gumagawa ng isang kahilingan, halimbawa sa pangkat ng pagpapatakbo, upang bigyan sila ng mga mapagkukunan na may ilang mga parameter.
- Ang operations team ay nagbibigay ng kinakailangang halaga—cloud o bare metal—at nangangako na panatilihin ang mga ito sa mabuting kondisyon ayon sa SLA. Ang configuration ay pinangangasiwaan din ng operations team.
- Ang team ay tumatanggap lamang ng cloud o bare metal na mapagkukunan mula sa operations team, at nagsasagawa ng configuration sa sarili nitong.
- Ang koponan mismo ay "bumili" ng mga mapagkukunan at pinananatili/kino-configure ang mga ito nang ganap nang nakapag-iisa.
Gumagamit ang aming team ng mga server na nangangailangan ng maintenance—mga update sa operating system, pag-install ng mga bagong package, atbp.
Para sa ating sarili, natukoy natin ang mga ito sa dalawang pangunahing uri:
- grupo ng tangke,
- pangkat ng serbisyo.
Ang grupo ng tangke ay binubuo ng mga host na may Yandex.Tank.
Kasama sa pangkat ng serbisyo ang lahat ng nauugnay sa pagpapanatili—iba't ibang serbisyo para sa pagbibigay ng suporta para sa ikot ng paglabas, pagbuo ng mga awtomatikong ulat, atbp.
Sa isang punto, naging mahirap na pamahalaan ang lahat ng ito nang manu-mano, kaya nagsimula kaming mag-isip tungkol sa pag-automate ng buong proseso, mula sa pag-setup ng server hanggang sa pag-develop, pag-deploy, at paglulunsad ng aming panloob na serbisyo.
Bakit kailangan ang isang konduktor, kahit na ang orkestra mismo ay maaaring tumugtog?
Upang magsimula, pinagkadalubhasaan namin ang Ansible at sinimulan naming buuin ang aming mga bare metal na server upang hindi gaanong umasa sa mga administrator ng system. Ito ay isang win-win na sitwasyon: nakakakuha tayo ng mga bagong kasanayan at pinapaginhawa ang mga administrador ng ilan sa mga gawaing mayroon na silang marami. Nagsusumikap kaming umunlad nang higit sa aming espesyalidad at tiyakin ang awtonomiya ng koponan hangga't maaari.
Matagal nang nagtatrabaho ang kumpanya sa Ansible, kaya madali naming isinama ang aming solusyon sa prosesong ito.
Sa kasalukuyan, ang host provisioning ay binubuo ng tatlong Ansible na tungkulin:
- ang unang tungkulin ay nag-i-install ng OS,
- ang pangalawa ay nagpapatakbo ng mga pangunahing setting para sa host, pahintulot ng LDAP, halimbawa,
- at ang pangatlo ay nag-i-install ng Yandex.Tank at mga nauugnay na dependencies sa isang Docker container.
Lumipat tayo sa mga serbisyong ginagamit natin sa loob ng koponan.
Para sa aming mga gawain, ginagamit namin ang Kotlin at Python nang pantay-pantay, na may kaunting Golang. Upang gawing pamantayan ang pagbuo at pag-deploy ng aming mga serbisyo, nagpasya kaming i-package ang mga ito sa mga container ng Docker. Nagbibigay ito sa amin ng kalayaang pumili ng aming programming language habang sabay-sabay na tinitiyak ang isang pare-parehong format ng paghahatid para sa aming mga aplikasyon.
Isang mabilis na tala tungkol sa IPv6 sa Docker
Available lang ang ilan sa mga serbisyong nakikipag-ugnayan sa amin sa pamamagitan ng IPv6, kaya kinailangan naming malaman kung paano i-enable ang IPv6 para sa mga container.
Ayon sa dokumentasyon ng IPv6 sa opisyal na website ng Docker, ang IPv6 ay pinagana sa pamamagitan ng pagdaragdag ng mga parameter sa daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}Sa kasong ito, dapat magbigay ang provider ng IPv6 subnet, kung saan mo papasukin fixed-cidr-v6.
Gayunpaman, pumili kami ng ibang opsyon - ipv6 NAT, at narito kung bakit:
- Ngayon docker sa ipv6 lang.
- Ang pagkakaroon ng globally routable na address sa bawat container ay nangangahulugan na ang lahat ng port (kahit ang mga hindi na-publish) ay maa-access ng lahat maliban na lang kung magsagawa ng karagdagang pag-filter.
- userland proxy para sa pag-publish ng mga port, .
Ang IPv6 NAT ay , na mismong namamahala sa mga panuntunan sa ip6tables at nag-e-edit sa mga ito kapag nagdaragdag ng bagong container.
Para gumana nang tama ang solusyong ito, kailangan ng ilang hakbang. Mahalagang simulan ang ip6table_nat sa system. Ang pagkakaroon ng module na naka-install sa system ay hindi ginagarantiya na ito ay mai-load sa kernel sa startup. Nakatagpo namin ito noong natanggap namin ang sumusunod na error noong naglulunsad ng container na may NAT sa isang bagong host:
2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)Nalutas ang problema pagkatapos magdagdag ng initialization sa Ansible role gamit ang modprobe module at i-load ito sa OS startup gamit ang lineinfile:
- name: Add ip6table_nat module
modprobe:
name: ip6table_nat
state: present
- name: Add ip6table_nat to boot
lineinfile:
path: /etc/modules
line: 'ip6table_nat'Siyanga pala, may maganda sa Habr , na maikli at malinaw na naglalarawan ng mga pakinabang at disadvantages nito o ng pamamaraang iyon para sa pagtatrabaho sa IPv6 sa Docker.
Ngunit bumalik tayo sa ating tanong sa simula:
Bakit kailangan ang isang konduktor, kahit na ang orkestra mismo ay maaaring tumugtog?
Ngayon alam na ng lahat kung paano maglaro sa aming koponan:
- ang proseso ng "pagpuno" ng mga server ay nilikha,
- Ang pagbuo at pag-deploy ng mga serbisyo ay pinag-isa.
Lumilitaw ang isang makatwirang tanong: paano namin mai-deploy, mai-update, at masusubaybayan ang aming mga serbisyo sa mga container ng Docker nang mahusay at awtomatiko hangga't maaari?
Kahit na alam ng bawat miyembro ng orkestra ang kanilang bahagi, maaari silang malito at lumihis sa orihinal na plano. Dito tayo nagkakaroon ng konklusyon na kung walang konduktor, ang ating orkestra ay hindi mag-eensayo nang epektibo at tumutugtog nang maayos. Ang konduktor ay may pananagutan para sa lahat ng aspeto ng pagganap, tinitiyak na ang lahat ay pinag-iisa ng isang pare-parehong tempo at mood.
Paano makakuha ng isang mahusay na konduktor na may kaunting pamumuhunan?
Ang paksa ng orkestra ay medyo mahusay na binuo sa merkado. Ngunit una, pag-usapan natin ang tungkol sa mga pantulong na tool na maaaring tumulong sa isang konduktor.
— isang sistema na nagbibigay ng dalawang pangunahing pag-andar:
- pagtuklas ng serbisyo,
- ibinahagi na tindahan ng key-value.
Sa aming orkestra, ang Consul ay magiging responsable para sa pagpaparehistro ng mga serbisyo at pag-iimbak ng kanilang mga configuration. Mayroong dalawang pagpipilian sa pagpaparehistro:
- Ang aktibo ay kapag ang serbisyo ay nagrerehistro mismo gamit ang HTTP API;
- Passive - ang serbisyo ay dapat na nakarehistro nang manu-mano.
Ang Vault ay isang solusyon sa storage na nag-istandardize at pinagsasama-sama ang secure na storage at pamamahala ng mga lihim—mga password, certificate.
Narito ang mga benepisyong makukuha natin sa paggamit ng tool na ito:
- Isang solong sentro para sa paglikha at pag-iimbak ng mga lihim, at pamamahala ng kanilang lifecycle sa pamamagitan ng HTTP API.
- Transit Secrets Engine — pag-encrypt at pag-decrypt ng data nang hindi ito iniimbak. Pinapagana ang naka-encrypt na paglipat ng data sa mga hindi secure na channel ng komunikasyon.
- I-access ang mga patakaran na madaling i-configure.
- Pag-audit ng pag-access sa mga lihim.
- Ang kakayahang lumikha ng sarili mong CA (Certificate Authority) para pamahalaan ang mga self-signed certificate sa loob ng iyong imprastraktura.
Isinasaalang-alang ang lahat ng aming mga kinakailangan, dalawang opsyon ang angkop para sa tungkulin ng konduktor: Kubernetes at Nomad.
Kubernetes
Ilang artikulo at libro na ang naisulat tungkol sa kanya (dito , halimbawa), ang mga ulat ay ipinakita, na aking ibuod sa madaling sabi: ito ay isang unibersal na tool na maaaring gawin ang halos anumang bagay. Ang presyo para dito ay hindi laging madali ang pag-set up at pagpapanatili ng isang Kubernetes cluster.
Pagala
mula sa HashiCorp, ang kumpanyang kilala sa nabanggit na consul at vault.
Nalaman naming mas madaling i-install at i-configure ang Nomad kaysa sa Kubernetes. Ang isang binary ay tumatakbo sa parehong server at client mode. Higit pa rito, sinasaklaw ng Nomad ang lahat ng mga gawain na gusto naming pangasiwaan nito: pamamahala ng cluster, isang mabilis na scheduler, at suporta sa multidatacenter. Dagdag pa, ang paggamit ng consul at vault ay nagbibigay sa amin ng mas mahigpit na pagsasama para sa pagsasaayos ng aming mga serbisyo.
Ano ang kasalukuyang ginagawa:
- naghanda ng mga server para sa pag-deploy ng Consul,
- Maa-update ang Consul gamit ang configuration ng nomad cluster, na dapat magpapahintulot sa nomad na awtomatikong ma-deploy,
- Kasabay nito, mag-i-install kami ng vault upang mag-imbak ng mga lihim.
Isang tanong para sa madla: sulit bang kumuha ng konduktor para sa mga ganoong gawain, o maayos ba ang ginagawa ng orkestra kung wala ito? Ibahagi ang iyong mga saloobin sa mga komento.
Mag-subscribe sa aming blog at manatiling nakikipag-ugnayan—sa lalong madaling panahon ay sasabihin namin sa iyo kung ano ang nangyari at kung na-set up namin ang Nomad cluster sa paraang gusto namin.
Halika sa aming komportable , kung saan maaari kang palaging humingi ng payo, tumulong sa mga kasamahan, at simpleng makipag-chat tungkol sa pananaliksik sa pagiging produktibo at higit pa.
Pinagmulan: www.habr.com
