Těžko by bylo špatné říci, že nejlepší z mužů
najít radost skrze utrpení.
Ludwig van Beethoven
Jmenuji se Sergey a pracuji ve společnosti Yandex.Money v týmu pro výzkum výkonu. 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 brali v úvahu. Veškeré dění z článku se odehrává v reálném čase, takže vývoj situace, milí čtenáři, sledujete téměř v přímém přenosu.
Proč potřebujeme v našem týmu dirigenta?
Kdo je dirigent? Od fr. diriger - řídit, řídit, vést - ve světě hudby - to je člověk, který je vedoucím učení a provádění souborové hudby. V našem případě je toto místo obsazeno orchestračními a automatizačními systémy.
Jejich role se neliší od role dirigenta v hudbě – jsou potřeba k tomu, aby pomáhali týmu, řídili a organizovali jeho hru.
Tým má zpravidla určitý soubor kapacit – říkejme jim servery – na kterých realizuje své projekty.
Přístup k získávání a provozování těchto serverů je různý. Několik příkladů:
- Tým vznese požadavek například na provozní skupinu, aby jim poskytla prostředky s určitými parametry.
- Operační tým jim poskytne požadované množství – cloud nebo holý kov – a zavazuje se je udržovat v řádném stavu podle SLA. Nastavení provádí také operační tým.
- Tým obdrží od provozní skupiny pouze cloudové nebo holé kovové zdroje a nakonfiguruje je sám.
- Tým sám „nakupuje“ zdroje a udržuje/nastavuje je zcela samostatně.
Náš tým používá servery, které je potřeba podporovat – aktualizace OS, instalace nových balíčků atd.
Pro sebe jsme je rozdělili do dvou hlavních typů:
- tanková skupina,
- servisní skupina.
Skupina tanků se skládá z hostitelů s Yandex.Tank.
Skupina služeb zahrnuje vše, co souvisí s údržbou – jedná se o různé služby pro podporu cyklu vydání, generování automatických reportů atd.
V jednu chvíli začalo být toto vše nepohodlné spravovat ručně a my jsme přemýšleli o automatizaci celého procesu, počínaje „načtením“ serverů a konče vývojem, vydáním a spuštěním naší interní služby.
Proč je potřeba dirigent, i když může hrát orchestr sám?
Pro začátek jsme si osvojili Ansible a začali „nalévat“ naše holé servery, abychom byli méně závislí na správcích systému – zde vyhrává každý, získáváme nové dovednosti a ulehčujeme správcům část práce, které mají bez nás vždy dost . Snažíme se co nejvíce rozvíjet nad rámec naší specializace a týmové autonomie.
Ve firmě je práce s Ansible poměrně dlouho konfigurována a regulována, takže jsme naše řešení snadno integrovali do tohoto procesu.
V současné době se hostitelský fond skládá ze tří rolí Ansible:
- první role nainstaluje OS,
- druhý spouští základní nastavení pro hostitele, autorizaci LDAP, např.
- a třetí nainstaluje Yandex.Tank a související závislosti do kontejneru dockeru.
Přejděme ke službám, které v rámci týmu využíváme.
Pro naše úkoly používáme rovnoměrně Kotlin a Python a trochu více Golang. Abychom sjednotili vývoj a nasazení našich služeb, rozhodli jsme se je zabalit do kontejnerů Docker. To vám dává svobodu volby programovacího jazyka a zároveň reguluje jednotný formát doručení pro vaši aplikaci.
Malá poznámka o ipv6 v Dockeru
Některé ze služeb, se kterými komunikujeme, jsou dostupné pouze prostřednictvím ipv6, takže jsme museli přijít na to, jak vytvořit ipv6 pro kontejnery.
Podle dokumentace ipv6 na oficiálních stránkách Dockeru je ipv6 povoleno přidáním parametrů do daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}V tomto případě musí poskytovatel vydat podsíť ipv6, do které se zaregistrujete fixed-cidr-v6.
Zvolili jsme však jinou možnost - ipv6 NAT, a zde je důvod:
- Nyní docker pouze s ipv6.
- Mít globálně směrovatelnou adresu v každém kontejneru znamená, že všechny porty (i nepublikované) jsou přístupné všem, pokud není provedeno dodatečné filtrování.
- userland proxy pro publikování portů, .
ipv6 NAT je , který sám spravuje pravidla v ip6tables a upravuje je při přidávání nového kontejneru.
Aby toto řešení správně fungovalo, bylo nutné provést řadu dalších manipulací. Nezapomeňte inicializovat ip6table_nat v systému. Přítomnost modulu nainstalovaného v systému nezaručuje, že modul bude načten do jádra při spuštění. Narazili jsme na to, když jsme obdrželi tuto chybu při spuštění kontejneru s NAT na novém hostiteli:
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: Add ip6table_nat module
modprobe:
name: ip6table_nat
state: present
- name: Add ip6table_nat to boot
lineinfile:
path: /etc/modules
line: 'ip6table_nat'Mimochodem, na náboji je jeden dobrý , který stručně a jasně popisuje výhody a nevýhody té či oné metody pro spouštění ipv6 v dockeru.
Ale vraťme se k naší otázce položené na začátku:
Proč je potřeba dirigent, i když může hrát orchestr sám?
Nyní si každý představí, jak hrát v našem týmu:
- byl vytvořen proces „nalévání“ serverů,
- vývoj a nasazení služeb jsou jednotné.
Nabízí se rozumná otázka – jak efektivně a co nejautomaticky nasazovat, aktualizovat a ovládat naše služby v kontejnerech Docker?
Přestože každý člen orchestru zná svůj part, může se splést a odchýlit se od původní myšlenky. Zde docházíme k závěru, že bez dirigenta nebude náš orchestr efektivně zkoušet a hrát souvisle. Dirigent zodpovídá za všechny parametry představení a zajišťuje, že vše spojuje jediné tempo a nálada.
Jak získat dobrého dirigenta s minimálními investicemi?
Téma orchestrace je na trhu docela dobře rozvinuté. Nejprve si ale povíme něco o pomocných nástrojích, které mohou dirigentovi pomoci.
- systém, který poskytuje dvě hlavní funkce:
- vyhledávání služeb,
- distribuované úložiště párů klíč–hodnota.
V našem orchestru bude Consul zodpovědný za registraci služeb a ukládání jejich konfigurací. Existují dvě možnosti registrace:
- Aktivní je, když se služba zaregistruje pomocí HTTP API;
- Pasivní – službu je nutné zaregistrovat ručně.
Vault je úložiště, které standardizuje a sjednocuje bezpečné ukládání a nakládání s tajemstvími – hesly, certifikáty.
Zde jsou výhody, které získáme používáním tohoto nástroje:
- Jediné centrum pro vytváření a ukládání tajemství a správu jejich životního cyklu pomocí HTTP API.
- Transit Secrets Engine – šifrování a dešifrování dat bez jejich uložení. Schopnost přenášet data v šifrované podobě přes nezabezpečené komunikační kanály.
- Přístupové zásady, které lze snadno konfigurovat.
- Audit přístupu k tajemství.
- Možnost vytvořit si vlastní certifikační autoritu (CA) pro správu certifikátů s vlastním podpisem v rámci vaší infrastruktury.
Vzhledem ke všem našim požadavkům byly pro roli dirigenta vhodné dvě varianty - Kubernetes a Nomad.
Kubernetes
Kolik článků a knih už o něm bylo napsáno (zde ), jsou zprávy, které napíšu stručně - jedná se o univerzální kombajn, který umí téměř vše. Cenou za to je, že nastavení a údržba clusteru na Kubernetes není vždy jednoduchá.
Nomád
od HashiCorp, společnosti známé výše zmíněným konzulem a trezorem.
Zjistili jsme, že Nomad se instaluje a konfiguruje docela jednodušeji než Kubernetes. Jeden binární soubor funguje v režimu serveru i klienta. Nomad zároveň pokrývá celý seznam úkolů, které chceme, aby řešil: správa clusteru, rychlý plánovač, podpora multidatacenter. Navíc při použití konzula a trezoru získáme těsnější integraci pro orchestraci našich služeb.
Co aktuálně probíhá:
- připravené servery pro nasazení Consul,
- konfigurace nomádského clusteru bude zadána do Consul, s pomocí kterého by měl být nomád nasazen automaticky,
- Paralelně nainstalujeme trezor pro ukládání tajemství.
Otázka pro publikum: vyplatí se najímat na takové úkoly dirigenta nebo se orchestru daří i bez něj? Napište nám do komentářů, co si o tom myslíte.
Přihlaste se k odběru našeho blogu a zůstaňte v kontaktu – brzy vám řekneme, co se nakonec stalo a zda jsme nomádský cluster nakonfigurovali tak, jak jsme chtěli.
Přijďte do naší útulny , kde můžete vždy požádat o radu, pomoci kolegům a jen si popovídat o výzkumu produktivity a dalších.
Zdroj: www.habr.com
