Sotva by bolo nesprávne povedať, že najlepší z mužov
nájsť radosť cez utrpenie.
Ludwig van Beethoven

Volám sa Sergey a pracujem v Yandex.Money v tíme pre výskum výkonnosti. Chcem vám povedať začiatok príbehu o našej ceste k využívaniu orchestrácie – ako sme si vyberali nástroje a čo sme brali do úvahy. Všetky udalosti z článku sa odohrávajú v reálnom čase, takže vývoj situácie, milí čitatelia, sledujete takmer v priamom prenose.
Prečo potrebujeme v našom tíme dirigenta?
Kto je dirigent? Od fr. diriger - riadiť, riadiť, viesť - vo svete hudby - to je človek, ktorý je vedúcim učenia a predvádzania súbornej hudby. V našom prípade je toto miesto obsadené orchestračnými a automatizačnými systémami.
Ich úloha sa nelíši od úlohy dirigenta v hudbe – sú potrební, aby pomáhali tímu, usmerňovali a organizovali jeho hru.
Tím má spravidla určitý súbor kapacít – nazvime ich servery – na ktorých realizuje svoje projekty.
Prístup k získaniu a prevádzke týchto serverov je rôzny. Niekoľko príkladov:
- Tím požiada napríklad operačnú skupinu, aby im poskytla zdroje s určitými parametrami.
- Operačný tím im poskytne požadované množstvo – oblak alebo holý kov – a zaviaže sa ich udržiavať v riadnom stave podľa SLA. Nastavenie vykonáva aj operačný tím.
- Tím dostáva od operačnej skupiny iba cloudové alebo holé kovové zdroje a konfiguruje si ich sám.
- Tím sám „nakupuje“ zdroje a udržiava/nastavuje ich úplne samostatne.
Náš tím používa servery, ktoré je potrebné podporovať – aktualizácia OS, inštalácia nových balíkov atď.
Pre seba sme ich rozdelili do dvoch hlavných typov:
- tanková skupina,
- servisná skupina.
Skupina tankov pozostáva z hostiteľov s Yandex.Tank.
Skupina služieb zahŕňa všetko, čo súvisí s údržbou - sú to rôzne služby na poskytovanie podpory pre cyklus vydania, generovanie automatických správ atď.
V jednom momente sa toto všetko stalo nepohodlným spravovať manuálne a uvažovali sme o automatizácii celého procesu, počnúc „načítaním“ serverov a končiac vývojom, vydaním a spustením našej internej služby.
Prečo je potrebný dirigent, aj keď orchester sám môže hrať?
Na začiatok sme si osvojili Ansible a začali „nalievať“ naše holé metalové servery, aby sme boli menej závislí od systémových administrátorov – tu vyhráva každý, získavame nové zručnosti a odbremeňujeme administrátorov od práce, ktorej majú bez nás vždy dosť. . Snažíme sa čo najviac rozvíjať nad rámec našej špecializácie a tímovej autonómie.
Vo firme je práca s Ansible pomerne dlho nakonfigurovaná a regulovaná, takže sme naše riešenie jednoducho integrovali do tohto procesu.
V súčasnosti sa hostiteľský fond skladá z troch rolí Ansible:
- prvá rola nainštaluje OS,
- druhý spúšťa základné nastavenia pre hostiteľa, autorizáciu LDAP, napr.
- a tretí nainštaluje Yandex.Tank a súvisiace závislosti do kontajnera dokovacieho zariadenia.
Prejdime k službám, ktoré v rámci tímu využívame.
Pre naše úlohy používame rovnako Kotlin a Python a trochu viac Golang. Aby sme zjednotili vývoj a nasadenie našich služieb, rozhodli sme sa ich zabaliť do kontajnerov Docker. To vám dáva slobodu výberu programovacieho jazyka a zároveň reguluje jednotný formát doručenia pre vašu aplikáciu.
Malá poznámka o ipv6 v Dockeri
Niektoré zo služieb, s ktorými komunikujeme, sú dostupné iba cez ipv6, takže sme museli prísť na to, ako vytvoriť ipv6 pre kontajnery.
Podľa dokumentácie ipv6 na oficiálnej webovej stránke Docker je ipv6 povolený pridaním parametrov do súboru daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}V tomto prípade musí poskytovateľ vydať podsieť ipv6, do ktorej sa zaregistrujete fixed-cidr-v6.
Vybrali sme si však inú možnosť - ipv6 NAT, a tu je dôvod:
- Teraz docker len s ipv6.
- Mať globálne smerovateľnú adresu v každom kontajneri znamená, že všetky porty (aj tie nepublikované) sú prístupné každému, pokiaľ sa nevykoná dodatočné filtrovanie.
- userland proxy pre publikovanie portov, .
ipv6 NAT je , ktorý sám spravuje pravidlá v ip6tables a upravuje ich pri pridávaní nového kontajnera.
Aby toto riešenie fungovalo správne, bolo potrebné vykonať množstvo ďalších manipulácií. Nezabudnite inicializovať ip6table_nat v systéme. Prítomnosť modulu nainštalovaného v systéme nezaručuje, že modul bude načítaný do jadra pri štarte. Stretli sme sa s tým, keď sme dostali túto chybu pri spustení kontajnera s NAT na novom hostiteľovi:
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 vyriešený po pridaní inicializácie do role Ansible pomocou modulu modprobe a jej načítaní 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 náboji je jeden dobrý , ktorý stručne a jasne popisuje výhody a nevýhody jednej alebo druhej metódy na spustenie ipv6 v dockeri.
Ale vráťme sa k otázke položenej na začiatku:
Prečo je potrebný dirigent, aj keď orchester sám môže hrať?
Teraz si každý predstavuje, ako hrať v našom tíme:
- bol vytvorený proces „nalievania“ serverov,
- vývoj a nasadenie služieb sú jednotné.
Vzniká rozumná otázka: ako efektívne a čo najautomaticky nasadiť, aktualizovať a ovládať naše služby v kontajneroch Docker?
Napriek tomu, že každý člen orchestra pozná svoj part, môže sa zmiasť a odkloniť sa od pôvodnej myšlienky. Tu prichádzame k záveru, že bez dirigenta nebude náš orchester efektívne cvičiť a hrať súvisle. Dirigent je zodpovedný za všetky parametre predstavenia a zabezpečuje, že všetko spája jednotné tempo a nálada.
Ako získať dobrého dirigenta s minimálnou investíciou?
Téma orchestrácie je na trhu celkom dobre rozvinutá. Najprv si však povedzme o pomocných nástrojoch, ktoré môžu pomôcť dirigentovi.
- systém, ktorý poskytuje dve hlavné funkcie:
- objavenie služby,
- distribuované úložisko párov kľúč – hodnota.
V našom orchestri bude konzul zodpovedný za registráciu služieb a ukladanie ich konfigurácií. Existujú dve možnosti registrácie:
- Aktívna je, keď sa služba zaregistruje pomocou HTTP API;
- Pasívne – službu je potrebné zaregistrovať manuálne.
Trezor je úložisko, ktoré štandardizuje a zjednocuje bezpečné ukladanie a manipuláciu s tajomstvami – heslá, certifikáty.
Tu sú výhody, ktoré získame používaním tohto nástroja:
- Jediné centrum na vytváranie a ukladanie tajomstiev a správu ich životného cyklu pomocou HTTP API.
- Transit Secrets Engine - šifrovanie a dešifrovanie údajov bez ich uloženia. Schopnosť prenášať dáta v šifrovanej forme cez nezabezpečené komunikačné kanály.
- Prístupové politiky, ktoré sa ľahko konfigurujú.
- Audit prístupu k tajomstvám.
- Schopnosť vytvoriť si vlastnú certifikačnú autoritu (CA) na správu certifikátov s vlastným podpisom v rámci vašej infraštruktúry.
Vzhľadom na všetky naše požiadavky boli pre rolu dirigenta vhodné dve možnosti - Kubernetes a Nomad.
Kubernetes
Koľko článkov a kníh už o ňom bolo napísaných (tu ), sú správy, ktoré napíšem stručne - ide o univerzálny kombajn, ktorý dokáže takmer všetko. Cenou za to je, že nastavenie a udržiavanie klastra na Kubernetes nie je vždy jednoduché.
nomád
od spoločnosti HashiCorp, ktorá je známa vyššie uvedeným konzulom a trezorom.
Zistili sme, že Nomad sa inštaluje a konfiguruje oveľa jednoduchšie ako Kubernetes. Jeden binárny súbor funguje v serverovom aj klientskom režime. Nomad zároveň pokrýva celý zoznam úloh, ktoré chceme, aby riešil: správa klastrov, rýchly plánovač, podpora multidátových centier. Navyše, keď použijeme konzul a trezor, získame užšiu integráciu pre organizáciu našich služieb.
Čo momentálne prebieha:
- pripravené servery na nasadenie Consul,
- konfigurácia klastra nomádov bude zadaná do Consul, pomocou ktorej by sa mal nomád nasadiť automaticky,
- Paralelne nainštalujeme trezor na ukladanie tajomstiev.
Otázka pre divákov: oplatí sa angažovať dirigenta na takéto úlohy alebo sa orchestru darí aj bez neho? Napíšte nám do komentárov, čo si o tom myslíte.
Prihláste sa na odber nášho blogu a buďte v kontakte – čoskoro vám povieme, čo sa nakoniec stalo a či sme nomádsky klaster nakonfigurovali tak, ako sme chceli.
Príďte do našej útulne , kde môžete vždy požiadať o radu, pomôcť kolegom a len tak sa porozprávať o výskume produktivity a ďalších.
Zdroj: hab.com
