Blíží se Nový rok. Děti po celé zemi již poslaly dopisy Dědu Mrázovi nebo si přály dárky, a hlavní vykonavatel jejich přání – jeden z velkých maloobchodníků – se připravoval na vrchol prodeje. V prosinci zatížení jeho datového centra vzrůstá několikanásobně. Proto se společnost rozhodla modernizovat datové centrum a zavést do provozu několik desítek nových serverů místo vybavení, jehož životnost končila. Na tomto pozadí se příběh s padajícími sněhovými vločkami končí a začíná thriller.
Vybavení dorazilo na místo několik měsíců před vrcholem prodeje. Provozní služba samozřejmě ví, jak a co nastavit na serverech, aby je uvedla do produkčního prostředí. Ale potřebovali jsme tento proces automatizovat a vyloučit lidský faktor. Kromě toho byly servery nahrazovány před migrací souboru systémů SAP, které byly pro společnost kriticky důležité.
Zahájení provozu nových serverů bylo pevně spojeno s termínem. A posunout ho by znamenalo ohrozit dodávky miliardy dárků a migraci systémů. Datum by ani tým složený z Děda Mráze a Sisyphusa nezměnil – migraci systému SAP pro řízení skladu lze provést pouze jednou ročně. Od 31. prosince do 1. ledna obrovské sklady maloobchodníka, které mají dohromady rozlohu 20 fotbalových hřišť, zastavují činnost na 15 hodin. A to je jediný časový úsek pro přestěhování systému. Neměli jsme žádný prostor pro chyby při uvedení serverů.
Hned uvedu na pravou míru: můj příběh odráží nástroje a procesy správy konfigurací, které používá náš tým.
Komplex správy konfigurací sestává z několika úrovní. Klíčovou součástí je systém CMS. Při průmyslovém provozu by absence jedné z úrovní nevyhnutelně vedla k nepříjemným zázrakům.
Správa instalace OS
První úroveň představuje systém řízení instalace operačních systémů na fyzické a virtuální servery. Vytváří základní konfigurace OS a zbavuje nás lidského faktoru.
S pomocí tohoto systému jsme získávali standardizované a pro další automatizaci použitelné instance serverů s operačním systémem. Při "rozšiřování" dostávaly minimální sadu místních uživatelů a veřejných klíčů SSH a také sjednocenou konfiguraci OS. Měli jsme zaručenou kontrolu serverů prostřednictvím CMS a byli jsme si jisti, že níže, na úrovni OS, nejsou žádná překvapení.
Úkol "maximálně" pro systém správy instalace — automaticky nastavovat servery od úrovně BIOS/Firmware až po OS. Mnohé zde závisí na hardwaru a úkolu nastavení. Pro heterogenní hardware lze zvážit . Pokud veškeré „železo“ pochází od jednoho dodavatele, je často pohodlnější použít hotové prostředky správy (například HP ILO Amplifier, DELL OpenManage atd.).
Pro instalaci OS na fyzických serverech jsme používali všem dobře známý Cobbler, ve kterém je definován soubor sjednocených profilů instalace s provozní službou. Při přidávání nového serveru do infrastruktury inženýr přiřadil MAC adresu serveru požadovanému profilu v Cobbler. Při prvním spuštění přes síť server získal dočasnou adresu a nový OS. Poté byl převeden do cílové VLAN/IP adresace a práce pokračovala tam. Ano, změna VLAN zabere čas a vyžaduje schválení, ale poskytuje další ochranu proti náhodné instalaci serveru ve výrobním prostředí.
Virtuální servery jsme vytvářeli na základě šablon připravených pomocí HashiCorp Packer. Důvod byl stejný: aby se předešlo možným lidským chybám při instalaci OS. Na rozdíl od fyzických serverů však Packer umožňuje nevyužívat PXE, síťové zavádění a změnu VLAN. To usnadnilo a zjednodušilo vytváření virtuálních serverů.
Obr. 1. Řízení instalace operačních systémů.
Správa tajemství
Každý systém správy konfigurací obsahuje data, která by měla být skryta před běžnými uživateli, ale jsou potřebná pro přípravu systémů. Jsou to hesla místních uživatelů a servisních účtů, klíče certifikátů, různé API tokeny atd. Obvykle se jim říká "tajemství".
Pokud od samého začátku nevymezíte, kde a jak tyto tajemství uchovávat, mohou se v závislosti na přísnosti požadavků na informační bezpečnost objevit takové způsoby uchovávání:
- přímo v kódu správy konfigurace nebo v souborech v repozitáři;
- ve specializovaných nástrojích pro správu konfigurací (např. Ansible Vault);
- v CI/CD systémech (Jenkins/TeamCity/GitLab/atd.) nebo v systémech správy konfigurací (Ansible Tower/Ansible AWX);
- také mohou být tajemství předávána „ručním způsobem“. Například jsou umístěna na předem dohodnuté místo a poté jsou používána systémy správy konfigurací;
- různé kombinace výše popsaného.
Každá metoda má své nedostatky. Hlavní z nich je absence politik přístupu k tajemstvím: nelze nebo je obtížné určit, kdo může používat ta nebo ta tajemství. Dalším mínusem je absence auditu přístupů a plnohodnotného životního cyklu. Jak rychle nahradit například veřejný klíč, který je zapsán v kódu a v několika souvisejících systémech?
Používali jsme centralizované úložiště tajemství HashiCorp Vault. To nám umožnilo:
- bezpečně uchovávat tajemství. Jsou šifrována, a i kdyby se někdo dostal k databázi úložiště Vault (např. obnovením z zálohy), tak nebude schopný přečíst tam uložená tajemství;
- organizovat politiky přístupu k tajemstvím. Uživatelům a aplikacím jsou přístupná pouze „přidělená“ tajemství;
- provádět audit přístupu k tajemstvím. Jakékoli akce s tajemstvími jsou zaznamenávány v auditorském protokolu Vault;
- organizovat plnohodnotný „životní cyklus“ práce s tajemstvími. Mohou být vytvářena, odvolávána, nastavovány jejich platnosti atd.
- snadno se integrovat s jinými systémy, které potřebují přístup k tajemství;
- a také aplikovat end-to-end šifrování, jednorázová hesla pro OS a DB, certifikáty autorizovaných center atd.
Nyní přejdeme k centrálnímu systému autentizace a autorizace. Mohli bychom se obejít i bez něj, ale správa uživatelů ve spoustě souvisejících systémů je příliš složitá. Nastavili jsme autentizaci a autorizaci prostřednictvím služby LDAP. Jinak bychom v tom samém Vault museli neustále vydávat a sledovat autentizační tokeny pro uživatele. A odstraňování a přidávání uživatelů by se proměnilo v úkol „udělal/a jsem to všude, kde jsem měl/a vytvořit/odstranit tuto identitu?“
Přidáváme ještě jednu úroveň do našeho systému: správu tajemství a centrální autentizaci/autorizaci:
Obr. 2. Správa tajemství.
Správa konfigurací
Dostali jsme se do jádra — do systému CMS. V našem případě se jedná o kombinaci Ansible a Red Hat Ansible AWX.
Místo Ansible může být použit Chef, Puppet, SaltStack. Zvolili jsme Ansible z několika důvodů.
- Za prvé, jeho univerzálnost. Sada hotových modulů pro správu . A pokud něco chybí, lze to najít na GitHubu a Galaxy.
- Za druhé, není třeba instalovat a udržovat agenty na spravovaném zařízení, dokazovat, že neovlivňují zátěž, a potvrzovat nepřítomnost "zadních vrátek".
- Za třetí, Ansible má nízkou bariéru vstupu. Kvalifikovaný inženýr napíše funkční playbook doslova první den práce s produktem.
Ale samotný Ansible v průmyslovém prostředí nám nestačil. Jinak by vzniklo mnoho problémů s omezením přístupu a auditem činností administrátorů. Jak rozdělit přístup? Přeci bylo potřeba, aby každé oddělení spravovalo (čti — spouštělo Ansible playbook) "svou" skupinu serverů. Jak povolit spuštění konkrétních Ansible playbook pouze určitém zaměstnancům? Nebo jak sledovat, kdo spouštěl playbook, aniž bychom zakládali množství lokálních uživatelských účtů na serverech a zařízeních spravovaných Ansible?
Většinu takových otázek vyřeší Red Hat , nebo jeho open-source upstream projekt . Proto jsme ho pro zákazníka zvolili.
A ještě jeden prvek do obrazu našeho CMS systému. Ansible playbook by měl být uložen v systémech pro správu kódu. U nás je to .
Takže samotné konfigurace řídí kombinace Ansible/Ansible AWX/GitLab (viz Obr. 3). Samozřejmě, AWX/GitLab jsou integrovány do jediné autentifikační sítě, a Ansible playbook je propojen s HashiCorp Vault. Konfigurace se dostávají do produkčního prostředí pouze přes Ansible AWX, ve kterém jsou stanovena všechna "pravidla hry": kdo a co může konfigurovat, odkud brát kód pro správu konfigurací pro CMS atd.
Obr. 3. Správa konfigurací.
Správa testování
Naše konfigurace je prezentována formou kódu. Proto se musíme řídit stejnými pravidly jako vývojáři softwaru. Bylo nezbytné zorganizovat procesy vývoje, nepřetržitého testování, dodávání a aplikace konfiguračního kódu na produkční servery.
Pokud to neuděláme hned, nastavené role pro konfiguraci buď přestanou být podporovány a měněny, nebo se přestanou spouštět v produkci. V léčbě této bolesti je známé řešení, které se osvědčilo v tomto projektu:
- každá role je pokryta modulovými testy;
- testy se automaticky spouští při jakékoli změně v kódu, který ovládá konfigurace;
- změny v kódu spravujícím konfigurace se dostanou do produkčního prostředí pouze po úspěšném dokončení všech testů a code review.
Vývoj kódu a správa konfigurací se staly klidnějšími a předvídatelnějšími. Pro organizaci nepřetržitého testování jsme použili nástroj GitLab CI/CD a jako rámec pro organizaci testů jsme vzali .
Při jakékoli změně v kódu spravujícím konfigurace GitLab CI/CD vyvolává Molecule:
- ta kontroluje syntaxi kódu,
- zvedá Docker kontejner,
- aplikuje upravený kód do vytvořeného kontejneru,
- provádí kontrolu role na idempotentnost a spouští testy pro tento kód (granularita je zde na úrovni ansible role, viz Obr. 4).
Konfigurace do produkčního prostředí jsme dodávali pomocí Ansible AWX. Odpovědní inženýři za provoz aplikovali změny v konfiguraci prostřednictvím předem definovaných šablon. AWX při každém nasazení „dotazoval“ poslední verzi kódu z master větve GitLab. Tak jsme vyloučili použití neověřeného nebo zastaralého kódu v produkčním prostředí. Přirozeně, kód se na master větev dostal pouze po testování, revizi a schválení.
Obr. 4. Automatizované testování rolí v GitLab CI/CD.
Je zde ještě problém spojený s provozováním produkčních systémů. V reálném životě je velmi obtížné provádět změny v konfiguraci pouze prostřednictvím kódu CMS. Dochází k mimořádným situacím, kdy inženýr musí změnit konfiguraci „hned a teď“, aniž by čekal na úpravu kódu, testování, schválení atd.
V důsledku ručních změn vznikají nesrovnalosti v konfiguraci na identickém zařízení (například u uzlů HA klastru různá konfigurace nastavení sysctl). Nebo skutečná konfigurace na zařízení se liší od té, která je definována v kódu CMS.
Proto v rámci kontinuálního testování kontrolujeme produkční prostředí na nesrovnalosti v konfiguracích. Zvolili jsme nejjednodušší možnost: spuštění kódu konfigurace CMS v režimu „dry run“, tedy bez aplikace změn, ale s oznámením o všech nesrovnalostech mezi plánovanou a skutečnou konfigurací. To jsme realizovali pomocí periodických spuštění všech Ansible playbook s volbou „—check“ na produkčních serverech. Za spuštění a aktuálnost playbooků opět zodpovídá Ansible AWX (viz Obr. 5):
Obr. 5. Kontroly nesrovnalostí v konfiguracích v Ansible AWX.
Po kontrolách AWX posílá zprávu o nesrovnalostech administrátorům. Ti zkoumají problematickou konfiguraci a poté ji opravují pomocí upravených playbooků. Tímto způsobem udržujeme konfiguraci v produkčním prostředí a CMS je vždy v aktuálním a synchronizovaném stavu. To eliminuje nepříjemná „zázraky“, když se kód CMS aplikuje na „živých“ serverech.
Nyní máme důležitou úroveň testování, skládající se z Ansible AWX/GitLab/Molecule (Obr. 6).
Obr. 6. Řízení testováním.
Složité? Nesouhlasím. Ale takový komplex řízení konfigurací se stal vyčerpávající odpovědí na řadu otázek spojených s automatizací nastavení serverů. Nyní má retailer na standardních serverech vždy přesně definovanou konfiguraci. CMS, na rozdíl od inženýra, nezapomene přidat potřebná nastavení, vytvořit uživatele a provést desítky nebo stovky požadovaných konfigurací.
V nastaveních serverů a prostředí dnes chybějí „tajné znalosti“. Všechny potřebné vlastnosti jsou vyjádřeny v playbooku. Žádná další kreativita a vágní pokyny: „nasaď jako běžný Oracle, ale je potřeba pár nastavení sysctl napsat a přidat uživatele se správným UID. Zeptej se kluků z provozu, ti to vědí.».
Možnost odhalit nesrovnalosti v konfiguracích a předem je opravit přináší klid. Bez systému pro řízení konfigurací to obvykle vypadá jinak. Problémy se hromadí, dokud jednoho dne „nevybuchnou“ v produkci. Poté probíhá analýza a kontrola konfigurací a opravy. A cyklus se opakuje znovu.
A samozřejmě jsme urychlili spuštění serverů do provozu z několika dnů na hodiny.
A na samotný novoroční večer, když děti radostně rozbalovaly dárky a dospělí si přáli pod údery hodin, naše inženýry migrovali SAP systém na nové servery. I Děda Mráz by řekl, že nejlepší zázraky jsou dobře připravené.
P.S. Náš tým se často setkává s tím, že objednavatelé chtějí co nejjednodušeji vyřešit problém správy konfigurací. Ideálně tak, aby to vypadalo jako mávnutím kouzelného proutku — jedním nástrojem. Ale v životě je to složitější (ano, znovu nepřivezli stříbrné kule): musíme vytvořit celý proces pomocí nástrojů, které jsou pro tým objednavatele pohodlné.
Autor: Sergej Artemov, architekt oddělení Ingosystemy Jet
Zdroj: habr.com
