🥇Ansible: Migrace konfigurace 120 VM z CoreOS na CentOS za 18 měsíců

Toto je přepis prezentace na DevopsConf 2019-10-01 a SPbLUG 2019-09-25.

To je příběh projektu, ve kterém byl použit vlastní systém správy konfigurací a proč se přechod na Ansible protáhl na 18 měsíců.

Den č. -XXX: Před začátkem

Původní infrastruktura byla tvořena mnoha samostatnými servery řízenými Hyper-V. Vytvoření virtuálního stroje vyžadovalo spoustu akcí: umístit disky na správné místo, nastavit DNS, rezervovat DHCP, umístit konfiguraci VM do git repozitáře. Tento proces byl částečně zautomatizován, ale například VM byly distribuovány mezi servery ručně. Například, vývojáři mohli upravit konfiguraci VM v gitu a aplikovat ji restartováním VM.

Custom Configuration Management Solution

Původní myšlenku, podezřívám, zamýšleli jako IaC: mnohé stateless VM, které při restartu resetovaly svůj stav. Jak vypadalo řízení konfigurací VM? Schematicky to vypadá jednoduše:

Pro VM se přiděloval statický MAC.
K VM byla připojena ISO s CoreOS a spouštěcí disk.
CoreOS spouští skript přizpůsobení, který stahuje z WEB serveru na základě své IP.
Skript stáhne přes SCP konfiguraci VM na základě IP adresy.
Spouští se série unit souborů systemd a série bash skriptů.

Toto řešení mělo mnoho zřejmých problémů:

ISO v CoreOS bylo deprecated.
Mnoho složitě automatizovaných akcí a magie při migraci/vytváření VM.
S obtížemi s aktualizacemi a když je potřeba software určité verze. A ještě zábavnější u modulů jádra.
VM nebyly tak úplně bez dat, tj. objevily se VM, u kterých byl připojen disk s uživatelskými daty navíc.
Někdo neustále chyboval se závislostmi unit souborů systemd a při restartu CoreOS zamrzla. S dostupnými prostředky v CoreOS to bylo problematické chytit.
Správa tajemství.
CM téměř neexistovalo. Byl tu bash a YML konfigurace CoreOS.

Aby bylo možné aplikovat konfiguraci VM, je nutné ji restartovat, ale nemusela se restartovat. Zdá se to jako zřejmý problém, ale není žádný perzistentní disk — logy není kam uložit. No dobře, zkusme přidat možnosti zavádění jádra, aby logy posílaly. Ale ne, jak je to všechno složité.

Den č.0: Přiznání problému

To byla běžná vývojová infrastruktura: Jenkins, testovací prostředí, monitorování, registry. CoreOS byla navržena pro hostování clustrů k8s, takže problém byl v tom, jak byla CoreOS využívána. Prvním krokem bylo výběr stacku. Zastavili jsme se na:

CentOS jako základní distribuce, protože je to nejblíže produkčním prostředím.
Ansible pro správu konfigurací, protože byla rozsáhlá odborná znalost.
Jenkins jako framework pro automatizaci stávajících procesů, protože už byl aktivně využíván pro vývojové procesy.
Hyper-V jako virtualizační platforma. Existuje řada důvodů, které přesahují tento příběh, ale stručně — nemůžeme používat cloud, musíme používat vlastní hardware.

Den č. 30: Zaznamenáváme stávající dohody — Agreements as Code.

Jakmile byl stack jasný, začala příprava na přestěhování. Zaznamenání stávajících dohod ve formě kódu (Agreements as Code!). Přechod ruční práce -> mechanizace -> automatizace.

1. Konfigurace VM

Ansible si s touto úlohou skvěle poradí. S minimem úsilí můžete řídit konfigurace VM:

Vytvoříme git repository.
Uložíme seznam VM do inventáře, konfigurace do playbooků a rolí.
Nastavujeme speciální Jenkins slave, ze kterého bude možné spouštět Ansible.
Vytvoříme job, nastavíme Jenkins.

První proces je hotový. Dohody byly zaznamenány.

2. Vytvořit novou VM

Zde to nebylo moc pohodlné. Z Linuxu nebylo snadné vytvářet VM na Hyper-V. Jedním z pokusů, jak tento proces zmechanizovat, bylo:

Ansible se připojuje přes WinRM k Windows hostiteli.
Ansible spouští PowerShell skript.
PowerShell skript vytváří novou VM.
Prostřednictvím Hyper-V/ScVMM se při vytváření VM v hostitelském OS nastavuje hostname.
VM při obnově DHCP lease odesílá své hostname.
Standardní integrace DDNS & DHCP na straně Domain Controller nastavuje DNS záznam.
VM lze přidat do inventáře a nastavit ji pomocí Ansible.

3. Vytvořit šablonu VM

Zde jsme nevymýšleli nic nového — vzali jsme Packer.

Do git repository ukládáme config Packer, kickstart.
Nastavujeme speciální Jenkins slave s Hyper-V a Packer.
Vytvoříme job, nastavíme Jenkins.

Jak tato kombinace funguje:

Packer vytváří prázdnou VM, připojuje ISO.
VM se spouští, Packer zadává do bootloaderu příkaz používat náš kickstart soubor z disket nebo HTTP.
Spouští se Anaconda s naším configem, provádí se počáteční nastavení OS.
Packer čeká na dostupnost VM.
Packer uvnitř VM spouští Ansible v lokálním režimu.
Ansible používá stejné role jako v kroku č. 1.
Packer exportuje šablonu VM.

Den č. 75: Refaktorujeme dohody, aniž bychom je porušili = Test ansible + Testkitchen.

Zafixovat dohody v kódu může být nedostatečné. Vždyť pokud se v pozadí procesu rozhodneš něco změnit — můžeš něco rozbít. Proto se u infrastruktury objevuje testování této infrastruktury. Abychom synchronizovali znalosti v rámci týmu, začali jsme testovat Ansible role. Nechci se do toho zabývat hlouběji, protože existuje článek popisující události v té době. Otestuj mě, pokud můžeš, nebo sní o testování ansible YML programátoři?(spoiler, to nebyla finální varianta a později se to stalo složitějším). Jak začít testovat Ansible, refaktorovat projekt za rok a neztratit hlavu.).

Den č. 130: A možná CentOS + ansible není potřeba? Možná openshift?

Musíme chápat, že proces zavedení infrastruktury nebyl jediný a byly tu vedlejší podprojekty. Například přišel požadavek na spuštění naší aplikace v openshiftu, což vedlo k výzkumu na více než jeden týden. Spouštíme aplikaci v Openshiftu a srovnáváme existující nástroje. co zpomalilo proces přechodu. Výsledkem se ukázalo, že openshift neřeší všechny potřeby, je potřeba skutečný hardware, nebo alespoň možnost hrát si s jádrem.

Den č. 170: Openshift nevyhovuje, riskneme to s Windows Azure Pack?

Hyper-V není příliš přátelský, SCVMM to moc neulehčuje. Ale existuje taková věc jako Windows Azure Pack, která je nadstavbou nad SCVMM a napodobuje Azure. Ve skutečnosti však produkt vypadá opuštěně: dokumentace s nefunkčními odkazy a velmi chudá. Ale v rámci výzkumu možností zjednodušení našeho cloudu jsme se na něj také podívali.

Den č. 250: Windows Azure Pack není moc dobrý. Zůstáváme na SCVMM.

Windows Azure Pack vypadalo slibně, ale bylo rozhodnuto nezavádět WAP s jeho obtížemi do systému kvůli zbytečným funkcím a zůstali jsme na SCVMM.

Den č. 360: Jíme slona po částech.

Až po roce byla připravena platforma, na kterou se mělo přejít, a začal proces migrace. Bylo stanovené SMART cíle. Vypsali jsme všechny VM a začali jednu po druhé řešit s konfigurací, popisovat ji v Ansible a pokrývat testy.

Den č. 450: Jaký systém se vytvořil?

Celý proces není zajímavý. Je rutinní, lze poznamenat, že většina konfigurací byla relativně jednoduchá nebo izomorfní, a podle principu Pareto 80 % konfigurací si vyžádalo 20 % času. Podle stejného principu 80 % času bylo věnováno přípravě na přestěhování a pouze 20 % na samotné přestěhování.