Tere kõigile. Töötan OK-s juhtiva süsteemiadministraatorina ja vastutan portaali stabiilse toimimise eest. Ma tahan rääkida sellest, kuidas me ehitasime ketaste automaatse asendamise protsessi ja kuidas me administraatori sellest protsessist välja jätsime ja robotiga asendasime.
See artikkel on omamoodi transliteratsioon HighLoad+ 2018. aastal
Ketta asendamise protsessi loomine
Kõigepealt mõned numbrid
OK on hiiglaslik teenus, mida kasutavad miljonid inimesed. Seda teenindab umbes 7 tuhat serverit, mis asuvad 4 erinevas andmekeskuses. Serverid sisaldavad üle 70 tuhande ketta. Kui need üksteise peale laduda, saad üle 1 km kõrguse torni.
Kõvakettad on serverikomponent, mis kõige sagedamini ebaõnnestub. Selliste mahtude juures tuleb meil vahetada umbes 30 ketast nädalas ja sellest protseduurist on saanud mitte eriti meeldiv rutiin.
Juhtumid
Meie ettevõte on võtnud kasutusele täiemahulise intsidentide haldamise. Salvestame iga juhtumi Jiras ning seejärel lahendame ja lahendame selle. Kui intsident avaldas kasutajatele mõju, siis saame kindlasti kokku ja mõtleme, kuidas sellistel puhkudel kiiremini reageerida, kuidas mõju vähendada ja loomulikult vältida selle kordumist.
Salvestusseadmed pole erand. Nende olekut jälgib Zabbix. Jälgime Syslogi sõnumeid kirjutamis-/lugemisvigade suhtes, analüüsime HW/SW raidide olekut, jälgime SMART-i ja arvutame SSD-de kulumist.
Kuidas enne kettaid vahetati
Kui Zabbixis ilmneb päästik, luuakse Jiras intsident ja määratakse see automaatselt andmekeskuste vastavatele inseneridele. Teeme seda kõigi HW intsidentidega, st nendega, mis nõuavad füüsilist tööd andmekeskuse seadmetega.
Andmekeskuse insener on isik, kes lahendab riistvaraga seotud probleeme ning vastutab serverite paigaldamise, hooldamise ja demonteerimise eest. Pärast pileti kättesaamist asub insener tööle. Kettariiulites vahetab ta kettaid iseseisvalt. Kui tal aga vajalikule seadmele ligi ei pääse, pöördub insener abi saamiseks valves olevate süsteemiadministraatorite poole. Kõigepealt peate ketta pöörlemisest eemaldama. Selleks tuleb teha serveris vajalikud muudatused, peatada rakendused ja lahti ühendada ketas.
Kogu portaali toimimise eest töövahetuse ajal vastutab valves olev süsteemiadministraator. Ta uurib juhtumeid, teeb remonti ja aitab arendajatel täita väikseid ülesandeid. Ta ei tegele ainult kõvaketastega.
Varem suhtlesid andmekeskuse insenerid süsteemiadministraatoriga vestluse kaudu. Insenerid saatsid lingid Jira piletitele, administraator jälgis neid, pidas tööpäevikut mõnes märkmikus. Kuid vestlused on selliste ülesannete jaoks ebamugavad: seal olev teave pole struktureeritud ja läheb kiiresti kaduma. Ja administraator võis lihtsalt arvutist eemale kõndida ja mõnda aega mitte vastata päringutele, samal ajal kui insener seisis serveris kettavirnaga ja ootas.
Kõige hullem oli aga see, et administraatorid ei näinud tervikpilti: millised kettaintsidendid olid olemas, kus võib tekkida probleem. See on tingitud asjaolust, et me delegeerime kõik HW juhtumid inseneridele. Jah, kõiki juhtumeid oli võimalik kuvada administraatori armatuurlaual. Kuid neid on palju ja administraator oli seotud ainult mõnega.
Lisaks ei saanud insener prioriteete õigesti seada, sest ta ei tea midagi konkreetsete serverite otstarbest ega teabe jaotusest draivide vahel.
Uus asendusprotseduur
Esimese asjana teisaldasime kõik kettaintsidendid eraldi tüüpi “HW disk” ja lisasime sellele väljad “blokeeri seadme nimi”, “suurus” ja “ketta tüüp”, et see teave salvestataks piletisse ja ei pea vestluses pidevalt vahetama.
Samuti leppisime kokku, et ühe intsidendi jooksul vahetame ainult ühte ketast. See lihtsustas oluliselt automatiseerimisprotsessi, statistika kogumist ja tööd tulevikus.
Lisaks lisasime välja “vastutav administraator”. Sinna lisatakse automaatselt valves olev süsteemiadministraator. See on väga mugav, sest nüüd näeb insener alati, kes vastutab. Pole vaja minna kalendrisse ja otsida. Just see väli võimaldas kuvada administraatori armatuurlaual pileteid, mis võivad vajada tema abi.
Tagamaks, et kõik osalejad saaksid uuendustest maksimaalset kasu, lõime filtrid ja armatuurlauad ning rääkisime neist poistele. Kui inimesed mõistavad muutusi, ei distantseeru nad neist kui millestki ebavajalikust. Inseneril on oluline teada serveri asukohanumbrit, ketta suurust ja tüüpi. Administraator peab ennekõike mõistma, mis serverite grupp see on ja milline võib olla ketta asendamise mõju.
Väljade olemasolu ja nende kuvamine on mugav, kuid see ei päästnud meid vajadusest kasutada vestlusi. Selleks pidime muutma töövoogu.
Varem oli see nii:
Nii jätkavad insenerid täna tööd, kui nad ei vaja administraatori abi.
Esimese asjana tutvustasime uut staatust Uurige. Pilet on selles staatuses, kui insener pole veel otsustanud, kas tal on vaja administraatorit või mitte. Selle oleku kaudu saab insener pileti administraatorile üle anda. Lisaks kasutame seda olekut piletite märgistamiseks, kui ketas vajab vahetamist, kuid ketast ennast kohapeal pole. See juhtub CDN-ide ja kaugsaitide puhul.
Lisasime ka staatuse Valmis. Pilet kantakse sellele peale ketta vahetamist. See tähendab, et kõik on juba tehtud, kuid HW/SW RAID on serveris sünkroonitud. See võib võtta üsna kaua aega.
Kui töösse kaasatakse administraator, läheb skeem veidi keerulisemaks.
Olekust avatud Pileti saavad tõlkida nii süsteemiadministraator kui ka insener. Olekus Pooleli administraator eemaldab ketta pöörlemisest, et insener saaks selle lihtsalt välja tõmmata: lülitab taustvalgustuse sisse, eemaldab ketta, peatab rakendused, olenevalt konkreetsest serverirühmast.
Seejärel kantakse pilet üle Valmis muutma: See on signaal insenerile, et ketta saab välja tõmmata. Jiras on kõik väljad juba täidetud, insener teab, mis tüüpi ja suurusega ketas on. Need andmed sisestatakse kas automaatselt eelmisele olekule või administraatori poolt.
Pärast ketta vahetamist muudetakse pileti olekuks Muudetud. See kontrollib, kas õige ketas on sisestatud, partitsioonid on tehtud, rakendus käivitatakse ja mõned andmete taastamise toimingud. Pileti saab ka olekusse üle kanda Valmis, jääb sel juhul vastutavaks administraator, kuna ta pani ketta pöörlema. Täielik diagramm näeb välja selline.
Uute väljade lisamine muutis meie elu palju lihtsamaks. Poisid hakkasid töötama struktureeritud teabega, sai selgeks, mida ja millises etapis on vaja teha. Prioriteedid on muutunud palju asjakohasemaks, kuna need määrab nüüd administraator.
Vestlusi pole vaja. Loomulikult võib administraator kirjutada insenerile "see tuleb kiiremini välja vahetada" või "on juba õhtu, kas teil on aega see välja vahetada?" Kuid me ei suhtle enam nendel teemadel igapäevaselt vestlustes.
Plaate hakati vahetama partiidena. Kui administraator tuli veidi varem tööle, tal on vaba aega ja midagi pole veel juhtunud, saab ta ette valmistada hulga servereid väljavahetamiseks: täita väljad, eemaldada kettad pöörlemisest ja anda ülesande insenerile. Insener tuleb andmekeskusesse veidi hiljem, näeb ülesannet, võtab laost vajalikud kettad ja vahetab kohe välja. Selle tulemusena on asendusmäär suurenenud.
Töövoo loomisel saadud õppetunnid
- Protseduuri koostamisel peate koguma teavet erinevatest allikatest.
Mõned meie administraatorid ei teadnud, et insener vahetab kettaid ise. Mõned inimesed arvasid, et MD RAID-i sünkroonimisega tegelesid insenerid, kuigi mõnel neist polnud selleks isegi juurdepääsu. Mõned juhtivad insenerid tegid seda, kuid mitte alati, sest protsessi polnud kuskil kirjeldatud. - Menetlus peaks olema lihtne ja arusaadav.
Inimesel on raske mitut sammu silmas pidada. Jira olulisemad naaberolekud tuleks paigutada põhiekraanile. Saate neid ümber nimetada, näiteks kutsume nimeks Käimasolevad muutmiseks valmis. Ja muud olekud saab rippmenüüsse peita, et need silma ei riivaks. Kuid parem on inimesi mitte piirata, vaid anda neile võimalus üleminekuks.
Selgitage innovatsiooni väärtust. Kui inimesed mõistavad, aktsepteerivad nad uut korda rohkem. Meie jaoks oli väga oluline, et inimesed ei klikiks kogu protsessi läbi, vaid järgiksid seda. Seejärel ehitasime sellele automaatika. - Oota, analüüsi, mõtle välja.
Protseduuri, tehnilise teostuse, koosolekute ja arutelude väljaehitamiseks kulus meil umbes kuu. Ja rakendamine võtab rohkem kui kolm kuud. Nägin, kuidas inimesed hakkavad tasapisi uuendust kasutama. Algstaadiumis oli palju negatiivsust. Kuid see oli protseduurist endast ja selle tehnilisest rakendamisest täiesti sõltumatu. Näiteks üks administraator ei kasutanud Jirat, vaid Jira pluginat Confluence’is ja mõned asjad polnud talle kättesaadavad. Näitasime talle Jirat ja administraatori tootlikkus tõusis nii üldiste ülesannete kui ka ketaste vahetamise puhul.
Ketta vahetamise automatiseerimine
Pöördusime mitu korda kettavahetuse automatiseerimise poole. Meil olid juba arendused ja skriptid, kuid need kõik töötasid kas interaktiivselt või käsitsi ja nõudsid käivitamist. Ja alles pärast uue protseduuri juurutamist saime aru, et just see oli see, millest me puudust tunneme.
Kuna nüüd on meie asendusprotsess jagatud etappideks, millest igaühel on konkreetne täitja ja toimingute loend, saame lubada automatiseerimist etappide kaupa, mitte korraga. Näiteks kõige lihtsamat etappi – Ready (RAID/andmete sünkroonimise kontrollimine) saab lihtsalt robotile delegeerida. Kui bot on veidi õppinud, saab talle anda olulisema ülesande - ketta pöörlema panemine vms.
Loomaaia seadistused
Enne kui robotist räägime, teeme lühikese ekskursiooni meie installatsioonide loomaaeda. Esiteks on selle põhjuseks meie infrastruktuuri hiiglaslik suurus. Teiseks proovime valida iga teenuse jaoks optimaalse riistvarakonfiguratsiooni. Meil on umbes 20 riistvaralist RAID-mudelit, enamasti LSI ja Adaptec, kuid on ka HP ja DELL erinevaid versioone. Igal RAID-kontrolleril on oma haldusutiliit. Käskude komplekt ja nende väljastamine võib iga RAID-kontrolleri puhul versiooniti erineda. Kui HW-RAIDi ei kasutata, võib kasutada mdraidi.
Peaaegu kõik uued installid teostame ilma ketta varundamiseta. Püüame enam mitte kasutada riist- ja tarkvara RAID-i, kuna varundame oma süsteeme andmekeskuse, mitte serverite tasemel. Kuid loomulikult on palju pärandservereid, mida tuleb toetada.
Kuskil kantakse RAID-kontrollerites olevad kettad toorseadmetesse, kuskil kasutatakse JBOD-sid. Serveris on ühe süsteemikettaga konfiguratsioonid ja kui see vajab väljavahetamist, siis tuleb server uuesti installeerida koos samade versioonide OS-i ja rakenduste installeerimisega, seejärel lisada konfiguratsioonifailid, käivitada rakendused. Samuti on palju serverirühmi, kus varundamine toimub mitte ketta alamsüsteemi tasemel, vaid otse rakendustes.
Kokku on meil üle 400 unikaalse serverirühma, mis töötavad ligi 100 erineva rakendusega. Sellise tohutu hulga võimaluste katmiseks vajasime multifunktsionaalset automatiseerimistööriista. Soovitavalt lihtsa DSL-iga, et mitte ainult kirjutaja ei saaks seda toetada.
Valisime Ansible, kuna see on agentideta: polnud vaja taristut ette valmistada, kiire algus. Lisaks on see kirjutatud Pythonis, mis on meeskonnasiseselt standardiks aktsepteeritud.
Üldskeem
Vaatame üldist automatiseerimisskeemi, kasutades näitena ühte juhtumit. Zabbix tuvastab, et sdb-kettal tekkis rike, päästik süttib ja Jiras luuakse pilet. Administraator vaatas seda, mõistis, et see ei ole duplikaat ega valepositiivne tulemus, st ketas on vaja vahetada, ja kandis pileti jaotisesse In Progress.
Pythonis kirjutatud DiskoBoti rakendus küsib Jiralt perioodiliselt uusi pileteid. See märkab, et on ilmunud uus Pilet Progress, käivitatakse vastav lõim, mis käivitab Ansible'is mänguraamatu (seda tehakse Jira iga oleku jaoks). Sel juhul käivitatakse Prepare2change.
Ansible saadetakse hostile, eemaldab ketta pöörlemisest ja teatab rakendusele olekust tagasihelistamise kaudu.
Tulemuste põhjal kannab bot automaatselt pileti ümber muutmiseks valmis. Insener saab teatise ja läheb plaati vahetama, misjärel kannab pileti Muudetud.
Ülalkirjeldatud skeemi kohaselt läheb pilet tagasi robotisse, mis käivitab teise mänguraamatu, läheb hosti ja paneb ketta pöörlema. Bot sulgeb pileti. Hurraa!
Nüüd räägime mõnest süsteemi komponendist.
Diskobot
See rakendus on kirjutatud Pythonis. See valib piletid Jirast vastavalt JQL-ile. Viimane läheb olenevalt pileti staatusest vastavale käitlejale, kes omakorda käivitab olekule vastava Ansible mänguraamatu.
JQL ja küsitlusintervallid on määratletud rakenduse konfiguratsioonifailis.
jira_states:
investigate:
jql: '… status = Open and "Disk Size" is EMPTY'
interval: 180
inprogress:
jql: '… and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
ready:
jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
interval: 7200
Näiteks olekuga Käimasolevate piletite hulgast valitakse ainult need, mille väljad Ketta suurus ja Seadme nimi on täidetud. Seadme nimi on mänguraamatu käivitamiseks vajaliku plokiseadme nimi. Ketta suurus on vajalik selleks, et insener teaks, millise suurusega ketast vaja on.
Valmisolekuga piletite hulgast filtreeritakse välja sildiga dbot_ignore piletid. Muide, Jira silte kasutame nii selliseks filtreerimiseks kui ka dubleerivate piletite märgistamiseks ja statistika kogumiseks.
Kui mänguraamat ebaõnnestub, määrab Jira sildi dbot_failed, et seda saaks hiljem lahendada.
Koostalitlusvõime Ansible'iga
Rakendus suhtleb Ansiblega läbi . Dokumendile playbook_executor edastame failinime ja muutujate komplekti. See võimaldab teil hoida Ansible projekti tavaliste yml-failide kujul, mitte seda Pythoni koodis kirjeldada.
Samuti Ansible'is *extra_vars* kaudu blokeerimisseadme nimi, pileti olek, samuti callback_url, mis sisaldab väljalaskevõtit – seda kasutatakse HTTP-s tagasihelistamiseks.
Iga käivitamise jaoks luuakse ajutine inventar, mis koosneb ühest hostist ja rühmast, kuhu see host kuulub, nii et rakendatakse rühma_varid.
Siin on näide HTTP tagasihelistamist rakendavast ülesandest.
Saame mänguraamatute täitmise tulemuse tagasihelistamis(t)e abil. Neid on kahte tüüpi:
- , see annab andmeid mänguraamatu täitmise tulemuste kohta. See kirjeldab käivitatud, edukalt või ebaõnnestunud ülesandeid. Seda tagasihelistamist kutsutakse, kui esitusraamatu esitamine on lõppenud.
- HTTP tagasihelistamine, et saada teavet mänguraamatu esitamise ajal. Ansible ülesandes täidame oma rakendusele POST/GET päringu.
Muutujad edastatakse HTTP-tagasikutsumise kaudu, mis määratleti esitusraamatu täitmise ajal ja mida soovime salvestada ja kasutada järgmistel käitamistel. Kirjutame need andmed sqlite'is.
Samuti jätame kommentaarid ja muudame pileti olekut HTTP tagasihelistamisega.
HTTP tagasihelistamine
# Make callback to Diskobot App
# Variables:
# callback_post_body: # A dict with follow keys. All keys are optional
# msg: If exist it would be posted to Jira as comment
# data: If exist it would be saved in Incident.variables
# desire_state: Set desire_state for incident
# status: If exist Proceed issue to that status
- name: Callback to Diskobot app (jira comment/status)
uri:
url: "{{ callback_url }}/{{ devname }}"
user: "{{ diskobot_user }}"
password: "{{ diskobot_pass }}"
force_basic_auth: True
method: POST
body: "{{ callback_post_body | to_json }}"
body_format: json
delegate_to: 127.0.0.1
Nagu paljud sama tüüpi ülesanded, paneme selle eraldi ühisesse faili ja lisame vajadusel, et mitte mänguraamatutes pidevalt korrata. See hõlmab tagasihelistamise_ URL-i, mis sisaldab probleemi võtit ja hosti nime. Kui Ansible täidab selle POST-i päringu, mõistab bot, et see tuli osana sellisest ja sellisest juhtumist.
Ja siin on näide mänguraamatust, milles väljastame ketta MD-seadmest:
# Save mdadm configuration
- include: common/callback.yml
vars:
callback_post_body:
status: 'Ready to change'
msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
data:
mdadm_data: "{{ mdadm_remove_disk.removed }}"
parted_info: "{{ parted_info | default() }}"
when:
- mdadm_remove_disk | changed
- mdadm_remove_disk.removed
See ülesanne viib Jira pileti olekusse „Muutmiseks valmis” ja lisab kommentaari. Samuti salvestab muutuja mdam_data loendi md-seadmetest, millelt ketas eemaldati, ja parted_info salvestab partitsiooni väljavõtte partitsioonist partitsioonist.
Kui insener sisestab uue ketta, saame neid muutujaid kasutada partitsioonide tõmmise taastamiseks, samuti ketta sisestamiseks md-seadmetesse, kust see eemaldati.
Võimalik kontrollrežiim
Automaatika sisselülitamine oli hirmus. Seetõttu otsustasime käivitada kõik mänguraamatud režiimis
, milles Ansible ei tee serverites mingeid toiminguid, vaid ainult emuleerib neid.
Selline käivitamine toimub läbi eraldi tagasihelistamismooduli ja mänguraamatu täitmise tulemus salvestatakse Jirasse kommentaarina.
Esiteks võimaldas see kontrollida roboti ja mänguraamatute tööd. Teiseks suurendas see administraatorite usaldust roboti vastu.
Kui läbisime valideerimise ja mõistsime, et saate Ansible'i käivitada mitte ainult kuivkäivitusrežiimis, tegime Jiras nupu Run Diskobot, et käivitada sama mänguraamat samade muutujatega samas hostis, kuid tavarežiimis.
Lisaks kasutatakse seda nuppu mänguraamatu taaskäivitamiseks, kui see kokku jookseb.
Mänguraamatute struktuur
Olen juba maininud, et olenevalt Jira pileti staatusest käivitab bot erinevaid mänguraamatuid.
Esiteks on sissepääsu korraldamine palju lihtsam.
Teiseks on see mõnel juhul lihtsalt vajalik.
Näiteks süsteemiketta vahetamisel tuleb esmalt minna juurutussüsteemi, luua ülesanne ja peale õiget juurutamist muutub server ssh-i kaudu ligipääsetavaks ning sinna saab rakenduse rullida. Kui teeksime seda kõike ühes mänguraamatus, ei saaks Ansible seda teha, kuna host pole saadaval.
Me kasutame iga serverirühma jaoks Ansible rolle. Siit näete, kuidas ühes neist on juhend(id) korraldatud.
See on mugav, kuna on kohe selge, kus millised ülesanded asuvad. Main.yml-is, mis on Ansible rolli sisend, saame lihtsalt lisada pileti oleku või kõigile vajalikke üldisi ülesandeid, näiteks identifitseerimise läbimist või märgi saamist.
uurimine.yml
Käitab piletite jaoks olekus Uurimine ja Avatud. Selle mänguraamatu jaoks on kõige olulisem plokkseadme nimi. See teave pole alati kättesaadav.
Selle saamiseks analüüsime Jira kokkuvõtet, viimast väärtust Zabbixi päästikust. See võib sisaldada blokeerimisseadme nime – õnneks. Või võib see sisaldada ühenduspunkti, siis peate minema serverisse, sõeluma selle ja arvutama vajaliku ketta. Päästik võib edastada ka scsi-aadressi või mõnda muud teavet. Kuid juhtub ka nii, et vihjeid pole ja tuleb analüüsida.
Olles teada saanud plokkseadme nime, kogume sellelt teavet ketta tüübi ja suuruse kohta, et täita Jira väljad. Samuti eemaldame teabe müüja, mudeli, püsivara, ID, SMARTi kohta ja sisestame kõik selle Jira pileti kommentaari. Administraator ja insener ei pea enam neid andmeid otsima. 🙂
valmista2muutus.yml
Ketta eemaldamine pöörlemisest, ettevalmistamine asendamiseks. Kõige raskem ja olulisem etapp. Siin saate rakenduse peatada, kui seda ei tohiks peatada. Või võtke välja ketas, millel ei olnud piisavalt koopiaid, ja see mõjutab kasutajaid, kaotades mõned andmed. Siin on meil vestluses kõige rohkem kontrolle ja märguandeid.
Kõige lihtsamal juhul räägime HW/MD RAID-ist ketta eemaldamisest.
Keerulisemates olukordades (meie salvestussüsteemides), kui varundamine toimub rakenduse tasemel, tuleb API kaudu minna rakenduse juurde, teatada ketta väljund, see deaktiveerida ja alustada taastamist.
Nüüd rändame massiliselt sinna ja kui server on pilvepõhine, helistab Diskobot pilve API-le, ütleb, et see töötab selle minioniga - serveriga, mis töötab konteinereid - ja palub "migreerida kõik konteinerid sellelt minionilt". Ja samal ajal lülitab sisse ketta taustvalgustuse, et insener näeks kohe, kumb tuleb välja tõmmata.
muudetud.yml
Pärast ketta vahetamist kontrollime esmalt selle saadavust.
Insenerid ei installi alati uusi draive, seega lisasime kontrolli meid rahuldavate SMART-väärtuste kohta.
Milliseid atribuute me vaatame?Ümberjaotatud sektorite arv (5) < 100
Praegune ootel sektorite arv (107) == 0
Kui ajam ei läbi testi, teatatakse insenerile, et see tuleb uuesti välja vahetada. Kui kõik on korras, lülitub taustvalgus välja, märgistatakse ja plaat pannakse pöörlema.
valmis.yml
Lihtsaim juhtum: HW/SW raid sünkroonimise kontrollimine või andmete sünkroonimise lõpetamine rakenduses.
Rakenduse API
Olen mitu korda maininud, et robot pääseb sageli ligi rakendusliidestele. Loomulikult ei olnud kõigil rakendustel vajalikke meetodeid, mistõttu tuli neid muuta. Siin on kõige olulisemad meetodid, mida kasutame:
- Olek. Klastri või ketta olek, et mõista, kas sellega saab töötada;
- Start/stopp. Ketta aktiveerimine/deaktiveerimine;
- Migreerida/taastada. Andmete migreerimine ja taastamine asendamise ajal ja pärast seda.
Ansible'ilt saadud õppetunnid
Ma tõesti armastan Ansiblet. Kuid sageli, kui ma vaatan erinevaid avatud lähtekoodiga projekte ja näen, kuidas inimesed mänguraamatuid kirjutavad, tekib mul pisut hirm. Millal/loop keerulised loogilised põimumised, paindlikkuse ja idempotentsuse puudumine kesta/käsu sagedase kasutamise tõttu.
Otsustasime kõike nii palju kui võimalik lihtsustada, kasutades ära Ansible eelist – modulaarsust. Kõrgeimal tasemel on mänguraamatud; neid võib kirjutada iga administraator, kolmanda osapoole arendaja, kes tunneb veidi Ansible'i.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Kui mõnda loogikat on mänguraamatutes raske rakendada, teisaldame selle Ansible moodulisse või filtrisse. Skripte saab kirjutada Pythonis või mõnes muus keeles.
Neid on lihtne ja kiire kirjutada. Näiteks ketta taustvalgustuse moodul, mille näide on ülaltoodud, koosneb 265 reast.
Kõige madalamal tasemel on raamatukogu. Selle projekti jaoks kirjutasime eraldi rakenduse, omamoodi abstraktsiooni üle riist- ja tarkvara RAID-ide, mis vastavaid päringuid täidavad.
Ansible'i suurimad tugevused on selle lihtsus ja selged mänguraamatud. Usun, et peate seda kasutama ja mitte genereerima hirmutavaid yaml-faile ja tohutul hulgal tingimusi, kestakoodi ja silmuseid.
Kui soovite korrata meie kogemust Ansible API-ga, pidage meeles kahte asja.
- Playbook_executor ja playbooks üldiselt ei saa anda ajalõpu. Ssh-seansil on ajalõpp, kuid mänguraamatus seda ei ole. Kui proovime lahti ühendada ketta, mida süsteemis enam pole, töötab mänguraamat lõputult, seega pidime selle käivitamise eraldi ümbrisesse mähkima ja ajalõpuga tapma.
- Ansible töötab kahvliga protsessides, nii et selle API pole lõimekindel. Kasutame kõiki oma mänguraamatuid ühe lõimega.
Selle tulemusena saime automatiseerida umbes 80% ketaste asendamise. Üldiselt on asendusmäär kahekordistunud. Täna vaatab administraator lihtsalt juhtunut ja otsustab, kas ketast tuleb vahetada või mitte ning teeb siis ühe klõpsu.
Kuid nüüd hakkame kokku puutuma teise probleemiga: mõned uued administraatorid ei tea, kuidas draive vahetada. 🙂
Allikas: www.habr.com