Tai kalbos stenograma и .
Tai istorija apie projektą, kuriame buvo naudojama savarankiškai parašyta konfigūracijos valdymo sistema ir kodėl perkėlimas į Ansible užtruko 18 mėnesių.
Diena Nr. -ХХХ: Prieš pradžią
Iš pradžių infrastruktūrą sudarė daugybė atskirų kompiuterių, kuriuose veikia „Hyper-V“. Kuriant virtualią mašiną reikėjo daug žingsnių: įdėti diskus į reikiamą vietą, užregistruoti DNS, rezervuoti DHCP, įdėti VM konfigūraciją į git saugyklą. Šis procesas buvo iš dalies mechanizuotas, tačiau, pavyzdžiui, VM tarp kompiuterių buvo paskirstytos rankomis. Tačiau, pavyzdžiui, kūrėjai gali pataisyti VM konfigūraciją git ir pritaikyti ją iš naujo paleisdami VM.
Pasirinktinis konfigūracijos valdymo sprendimas
Įtariu, kad pradinė idėja buvo sumanyta kaip IaC: daugelis be būsenos VM, kurios iš naujo paleidžiamos iš naujo į nulinę būseną. Kas buvo VM konfigūracijos valdymas? Schematiškai tai atrodo paprasta:
- VM buvo nustatytas statinis MAC.
- Prie VM buvo prijungtas ISO su CoreOS ir įkrovos diskas.
- „CoreOS“ paleidžia tinkinimo scenarijų, atsisiųsdama jį iš WEB serverio pagal jo IP.
- Scenarijus atsisiunčia VM konfigūraciją per SCP pagal IP adresą.
- Paleidžiami sistemos vienetų failų ir bash scenarijų audiniai.
Šis sprendimas turėjo daug akivaizdžių problemų:
- „CoreOS ISO“ nebenaudojamas.
- Daug sudėtingų automatizuotų veiksmų ir magijos perkeliant / kuriant VM.
- Sunkumai atnaujinant ir kai reikalinga tam tikra programinės įrangos versija. Dar smagiau su branduolio moduliais.
- VM nebuvo taip gauti be duomenų, t.y. Atsirado VM su disku su papildomais vartotojo duomenimis.
- Kažkas nuolat sugadindavo sistemos vienetų priklausomybes ir „CoreOS“ užšaldavo perkraunant. Tai buvo sunku sugauti naudojant turimus „CoreOS“ įrankius.
- Paslapčių valdymas.
- CM nebuvo. „CoreOS“ buvo „bash“ ir „YML“ konfigūracijos.
Jei norite pritaikyti VM konfigūraciją, turite ją paleisti iš naujo, tačiau ji gali nepaleisti iš naujo. Atrodo akivaizdi problema, bet nėra nuolatinių diskų – nėra kur išsaugoti žurnalų. Na, gerai, pabandykime pridėti branduolio įkėlimo parinktį, kad žurnalai būtų siunčiami. Bet ne, kaip viskas sudėtinga.
0 diena: pripažinkite problemą
Tai buvo įprasta kūrimo infrastruktūra: jenkins, testavimo aplinkos, stebėjimas, registras. CoreOS buvo sukurtas k8s klasterių talpinimui, t.y. problema buvo tai, kaip buvo naudojamas CoreOS. Pirmas žingsnis buvo kamino pasirinkimas. Mes apsigyvenome:
- Centos kaip bazinis paskirstymas, nes Tai artimiausias paskirstymas gamybos aplinkai.
- Galimas konfigūracijos valdymui, nes buvo atlikta išsami jo ekspertizė.
- Jenkins kaip esamų procesų automatizavimo pagrindą, nes jis jau buvo aktyviai naudojamas plėtros procesams
- "Hyper-V" kaip virtualizacijos platforma. Yra nemažai priežasčių, kurios peržengia istorijos ribas, bet trumpai tariant – negalime naudoti debesų, turime naudoti savo aparatūrą.
30 diena: Esamų susitarimų taisymas – Sutartys kaip kodeksas
Kai stackas buvo aiškus, prasidėjo pasiruošimas ėjimui. Esamų susitarimų taisymas kodo forma (Sutartys kaip kodeksas!). Perėjimas fizinis darbas -> mechanizacija -> automatizavimas.
1. Konfigūruokite VM
Ansible tai puikiai atlieka. Atlikdami minimalius kūno judesius, galite valdyti VM konfigūracijas:
- Sukurkite git saugyklą.
- VM sąrašą įtraukėme į inventorių, konfigūracijas į žaidimų knygeles ir vaidmenis.
- Mes nustatome specialų jenkins vergą, iš kurio galite paleisti Ansible.
- Sukuriame darbą ir konfigūruojame Jenkins.
Pirmasis procesas yra paruoštas. Sutartys yra fiksuotos.
2. Sukurkite naują VM
Viskas čia nebuvo labai patogu. Nėra labai patogu kurti VM naudojant „Hyper-V“ iš „Linux“. Vienas iš bandymų mechanizuoti šį procesą buvo:
- „Ansbile“ prisijungia per WinRM prie „Windows“ pagrindinio kompiuterio.
- Ansible vykdo powershell scenarijų.
- Powershell scenarijus sukuria naują VM.
- Naudojant Hyper-V/ScVMM, kuriant VM svečių OS, sukonfigūruojamas pagrindinio kompiuterio pavadinimas.
- Atnaujinant DHCP nuomą, VM siunčia savo pagrindinio kompiuterio pavadinimą.
- Standartinis ddns ir dhcp integravimas domeno valdiklio pusėje sukonfigūruoja DNS įrašą.
- Galite įtraukti VM prie savo inventoriaus ir sukonfigūruoti jį naudodami Ansible.
3. Sukurkite VM šabloną
Jie čia nieko nesugalvojo - paėmė pakuotoją.
- Pridėkite paketuotoją, kickstart konfigūraciją į „git“ saugyklą.
- Specialaus jenkins vergo su hyper-v ir Packer nustatymas.
- Sukuriame darbą ir konfigūruojame Jenkins.
Kaip veikia ši nuoroda:
- Packer sukuria tuščią VM ir paima ISO.
- VM paleidžiamas, paketuotojas įveda komandą į įkrovos įkroviklį, kad naudotų mūsų kickstart failą iš diskelio arba http.
- „Anaconda“ paleidžiama naudojant mūsų konfigūraciją ir atlikta pradinė OS konfigūracija.
- Pakuotojas laukia, kol VM bus pasiekiama.
- Pakuotojas VM viduje veikia vietiniu režimu.
- Ansible naudoja lygiai tuos pačius vaidmenis, kaip ir 1 veiksme.
- Packer eksportuoja VM šabloną.
75 diena: Pakartokite susitarimą nepažeisdami = Išbandyti galima + Testkitchen
Užfiksuoti susitarimus kode gali nepakakti. Galų gale, jei proceso subtilybėse norite ką nors pakeisti, galite ką nors sulaužyti. Todėl infrastruktūros atveju atsiranda būtent šios infrastruktūros testavimas. Norėdami sinchronizuoti žinias komandoje, pradėjome testuoti Ansible vaidmenis. Nesigilinsiu, nes... yra straipsnis, kuriame aprašomi įvykiai tuo metu (spoileris tai nebuvo galutinė versija, o vėliau viskas tapo sudėtingesnė ).
130 diena: gal CentOS+ansible nereikia? gal openshift?
Turime suprasti, kad infrastruktūros diegimo procesas nebuvo vienintelis ir buvo šalutinių paprojekčių. Pavyzdžiui, atėjo užklausa paleisti mūsų programą „Openshift“ ir dėl to tyrimai truko ilgiau nei vieną savaitę kurie sulėtino judėjimo procesą. Rezultatas pasirodė, kad „openshift“ neapima visų poreikių, jums reikia tikros aparatinės įrangos arba bent jau galimybės žaisti su branduoliu.
170 diena: „Openshift“ netinka, rizikuokime su „Windows Azure Pack“?
„Hyper-V“ nėra labai draugiškas, o SCVMM jo nepagerina. Tačiau yra toks dalykas kaip „Windows Azure Pack“, kuris yra SCVMM priedas ir imituoja „Azure“. Tačiau iš tikrųjų produktas atrodo apleistas: dokumentacijoje yra neveikiančių nuorodų ir ji yra labai menka. Tačiau nagrinėdami galimybes supaprastinti mūsų debesies gyvenimą, jie taip pat atsižvelgė į tai.
250 diena: „Windows Azure Pack“ nėra labai geras. Mes liekame SCVMM
„Windows Azure Pack“ atrodė daug žadanti, tačiau dėl nereikalingų funkcijų buvo nuspręsta WAP ir jo sudėtingumo neįtraukti į sistemą ir liko prie SCVMM.
360 diena: dramblio valgymas po gabalėlį
Tik po metų platforma persikėlimui buvo paruošta ir persikraustymo procesas prasidėjo. Šiuo tikslu buvo įdiegta S.M.A.R.T. užduotis. Mes patikrinome visas VM ir pradėjome po vieną išsiaiškinti konfigūraciją, aprašyti ją Ansible ir padengti testais.
450 diena: kokią sistemą gavote?
Pats procesas nėra įdomus. Tai įprasta, galima pastebėti, kad dauguma konfigūracijų buvo gana paprastos arba izomorfinės ir pagal Pareto principą 80% VM konfigūracijų užtrukdavo 20% laiko. Tuo pačiu principu 80% laiko buvo praleista ruošiantis persikėlimui ir tik 20% pačiam judėjimui.
540 diena: finalas
Kas atsitiko per 18 mėnesių?
- Sutartys tapo kodeksu.
- Fizinis darbas -> Mechanizacija -> Automatika.
Nuorodos
Šaltinis: www.habr.com