Blížil se Nový rok. Děti po celé zemi už posílaly dopisy Ježíškovi nebo si vyrobily dárky pro sebe a jejich hlavní vykonavatel, jeden z velkých maloobchodníků, se připravoval na apoteózu výprodejů. V prosinci se zatížení jeho datového centra několikrát zvýší. Proto se společnost rozhodla zmodernizovat datové centrum a místo dosluhujícího zařízení zprovoznit několik desítek nových serverů. Tím příběh na pozadí vířících sněhových vloček končí a thriller začíná.

Zařízení dorazilo na místo několik měsíců před vrcholem prodeje. Provozní služba samozřejmě ví, jak a co nakonfigurovat na serverech, aby je uvedla do produkčního prostředí. Potřebovali jsme to ale zautomatizovat a eliminovat lidský faktor. Kromě toho byly servery vyměněny před migrací sady systémů SAP, které byly pro společnost kritické.

Zprovoznění nových serverů bylo přísně vázáno na termín. A přesunout to znamenalo ohrozit jak zásilku miliardy dárků, tak migraci systémů. Termín nemohl změnit ani tým složený z Otce Frosta a Santa Clause – systém SAP pro skladové hospodářství můžete převést pouze jednou ročně. Od 31. prosince do 1. ledna přestanou fungovat na 20 hodin obrovské sklady maloobchodníka o celkové velikosti 15 fotbalových hřišť. A to je jediná doba pro přesun systému. Při zavádění serverů jsme neměli prostor pro chyby.

Dovolte mi, abych byl jasný: můj příběh odráží nástroje a proces správy konfigurace, které náš tým používá.

Komplex správy konfigurace se skládá z několika úrovní. Klíčovou součástí je CMS systém. V průmyslovém provozu by absence jedné z úrovní nevyhnutelně vedla k nepříjemným zázrakům.

Správa instalace OS

První úrovní je systém pro správu instalace operačních systémů na fyzické a virtuální servery. Vytváří základní konfigurace OS, eliminuje lidský faktor.

Pomocí tohoto systému jsme obdrželi standardní serverové instance s OS vhodnými pro další automatizaci. Během „nalévání“ obdrželi minimální sadu místních uživatelů a veřejných klíčů SSH a také konzistentní konfiguraci OS. Mohli jsme zaručit správu serverů prostřednictvím CMS a byli jsme si jisti, že „dole“ na úrovni OS nás žádná překvapení nečekají.

„Maximálním“ úkolem systému správy instalace je automatická konfigurace serverů od úrovně BIOS/Firmware až po OS. Zde hodně záleží na vybavení a úlohách nastavení. U heterogenních zařízení můžete zvážit REDFISH API. Pokud je veškerý hardware od jednoho dodavatele, pak je často výhodnější použít hotové nástroje pro správu (například HP ILO Amplifier, DELL OpenManage atd.).

Pro instalaci OS na fyzické servery jsme použili známý Cobbler, který definuje sadu instalačních profilů dohodnutých s provozní službou. Při přidávání nového serveru do infrastruktury technik svázal MAC adresu serveru s požadovaným profilem v Cobbleru. Při prvním spuštění ze sítě server obdržel dočasnou adresu a nový operační systém. Poté byl přenesen do cílové VLAN/IP adresování a tam se pokračovalo v práci. Ano, změna VLAN vyžaduje čas a vyžaduje koordinaci, ale poskytuje dodatečnou ochranu proti náhodné instalaci serveru v produkčním prostředí.

Vytvořili jsme virtuální servery na základě šablon připravených pomocí HashiСorp Packer. Důvod byl stejný: zabránit možným lidským chybám při instalaci OS. Na rozdíl od fyzických serverů však Packer eliminuje potřebu PXE, zavádění sítě a změny VLAN. Díky tomu bylo vytváření virtuálních serverů snazší a jednodušší.

Rýže. 1. Správa instalace operačních systémů.

Správa tajemství

Jakýkoli systém správy konfigurace obsahuje data, která by měla být běžným uživatelům skryta, ale jsou potřebná pro přípravu systémů. Jedná se o hesla pro místní uživatele a servisní účty, klíče certifikátů, různé tokeny API atd. Obvykle se jim říká „tajné“.

Pokud od samého začátku neurčíte, kde a jak tato tajemství uložit, pak v závislosti na závažnosti požadavků na zabezpečení informací budou pravděpodobně následující způsoby ukládání:

• přímo v konfiguračním řídicím kódu nebo v souborech v úložišti;
• ve specializovaných nástrojích pro správu konfigurace (například Ansible Vault);
• v systémech CI/CD (Jenkins/TeamCity/GitLab/atd.) nebo v systémech pro správu konfigurace (Ansible Tower/Ansible AWX);
• tajemství lze také přenášet „ručně“. Například jsou rozmístěny na určeném místě a poté je používají systémy správy konfigurace;
• různé kombinace výše uvedeného.

