Orkestra e performancës

Nuk është e gabuar të thuhet se njerëzit më të mirë
kanë gëzim përmes vuajtjes.
Ludwig van Beethoven

Unë jam Sergei, punoj në Yandex.Money në ekipin e hulumtimit të performancës. Dëshiroj t'ju tregoj fillimin e historisë sonë për përdorimin e orkestrimit — si zgjodhëm mjetet dhe çfarë kemi marrë parasysh. Të gjitha ngjarjet në artikull ndodhin në kohë reale, kështu që ju, lexuesit e dashur, po ndiqni zhvillimin e situatës pothuajse në kohë reale.

Përse na nevojitet një dirigjent në ekip?

Kush është dirigjenti? Nga frëngjishtja diriger — të udhëheqësh, të drejtosh, të menaxhosh — në botën e muzikës — është një person, udhëheqësi i praktikimit dhe interpretimit të muzikës ansambël. Në rastin tonë, ky vend zë sistemet e orkestrimit dhe automatizimit.

Roli i tyre nuk ndryshon nga ai i dirigjentit në muzikë — ata janë të nevojshëm për të ndihmuar ekipin, për të drejtuar dhe organizuar interpretimin e tij.

Si rregull, ekipi ka një grup kapacitetesh — le t'i quajmë servera, në të cilët ata realizojnë projektet e tyre.

Qasja për marrjen dhe shfrytëzimin e këtyre serverëve është e ndryshme. Disa shembuj:

• Ekipi bën një kërkesë, për shembull në grupin e operacioneve, për t'u siguruar burime me parametra të caktuar.
• Grupi i operacioneve siguron sasinë e nevojshme — cloud ose bare metal («harduer i papërpunuar») — dhe obligohet t'i mbajë ato në gjendje të mirë sipas SLA. Konfigurimi gjithashtu realizohet nga grupi i operacioneve.
• Ekipi merr vetëm burime cloud ose bare metal nga grupi i operacioneve, konfigirimi e bën vetë.
• Ekipi vetë «bler» burimet dhe i mban/konfiguron ato plotësisht në mënyrë të pavarur.

Në ekipin tonë përdoren serverë që duhet të mbahen — të rinovohen OS, të instalohen paketa të reja, etj.

Për vete i kemi ndarë në dy lloje kryesore:

• grupi i tankeve,
• grupi i shërbimit.

Grupi i tankeve përbëhet nga hoste me Yandex.Tank.

Grupi i shërbimit përfshin gjithçka që lidhet me shërbimin — këtu janë shërbime të ndryshme që sigurojnë mbështetje për ciklin e lëshimit, gjenerimin e raporteve automatike, etj.

Në një moment, u bë e vështirë të menaxhohet gjithçka manualisht, prandaj menduam për automatizimin e gjithë procesit, duke filluar nga 'instalimi' i serverëve dhe duke përfunduar me zhvillimin, publikimin dhe lançimin e shërbimit tonë të brendshëm.

Pse nevojitet një dirigjent, edhe nëse orkestrat dinë të luajnë vetë?

Fillimisht, ne përvetësuam Ansible dhe filluam të 'instalojmë' serverët tanë bare metal, për të qenë më pak të varur nga administratorët e sistemeve — këtu përfitojnë të gjithë, ne fitojmë aftësi të reja dhe i lirojmë administratorët nga një pjesë e punës, e cila gjithmonë është mjaft e mjaftueshme për ta. Ne kemi një synim për t'u zhvilluar jashtë specialitetit tonë dhe për autonominë e ekipit sa më shumë që të jetë e mundur.

Në kompaninë tonë, puna me Ansible është e organizuar dhe rregulluar prej kohësh, prandaj ne e integrojmë lehtësisht zgjidhjen tonë në këtë proces.

Aktualisht, instalimi i hosteve konsiston në tre role Ansible:

