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

See on ettekande kokkuvõte DevopsConf 2019-10-01 ja SPbLUG 2019-09-25.

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

Päev № -XXX: Enne algust

Alguses koosnes infrastruktuur paljusid eraldiseisvaid hoste, mille haldamiseks kasutati Hyper-V. Virtuaalse masina loomine nõudis hulgaliselt toiminguid: kettad õigesse kohta panna, DNS määrata, DHCP reserveerida, VM-i konfiguratsioon git-repositooriumisse panna. See protsess oli osaliselt mehhaniseeritud, kuid näiteks VM-id jagati hostide vahel käsitsi. Kuid näiteks arendajad said VM-i konfiguratsiooni git-is muutes selle taastada VM-i taaskäivitamisega.

Kohandatud konfiguratsioonihalduse lahendus

Algne idee, kahtlustan, pidi olema nagu IaC: hulk state'ita VM-e, mis taaskäivitamisel oma oleku nulliks. Kuidas nägi välja VM-i konfiguratsiooni haldamine? Koonduvalt näeb see lihtne välja:

1. VM-idele kinnitati staatiline MAC.
2. VM-idele ühendati ISO koos CoreOS-i ja laadimisdiskiga.
3. CoreOS käivitab kohandamisskripti, laadides selle WEB-serverist alla oma IP-aadressi alusel.
4. Skript tõmbab SCP kaudu alla VM-i konfiguratsiooni, tuginedes IP-aadressile.
5. Käivituvad systemd üksuste failide jadad ja bash-skriptide jadad.

Sellel lahendusel oli mitu ilmset probleemi:

1. ISO CoreOS-is oli vananenud.
2. Palju keerukaid automatiseeritud toiminguid ja maagiat VM-i migreerimisel/loomisel.
3. Uuendamisega oli keeruline, eriti kui konkreetses versioonis tarkvara vajati. Veelgi keerulisem oli tuumamoodulitega.
4. VM-id ei olnud sugugi andmeta, st ilmusid VM-id, millel oli täiendavalt ühendatud kett kasutajate andmetega.
5. Keegi tegi pidevalt vigu systemd üksuste sõltuvustega ja CoreOS-i taaskäivitamisel hangus see. Olemasolevate vahenditega oli CoreOS-is seda probleemset tuvastada keeruline.
6. Salajaste andmete haldamine.
7. CM ei olnud praktiliselt olemas. Oli bash ja CoreOS-i YML konfiguratsioonid.

VM-i konfiguratsiooni rakendamiseks on vajalik selle taaskäivitamine, kuid see ei pruugi taaskäivituda. Tundub ilmne probleem, kuid püsivad kettad puuduvad — logisid pole kuhugi salvestada. Noh, proovime lisada kernelibootimise valikuid, et logid edastataks. Kuid ei, kõik tundub nii keeruline.

Päev nr 0: Probleemi tunnustamine

See oli tavaline arenduse infrastruktuur: jenkins, testkeskkonnad, jälgimised, registry. CoreOS mõeldi k8s klastrite hostimiseks, st probleem seisnes selles, kuidas CoreOS'i kasutati. Esimene samm oli steigi valimine. Otsustasime:

1. CentOS kas aluseks olev distributsi, kuna see on kõige lähedasem tootmisringkondadele.
2. Ansible konfiguratsioonide haldamiseks, kuna selle kohta oli ulatuslikku ekspertiisi.
3. Jenkins olemasolevate protsesside automatiseerimise raamistiku näol, kuna seda kasutati juba aktiivselt arendusprotsessides.
4. Hyper-V virtualiseerimise platvormina. On mitmeid põhjuseid, mis ületavad selle jutu, kuid lühidalt — me ei saa kasutada pilvi, peame kasutama oma riistvara.

Päev №30: Salvestame olemasolevad lepped — Agreements as Code

Kui steik oli selge, algas ettevalmistus kolimiseks. Olemasolevate lepingute salvestamine koodina (Agreements as Code!). Üleminek käte töö -> mehhaniseerimine -> automatiseerimine.

1. Konfigureeri virtuaalmasinad

Ansible teeb selle ülesande suurepäraselt. Minimalsete pingutustega saab hallata VM-de konfiguratsioone:

1. Loome git reposti.
2. Kogume VM-id inventari, konfiguratsioonid playbookidesse ja rollidesse.
3. Seame üles spetsiaalse Jenkins slave'i, millelt on võimalik Ansible'i käivitada.
4. Loome töö, seadistame Jenkinsit.

Esimene protsess on valmis. Kokku lepingud on kinnitatud.

2. Looge uus VM

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