Každá metoda má své nevýhody. Hlavním z nich je nedostatek zásad pro přístup k tajemstvím: je nemožné nebo obtížné určit, kdo může používat určitá tajemství. Další nevýhodou je chybějící auditování přístupu a úplný životní cyklus. Jak rychle nahradit například veřejný klíč, který je zapsán v kódu a v řadě souvisejících systémů?

Použili jsme centralizované tajné úložiště HashiCorp Vault. To nám umožnilo:

• udržet tajemství v bezpečí. Jsou šifrované, a i když někdo získá přístup k databázi Vaultu (například obnovením ze zálohy), nebude moci číst tam uložená tajemství;
• organizovat zásady pro přístup k tajemstvím. Uživatelé a aplikace mají k dispozici pouze jim „přidělená“ tajemství;
• auditovat přístup k tajemstvím. Všechny akce s tajnými klíči jsou zaznamenány v protokolu auditu úložiště;
• organizovat plnohodnotný „životní cyklus“ práce s tajemstvím. Lze je vytvořit, zrušit, nastavit datum vypršení platnosti atd.
• snadná integrace s jinými systémy, které potřebují přístup k tajemstvím;
• a také používat end-to-end šifrování, jednorázová hesla k OS a databázi, certifikáty autorizovaných center atp.

Nyní přejdeme k centrálnímu autentizačnímu a autorizačnímu systému. Bylo to možné i bez něj, ale správa uživatelů v mnoha souvisejících systémech je příliš netriviální. Nastavili jsme ověřování a autorizaci prostřednictvím služby LDAP. Jinak by Vault musel neustále vydávat a sledovat ověřovací tokeny pro uživatele. A mazání a přidávání uživatelů by se změnilo v úkol „vytvořil/smazal jsem tento uživatelský účet všude?“

Do našeho systému přidáváme další úroveň: správu tajemství a centrální ověřování/autorizaci:

Rýže. 2. Správa tajemství.

Správa konfigurace

Dostali jsme se k jádru – CMS systému. V našem případě se jedná o kombinaci Ansible a Red Hat Ansible AWX.

Místo Ansible lze použít Chef, Puppet, SaltStack. Ansible jsme vybrali na základě několika kritérií.

• Za prvé je to všestrannost. Sada hotových modulů pro ovládání dělá dojem. A pokud toho nemáte dost, můžete hledat na GitHubu a Galaxy.
• Za druhé, není třeba instalovat a podporovat agenty na spravovaném zařízení, dokazovat, že nezasahují do zatížení, a potvrzovat absenci „záložek“.
• Za třetí, Ansible má nízkou překážku vstupu. Kompetentní inženýr sepíše pracovní příručku doslova první den práce s produktem.

Samotný Ansible v produkčním prostředí nám ale nestačil. V opačném případě by vznikalo mnoho problémů s omezováním přístupu a auditováním akcí administrátorů. Jak omezit přístup? Koneckonců bylo nutné, aby každé oddělení spravovalo (čti: spustilo Ansible playbook) „svou“ sadu serverů. Jak povolit pouze určitým zaměstnancům spouštět konkrétní knihy Ansible? Nebo jak sledovat, kdo spustil playbook, aniž byste museli nastavovat spoustu místních znalostí o serverech a zařízeních s Ansible?

Lví podíl na těchto problémech řeší Red Hat Ansible věž, nebo jeho open-source upstream projekt Ansible AWX. Proto jsme to u zákazníka upřednostnili.

A ještě jeden dotek k portrétu našeho CMS systému. Ansible playbook by měl být uložen v systémech správy úložišť kódu. Máme to GitLab CE.

Samotné konfigurace jsou tedy spravovány kombinací Ansible/Ansible AWX/GitLab (viz obr. 3). AWX/GitLab je samozřejmě integrován s jediným autentizačním systémem a Ansible playbook je integrován s HashiCorp Vault. Konfigurace vstupují do produkčního prostředí pouze prostřednictvím Ansible AWX, ve kterém jsou specifikována všechna „pravidla hry“: kdo může co konfigurovat, kde získat kód pro správu konfigurace pro CMS atd.

Rýže. 3. Správa konfigurace.

Řízení testů

Naše konfigurace je prezentována ve formě kódu. Proto jsme nuceni hrát podle stejných pravidel jako vývojáři softwaru. Potřebovali jsme zorganizovat procesy vývoje, průběžného testování, dodání a aplikace konfiguračního kódu na produkční servery.

Pokud se tak nestane okamžitě, role napsané pro konfiguraci by buď přestaly být podporovány a upravovány, nebo by přestaly být spouštěny v produkci. Lék na tuto bolest je známý a osvědčil se v tomto projektu:

• každá role je pokryta jednotkovými testy;
• testy se spouštějí automaticky, kdykoli dojde k jakékoli změně v kódu, který spravuje konfigurace;
• změny v kódu správy konfigurace jsou uvolněny do produkčního prostředí až po úspěšném absolvování všech testů a revize kódu.

