To je prepis govora и .
To je zgodba o projektu, ki je uporabljal samonapisani sistem za upravljanje konfiguracije in zakaj je prehod na Ansible trajal 18 mesecev.
Dan št. -ХХХ: Pred začetkom
Sprva je bila infrastruktura sestavljena iz številnih ločenih gostiteljev, ki so poganjali Hyper-V. Ustvarjanje virtualnega stroja je zahtevalo veliko korakov: namestitev diskov na pravo mesto, registracija DNS, rezervacija DHCP, namestitev konfiguracije VM v repozitorij git. Ta postopek je bil delno mehaniziran, vendar so bili na primer VM-ji ročno razdeljeni med gostitelje. Toda razvijalci bi lahko na primer popravili konfiguracijo VM v git in jo uporabili s ponovnim zagonom VM.
Rešitev za upravljanje konfiguracije po meri
Domnevam, da je bila prvotna ideja zasnovana kot IaC: veliko navideznih računalnikov brez stanja, ki ob ponovnem zagonu ponastavijo svoje stanje na nič. Kaj je bilo upravljanje konfiguracije VM? Shematično je videti preprosto:
- Za VM je bil določen statični MAC.
- Na VM sta bila povezana ISO s CoreOS in zagonska disketa.
- CoreOS zažene prilagoditveni skript tako, da ga prenese s spletnega strežnika na podlagi njegovega IP-ja.
- Skript prenese konfiguracijo VM prek SCP na podlagi naslova IP.
- Zaženeta se podloga za datoteke sistemske enote in podloga za skripte bash.
Ta rešitev je imela veliko očitnih težav:
- CoreOS ISO je zastarel.
- Veliko zapletenih avtomatiziranih dejanj in čarovnije pri selitvi/ustvarjanju virtualnih strojev.
- Težave s posodabljanjem in kdaj je potrebna določena različica programske opreme. Še več zabave z moduli jedra.
- VM niso bili tako pridobljeni brez podatkov, tj. VM so se pojavili z diskom z nameščenimi dodatnimi uporabniškimi podatki.
- Nekdo je nenehno pokvaril odvisnosti sistemske enote in CoreOS je zamrznil ob ponovnem zagonu. Težko je bilo to ujeti z uporabo razpoložljivih orodij v CoreOS.
- Upravljanje skrivnosti.
- CM ni bilo. Za CoreOS sta bili konfiguraciji bash in YML.
Če želite uporabiti konfiguracijo VM, ga morate znova zagnati, vendar se morda ne bo znova zagnal. Zdi se kot očitna težava, vendar ni trajnih diskov - dnevnikov ni kam shraniti. No, v redu, poskusimo dodati možnost nalaganja jedra, da bodo dnevniki poslani. Ampak ne, kako je vse skupaj zapleteno.
Dan #0: Prepoznajte težavo
Šlo je za običajno razvojno infrastrukturo: jenkins, testna okolja, spremljanje, register. CoreOS je bil zasnovan za gostovanje gruč k8s, tj. problem je bil, kako je bil uporabljen CoreOS. Prvi korak je bila izbira sklada. Odločili smo se za:
- CentOS kot osnovna distribucija, ker To je najbližja distribucija proizvodnim okoljem.
- Možno za upravljanje konfiguracije, saj na njem je bil opravljen obsežen pregled.
- Jenkins kot okvir za avtomatizacijo obstoječih procesov, saj se že aktivno uporablja za razvojne procese
- Hyper-V kot virtualizacijska platforma. Obstaja vrsta razlogov, ki presegajo okvir zgodbe, a na kratko – ne moremo uporabljati oblakov, moramo uporabljati lastno strojno opremo.
Dan št. 30: Popravljanje obstoječih dogovorov - Dogovori kot koda
Ko je bil sklad prazen, so se začele priprave na selitev. Popravek obstoječih dogovorov v obliki kode (Sporazumi kot kodeks!). Prehod ročno delo -> mehanizacija -> avtomatizacijo.
1. Konfigurirajte VM
Ansible to odlično opravi. Z najmanj premiki telesa lahko prevzamete nadzor nad konfiguracijami VM:
- Ustvarite repozitorij git.
- Seznam navideznih strojev damo v inventar, konfiguracije v priročnike in vloge.
- Postavljamo poseben suženj Jenkins, iz katerega lahko poganjate Ansible.
- Ustvarimo delovno mesto in konfiguriramo Jenkins.
Prvi postopek je pripravljen. Dogovori so fiksni.
2. Ustvarite nov VM
Vse tukaj ni bilo zelo priročno. Ustvarjanje navideznih strojev na Hyper-V iz Linuxa ni zelo priročno. Eden od poskusov mehanizacije tega procesa je bil:
- Ansbile se prek WinRM poveže z gostiteljem Windows.
- Ansible zažene skript powershell.
- Skript Powershell ustvari nov VM.
- Z uporabo Hyper-V/ScVMM je pri ustvarjanju VM v gostujočem OS konfigurirano ime gostitelja.
- Pri posodabljanju zakupa DHCP VM pošlje svoje ime gostitelja.
- Standardna integracija ddns & dhcp na strani krmilnika domene konfigurira zapis DNS.
- V svoj inventar lahko dodate VM in ga konfigurirate z Ansible.
3.Ustvarite predlogo VM
Tukaj si niso ničesar izmislili - vzeli so embalaže.
- Dodajte konfiguracijo pakirnika, kickstart v repozitorij git.
- Nastavitev posebnega suženjskega strežnika Jenkins s Hyper-V in Packerjem.
- Ustvarimo delovno mesto in konfiguriramo Jenkins.
Kako deluje ta povezava:
- Packer ustvari prazen VM in pobere ISO.
- VM se zažene, Packer vnese ukaz v zagonski nalagalnik za uporabo naše zagonske datoteke z diskete ali http.
- Anaconda se zažene z našo konfiguracijo in začetna konfiguracija OS je končana.
- Packer čaka, da postane VM na voljo.
- Packer znotraj VM teče ansible v lokalnem načinu.
- Ansible uporablja popolnoma enake vloge kot v 1. koraku.
- Packer izvozi predlogo VM.
Dan #75: Preoblikujte sporazum, ne da bi ga zlomili = Test ansible + Testkitchen
Zajemanje konvencij v kodo morda ne bo dovolj. Konec koncev, če želite nekaj spremeniti v notranjosti procesa, lahko nekaj pokvarite. Zato se pri infrastrukturi pojavlja testiranje prav te infrastrukture. Za sinhronizacijo znanja znotraj ekipe smo začeli testirati vloge Ansible. Ne bom šel v globino, ker ... obstaja članek, ki opisuje dogodke v tistem trenutku (spoiler to ni bila končna verzija in kasneje je postalo vse bolj zapleteno ).
Dan #130: Mogoče CentOS+ansible ni potreben? mogoče openshift?
Zavedati se moramo, da proces uvajanja infrastrukture ni bil edini in so bili stranski podprojekti. Prišla je na primer zahteva za zagon naše aplikacije v openshiftu, kar je povzročilo več kot en teden raziskovanja kar je upočasnilo premikanje. Izkazalo se je, da openshift ne pokriva vseh potreb, potrebujete pravo strojno opremo ali vsaj sposobnost igranja z jedrom.
Dan #170: Openshift ni primeren, tvegajmo z Windows Azure Pack?
Hyper-V ni zelo prijazen, SCVMM ga ne izboljša veliko. Obstaja pa nekaj takega, kot je Windows Azure Pack, ki je dodatek k SCVMM in posnema Azure. Toda v resnici je izdelek videti zapuščen: dokumentacija ima prekinjene povezave in je zelo redka. Toda v okviru študije možnosti za poenostavitev življenja našega oblaka so si ogledali tudi to.
Dan #250: Windows Azure Pack ni zelo dober. Ostajamo na SCVMM
Windows Azure Pack je bil videti obetaven, vendar je bilo odločeno, da se WAP s svojo zapletenostjo ne bo vnesel v sistem zaradi nepotrebnih funkcij in je ostal pri SCVMM.
Dan #360: Jesti slona kos za kosom
Šele leto kasneje je bila pripravljena ploščad za selitev in začela se je selitev. V ta namen je bil nameščen S.M.A.R.T. naloga. Preverili smo vse VM-je in začeli ugotavljati konfiguracijo enega za drugim, ga opisali v Ansibleu in pokrili s testi.
Dan #450: Kakšen sistem ste dobili?
Sam proces ni zanimiv. To je rutina, lahko opazimo, da je bila večina konfiguracij razmeroma enostavnih ali izomorfnih in po Paretovem principu je 80 % konfiguracij VM zahtevalo 20 % časa. Po enakem principu je bilo 80% časa porabljenega za pripravo selitve in le 20% za selitev samo.
Dan #540: Finale
Kaj se je zgodilo v 18 mesecih?
- Sporazumi so postali kodeks.
- Ročno delo -> Mehanizacija -> Avtomatizacija.
Moj meni
Vir: www.habr.com