🥇Ansible: Migration af konfiguration 120 VM fra CoreOS til CentOS på 18 måneder

Dette er en transkription af præsentationen på DevopsConf 2019-10-01 og SPbLUG 2019-09-25.

Dette er historien om projektet, hvor der blev brugt et skræddersyet konfigurationsstyringssystem, og hvorfor overflytningen til Ansible tog 18 måneder.

Dag № -XXX: Før begyndelsen

Oprindeligt bestod infrastrukturen af en række fristående servere, der blev drevet af Hyper-V. Oprettelse af en virtuel maskine krævede mange handlinger: placere diske det rigtige sted, skrive DNS, reservere DHCP, lægge VM-konfigurationen i et git-repositorium. Denne proces var delvist automatiseret, men for eksempel blev VM'er fordelt mellem serverne manuelt. Men udviklerne kunne ændre VM-konfigurationen i git og anvende den ved at genstarte VM'en.

Skræddersyet konfigurationsstyringsløsning

Den oprindelige idé, som jeg formoder blev set som IaC: mange stateless VM'er, der nulstillede deres tilstand ved genstart. Hvordan så konfigurationsstyringen af VM'erne ud? Det ser simpelt ud skematisk:

Der blev tildelt statisk MAC til VM'erne.
Der blev tilsluttet ISO med CoreOS og en boot-disk til VM'erne.
CoreOS kører et tilpasningsscript, som den downloader fra WEB-serveren baseret på sin IP.
Scriptet henter VM-konfigurationen via SCP baseret på IP-adressen.
En række systemd enheds-filer og en række bash-scripts bliver kørt.

Denne løsning havde mange åbenlyse problemer:

ISO i CoreOS var deprecated.
Mange komplekse automatiserede handlinger og magi ved migration/oprettelse af VM'er.
Problemer med opdatering, når specifik softwareversion er nødvendig. Det bliver endnu sjovere med kernel-moduler.
VM'erne var ikke helt uden data, dvs. der opstod VM'er, der havde et ekstra monteret disk med brugerdata.
Nogle gange lavede nogen fejl med afhængighederne af systemd enheden, og ved genstart hang CoreOS. Det var problematisk at fange det med de eksisterende værktøjer i CoreOS.
Håndtering af hemmeligheder.
CM eksisterede nærmest ikke. Der var bash og YML-konfigurationer for CoreOS.

For at anvende VM-konfigurationen skal den genstartes, men den kunne ikke genstarte. Det virker som et åbenlyst problem, men der er ingen persistente diske — hvor skal logfilerne gemmes? Nå, lad os prøve at tilføje indlæsning af kernel-optioner for at sende loggene. Men nej, det er alt sammen så besværligt.

Dag №0: Problemet erkendelse

Det var en almindelig udviklingsinfrastruktur: jenkins, testmiljøer, overvågninger, registry. CoreOS blev designet til hosting af k8s-klynger, så problemet lå i, hvordan CoreOS blev brugt. Det første skridt var valget af stak. Vi valgte:

CentOS som basisdistribution, da det er den mest nærliggende distribution til produktionsmiljøer.
Ansible til konfigurationsstyring, da der var meget ekspertise inden for det.
Jenkins som et automatiseringsframework for eksisterende processer, da det allerede blev brugt aktivt til udviklingsprocesser.
Hyper-V som virtualiseringsplatform. Der er en række årsager, der strækker sig ud over, hvad der kan fortælles her, men kort sagt — vi kan ikke bruge cloud-løsninger, vi er nødt til at bruge vores eget udstyr.

Dag №30: Fastslå eksisterende aftaler — Agreements as Code

Når stakken var klar, begyndte forberedelserne til flytning. Fastlæggelse af eksisterende aftaler i form af kode (Agreements as Code!). Overgangen manuelt arbejde -> mekanisering -> automatisering.

1. Konfigurér VMs

Ansible klarer denne opgave fremragende. Med minimale anstrengelser kan man tage kontrol over VM'ernes konfigurationer:

Opret en git-repository.
Læg listen over VMs i inventory, konfigurationer i playbooks og roller.
Konfigurer en særlig jenkins slave, som kan køre ansible.
Opret job, konfigurer Jenkins.

Den første proces er klar. Aftalerne er fastslået.

2. Opret ny VM