Vývoj kódu a správa konfigurací se stala klidnější a předvídatelnější. K organizaci průběžného testování jsme použili sadu nástrojů GitLab CI/CD a vzali Ansible Molecule.

Kdykoli dojde ke změně v kódu správy konfigurace, GitLab CI/CD zavolá Molecule:

• kontroluje syntaxi kódu,
• zvedne kontejner Docker,
• použije upravený kód na vytvořený kontejner,
• zkontroluje roli na idempotenci a spustí testy pro tento kód (zrnitost je zde na úrovni ansible role, viz obr. 4).

Do produkčního prostředí jsme dodali konfigurace pomocí Ansible AWX. Provozní inženýři aplikovali změny konfigurace prostřednictvím předdefinovaných šablon. AWX si při každém použití nezávisle „vyžádalo“ nejnovější verzi kódu z hlavní větve GitLab. Tímto způsobem jsme vyloučili použití netestovaného nebo zastaralého kódu v produkčním prostředí. Kód přirozeně vstoupil do hlavní větve až po testování, kontrole a schválení.

Rýže. 4. Automatické testování rolí v GitLab CI/CD.

S provozem výrobních systémů je také spojen problém. V reálném životě je velmi obtížné provádět změny konfigurace pouze pomocí kódu CMS. Nouzové situace nastávají, když technik musí změnit konfiguraci „tady a teď“, aniž by čekal na úpravy kódu, testování, schválení atd.

Výsledkem je, že kvůli ručním změnám se na stejném typu zařízení objevují nesrovnalosti v konfiguraci (například nastavení sysctl je na uzlech clusteru HA nakonfigurováno jinak). Nebo se skutečná konfigurace na zařízení liší od konfigurace uvedené v kódu CMS.

Proto kromě průběžného testování kontrolujeme produkční prostředí, zda nevykazují nesrovnalosti v konfiguraci. Zvolili jsme nejjednodušší možnost: spuštění konfiguračního kódu CMS v režimu „dry run“, tedy bez aplikování změn, ale s upozorněním na všechny nesrovnalosti mezi plánovanou a skutečnou konfigurací. Implementovali jsme to pravidelným spouštěním všech Ansible playbooků s možností „—check“ na produkčních serverech. Jako vždy je Ansible AWX zodpovědný za spuštění a udržování příručky aktuální (viz obr. 5):

Rýže. 5. Kontroluje nesrovnalosti v konfiguraci v Ansible AWX.

Po kontrole odešle AWX administrátorům zprávu o nesrovnalostech. Prostudují problematickou konfiguraci a poté ji opraví prostřednictvím upravených playbooků. Takto udržujeme konfiguraci v produkčním prostředí a CMS je vždy aktuální a synchronizovaný. To eliminuje nepříjemné „zázraky“ při použití CMS kódu na „produkčních“ serverech.

Nyní máme důležitou testovací vrstvu sestávající z Ansible AWX/GitLab/Molecule (obrázek 6).

Rýže. 6. Řízení testů.

Obtížný? Nehádám se. Ale takový komplex správy konfigurace se stal komplexní odpovědí na mnoho otázek souvisejících s automatizací konfigurace serveru. Nyní mají standardní servery prodejce 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 či stovky požadovaných nastavení.

V nastavení serverů a prostředí dnes neexistují žádné „tajné znalosti“. Všechny potřebné funkce jsou zohledněny v playbooku. Už žádná kreativita a vágní pokyny: “Nainstalujte jej jako běžný Oracle, ale musíte zadat několik nastavení sysctl a přidat uživatele s požadovaným UID. Zeptejte se chlapů v provozu, vědí".

Schopnost detekovat nesrovnalosti v konfiguraci a proaktivně je opravovat poskytuje klid. Bez systému správy konfigurace to obvykle vypadá jinak. Problémy se hromadí, až jednoho dne „vystřelí“ do výroby. Poté se provede debriefing, konfigurace se zkontrolují a opraví. A cyklus se znovu opakuje

A samozřejmě jsme zrychlili zprovoznění serverů z několika dnů na hodiny.

No a na samotný Silvestr, když děti radostně rozbalovaly dárky a dospělí si přáli, když zvonkohry udeřily, naši inženýři migrovali systém SAP na nové servery. I Santa Claus řekne, že nejlepší zázraky jsou ty, které jsou dobře připravené.

PS Náš tým se často setkává s tím, že zákazníci chtějí problémy se správou konfigurace řešit co nejjednodušeji. Ideálně jako mávnutím kouzelného proutku – s jedním nástrojem. Ale v životě je všechno složitější (ano, stříbrné náboje nebyly znovu dodány): musíte vytvořit celý proces pomocí nástrojů, které jsou vhodné pro tým zákazníka.

Autor: Sergey Artemov, architekt oddělení řešení DevOps "Jet Infosystems"

Zdroj: www.habr.com