🥇Ansible: Konfiguratsiooni migreerimine 120 VM-i CoreOS-lt CentOS-ile 18 kuu jooksul

See esitluse tõlgendus DevopsConf 2019-10-01 ja SPbLUG 2019-09-25.

See on projekti lugu, kus kasutati kohandatud konfiguratsioonihalduse süsteemi ja miks üleminek Ansible'ile venis 18 kuud.

Päev № -ХХХ: Enne algust

Algne infrastruktuur koosnes paljuski eraldiseisvatest hostidest, mida haldas Hyper-V. Virtuaalmachine'i loomine nõudis palju samme: diskide paigutamine õigesse kohta, DNS-i seadistamine, DHCP reservatsioonide tegemine ja VM konfiguratsiooni salvestamine git-iga. See protsess oli osaliselt mehhaniseeritud, kuid näiteks VM-id jaotati hostide vahel käsitsi. Kuid arendajad said VM-i konfiguratsiooni git-iga muutes rakendada seda VM-i taaskäivitamise kaudu.

Kohandatud konfiguratsioonihalduse lahendus

Algne idee, kahtlustan, oli mõeldud nagu IaC: hulk staateless VM-e, mis lähtestavad oma oleku pärast taaskäivitamist. Kuidas siis tundus VM-ide konfiguratsiooni haldamine? Skeemiliselt näeb see lihtne välja:

VM-idele määrati staatiline MAC.
VM-ile ühendati ISO CoreOS ja käivitusdisk.
CoreOS käivitab kohandamise skripti, laadides selle alla veebiserverist vastavalt oma IP-le.
Skript tõmbab läbi SCP VM konfiguratsiooni, lähtudes IP-aadressist.
Käivitub hulk systemd unit faile ja rida bash skripte.

Sellel lahendusel oli palju ilmselgeid probleeme:

ISO CoreOS-is oli deprecated.
Palju keerulisi automatiseeritud toiminguid ja maagia VM-ide migreerimisel/loomisel.
Probleem uuendamisel ja kui vajalik on teatud versiooni tarkvara. Veelgi keerulisem oli tuumamoodulite puhul.
VM-id ei olnud nii andmeteta, st ilmusid VM-id, millel oli lisaks monteeritud kettad kasutajate andmetega.
Keegi eksis pidevalt systemd uniti sõltuvustega ja CoreOS hangus taaskäivitamisel. Käesolevad vahendid CoreOS-is selle tabamiseks olid problemaatilised.
Salajase haldamine.
CM ei olnud sisuliselt olemas. Oli bash ja YML konfiguratsioonid CoreOS-is.

Kuna VM-i konfiguratsiooni rakendamiseks tuleb seda taaskäivitada, võis see mitte taaskäivituda. Tundub, et see on ilmne probleem, kuid püsiandmeid pole – logisid ei saa säilitada. No hästi, proovime lisada kernelilaadimisvalikuid, et logid edastataks. Kuid ei, see on kõik nii keeruline.

Päev №0: Probleemi tunnustamine

See oli tavaline arenduste infrastruktuur: jenkins, testkeskkonnad, jälgimised, registrid. CoreOS oli mõeldud k8s-klastrite majutamiseks, st probleem oli selles, kuidas CoreOS'i kasutati. Esimene samm oli steki valimine. Peatusime:

CentOS kui põhijagamine, kuna see on kõige lähemal tootmisreaktsioonidele.
Ansible konfiguratsioonide haldamiseks, kuna selle kohta oli suur ekspertteave.
Jenkinsile automaatika raamistikuna olemasolevate protsesside jaoks, kuna seda kasutati juba aktiivselt arendusprotsesside jaoks.
Hyper-V virtualiseerimise platvormina. On mitmeid põhjuseid, mis ületavad jutustamise ulatust, kuid lühidalt - me ei saa kasutada pilvi, peame kasutama oma riistvara.

Päev nr 30: Fikseerime olemasolevad kokkulepped - Agreements as Code

Kui stek oli selge, algas üleviimise ettevalmistamine. Olemasolevate kokkulepetega koodina fikseerimine (Agreements as Code!). Üleminek käsitöö -> mehhaniseerimine -> automaatika.

1. Konfigureeri VM-id

Ansible teeb selle töö suurepäraselt ära. Minimaalse vaevaga saab hallata VM-i konfiguratsioone:

Loo git-repositoorium.
Paigutame VM-ide nimekirja inventuuri, konfiguratsioonid mängude ja rollidena.
Seadistame spetsiaalse jenkins slave'i, mille kaudu saab ansible'it käivitada.
Loome töö, seadistame Jenkins'i.

Esimene protsess on valmis. Kokkulepped on fikseeritud.

