Blížil sa Nový rok. Deti po celej krajine už posielali listy Santa Clausovi alebo si vyrábali darčeky pre seba a ich hlavný vykonávateľ, jeden z veľkých predajcov, sa pripravoval na apoteózu výpredajov. V decembri sa zaťaženie jeho dátového centra niekoľkonásobne zvyšuje. Preto sa spoločnosť rozhodla zmodernizovať dátové centrum a namiesto dosluhujúceho zariadenia uviesť do prevádzky niekoľko desiatok nových serverov. Tým sa príbeh na pozadí víriacich snehových vločiek končí a začína sa thriller.
Zariadenie dorazilo na miesto niekoľko mesiacov pred vrcholom predaja. Operačná služba, samozrejme, vie, ako a čo nakonfigurovať na serveroch, aby ich priviedla do produkčného prostredia. Toto sme však potrebovali zautomatizovať a eliminovať ľudský faktor. Okrem toho boli servery nahradené pred migráciou sady systémov SAP, ktoré boli pre spoločnosť kritické.
Uvedenie nových serverov do prevádzky bolo prísne viazané na termín. A presunúť ho znamenalo ohroziť odoslanie miliardy darov aj migráciu systémov. Termín nedokázal zmeniť ani tím zložený z Otca Frosta a Santa Clausa – systém SAP pre skladové hospodárstvo môžete preniesť len raz ročne. Od 31. decembra do 1. januára sa na 20 hodín zastaví práca v obrovských skladoch maloobchodníka s celkovou veľkosťou 15 futbalových ihrísk. A toto je jediný časový úsek na presun systému. Pri zavádzaní serverov sme nemali priestor na chyby.
Aby som bol jasný: môj príbeh odráža nástroje a proces správy konfigurácií, ktoré používa náš tím.
Komplex správy konfigurácie pozostáva z niekoľkých úrovní. Kľúčovým komponentom je CMS systém. V priemyselnej prevádzke by absencia jednej z úrovní nevyhnutne viedla k nepríjemným zázrakom.
Správa inštalácie OS
Prvou úrovňou je systém riadenia inštalácie operačných systémov na fyzické a virtuálne servery. Vytvára základné konfigurácie OS, pričom eliminuje ľudský faktor.
Pomocou tohto systému sme získali štandardné serverové inštancie s OS vhodnými na ďalšiu automatizáciu. Počas „nalievania“ dostali minimálnu sadu lokálnych používateľov a verejných kľúčov SSH, ako aj konzistentnú konfiguráciu OS. Mohli sme zaručiť správu serverov prostredníctvom CMS a boli sme si istí, že „dole“ na úrovni operačného systému nenastanú žiadne prekvapenia.
„Maximálnou“ úlohou systému správy inštalácie je automatická konfigurácia serverov od úrovne BIOS/Firmvér až po OS. Tu veľa závisí od vybavenia a úloh nastavenia. Pre heterogénne vybavenie môžete zvážiť . Ak je všetok hardvér od jedného dodávateľa, potom je často výhodnejšie použiť hotové nástroje na správu (napríklad HP ILO Amplifier, DELL OpenManage atď.).
Na inštaláciu OS na fyzické servery sme použili známy Cobbler, ktorý definuje sadu inštalačných profilov dohodnutých s prevádzkovou službou. Pri pridávaní nového servera do infraštruktúry inžinier spojil MAC adresu servera s požadovaným profilom v Cobbleri. Pri prvom spustení cez sieť server dostal dočasnú adresu a nový operačný systém. Potom bol prenesený do cieľového VLAN/IP adresovania a tam sa pokračovalo v práci. Áno, zmena VLAN si vyžaduje čas a vyžaduje koordináciu, ale poskytuje dodatočnú ochranu proti náhodnej inštalácii servera v produkčnom prostredí.
Virtuálne servery sme vytvorili na základe šablón pripravených pomocou HashiСorp Packer. Dôvod bol rovnaký: zabrániť možným ľudským chybám pri inštalácii OS. Na rozdiel od fyzických serverov však Packer eliminuje potrebu PXE, zavádzania siete a zmien VLAN. To uľahčilo a zjednodušilo vytváranie virtuálnych serverov.
Ryža. 1. Riadenie inštalácie operačných systémov.
Správa tajomstiev
Každý systém riadenia konfigurácie obsahuje údaje, ktoré by mali byť pred bežnými používateľmi skryté, ale sú potrebné na prípravu systémov. Sú to heslá pre lokálnych používateľov a servisné účty, kľúče certifikátov, rôzne tokeny API atď. Zvyčajne sa nazývajú „tajné“.
Ak od úplného začiatku neurčíte, kde a ako tieto tajomstvá uložiť, potom v závislosti od závažnosti požiadaviek na bezpečnosť informácií budú pravdepodobne nasledujúce spôsoby ukladania:
- priamo v konfiguračnom riadiacom kóde alebo v súboroch v úložisku;
- v špecializovaných nástrojoch na správu konfigurácie (napríklad Ansible Vault);
- v systémoch CI/CD (Jenkins/TeamCity/GitLab/atď.) alebo v systémoch riadenia konfigurácie (Ansible Tower/Ansible AWX);
- tajomstvá je možné prenášať aj „ručne“. Napríklad sú rozmiestnené na určenom mieste a potom ich používajú systémy riadenia konfigurácie;
- rôzne kombinácie vyššie uvedeného.
Každá metóda má svoje nevýhody. Hlavným z nich je nedostatok pravidiel pre prístup k tajomstvám: je nemožné alebo ťažké určiť, kto môže použiť určité tajomstvá. Ďalšou nevýhodou je chýbajúci audit prístupu a úplný životný cyklus. Ako rýchlo nahradiť napríklad verejný kľúč, ktorý je zapísaný v kóde a v množstve súvisiacich systémov?
Použili sme centralizované tajné úložisko HashiCorp Vault. To nám umožnilo:
- uchovávať tajomstvá v bezpečí. Sú zašifrované a aj keď niekto získa prístup k databáze Vaultu (napríklad jej obnovením zo zálohy), nebude môcť čítať tajomstvá, ktoré sú tam uložené;
- organizovať zásady prístupu k tajomstvám. Používatelia a aplikácie majú k dispozícii iba tajomstvá, ktoré im boli „pridelené“;
- audit prístupu k tajomstvám. Všetky akcie s tajnými informáciami sa zaznamenávajú do denníka auditu trezora;
- organizovať plnohodnotný „životný cyklus“ práce s tajomstvami. Môžu byť vytvorené, odvolané, nastaviť dátum vypršania platnosti atď.
- jednoduchá integrácia s inými systémami, ktoré potrebujú prístup k tajomstvám;
- a tiež používať end-to-end šifrovanie, jednorazové heslá pre OS a databázu, certifikáty autorizovaných centier a pod.
Teraz prejdime k centrálnemu systému autentifikácie a autorizácie. Dalo sa to zaobísť aj bez toho, ale správa používateľov v mnohých súvisiacich systémoch je príliš netriviálna. Nastavili sme autentifikáciu a autorizáciu prostredníctvom služby LDAP. V opačnom prípade by Vault musel neustále vydávať a sledovať overovacie tokeny pre používateľov. A mazanie a pridávanie používateľov by sa zmenilo na úlohu „vytvoril som/zmazal som tento používateľský účet všade?“
Do nášho systému pridávame ďalšiu úroveň: správu tajomstiev a centrálnu autentifikáciu/autorizáciu:
Ryža. 2. Správa tajomstiev.
Správa konfigurácie
Dostali sme sa k jadru – CMS systému. V našom prípade ide o kombináciu Ansible a Red Hat Ansible AWX.
Namiesto Ansible možno použiť Chef, Puppet, SaltStack. Ansible sme si vybrali na základe niekoľkých kritérií.
- Po prvé, je to všestrannosť. Sada hotových modulov na ovládanie . A ak ho nemáte dosť, môžete hľadať na GitHub a Galaxy.
- Po druhé, nie je potrebné inštalovať a podporovať agentov na spravovanom zariadení, dokazovať, že nezasahujú do záťaže, a potvrdzovať absenciu „záložiek“.
- Po tretie, Ansible má nízku prekážku vstupu. Kompetentný inžinier napíše pracovnú príručku doslova v prvý deň práce s produktom.
Samotný Ansible v produkčnom prostredí nám ale nestačil. V opačnom prípade by nastali mnohé problémy s obmedzením prístupu a auditovaním činnosti administrátorov. Ako obmedziť prístup? Koniec koncov, bolo potrebné, aby každé oddelenie spravovalo (čítaj: spustilo Ansible playbook) „svoju“ sadu serverov. Ako povoliť iba niektorým zamestnancom spúšťať konkrétne knihy Ansible? Alebo ako sledovať, kto spustil príručku bez toho, aby ste museli nastavovať veľa miestnych znalostí o serveroch a zariadeniach, na ktorých beží Ansible?
Leví podiel takýchto problémov rieši Red Hat , alebo jeho open-source upstream projekt . Preto sme to u zákazníka uprednostnili.
A ešte jeden dotyk k portrétu nášho CMS systému. Ansible playbook by mal byť uložený v systémoch správy úložísk kódu. Máme to .
Samotné konfigurácie sú teda spravované kombináciou Ansible/Ansible AWX/GitLab (pozri obr. 3). Samozrejme, AWX/GitLab je integrovaný s jediným autentifikačným systémom a Ansible playbook je integrovaný s HashiCorp Vault. Konfigurácie vstupujú do produkčného prostredia iba cez Ansible AWX, v ktorom sú špecifikované všetky „pravidlá hry“: kto môže čo konfigurovať, kde získať konfiguračný riadiaci kód pre CMS atď.
Ryža. 3. Správa konfigurácie.
Manažment testov
Naša konfigurácia je prezentovaná vo forme kódu. Preto sme nútení hrať podľa rovnakých pravidiel ako vývojári softvéru. Potrebovali sme zorganizovať procesy vývoja, priebežného testovania, dodávky a aplikácie konfiguračného kódu na produkčné servery.
Ak sa to neurobí okamžite, roly napísané pre konfiguráciu by buď prestali byť podporované a upravované, alebo by sa prestali spúšťať do produkcie. Liek na túto bolesť je známy a osvedčil sa v tomto projekte:
- každá rola je pokrytá jednotkovými testami;
- testy sa spúšťajú automaticky vždy, keď dôjde k akejkoľvek zmene v kóde, ktorý spravuje konfigurácie;
- zmeny v kóde správy konfigurácie sú uvoľnené do produkčného prostredia až po úspešnom absolvovaní všetkých testov a preskúmaní kódu.
Vývoj kódu a správa konfigurácií sa stali pokojnejšími a predvídateľnejšími. Na organizáciu nepretržitého testovania sme použili súpravu nástrojov GitLab CI/CD a vzali sme to .
Kedykoľvek dôjde k zmene v kóde správy konfigurácie, GitLab CI/CD zavolá Molecule:
- kontroluje syntax kódu,
- zdvihne kontajner Docker,
- použije upravený kód na vytvorený kontajner,
- skontroluje rolu na idempotenciu a spustí testy pre tento kód (zrnitosť je tu na úrovni ansible role, pozri obr. 4).
Do produkčného prostredia sme dodávali konfigurácie pomocou Ansible AWX. Prevádzkoví inžinieri aplikovali zmeny konfigurácie prostredníctvom preddefinovaných šablón. AWX si pri každom použití nezávisle „vyžiadal“ najnovšiu verziu kódu z hlavnej pobočky GitLab. Týmto spôsobom sme vylúčili použitie netestovaného alebo zastaraného kódu v produkčnom prostredí. Prirodzene, kód vstúpil do hlavnej vetvy až po testovaní, kontrole a schválení.
Ryža. 4. Automatické testovanie rolí v GitLab CI/CD.
S prevádzkou výrobných systémov je spojený aj problém. V reálnom živote je veľmi ťažké vykonať zmeny v konfigurácii iba prostredníctvom kódu CMS. Núdzové situácie nastávajú, keď inžinier musí zmeniť konfiguráciu „tu a teraz“ bez čakania na úpravu kódu, testovanie, schválenie atď.
Výsledkom je, že v dôsledku manuálnych zmien sa v konfigurácii na rovnakom type zariadenia objavia nezrovnalosti (napríklad nastavenia sysctl sú na uzloch klastra HA nakonfigurované odlišne). Alebo sa skutočná konfigurácia na zariadení líši od konfigurácie uvedenej v kóde CMS.
Preto okrem neustáleho testovania kontrolujeme produkčné prostredia kvôli nezrovnalostiam v konfigurácii. Zvolili sme najjednoduchšiu možnosť: spustenie konfiguračného kódu CMS v režime „suchého chodu“, teda bez aplikovania zmien, ale s upozornením na všetky nezrovnalosti medzi plánovanou a skutočnou konfiguráciou. Implementovali sme to pravidelným spúšťaním všetkých príručiek Ansible s možnosťou „—skontrolovať“ na produkčných serveroch. Ako vždy, Ansible AWX je zodpovedný za spustenie a udržiavanie aktuálnej knihy (pozri obr. 5):
Ryža. 5. Kontroluje nezrovnalosti v konfigurácii v Ansible AWX.
Po kontrole AWX odošle správu o nezrovnalosti administrátorom. Naštudujú si problematickú konfiguráciu a potom ju opravia prostredníctvom upravených playbookov. Takto udržiavame konfiguráciu v produkčnom prostredí a CMS je vždy aktuálny a synchronizovaný. Tým sa eliminujú nepríjemné „zázraky“ pri použití CMS kódu na „produkčných“ serveroch.
Teraz máme dôležitú testovaciu vrstvu pozostávajúcu z Ansible AWX/GitLab/Molecule (obrázok 6).
Ryža. 6. Riadenie testov.
ťažké? Nehádam sa. Ale takýto komplex konfiguračného manažmentu sa stal komplexnou odpoveďou na mnohé otázky súvisiace s automatizáciou konfigurácie servera. Teraz majú štandardné servery predajcu vždy presne definovanú konfiguráciu. CMS na rozdiel od inžiniera nezabudne pridať potrebné nastavenia, vytvoriť používateľov a vykonať desiatky či stovky požadovaných nastavení.
V nastaveniach serverov a prostredí dnes neexistujú žiadne „tajné znalosti“. Všetky potrebné funkcie sú uvedené v príručke. Už žiadna kreativita a vágne pokyny: “Nainštalujte ho ako bežný Oracle, ale musíte zadať niekoľko nastavení sysctl a pridať používateľov s požadovaným UID. Opýtajte sa chlapov v prevádzke, vedia".
Schopnosť odhaliť nezrovnalosti v konfigurácii a proaktívne ich opraviť poskytuje pokoj. Bez systému na správu konfigurácie to zvyčajne vyzerá inak. Problémy sa hromadia, až jedného dňa „vystrelia“ do výroby. Potom sa vykoná prehľad, konfigurácie sa skontrolujú a opravia. A cyklus sa znova opakuje
A samozrejme sme urýchlili spúšťanie serverov do prevádzky z niekoľkých dní na hodiny.
No a na samotný Silvester, keď deti s radosťou rozbaľovali darčeky a dospelí si priali pri zvonení, naši inžinieri migrovali systém SAP na nové servery. Aj Santa Claus povie, že najlepšie zázraky sú tie, ktoré sú dobre pripravené.
PS Náš tím sa často stretáva s tým, že zákazníci chcú riešiť problémy so správou konfigurácie čo najjednoduchšie. Ideálne akoby mávnutím ruky – s jedným nástrojom. Ale v živote je všetko komplikovanejšie (áno, strieborné guľky neboli opäť dodané): musíte vytvoriť celý proces pomocou nástrojov, ktoré sú vhodné pre tím zákazníka.
Autor: Sergey Artemov, architekt oddelenia "Informačné systémy prúdových lietadiel"
Zdroj: hab.com