• rolin e parë instalon OS-në,
• roli i dytë bën konfigurimet e bazës për hostin, si për shembull autorizimin LDAP,
• dhe roli i tretë instalon Yandex.Tank në një kontejner docker dhe varësitë përkatëse.

Tani kalojmë në shërbimet që përdorim brenda ekipit.

Për ne, po përdorim në mënyrë të barabartë Kotlin dhe Python, dhe pak Golang. Për të unifikuar zhvillimin dhe implementimin e shërbimeve tona, kemi vendosur t'i paketojmë ato në konteinerë docker. Kjo ofron lirinë për të zgjedhur gjuhën e programimit dhe njëkohësisht rregullon një format të vetëm për dorëzimin e aplikacionit tonë.

Një vërejtje e vogël rreth ipv6 në Docker

Pjesa e shërbimeve me të cilat ne bashkëpunojmë është e доступна vetëm përmes ipv6, prandaj ishte e nevojshme të kuptohej se si të bëhet ipv6 për konteinerët.

Sipas dokumentacionit për ipv6 në faqen zyrtare të Docker, ipv6 aktivizohet duke shtuar parametrat në daemon.json:

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

Në të njëjtën kohë, ofruesi duhet të japë një nënrrjetë ipv6, të cilën do ta shkruani në fixed-cidr-v6.
Megjithatë, ne zgjodhëm një opsion tjetër — ipv6 NAT, dhe ja pse:

• Tani docker nuk mund të përdoret vetëm me ipv6.
• Prania e një adrese globalisht e drejtuar në çdo konteiner do të thotë se të gjitha portet (edhe ato të pavendosura) bëhen të qasshme për të gjithë, nëse nuk ka një filtrin tjetër të shtuar.
• proxy i userland për publikimin e porteve, iptables vetëm për ipv4.

ipv6 NAT — kjo është docker-konteineri, i cili menaxhon vetë rregullat në ip6tables dhe i editojnë ato kur shtohet një konteiner i ri.

Për të funksionuar siç duhet ky zgjidhje, ishte e nevojshme të bëheshin disa manipulime. Është e domosdoshme të inicializohet ip6table_nat në sistem. Prania e modulit të instaluar në sistem nuk garanton që kur të ndizet, moduli do të ngarkohet në kernel. Ne u përballëm me këtë, kur morëm këtë gabim gjatë nisjes së konteinerit me NAT në një host të ri:

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?)

Problemi u zgjidh pas shtimit në rolin Ansible të inicializimit përmes modulit modprobe dhe ngarkimit në fillim të sistemit me lineinfile:

- name: Shto modulin ip6table_nat
  modprobe:
    name: ip6table_nat
    state: present
- name: Shto ip6table_nat në nisje
  lineinfile:
    path: /etc/modules
    line: 'ip6table_nat'

Për shembull, në Habra ka një të mirë artikull, e cila përshkruan shkurtimisht dhe qartë përparësitë dhe disavantazhet e metodave të ndryshme për të punuar me ipv6 në docker.

Por le të kthehemi në pyetjen tonë, e cila u bë në fillim:
Pse nevojitet një dirigjent, edhe nëse orkestrat dinë të luajnë vetë?

Tani të gjithë e përfytyrojnë se si të luajnë në ekipin tonë:

• processi i "derdhjes" së serverëve është krijuar,
• zhvillimi dhe deploy i shërbimeve janë të unifikuara.

Shfaqet një pyetje e arsyeshme — si të depilojmë, përditësojmë dhe kontrollojmë shërbimet tona në konteinerat docker sa më efektivisht dhe automatikisht?

Pavarësisht se çdo anëtar i orkestrës e njeh rolin e tij, ai mund të devijojë dhe të largohet nga qëllimi fillestar. Këtu arrijmë në përfundimin se pa një dirigjent, orkestrën tonë nuk do të jetë efektive në provime dhe nuk do të luajë me sinkronizim. Dirigjenti është përgjegjës për të gjitha parametrat e ekzekutimit, që gjithçka të jetë e bashkuar me një ritëm dhe humor të përbashkët.

