Ez a beszéd kibővített változata a és .
Ez a projekt története, amelyben egyedi konfigurációkezelő rendszert használtunk, és hogy miért tartott 18 hónapig az Ansible-ra való átállás.
Nap № -XXX: A kezdet előtt
Eredetileg az infrastruktúra sok különálló hyper-v-vel rendelkező hosztot jelentett. Virtuális gép létrehozása számos lépést igényelt: lemezek elhelyezése a megfelelő helyen, DNS beállítások, DHCP lefoglalása, a VM konfigurációjának elhelyezése a git tárolóban. Ez a folyamat részben automatizált volt, de például a VM-eket kézzel osztották el a hosztok között. Azonban a fejlesztők javíthatták a VM konfigurációját a git-ben, és alkalmazhatták azt a VM újraindításával.
Egyedi Konfigurációkezelő Megoldás
Az eredeti ötletet, gyanítom, IaC-ként tervezték: sok stateless VM, amelyek újraindításkor alaphelyzetbe állították az állapotukat. Hogyan nézett ki a VM-ek konfigurációs kezelése? Sémásan egyszerűnek tűnt:
- A VM-hez statikus MAC-ot rendeltek.
- A VM-hez ISO-t csatlakoztattak a CoreOS-szel és a boot lemezzel.
- A CoreOS elindít egy testreszabási szkriptet, amelyet a WEB szerverről tölt le az IP címe alapján.
- A szkript SCP-n keresztül letölti a VM konfigurációját az IP cím alapján.
- Folyamatsorozatot indít a systemd unit fájlokból és bash szkriptekből.
Ennek a megoldásnak sok nyilvánvaló problémája volt:
- Az ISO a CoreOS-ban elavult.
- Sok bonyolultan automatizálható lépés és varázslat a VM-ek migrálása/létrehozása során.
- Nehézségek a frissítésekkel, amikor egy bizonyos verziójú szoftverre van szükség. Még viccesebb a kernel modulokkal.
- A VM-ek nem voltak annyira adatmentesek, azaz megjelentek olyan VM-ek, amelyekhez felhasználói adatokat tartalmazó lemezt csatoltak.
- Folyamatosan valaki hibázott a systemd unit függőségekkel, és a CoreOS újraindítása során lelassult. A CoreOS meglévő eszközeivel ezt nehéz volt nyomon követni.
- Titkosítás kezelése.
- CM nem volt igazán. Volt bash és YML konfiguráció a CoreOS-ban.
A VM konfigurációjának alkalmazásához újra kell indítani, de előfordulhat, hogy nem indult újra. Ez nyilvánvalónak tűnik, de mivel nincsenek tartós lemezek - a naplókat nem lehetett hová menteni. Nos, próbáljuk hozzáadni a kernelfeltöltési opciókat, hogy a naplókat elküldjük. De nem, ez mennyire bonyolult mind.
Nap №0: A probléma elismerése
Ez egy átlagos fejlesztői infrastruktúra volt: jenkins, tesztkörnyezetek, monitorozás, registry. A CoreOS-t a k8s klaszterek hosztolására tervezték, tehát a probléma a CoreOS használatában rejlett. Az első lépés a stack kiválasztása volt. A következő mellett döntöttünk:
- CentOS mint alap disztribúció, mivel ez a legközelebbi disztribúció a production környezetekhez.
- Ansible a konfigurációk kezelésére, mivel jelentős tapasztalatunk volt vele.
- Jenkins mint a meglévő folyamatok automatizálására szolgáló keretrendszer, mivel már aktívan használták a fejlesztési folyamatokban.
- Hyper-V mint virtualizációs platform. Számos ok van, ami túlmutat a történeten, de röviden — nem használhatunk felhőket, saját hardverünket kell használnunk.
30. nap: A meglévő megállapodások rögzítése — Agreements as Code
Miután a stack egyértelművé vált, megkezdődött a költözés előkészítése. A meglévő megállapodások kódba rögzítése (Agreements as Code!). Az átállás kézi munka -> mechánizálás -> automatizálás.
1. VMs konfigurálása
Az Ansible kiválóan boldogul e feladattal. Minimális mozdulattal kezelhetjük a VM-ek konfigurációit:
- Git repository létrehozása.
- A VM-ek listáját inventory-ba, a konfigurációkat playbook-okba és szerepkörökbe helyezzük.
- Beállítunk egy speciális jenkins slave-t, ahonnan elindíthatjuk az ansible-t.
- Létrehozunk egy job-ot, beállítjuk a Jenkins-t.
Az első folyamat készen van. A megállapodások rögzítve lettek.
2. Új VM létrehozása
Itt nem volt túl kényelmes. Linuxból nem volt egyszerű VM-et létrehozni a Hyper-V-n. Az egyik kísérlet a folyamat mechanizálására a következő volt:
- Az Ansible WinRM-en keresztül csatlakozik a Windows hoszthoz.
- Az Ansible elindít egy PowerShell szkriptet.
- A PowerShell szkript létrehoz egy új VM-et.
- A Hyper-V/ScVMM segítségével, amikor VM-et hozunk létre, a vendég OS-ben beállítjuk a hostname-t.
- A VM a DHCP lease frissítésekor elküldi a hostname-jét.
- A DDNS és DHCP natív integrációja a Domain Controller oldalán beállítja a DNS rekordot.
- A VM-eket hozzáadhatjuk az inventory-hoz, és beállíthatjuk az Ansible segítségével.
3. VM sablon létrehozása
Itt nem találtunk fel semmit — a packert használtuk.
- A git repository-ba tesszük a packer, kickstart konfigurációt.
- Beállítunk egy speciális jenkins slave-t hyper-v-vel és packer-rel.
- Létrehozunk egy job-ot, beállítjuk a Jenkins-t.
Hogyan működik ez a párosítás:
- A packer létrehozza a üres VM-et, és csatlakoztatja az ISO-t.
- A VM elindul, a packer a bootloaderbe beírja, hogy használja a mi kickstart fájlunkat floppy lemezről vagy http-ról.
- Az anaconda elindul a mi konfigurációnkkal, és végrehajtja az OS elsődleges beállítását.
- A packer megvárja a VM elérhetőségét.
- A Packer a VM-en belül helyben futtatja az ansiblet.
- Az Ansible ugyanazokat a szerepeket használja, mint az 1. lépésben.
- A Packer exportálja a VM sablonját.
75. nap: Újrafogalmazzuk a megállapodásokat, anélkül, hogy megsértenénk = Teszteld az ansiblet + Tesztkonyhát.
A megállapodások kódba rögzítése nem mindig elegendő. Ha a háttérfolyamat során valamit meg szeretnél változtatni, előfordulhat, hogy valamit eltörsz. Ezért infrastruktúrában megjelenik az infrastruktúra tesztelése. Annak érdekében, hogy szinkronban tartsuk a tudást a csapat keretein belül, elkezdtük tesztelni az Ansible szerepeit. Nem mélyednék bele, mivel van egy cikk, amely leírja az akkori eseményeket. (spoiler: ez nem volt a végső változat, és később minden bonyolultabb lett) ).
130. nap: Talán a CentOS+ansible nem szükséges? Talán az OpenShift?
Fontos megérteni, hogy az infrastruktúra bevezetése nem volt egyedüli folyamat, és voltak mellékalprojektek. Például érkezett egy kérés az alkalmazásunk OpenShift-en való futtatására, ami több hétnyi kutatást követelt. Mi lassította le a költöztetési folyamatot. Az eredmény az lett, hogy az OpenShift nem elégíti ki az összes igényt, valódi vasra van szükség, vagy legalább a lehetőség, hogy a kernellel lehessen játszani.
170. nap: Az OpenShift nem megfelelő, merjünk kockázatot vállalni a Windows Azure Pack-kal?
A Hyper-V nem éppen barátságos, a SCVMM nem javítja a helyzetet. De van a Windows Azure Pack, ami a SCVMM fölötti kiegészítés és az Azure-t utánozza. De valójában a termék elhanyagoltnak tűnik: a dokumentáció hibás linkekkel tele és meglehetősen szegényes. De a kutatás keretein belül a könnyítési lehetőségeket is figyelembe vettük.
250. nap: A Windows Azure Pack nem igazán működik. Maradunk a SCVMM-nél.
A Windows Azure Pack ígéretesnek tűnt, de úgy döntöttünk, hogy nem hozzuk be a WAP-t a bonyolultságaival a rendszerbe a felesleges funkciók miatt, és maradunk a SCVMM-nél.
360. nap: Elemezzük a dolgokat lépésről lépésre.
Csak egy évvel később készült el az a platform, ahová költözni lehetett, és megkezdődött a költöztetési folyamat. Ehhez egy S.M.A.R.T. feladatot állítottunk fel. Felsorolva az összes VM-et, elkezdtük egyesével megvizsgálni a konfigurációt, Ansible-re leírni azt és tesztekkel lefedni.
450. nap: Milyen rendszer jött létre?
A folyamat nem érdekes. Rutinszerű, meg lehet jegyezni, hogy a konfigurációk többsége viszonylag egyszerű vagy izomorf volt, és a Pareto-elv szerint a konfigurációk 80%-a 20% időt igényelt. Ugyanezen elv alapján 80% időt fordítottunk a költözés előkészítésére, és csak 20%-ot magára a költözésre.
540. nap: A finálé
Mi történt az elmúlt 18 hónapban?
- A megállapodások kóddá váltak.
- Kézi munka -> Mechanizálás -> Automatizálás.
Hivatkozások
Forrás: habr.com
