Tere kõigile. Ma töötan peamise süsteemiadministraatorina O.K.-s ja vastutan portaali stabiilse töötamise eest. Soovin rääkida, kuidas me oleme üles ehitanud automaatse ketaste vahetamise protsessi ning seejärel, kuidas me eemaldasime selle protsessist administraatori ja asendasime ta robotiga.
See artikkel on teatud mõttes transkriptsioon HighLoad+ 2018-l
Ketaste vahetamise protsessi tõhususe ülesehitamine
Esiteks mõned numbrid
O.K. on hiiglaslik teenus, mida kasutavad miljonid inimesed. Seda teenindab umbes 7000 serverit, mis asuvad neljas erinevas andmekeskuses. Serverites on üle 70 000 ketta. Kui need üksteise peale laduda, saame üle 1 km kõrge torni.
Ketad on serveri komponent, mis laguneb kõige sagedamini. Selliste suurte mahtude korral peame iga nädal vahetama umbes 30 ketast, ja see protseduur on muutunud üsna ebameeldivaks rutiiniks.
Intsidentide
Meie firmas on kehtestatud täielik probleemihaldus. Iga probleem fikseeritakse Jira-s, seejärel lahendame ja arutame seda. Kui probleemil on mõju kasutajatele, koguneme kindlasti ja mõtleme, kuidas kiiresti sellistes olukordades reageerida, kuidas vähendada mõju ja muidugi, kuidas vältida kordumist.
Kettad pole erand. Nende seisundi jälgimist teostab Zabbix. Jälgime Syslog-s kirjutamise/loetavuse vigu, analüüsime HW/SW-raidide seisukorda, jälgime SMART-i ja SSD-de kulumist.
Kuidas kettad varem vahetati
Kui Zabbixis süttib mõni käivitus, genereeritakse Jira-s probleem ja see määratakse automaatselt vastavatele inseneridele andmekeskustes. Teeme seda kõigi riistvara probleemidega, ehk siis sellistega, mis nõuavad füüsilist tööd seadmete kallal andmekeskuses.
Andmekeskuse insener on inimene, kes lahendab küsimusi, mis on seotud riistvaraga, vastutab serverite paigaldamise, hoolduse ja demonteerimise eest. Pärast päringu saamist asub insener tööle. Ketaste riiulites vahetab ta kettad iseseisvalt. Kuid kui tal puudub juurdepääs vajalikele seadmetele, pöördub insener abi saamiseks ööpäevara turvaseadmestike administraatorite poole. Esiteks tuleb ketas välja rotaatsioonist eemaldada. Selleks tuleb teha vajalikud muudatused serveris, peatada rakendused, eemaldada ketas.
Vahetuses olev süsteemiadministraator vastutab kogu portaali töö eest. Ta uurib juhtumeid, tegeleb parandamisega, aitab arendajaid väikeste ülesannete täitmisel. Ta ei tegele ainult kõvakettastega.
Varem suhtlesid andmekeskuse insenerid süsteemiadministraatoriga vestluses. Insenerid saatsid linke Jira-piletitele, administraator läks neid vaatama ja haldas töölõike mingisuguses märkmete raamatus. Kuid selliste ülesannete jaoks ei ole vestlused mugavad: teave seal ei ole struktureeritud ja kaob kiiresti. Ja administraator võis lihtsalt arvutist eemale minna ning mõnda aega ei vastata päringutele, samas kui insener seisis serveri juures, käes hunnik kettaid, ja ootas.
Kuid kõige halvem oli see, et administraatorid ei näinud tervikpilti: millised kõvaketta juhtumid eksisteerivad, kus võib potentsiaalselt probleem tekkida. See on seotud sellega, et me anname kõik HW-juhtumid inseneridele. Jah, kõik juhtumid oli võimalik kuvada administraatori armatuurlaudadele. Kuid neid on väga palju ja administraatorit kaasati vaid mõnedes neist.
Lisaks ei suutnud insener õigesti prioriteete seada, sest ta ei teadnud konkreetsete serverite otstarbe ega teabe jaotuse kohta salvestites.
Uus asendamisprotseduur
Esimene asi, mida me tegime, oli viia kõik kõvaketta juhtumid eraldi tüüpi "HW-ketas" ja lisada sellele väljad "blokeerimisaparaadi nimi", "suurus" ja "ketta tüüp", et see teave salvestuks piletisse, ning ei peaks seda pidevalt vestluses jagama.
Samuti leppisime kokku, et ühe juhtumi raames vahetame ainult ühe ketta. See lihtsustas oluliselt automatiseerimise protsessi, statistika kogumist ja tööd.
Lisaks lisasime välja "vastutav administraator". Sinna pannakse automaatselt vahetuses olev süsteemiadministraator. See on väga mugav, sest nüüd näeb insener alati, kes on vastutav. Ei ole vaja kalendrisse minna ja otsida. Just see väli võimaldas tuua administraatori armatuurlaudadele piletid, kus võib-olla vajatakse tema abi.
Kuna kõik osalejad saaksid uuendustest maksimaalset kasu, oleme loonud filtrid ja armatuurlaud, ning rääkinud neist meestele. Kui inimesed mõistavad muudatusi, ei hoia nad neist distantse, nagu need oleksid ebaolulised. Inseneril on oluline teada riiuli numbrit, kus server asub, ketta suurust ja tüüpi. Administrator peab peaeesmärgina mõistma, mis tüüpi serverigrupp see on ja milline võib olla mõju ketta vahetamisel.
Väljade olemasolu ja nende kuvamine on mugav, kuid see ei vabastanud meid vajadusest kasutada vestlusi. Selleks tuli tööprotsessi muuta.
Varem oli see selline:
Täna töötavad insenerid nii jätkuvalt, kui nad ei vaja administraatori abi.
Esimene asi, mida me tegime, oli uue staatuse, Investigate, sisseviimine. Selles etapis on pilet selline, kus insener pole veel otsustanud, kas tal on administraator vajalik või mitte. Selle staatuse kaudu saab insener piletit administraatorile edastada. Lisaks on selle staatusega me märkime pileteid, kus on vajalik ketta vahetamine, kuid ketast end pole platsil. See juhtub näiteks CDN-ide ja kaugplatside puhul.
Lisaks oleme lisanud staatuse, Valmis. Sellesse staatusesse kantakse pilet pärast ketta vahetamist. See tähendab, et kõik on juba tehtud, kuid serveris sünkroniseeritakse HW/SW RAID. See võib võtta üsna kaua aega.
Kui tööle kaasatakse administraator, muutub skeem veidi keerulisemaks.
Staatusest, Ava saab piletit edastada nii süsteemiadministraator kui ka insener. Staatuses In progress võtab administraator ketta rotiatsioonist välja, et insener saaks selle lihtsalt välja võtta: lülitab sisse valgustuse, monteerib ketta lahti, peatab rakendused, olenevalt konkreetse serverigruppi vajadustest.
Seejärel kantakse pilet staatusesse Ready to change: see on signaal insenerile, et ketas saab välja võtta. Kõik väljad Jira-s on juba täidetud, insener teab, milline on ketta tüüp ja suurus. Need andmed kantakse kas automaatselt eelmisel staatuse kaudu või administraatori poolt.
Pärast ketta vahetamist kantakse pilet staatusesse Changed. Kontrollitakse, et oleme vahetanud vajaliku ketta, tehakse partitsioneerimine, rakendus käivitatakse ja mõned andmete taastamise ülesanded täidetakse. Samuti võib pilet olla kantud staatusesse Valmis, sel juhul jääb vastutavaks administraator, kuna tema lisas ketta rotiatsiooni. Täielik skeem näeb välja selline.
Uute väljade lisamine on meie elu oluliselt lihtsustanud. Inimesed hakkavad töötama struktureeritud teabe alusel, on selge, mida ja millal teha. Prioriteedid on nüüd palju asjakohasemad, kuna need määrab administraator.
Suhtlemise vajadus chattides on kadunud. Loomulikult võib administraator kirjutada insenerile "siin tuleb kiiremini vahetada" või "on juba õhtu, kas jõuad vahetada?". Kuid me ei suhtle enam igapäevaselt nendel teemadel chattides.
Kettad vahetatakse now massiliselt. Kui administraator tuleb tööle natuke varem ja tal on vaba aega ning midagi pole veel juhtunud, saab ta ette valmistada mitu serverit vahetamiseks: väljad seadistada, kettad rotatsioonist välja võtta ja ülesande insenerile edastada. Insener tuleb hiljem andmekeskusesse, näeb ülesannet, võtab laost vajalikud andmekandjad ja vahetab kohe välja. Tulemusena on vahetuse kiirus suurenenud.
Omandatud kogemus tööprotsessi koostamisel.
- Protseduuri koostamisel tuleb koguda teavet erinevatest allikatest.
Mõned meie administraatorid ei teadnud, et insener vahetab kettaid iseseisvalt. Mõned arvasid, et MD RAID sünkroniseerimise eest hoolitsevad insenerid, kuigi mõnel neist ei olnud selleks isegi ligipääsu. Mõned peamised insenerid tegid seda, kuid mitte alati, kuna protsess ei olnud kuskil kirja pandud. - Protseduur peab olema lihtne ja arusaadav.
Inimeste on raske meeles pidada mitmeid samme. Kõige olulisemad kõrvuti olevaid staatuseid Jiras tuleks tuua peamisele ekraanile. Saame neid nimetada ümber, näiteks, progressis olekut nimetame Ready to change. Ülejäänud staatuseid saab varjata rippmenüüsse, et need ei segaks silma. Kuid parem on mitte piirata inimesi, anda neile võimalus üleminekuid teha.
Selgitage uuenduste väärtust. Kui inimesed mõistavad, aktsepteerivad nad uut protsessi paremini. Meie jaoks oli väga oluline, et inimesed ei klõpsaks kogu protsessi läbi, vaid käiksid selle läbi. Hiljem ehitasime sellele automatiseerimise. - Oodata, analüüsida, selgitada.
Me võtsime umbes kuus kuud, et välja töötada protseduur, tehniline teostus, koosolekud ja arutelud. Käivitamiseks läks aga rohkem kui kolm kuud. Nägin, kuidas inimesed järk-järgult hakkasid uuendust kasutama. Esimestel etappidel oli palju negatiivsust. Kuid see ei olnud absoluutselt seotud protseduuri endaga ega selle tehnilise teostusega. Näiteks kasutas üks administraator mitte Jira, vaid Jira-pluginat Confluences, mistõttu ei olnud mõned asjad talle kergesti kättevõetavad. Näitasime talle Jira'd, administraatori tootlikkus kasvas nii üldiste ülesannete kui ka ketaste asendamise osas.
Ketaste asendamise automatiseerimine
Ketaste asendamise automatiseerimisega oleme proovinud mitu korda. Meil oli juba varasemalt välja töötatud skripte, kuid need töötasid kas interaktiivselt või käsitsi, nõudes käivitamist. Alles uue protseduuri juurutamise järel mõistsime, et just seda me vajasimegi.
Kuna nüüd on ketaste asendamise protsess jagatud etappideks, mille igaühe kohta on määratud vastutaja ja toimingute loetelu, saame automatiseerimist etappide kaupa sisse lülitada, mitte korraga täielikult. Näiteks on kõige lihtsam etapp — Ready (RAID/sünkroniseerimise kontroll) — kergesti delegereeritav robotile. Kui robot pisut õpib, saab talle anda vastutuskohasema ülesande — ketta sisselülitamine rotatsiooni jne.
Seadistuste loomine
Enne kui räägime robotist, teeme väikese ekskursi meie seadistuste loomisse. Esiteks on see tingitud meie infrastruktuuri hiiglaslikust suurusest. Teiseks püüame iga teenuse jaoks leida optimaalse riistvarakonfiguratsiooni. Meil on umbes 20 erinevat RAID-mudelit, peamiselt LSI ja Adaptec, kuid leidub ka HP ja DELL erinevaid versioone. Igal RAID-kontrolleril on oma haldustööriist. Käskude komplekt ja nende väljund võivad iga RAID-kontrolleri versiooni põhjal erineda. Seal, kus ei kasutata HW-RAID'i, võib olla mdraid.
Peaaegu kõik uued installatsioonid teeme ilma kettasalvestuseta. Püüame enam mitte kasutada riistvaralist ega tarkvaralist RAID'i, kuna varundame meie süsteeme andmekeskuste tasemel, mitte serverite tasemel. Kuid loomulikult on palju pärandservereid, mida tuleb toetada.
Kusagil RAID-kontrollerites kasutatakse raw seadmeid, mõnes kohas kasutatakse JBOD-i. Serveris on konfiguratsioonid, kus on üks süsteemidisk, ja kui seda tuleb vahetada, tuleb server uuesti seadistada koos operatsioonisüsteemi ja rakenduste paigaldamisega, sealhulgas nende samade versioonidega, et seejärel lisada konfiguratsioonifailid ja käivitada rakendused. Samuti on palju serverigruppe, kus varukoopiaid tehakse mitte ketastaadi tasemel, vaid otse rakendustes endis.
Kokku on meil üle 400 ainulaadse serverigruppi, kus töötab umbes 100 erinevat rakendust. Nii suure variandi katmiseks vajasime multifunktsionaalset automatiseerimistööriista. Eelistatavalt lihtsa DSL-iga, et seda saaks toetada mitte ainult see, kes selle kirjutas.
Valisime Ansible'i, kuna see on agentideta: infrastruktuuri ettevalmistamine ei olnud vajalik, kiire käivitamine. Lisaks on see kirjutatud Pythonis, mis on meeskonnas standardina vastu võetud.
Üldine skeem
Vaadakem üldist automatiseerimisse kustutusprotsessi ühe juhtumi näitel. Zabbix tuvastab, et disk sdb on rikki läinud, aktiveeritakse häire, luuakse pilet Jira-s. Administraator vaatab selle üle, mõistab, et see ei ole duplikaat ega valehäire, st disk tuleb vahetada, ja suunab pileti olekusse In progress.
Rakendus DiskoBot, mis on kirjutatud Pythonis, küsib aeg-ajalt Jira't välja uute piletite osas. See märgib, et on ilmunud uus pilet olekus In progress, aktiveeritakse vastav niit, mis käivitab playbook'i Ansible'is (seda tehakse iga oleku jaoks Jira-s). Käivitatakse Prepare2change.
Ansible saadetakse hostile, eemaldab ketta rotatsioonist ja teatab olekust rakendusele Callbacks kaudu.
Tulemustest peab bot automaatselt pileti Ready to change olekusse. Insener saab teavituse ja läheb ketast vahetama, seejärel suunab pileti olekusse Changed.
Ülaltoodud skeemi kohaselt naaseb pilet tagasi boti juurde, see käivitab teise playbook'i, läheb hostile ja sisestab ketta rotatsiooni. Bot sulgeb pileti. Hurraa!
Nüüd räägime mõnest süsteemi komponendist.
Diskobot
See rakendus on kirjutatud Pythonis. See valib piletid Jira's JQL alusel. Sõltuvalt pileti olekust suunatakse see vastava töötleja juurde, mis omakorda käivitab vastavale olekule vastava Ansible playbook'i.
JQL ja küsitluse intervallid on määratud 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, In progress olekuga piletitest valitakse ainult need, mille Disk size ja Device name väljad on täidetud. Device name on plokk-seadme nimi, mis on vajalik playbook’i täitmiseks. Disk size on vajalik, et insener teaks, kui suurel kettal on vajadus.
Valmistoimingute Ready olekuga piletitest filtreeritakse välja piletid, millel on dbot_ignore silt. Üldiselt kasutame Jira silte selliseks filtreerimiseks, samuti piletite dubleerimise märgistamiseks ja statistika kogumiseks.
Playbook’i tõrke korral määrab Jira piletile dbot_failed sildi, et hiljem oleks võimalik probleemi uurida.
Koostoime Ansible’iga
Rakendus suhtleb Ansible’iga läbi . Playbook_executor’is edastame faili nime ja muutuja kogumi. See võimaldab hoida Ansible projekti tavlike yml-faile kujul, mitte kirjeldada seda Python-koodis.
Samuti edastatakse Ansible’s *extra_vars* kaudu plokk-seadmme nimi, pileti olek ja callback_url, kus on peidetud issue key — seda kasutatakse HTTP callback’ides.
Iga käivitamise jaoks genereeritakse ajutine inventory, mis koosneb ühest hostist ja grupist, kuhu see host kuulub, et rakenduksid group_vars.
Siin on näide ülesandest, kus on rakendatud HTTP callback.
Playbook’ide täitmise tulemused saadakse callback(-ide) kaudu. Need on kahte tüüpi:
- , see esitab andmed playbook’i täitmise tulemuste kohta. Seal on kirjeldatud ülesandeid, mis on käivitatud, õnnestunud või ebaõnnestunud. See callback kutsutakse esile playbook’i mängimise lõpus.
- HTTP callback, et saada teavet playbook’i mängimise ajal. Ansible ülesandes teeme POST/GET päringu meie rakenduse suunas.
HTTP callback(-ide) kaudu edastatakse muutujaid, mis määrati playbook’i täitmise ajal ja mida soovime säilitada ja kasutada järgmiste käivitamiste juures. Need andmed salvestame sqlite’isse.
Samuti jätame HTTP callback’i kaudu kommentaare ja muutume pileti olekut.
HTTP callback
# 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 paljude sarnaste ülesannete puhul, oleme selle välja tõstnud eraldi common faili ja lisame selle vajadusel, et mitte pidevalt playbook'ides korrata. Siin kajastub callback_url, milles on sisseehitatud issue key ja host name. Kui Ansible täidab selle POST-päringu, mõistab bot, et see tuleb teatud intsidenti seoses.
Siin on näide playbook'ist, kus me eemaldasime 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 "Ready to change" ja lisab kommentaari. Samuti salvestatakse muutujasse mdam_data nimekiri md-seadmetest, kust ketas eemaldati, ja parted_info - partitsiooni dump partedilt.
Kui insener paigaldab uue ketta, saame kasutada neid muutujaid, et taastada partitsioonide dump ja samuti tuua ketas tagasi nendesse md-seadetesse, kust see eemaldati.
Ansible kontrollrežiim
Automatiseerimise käivitamine oli hirmutav. Seetõttu otsustasime käivitada kõik playbook'id režiimis
, kus Ansible ei tee serverites mingeid toiminguid, vaid lihtsalt simuleerib neid.
Selline käivitus teostatakse eraldi callback-mooduli kaudu ja playbook'i täitmise tulemus salvestatakse Jira's kommentaarina.
Esiteks võimaldas see valideerida boti ja playbook'ide toimimist. Teiseks suurendas see administraatorite usaldust boti vastu.
Kui olime läbinud valideerimise ja mõistsime, et Ansible't saab käivitada mitte ainult dry run režiimis, siis lõime Jira's nuppu Run Diskobot, et käivitada sama playbook'i samade muutujatega samal hostil, kuid tavarežiimis.
Peale selle kasutatakse nuppu playbook'i korduskäivitamiseks, kui see peaks ebaõnnestuma.
Playbookide struktuur
Olen juba maininud, et sõltuvalt Jira pileti olekust käivitab bot erinevaid playbook'e.
Esiteks on nii palju lihtsam sissepääsu organiseerida.
Teiseks on teatud juhtudel see lihtsalt vajalik.
Näiteks süsteemse ketta vahetamisel tuleb kõigepealt minna deploy-süsteemi, luua ülesanne ja pärast korralikku kasutuselevõttu saab server ssh kaudu kätte ja sinna saab rakenduse paigaldada. Kui me teeksime kogu selle tegevuse ühes playbook'is, ei suudaks Ansible seda täita, kuna host ei oleks saadaval.
Kasutame Ansible'i rolle iga serverigruppi jaoks. Siin on näha, kuidas playbook'id ühes neist on organiseeritud.
See on mugav, sest kohe on selge, kus erinevad ülesanded asuvad. Failis main.yml, mis on Ansible'i rolli sissejuhatus, võib meil olla lihtsalt include pileti staatuse järgi või üldised ülesanded, mis on vajalikud kõigile, näiteks identifitseerimise läbimine või tokeni saamine.
Investigation.yml
Käivitatakse piletite jaoks, mille staatus on Investigation ja Open. Selle playbook'i kõige olulisem element on plokkseadmestiku nimi. See teave ei ole alati kergesti kättesaadav.
Selle saamiseks analüüsime Jira kokkuvõtet, viimast väärtust Zabbix'i töötluselt. Seal võib sisalduda plokkseadmestiku nimi — kui meil vedas. Ahnem võib sisalduda mount point, siis tuleb minna serverisse, parseerida ja arvutada vajalik kett. Samuti võib töötlus edastada scsi-aadressi või mõne muu teabe. Kuid juhtub ka, et mingit teavet ei ole, ja tuleb analüüsida.
Kui me oleme välja selgitanud plokkseadmestiku nime, kogume selle kohta teavet ketta tüübi ja suuruse osas, et täita väljad Jira's. Samuti võtame teavet tootja, mudeli, firmavärskenduse, ID, SMART osas ja kõik see lisatakse kommentaarina Jira-piletisse. Administrator ja insener ei pea nüüd neid andmeid enam otsima. 🙂
prepare2change.yml
Ketta välja tõmbamine ringlusest, ettevalmistamine asendamiseks. See on kõige keerulisem ja vastutustundlikum etapp. Just siin võib rakendust peatada, kui seda ei saa peatada. Või tõmmata välja ketas, millel ei olnud koopiaid, ja seetõttu mõjutada kasutajaid, kaotada teatud andmeid. Siin on meil kõige rohkem kontrolle ja teavitusi vestluses.
Lihtsamas olukorras on tegemist ketta eemaldamisega HW/MD RAID'ist.
Komplekssemates olukordades (meie salvestussüsteemides), kus replikatsioon toimub rakenduse tasemel, tuleb minna rakendusse API kaudu, teatada ketta eemaldamisest, deaktiveerida see ja alustada taastamist.
Meigma praegu massiliselt , ja kui server on pilves, siis Diskobot pöördub pilve API poole, teatab, et plaanib töötada selle mini-serveriga — serveriga, kus konteinerid on käivitatud — ja palub 'migreeri kõik konteinerid sellest mini-serverist'. Ja samal ajal aktiveerib ketta valgustuse, et insener näeks kohe, milline tuleb välja tõmmata.
changed.yml
Pärast ketta vahetamist kontrollime kõigepealt selle kättesaadavust.
Insenerid ei pane alati uusi kettaid, seetõttu lisasime kontrolli meie jaoks sobivate SMART väärtuste üle.
Milliseid atribuute me vaatameUuendatud sektorite arv (5) < 100
Praegune ootel sektorite arv (107) == 0
Kui ketas ei läbinud kontrolli, teavitatakse inseneri korduvast vahetamisest. Kui kõik on korras, kustutatakse märgistus ja ketas viiakse ringlusse.
ready.yml
Kõige lihtsam juhtum: HW/SW RAIDi sünkroniseerimise kontrollimine või andmete sünkroniseerimise lõpetamine rakenduses.
Rakenduste API
Olen mitmel korral maininud, et sageli pöördub bott rakenduste API poole. Loomulikult ei olnud kõigil rakendustel vajalikud meetodid, seega tuli need täiendada. Siin on kõige olulisemad meetodid, mida me kasutame:
- Status. Klastri või ketta staatus, et mõista, kas sellega saab töötada;
- Start/stop. Ketta aktiveerimine-deaktiveerimine;
- Migrate/restore. Andmete migreerimine ja taastamine vahetuse ajal ja pärast seda.
Kogemus Ansible'ist
Mulle meeldib Ansible väga. Kuid sageli, kui vaatan erinevaid avatud lähtekoodiga projekte ja näen, kuidas inimesed kirjutavad playbook'e, tunnen end natuke hirmutatuna. Komplekssed loogilised keerised, puuduv paindlikkus ja idempotentsus, mis tulenevad shell/command'i sagedasest kasutamisest.
Otsustasime kõik võimalikult lihtsaks muuta, kasutades Ansible'i eelist — moodulsust. Kõige kõrgemal tasemel on playbook'id, mida saab kirjutada iga administraator või väline arendaja, kes veidi tunneb Ansible'it.
- name: Wink 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 keeruline rakendada playbook'ides, viime selle Ansible moodulisse või filtrisse. Skripte saab kirjutada nii Pythonis kui ka mõnes muus keeles.
Need on kergesti ja kiiresti kirjutatavad. Näiteks ketta vilkumise moodul, mille näide ülal on, koosneb 265 reast.
Kõige madalamal tasemel on raamatukogu. Selle projekti jaoks lõime eraldi rakenduse, omamoodi abstraktsiooni riist- ja tarkvarapõhiste RAIDide üle, mis täidavad vastavaid päringuid.
Ansible'i tugevused on lihtsus ja arusaadavad playbook'id. Arvan, et peaksime seda kasutama ega genereerima hirmuäratavaid yaml-faile ja tohutut arvu tingimusi, shell-koodi ja silmuseid.
Kui soovite meie Ansible API kogemust korrata, pidage silmas kahte asja:
- Playbook_executor ja playbook'i ei saa üldse aega edasi anda. On olemas aeg ssh-seansile, kuid playbook'i jaoks ei ole aega. Kui me proovime lahti harutada ketast, mis süsteemis enam ei eksisteeri, siis playbook töötab lõputult, seetõttu pidime selle käivitamise panema eraldi wrapperisse ja tapma selle ajaülesande tõttu.
- Ansible töötab fork-protsesside alusel, seega ei ole selle API lõngade turvaline. Käitame kõiki meie playbook'e ühe lõngaga.
Lõpuks suutsime automatiseerida umbes 80% ketaste vahetust. Üldiselt on vahetuse kiirus kahekordistunud. Täna vaatab administraator lihtsalt intsidenti ja otsustab, kas on vaja ketast vahetada või mitte, ning seejärel teeb ühe klikiga.
Aga nüüd hakkame silmitsi seisma teise probleemiga: mõned uued administraatorid ei tea, kuidas kettaid vahetada. 🙂
Allikas: habr.com
