A dolog a Karácsonyhoz közeledett. Az ország gyerekei már elküldték leveleiket a Mikulásnak, vagy meglepetéseket terveztek maguknak, míg a főszereplőjük – az egyik nagy kiskereskedő – a vásárlási csúcsra készült. Decemberben a cég adatközpontjára az átlagosnál sokkal nagyobb terhelés nehezedik. Ezért a vállalat úgy döntött, hogy modernizálja az adatközpontját, és több tucat új szervert állít üzembe a megfogyatkozott élettartamú berendezések helyett. Ezzel a hópelyhek körforgásának hangulata zárul, és megkezdődik a thriller.
A berendezés hónapokkal a vásárlási csúcs előtt érkezett a helyszínre. A műszaki szolgáltatás természetesen pontosan tudja, hogyan kell beállítani a szervereket, hogy azokat produkciós környezetbe illeszthessék. De nekünk ezt automatizálnunk kellett, és ki kellett zárnunk az emberi tényezőt is. Ezenkívül a szerverek a SAP rendszerek migrációja előtt váltották fel egymást, amelyek kritikus fontosságúak a cég számára.
Az új szerverek üzembe helyezése szorosan kapcsolódott a határidőhöz. A határidő eltolása a milliárd ajándék kiszállításának és a rendszerek migrációjának veszélyeztetését jelentette. A dátumot még a Mikulás csapata sem tudta volna megváltoztatni — a raktárkezelő SAP rendszerének átköltöztetését évente egyszer lehet csak elvégezni. December 31-én és január 1-jén a kiskereskedő hatalmas raktárai, összesen 20 focipályányi területen, 15 órára leállítják működésüket. Ez a migrációs időszak egyedüli lehetősége. Nincs hibázási lehetőségünk az új szerverek üzembe helyezésével kapcsolatban.
Azonnal tisztázom: a történetem olyan eszközökről és konfigurációkezelési folyamatokról szól, amelyeket a csapatunk alkalmaz.
A konfigurációkezelési komplexum több szintből áll. A kulcselem a CMS-rendszer. Ipari használat esetén az egyik szint hiánya elkerülhetetlenül kellemetlen csodákhoz vezetett volna.
Az operációs rendszerek telepítésének kezelése
Az első szint az operációs rendszerek telepítésének kezelő rendszere fizikai és virtuális szerverekre. Ez létrehozza az operációs rendszerek alap konfigurációit, kiküszöbölve az emberi tényezőt.
Ezzel a rendszerrel alaptípusú, automatizálásra alkalmas példányokat kaptunk az operációs rendszerekkel rendelkező szerverekből. A "kiöntés" során minimális helyi felhasználói készletet és nyilvános SSH-kulcsokat kaptak, valamint a konzisztensebb operációs rendszerkonfigurációt. Garantáltan tudtuk kezelni a szervereket egy CMS-en keresztül, és biztosak voltunk abban, hogy az operációs rendszer szintjén nincsenek meglepetések.
A telepítési rendszer "maximum" feladata az, hogy automatikusan konfigurálja a szervereket a BIOS / Firmware szintjétől az operációs rendszerig. Sok minden itt a hardvertől és a konfigurálási feladatoktól függ. Heterogén hardverek esetén érdemes megfontolni. . Ha az összes "hardver" egy gyártótól származik, akkor gyakran kényelmesebb használni a kész kezelési eszközöket (például HP ILO Amplifier, DELL OpenManage stb.).
Fizikai szerverek operációs rendszerének telepítésére jól ismert Cobbler-t használtuk, amelyben a telepítési profilok egy meghatározott készlete található, amelyeket az üzemeltetés szolgáltatása jóváhagyott. Amikor új szervert adtak hozzá az infrastruktúrához, a mérnök összekapcsolta a szerver MAC-címét a Cobblerben a szükséges profillal. Az első hálózati indításkor a szerver átmeneti címet és új operációs rendszert kapott. Ezt követően áthelyezték a cél VLAN / IP-címezésbe és ott folytatták a munkát. Igen, a VLAN változtatás időt von el és egyeztetést igényel, de ezáltal további védelmet nyújt a szerver véletlen telepítése ellen a production környezetben.
Virtuális szervereket a HashiCorp Packer segítségével elkészített sablonok alapján hoztunk létre. Az ok ugyanaz volt: hogy megakadályozzuk az operációs rendszer telepítése során esetlegesen elképzelhető emberi hibákat. De a fizikai szerverekkel ellentétben a Packer lehetővé teszi a PXE, a hálózati indítás és a VLAN váltás elkerülését. Ez megkönnyítette és egyszerűsítette a virtuális szerverek létrehozását.
1. ábra. Operációs rendszerek telepítésének kezelése.
Titkok kezelése
Bármely konfigurációkezelő rendszer olyan adatokat tartalmaz, amelyek elől a normál felhasználók számára rejtve kell maradniuk, de szükségesek a rendszerek előkészítéséhez. Ide tartoznak a helyi felhasználók és szolgáltatási fiókok jelszavai, tanúsítványkulcsok, különféle API Tokenek stb. Általában "titkoknak" nevezik őket.
Ha eleve nem határozzuk meg, hol és hogyan tároljuk ezeket a titkokat, az információbiztonsági követelmények szigorától függően valószínű, hogy az alábbi tárolási módok lehetségesek:
- közvetlenül a konfigurációs vezérlőkódba vagy a tárolófájlokba;
- speciális konfigurációkezelő eszközökben (például Ansible Vault);
- CI/CD rendszerekben (Jenkins/TeamCity/GitLab/stb.) vagy konfigurációkezelő rendszerekben (Ansible Tower/Ansible AWX);
- a titkokat 'kézi kezelés' útján is át lehet adni. Például megosztják egy előre megállapított helyen, majd a konfigurációkezelő rendszerek használják őket;
- a fent említettek különböző kombinációi.
Minden módszernek megvannak a hátrányai. A fő probléma a hozzáférési politikák hiánya a titkokhoz: nem lehet vagy nehéz meghatározni, ki használhatja a különböző titkokat. Egy másik hátrány a hozzáférés audittal és a teljes életciklus hiánya. Milyen gyorsan lehet például helyettesíteni egy nyilvános kulcsot, amely a kódban és számos kapcsolódó rendszerben van megadva?
Központosított titoktárolót használtunk, HashiCorp Vault. Ez lehetővé tette számunkra:
- a titkok biztonságos tárolását. Ezek titkosítva vannak, és még ha valaki hozzá is fér a Vault adattárolójához (például egy biztonsági mentésből helyreállítva), nem fogja tudni elolvasni a tárolt titkokat;
- a titkokhoz való hozzáférési politikák megszervezését. A felhasználók és alkalmazások csak az 'odaítélt' titkokhoz férhetnek hozzá;
- a titkokhoz való hozzáférés auditálását. A titkokkal kapcsolatos minden tevékenységet rögzítenek a Vault auditnaplójában;
- a titkokkal való teljes 'életciklus' működtetését. Ezeket létre lehet hozni, vissza lehet vonni, lejárati időt lehet beállítani stb.
- könnyen integrálható más rendszerekkel, amelyeknek szükségük van a titkokhoz való hozzáférésre;
- és alkalmazni lehet végponttól végpontig terjedő titkosítást, egyszeri jelszavakat az operációs rendszerekhez és adatbázisokhoz, hitelesítő központok tanúsítványait stb.
Most áttérünk a központi hitelesítési és engedélyezési rendszerre. Megoldható lett volna nélküle is, de a felhasználók adminisztrálása annyi kapcsolódó rendszerben nem triviális. Hitelesítést és engedélyezést állítottunk be LDAP szolgáltatáson keresztül. Különben a Vault-ban folyamatosan ki kellett volna adni és nyilvántartani a felhasználói hitelesítő tokeneket. A felhasználók hozzáadása és eltávolítása pedig egy 'bárhol létrehoztam/eltávolítottam ezt a felhasználót?' küldetésbe torkolt volna.
Hozzáadunk egy új szintet a rendszerünkhöz: titkok kezelése és központi hitelesítés/engedélyezés:
Ábra 2. Titkok kezelése.
Konfigurációkezelés
Eljutottunk a lényeghez — a CMS rendszerhez. A mi esetünkben ez az Ansible és a Red Hat Ansible AWX összekapcsolása.
Az Ansible helyett választható még Chef, Puppet, vagy SaltStack is. Az Ansible-t több szempont alapján választottuk.
- Először is, az univerzalitás. Kész modulok széles választéka áll rendelkezésre a kezeléshez, . Ha esetleg hiányzik valami, akkor a GitHub-on és a Galaxy-n is kereshetünk.
- Másodsorban, nem szükséges ügynököket telepíteni és karbantartani a kezelt eszközökre, bizonygatni, hogy nem zavarják a terhelést, és igazolni az "elrejtegetés" hiányát.
- Harmadszor, az Ansible-nek alacsony a belépési küszöbe. Egy ügyes mérnök az első munkanapján ír egy működő playbook-ot a termékkel.
De az Ansible önmagában nem volt elegendő az ipari környezetben. Máskülönben sok probléma merült volna fel a hozzáférés korlátozásával és az adminisztrátorok tevékenységének auditálásával. Hogyan lehet korlátozni a hozzáférést? Azt szerettük volna, hogy minden osztály a "saját" szerverállományát kezelje (értsd — elindítaná az Ansible playbook-ot). Hogyan lehetne engedélyezni egy adott Ansible playbook futtatását csak bizonyos munkatársak számára? Vagy hogyan lehet nyomon követni, ki futtatta a playbook-ot anélkül, hogy számos helyi felhasználói fiókot kellene létrehozni a szervereken és az Ansible kezelése alatt lévő eszközökön?
Az ilyen kérdések túlnyomó többségére a Red Hat kínál megoldást. , vagy annak nyílt forráskódú upstream projektje, . Ezért is választottuk ezt az ügyfél számára.
És egy újabb részlet a CMS rendszerünk portréjához. Az Ansible playbook-ot a kódkezelő rendszerekben kell tárolni. Nálunk ez .
Tehát a konfigurációkat az Ansible/Ansible AWX/GitLab páros kezeli (lásd a 3. ábrát). Természetesen az AWX/GitLab integrálva van egy központi hitelesítési rendszerrel, az Ansible playbook pedig a HashiCorp Vault-tal. A konfigurációk csak az Ansible AWX-en keresztül kerülnek a produkciós környezetbe, ahol minden "játékszabályt" meghatározott: ki és mit konfigurálhat, honnan szerezheti be a CMS-hez szükséges kódot stb.
3. ábra. Konfigurációkezelés.
Tesztelés kezelése
A konfigurációnk kód formájában van megjelenítve. Ezért nekünk is ugyanazt a szabályrendszert kell követnünk, mint a szoftverfejlesztőknek. Szerveznünk kellett a fejlesztési, folyamatos tesztelési, szállítási és a konfigurációs kód alkalmazásának folyamatát a produkciós szervereken.
Ha ezt nem csináljuk meg azonnal, a konfiguráláshoz írt szerepek vagy már nem lennének támogatva és módosítva, vagy nem indulnának el a production környezetben. A probléma gyógymódja ismert, és bevált ebben a projektben:
- minden szerepet moduláris tesztek fednek le;
- a teszteket automatikusan futtatják a kódban bekövetkező bármilyen változáskor, amely a konfigurációkat irányítja;
- a konfigurációk kezelésére vonatkozó kód módosításai csak az összes teszt és a kódellenőrzés sikeres teljesítése után kerülnek a production környezetbe.
A kód fejlesztése és a konfigurációkezelés nyugodtabbá és kiszámíthatóbbá vált. A folyamatos tesztelés megszervezéséhez a GitLab CI/CD eszközkészletet használtuk, a tesztek megszervezésére pedig a következőt választottuk: .
Bármilyen módosítás esetén a konfigurációk kezelésére vonatkozó kódban a GitLab CI/CD meghívja a Molecule-t:
- ez ellenőrzi a kód szintaxisát,
- elindít egy Docker konténert,
- alkalmazza a módosított kódot a létrehozott konténerbe,
- ellenőrzi a szerepet idempotenciára, és futtatja a teszteket a kód számára (itt a részletesség az ansible szerep szintjén van, lásd 4. ábra).
A production környezetbe konfigurációkat az Ansible AWX segítségével juttattunk el. Az üzemeltetésért felelős mérnökök előre meghatározott sablonokon keresztül alkalmazták a konfigurációs változásokat. Az AWX minden alkalmazásnál saját magától "lekérdezte" az utolsó verziót a GitLab master ágából. Így kizártuk a nem ellenőrzött vagy elavult kód használatát a production környezetben. Természetesen a kód csak a tesztelés, átnézés és jóváhagyás után került a master ágba.
4. ábra. Szerepek automatikus tesztelése a GitLab CI/CD-ben.
A production rendszerek üzemeltetésével kapcsolatosan még egy probléma is adódik. A valós életben nagyon nehéz a konfigurációt csak a CMS kódján keresztül megváltoztatni. Vannak váratlan helyzetek, amikor a mérnöknek azonnal módosítania kell a konfigurációt, nem várva a kód módosítását, tesztelést, jóváhagyást stb.
Ennek következtében a kézi módosítások miatt eltérések jelennek meg az azonos típusú berendezéseken (például az HA klaszter csomópontjain különböző sysctl beállítás konfiguráció). Vagy a valós konfiguráció a berendezésen eltér a CMS kódjában megadottaktól.
Ezért a folyamatos tesztelés mellett ellenőrizzük a production környezetekben a konfigurációk eltérését. A legegyszerűbb megoldást választottuk: a CMS konfigurációs kódjának futtatása „dry run” módban, azaz a változtatások alkalmazása nélkül, de minden eltérésről értesítést kapva, amely a tervezett és a valós konfiguráció között van. Ezt az Ansible playbook-ok rendszeres futtatásával valósítottuk meg, „—check” opcióval a production szervereken. A playbook futtatásáért és érvényességéért, mint mindig, az Ansible AWX felelős (lásd 5. ábra):
5. ábra. A konfigurációk eltérésének ellenőrzése az Ansible AWX-ben.
Az AWX ellenőrzések után jelentést küld az eltérésekről az adminisztrátoroknak. Ők tanulmányozzák a problémás konfigurációt, majd a kijavított playbook segítségével javítják azt. Így biztosítjuk, hogy a production környezet konfigurációja, illetve a CMS mindig aktuális és szinkronizált állapotban legyen. Ez megszabadít bennünket a kellemetlen „csodáktól”, amikor a CMS kódja a „éles” szervereken alkalmazásra kerül.
Most fontos tesztelési szintet értünk el, amely az Ansible AWX/GitLab/Molecule-ból áll (6. ábra).
6. ábra. A tesztelés kezelése.
Bonyolult? Nem vitatom. De ez a konfigurációk kezelésére szolgáló komplex rendszer átfogó választ ad a szerverek beállításával kapcsolatos számos kérdésre. Most a kiskereskedő tipikus szerverei mindig szigorúan meghatározott konfigurációval rendelkeznek. A CMS, ellentétben az mérnökkel, nem fogja elfelejteni, hogy hozzáadja a szükséges beállításokat, létrehozza a felhasználókat, és elvégezze a szükséges tucat vagy száz beállítást.
A szerverek és környezetek beállításaiban ma már nincsenek „titkos tudások”. Minden szükséges sajátosságot a playbook tükröz. Nincs több kreatív megoldás és ködös instrukció: „állítsd be mint egy hagyományos Oracle-t, de ott pár sysctl beállítást fel kell tüntetni, és a szükséges UID-val rendelkező felhasználókat hozzáadni. Kérdezd a működtető csapatot, ők tudják.».
A konfigurációk eltéréseinek és azok előzetes kijavításának lehetősége megnyugtató. A konfigurációkezelő rendszer nélkül ez általában másképpen néz ki. A problémák felhalmozódnak, amíg egyszer csak „visszavágnak” a production-ben. Ezután következik a baleset elemzése, a konfigurációk ellenőrzése és kijavítása. És a ciklus újra kezdődik.
És természetesen felgyorsítottuk a szerverek üzembe helyezését néhány napról órákra.
Az újéj éjszakáján, amikor a gyerekek boldogan bontogatták az ajándékokat, és a felnőttek kívánságokat fogalmaztak meg a harangszó alatt, mérnökeink migrálták a SAP-rendszert az új szerverekre. Még a Mikulás is megerősítheti, hogy a legszebb csodák jól előkészítettek.
P.S. Csapatunk gyakran találkozik azzal, hogy az ügyfelek a lehető legegyszerűbben szeretnék megoldani a konfigurációkezelés feladatát. Ideális esetben, mintha varázslatra lenne szükség — egy eszközzel. De az élet bonyolultabb (igen, újra nem hozták a ezüstgolyókat): egy egész folyamatot kell létrehozni az ügyféltámogató eszközök segítségével.
Szerző: Szergej Artemov, az osztály architektusa Az Infószisztémák Jet
Forrás: habr.com