Si të sigurojmë një dirigjent të mirë me investime minimale?

Tema e orkestrimit është zhvilluar mjaft mirë në treg. Por fillimisht, le të flasim për mjetet ndihmës që mund ta ndihmojnë dirigjentin.

Consul — një sistem që ofron dy funksione kryesore:

• zbulesë shërbimesh (service discovery),
• depozitë të shpërndarë të çelës-veçori.

Në orkestrën tonë, Consul do të përgjigjet për regjistrimin e shërbimeve dhe ruajtjen e konfigurimeve të tyre. Ka dy mundësi regjistrimi:

• Aktive — kjo është kur shërbimi regjistron veten duke përdorur HTTP API;
• Pasive — shërbimi duhet të regjistrohet manualisht.

Vault — është një depo që standardizon dhe unifikon ruajtjen e sigurt dhe punën me sekrete — fjalëkalime, certifikata.
Ja përparësitë që do të fitojmë duke përdorur këtë mjet:

• Një qendër e vetme për krijimin dhe ruajtjen e sekreteve, duke menaxhuar ciklin e jetës së tyre përmes HTTP API.
• Transit Secrets Engine — enkriptimi dhe dekryptimi i të dhënave pa i ruajtur ato. Mundësia për të transferuar të dhënat në formë të enkriptuar përmes kanaleve të pasigurta.
• Politikat e qasjes, të cilat janë lehtë të konfigurueshme.
• Auditimi i qasjes në sekrete.
• Mundësia për të krijuar një CA (Autoritetin e Certifikimit) për të menaxhuar certifikatat e nënshkruara vetë brenda infrastrukturës së saj.

Duke marrë parasysh të gjitha kërkesat tona, dy opsione ishin të përshtatshme për rolin e dirigjentit — Kubernetes dhe Nomad.

Kubernetes

Sa shumë artikuj dhe libra janë shkruar për të (ja kjo, për shembull), janë përfolur shumë ligjërata, prandaj do ta shkruaj shkurt — është një kombinator universale që mund të bëjë pothuajse gjithçka. Shkalla për këtë — nuk janë gjithmonë të lehta konfigurimi dhe mbështetje e klasterit në Kubernetes.

Nomad

Instrument nga HashiCorp, një kompani e njohur për consul dhe vault siç u përmend më lart.

Nomad na duket mjaft i lehtë për t'u instaluar dhe konfiguruar, më shumë se Kubernetes. Një skedar binar funksionon si në mënyrë serveri, ashtu edhe në atë klienti. Në të njëjtën kohë, Nomad përfshin të gjithë listën e detyrave që dëshirojmë të zgjidhë: menaxhimi i klasterit, planifikues i shpejtë, mbështetje multidatacenter. Për më tepër, duke përdorur consul dhe vault, ne marrim një integrim më të ngushtë për orkestrimin e shërbimeve tona.

Çfarë është në punë tani:

• kemi përgatitur serverat për implementimin e Consul,
• në Consul do të regjistrohet konfigurimi i klasterit nomad, përmes të cilit nomad duhet të implementohet automatikisht,
• paralelisht do të instalojmë vault për ruajtjen e sekreteve.

Pyetja në sallë — a ka vlerë të hymë në një orkestrues për detyra të tilla apo orkestrimi shkon mirë edhe pa të? Na tregoni në komentet tuaj se çfarë mendoni për këtë.

Abonohuni në blogun tonë dhe qëndroni në kontakt — së shpejti do t'ju tregojmë se çfarë arritëm në fund dhe nëse e konfiguruan klasterin nomad ashtu si dëshironim.

Hyni në bisedën tonë të Telegramit, ku gjithmonë mund të kërkoni këshilla, të ndihmoni kolegët dhe thjesht të flisni për hulumtimet e performancës dhe jo vetëm.

Burimi: habr.com