Ovo je transkript govora и .
Ovo je priča o projektu koji je koristio sistem za upravljanje konfiguracijom koji je sam napisao i zašto je prelazak na Ansible trajao 18 mjeseci.
Dan br. -HHH: Prije početka
U početku se infrastruktura sastojala od mnogo odvojenih hostova koji su pokretali Hyper-V. Kreiranje virtuelne mašine zahtevalo je mnogo koraka: stavljanje diskova na pravo mesto, registrovanje DNS-a, rezervisanje DHCP-a, stavljanje VM konfiguracije u git spremište. Ovaj proces je bio djelimično mehaniziran, ali na primjer, VM-ovi su distribuirani između hostova ručno. Ali, na primjer, programeri bi mogli ispraviti konfiguraciju VM-a u git-u i primijeniti je ponovnim pokretanjem VM-a.
Prilagođeno rješenje za upravljanje konfiguracijom
Pretpostavljam da je prvobitna ideja bila zamišljena kao IaC: mnogi VM-ovi bez državljanstva koji resetuju svoje stanje na nulu kada se ponovo pokrenu. Šta je bilo upravljanje konfiguracijom VM-a? Šematski izgleda jednostavno:
- Statički MAC je prikovan za VM.
- ISO sa CoreOS-om i disk za pokretanje su povezani na VM.
- CoreOS pokreće skriptu za prilagođavanje preuzimanjem sa WEB servera na osnovu IP adrese.
- Skripta preuzima konfiguraciju VM-a preko SCP-a na osnovu IP adrese.
- Pokreće se podnožje sistemskih fajlova jedinica i podnožje bash skripti.
Ovo rješenje je imalo mnogo očiglednih problema:
- CoreOS ISO je zastario.
- Mnogo složenih automatizovanih radnji i magije prilikom migracije/kreiranja VM-a.
- Poteškoće s ažuriranjem i kada je potrebna određena verzija softvera. Još zabavnije sa modulima kernela.
- VM nisu tako dobijeni bez podataka, tj. VM-ovi su se pojavili s diskom s montiranim dodatnim korisničkim podacima.
- Neko je stalno zeznuo ovisnosti o sistemskoj jedinici i CoreOS bi se zamrznuo prilikom ponovnog pokretanja. Bilo je teško uhvatiti ovo koristeći dostupne alate u CoreOS-u.
- Upravljanje tajnama.
- Nije bilo CM. Postojale su bash i YML konfiguracije za CoreOS.
Da biste primijenili konfiguraciju VM-a, morate ga ponovo pokrenuti, ali se možda neće ponovo pokrenuti. Čini se kao očigledan problem, ali nema postojanih diskova - nema gdje sačuvati zapise. Pa, ok, hajde da pokušamo da dodamo opciju učitavanja kernela kako bi se zapisnici slali. Ali ne, kako je sve to komplikovano.
Dan #0: Prepoznajte problem
Bila je to uobičajena razvojna infrastruktura: jenkins, testna okruženja, nadzor, registar. CoreOS je dizajniran za hostovanje k8s klastera, tj. problem je bio kako se koristio CoreOS. Prvi korak je bio odabir steka. Odlučili smo se na:
- CentOS kao baznu distribuciju, jer Ovo je najbliža distribucija proizvodnim okruženjima.
- Ansible za upravljanje konfiguracijom, jer bilo je opsežnog ispitivanja o tome.
- Jenkins kao okvir za automatizaciju postojećih procesa, jer već se aktivno koristi za razvojne procese
- Hyper-V kao platforma za virtuelizaciju. Postoji niz razloga koji prevazilaze okvire priče, ali ukratko – ne možemo koristiti oblake, moramo koristiti vlastiti hardver.
Dan br. 30: Popravljanje postojećih sporazuma - Sporazumi kao kod
Kada je stek bio čist, počele su pripreme za selidbu. Popravljanje postojećih sporazuma u obliku koda (Ugovori kao kod!). Tranzicija ručni rad -> mehanizacija -> automatizacija.
1. Konfigurirajte VM
Ansible to odlično radi. Uz minimum pokreta tijela možete preuzeti kontrolu nad konfiguracijama VM-a:
- Kreirajte git spremište.
- Stavili smo listu VM-a u inventar, konfiguracije u playbooks i uloge.
- Postavljamo poseban jenkins slave iz kojeg možete pokrenuti Ansible.
- Kreiramo posao i konfiguriramo Jenkinsa.
Prvi proces je spreman. Ugovori su fiksni.
2. Kreirajte novi VM
Sve ovdje nije bilo baš zgodno. Nije baš zgodno kreirati VM na Hyper-V iz Linuxa. Jedan od pokušaja mehanizacije ovog procesa bio je:
- Ansbile se povezuje preko WinRM-a na Windows host.
- Ansible pokreće powershell skriptu.
- Powershell skripta kreira novu VM.
- Koristeći Hyper-V/ScVMM, prilikom kreiranja VM-a u gostujućem OS-u, konfiguriše se ime hosta.
- Prilikom ažuriranja DHCP zakupa, VM šalje svoje ime hosta.
- Standardna ddns & dhcp integracija na strani kontrolera domene konfiguriše DNS zapis.
- Možete dodati VM u svoj inventar i konfigurirati ga pomoću Ansiblea.
3. Kreirajte VM šablon
Ovdje nisu ništa izmislili - uzeli su paker.
- Dodajte packer, kickstart konfiguraciju u git spremište.
- Postavljanje posebnog jenkins slave-a sa hyper-v i Packer-om.
- Kreiramo posao i konfiguriramo Jenkinsa.
Kako radi ovaj link:
- Packer kreira prazan VM i preuzima ISO.
- VM se pokreće, Packer unosi komandu u bootloader da koristi našu kickstart datoteku sa diskete ili http.
- Anaconda se pokreće sa našom konfiguracijom, a početna konfiguracija OS-a je urađena.
- Packer čeka da VM postane dostupan.
- Paker unutar VM-a radi ansible u lokalnom načinu.
- Ansible koristi potpuno iste uloge koje radi u koraku #1.
- Packer izvozi VM šablon.
Dan #75: Refaktorirajte sporazum bez prekida = Test ansible + Testkitchen
Hvatanje konvencija u kodu možda neće biti dovoljno. Na kraju krajeva, ako u samom procesu želite nešto promijeniti, možete nešto slomiti. Stoga se u slučaju infrastrukture javlja testiranje upravo ove infrastrukture. Kako bismo sinkronizirali znanje unutar tima, počeli smo testirati Ansible uloge. Neću ulaziti u dubinu jer... postoji članak koji opisuje događaje u tom trenutku (spoiler ovo nije bila konačna verzija i kasnije je sve postalo komplikovanije ).
Dan #130: Možda CentOS+ansible nije potreban? mozda openshift?
Moramo shvatiti da proces uvođenja infrastrukture nije bio jedini i da su postojali sporedni potprojekti. Na primjer, stigao je zahtjev za pokretanje naše aplikacije u openshift-u i to je rezultiralo istraživanjem koje je trajalo više od jedne sedmice što je usporilo proces kretanja. Rezultat se pokazao da openshift ne pokriva sve potrebe; potreban vam je pravi hardver, ili barem mogućnost igranja sa kernelom.
Dan #170: Openshift nije prikladan, hajde da rizikujemo sa Windows Azure paketom?
Hyper-V nije baš prijateljski raspoložen, SCVMM ga ne čini mnogo boljim. Ali postoji nešto kao što je Windows Azure Pack, koji je dodatak SCVMM-u i oponaša Azure. Ali u stvarnosti, proizvod izgleda napušteno: dokumentacija ima prekinute veze i vrlo je rijetka. Ali, kao dio proučavanja opcija za pojednostavljivanje života našeg oblaka, oni su ga također pogledali.
Dan #250: Windows Azure paket nije baš dobar. Ostajemo na SCVMM
Windows Azure Pack je izgledao obećavajuće, ali je odlučeno da se ne unose WAP sa njegovom složenošću u sistem radi nepotrebnih karakteristika i ostao je SCVMM.
Dan #360: Jedenje slona dio po dio
Samo godinu dana kasnije platforma za preseljenje je bila spremna i proces selidbe je počeo. U tu svrhu je instaliran S.M.A.R.T. zadatak. Provjerili smo sve VM-ove i počeli da shvaćamo konfiguraciju jednu po jednu, opisujemo je u Ansibleu i pokrivamo je testovima.
Dan #450: Kakav sistem ste dobili?
Sam proces nije zanimljiv. To je rutinsko, može se primijetiti da je većina konfiguracija bila relativno jednostavna ili izomorfna i prema Pareto principu, 80% VM konfiguracija je zahtijevalo 20% vremena. Po istom principu, 80% vremena je utrošeno na pripremu selidbe, a samo 20% na sam potez.
Dan #540: Finale
Šta se desilo za 18 mjeseci?
- Sporazumi su postali kodeks.
- Ručni rad -> Mehanizacija -> Automatizacija.
Linkovi
izvor: www.habr.com