Dette er en utskrift av talen и .
Dette er historien om et prosjekt som brukte et selvskrevet konfigurasjonsstyringssystem og hvorfor overgangen til Ansible tok 18 måneder.
Dag nr. -ХХХ: Før begynnelsen
Opprinnelig besto infrastrukturen av mange separate verter som kjørte Hyper-V. Å lage en virtuell maskin krevde mange trinn: å sette diskene på riktig sted, registrere DNS, reservere DHCP, sette VM-konfigurasjonen i git-depotet. Denne prosessen var delvis mekanisert, men for eksempel ble VM-er fordelt mellom verter for hånd. Men for eksempel kan utviklere korrigere VM-konfigurasjonen i git og bruke den ved å starte VM-en på nytt.
Custom Configuration Management Solution
Den opprinnelige ideen, mistenker jeg, ble unnfanget som IaC: mange statsløse VM-er som tilbakestiller tilstanden til null når de starter på nytt. Hva var VM-konfigurasjonsadministrasjon? Skjematisk ser det enkelt ut:
- En statisk MAC ble spikret ned for VM.
- En ISO med CoreOS og en oppstartsdisk ble koblet til VM.
- CoreOS lanserer tilpasningsskriptet ved å laste det ned fra WEB-serveren basert på IP-adressen.
- Skriptet laster ned VM-konfigurasjonen via SCP basert på IP-adressen.
- Fotduken til systemd-enhetsfiler og fotduken til bash-skript lanseres.
Denne løsningen hadde mange åpenbare problemer:
- CoreOS ISO har blitt avviklet.
- Mange komplekse automatiserte handlinger og magi ved migrering/oppretting av VM-er.
- Vanskeligheter med å oppdatere og når en viss versjon av programvare er nødvendig. Enda morsommere med kjernemoduler.
- VM-er ble ikke slik innhentet uten data, dvs. VM-er dukket opp med en disk med ekstra brukerdata montert.
- Noen skrudde stadig opp systemd-enhetsavhengighetene, og CoreOS ville fryse ved omstart. Det var vanskelig å fange dette ved å bruke de tilgjengelige verktøyene i CoreOS.
- Hemmelighetsbehandling.
- Det var ingen CM. Det var bash- og YML-konfigurasjoner for CoreOS.
For å bruke VM-konfigurasjonen må du starte den på nytt, men den starter kanskje ikke på nytt. Det virker som et åpenbart problem, men det er ingen vedvarende disker - det er ingen steder å lagre logger. Vel, ok, la oss prøve å legge til kjernelastingsalternativet slik at loggene sendes. Men nei, så komplisert det hele er.
Dag #0: Gjenkjenne problemet
Det var den vanlige utviklingsinfrastrukturen: jenkins, testmiljøer, overvåking, register. CoreOS ble designet for å være vert for k8s-klynger, dvs. problemet var hvordan CoreOS ble brukt. Det første trinnet var å velge en stabel. Vi bestemte oss for:
- CentOS som en basisfordeling, fordi Dette er den nærmeste distribusjonen til produksjonsmiljøer.
- Ansible for konfigurasjonsadministrasjon, fordi det var omfattende undersøkelser av det.
- Jenkins som et rammeverk for å automatisere eksisterende prosesser, fordi den har allerede blitt aktivt brukt i utviklingsprosesser
- Hyper-V som en virtualiseringsplattform. Det er en rekke årsaker som går utenfor historiens omfang, men kort sagt – vi kan ikke bruke skyene, vi må bruke vår egen maskinvare.
Dag nr. 30: Fastsetting av eksisterende avtaler - Avtaler som Kode
Da stabelen var klar, begynte forberedelsene til flyttingen. Retting av eksisterende avtaler i form av kode (Avtaler som kode!). Overgang manuelt arbeid -> mekanisering -> automasjon.
1. Konfigurer VM-er
Ansible gjør en god jobb med dette. Med et minimum av kroppsbevegelser kan du ta kontroll over VM-konfigurasjoner:
- Lag et git-depot.
- Vi legger listen over virtuelle maskiner i inventar, konfigurasjoner i spillebøker og roller.
- Vi setter opp en spesiell jenkins-slave som du kan kjøre Ansible fra.
- Vi oppretter en jobb og konfigurerer Jenkins.
Den første prosessen er klar. Avtalene ligger fast.
2. Opprett ny VM
Alt her var ikke veldig praktisk. Det er ikke veldig praktisk å lage VM-er på Hyper-V fra Linux. Et av forsøkene på å mekanisere denne prosessen var:
- Ansbile kobler seg til Windows-verten via WinRM.
- Ansible kjører et powershell-skript.
- Powershell-skriptet oppretter en ny VM.
- Ved å bruke Hyper-V/ScVMM, når du oppretter en VM i gjeste-OS, konfigureres vertsnavnet.
- Når du oppdaterer DHCP-leieavtalen, sender VM-en vertsnavnet.
- Standard ddns- og dhcp-integrasjon på domenekontrollersiden konfigurerer DNS-posten.
- Du kan legge til en VM i inventaret ditt og konfigurere det med Ansible.
3. Lag VM-mal
De fant ikke opp noe her - de tok en pakker.
- Legg til pakkeren, kickstart config til git-depotet.
- Setter opp en spesiell jenkins-slave med hyper-v og Packer.
- Vi oppretter en jobb og konfigurerer Jenkins.
Slik fungerer denne linken:
- Packer oppretter en tom VM og henter ISO.
- VM starter opp, Packer legger inn kommandoen i oppstartslasteren for å bruke vår kickstart-fil fra en diskett eller http.
- Anaconda lanseres med vår konfigurasjon, og den første OS-konfigurasjonen er ferdig.
- Packer venter på at VM-en blir tilgjengelig.
- Packer inne i VM kjører ansible i lokal modus.
- Ansible bruker nøyaktig de samme rollene som den fungerer i trinn #1.
- Packer eksporterer VM-malen.
Dag #75: Refaktorer avtalen uten å bryte = Test ansible + Testkitchen
Å fange konvensjoner i kode er kanskje ikke nok. Tross alt, hvis du i inn- og utkanten av prosessen ønsker å endre noe, kan du bryte noe. Derfor, når det gjelder infrastruktur, vises testing av nettopp denne infrastrukturen. For å synkronisere kunnskap i teamet begynte vi å teste Ansible-roller. Jeg vil ikke gå i dybden fordi... det er en artikkel som beskriver hendelsene på det tidspunktet (spoiler dette var ikke den endelige versjonen og senere ble alt mer komplisert ).
Dag #130: Kanskje CentOS+ansible ikke er nødvendig? kanskje openshift?
Vi må forstå at prosessen med å innføre infrastruktur ikke var den eneste, og det var sidedelprosjekter. For eksempel kom en forespørsel om å lansere applikasjonen vår i openshift, og dette resulterte i forskning i mer enn én uke som bremset flytteprosessen. Resultatet viste seg at openshift ikke dekker alle behov; du trenger ekte maskinvare, eller i det minste muligheten til å spille med kjernen.
Dag #170: Openshift er ikke egnet, la oss ta en sjanse med Windows Azure Pack?
Hyper-V er ikke veldig vennlig, SCVMM gjør det ikke mye bedre. Men det er noe slikt som Windows Azure Pack, som er et tillegg til SCVMM og etterligner Azure. Men i virkeligheten ser produktet forlatt ut: dokumentasjonen har brutte koblinger og er veldig sparsom. Men som en del av studiet av alternativer for å forenkle livet til skyen vår, så de også på det.
Dag #250: Windows Azure Pack ikke veldig bra. Vi forblir på SCVMM
Windows Azure Pack så lovende ut, men det ble besluttet å ikke bringe WAP med dets kompleksitet inn i systemet av hensyn til unødvendige funksjoner og ble med SCVMM.
Dag #360: Å spise elefanten stykke for stykke
Bare et år senere var plattformen for å flytte til klar og flytteprosessen startet. For dette formålet ble det satt en SMART-oppgave. Vi sjekket ut alle VM-ene og begynte å finne ut konfigurasjonen én etter én, beskrive den i Ansible og dekke den med tester.
Dag #450: Hva slags system fikk du?
Selve prosessen er ikke interessant. Det er rutine, det kan bemerkes at de fleste konfigurasjonene var relativt enkle eller isomorfe og i henhold til Pareto-prinsippet krevde 80 % av VM-konfigurasjonene 20 % av tiden. Etter samme prinsipp ble 80 % av tiden brukt på å forberede flyttingen og bare 20 % på selve flyttingen.
Dag #540: Finale
Hva skjedde på 18 måneder?
- Avtalene ble en kode.
- Manuelt arbeid -> Mekanisering -> Automatisering.
lenker
Kilde: www.habr.com