🥇Orchester výkonu

Ťažko povedať, že najlepší z ľudí
nachádzajú radosť cez utrpenie.
Ludwig van Beethoven

Som Sergej, pracujem v Yandex.Money v tíme pre výskum výkonu. Chcem vám rozprávať začiatok príbehu o našej ceste k používaniu orchestrácie — ako sme vyberali nástroje a čo sme pri tom zohľadnili. Všetky udalosti z článku sa dejú v reálnom čase, takže vy, milí čitatelia, sledujete vývoj situácie prakticky v priamom prenose.

Prečo potrebujeme dirigenta v tíme?

Kto je vlastne dirigent? Z francúzskeho diriger — riadiť, usmerňovať, viesť — vo svete hudby je to osoba, vedúca nácvik a výkon ansámblovej hudby. V našom prípade toto miesto zaujímajú systémy orchestrácie a automatizácie.

Ich úloha sa nijako nelíši od úlohy dirigenta v hudbe — sú potrební na to, aby pomáhali tímu, usmerňovali a organizovali jeho hru.

Tím zvyčajne disponuje určitým súborom kapacít — nazvime ich servermi, na ktorých realizujú svoje projekty.

Prístup k získavaniu a využívaniu týchto serverov je rôznorodý. Niekoľko príkladov:

Tím podáva požiadavku, napríklad do skupiny prevádzky, na poskytnutie im zdrojov s určitými parametrami.
Skupina prevádzky im poskytne potrebný počet — cloud alebo bare metal („holý hardvér“) — a zaviaže sa ich udržiavať v riadnom stave podľa SLA. Nastavenie sa taktiež vykonáva silami skupiny prevádzky.
Tím dostáva iba zdroje cloud alebo bare metal od skupiny prevádzky, nastavenie vykonáva svojimi silami.
Tím si sám „zabezpečuje“ zdroje a úplne ich sám udržiava/nastavuje.

V našom tíme používame servery, ktoré je potrebné udržiavať — aktualizovať operačný systém, inštalovať nové balíčky a pod.

Pre seba ich vyčleňujeme do dvoch hlavných typov:

tanková skupina,
servisná skupina.

Tanková skupina sa skladá z hostiteľov s Yandex.Tankom.

Servisná skupina obsahuje všetko, čo súvisí s obsluhou — rôzne služby na zabezpečenie podpory životného cyklu vydania, generovania automatických správ a pod.

V jednom momente sa stalo nepraktické riadiť to všetko manuálne a zamysleli sme sa nad automatizáciou celého procesu, počínajúc „nalievaním“ serverov a končiac vývojom, nasadením a spustením našich interných služieb.

Prečo je dirigent potrebný, aj keď orchester vie hrať sám?

Najprv sme zvládli Ansible a začali sme „nalievať“ naše servery bare metal, aby sme boli menej závislí od systémových administrátorov — z toho naozaj ťažia všetci, získavame nové zručnosti a zbavujeme administrátorov časti práce, ktorej majú vždy dosť aj bez nás. Snažíme sa o rozvoj mimo naše špecializácie a tímovú autonómiu, pokiaľ je to možné.

V spoločnosti je práca s Ansible už nastavená a zregulovaná dosť dlho, takže sme ľahko integrovali svoje riešenie do tohto procesu.

Momentálne sa nalievanie hostiteľov skladá z troch rolí Ansible:

prvá rola inštaluje OS,
druhá vykonáva základné nastavenia pre hostiteľa, napríklad LDAP autorizáciu,
a tretia inštaluje Yandex.Tank do docker kontajnera a potrebné závislosti.

Prejdime k službám, ktoré používame v rámci tímu.

Pre naše úlohy používame rovnako Kotlin a Python, a ešte trošku Golang. Aby sme zjednotili vývoj a nasadenie našich služieb, rozhodli sme sa zabalíť ich do docker kontajnerov. To nám dáva slobodu voľby programovacieho jazyka a zároveň upravuje jednotný formát dodania našich aplikácií.

Malá poznámka o ipv6 v Dockeri

Časť služieb, s ktorými komunikujeme, je dostupná iba prostredníctvom ipv6, takže sme museli prísť na to, ako spraviť ipv6 pre kontajnery.

Podľa dokumentácie o ipv6 na oficiálnych stránkach Dockera sa ipv6 aktivuje pridaním parametrov do daemon.json:

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

V tomto prípade by mal poskytovateľ poskytnúť podsieť ipv6, ktorú zapíšete do fixed-cidr-v6.
Avšak zvolili sme iný variant — ipv6 NAT, a to z nasledujúcich dôvodov:

V súčasnosti docker nie je možné používať iba s ipv6.
Povolenie globálne smerovateľnej adresy v každom kontejnery znamená, že všetky porty (aj nepublikované) sú prístupné všetkým, pokiaľ sa nevykoná dodatočná filtrácia.
userland proxy na publikovanie portov, iptables iba pre ipv4.

