Rok sa chýlil k Novému roku. Deti z celej krajiny už poslali listy Ježiškovi alebo si vymysleli želania, a ich hlavný vykonávateľ — jeden z veľkých predajcov — sa pripravoval na vyvrcholenie predaja. V decembri zaťaženosť jeho dátového centra narastá niekoľkonásobne. Preto sa spoločnosť rozhodla modernizovať dátové centrum a zaviesť do prevádzky niekoľko desiatok nových serverov na miesto zastaraného vybavenia. Týmto sa rozprávka so snehovými vločkami končí a začína thriller.
Zariadenie prišlo na miesto niekoľko mesiacov pred vrcholom predaja. Prevádzková služba samozrejme vie, ako a čo nastaviť na serveroch, aby ich uviedli do produkčného prostredia. Ale my sme potrebovali tento proces automatizovať a eliminovať ľudský faktor. Navyše servery nahrádzali pred migráciou súbor systémov SAP, ktoré sú kriticky dôležité pre spoločnosť.
Uvádzanie nových serverov do prevádzky bolo prísne viazané na termín. Posunúť ho znamenalo ohroziť nielen dodávky miliardy darčekov, ale aj migráciu systémov. Zmeniť dátum by nedokázal ani tím v zložení Ježiška a Santa Clausa — systém SAP pre správu skladu je možné presunúť iba raz ročne. Od 31. decembra do 1. januára obrovské sklady predajcu, ktoré sú rozlohou ako 20 futbalových ihrísk, na 15 hodín zastavujú svoju činnosť. A to je jediné časové obdobie na presun systému. Nemali sme právo na chybu pri uvádzaní serverov do prevádzky.
Hneď na úvod vysvetlím: môj príbeh odráža nástroje a procesy správy konfigurácií, ktoré naša tím využíva.
Komplex správy konfigurácií pozostáva z niekoľkých úrovní. Kľúčovou súčasťou je CMS systém. Pri priemyselných činnostiach by absencia jednej z úrovní nevyhnutne priviedla k nepríjemným prekvapeniam.
Správa inštalácie OS
Prvá úroveň — to je systém správy inštalácie operačných systémov na fyzických a virtuálnych serveroch. Vytvára základné konfigurácie OS, čím odstraňuje ľudský faktor.
S touto systémou sme získavali štandardizované a vhodné pre ďalšiu automatizáciu verzie serverov s OS. Pri „rozlievaní“ dostávali minimálny súbor lokálnych používateľov a verejných kľúčov SSH, ako aj zosúladenej konfigurácie OS. Mohli sme spoľahlivo spravovať servery cez CMS a boli sme si istí, že "dole", na úrovni OS, nie sú žiadne prekvapenia.
Úlohou „maximálne“ pre systém správy inštalácie je automaticky nastavovať servery od úrovne BIOS/Firmware po OS. Mnohé závisí od hardvéru a nastavenia. Pre heterogénny hardvér možno zvážiť . Ak je všetok "hardvér" od jedného dodávateľa, často je pohodlnejšie používať hotové správcovské nástroje (napríklad HP ILO Amplifier, DELL OpenManage a pod.).
Na inštaláciu OS na fyzických serveroch sme používali všetkým známy Cobbler, v ktorom je definovaný súbor dohodnutých profilov inštalácie so servisným oddelením. Pri pridávaní nového servera do infraštruktúry inžinier priradil MAC-adresu servera požadovaný profil v Cobbleri. Pri prvom spustení cez sieť server dostal dočasnú adresu a najnovší OS. Potom ho previedli do cieľovej VLAN/IP-adresácie a pokračovali v práci už tam. Áno, zmena VLAN zaberá čas a vyžaduje súhlas, ale poskytuje dodatočnú ochranu pred náhodnou inštaláciou servera v produkčnom prostredí.
Virtuálne servery sme vytvárali na základe šablón pripravených pomocou HashiCorp Packer. Dôvod bol rovnaký: aby sa predišlo možným ľudským chybám pri inštalácii OS. Avšak, na rozdiel od fyzických serverov, Packer umožňuje nevyužívať PXE, sieťové spúšťanie a zmenu VLAN. To zjednodušilo vytváranie virtuálnych serverov.
Obr. 1. Správa inštalácie operačných systémov.
Správa tajomstiev
Akýkoľvek systém správy konfigurácií obsahuje údaje, ktoré by mali byť skryté pred bežnými používateľmi, ale sú potrebné pre prípravu systémov. Ide o heslá lokálnych používateľov a servisných účtov, kľúče certifikátov, rôzne API Tokens a pod. Tieto sa zvyčajne nazývajú „tajomstvá“.
Ak sa od začiatku neurčí, kde a ako uchovávať tieto tajomstvá, v závislosti od prísnosti požiadaviek informačnej bezpečnosti sú pravdepodobné nasledujúce spôsoby uchovávania:
- priamo v kóde správy konfigurácie alebo v súboroch v úložisku;
- v špecializovaných nástrojoch na správu konfigurácií (napr. Ansible Vault);
- v systémoch CI/CD (Jenkins/TeamCity/GitLab/ a pod.) alebo v systémoch správy konfigurácií (Ansible Tower/Ansible AWX);
- tajomstvá môžu byť tiež prenášané na „ručnom riadení“. Napríklad ich umiestniť na dohodnuté miesto a potom ich využívajú systémy správy konfigurácií;
- rôzne kombinácie vyššie opísaného.
Každá metóda má svoje nevýhody. Hlavná z nich - absencia politík prístupu k tajnostiam: nie je možné alebo je ťažké zistiť, kto môže používať tie alebo oné tajomstvá. Ďalší mínus - absencia auditu prístupu a plnohodnotného životného cyklu. Ako rýchlo vymeniť, napríklad, verejný kľúč, ktorý je zapísaný v kóde a v niekoľkých súvisiacich systémoch?
Použili sme centralizované úložisko tajomstiev HashiCorp Vault. To nám umožnilo:
- bezpečne uchovávať tajomstvá. Sú šifrované, a aj keby niekto získal prístup k databáze úložiska Vault (napríklad obnovovaním z rezervnej kópie), nebude schopný prečítať tam uložené tajomstvá;
- organizovať politiky prístupu k tajomstvem. Používateľom a aplikáciám sú dostupné len „vyhradené“ im tajomstvá;
- vykonávať audit prístupu k tajomstvem. Akékoľvek akcie s tajomstvom sú zaznamenávané do audítorského denníka Vault;
- organizovať plnohodnotný „životný cyklus“ práce s tajomstvom. Môžu sa vytvárať, odoberať, nastavovať doby platnosti atď.
- ľahko sa integrovať s inými systémami, ktoré potrebujú prístup k tajomstvam;
- a navyše aplikovať end-to-end šifrovanie, jednorazové heslá pre OS a DB, certifikáty oprávnených centier atď.
Teraz prejdeme k centrálnej autentifikačnej a autorizačnej systém. Môžeme sa zaobísť aj bez nej, ale spravovať používateľov v mnohých sprievodných systémoch je príliš zložité. Nastavili sme autentifikáciu a autorizáciu cez službu LDAP. Inak by v tom istom Vault bolo potrebné nepretržite vydávať a viesť evidenciu autentifikačných tokenov pre používateľov. A odstraňovanie a pridávanie používateľov by sa stalo questom „všade som vytvoril/odstránil túto identifikáciu?“
Pridávame ďalšiu úroveň do našej sústavy: správa tajomstiev a centrálna autentifikácia/autorizácia:
Obr. 2. Správa tajomstiev.
Správa konfigurácií
Dostali sme sa do srdca — do systému CMS. V našom prípade ide o kombináciu Ansible a Red Hat Ansible AWX.
Namiesto Ansible môže byť použitý Chef, Puppet, SaltStack. Vybrali sme Ansible z niekoľkých kritérií.
- Po prvé, je to univerzálnosť. Sada pripravených modulov na správu . A ak je ich nedostatok, dá sa hľadať na GitHub a Galaxy.
- Po druhé, nie je potrebné inštalovať a udržiavať agentov na spravovanom zariadení, dokazovať, že nerušia zaťaženie a potvrdzovať absenciu "zálohovaní".
- Po tretie, Ansible má nízky prah vstupu. Odborne zdatný inžinier napíše funkčný playbook doslova v prvý deň práce s produktom.
Ale len Ansible v priemyselnom prostredí nám nestačilo. Inak by vzniklo veľa problémov s obmedzením prístupu a auditom činností administrátorov. Ako oddeliť prístup? Veď bolo potrebné, aby každé oddelenie spravovalo (čítaj — spúšťalo Ansible playbook) "svoj" súbor serverov. Ako povoliť spúšťanie konkrétnych Ansible playbook iba určitým zamestnancom? Alebo ako sledovať, kto spúšťal playbook, bez zakladania množstva lokálnych užívateľských účtov na serveroch a zariadeniach pod správou Ansible?
Veľkú časť podobných otázok rieši Red Hat , alebo jeho open-source upstream projekt . Preto sme ho uprednostnili pre zákazníka.
A ešte jeden detail k portretu nášho systému CMS. Ansible playbook musí byť uložený v systémoch správy kódu. U nás je to .
Takže samotné konfigurácie spravuje kombinácia Ansible/Ansible AWX/GitLab (pozri Obr. 3). Samozrejme, AWX/GitLab sú integrované s jednotným systémom autentifikácie, a Ansible playbook — s HashiCorp Vault. Konfigurácie sa dostanú do produkčného prostredia len cez Ansible AWX, v ktorom sú stanovené všetky "pravidlá hry": kto a čo môže konfigurovať, odkiaľ brať kód na správu konfigurácií pre CMS atď.
Obr. 3. Správa konfigurácií.
Správa testovania
Naša konfigurácia je prezentovaná vo forme kódu. Preto sme nútení hrať podľa tých istých pravidiel ako vývojári softvéru. Museli sme usporiadať procesy vývoja, nepretržitého testovania, dodávky a aplikácie konfiguračného kódu na produkčné servery.
Ak to neurobíte ihneď, napísané úlohy pre konfiguráciu buď prestanú fungovať a budú sa meniť, alebo sa prestanú spúšťať v produkcii. Liekom na túto bolesť je známa metóda a táto sa v projekte osvedčila:
- každá úloha je pokrytá modulovými testami;
- testy sa automaticky spúšťajú pri akejkoľvek zmene v kóde, ktorý spravuje konfigurácie;
- zmeny v kóde správy konfigurácií prechádzajú do produkčného prostredia len po úspešnom prechode všetkých testov a review kódu.
Vývoj kódu a správa konfigurácií sa stali pokojnejšími a predvídateľnejšími. Pre organizáciu kontinuálneho testovania sme použili nástroje GitLab CI/CD, a ako rámec pre organizáciu testov sme zvolili .
Pri akejkoľvek zmene v kóde správy konfigurácií GitLab CI/CD vyvolá Molecule:
- ten kontroluje syntax kódu,
- umožňuje Docker kontajner,
- aplikuje upravený kód do vytvoreného kontajnera,
- kontroluje úlohu na idempotentnosť a spúšťa testy pre tento kód (granularita je tu na úrovni ansible role, pozri Obr. 4).
Konfigurácie do produkčného prostredia sme dodávali pomocou Ansible AWX. Odpovední za prevádzku inžinieri aplikovali zmeny v konfigurácii prostredníctvom vopred definovaných šablón. AWX pri každom použití „požiadal“ o poslednú verziu kódu z master vetvy GitLab. Tak sme vylúčili použitie neovereného alebo zastaraného kódu v produkčnom prostredí. Samozrejme, kód sa do master vetvy dostal len po testovaní, prezeraní a schválení.
Obr. 4. Automatizované testovanie úloh v GitLab CI/CD.
Existuje ešte problém spojený s prevádzkou produkčných systémov. V reálnom živote je veľmi ťažké robiť zmeny v konfigurácii len cez kód CMS. Vznikajú mimoriadne situácie, keď inžinier musí zmeniť konfiguráciu „tu a teraz“, bez čakania na úpravu kódu, testovanie, schválenie a pod.
Výsledkom sú rozdiely v konfigurácii na rovnakom hardvéri (napríklad na uzloch HA-klastra rôzna konfigurácia nastavení sysctl). Alebo skutočná konfigurácia na hardvéri sa líši od tej, ktorá je definovaná v kóde CMS.
Preto okrem nepretržitého testovania kontrolujeme produkčné prostredia na rozdiely v konfiguráciách. Vybrali sme najjednoduchšiu možnosť: spustenie kódu konfigurácie CMS v režime „dry run“, teda bez aplikácie zmien, ale s upozornením na všetky rozdiely medzi plánovanou a skutočnou konfiguráciou. Realizovali sme to pomocou periodických spúšťaní všetkých Ansible playbook s voľbou „—check“ na produkčných serveroch. Za spustenie a aktuálnosť playbook, ako vždy, zodpovedá Ansible AWX (pozri Obr. 5):
Obr. 5. Kontroly na rozdiely v konfiguráciách v Ansible AWX.
Po kontrolách AWX posiela správu o rozdielo administrátorom. Tí skúmajú problematickú konfiguráciu a potom ju opravujú prostredníctvom upravených playbook. Takto udržiavame konfiguráciu v produkčnom prostredí a CMS je vždy v aktuálnom a synchronizovanom stave. To zbavuje nepríjemných „zázrakov“, keď sa kód CMS aplikuje na „živých“ serveroch.
Teraz máme dôležitú úroveň testovania pozostávajúcu z Ansible AWX/GitLab/Molecule (Obr. 6).
Obr. 6. Správa testovania.
Zložité? Nesúhlasím. Ale taký komplex riadenia konfigurácií sa stal vyčerpávajúcou odpoveďou na množstvo otázok spojených s automatizáciou nastavenia serverov. Teraz má retailer pri typových serveroch vždy prísne definovanú konfiguráciu. CMS, na rozdiel od inžiniera, nezabudne pridať potrebné nastavenia, vytvoriť používateľov a vykonať desiatky alebo stovky požadovaných nastavení.
V nastaveniach serverov a prostredí dnes chýbajú „tajné znalosti“. Všetky potrebné vlastnosti sú odrazené v playbook. Žiadna ďalšia kreativita a nejasné inštrukcie: „nainštaluj ako bežný Oracle, ale je potrebné pár nastavení sysctl predpísať, a pridať používateľov s požadovaným UID. Opýtaj sa chlapcov z prevádzky, oni to vedia».
Možnost zistiť rozdiely v konfiguráciách a vopred ich opraviť prináša pokoj. Bez systému správy konfigurácií sa to zvyčajne javí inak. Problémy sa hromadia, až kým raz ne „vystrelia“ v produkcii. Potom sa uskutoční analýza, kontrolujú a opravujú konfigurácie. A cyklus sa opakuje znova.
A samozrejme sme urýchlili uvedenie serverov do prevádzky z niekoľkých dní na hodiny.
Na samotný silvestrovský večer, keď deti radostne rozbaľovali darčeky a dospelí si želali pod údery zvonov, naši inžinieri migrovali SAP systém na nové servery. Aj Dedo Mráz povie, že najlepšie zázraky sú dobre pripravené.
P.S. Náš tím sa často stretáva s tým, že klienti chcú čo najjednoduchšie riešiť úlohu správy konfigurácií. Ideálne by to malo byť ako zázrak — jedným nástrojom. Ale v skutočnosti je to oveľa zložitejšie (áno, znova nepriniesli strieborné guľky): musíme vytvoriť celý proces s pomocou nástrojov priateľských pre tím klienta.
Autor: Sergej Artemov, architekt oddelenia Infósystémy Jet
Zdroj: habr.com