Her var alt ikke særlig praktisk. Det var ikke nemt at oprette VMs på Hyper-V fra Linux. Et af forsøgene på at mekanisere denne proces var:

Ansible forbinder via WinRM til windows-værten.
Ansible kører et powershell-script.
Powershell-scriptet opretter en ny VM.
Ved hjælp af Hyper-V/ScVMM indstilles hostname i gæstesystemet, når VM'en oprettes.
VM'en sender sit hostname, når den opdaterer DHCP lease.
Den indbyggede integration af ddns & amp; dhcp på siden af Domain Controller konfigurerer DNS-posten.
Man kan tilføje VMs til inventar og konfigurere dem med Ansible.

3. Opret VM-skabelon

Her opfandt vi intet nyt — vi brugte packer.

I git-repository'en lægger vi konfigurationen til packer, kickstart.
Konfigurer en særlig jenkins slave med hyper-v og Packer.
Opret job, konfigurer Jenkins.

Hvordan dette setup fungerer:

Packer opretter en tom VM, tilslutter ISO.
VM'en starter, Packer indtaster kommandoen for at bruge vores kickstart-fil fra diskette eller http.
Anaconda starter med vores konfiguration og laver den indledende opsætning af OS.
Packer venter på, at VM'en er tilgængelig.
Packer kører ansible i lokaltilstand inde i VM'en.
Ansible anvender nøjagtig de samme roller som i trin №1.
Packer eksporterer VM-skabelonen.

Dag №75: Refactorering af aftaler uden at bryde = Test ansible + Testkitchen

At fastsætte aftaler i koden kan være utilstrækkeligt. For hvis du undervejs i processen ønsker at ændre noget — kan du komme til at bryde noget. Derfor, i tilfælde af infrastrukturen, er testningen af selve infrastrukturen vigtig. For at synkronisere viden i teamet begyndte vi at teste Ansible-roller. Jeg vil ikke gå mere i dybden, da der findes en artikel, der beskriver begivenhederne på det tidspunkt. Test mig, hvis du kan, eller drømmer YML-programmører om at teste ansible?(spoiler, det var ikke den endelige version, og senere blev det mere kompliceret) Hvordan man begynder at teste Ansible, refaktorere projektet på et år uden at miste besindelsen).

Dag №130: Måske er CentOS+ansible ikke nødvendigt? Måske openshift?

Det er vigtigt at forstå, at processen med at integrere infrastrukturen ikke var den eneste, og der var også underprojekter. For eksempel kom der en anmodning om at køre vores applikation i openshift, hvilket resulterede i undersøgelser, der tog over en uge. Vi starter applikationen i Openshift og sammenligner med det eksisterende værktøj. Hvad stoppede flytteprocessen. Konklusionen var, at openshift ikke dækkede alle behov; der kræves ægte hardware eller i det mindste muligheden for at lege med kernen.

Dag №170: Openshift er ikke egnet, tør vi prøve Windows Azure Pack?

Hyper-V er ikke særlig brugervenlig, og SCVMM gør det ikke meget bedre. Men der findes noget, der hedder Windows Azure Pack, som er et lag ovenpå SCVMM og efterligner Azure. Men i virkeligheden ser produktet forladt ud: dokumentationen har ødelagte links og er temmelig sparsom. Men i forbindelse med undersøgelsen af muligheder for at forenkle vores sky, kiggede vi også på det.

Dag №250: Windows Azure Pack er ikke imponerende. Vi bliver på SCVMM.

Windows Azure Pack så lovende ud, men det blev besluttet ikke at bringe WAP med sine kompleksiteter ind i systemet for unødvendige funktioner, og vi blev på SCVMM.

Dag №360: Vi spiser elefanten stykke for stykke.

Sæsoner senere var platformen klar til at flytte til, og flytteprocessen begyndte. For dette blev der sat en S.M.A.R.T. opgave. Vi skrev alle VM'er ned og begyndte én ad gangen at se på konfigurationen, beskrive den i Ansible og dække den med tests.

Dag №450: Hvilket system blev der?

Selve processen er ikke interessant. Den er rutinepræget, og man kan bemærke, at de fleste konfigurationer var relativt enkle eller isomorfe. Ifølge Pareto-princippet krævede 80% af konfigurationerne 20% af tiden. På samme måde gik 80% af tiden til forberedelse af flytningen, og kun 20% gik til selve flytningen.