Dit is 'n transkripsie van die toespraak и .
Dit is die verhaal van 'n projek wat 'n selfgeskrewe konfigurasiebestuurstelsel gebruik het en waarom die skuif na Ansible 18 maande geneem het.
Dag No. -ХХХ: Voor die begin
Aanvanklik het die infrastruktuur bestaan uit baie afsonderlike gashere wat Hyper-V gebruik. Die skep van 'n virtuele masjien het baie stappe vereis: om die skywe op die regte plek te plaas, DNS te registreer, DHCP te bespreek, die VM-konfigurasie in die git-bewaarplek te plaas. Hierdie proses is gedeeltelik gemeganiseer, maar byvoorbeeld, VM's is met die hand tussen gashere versprei. Maar ontwikkelaars kan byvoorbeeld die VM-konfigurasie in git regstel en dit toepas deur die VM te herlaai.
Pasgemaakte konfigurasiebestuuroplossing
Die oorspronklike idee, vermoed ek, is opgevat as IaC: baie staatlose VM's wat hul toestand na nul terugstel wanneer dit herlaai word. Wat was VM-konfigurasiebestuur? Skematies lyk dit eenvoudig:
- 'n Statiese MAC is vasgenael vir die VM.
- 'n ISO met CoreOS en 'n selflaaiskyf is aan die VM gekoppel.
- CoreOS begin die aanpassingskrip deur dit van die WEB-bediener af te laai gebaseer op sy IP.
- Die skrip laai die VM-konfigurasie af via SCP gebaseer op die IP-adres.
- Die voetdoek van systemd-eenheidlêers en die voetdoek van bash-skrifte word bekendgestel.
Hierdie oplossing het baie ooglopende probleme gehad:
- CoreOS ISO is opgeskort.
- Baie komplekse outomatiese aksies en magie wanneer VM's migreer/skep.
- Probleme met opdatering en wanneer 'n sekere weergawe van sagteware benodig word. Selfs meer pret met kernmodules.
- VM'e is nie so verkry sonder data nie, m.a.w. VM's het verskyn met 'n skyf met bykomende gebruikersdata gemonteer.
- Iemand was voortdurend besig om die systemd-eenheidafhanklikhede op te skroef en CoreOS sou vries wanneer dit herlaai word. Dit was moeilik om dit op te vang met behulp van die beskikbare gereedskap in CoreOS.
- Geheime bestuur.
- Daar was geen CM nie. Daar was bash- en YML-konfigurasies vir CoreOS.
Om die VM-konfigurasie toe te pas, moet jy dit herlaai, maar dit sal dalk nie herlaai nie. Dit lyk na 'n ooglopende probleem, maar daar is geen aanhoudende skywe nie - daar is nêrens om logs te stoor nie. Wel, ok, kom ons probeer om die kernlaai-opsie by te voeg sodat die logs gestuur sal word. Maar nee, hoe ingewikkeld is dit alles.
Dag #0: Herken die probleem
Dit was die gewone ontwikkelingsinfrastruktuur: jenkins, toetsomgewings, monitering, register. CoreOS is ontwerp om k8s-klusters te huisves, d.w.s. die probleem was hoe CoreOS gebruik is. Die eerste stap was om 'n stapel te kies. Ons het besluit om:
- CentOS as 'n basis verspreiding, want Dit is die naaste verspreiding aan produksie-omgewings.
- Ansible vir konfigurasiebestuur, want daar was uitgebreide ondersoeke daaroor.
- Jenkins as 'n raamwerk vir die outomatisering van bestaande prosesse, want dit is reeds aktief vir ontwikkelingsprosesse gebruik
- Hyper-V as 'n virtualiseringsplatform. Daar is 'n aantal redes wat buite die bestek van die storie gaan, maar kortliks - ons kan nie die wolke gebruik nie, ons moet ons eie hardeware gebruik.
Dag No. 30: Regstelling van bestaande ooreenkomste - Ooreenkomste as Kode
Toe die stapel skoon was, het voorbereidings vir die skuif begin. Regstelling van bestaande ooreenkomste in die vorm van kode (Ooreenkomste as Kode!). Oorgang hande arbeid -> meganisasie -> outomatisering.
1. Stel VM's op
Ansible doen goeie werk hiermee. Met 'n minimum van liggaamsbewegings kan jy beheer neem van VM-konfigurasies:
- Skep 'n git-bewaarplek.
- Ons plaas die lys van VM's in voorraad, konfigurasies in speelboeke en rolle.
- Ons stel 'n spesiale jenkins-slaaf op waaruit jy Ansible kan bestuur.
- Ons skep 'n werk en stel Jenkins in.
Die eerste proses is gereed. Die ooreenkomste is vas.
2. Skep nuwe VM
Alles hier was nie baie gerieflik nie. Dit is nie baie gerieflik om VM's op Hyper-V vanaf Linux te skep nie. Een van die pogings om hierdie proses te meganiseer was:
- Ansbile verbind via WinRM aan die Windows-gasheer.
- Ansible loop 'n powershell-skrip.
- Powershell-skrip skep 'n nuwe VM.
- Deur Hyper-V/ScVMM te gebruik, word die gasheernaam gekonfigureer wanneer 'n VM in die gasbedryfstelsel geskep word.
- Wanneer die DHCP-huurkontrak opgedateer word, stuur die VM sy gasheernaam.
- Standaard ddns en dhcp-integrasie aan die domeinbeheerder-kant konfigureer die DNS-rekord.
- Jy kan 'n VM by jou voorraad voeg en dit met Ansible konfigureer.
3. Skep VM-sjabloon
Hulle het niks hier uitgedink nie - hulle het 'n pakker geneem.
- Voeg die pakker, kickstart config by die git-bewaarplek.
- Die opstel van 'n spesiale jenkins-slaaf met hyper-v en Packer.
- Ons skep 'n werk en stel Jenkins in.
Hoe hierdie skakel werk:
- Packer skep 'n leë VM en tel die ISO op.
- Die VM boots, Packer voer die opdrag in die selflaaiprogram in om ons kickstart-lêer vanaf 'n disket of http te gebruik.
- Anaconda word met ons konfigurasie bekendgestel, en die aanvanklike OS-konfigurasie is gedoen.
- Packer wag vir die VM om beskikbaar te word.
- Packer binne die VM loop moontlik in plaaslike modus.
- Ansible gebruik presies dieselfde rolle as wat dit in stap #1 werk.
- Packer voer die VM-sjabloon uit.
Dag #75: Refaktoreer die ooreenkoms sonder om te breek = Toets ansible + Toetskombuis
Die vaslegging van konvensies in kode is dalk nie genoeg nie. Na alles, as jy in die ins en outs van die proses iets wil verander, kan jy iets breek. Daarom, in die geval van infrastruktuur, verskyn toetsing van hierdie einste infrastruktuur. Om kennis binne die span te sinchroniseer, het ons Ansible-rolle begin toets. Ek gaan nie in die diepte in nie, want... daar is 'n artikel wat die gebeure op daardie tydstip beskryf (spoiler dit was nie die finale weergawe nie en later het alles meer ingewikkeld geword ).
Dag #130: Dalk is CentOS+ansible nie nodig nie? dalk oopskuif?
Ons moet verstaan dat die proses om infrastruktuur bekend te stel nie die enigste een was nie en daar was sy subprojekte. Daar het byvoorbeeld 'n versoek gekom om ons toepassing in openshift bekend te stel en dit het navorsing vir meer as een week tot gevolg gehad wat die bewegingsproses vertraag het. Die resultaat het geblyk dat openshift nie alle behoeftes dek nie; jy benodig regte hardeware, of ten minste die vermoë om met die kern te speel.
Dag #170: Openshift is nie geskik nie, laat ons 'n kans waag met Windows Azure Pack?
Hyper-V is nie baie vriendelik nie, SCVMM maak dit nie veel beter nie. Maar daar is iets soos Windows Azure Pack, wat 'n byvoeging tot SCVMM is en Azure naboots. Maar in werklikheid lyk die produk verlate: die dokumentasie het gebreekte skakels en is baie yl. Maar as deel van die studie van opsies om die lewe van ons wolk te vereenvoudig, het hulle ook daarna gekyk.
Dag #250: Windows Azure Pack nie baie goed nie. Ons bly op SCVMM
Windows Azure Pack het belowend gelyk, maar daar is besluit om nie WAP met sy kompleksiteite in die stelsel in te bring ter wille van onnodige kenmerke nie en het by SCVMM gebly.
Dag #360: Eet die olifant stukkie vir stukkie
Slegs 'n jaar later was die platform vir verhuising gereed en het die verhuisingsproses begin. Vir hierdie doel is 'n SMART taak opgestel. Ons het al die VM's nagegaan en begin om die konfigurasie een vir een uit te vind, dit in Ansible te beskryf en dit met toetse te bedek.
Dag #450: Watter soort stelsel het jy gekry?
Die proses self is nie interessant nie. Dit is roetine, daar kan opgemerk word dat die meeste van die konfigurasies relatief eenvoudig of isomorfies was en volgens die Pareto-beginsel het 80% van die VM-konfigurasies 20% van die tyd benodig. Volgens dieselfde beginsel is 80% van die tyd bestee aan die voorbereiding van die skuif en slegs 20% aan die skuif self.
Dag #540: Finaal
Wat het in 18 maande gebeur?
- Die ooreenkomste het 'n kode geword.
- Hande arbeid -> Meganisasie -> outomatisering.
verlaat
Bron: will.com