ipv6 NAT — to je docker kontajner, ktorý sám spravuje pravidlá v ip6tables a upravuje ich pri pridávaní nového kontajnera.

Aby toto riešenie správne fungovalo, bolo potrebné vykonať ešte niekoľko manipulácií. Nevyhnutne je potrebné inicializovať ip6table_nat v systéme. To, že je modul nainštalovaný v systéme, nezaručuje, že pri spustení sa modul načíta do jadra. S týmto sme sa stretli, keď sme dostali takúto chybu pri spustení kontajnera s NAT na čerstvom hoste:

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ém bol vyřešený po pridaní do úlohy Ansible inicializácie pomocou modulu modprobe a načítania pri štarte OS pomocou 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'

Mimochodom, na habre je dobrá článok, ktorá stručne a jasne popisuje výhody a nevýhody rôznych metód práce s ipv6 v dockeri.

Ale vráťme sa k našej otázke, položené na začiatku:
Prečo je dirigent potrebný, aj keď orchester vie hrať sám?

Teraz všetci chápu, ako hrať v našej družine:

proces „nalievania“ serverov je vytvorený,
vývoj a nasadenie služieb sú unifikované.

Zdá sa, že je tu rozumná otázka — ako efektívne a maximálne automatizovane nasadzovať, aktualizovať, kontrolovať naše služby v docker-kontajneroch?

Napriek tomu, že každý člen orchestra pozná svoju partiu, môže sa pomýliť a odchýliť sa od pôvodnej predstavy. Tu prichádzame k tomu, že bez dirigenta náš orchester nebude efektívne rehetrí a zharmonizovane hrať. Dirigent zodpovedá za všetky parametre výkonu, za to, aby všetko bolo spojené jediným tempom a náladou.

Ako získať dobrého dirigenta s minimálnymi investíciami?

Téma orchestrácie je na trhu dostatočne rozvinutá. Ale najprv sa porozprávajme o pomocných nástrojoch, ktoré môžu pomôcť dirigentovi.

Consul — systém, ktorý poskytuje dve hlavné funkcie:

objavovanie služieb (service discovery),
distribuované úložisko pre kľúč-hodnotu.

V našom orchestri bude Consul zodpovedať za registráciu služieb a uchovávanie ich konfigurácií. Existujú dve možnosti registrácie:

Aktívna — to je, keď sa služba sama registruje pomocou HTTP API;
Pasívna — službu je potrebné zaregistrovať ručne.

Vault je úložiště, které standardizuje a zjednocuje bezpečné ukládání a práci s tajemstvími — hesla, certifikáty.
Toto jsou výhody, které získáme použitím tohoto nástroje:

Jednotné centrum pro vytváření a ukládání tajemství, správa jejich životního cyklu pomocí HTTP API.
Transit Secrets Engine — šifrování a dešifrování dat bez jejich ukládání. Možnost přenosu dat zašifrovaně přes nechráněné komunikační kanály.
Přístupové politiky, které se dají snadno nastavit.
Audit přístupu k tajemstvím.
Možnost vytvoření vlastního CA (Certificate Authority) pro správu vlastních certifikátů v rámci své infrastruktury.

S ohledem na všechny naše požadavky, na roli dirigenta byly dva varianty — Kubernetes a Nomad.

Kubernetes

Kolik už bylo napsáno článků a knih (tady takové, například), bylo řečeno přednášek, takže to shrnu — je to univerzální kombajn, který může prakticky cokoli. Cena za to — ne vždy jednoduché nastavení a údržba clustera na Kubernetes.

Nomad

Nástroj od HashiCorp, společnosti známé zmiňovanými consul a vault.

Nomad se nám zdál dostatečně jednoduchý pro instalaci a nastavení ve srovnání s Kubernetes. Jeden binární soubor funguje jak v režimu serveru, tak klienta. Přitom Nomad pokrývá celý seznam úkolů, které chceme, aby řešil: správa clustera, rychlý plánovač, podpora pro multidatacentra. Navíc při používání consul a vault získáváme bližší integraci pro orchestraci našich služeb.

Co je nyní v práci:

připravili jsme servery pro nasazení Consul,
do Consul bude vložena konfigurace clustera nomad, pomocí které bude nomad nasazen automaticky,
paralelně budeme instalovat vault pro ukládání tajemství.

Otázka do sálu — má smysl zavádět dirigenta pro takové úkoly nebo orchestrace bez něj funguje dobře? Podělte se v komentářích o své názory na toto téma.

Sledujte náš blog a zůstaňte v kontaktu — brzy vám povíme, co se nakonec povedlo, a zda jsme nastavili cluster nomad tak, jak jsme chtěli.

Zavítejte do našeho útulného telegramového chatu, kde můžete vždy požádat o radu, pomoci kolegům a jen tak si popovídat o výzkumu výkonnosti a nejen o tom.

Zdroj: habr.com