2. Loo uus VM

Siin polnud kõik väga mugav. Linuxist oli ebamugav luua VM-e Hyper-V-s. Üks katse selle protsessi mehhaniseerimiseks oli:

Ansible ühendub WinRM kaudu Windowsi hostiga.
Ansible käivitab powershell skripti.
Powershell skript loob uue VM.
Hyper-V/ScVMM vahenditega seadistatakse vm-i loomisel külgoperatsioonis hostname.
VM saadab uuendades DHCP lease oma hostname'i.
Eramud integreerimine ddns & dhcp Domaanikontrolleri poole seadistab DNS-i kirje.
VM-id saab lisada inventuuri ja nende anabse'it seadistada.

3. Loo VM-i mall

Siin ei hakatud midagi leiutama - võeti packer.

Git-repositooriumisse paneme packer'i konfi ja kickstart'i.
Seadistame spetsiaalse jenkins slave'i hyper-v ja Packer'iga.
Loome töö, seadistame Jenkins'i.

Kuidas see kombinatsioon töötab:

Packer loob tühja VM-i, ühendab ISO-d.
VM käivitub, Packer annab laadimisprogrammile käsu kasutada meie kickstart faili diskettidelt või http-st.
Anaconda käivitub meie konfiguratsiooniga, tehakse algseadistus OS-ile.
Packer ootab VM-i kättesaadavust.
Packer käivitab VM-is ansible'i kohalikus režiimis.
Ansible kasutab samu rolle nagu 1. sammus.
Packer ekspordib VM-i šablooni.

Päev №75: Refaktoreerime kokkuleppeid, rikkumata = Testi ansible + Testkitchen

Kokkulepete koodiks fikseerimine võib olla ebapiisav. Kui sa tahad protsessi käigus midagi muuta – võid midagi purustada. Seetõttu ilmneb infrastruktuuri testimise vajadus. Meie tiimis, et teadmisi sünkroniseerida, hakkasime testima Ansible rolle. Ei hakka süvitsi minema, sest on artikkel, mis kirjeldab tol ajal toimunud sündmusi. Proovi mind, kui suudad, või unistavad YML-programmeerijad ansible'i testimisest?(spoiler: see ei olnud lõplik variant ja hiljem läks kõik keerulisemaks) Kuidas alustada Ansible'i testimist, refaktoreerida projekt aasta jooksul ja mitte ära hinge jääda.).

Päev №130: Kas CentOS+ansible polegi vajalik? Äkki openshift?

Tuleb mõista, et infrastruktuuri kaasamise protsess ei olnud ainus ja tekkis kõrvalprojekte. Näiteks saime taotluse meie rakenduse käivitamiseks openshiftis ja see kujunes välja uuringuteks, mis kestsid üle nädala. Käivitame rakenduse Openshiftis ja võrdleme olemasolevat tööriistade komplekti. mis aeglustas ülemineku protsessi. Tulemuseks selgus, et openshift ei kata kõiki vajadusi, vajalik on reaalne riistvara, või vähemalt võimalus tuuma katsetamiseks.

Päev №170: Openshift ei sobi, kas riskime Windows Azure Packiga?

Hyper-V ei ole just sõbralik, SCVMM ei tee seda palju paremaks. Kuid olemas on selline asi nagu Windows Azure Pack, mis on SCVMM-i pealiskonstruktsioon ja jäljendab Azure'i. Kuid tegelikkuses näeb toode välja mahajäetud: dokumentatsioon katkendlike linkidega ja üsna napp. Kuid meie pilve elu lihtsustamise valikute uurimise raames vaatasime ka seda.

Päev №250: Windows Azure Pack ei ole just parim. Jääme SCVMM-ile.

Windows Azure Pack nägi välja paljutõotav, kuid otsustati mitte tuua WAP-i oma süsteemi selle keerukustega tarbetute funktsioonide tõttu ja jääda SCVMM-ile.

Päev №360: Sööme elevanti tükkide kaupa.

Alles aasta pärast oli platvorm, kuhu kolida, valmis ja algas ülemineku protsess. Selleks pandi paika S.M.A.R.T. ülesanne. Kõik VM-id loetleti ja hakati üks haaval nende konfigureerimisega tegelema, kirjeldama seda Ansible'is ning katma testidega.

Päev №450: Milline süsteem välja kujunes?

Protsess ise ei ole huvitav. See on rutiinne, võib märkida, et enamik konfiguratsioone olid suhteliselt lihtsad või isomorfsed ja Pareto printsiibi järgi läks 80% konfiguratsioonide jaoks 20% ajast. Sama printsiibi kohaselt kulus 80% ajast koristustööde ettevalmistamiseks ja ainult 20% ise kolimiseks.