🥇Ansible: Migrácia konfigurácie 120 VM z CoreOS na CentOS za 18 mesiacov

Toto je prepis prezentácie na DevopsConf 2019-10-01 a SPbLUG 2019-09-25.

Toto je príbeh projektu, na ktorom sa používal vlastný systém správy konfigurácií a prečo prechod na Ansible trval 18 mesiacov.

Deň č. -XXX: Pred začiatkom

Pôvodne infraštruktúra pozostávala z množstva samostatných hostiteľov spravovaných Hyper-V. Vytvorenie virtuálneho stroja si vyžadovalo množstvo krokov: umiestniť disky na správne miesto, nastaviť DNS, rezervovať DHCP, uložiť konfiguráciu VMs do git repozitára. Tento proces bol čiastočne zmechanizovaný, ale napríklad rozdelenie VM medzi hostiteľov prebiehalo manuálne. Avšak vývojári mohli upraviť konfiguráciu VM v Gite a aplikovať ju reštartovaním VM.

Vlastné riešenie správy konfigurácií

Pôvodnú myšlienku, predpokladám, zamýšľali ako IaC: množstvo stateless VMs, ktoré sa pri reštarte vrátili do pôvodného stavu. Ako vyzeralo riadenie konfigurácií VMs? Schematicky to vyzeralo jednoducho:

Pre VMs sme nastavili statický MAC.
K VMs sme pripojili ISO s CoreOS a zavádzací disk.
CoreOS spúšťa skript prispôsobenia z jeho WEB servera na základe svojej IP.
Skript sťahuje konfiguráciu VM cez SCP na základe IP adresy.
Spustila sa séria súborov systemd unit a séria bash skriptov.

Toto riešenie malo množstvo zrejmých problémov:

ISO v CoreOS bolo zastarané.
Množstvo zložitých automatizovaných krokov a čarodejníctva pri migrácii/vytváraní VMs.
Problémy s aktualizáciou a potrebou softvéru určitej verzie. Ešte zábavnejšie to bolo s modulmi jadra.
VMs neboli až tak bez údajov, teda sa objavili VMs, ktoré mali pripojený disk s používateľskými údajmi navyše.
Niekoho stále zradili závislosti systemd unit a pri reštarte CoreOS sa zasekla. Bolo problematické odchytávať to dostupnými prostriedkami v CoreOS.
Správa tajomstiev.
CM prakticky neexistovalo. Bol tu bash a YML konfigurácie CoreOS.

Na aplikovanie konfigurácie VM bola potrebná jej reštart, ale mohla sa neúspešne reštartovať. Zdanlivo banálny problém, ale neexistovali perzistentné disky — nemali sme kde uchovávať logy. Dobre, skúsme pridať možnosti pri zavádzaní jadra, aby sa logy posielali. Ale nie, aké je to všetko zložité.

Deň č.0: Uznať problém

To bola bežná vývojová infraštruktúra: Jenkins, testovacie prostredia, monitorovanie, registry. CoreOS bola navrhnutá na hosting klastrov k8s, tj. problém bol v tom, ako sa CoreOS používala. Prvým krokom bol výber stacku. Zastavili sme sa na:

CentOS ako základný distribútor, pretože to je najbližší distribútor k výrobným prostrediam.
Ansible na správu konfigurácií, pretože s ním existovala rozsiahla expertíza.
Jenkins ako rámec na automatizáciu existujúcich procesov, pretože sa už aktívne používal na procesy vývoja.
Hyper-V ako platforma virtualizácie. Existuje množstvo dôvodov, ktoré presahujú rámec rozprávania, ale ak to zhrnieme — nemôžeme používať cloudy, musíme použiť náš hardvér.

Deň č. 30: Fixácia existujúcich dohod — Agreements as Code

Keď bol jasný stack, začala sa príprava na presun. Fixovanie existujúcich dohôd vo forme kódu (Agreements as Code!). Prechod ručný prácu -> mechanizácia -> automatizáciu.

1. Konfigurácia VM

Ansible si s touto úlohou výborne poradí. S minimálnym úsilím je možné prevziať správu konfigurácií VM:

Vytvárame git repozitár.
Ukladáme zoznam VM do inventáru, konfigurácie do playbookov a rolí.
Nastavujeme špeciálny Jenkins slave, z ktorého je možné spúšťať Ansible.
Vytvoríme job, nastavíme Jenkins.

Prvý proces je pripravený. Dohody sú fixované.

2. Vytvoriť novú VM

Tu to nebolo veľmi pohodlné. Z Linuxu nebolo veľmi pohodlné vytvárať VM na Hyper-V. Jedným z pokusov mechanizovať tento proces bolo:

Ansible sa pripája cez WinRM k Windows hostiteľovi.
Ansible spúšťa powershell skript.
Powershell skript vytvára novú VM.
Prostriedkami Hyper-V/ScVMM pri vytváraní VM v hosťovskom OS sa nastavuje hostname.
VM pri aktualizácii DHCP lease posiela svoj hostname.
Štandardná integrácia ddns & dhcp na strane Domain Controller nastavuje DNS záznam.
VM je možné pridávať do inventáru a nastavovať ju Ansible.

3. Vytvoriť šablónu VM

Tu sme nič nevymýšľali - zobrali sme Packer.

Do git repozitára ukladáme konfiguráciu packer, kickstart.
Nastavujeme špeciálny Jenkins slave s Hyper-V a Packer.
Vytvoríme job, nastavíme Jenkins.

Ako funguje táto väzba:

Packer vytvára prázdnu VM, pripojí ISO.
VM sa načíta, Packer zadáva do zavádzača príkaz použiť náš kickstart súbor z diskety alebo http.
Spustí sa anaconda s našou konfiguráciou, vykoná sa počiatočné nastavenie OS.
Packer čaká na dostupnosť VM.
Packer vo VM spúšťa Ansible v lokálnom režime.
Ansible využíva presne tie isté role ako v kroku č. 1.
Packer exportuje šablónu VM.

Deň č. 75: Refaktoring dohôd bez problémov = Test ansible + Testkitchen.

Zafixovanie dohôd v kóde môže byť nedostatočné. Veď ak by si chcel v procese niečo zmeniť — môžeš niečo pokaziť. Preto sa v oblasti infraštruktúry objavuje testovanie tejto infraštruktúry. Aby sme synchronizovali vedomosti v rámci tímu, začali sme testovať Ansible role. Nebudem sa do toho hlboko ponárať, pretože existuje článok popisujúci udalosti v tom čase. Otestuj ma, ak môžeš, alebo snívajú YML programátori o testovaní ansible?(spojler, to nebolo finálne, neskôr sa všetko skomplikovalo. Ako začať testovať Ansible, refaktorovať projekt za rok a nezblázniť sa).

Deň č. 130: A možno CentOS + ansible nie je potrebný? Možno openshift?

Musíme si uvedomiť, že proces začleňovania infraštruktúry nebol jediný a boli aj vedľajšie podprojekty. Napríklad prišla žiadosť o spustenie našej aplikácie v openshift a to sa pretiahlo na niekoľkotýždňový prieskum. Spúšťame aplikáciu v Openshift a porovnávame existujúce nástroje. čo spomalilo proces presúvania. Výsledkom bolo, že openshift neuzatvára všetky potreby, potrebujeme reálne železo, alebo aspoň možnosť experimentovať s jadrom.

Deň č. 170: Openshift nie je vhodný, riskneme s Windows Azure Pack?

Hyper-V nie je veľmi priateľský, SCVMM mu nepridáva na kvalite. Ale existuje taká vec ako Windows Azure Pack, ktorá je nadstavbou nad SCVMM a napodobňuje Azure. V skutočnosti však produkt vyzerá opustený: dokumentácia s nefunkčnými odkazmi a veľmi skromná. Ale v rámci prieskumu možností zjednodušenia nášho cloudu sme sa na neho pozerali tiež.

Deň č. 250: Windows Azure Pack nie je príliš dobrý. Zostávame na SCVMM.

Windows Azure Pack vyzeral sľubne, ale rozhodli sme sa neprinášať WAP s jeho zložitosti do systému kvôli nepotrebným funkciám a zostali sme na SCVMM.

Deň č. 360: Jeme slona po častiach.

Len po roku bola pripravená platforma, kam sa presunúť, a začal proces presunu. Na to bola stanovená úloha S.M.A.R.T. Zozbierali sme všetky VM a začali sa jednou po druhej zaoberať konfiguráciou, opísali sme ju na Ansible a pokryli testami.

Deň č. 450: Aký systém sa vytvoril?

Celý proces nie je zaujímavý. Je rutinný, možno poznamenať, že väčšina konfigurácií bola relatívne jednoduchá alebo izomorfná a podľa Princípu Pareto 80 % konfigurácií vyžadovalo 20 % času. Podľa toho istého princípu 80 % času išlo na prípravu presunu a len 20 % na samotný presun.

Deň č. 540: Finále

Čo sa stalo za 18 mesiacov?

Dohody sa stali kódexom.
Ručná práca -> Mechanizácia -> Automatizácia.

Odkazy

Zdroj: habr.com