Těžko by se dalo říct, že ti nejlepší mezi námi
nacházejí radost prostřednictvím utrpení.
Ludwig van Beethoven
Jsem Sergey, pracuji v Yandex.Money na týmu pro výkonová zkoumání. Chci vám vyprávět začátek příběhu o naší cestě k využití orchestrace — jak jsme vybírali nástroje a co jsme při tom zohledňovali. Všechny události v článku probíhají v reálném čase, takže vy, drazí čtenáři, sledujete vývoj situace téměř v přímém přenosu.
Proč potřebujeme dirigenta v týmu?
Kdo vlastně je dirigent? Z francouzského diriger — řídit, směřovat, vést — ve světě hudby je to osoba, vedoucí přípravy a výkonu souborové hudby. V našem případě tuto roli hrají systémy orchestrace a automatizace.
Jejich úloha se nijak neliší od role dirigenta v hudbě — jsou potřební, aby pomáhali týmu, směřovali a organizovali jeho hru.
Obvykle má tým určitou sadu kapacit — nazvěme je servery, na kterých realizují své projekty.
Přístup k získání a provozování těchto serverů je různorodý. Několik příkladů:
- Tým podá žádost, například k provozní skupině, o poskytnutí zdrojů s určitými parametry.
- Provozní skupina jim poskytne potřebné množství — cloud nebo bare metal („holé železo“) — a zavazuje se je udržovat v patřičném stavu podle SLA. Nastavení provádí také provozní skupina.
- Tým obdrží pouze zdroje cloud nebo bare metal od provozní skupiny, nastavení provádí vlastními silami.
- Tým si sám „nakupuje“ zdroje a kompletně je udržuje/nastavuje sám.
V našem týmu se používají servery, které je třeba udržovat — aktualizovat OS, instalovat nové balíčky atd.
Pro sebe jsme je rozlišili do dvou hlavních typů:
- tanková skupina,
- servisní skupina.
Tanková skupina se skládá z hostitelů s Yandex.Tankem.
Servisní skupina zahrnuje vše, co souvisí s údržbou — to jsou různé služby na podporu životního cyklu vydání, generování automatických reportů atd.
V jednom okamžiku se stalo nepohodlné spravovat to všechno ručně, a tak jsme začali přemýšlet o automatizaci celého procesu, počínaje „naléváním“ serverů a konče vývojem, nasazením a spuštěním našeho interního servisu.
Proč je dirigent potřebný, i když orchestr umí hrát sám?
Nejprve jsme se naučili Ansible a začali „nalévat“ naše servery bare metal, abychom byli méně závislí na systémových administrátorech — zde vyhráváme všichni, získáváme nové dovednosti a osvobozujeme administrátory od části práce, které mají vždy dost. Snažíme se o rozvoj mimo naši specializaci a týmu co nejvíce autonomie.
V naší společnosti je práce s Ansible již dávno nastavena a regulována, takže jsme snadno začlenili naše řešení do tohoto procesu.
Dnes se nalévání hostitelů skládá ze tří rolí Ansible:
- první role instaluje operační systém,
- druhá provádí základní nastavení pro hostitele, například LDAP autorizaci,
- a třetí instalační skript do docker kontejneru Yandex.Tank a související závislosti.
Přejděme k službám, které uvnitř týmu používáme.
Pro naše úkoly používáme srovnatelně Kotlin a Python, a také o něco málo Golang. Abychom sjednotili vývoj a nasazení našich služeb, rozhodli jsme se je balit do docker kontejnerů. To poskytuje svobodu volby programovacího jazyka a zároveň reguluje jednotný formát dodání našeho aplikace.
Malá poznámka o ipv6 v Dockeru
Část služeb, se kterými interagujeme, je dostupná pouze přes ipv6, a proto jsme se museli naučit, jak udělat ipv6 pro kontejnery.
Podle dokumentace k ipv6 na oficiálních stránkách Dockeru se ipv6 aktivuje přidáním parametrů do daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}Přičemž poskytovatel musí vydat podsíť ipv6, kterou zapíšete do fixed-cidr-v6.
My jsme si však vybrali jinou možnost — ipv6 NAT, a to z následujících důvodů:
- Nyní docker pouze s ipv6.
- Přítomnost globálně směrovatelné adresy v každém kontejneru znamená, že všechny porty (i nepublikované) jsou dostupné všem, pokud neprobíhá dodatečná filtraci.
- use-userland proxy pro publikaci portů, .
ipv6 NAT je , který sám spravuje pravidla v ip6tables a upravuje je při přidání nového kontejneru.
Aby toto řešení správně fungovalo, bylo nezbytné provést ještě řadu dalších manipulací. Je nutné inicializovat ip6table_nat v systému. Pouhá přítomnost nainstalovaného modulu v systému nezaručuje jeho načtení do jádra při spuštění. S tím jsme se setkali, když jsme při spuštění kontejneru s NAT na novém hostu obdrželi tuto chybu:
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 byl vyřešen po přidání inicializace do role Ansible pomocí modulu modprobe a načtení při startu OS pomocí lineinfile:
- name: Přidat modul ip6table_nat
modprobe:
name: ip6table_nat
state: present
- name: Přidat ip6table_nat do boot
lineinfile:
path: /etc/modules
line: 'ip6table_nat'Mimochodem, na Habr je dobrý , který stručně a jasně popisuje výhody a nevýhody různých metod pro práci s ipv6 v dockeru.
Ale vraťme se k naší otázce, kterou jsme položili na začátku:
Proč je dirigent potřebný, i když orchestr umí hrát sám?
Teď už si všichni představují, jak hrát v našem týmu:
- proces „nalévání“ serverů je vytvořen,
- vývoj a nasazení služeb je unified.
Vzniká opodstatněná otázka — jak efektivně a maximálně automatizovaně nasazovat, aktualizovat, monitorovat naše služby v docker kontejnerech?
I když každý člen orchestru zná svou partii, může se splést, odstoupit od původní myšlenky. Zde se dostáváme k tomu, že bez dirigenta náš orchestr nebude efektivně zkoušet a hrát v synchronizaci. Dirigent odpovídá za všechny parametry provedení, za to, aby vše bylo spojeno jednotným tempem a náladou.
Jak s minimálními náklady získat dobrého dirigenta?
Téma orchestrace je na trhu dostatečně rozvinuté. Ale nejprve si promluvíme o pomocných nástrojích, které mohou dirigentovi pomoci.
— systém, který poskytuje dvě hlavní funkce:
- objevování služeb (service discovery),
- distribuované úložiště klíč-hodnota.
V našem orchestru bude Consul odpovědný za registraci služeb a ukládání jejich konfigurací. Existují dvě možnosti registrace:
- Aktivní — to je, když se služba registruje sama pomocí HTTP API;
- Pasivní — službu je nutné zapsat ručně.
Vault — je úložiště, které standardizuje a unifikuje bezpečné uchovávání a práci s tajemstvími — hesla, certifikáty.
Zde jsou výhody, které získáme používáním tohoto nástroje:
- Jednotné centrum pro vytváření a uchovávání tajemství, správa jejich životního cyklu prostřednictvím HTTP API.
- Transit Secrets Engine — šifrování-dešifrování dat bez jejich uchovávání. Možnost přenosu dat zašifrovaně po nezabezpečených komunikačních kanálech.
- Politiky přístupu, které lze pohodlně nastavit.
- Audit přístupu k tajemstvím.
- Možnost vytvoření vlastní CA (Certifikační autority) pro správu vlastních podepsaných certifikátů uvnitř vlastní infrastruktury.
Celkově odpovídají dvě varianty — Kubernetes a Nomad — našim požadavkům na roli dirigenta.
Kubernetes
Kolik článků a knih o něm již bylo napsáno (tady , například), bylo řečeno ve zprávách, že napíšu stručně — je to univerzální kombajn, který umí prakticky vše. Cena za to — ne vždy jednoduché nastavení a podpora klastru na Kubernetes.
Nomad
od HashiCorp, společnosti známé zmiňovanými consul a vault.
Nomad nám přišel dost jednoduchý na instalaci a nastavení, ve srovnání s Kubernetes. Jeden binární soubor funguje jak v režimu serveru, tak klienta. Nomad pokrývá celý seznam úloh, které chceme, aby vyřešil: správa klastru, rychlý plánovač, podpora pro multidatacentra. Navíc použitím consul a vault získáváme těsnější integraci pro orchestrace našich služeb.
Co se nyní připravuje:
- připravili jsme servery pro nasazení Consul,
- konfigurace clustru nomad bude zanesena do Consul, prostřednictvím které by měl být nomad nasazen automaticky,
- současně budeme instalovat vault pro uchovávání tajemství.
Otázka do diskuze — má smysl mít dirigenta pro takové úkoly, nebo je orchestrace bez něj v pořádku? Napište v komentářích, co si o tom myslíte.
Přihlaste se k našemu blogu a zůstaňte v obraze — brzy vám řekneme, co se nakonec stalo, a jestli jsme nastavili klastr nomad tak, jak jsme chtěli.
Navštivte náš útulný , kde vždy můžete požádat o radu, pomoci kolegům a prostě si popovídat o výzkumu výkonu a nejen o tom.
Zdroj: habr.com