1. Ansible ühendub WinRM kaudu Windowsi hostiga.
2. Ansible käivitab PowerShell skripti.
3. PowerShell skript loob uue VM-i.
4. Hyper-V/ScVMM abil, kui VM-i luuakse, on külalis-OS-is seadistatud hostname.
5. VM saadab DHCP lease'i uuendamisel oma hostname'i.
6. DDNS ja DHCP standardne integreerimine Domain Controller'i poolest seadistab DNS kirje.
7. VM-e saab lisada inventari ja seadistada nende Ansible'i.

3. Looge VM-i mall

Siin ei hakanud me midagi leiutama — võtsime Packer'i.

1. Paneme Git reposse Packer'i ja kickstarti konfi.
2. Seame üles spetsiaalse Jenkins slave'i Hyper-V ja Packer'i jaoks.
3. Loome töö, seadistame Jenkinsit.

Kuidas see kombinatsioon töötab:

1. Packer loob tühja VM-i ning ühendab ISO.
2. VM käivitub, Packer annab käskluse kasutada meie kickstart faili ketasel või http kaudu.
3. Käivitub Anaconda koos meie konfiguuri, tehakse OS-i esialgne seadistamine.
4. Packer ootab VM-i kättesaadavust.
5. Packer VM sees ansible running in local mode.
6. Ansible uses exactly the same roles as in step №1.
7. Packer exports the VM template.

Day №75: Refactoring agreements without breaking = Test ansible + Testkitchen

Simply fixing the agreements in code may not be enough. If during the process you want to change something, you might break something. Therefore, infrastructure testing becomes essential. To synchronize knowledge within the team, we started testing Ansible roles. I won't go into detail as there is an article describing the events at that time. Test me if you can, or do YML programmers dream of testing ansible?(spoiler, this was not the final version and things got more complicated later) How to start testing Ansible, refactor a project in a year, and not lose your mind.).

Day №130: Maybe CentOS+ansible isn't needed? Maybe openshift?

It's important to understand that the infrastructure integration process wasn't the only one, and there were side projects. For instance, a request came to run our application in openshift, which led to research lasting more than a week. Käivitame rakenduse Openshiftis ja võrdleme olemasolevat tööriistade komplekti mis pidurdas kolimise protsessi. Tulemuseks oli, et openshift ei katnud kõiki vajadusi, vajalik on reaalne riistvara või vähemalt võimalus mängida tuumaga.

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

Hyper-V ei ole eriti sõbralik, SCVMM ei tee sellest palju paremat. Kuid on olemas selline asi nagu Windows Azure Pack, mis on SCVMM-i pealne ja matkib Azure'i. Kuid tegelikkuses näeb toode välja mahajäetud: dokumentatsioon on katkenud linkidega ja üsna vaene. Kuid meie pilve elu lihtsustamise võimaluste uurimisel vaatasime ka seda.

Päev №250: Windows Azure Pack ei ole väga hea. Jätkame SCVMM-is.

Windows Azure Pack nägi välja paljutõotav, kuid otsustasime mitte tuua WAP-i koos selle raskustega süsteemi, et vältida tarbetuid funktsioone, ja jäime SCVMM-i.

Päev №360: Söödame elevanti tükkhaaval

Ainult aasta pärast oli platvorm valmis, kuhu kolida, ja kolimisprotsess algas. Selleks seati eesmärgiks S.M.A.R.T. ülesanne. Kirjutasime üles kõik virtuaalsed masinad ja hakkasime üksikult nende konfiguratsiooniga tegelema, kirjeldama seda Ansible'is, katma testidega.

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

Protsess ise ei ole huvitav. See on rutiinne, võib märkida, et enamus konfiguratsioone olid suhteliselt lihtsad või isomorfsed ning Pareto põhimõtte kohaselt nõudis 80% konfiguratsioone 20% ajast. Sama printsiibi kohaselt kulus 80% ajast ettevalmistamiseks ja ainult 20% üleviimiseks.

Päev nr 540: Finaal

Mis siis 18 kuu jooksul juhtus?

1. Kokkulepped muutusid koodiks.
2. Käsitöö -> Mehaanizatsioon -> Automatiseerimine.

Lingid

• Inglise versioon
• Ristpostitus isiklikust blogist
• esitlused
• How to start testing Ansible, refactor a project in a year, and not lose your mind.
• Kogemused üle 200 000 rea infrastruktuuri koodist testimisel
• Laseme juurutada OpenShiftisse
• Kuidas testida oma operatsioonisüsteemi distributsiooni
• Küsi minult, kui saad. Kas YML arendajad unistavad ansible'i testimisest?

Allikas: habr.com