Aceasta este o transcriere a discursului и .
Aceasta este povestea unui proiect care a folosit un sistem de management al configurației scris de sine și de ce mutarea la Ansible a durat 18 luni.
Ziua nr. -ХХХ: Înainte de început
Inițial, infrastructura a constat din multe gazde separate care rulau Hyper-V. Crearea unei mașini virtuale a necesitat mulți pași: punerea discurilor la locul potrivit, înregistrarea DNS, rezervarea DHCP, punerea configurației VM în depozitul git. Acest proces a fost parțial mecanizat, dar, de exemplu, VM-urile au fost distribuite manual între gazde. Dar, de exemplu, dezvoltatorii ar putea corecta configurația VM în git și o pot aplica prin repornirea VM.
Soluție de gestionare a configurației personalizate
Ideea originală, bănuiesc, a fost concepută ca IaC: multe mașini virtuale fără stat care își resetează starea la zero când sunt repornite. Ce a fost managementul configurației VM? Schematic pare simplu:
- Un MAC static a fost pus în cuie pentru VM.
- Un ISO cu CoreOS și un disc de pornire au fost conectate la VM.
- CoreOS lansează scriptul de personalizare prin descărcarea acestuia de pe serverul WEB pe baza IP-ului său.
- Scriptul descarcă configurația VM prin SCP pe baza adresei IP.
- Se lansează panoul de bază al fișierelor unitare systemd și cel al scripturilor bash.
Această soluție a avut multe probleme evidente:
- CoreOS ISO a fost depreciat.
- O mulțime de acțiuni automate complexe și magie la migrarea/crearea de VM.
- Dificultate cu actualizarea și când este necesară o anumită versiune de software. Și mai distractiv cu modulele kernel.
- VM-urile nu au fost astfel obținute fără date, de exemplu. VM-urile au apărut cu un disc cu date suplimentare de utilizator montate.
- Cineva strica constant dependențele unității de sistem și CoreOS se bloca la repornire. A fost dificil să înțelegi acest lucru folosind instrumentele disponibile în CoreOS.
- Managementul secretelor.
- Nu a existat CM. Au existat configurații bash și YML pentru CoreOS.
Pentru a aplica configurația VM, trebuie să o reporniți, dar este posibil să nu repornească. Pare o problemă evidentă, dar nu există discuri persistente - nu există unde să salvezi jurnalele. Ei bine, bine, să încercăm să adăugăm opțiunea de încărcare a nucleului, astfel încât jurnalele să fie trimise. Dar nu, cât de complicat este totul.
Ziua #0: Recunoașteți problema
Era infrastructura obișnuită de dezvoltare: jenkins, medii de testare, monitorizare, registry. CoreOS a fost conceput pentru a găzdui clustere k8s, de exemplu. problema a fost cum a fost folosit CoreOS. Primul pas a fost alegerea unei stive. Ne-am hotărât pe:
- CentOS ca distributie de baza, deoarece Aceasta este cea mai apropiată distribuție de mediile de producție.
- ansiblu pentru managementul configurației, deoarece s-a făcut o examinare amplă asupra ei.
- Jenkins ca un cadru de automatizare a proceselor existente, deoarece a fost deja utilizat în mod activ pentru procesele de dezvoltare
- Hyper-V ca platformă de virtualizare. Există o serie de motive care depășesc domeniul de aplicare al poveștii, dar pe scurt - nu putem folosi norii, trebuie să folosim propriul nostru hardware.
Ziua nr. 30: Fixarea acordurilor existente - Acordurile ca Cod
Când stiva a fost liberă, au început pregătirile pentru mutare. Fixarea acordurilor existente sub formă de cod (Acordurile ca cod!). Tranziție muncă manuală -> mecanizare -> automatizare.
1. Configurați VM-uri
Ansible face o treabă grozavă în acest sens. Cu un minim de mișcări ale corpului, puteți prelua controlul asupra configurațiilor VM:
- Creați un depozit git.
- Am pus lista de VM-uri în inventar, configurații în playbook-uri și roluri.
- Înființăm un sclav special Jenkins din care poți rula Ansible.
- Creăm un loc de muncă și configurăm Jenkins.
Primul proces este gata. Acordurile sunt fixe.
2. Creați un nou VM
Totul aici nu a fost foarte convenabil. Nu este foarte convenabil să creați VM-uri pe Hyper-V din Linux. Una dintre încercările de mecanizare a acestui proces a fost:
- Ansbile se conectează prin WinRM la gazda Windows.
- Ansible rulează un script powershell.
- Scriptul Powershell creează o nouă VM.
- Folosind Hyper-V/ScVMM, atunci când se creează o VM în sistemul de operare invitat, numele de gazdă este configurat.
- La actualizarea contractului de închiriere DHCP, VM-ul își trimite numele de gazdă.
- Integrarea standard ddns și dhcp pe partea controlerului de domeniu configurează înregistrarea DNS.
- Puteți adăuga un VM la inventarul dvs. și îl puteți configura cu Ansible.
3.Creați șablonul VM
Nu au inventat nimic aici - au luat un ambalator.
- Adăugați configurația packer, kickstart în depozitul git.
- Crearea unui sclav special Jenkins cu hyper-v și Packer.
- Creăm un loc de muncă și configurăm Jenkins.
Cum funcționează acest link:
- Packer creează un VM gol și preia ISO.
- VM pornește, Packer introduce comanda în bootloader pentru a utiliza fișierul nostru kickstart de pe o dischetă sau http.
- Anaconda este lansat cu configurația noastră și configurarea inițială a sistemului de operare este făcută.
- Packer așteaptă ca VM-ul să devină disponibil.
- Packer în interiorul VM rulează ansible în modul local.
- Ansible folosește exact aceleași roluri pe care le lucrează la pasul #1.
- Packer exportă șablonul VM.
Ziua #75: Refactorizează acordul fără a se rupe = Test ansible + Testkitchen
Capturarea convențiilor în cod poate să nu fie suficientă. La urma urmei, dacă în dedesubturile procesului vrei să schimbi ceva, poți rupe ceva. Prin urmare, în cazul infrastructurii, apare chiar testarea acestei infrastructuri. Pentru a sincroniza cunoștințele în cadrul echipei, am început să testăm rolurile Ansible. Nu voi intra în profunzime pentru că... există un articol care descrie evenimentele din acel moment (spoiler aceasta nu a fost versiunea finală și mai târziu totul a devenit mai complicat ).
Ziua #130: Poate că CentOS+ansible nu este necesar? poate shift deschis?
Trebuie să înțelegem că procesul de introducere a infrastructurii nu a fost singurul și au existat subproiecte secundare. De exemplu, a venit o solicitare de lansare a aplicației noastre în shift deschis și acest lucru a dus la cercetare pentru mai mult de o săptămână care a încetinit procesul de mișcare. Rezultatul s-a dovedit că openshift nu acoperă toate nevoile; aveți nevoie de hardware real sau cel puțin de capacitatea de a juca cu nucleul.
Ziua #170: Openshift nu este potrivit, să riscăm cu Windows Azure Pack?
Hyper-V nu este foarte prietenos, SCVMM nu o face cu mult mai bună. Dar există un astfel de lucru precum Windows Azure Pack, care este un supliment pentru SCVMM și imită Azure. Dar, în realitate, produsul pare abandonat: documentația are legături rupte și este foarte rară. Dar, ca parte a studiului opțiunilor pentru simplificarea vieții cloud-ului nostru, au analizat și ei.
Ziua #250: Pachetul Windows Azure nu este foarte bun. Rămânem pe SCVMM
Windows Azure Pack părea promițător, dar s-a decis să nu aducă WAP cu complexitățile sale în sistem de dragul funcțiilor inutile și a rămas cu SCVMM.
Ziua #360: Mâncarea elefantului bucată cu bucată
Doar un an mai târziu, platforma pentru mutare a fost gata și procesul de mutare a început. În acest scop a fost instalat S.M.A.R.T. sarcină. Am verificat toate VM-urile și am început să descoperim configurația una câte una, să o descriem în Ansible și să o acoperim cu teste.
Ziua #450: Ce fel de sistem ai primit?
Procesul în sine nu este interesant. Este de rutină, se poate observa că majoritatea configurațiilor au fost relativ simple sau izomorfe și conform principiului Pareto, 80% din configurațiile VM au necesitat 20% din timp. După același principiu, 80% din timp a fost petrecut pregătind mutarea și doar 20% mișcarea în sine.
Ziua #540: Finala
Ce s-a întâmplat în 18 luni?
- Acordurile au devenit un cod.
- Muncă manuală -> Mecanizare -> Automatizare.
Link-uri
Sursa: www.habr.com