Detta är en utskrift av talet и .
Det här är historien om ett projekt som använde ett självskrivet konfigurationshanteringssystem och varför flytten till Ansible tog 18 månader.
Dag nr. -ХХХ: Före början
Inledningsvis bestod infrastrukturen av många separata värdar som körde Hyper-V. Att skapa en virtuell maskin krävde många steg: att sätta diskarna på rätt plats, registrera DNS, reservera DHCP, sätta VM-konfigurationen i git-förvaret. Denna process var delvis mekaniserad, men till exempel distribuerades virtuella datorer mellan värdar för hand. Men till exempel kan utvecklare korrigera den virtuella datorns konfiguration i git och tillämpa den genom att starta om den virtuella datorn.
Custom Configuration Management Solution
Den ursprungliga idén, misstänker jag, var tänkt som IaC: många tillståndslösa virtuella datorer som återställer sitt tillstånd till noll när de startas om. Vad var VM-konfigurationshantering? Schematiskt ser det enkelt ut:
- En statisk MAC spikades fast för den virtuella datorn.
- En ISO med CoreOS och en startskiva kopplades till den virtuella datorn.
- CoreOS startar anpassningsskriptet genom att ladda ner det från WEB-servern baserat på dess IP.
- Skriptet laddar ner VM-konfigurationen via SCP baserat på IP-adressen.
- Fotduken för systemd-enhetsfiler och fotduken för bash-skript lanseras.
Denna lösning hade många uppenbara problem:
- CoreOS ISO har fasats ut.
- Många komplexa automatiserade åtgärder och magi när du migrerar/skapar virtuella datorer.
- Svårigheter med att uppdatera och när en viss version av programvaran behövs. Ännu roligare med kärnmoduler.
- VM:er erhölls inte så utan data, dvs. VM:er dök upp med en disk med ytterligare användardata monterad.
- Någon skruvade ständigt på systemd-enhetsberoendena och CoreOS skulle frysa vid omstart. Det var svårt att fånga detta med de tillgängliga verktygen i CoreOS.
- Hemlighetshantering.
- Det fanns ingen CM. Det fanns bash- och YML-konfigurationer för CoreOS.
För att tillämpa VM-konfigurationen måste du starta om den, men den kanske inte startas om. Det verkar som ett uppenbart problem, men det finns inga beständiga diskar - det finns ingenstans att spara loggar. Nåväl, ok, låt oss försöka lägga till kärnladdningsalternativet så att loggarna skickas. Men nej, vad komplicerat det hela är.
Dag #0: Inse problemet
Det var den vanliga utvecklingsinfrastrukturen: jenkins, testmiljöer, övervakning, register. CoreOS designades för att vara värd för k8s-kluster, dvs. problemet var hur CoreOS användes. Det första steget var att välja en stack. Vi bestämde oss för:
- CentOS som en basfördelning, eftersom Detta är den närmaste distributionen till produktionsmiljöer.
- Ansible för konfigurationshantering, eftersom det gjordes en omfattande granskning av det.
- Jenkins som ett ramverk för att automatisera befintliga processer, eftersom den har redan använts aktivt för utvecklingsprocesser
- Hyper-V som en virtualiseringsplattform. Det finns ett antal anledningar som går utanför berättelsens ram, men kort sagt – vi kan inte använda molnen, vi måste använda vår egen hårdvara.
Dag nr 30: Fastställande av befintliga avtal - Avtal som kod
När traven var klar började förberedelserna för flytten. Fixa befintliga avtal i form av kod (Avtal som kod!). Övergång manuellt arbete -> mekanisering -> automation.
1. Konfigurera virtuella datorer
Ansible gör ett bra jobb med detta. Med ett minimum av kroppsrörelser kan du ta kontroll över VM-konfigurationer:
- Skapa ett git-förråd.
- Vi lägger listan över virtuella datorer i inventering, konfigurationer i spelböcker och roller.
- Vi håller på att skapa en speciell jenkins-slav från vilken du kan köra Ansible.
- Vi skapar ett jobb och konfigurerar Jenkins.
Den första processen är klar. Avtalen är fasta.
2. Skapa ny virtuell dator
Allt här var inte särskilt bekvämt. Det är inte särskilt bekvämt att skapa virtuella datorer på Hyper-V från Linux. Ett av försöken att mekanisera denna process var:
- Ansbile ansluter via WinRM till Windows-värden.
- Ansible kör ett powershell-skript.
- Powershell-skriptet skapar en ny virtuell dator.
- Med hjälp av Hyper-V/ScVMM, när du skapar en virtuell dator i gästoperativsystemet, konfigureras värdnamnet.
- Vid uppdatering av DHCP-leasingavtalet skickar den virtuella datorn dess värdnamn.
- Standard ddns & dhcp-integration på domänkontrollantsidan konfigurerar DNS-posten.
- Du kan lägga till en virtuell dator till ditt lager och konfigurera den med Ansible.
3. Skapa VM-mall
De uppfann ingenting här - de tog en packare.
- Lägg till packaren, kickstart config till git-förvaret.
- Skapar en speciell jenkinsslav med hyper-v och Packer.
- Vi skapar ett jobb och konfigurerar Jenkins.
Hur denna länk fungerar:
- Packer skapar en tom virtuell dator och hämtar ISO.
- VM:n startar, Packer matar in kommandot i bootloadern för att använda vår kickstart-fil från en diskett eller http.
- Anaconda lanseras med vår konfiguration och den initiala OS-konfigurationen är klar.
- Packer väntar på att den virtuella datorn ska bli tillgänglig.
- Packer inuti den virtuella datorn körs ansible i lokalt läge.
- Ansible använder exakt samma roller som den fungerar i steg #1.
- Packer exporterar VM-mallen.
Dag #75: Refaktorera avtalet utan att bryta = Test ansible + Testkitchen
Att fånga konventioner i kod kanske inte räcker. När allt kommer omkring, om du i processens ins och outs vill förändra något, kan du bryta något. Därför, när det gäller infrastruktur, visas testning av just denna infrastruktur. För att synkronisera kunskap inom teamet började vi testa Ansible-roller. Jag går inte in på djupet eftersom... det finns en artikel som beskriver händelserna vid den tidpunkten (spoiler detta var inte den slutliga versionen och senare blev allt mer komplicerat ).
Dag #130: CentOS+ansible kanske inte behövs? kanske openshift?
Vi måste förstå att processen med att införa infrastruktur inte var den enda och att det fanns sidodelprojekt. Till exempel kom en förfrågan om att lansera vår applikation i openshift och detta resulterade i forskning i mer än en vecka vilket saktade ner flyttprocessen. Resultatet visade sig att openshift inte täcker alla behov, du behöver riktig hårdvara, eller åtminstone förmågan att spela med kärnan.
Dag #170: Openshift passar inte, låt oss chansa med Windows Azure Pack?
Hyper-V är inte särskilt vänlig, SCVMM gör det inte mycket bättre. Men det finns något sådant som Windows Azure Pack, som är ett tillägg till SCVMM och härmar Azure. Men i verkligheten ser produkten övergiven ut: dokumentationen har brutna länkar och är väldigt sparsam. Men som en del av studien av alternativ för att förenkla livet för vårt moln, tittade de också på det.
Dag #250: Windows Azure Pack inte särskilt bra. Vi är kvar på SCVMM
Windows Azure Pack såg lovande ut, men det beslutades att inte ta med WAP med dess komplexitet in i systemet för onödiga funktioner och stannade hos SCVMM.
Dag #360: Att äta elefanten bit för bit
Bara ett år senare var plattformen för att flytta till klar och flyttprocessen började. För detta ändamål sattes en SMART-uppgift. Vi kollade in alla virtuella datorer och började ta reda på konfigurationen en efter en, beskriva den i Ansible och täcka den med tester.
Dag #450: Vilken typ av system fick du?
Processen i sig är inte intressant. Det är rutinmässigt, det kan noteras att de flesta av konfigurationerna var relativt enkla eller isomorfa och enligt Pareto-principen krävde 80% av VM-konfigurationerna 20% av tiden. Enligt samma princip ägnades 80 % av tiden åt att förbereda flytten och endast 20 % på själva flytten.
Dag #540: Final
Vad hände på 18 månader?
- Avtalen blev en kod.
- Manuellt arbete -> Mekanisering -> Automation.
vänster
Källa: will.com