Közeledett az újév. A gyerekek országszerte küldtek már levelet a Mikulásnak, vagy készítettek ajándékot maguknak, fő végrehajtójuk, az egyik nagy kereskedő pedig az árusítás apoteózisára készült. Decemberben többszörösére nő az adatközpont terhelése. Ezért a cég az adatközpont korszerűsítése mellett döntött, és az élettartama végéhez érkezett berendezések helyett több tucat új szervert helyez üzembe. Ezzel véget ér a mese a kavargó hópelyhek hátterében, és kezdődik a thriller.
A berendezések több hónappal az eladások csúcsa előtt érkeztek a helyszínre. Az operatív szolgáltatás természetesen tudja, hogyan és mit kell konfigurálni a szervereken, hogy azokat az éles környezetbe vigye. De ezt automatizálnunk kellett, és ki kellett küszöbölnünk az emberi tényezőt. Ezenkívül a szervereket a vállalat számára kritikus SAP-rendszerek migrációja előtt lecserélték.
Az új szerverek üzembe helyezése szigorúan határidőhöz volt kötve. Az áthelyezés pedig egymilliárd ajándék szállítását és a rendszerek migrációját is veszélyeztette. Még a Father Frostból és a Mikulásból álló csapat sem tudta megváltoztatni a dátumot – az SAP rendszert csak évente egyszer lehet raktárkezelésre átvinni. December 31-től január 1-ig a kereskedő hatalmas, összesen 20 futballpálya méretű raktárai 15 órára leállítják a munkát. És ez az egyetlen időszak a rendszer áthelyezésére. A szerverek bevezetésekor nem volt lehetőségünk hibázni.
Hadd fogalmazzak világosan: történetem a csapatunk által használt eszközöket és konfigurációkezelési folyamatokat tükrözi.
A konfigurációkezelési komplexum több szintből áll. A kulcselem a CMS rendszer. Ipari üzemben az egyik szint hiánya elkerülhetetlenül kellemetlen csodákhoz vezetne.
Az operációs rendszer telepítésének kezelése
Az első szint az operációs rendszerek fizikai és virtuális szerverekre történő telepítését kezelő rendszer. Alapvető operációs rendszer-konfigurációkat hoz létre, kiküszöbölve az emberi tényezőt.
Ezzel a rendszerrel standard szerverpéldányokat kaptunk további automatizálásra alkalmas operációs rendszerrel. A „öntés” során minimális számú helyi felhasználót és nyilvános SSH-kulcsot kaptak, valamint konzisztens operációs rendszer-konfigurációt. Biztosak voltunk abban, hogy a CMS-en keresztül kezeljük a szervereket, és biztosak voltunk abban, hogy az operációs rendszer szintjén „lent” nem lesz meglepetés.
A telepítéskezelő rendszer „maximális” feladata a kiszolgálók automatikus konfigurálása a BIOS/Firmware szinttől az operációs rendszerig. Itt sok függ a felszereléstől és a beállítási feladatoktól. Heterogén berendezések esetén megfontolhatja . Ha az összes hardver egy gyártótól származik, akkor gyakran kényelmesebb a kész felügyeleti eszközök használata (például HP ILO Amplifier, DELL OpenManage stb.).
Az operációs rendszer fizikai szerverekre történő telepítéséhez a jól ismert Cobbler-t használtuk, amely az üzemeltetési szolgáltatással egyeztetett telepítési profilokat határoz meg. Amikor új szervert adtunk hozzá az infrastruktúrához, a mérnök hozzákötötte a szerver MAC-címét a kívánt profilhoz a Cobblerben. A hálózaton keresztüli első indításkor a szerver ideiglenes címet és új operációs rendszert kapott. Ezután átkerült a cél VLAN/IP címzésre, és ott folytatta a munkát. Igen, a VLAN megváltoztatása időt vesz igénybe, és koordinációt igényel, de további védelmet nyújt a kiszolgáló üzemi környezetben történő véletlen telepítése ellen.
Virtuális szervereket hoztunk létre a HashiСorp Packer segítségével elkészített sablonok alapján. Az ok ugyanaz volt: az esetleges emberi hibák megelőzése az operációs rendszer telepítésekor. A fizikai szerverekkel ellentétben azonban a Packerben nincs szükség PXE-re, hálózati rendszerindításra és VLAN-módosításokra. Ez megkönnyítette és egyszerűbbé tette a virtuális szerverek létrehozását.
Rizs. 1. Operációs rendszerek telepítésének irányítása.
A titkok kezelése
Bármely konfigurációkezelő rendszer tartalmaz adatokat, amelyeket el kell rejteni a hétköznapi felhasználók elől, de a rendszerek előkészítéséhez szükségesek. Ezek a helyi felhasználók és szolgáltatásfiókok jelszavai, tanúsítványkulcsok, különféle API-tokenek stb. Ezeket általában „titkok”-nak nevezik.
Ha nem határozza meg kezdettől fogva, hol és hogyan tárolja ezeket a titkokat, akkor az információbiztonsági követelmények szigorúságától függően a következő tárolási módok valószínűek:
- közvetlenül a konfigurációs vezérlőkódban vagy a tárolóban lévő fájlokban;
- 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 titkok „manuálisan” is átvihetők. Például egy meghatározott helyen vannak elhelyezve, majd a konfigurációkezelő rendszerek használják őket;
- a fentiek különféle kombinációi.
Mindegyik módszernek megvannak a maga hátrányai. A fő probléma a titkokhoz való hozzáférésre vonatkozó szabályzat hiánya: lehetetlen vagy nehéz meghatározni, hogy ki használhatja fel bizonyos titkokat. További hátrány a hozzáférési auditálás és a teljes életciklus hiánya. Hogyan lehet gyorsan lecserélni például egy nyilvános kulcsot, amely a kódban és számos kapcsolódó rendszerben van írva?
A HashiCorp Vault központosított titkos tárolóját használtuk. Ez lehetővé tette számunkra:
- őrizd biztonságban a titkokat. Titkosítva vannak, és ha valaki hozzáfér a Vault adatbázishoz (például biztonsági másolatból visszaállítva), akkor sem tudja elolvasni az ott tárolt titkokat;
- titkokhoz való hozzáférésre vonatkozó szabályzatokat szervez. Csak a számukra „kiosztott” titkok állnak a felhasználók és alkalmazások rendelkezésére;
- titkokhoz való hozzáférés ellenőrzése. Minden titkot tartalmazó művelet rögzítésre kerül a Vault ellenőrzési naplójában;
- megszervezni a titkokkal való munka teljes értékű „életciklusát”. Létrehozhatók, visszavonhatók, lejárati dátumot állíthatnak be stb.
- könnyen integrálható más rendszerekkel, amelyeknek hozzáférésre van szükségük a titkokhoz;
- és végpontok közötti titkosítást, egyszeri jelszavakat az operációs rendszerhez és az adatbázishoz, az engedélyezett központok tanúsítványait stb.
Most térjünk át a központi hitelesítési és engedélyezési rendszerre. Anélkül is meg lehetett csinálni, de sok kapcsolódó rendszerben túlságosan nem triviális a felhasználók adminisztrálása. A hitelesítést és engedélyezést az LDAP szolgáltatáson keresztül konfiguráltuk. Ellenkező esetben a Vaultnak folyamatosan ki kell adnia és nyomon kell követnie a hitelesítési tokeneket a felhasználók számára. A felhasználók törlése és hozzáadása pedig egy „létrehoztam/töröltem ezt a felhasználói fiókot mindenhol?” kérdéssé.
Újabb szinttel bővítjük rendszerünket: titokkezelés és központi hitelesítés/engedélyezés:
Rizs. 2. Titkok kezelése.
Konfiguráció-menedzsment
Elérkeztünk a lényeghez - a CMS rendszerhez. Esetünkben ez az Ansible és a Red Hat Ansible AWX kombinációja.
Az Ansible helyett Chef, Puppet, SaltStack használható. Az Ansible-t több szempont alapján választottuk.
- Először is ez a sokoldalúság. Kész modulok készlete a vezérléshez . Ha pedig nem lenne elég belőle, kereshet a GitHubon és a Galaxy-n.
- Másodszor, nincs szükség ügynökök telepítésére és támogatására a felügyelt berendezésekre, bizonyítaniuk kell, hogy nem zavarják a terhelést, és megerősíteni a „könyvjelzők” hiányát.
- Harmadszor, az Ansible-nek alacsony a belépési korlátja. Egy hozzáértő mérnök a termékkel való munka első napján szó szerint megírja a munkafüzetet.
De az Ansible önmagában gyártási környezetben nem volt elég számunkra. Ellenkező esetben sok probléma merülne fel a hozzáférés korlátozásával és az adminisztrátorok tevékenységének ellenőrzésével. Hogyan lehet korlátozni a hozzáférést? Hiszen minden osztálynak „saját” szerverkészletét kellett kezelnie (értsd: futtatni az Ansible playbook-ot). Hogyan engedhető meg, hogy csak bizonyos alkalmazottak fussanak bizonyos Ansible játékkönyveket? Vagy hogyan lehet nyomon követni, hogy ki indította el a játékkönyvet anélkül, hogy sok helyismeretet kellene beállítani az Ansible-t futtató szervereken és berendezéseken?
Az ilyen problémák oroszlánrészét a Red Hat oldja meg , vagy nyílt forráskódú upstream projektje . Ezért is részesítettük előnyben az ügyfél számára.
És még egy érintés CMS rendszerünk portréjához. A lehetséges játékkönyvet a kódtárkezelő rendszerekben kell tárolni. Nekünk megvan .
Tehát magukat a konfigurációkat az Ansible/Ansible AWX/GitLab kombinációja kezeli (lásd 3. ábra). Természetesen az AWX/GitLab egyetlen hitelesítési rendszerrel, az Ansible playbook pedig a HashiCorp Vaulttal integrálva van. A konfigurációk csak az Ansible AWX-en keresztül jutnak be az éles környezetbe, amelyben minden „játékszabály” meg van adva: ki mit konfigurálhat, honnan szerezheti be a CMS konfigurációkezelési kódját stb.
Rizs. 3. Konfigurációkezelés.
Tesztkezelés
Konfigurációnk kód formájában jelenik meg. Ezért kénytelenek vagyunk ugyanazokkal a szabályokkal játszani, mint a szoftverfejlesztők. Meg kellett szerveznünk a fejlesztési, folyamatos tesztelési, konfigurációs kód szállítási és alkalmazási folyamatait a termelési szerverekre.
Ha ez nem történik meg azonnal, akkor a konfigurációhoz írt szerepkörök támogatása és módosítása megszűnik, vagy megszűnik az éles indítás. A fájdalom gyógymódja ismert, és ebben a projektben bevált:
- minden szerepkört egységtesztek fednek le;
- a tesztek automatikusan futnak, amikor bármilyen változás történik a konfigurációkat kezelő kódban;
- A konfigurációkezelési kód módosításai csak az összes teszt és a kód áttekintése után kerülnek át az éles környezetbe.
A kódfejlesztés és a konfigurációkezelés nyugodtabb és kiszámíthatóbb lett. A folyamatos tesztelés megszervezéséhez a GitLab CI/CD eszközkészletét használtuk, és vettük .
Amikor változás történik a konfigurációkezelési kódban, a GitLab CI/CD meghívja a Molecule-t:
- ellenőrzi a kód szintaxisát,
- felemeli a Docker konténert,
- alkalmazza a módosított kódot a létrehozott tárolóra,
- ellenőrzi a szerepkör idempotenciáját, és teszteket futtat erre a kódra (a részletesség itt a lehetséges szerepszinten van, lásd 4. ábra).
A konfigurációkat Ansible AWX segítségével szállítottuk az éles környezetbe. Az üzemeltetési mérnökök a konfigurációs változtatásokat előre meghatározott sablonokon keresztül alkalmazták. Az AWX függetlenül „kérte” a kód legújabb verzióját a GitLab fő ágától minden alkalommal, amikor azt használták. Így kizártuk a teszteletlen vagy elavult kód használatát az éles környezetben. A kód természetesen csak tesztelés, áttekintés és jóváhagyás után került a master ágba.
Rizs. 4. A szerepkörök automatikus tesztelése GitLab CI/CD-ben.
Probléma merül fel a termelési rendszerek működésével is. A való életben nagyon nehéz konfigurációs változtatásokat végrehajtani pusztán CMS-kódon keresztül. Vészhelyzetek merülnek fel, amikor a mérnöknek „itt és most” meg kell változtatnia a konfigurációt anélkül, hogy megvárná a kódszerkesztést, tesztelést, jóváhagyást stb.
Ennek eredményeként a kézi változtatások miatt eltérések jelennek meg a konfigurációban ugyanazon a típusú berendezéseken (például a sysctl beállítások eltérően vannak konfigurálva a HA-fürtcsomópontokon). Vagy a berendezés tényleges konfigurációja eltér a CMS kódban meghatározottaktól.
Ezért a folyamatos tesztelés mellett ellenőrizzük a termelési környezeteket konfigurációs eltérések szempontjából. A legegyszerűbb megoldást választottuk: a CMS konfigurációs kódját „száraz futás” módban futtatjuk, azaz változtatások nélkül, de a tervezett és a tényleges konfiguráció közötti eltérések bejelentésével. Ezt úgy valósítottuk meg, hogy időszakosan futtattuk az összes Ansible játékkönyvet a „—check” opcióval az éles szervereken. Mint mindig, az Ansible AWX felelős a játékkönyv elindításáért és naprakészen tartásáért (lásd: 5. ábra):
Rizs. 5. Ellenőrzi az Ansible AWX konfigurációs eltéréseit.
Az ellenőrzések után az AWX eltérési jelentést küld a rendszergazdáknak. Tanulmányozzák a problémás konfigurációt, majd kijavítják a módosított játékfüzeteken keresztül. Így tartjuk karban a konfigurációt az éles környezetben, és a CMS mindig naprakész és szinkronizált. Ez kiküszöböli a kellemetlen „csodákat”, amikor CMS kódot használnak a „termelési” szervereken.
Most van egy fontos tesztelési rétegünk, amely az Ansible AWX/GitLab/Molecule-ból áll (6. ábra).
Rizs. 6. Tesztkezelés.
Nehéz? Nem vitatkozom. De a konfigurációkezelés ilyen komplexuma átfogó választ ad a szerverkonfiguráció automatizálásával kapcsolatos számos kérdésre. Mostantól a kiskereskedők szabványos szerverei mindig szigorúan meghatározott konfigurációval rendelkeznek. A CMS a mérnökökkel ellentétben nem felejti el hozzáadni a szükséges beállításokat, létrehozni a felhasználókat, és több tucat vagy száz szükséges beállítást végrehajtani.
A szerverek és környezetek beállításaiban ma már nincs „titkos tudás”. Minden szükséges funkció megtalálható a forgatókönyvben. Nincs több kreativitás és homályos utasítások: "Telepítse úgy, mint a hagyományos Oracle-t, de meg kell adnia néhány sysctl beállítást, és hozzá kell adnia a szükséges felhasználói azonosítóval rendelkező felhasználókat. Kérdezd meg az operáló srácokat, ők tudják".
A konfigurációs eltérések észlelésének és proaktív kijavításának képessége nyugalmat biztosít. Konfigurációkezelő rendszer nélkül ez általában másképp néz ki. A problémák addig halmozódnak, amíg egy napon „be nem lőnek” a termelésbe. Ezt követően kikérdezés történik, a konfigurációk ellenőrzése és javítása megtörténik. És a ciklus újra megismétlődik
És természetesen több napról órákra felgyorsítottuk a szerverek üzembe helyezését.
Nos, magán a szilveszterkor, amikor a gyerekek örömmel bontották ki az ajándékokat, a felnőttek pedig jókívánságokat fogalmaztak meg, miközben megszólalt a harangszó, mérnökeink áttelepítették az SAP rendszert új szerverekre. Még a Mikulás is azt mondja, hogy a legjobb csodák azok, amelyek jól felkészültek.
PS Csapatunk gyakran találkozik azzal, hogy az ügyfelek a konfigurációkezelési problémákat a lehető legegyszerűbben szeretnék megoldani. Ideális esetben, mintha varázsütésre - egyetlen eszközzel. De az életben minden bonyolultabb (igen, az ezüstgolyókat nem szállították újra): egy teljes folyamatot kell létrehoznia olyan eszközökkel, amelyek kényelmesek az ügyfél csapata számára.
Szerző: Sergey Artemov, tanszéki építész "Jet Inforendszerek"
Forrás: will.com