See on kõne ärakiri и .
See on lugu projektist, mis kasutas ise kirjutatud konfiguratsioonihaldussüsteemi ja miks Ansible'i üleminek võttis aega 18 kuud.
Päev nr -ХХХ: Enne algust
Algselt koosnes infrastruktuur paljudest eraldi hostidest, mis käitasid Hyper-V-d. Virtuaalse masina loomine nõudis mitmeid samme: ketaste õigesse kohta paigutamine, DNS registreerimine, DHCP reserveerimine, VM konfiguratsiooni git repositooriumisse panemine. See protsess oli osaliselt mehhaniseeritud, kuid näiteks VM-id jaotati hostide vahel käsitsi. Kuid näiteks võivad arendajad parandada VM-i konfiguratsiooni gitis ja rakendada seda VM-i taaskäivitamisega.
Kohandatud konfiguratsioonihalduslahendus
Arvan, et algne idee loodi IaC-na: paljud olekuta VM-id, mis lähtestavad taaskäivitamisel oma oleku nulli. Mis oli VM-i konfiguratsioonihaldus? Skemaatiliselt tundub see lihtne:
- VM-i jaoks naelutati staatiline MAC.
- VM-iga ühendati CoreOS-iga ISO ja alglaadimisketas.
- CoreOS käivitab kohandamisskripti, laadides selle alla veebiserverist selle IP alusel.
- Skript laadib IP-aadressi põhjal alla VM-i konfiguratsiooni SCP kaudu.
- Käivitatakse systemd-üksuse failide jalalapp ja bash-skriptide jalalapp.
Sellel lahendusel oli palju ilmseid probleeme:
- CoreOS ISO tugi on aegunud.
- VM-ide migreerimisel/loomisel palju keerulisi automatiseeritud toiminguid ja maagiat.
- Raskused värskendamisel ja kui on vaja teatud tarkvaraversiooni. Kerneli moodulitega veelgi lõbusam.
- VM-e ei saadud nii ilma andmeteta, st. VM-id ilmusid kettaga, millele oli paigaldatud täiendavad kasutajaandmed.
- Keegi keeras pidevalt süsteemiüksuse sõltuvusi üles ja CoreOS külmutas taaskäivitamisel. CoreOS-is saadaolevate tööriistade abil oli seda raske tabada.
- Saladuste haldamine.
- CM-i ei olnud. CoreOS-i jaoks olid bash ja YML konfiguratsioonid.
VM-i konfiguratsiooni rakendamiseks peate selle taaskäivitama, kuid see ei pruugi taaskäivitada. Tundub ilmselge probleem, kuid püsivaid kettaid pole - logisid pole kuhugi salvestada. Noh, ok, proovime lisada kerneli laadimise võimaluse, et logid saadetakse. Aga ei, kui keeruline see kõik on.
Päev nr 0: teadvustage probleem
See oli tavaline arendustaristu: jenkinid, testkeskkonnad, monitooring, register. CoreOS oli mõeldud k8s klastrite majutamiseks, st. probleem oli selles, kuidas CoreOS-i kasutati. Esimene samm oli virna valimine. Leppisime kokku:
- CentOS baasjaotusena, sest See on tootmiskeskkondadele lähim jaotus.
- Võimalik konfiguratsiooni haldamiseks, sest selle kohta tehti põhjalik uurimine.
- Jenkins raamistikuna olemasolevate protsesside automatiseerimiseks, sest seda on arendusprotsessides juba aktiivselt kasutatud
- Hyper-V virtualiseerimisplatvormina. On mitmeid põhjuseid, mis lähevad loo raamest välja, aga lühidalt – me ei saa kasutada pilvi, me peame kasutama oma riistvara.
Päev nr 30: Olemasolevate lepingute fikseerimine – Lepingud kui koodeks
Kui stäkk selge, algasid kolimise ettevalmistused. Olemasolevate lepingute parandamine koodi kujul (Lepingud koodina!). Üleminek käsitsitöö -> mehhaniseerimine -> automatiseerimine.
1. VM-ide seadistamine
Ansible saab sellega suurepäraselt hakkama. Minimaalsete kehaliigutustega saate VM-i konfiguratsioone juhtida.
- Looge git-hoidla.
- Panime VM-ide loendi inventari, konfiguratsioonid mänguraamatutesse ja rollidesse.
- Seadistame spetsiaalse jenkinsi orja, millest saate Ansible'i käivitada.
- Loome töökoha ja konfigureerime Jenkinsi.
Esimene protsess on valmis. Kokkulepped on fikseeritud.
2. Looge uus VM
Kõik siin ei olnud eriti mugav. Linuxist Hyper-V peal VM-e luua pole kuigi mugav. Üks katsetest seda protsessi mehhaniseerida oli:
- Ansbile ühendub WinRM-i kaudu Windowsi hostiga.
- Ansible käitab powershelli skripti.
- Powershelli skript loob uue VM-i.
- Kasutades Hyper-V/ScVMM-i, konfigureeritakse külaliste OS-is VM-i loomisel hostinimi.
- DHCP-liisingu värskendamisel saadab VM oma hostinime.
- Standardne ddns & dhcp integratsioon domeenikontrolleri poolel konfigureerib DNS-kirje.
- Saate lisada oma laoseisule VM-i ja konfigureerida selle rakendusega Ansible.
3. Looge VM-mall
Nad ei leiutanud siin midagi - nad võtsid pakkija.
- Lisage pakkija, käivitage konfiguratsioon git-hoidlasse.
- Spetsiaalse jenkinsi orja seadistamine koos hyper-v ja Packeriga.
- Loome töökoha ja konfigureerime Jenkinsi.
Kuidas see link töötab:
- Packer loob tühja VM-i ja valib ISO.
- VM käivitub, Packer sisestab alglaadurisse käsu, et kasutada meie kickstart-faili disketilt või http-lt.
- Anaconda käivitatakse meie konfiguratsiooniga ja OS-i esialgne konfiguratsioon on tehtud.
- Packer ootab, kuni VM on saadaval.
- VM-i sees olev pakkija töötab kohalikus režiimis.
- Ansible kasutab täpselt samu rolle, mida ta töötab toimingus nr 1.
- Packer ekspordib VM-i malli.
75. päev: muutke kokkulepet rikkumata = katsetage võimalik + Testköök
Konventsioonide hõivamisest koodis ei pruugi piisata. Lõppude lõpuks, kui protsessi läbi ja lõhki tahate midagi muuta, võite midagi katki teha. Seetõttu ilmneb infrastruktuuri puhul just selle infrastruktuuri testimine. Meeskonnas teadmiste sünkroonimiseks alustasime Ansible rollide testimist. Ma ei hakka süvenema, sest... on artikkel, mis kirjeldab sündmusi sel ajahetkel (spoiler, see ei olnud lõplik versioon ja hiljem muutus kõik keerulisemaks ).
Päev nr 130: võib-olla pole CentOS+ansible'i vaja? äkki openshift?
Peame mõistma, et taristu juurutamise protsess polnud ainuke ja seal oli kõrvalalaprojekte. Näiteks tuli taotlus käivitada meie rakendus openshiftis ja selle tulemuseks oli üle ühe nädala kestnud uurimistöö mis aeglustas liikumisprotsessi. Tulemuseks selgus, et openshift ei kata kõiki vajadusi, vaja on päris riistvara või vähemalt kerneliga mängimise võimalust.
Päev #170: Openshift ei sobi, kas võtame võimaluse Windows Azure Packiga?
Hyper-V ei ole väga sõbralik, SCVMM ei tee seda palju paremaks. Kuid on olemas selline asi nagu Windows Azure Pack, mis on SCVMM-i lisand ja jäljendab Azure'i. Kuid tegelikkuses näeb toode välja hüljatud: dokumentatsioonis on katkised lingid ja see on väga hõre. Kuid meie pilve eluea lihtsustamise võimaluste uurimise raames vaatasid nad ka seda.
Päev 250: Windows Azure Pack pole eriti hea. Jääme SCVMM-i juurde
Windows Azure Pack tundus paljulubav, kuid otsustati mittevajalike funktsioonide huvides WAP-i koos selle keerukusega süsteemi tuua ja jäi SCVMM-i juurde.
Päev 360: elevandi söömine tükkhaaval
Alles aasta hiljem oli kolimise platvorm valmis ja kolimisprotsess algas. Selleks paigaldati S.M.A.R.T. ülesanne. Vaatasime kõik VM-id üle ja hakkasime ükshaaval konfiguratsiooni välja mõtlema, Ansibles kirjeldama ja testidega katma.
Päev 450: Millise süsteemi sa said?
Protsess ise pole huvitav. See on rutiinne, võib märkida, et enamik konfiguratsioone olid suhteliselt lihtsad või isomorfsed ja Pareto põhimõtte kohaselt nõudis 80% VM-i konfiguratsioonidest 20% ajast. Samal põhimõttel kulus 80% ajast kolimise ettevalmistamisele ja ainult 20% liikumisele endale.
Päev #540: finaal
Mis juhtus 18 kuu jooksul?
- Kokkulepetest sai koodeks.
- Käsitöö -> Mehhaniseerimine -> Automaatika.
Lingid
Allikas: www.habr.com