Grūti būtu apgalvot, ka labākie cilvēki
atrod prieku caur ciešanām.
Ludvigs van Bīthovens
Es esmu Sergejs, strādāju Yandex.Money veiktspējas pētniecības komandā. Vēlos pastāstīt par mūsu ceļojuma sākumu uz orķestrāciju — kā mēs izvēlējāmies rīkus un ko ņēmām vērā. Visi rakstā aprakstītie notikumi notiek reālā laikā, tāpēc jūs, dārgi lasītāji, praktiski sekojat situācijas attīstībai tiešraidē.
Kāpēc mums komandā ir dirigents?
Kas ir dirigents? No franču valodas diriger — vadīt, organizēt, komandēt — mūzikas pasaulē tas ir cilvēks, kurš vada ansambļa muzikālo izpildījumu. Mūsu gadījumā šo lomu aizņem orķestrācijas un automatizācijas sistēmas.
Viņu loma neatšķiras no dirigenta lomas mūzikā — tie ir nepieciešami, lai palīdzētu komandai, vadītu un organizētu tās spēli.
Parasti komandai ir noteikts jaudas kopums — sauksim tās par serveriem, uz kuriem tie īsteno savus projektus.
Pieeja šo serveru iegūšanai un ekspluatācijai ir dažāda. Daži piemēri:
- Komanda veic pieprasījumu, piemēram, ekspluatācijas grupai, par resursu nodrošināšanu ar noteiktiem parametriem.
- Ekspluatācijas grupa nodrošina viņiem nepieciešamo daudzumu — cloud vai bare metal („tīro dzelzi”) — un apņemas uzturēt tos labā stāvoklī saskaņā ar SLA. Iestatīšana tiek veikta arī ekspluatācijas grupas spēkos.
- Komanda saņem tikai cloud vai bare metal resursus no ekspluatācijas grupas, iestatīšanu viņi veic paši.
- Komanda pati „iegādājas” resursus un pilnībā uztur/nosaka tos pati.
Mūsu komandā tiek izmantoti serveri, kurus nepieciešams atbalstīt — atjaunināt OS, instalēt jaunus pakotnes utt.
Mēs izcēlām tos divos galvenajos tipos:
- tanku grupa,
- servisa grupa.
Tanku grupa sastāv no hostiem ar Yandex.Tank.
Servisa grupa ietver visu, kas saistīts ar apkalpošanu — tas ir dažādi pakalpojumi, kas nodrošina atbalstu izlaišanas ciklam, automātisko ziņojumu ģenerēšanu utt.
Vienā brīdī visam šim kļuva neērti pārvaldīt manuāli, un mēs domājām par visa procesa automatizāciju, sākot no serveru "uzpildīšanas" līdz mūsu iekšējā pakalpojuma izstrādei, izvietošanai un palaišanai.
Kāpēc orķestrim nepieciešams diriģents, pat ja orķestris pats prot spēlēt?
Vispirms mēs apguvām Ansible un sākām "uzpildīt" mūsu bare metal serverus, lai būtu mazāk atkarīgi no sistēmu administratoriem — šeit ieguvēji esam visi, mēs iegūstam jaunas prasmes un atbrīvojam administratorus no daļas darba, kurā viņiem arī bez mums vienmēr ir pietiekami daudz.
Mūsu uzņēmumā darbs ar Ansible jau ir pietiekami labi organizēts un reglamentēts, tāpēc mēs viegli iekļāvām savu risinājumu šajā procesā.
Šobrīd hostu uzpilde sastāv no trim Ansible lomām:
- pirmā loma uzstāda OS,
- otrā veic pamata iestatījumus hostam, piemēram, LDAP autorizāciju,
- un trešā uzstāda Yandex.Tank un saistītās atkarības docker konteinerā.
Pāriesim pie pakalpojumiem, kurus mēs izmantojam komandā.
Saviem uzdevumiem mēs vienlīdz izmantojam Kotlin un Python, kā arī nedaudz Golang. Lai vienkāršotu mūsu pakalpojumu izstrādi un izvietošanu, mēs nolēmām tos iepakot docker konteineros. Tas sniedz brīvību izvēlēties programmēšanas valodu un vienlaicīgi regulē vienotu formātu savas aplikācijas piegādei.
Mazs paskaidrojums par ipv6 Docker
Daži pakalpojumi, ar kuriem mēs sadarbojamies, ir pieejami tikai pa ipv6, tādēļ nācās saprast, kā izveidot ipv6 konteineriem.
Saskaņā ar oficiālās Docker dokumentācijas par ipv6, ipv6 tiek aktivizēts, pievienojot parametrus daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}Tomēr pakalpojumu sniedzējam jāizsniedz ipv6 apakšnet, kuru jūs ierakstīsiet fixed-cidr-v6.
Tomēr mēs izvēlējāmies citu variantu — ipv6 NAT, un šeit ir iemesls:
- Šobrīd docker tikai ar ipv6.
- Ja katrā konteinerā ir globāli maršrutējams adrese, tas nozīmē, ka visi porti (pat nepublicētie) kļūst pieejami visiem, ja netiek veikta papildu filtrācija.
- userland proxy portu publikācijai, .
ipv6 NAT — tas ir , kas pats pārvalda noteikumus ip6tables un rediģē tos, pievienojot jaunu konteineru.
Lai šis risinājums darbotos pareizi, bija jāveic vēl dažas manipulācijas. Nepieciešams inicializēt ip6table_nat sistēmā. Klātbūtne instalētā moduļa sistēmā nenodrošina, ka procesa sākumā modulis tiks ielādēts kodolā. Mēs saskārāmies ar šo, kad saņēmām šādu kļūdu, uzsākot konteineru ar NAT uz jauna hosta:
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?)Problēma tika atrisināta pēc inicializācijas pievienošanas Ansible lomai, izmantojot modprobe moduli un ielādējot to operētājsistēmas palaišanas laikā, izmantojot lineinfile:
- name: Pievienot ip6table_nat moduļus
modprobe:
name: ip6table_nat
state: present
- name: Pievienot ip6table_nat uz startu
lineinfile:
path: /etc/modules
line: 'ip6table_nat'Starp citu, Habrā ir laba , kas īsi un skaidri apraksta katras metodes priekšrocības un trūkumus, strādājot ar ipv6 Docker.
Bet atgriezīsimies pie mūsu sākotnējā jautājuma:
Kāpēc orķestrim nepieciešams diriģents, pat ja orķestris pats prot spēlēt?
Tagad viss skaidrs par to, kā spēlēt mūsu komandā:
- serveru «nolišanas» process ir izveidots,
- pakalpojumu izstrāde un izvietošana ir standartizēta.
Radās saprātīgs jautājums — kā efektīvi un maksimāli automatizēti izvietot, atjaunināt un kontrolēt mūsu pakalpojumus Docker konteineros?
Neskatoties uz to, ka katrs orķestra dalībnieks zina savu lomu, viņš var izkrist no ritma, atkāpjoties no sākotnējās ieceres. Šeit mēs nonākam pie tā, ka bez diriģenta mūsu orķestris nevarēs efektīvi mēģināt un saskaņoti spēlēt. Diriģents atbild par visiem izpildes parametriem, pārliecinoties, ka viss ir apvienots ar vienotu tempu un noskaņu.
Kā ar minimālām investīcijām iegūt labu diriģentu?
Orķestrēšanas tēma ir pietiekami labi attīstīta tirgū. Bet vispirms runāsim par palīgrīkiem, kas varētu palīdzēt diriģentam.
— sistēma, kas sniedz divas galvenās funkcijas:
- pakalpojumu atklāšana (service discovery),
- izplatīta atslēga-vērtība krātuve.
Mūsu orķestrī Consul atbildēs par pakalpojumu reģistrāciju un to konfigurāciju glabāšanu. Ir divi reģistrācijas varianti:
- Aktīvā — kad pakalpojums pats sevi reģistrē, izmantojot HTTP API;
- Pasīvā — pakalpojuma reģistrēšanai ir jāraksta manuāli.
Vault ir uzglabāšanas risinājums, kas standartizē un apvieno drošu noslēpumu, piemēram, paroli un sertifikātu, glabāšanu un apstrādi.
Šeit ir ieguvumi, ko mēs iegūsim, izmantojot šo rīku:
- Viens centrs, lai izveidotu un glabātu noslēpumus, kā arī pārvaldītu to dzīves ciklu, izmantojot HTTP API.
- Transit Secrets Engine — datu šifrēšana-atslēgšana bez to saglabāšanas. Iespēja pārsūtīt datus šifrētā veidā pa neaizsargātiem sakaru kanāliem.
- Piekļuves politikas, kuras ir ērti iestatīt.
- Audits par piekļuvi noslēpumiem.
- Iespēja izveidot savu CA (sertifikācijas autoritāti), lai pārvaldītu pašaizpildītos sertifikātus savā infrastruktūrā.
Ņemot vērā visus mūsu prasības, par diriģentu derēja divi varianti – Kubernetes un Nomad.
Kubernetes
Cik jau rakstu un grāmatu par to ir uzrakstīts (lūk, , piemēram), ir stāstīts lekciju gadu, tāpēc rakstīšu īsi – tas ir universāls mašīna, kas var praktiski visu. Samaksas par to – ne vienmēr viegla iestatīšana un atbalsts kubernetes klastera.
Nomad
no HashiCorp, uzņēmuma, kas pazīstams ar iepriekš minēto consulu un vault.
Nomad mums šķita daudz vieglāk uzstādīt un konfigurēt nekā Kubernetes. Viens izpildfaila darbs kā servera, tā arī klienta režīmā. Turklāt Nomad aptver visu uzdevumu sarakstu, kurus mēs vēlētos, lai tas risinātu: klastera pārvaldība, ātra plānošana, multidatacenter atbalsts. Turklāt, izmantojot consulu un vault, mēs iegūstam ciešāku integrāciju mūsu pakalpojumu orķestrācijai.
Kas šobrīd ir darba procesā:
- sagatavojuši serverus Consul izvietošanai,
- Consul tiks ierakstīta nomad klastera konfigurācija, ar kuras palīdzību nomad tiks automātiski izvietots,
- vienlaikus uzstādīsim vault noslēpumu glabāšanai.
Jautājums zālē — vai ir vērts izveidot diriģentu šādām funkcijām, vai orķestrā bez tā arī labi? Pastāstiet komentāros, ko domājat par to.
Sekojiet mūsu emuāram un palieciet saistībā — drīz pastāstīsim, kas iznācis, un vai mēs konfigurējām nomad klasteri tā, kā vēlējāmies.
Nāciet uz mūsu relaksējošo , kur jūs vienmēr varat lūgt padomu, palīdzēt kolēģiem un vienkārši parunāt par veiktspējas pētījumiem un ne tikai.
Avots: habr.com
