Ez a beszéd átirata и .
Ez egy olyan projekt története, amely egy saját maga által írt konfigurációkezelő rendszert használt, és miért tartott 18 hónapig az Ansible-re való áttérés.
sz. nap -ХХХ: A kezdet előtt
Kezdetben az infrastruktúra sok különálló, Hyper-V-t futtató gazdagépből állt. A virtuális gép létrehozása sok lépést igényelt: a lemezek megfelelő helyre helyezése, DNS regisztrálása, DHCP lefoglalása, a virtuális gép konfigurációjának elhelyezése a git repository-ban. Ez a folyamat részben gépesített volt, de például a virtuális gépeket kézzel osztották szét a gazdagépek között. De például a fejlesztők kijavíthatják a virtuális gép konfigurációját a gitben, és a virtuális gép újraindításával alkalmazhatják.
Egyedi konfigurációkezelési megoldás
Az eredeti ötlet, gyanítom, IaC-ként született: sok állapot nélküli virtuális gép, amelyek újraindításkor nullára állítják vissza állapotukat. Mi volt a VM konfigurációkezelés? Sematikusan egyszerűnek tűnik:
- Statikus MAC-ot szögeztek le a virtuális gép számára.
- A virtuális géphez egy CoreOS rendszerű ISO és egy indítólemez csatlakozik.
- A CoreOS elindítja a testreszabási szkriptet úgy, hogy letölti azt a WEB szerverről az IP alapján.
- A szkript letölti a virtuális gép konfigurációját az SCP-n keresztül az IP-cím alapján.
- Elindul a systemd unit fájlok lábtörlője és a bash szkriptek lábtörlője.
Ez a megoldás számos nyilvánvaló problémát okozott:
- A CoreOS ISO elavult.
- Sok összetett automatizált művelet és varázslat a virtuális gépek migrálásakor/létrehozásakor.
- Nehézségek a frissítéssel, és amikor egy bizonyos szoftververzióra van szükség. Még szórakoztatóbb a kernelmodulokkal.
- A virtuális gépek nem így kerültek elő adat nélkül, pl. A virtuális gépek egy lemezzel jelentek meg további felhasználói adatokkal.
- Valaki folyamatosan csavargatta a rendszeregység-függőségeket, és a CoreOS lefagyott újraindításkor. Ezt nehéz volt elkapni a CoreOS rendelkezésre álló eszközeivel.
- Titkok kezelése.
- Nem volt CM. Voltak bash és YML konfigurációk a CoreOS-hez.
A virtuális gép konfigurációjának alkalmazásához újra kell indítania, de előfordulhat, hogy nem indul újra. Nyilvánvaló problémának tűnik, de nincsenek állandó lemezek - nincs hova menteni a naplókat. Nos, rendben, próbáljuk meg hozzáadni a kernel betöltési opciót, hogy a naplók elküldésre kerüljenek. De nem, milyen bonyolult az egész.
0. nap: Ismerje fel a problémát
A szokásos fejlesztési infrastruktúra volt: jenkinek, tesztkörnyezetek, monitorozás, registry. A CoreOS-t k8s klaszterek fogadására tervezték, pl. a probléma az volt, hogy a CoreOS-t hogyan használták. Az első lépés a verem kiválasztása volt. Megállapodtunk:
- CentOS alapeloszlásként, mert Ez a legközelebbi elosztás a termelési környezetekhez.
- Ansible konfigurációkezeléshez, mert alapos vizsgálat folyt róla.
- Jenkins a meglévő folyamatok automatizálásának kereteként, mert már aktívan használták fejlesztési folyamatokhoz
- Hyper-V virtualizációs platformként. Számos ok van, amelyek túlmutatnak a történet keretein, de röviden - nem használhatjuk a felhőket, a saját hardverünket kell használnunk.
30. nap: Meglévő megállapodások rögzítése – Megállapodások kódexként
Amikor a stack tiszta volt, megkezdődtek a költözés előkészületei. Meglévő megállapodások rögzítése kód formájában (Megállapodások kódexként!). Átmenet fizikai munka -> gépesítés -> automatizálás.
1. Konfigurálja a virtuális gépeket
Az Ansible nagyszerű munkát végez ebben. Minimális testmozgással átveheti az irányítást a virtuális gép konfigurációi felett:
- Hozzon létre egy git-tárat.
- A virtuális gépek listáját leltárba, a konfigurációkat a játékfüzetekbe és a szerepekbe helyezzük.
- Beállítunk egy speciális jenkins rabszolgát, amelyből futtathatja az Ansible-t.
- Létrehozunk egy munkát, és beállítjuk a Jenkinst.
Az első folyamat készen áll. A megállapodások rögzítettek.
2. Hozzon létre új virtuális gépet
Itt minden nem volt túl kényelmes. Nem túl kényelmes virtuális gépeket létrehozni a Hyper-V-n Linuxból. Ennek a folyamatnak az egyik gépesítésére tett kísérlete a következő volt:
- Az Ansbile WinRM-en keresztül csatlakozik a Windows gazdagéphez.
- Az Ansible egy powershell-szkriptet futtat.
- A Powershell-szkript új virtuális gépet hoz létre.
- A Hyper-V/ScVMM használatával virtuális gép létrehozásakor a vendég operációs rendszerben a gazdagépnév konfigurálva van.
- A DHCP-bérlet frissítésekor a virtuális gép elküldi a gazdagép nevét.
- A tartományvezérlő oldalon található szabványos ddns és dhcp integráció konfigurálja a DNS-rekordot.
- Hozzáadhat egy virtuális gépet a készletéhez, és konfigurálhatja az Ansible segítségével.
3. VM-sablon létrehozása
Itt nem találtak fel semmit - csomagolót vettek.
- Adja hozzá a csomagolót, a kickstart konfigurációt a git tárolóhoz.
- Speciális jenkins slave beállítása hyper-v-vel és Packerrel.
- Létrehozunk egy munkát, és beállítjuk a Jenkinst.
Hogyan működik ez a link:
- A Packer létrehoz egy üres virtuális gépet, és felveszi az ISO-t.
- A virtuális gép elindul, a Packer beírja a parancsot a rendszerbetöltőbe, hogy a hajlékonylemezről vagy http-ről származó indítófájlunkat használja.
- Az Anaconda a mi konfigurációnkkal elindul, és az operációs rendszer kezdeti konfigurációja megtörtént.
- A Packer arra vár, hogy a virtuális gép elérhetővé váljon.
- A virtuális gépen belüli Packer helyi módban fut.
- Az Ansible pontosan ugyanazokat a szerepköröket használja, mint az 1. lépésben.
- A Packer exportálja a virtuálisgép-sablont.
75. nap: Refaktorálja újra a megállapodást törés nélkül = Tesztelhető + Tesztkonyha
Előfordulhat, hogy a konvenciók kódban történő rögzítése nem elegendő. Hiszen ha a folyamat csínján-bínján változtatni akarsz valamit, akkor valamit eltörhetsz. Ezért az infrastruktúra esetében éppen ennek az infrastruktúrának a tesztelése jelenik meg. A csapaton belüli tudás szinkronizálása érdekében elkezdtük az Ansible szerepek tesztelését. Nem megyek bele, mert… van egy cikk, amely leírja az akkori eseményeket (spoiler ez nem volt a végleges verzió és később minden bonyolultabb lett ).
130. nap: Lehet, hogy nincs szükség CentOS+ansible-re? esetleg openshift?
Meg kell értenünk, hogy nem az infrastruktúra bevezetésének folyamata volt az egyetlen, hanem mellékes alprojektek is voltak. Például érkezett egy kérés, hogy indítsuk el az alkalmazásunkat openshiftben, és ez több mint egy hétig tartó kutatást eredményezett ami lelassította a mozgási folyamatot. Az eredményből kiderült, hogy az openshift nem elégít ki minden igényt, valódi hardver kell hozzá, vagy legalább a kernellel való játék képessége.
170. nap: Az Openshift nem megfelelő, kockáztassunk a Windows Azure Pack segítségével?
A Hyper-V nem túl barátságos, az SCVMM nem teszi sokkal jobbá. De létezik olyan, mint a Windows Azure Pack, amely az SCVMM kiegészítője, és az Azure-t utánozza. A valóságban azonban a termék elhagyatottnak tűnik: a dokumentáció hibás hivatkozásokat tartalmaz, és nagyon ritka. De a felhőnk élettartamának egyszerűsítésének lehetőségeiről szóló tanulmány részeként ezt is megvizsgálták.
250. nap: A Windows Azure Pack nem túl jó. Maradunk az SCVMM-nél
A Windows Azure Pack ígéretesnek tűnt, de úgy döntöttek, hogy a WAP-ot a maga bonyolultságával együtt nem hozzuk be a rendszerbe a felesleges szolgáltatások kedvéért, és maradt az SCVMM.
360. nap: Az elefánt megevése darabonként
Csak egy évvel később elkészült a költözés platformja, és megkezdődött a költözési folyamat. Erre a célra az S.M.A.R.T. feladat. Megvizsgáltuk az összes virtuális gépet, és elkezdtük egyenként kitalálni a konfigurációt, leírjuk az Ansible-ben, és lefedjük tesztekkel.
450. nap: Milyen rendszert kapott?
Maga a folyamat nem érdekes. Ez rutin, megjegyezhető, hogy a legtöbb konfiguráció viszonylag egyszerű vagy izomorf volt, és a Pareto-elv szerint a virtuálisgép-konfigurációk 80%-a az idő 20%-át igényelte. Ugyanezen elv szerint az idő 80%-át a költözés előkészítésével, és csak 20%-át magával a költözéssel töltötték.
540. nap: döntő
Mi történt 18 hónap alatt?
- A megállapodásokból kódex lett.
- Fizikai munka -> Gépesítés -> automatizálás.
Linkek
Forrás: will.com