Dette er en udskrift af talen и .
Dette er historien om et projekt, der brugte et selvskrevet konfigurationsstyringssystem, og hvorfor flytningen til Ansible tog 18 måneder.
Dag nr. -ХХХ: Før begyndelsen
Oprindeligt bestod infrastrukturen af mange separate værter, der kørte Hyper-V. Oprettelse af en virtuel maskine krævede mange trin: at sætte diskene på det rigtige sted, registrere DNS, reservere DHCP, sætte VM-konfigurationen i git-lageret. Denne proces var delvist mekaniseret, men for eksempel blev VM'er fordelt mellem værter manuelt. Men for eksempel kunne udviklere rette VM-konfigurationen i git og anvende den ved at genstarte VM'en.
Custom Configuration Management Solution
Den oprindelige idé, formoder jeg, blev udtænkt som IaC: mange statsløse VM'er, der nulstiller deres tilstand, når de genstartes. Hvad var VM-konfigurationsstyring? Skematisk ser det simpelt ud:
- En statisk MAC blev spikret til VM'en.
- En ISO med CoreOS og en boot-disk blev tilsluttet VM'en.
- CoreOS starter tilpasningsscriptet ved at downloade det fra WEB-serveren baseret på dets IP.
- Scriptet downloader VM-konfigurationen via SCP baseret på IP-adressen.
- Fodkluden af systemd enhedsfiler og fodkluden af bash-scripts lanceres.
Denne løsning havde mange åbenlyse problemer:
- CoreOS ISO er blevet forældet.
- En masse komplekse automatiserede handlinger og magi ved migrering/oprettelse af VM'er.
- Besvær med at opdatere, og når en bestemt version af software er nødvendig. Endnu sjovere med kernemoduler.
- VM'er blev ikke således opnået uden data, dvs. VM'er dukkede op med en disk med yderligere brugerdata monteret.
- Nogen skruede konstant op for systemd-enhedsafhængighederne, og CoreOS ville fryse ved genstart. Det var svært at fange dette ved hjælp af de tilgængelige værktøjer i CoreOS.
- Administration af hemmeligheder.
- Der var ingen CM. Der var bash- og YML-konfigurationer til CoreOS.
For at anvende VM-konfigurationen skal du genstarte den, men den genstarter muligvis ikke. Det virker som et åbenlyst problem, men der er ingen vedvarende diske - der er ingen steder at gemme logfiler. Nå, ok, lad os prøve at tilføje kerneindlæsningsindstillingen, så logfilerne bliver sendt. Men nej, hvor er det hele kompliceret.
Dag #0: Genkend problemet
Det var den sædvanlige udviklingsinfrastruktur: jenkins, testmiljøer, overvågning, registreringsdatabasen. CoreOS blev designet til at hoste k8s-klynger, dvs. problemet var, hvordan CoreOS blev brugt. Det første skridt var at vælge en stak. Vi afgjorde:
- CentOS som en basisfordeling, fordi Dette er den tætteste distribution til produktionsmiljøer.
- Ansible til konfigurationsstyring, fordi der var omfattende undersøgelser af det.
- Jenkins som ramme for automatisering af eksisterende processer, pga det er allerede blevet aktivt brugt til udviklingsprocesser
- Hyper-V som virtualiseringsplatform. Der er en række årsager, der går ud over historiens rammer, men kort sagt – vi kan ikke bruge skyerne, vi skal bruge vores egen hardware.
Dag nr. 30: Fastsættelse af eksisterende aftaler - Aftaler som Kode
Da stakken var klar, begyndte forberedelserne til flytningen. Ret eksisterende aftaler i form af kode (Aftaler som kodeks!). Overgang Manuelt arbejde -> mekanisering -> automatisering.
1. Konfigurer VM'er
Ansible gør et godt stykke arbejde med dette. Med et minimum af kropsbevægelser kan du tage kontrol over VM-konfigurationer:
- Opret et git-lager.
- Vi sætter listen over VM'er i inventar, konfigurationer i playbooks og roller.
- Vi opretter en speciel jenkins-slave, hvorfra du kan køre Ansible.
- Vi opretter et job og konfigurerer Jenkins.
Den første proces er klar. Aftalerne ligger fast.
2. Opret ny VM
Alt her var ikke særlig bekvemt. Det er ikke særlig praktisk at oprette VM'er på Hyper-V fra Linux. Et af forsøgene på at mekanisere denne proces var:
- Ansbile forbinder via WinRM til Windows-værten.
- Ansible kører et powershell-script.
- Powershell-script opretter en ny VM.
- Ved at bruge Hyper-V/ScVMM, når du opretter en VM i gæsteoperativsystemet, konfigureres værtsnavnet.
- Ved opdatering af DHCP-leasingkontrakten sender VM'en sit værtsnavn.
- Standard ddns & dhcp-integration på Domain Controller-siden konfigurerer DNS-posten.
- Du kan tilføje en VM til din beholdning og konfigurere den med Ansible.
3. Opret VM-skabelon
De har ikke opfundet noget her - de tog en pakker.
- Tilføj pakkeren, kickstart config til git repository.
- Opsætning af en speciel jenkins-slave med hyper-v og Packer.
- Vi opretter et job og konfigurerer Jenkins.
Sådan fungerer dette link:
- Packer opretter en tom VM og henter ISO'en.
- VM'en starter, Packer indtaster kommandoen i bootloaderen for at bruge vores kickstart-fil fra en diskette eller http.
- Anaconda lanceres med vores konfiguration, og den indledende OS-konfiguration er udført.
- Packer venter på, at VM'en bliver tilgængelig.
- Packer inde i VM'en kører ansible i lokal tilstand.
- Ansible bruger nøjagtig de samme roller, som den fungerer i trin #1.
- Packer eksporterer VM-skabelonen.
Dag #75: Refaktorer aftalen uden at bryde = Test ansible + Testkøkken
Det er muligvis ikke nok at fange konventioner i kode. Når alt kommer til alt, hvis du i processens ins og outs vil ændre noget, kan du bryde noget. Derfor, i tilfælde af infrastruktur, dukker test af netop denne infrastruktur op. For at synkronisere viden inden for teamet begyndte vi at teste Ansible-roller. Jeg vil ikke gå i dybden, fordi... der er en artikel, der beskriver begivenhederne på det tidspunkt (spoiler dette var ikke den endelige version og senere blev alt mere kompliceret ).
Dag #130: Måske er CentOS+ansible ikke nødvendig? måske openshift?
Vi må forstå, at processen med at indføre infrastruktur ikke var den eneste, og der var sidedelprojekter. For eksempel kom en anmodning om at lancere vores applikation i openshift, og dette resulterede i forskning i mere end en uge hvilket bremsede flytteprocessen. Resultatet viste sig, at openshift ikke dækker alle behov; du har brug for rigtig hardware, eller i det mindste evnen til at spille med kernen.
Dag #170: Openshift er ikke egnet, lad os tage en chance med Windows Azure Pack?
Hyper-V er ikke særlig venlig, SCVMM gør det ikke meget bedre. Men der er sådan noget som Windows Azure Pack, som er en tilføjelse til SCVMM og efterligner Azure. Men i virkeligheden ser produktet forladt ud: dokumentationen har brudte links og er meget sparsom. Men som en del af undersøgelsen af muligheder for at forenkle livet for vores sky, så de også på det.
Dag #250: Windows Azure Pack ikke særlig god. Vi forbliver på SCVMM
Windows Azure Pack så lovende ud, men det blev besluttet ikke at bringe WAP med dets kompleksitet ind i systemet af hensyn til unødvendige funktioner og blev med SCVMM.
Dag #360: At spise elefanten stykke for stykke
Kun et år senere var platformen til at flytte til klar, og flytteprocessen begyndte. Til dette formål blev der sat en SMART opgave. Vi tjekkede alle VM'erne ud og begyndte at finde ud af konfigurationen én efter én, beskrive den i Ansible og dække den med tests.
Dag #450: Hvilken slags system fik du?
Selve processen er ikke interessant. Det er rutine, det kan bemærkes, at de fleste af konfigurationerne var relativt simple eller isomorfe, og ifølge Pareto-princippet krævede 80% af VM-konfigurationerne 20% af tiden. Efter samme princip blev 80 % af tiden brugt på at forberede flytningen og kun 20 % på selve flytningen.
Dag #540: Finale
Hvad skete der på 18 måneder?
- Aftalerne blev et kodeks.
- Manuelt arbejde -> Mekanisering -> Automation.
Links
Kilde: www.habr.com