🥇Ansible: Migrarea configurației a 120 VM de la CoreOS la CentOS în 18 luni

Aceasta este transcrierea prezentării de la DevopsConf 2019-10-01 și SPbLUG 2019-09-25.

Aceasta este povestea proiectului care a folosit un sistem de gestionare a configurațiilor personalizat și de ce migrarea pe Ansible a durat 18 luni.

Ziua № -XXX: Înainte de început

Inițial, infrastructura consta dintr-o mulțime de servere independente gestionate de Hyper-V. Crearea unei mașini virtuale necesita numeroase acțiuni: a plasa discurile în locul corect, a configura DNS-ul, a rezerva DHCP-ul, a plasa configurația VM într-un repository Git. Acest proces era parțial mecanizat, dar de exemplu, VM-urile erau distribuite manual între servere. De exemplu, dezvoltatorii puteau modifica configurația VM în Git și să o aplice repornind VM-ul.

Soluție personalizată de gestionare a configurației

Ideea inițială, suspectez eu, a fost gândită ca IaC: o mulțime de VM-uri stateless, care își resetau starea la repornire. Cum se desfășura gestionarea configurației VM-urilor? Schema părea simplă:

Pentru VM-uri erau configurate MAC-uri statice.
Se conecta un ISO la VM cu CoreOS și un disc de boot.
CoreOS rulează un script de personalizare descărcându-l de pe serverul WEB pe baza adresei sale IP.
Scriptul descarcă prin SCP configurația VM-ului bazându-se pe adresa IP.
Se lansează o serie de fișiere unitate systemd și o serie de scripturi bash.

Această soluție avea multe probleme evidente:

ISO în CoreOS fusese depreciat.
Numeroase acțiuni dificil de automatizat și magie în timpul migrației/creării VM-urilor.
Dificultăți cu actualizarea și când era necesar un software de o anumită versiune. Era și mai complicat cu modulele kernel.
VM-urile nu erau tocmai fără date, adică au apărut VM-uri cu un disc montat cu date utilizator.
Continuau să existe probleme cu dependențele unităților systemd și CoreOS se bloca la repornire. Era problemă să depistezi asta cu instrumentele existente în CoreOS.
Gestionarea secretelor.
CM nu exista, practic. Era bash și fișiere de configurare YML pentru CoreOS.

Pentru a aplica configurația VM-ului, era nevoie de o repornire, dar aceasta putea să nu se repornească. O problemă aparent evidentă, dar nu există discuri persistente - nu aveai unde să salvezi jurnalele. Bine, să încercăm să adăugăm opțiuni de boot pentru a trimite jurnalele. Dar nu, cât de complicat e totul.

Ziua №0: Recunoașterea problemei

Aceasta era o infrastructură de dezvoltare obișnuită: jenkins, medii de testare, monitorizare, registry. CoreOS a fost conceput pentru găzduirea clusterelor k8s, adică problema a fost modul în care era utilizat CoreOS. Primul pas a fost alegerea stivei. Ne-am oprit la:

CentOS ca distribuție de bază, deoarece este cea mai apropiată distribuție de medii de producție.
Ansible pentru gestionarea configurațiilor, deoarece exista o expertiză extinsă pe acest subiect.
Jenkins ca un cadru de automatizare a proceselor existente, deoarece deja era folosit activ pentru procesele de dezvoltare
Hyper-V ca platformă de virtualizare. Există o serie de motive dincolo de cele povestite, dar pe scurt — nu putem utiliza soluții cloud, trebuie să folosim hardware-ul nostru.

Ziua #30: Documentăm acordurile existente — Agreements as Code

Odată ce stiva a fost clară, a început pregătirea pentru migrare. Documentarea acordurilor existente sub formă de cod (Agreements as Code!). Trecerea muncă manuală -> mecanizare -> automatizarea.

1. Configurează VM-uri

Ansible se descurcă excelent cu această sarcină. Cu un minim de efort, putem gestiona configurațiile VM-urilor:

Creăm un repository git.
Adunăm lista VM-urilor în inventory, configurațiile în playbook-uri și roluri.
Configurăm un slave Jenkins special de pe care putem rula ansible.
Creăm un job, configurăm Jenkins.

Primul proces este gata. Acordurile au fost documentate.

2. Creează un nou VM

Aici nu era foarte confortabil. Din Linux nu era foarte ușor să creăm VM-uri pe Hyper-V. Una dintre încercările de a mecaniza acest proces a fost:

Ansible se conectează prin WinRM la gazda Windows.
Ansible rulează un script PowerShell.
Scriptul PowerShell creează un nou VM.
Prin intermediul Hyper-V/ScVMM, la crearea VM-ului pe OS-ul gazdă se configurează hostname-ul.
VM-ul, la actualizarea lease-ului DHCP, trimite hostname-ul său.
Integrarea standard ddns & dhcp pe partea Domain Controller configurează înregistrarea DNS.
Se pot adăuga VM-uri în inventory și se poate configura Ansible pentru acestea.

3. Creează un template de VM

Aici nu am inventat nimic — am folosit packer.

În repository-ul git, adăugăm configurația packer, kickstart.
Configurăm un slave Jenkins special cu hyper-v și Packer.
Creăm un job, configurăm Jenkins.

Cum funcționează această combinație:

Packer creează un VM gol, atașează ISO.
VM-ul se încarcă, Packer introduce în bootloader comanda de a folosi fișierul nostru kickstart de pe dischetă sau http.
Se lansează anaconda cu configurația noastră, se face configurarea inițială a OS-ului.
Packer așteaptă disponibilitatea VM-ului.
Packer rulează ansible în modul local în interiorul VM-ului.
Ansible folosește exact aceleași roluri ca în pasul nr. 1.
Packer exportă un șablon de VM.

Ziua nr. 75: Refactorizăm convențiile fără a strica = Testă ansible + Testkitchen

A fixa convențiile în cod poate să nu fie suficient. De fapt, dacă în procesul intern vrei să schimbi ceva, s-ar putea să strici ceva. De aceea, în cazul infrastructurii, apare nevoia de a testa această infrastructură. Pentru a sincroniza cunoștințele în cadrul echipei, am început să testăm rolurile Ansible. Nu vreau să aprofundez, deoarece există un articol care descrie evenimentele din acel moment. Testează-mă dacă poți sau visează programatorii YML la testarea ansible?(spoiler, aceasta nu a fost versiunea finală și mai târziu totul a devenit mai complicat) Cum să începi să testezi Ansible, să refactorizezi un proiect într-un an fără a pierde controlul.).

Ziua nr. 130: Poate că CentOS + ansible nu este necesar? Poate openshift?

Trebuie să înțelegem că procesul de încorporare a infrastructurii nu a fost singurul și au fost subproiecte secundare. De exemplu, a apărut o solicitare pentru a rula aplicația noastră pe openshift și aceasta s-a transformat într-o cercetare de mai multe săptămâni. Rulăm aplicația în Openshift și comparăm instrumentele existente. ce a încetinit procesul de mutare. Concluzia a fost că openshift nu satisface toate nevoile, este nevoie de hardware real sau cel puțin de posibilitatea de a experimenta cu nucleul.

Ziua nr. 170: Openshift nu se potrivește, riscă să încercăm cu Windows Azure Pack?

Hyper-V nu este foarte prietenos, SCVMM nu îl îmbunătățește prea mult. Dar există un lucru numit Windows Azure Pack, care este un addon pentru SCVMM și imită Azure. Dar, în realitate, produsul pare abandonat: documentația conține linkuri rupte și este destul de sărăcăcioasă. Dar în cadrul cercetării soluțiilor pentru a simplifica viața norului nostru, l-am analizat și pe acesta.

Ziua nr. 250: Windows Azure Pack nu este prea bun. Rămânem pe SCVMM.

Windows Azure Pack părea promițător, dar s-a decis să nu introducem WAP cu dificultățile sale în sistem pentru caracteristici inutile, așa că am rămas pe SCVMM.

Ziua nr. 360: Mâncăm elefantul pe bucăți.

Numai după un an a fost pregătită platforma unde să ne mutăm și a început procesul de mutare. Pentru aceasta, a fost stabilită o sarcină S.M.A.R.T. Am listat toate VM-urile și am început să ne ocupăm de configurarea lor, să o descriem în Ansible și să o acoperim cu teste.

Ziua nr. 450: Ce sistem a rezultat?

Procesul în sine nu este interesant. Este rutinier, se poate observa că majoritatea configurațiilor au fost relativ simple sau izomorfe și, conform principiului Pareto, 80% din configurații au necesitat 20% din timp. În același fel, 80% din timp a fost alocat pregătirii mutării și doar 20% pentru mutare în sine.

Ziua nr. 540: Finalul

Ce s-a întâmplat în 18 luni?

Acordurile au devenit cod.
Muncă manuală -> Mecanizarea -> Automatizarea.

Linkuri

Sursa: habr.com