🥇Ansible: Migration av konfigurationen av 120 VM från CoreOS till CentOS på 18 månader

Detta är en transkription av presentationen på DevopsConf 2019-10-01 och SPbLUG 2019-09-25.

Detta är historien om projektet där en skräddarsydd konfigurationshanteringssystem användes och varför flytten till Ansible drog ut på tiden i 18 månader.

Dag № -XXX: Innan starten

I början bestod infrastrukturen av många fristående värdar som styrdes av Hyper-V. Att skapa en virtuell maskin krävde många steg: placera diskarna på rätt plats, ange DNS, reservera DHCP, och lägga konfigurationen av VM i git-repositoriet. Denna process var delvis mekaniserad, men exempelvis fördelades VM manuellt mellan värdarna. Men exempelvis kunde utvecklarna, efter att ha justerat VM-konfigurationen i git, tillämpa den genom att starta om VM.

Anpassad konfigurationshanteringslösning

Den ursprungliga idén, misstänker jag, var tänkt som IaC: många stateless VMs som återställde sitt tillstånd vid omstart. Hur såg konfigurationshanteringen av VMs ut? Schematisk ser det enkelt ut:

För VM tilldelades en statisk MAC-adress.
ISO med CoreOS kopplades till VM och en startdisk.
CoreOS kör ett anpassningsskript genom att hämta det från webbservern baserat på sin IP.
Skriptet hämtar genom SCP konfigurationen av VM baserat på IP-adressen.
En mängd systemd-enhetsfiler och bash-script körs.

Denna lösning hade många uppenbara problem:

ISO i CoreOS var föråldrad.
Många komplicerade automatiserade åtgärder och magi vid migrering/skapande av VM.
Svårigheter med uppdatering av programvara som måste ha en viss version. Det var ännu mer problematiskt med kärnmoduler.
VM var inte helt utan data, dvs. det fanns VM som hade en monterad disk med användardata dessutom.
Någon gjorde ständigt misstag med beroenden för systemd-enheter och CoreOS hängde vid omstart. Det var problematiskt att fånga detta med de befintliga verktygen i CoreOS.
Hantering av hemligheter.
CM fanns knappt. Det var bash och YML-konfigurationer för CoreOS.

För att tillämpa konfigurationen av VM måste den startas om, men den kanske inte startade om. En rätt uppenbar problematik, men det finns inga persistenta diskar – det finns ingenstans att spara loggar. Okej, låt oss försöka lägga till alternativ i kärnstarten så att loggar skickas. Men nej, allt är så komplicerat.

Dag №0: Erkännande av problemet

Det var en vanlig utvecklingsinfrastruktur: jenkins, testmiljöer, övervakning, registry. CoreOS var avsett för hosting av k8s kluster, dvs problemet låg i hur CoreOS användes. Det första steget var att välja stack. Vi beslutade att använda:

CentOS som basdistribuering, eftersom det är den som ligger närmast produktionsmiljöer.
Ansible för att hantera konfigurationer, eftersom det fanns omfattande expertis om det.
Jenkins som ett ramverk för att automatisera befintliga processer, eftersom det redan användes aktivt för utvecklingsprocesser.
Hyper-V som en virtualiseringsplattform. Det finns flera skäl som går utanför berättelsen, men kort sagt - vi kan inte använda moln, vi måste använda vår egen hårdvara.

Dag nr 30: Dokumentera befintliga avtal - Agreements as Code

När stacken var klar började förberedelserna för flytten. Dokumentationen av befintliga avtal i form av kod (Agreements as Code!). Övergången manuellt arbete -> mekanisering -> som möjliggör snabbare testning, distribution och leverans av ny funktionalitet till användarna. Till exempel skapas det i alla våra projekt automatiskt en CI-pipeline vid varje commit. I den byggs en avbild, testas, distribueras till olika Kubernetes-miljöer för felsökning och vidare kontroller, och om allt går bra - når förändringarna slutligen användaren. Detta är inte längre raketvetenskap, utan en vanlig företeelse för många - förmodligen även för dig, eftersom du läser denna artikel..

1. Konfigurera VM:ar

Ansible hanterar denna uppgift utmärkt. Med minimal ansträngning kan man ta över hanteringen av VM-konfigurationer:

Skapa ett git-repo.
Lägg in listan på VM:ar i inventariet, konfigurationerna i playbooks och roller.
Ställ in en speciell jenkins-slave som kan köra ansible.
Skapa jobb, konfigurera Jenkins.

Den första processen är klar. Avtalen är dokumenterade.

2. Skapa ny VM

Här var det inte särskilt bekvämt. Att skapa VM:ar på Hyper-V från Linux var inte så smidigt. Ett av försöken att automatisera denna process var:

Ansible ansluter via WinRM till Windows-värden.
Ansible kör ett powershell-skript.
Powershell-skriptet skapar en ny VM.
Med hjälp av Hyper-V/ScVMM konfigureras hostname när VM:ar skapas i gäst OS.
VM:en skickar sitt hostname vid uppdatering av DHCP-lease.
Den inbyggda integrationen av ddns & dhcp på Domains Controller konfigurerar DNS-poster.
Man kan lägga till VM:ar i inventariet och konfigurera dem med Ansible.

3. Skapa VM-mall

Här uppfann vi ingenting - vi använde packer.

I git-repo laddar vi upp packer-konfigurationen, kickstart.
Ställ in en speciell jenkins-slave med hyper-v och Packer.
Skapa jobb, konfigurera Jenkins.

Så här fungerar denna koppling:

Packer skapar en tom VM, kopplar ISO.
VM:en startar, Packer ger bootloader-kommandot att använda vår kickstart-fil från floppy eller http.
Anaconda startas med vår konfiguration, den första inställningen av OS görs.
Packer väntar på att VM:en ska bli tillgänglig.
Packer kör ansible i lokal läge inuti VM:en.
Ansible använder exakt samma roller som i steg №1.
Packer exporterar VM-mallen.

Dag №75: Refaktorerar överenskommelser utan att bryta = Testa ansible + Testkitchen

Att fastställa överenskommelser i koden kan vara otillräckligt. Om du vill ändra något i grunden kan du riskera att bryta något. Därför behövs testning av infrastrukturen. För att synka kunskapen inom teamet började vi testa Ansible-roller. Jag ska inte gå djupare in på det, då det finns en artikel som beskriver händelserna vid den tidpunkten. Testa mig om du kan, eller drömmer YML-programmerare om testning av ansible?(spoiler, detta var inte den slutgiltiga versionen och senare blev allt mer komplicerat) Hur man börjar testa Ansible, refaktorerar projektet på ett år och inte tappar förståndet.).

Dag №130: Behöver vi verkligen CentOS+ansible? Kanske Openshift?

Det är viktigt att förstå att processen att implementera infrastrukturer inte var den enda, och det fanns sidoprojekt. Till exempel kom en förfrågan om att köra vår applikation i Openshift vilket ledde till flera veckors forskning. Vi startar applikationen i Openshift och jämför med befintliga verktyg. Vad som bromsade flyttprocessen. Slutsatsen blev att Openshift inte täcker alla behov, vi behöver riktig hårdvara, eller åtminstone möjlighet att experimentera med kärnan.

Dag №170: Openshift fungerar inte, ska vi satsa på Windows Azure Pack?

Hyper-V är inte särskilt användarvänligt, SCVMM gör det inte mycket bättre. Men det finns en produkt som heter Windows Azure Pack, som är ett tillägg till SCVMM och imiterar Azure. Men i verkligheten ser produkten övergiven ut: dokumentationen har trasiga länkar och är ganska sparsam. Men inom ramen för att utforska alternativ för att förenkla vårt moln tittade vi även på detta.

Dag №250: Windows Azure Pack är inte så bra. Vi stannar kvar på SCVMM.

Windows Azure Pack verkade lovande, men det beslutades att inte införa WAP med dess komplikationer för att få onödiga funktioner, och vi stannade på SCVMM.

Dag №360: Äter elefanten bit för bit.

Först efter ett år var plattformen redo för flytt och processen började. En S.M.A.R.T. uppgift ställdes. Vi listade alla VM och började gå igenom konfigurationen en i taget, beskriva den på Ansible och täcka med tester.

Dag №450: Vilket system fick vi?

Själva processen är inte intressant. Den är rutinmässig, och det kan noteras att de flesta konfigurationerna var relativt enkla eller isomorfa, och enligt Pareto-principen krävde 80 % av konfigurationerna 20 % av tiden. På samma sätt gick 80 % av tiden åt till att förbereda flytten och endast 20 % till själva flytten.