Ahojte všetci. Pracujem ako vedúci systémový administrátor v OK a zodpovedám za stabilnú prevádzku portálu. Chcem hovoriť o tom, ako sme vytvorili proces na automatickú výmenu diskov a ako sme z tohto procesu vylúčili správcu a nahradili ho robotom.
Tento článok je akýmsi prepisom na HighLoad+ 2018
Vytvorenie procesu výmeny disku
Najprv nejaké čísla
OK je obrovská služba, ktorú využívajú milióny ľudí. Obsluhuje ho približne 7 tisíc serverov, ktoré sú umiestnené v 4 rôznych dátových centrách. Servery obsahujú viac ako 70 tisíc diskov. Ak ich poskladáte na seba, získate vežu vysokú viac ako 1 km.
Pevné disky sú komponentom servera, ktorý najčastejšie zlyháva. Pri takýchto objemoch musíme za týždeň vymeniť asi 30 diskov a tento postup sa stal nie veľmi príjemnou rutinou.
Incidenty
Naša spoločnosť zaviedla plnohodnotné riadenie incidentov. Každý incident zaznamenáme v Jire a potom ho vyriešime a vyriešime. Ak mal nejaký incident na používateľov vplyv, tak sa určite zídeme a premýšľame, ako v takýchto prípadoch rýchlejšie reagovať, ako znížiť efekt a samozrejme ako zabrániť opakovaniu.
Úložné zariadenia nie sú výnimkou. Ich stav monitoruje Zabbix. Monitorujeme správy v Syslog kvôli chybám zápisu/čítania, analyzujeme stav HW/SW raidov, monitorujeme SMART a počítame opotrebovanie SSD.
Ako sa predtým menili disky
Keď v Zabbixe nastane spúšťač, v Jira sa vytvorí incident a automaticky sa pridelí príslušným inžinierom v dátových centrách. Robíme to pri všetkých HW incidentoch, teda takých, ktoré vyžadujú akúkoľvek fyzickú prácu so zariadením v dátovom centre.
Inžinier dátového centra je osoba, ktorá rieši problémy súvisiace s hardvérom a je zodpovedná za inštaláciu, údržbu a demontáž serverov. Po prijatí lístka sa inžinier pustí do práce. V diskových regáloch vymieňa disky samostatne. Ak však nemá prístup k požadovanému zariadeniu, inžinier sa obráti so žiadosťou o pomoc na službukonajúcich správcov systému. Najprv musíte odstrániť disk z rotácie. Ak to chcete urobiť, musíte vykonať potrebné zmeny na serveri, zastaviť aplikácie a odpojiť disk.
Za chod celého portálu počas pracovnej zmeny zodpovedá službukonajúci správca systému. Vyšetruje incidenty, robí opravy a pomáha vývojárom dokončiť malé úlohy. Nezaoberá sa len pevnými diskami.
Predtým inžinieri dátových centier komunikovali so správcom systému cez chat. Inžinieri poslali odkazy na lístky Jira, správca ich sledoval a viedol si protokol o práci v nejakom poznámkovom bloku. Rozhovory sú však pre takéto úlohy nepohodlné: informácie tam nie sú štruktúrované a rýchlo sa strácajú. A správca mohol jednoducho odísť od počítača a nejaký čas nereagovať na požiadavky, zatiaľ čo inžinier stál pri serveri so hromadou diskov a čakal.
Najhoršie však bolo, že správcovia nevideli celý obraz: aké diskové incidenty existovali, kde by potenciálne mohol vzniknúť problém. Je to spôsobené tým, že všetky HW incidenty delegujeme na inžinierov. Áno, všetky incidenty bolo možné zobraziť na administrátorskom dashboarde. Ale je ich veľa a správca sa podieľal len na niektorých.
Okrem toho inžinier nedokázal správne nastaviť priority, pretože nevie nič o účele konkrétnych serverov ani o distribúcii informácií medzi jednotkami.
Nový postup výmeny
Prvá vec, ktorú sme urobili, bolo presunutie všetkých diskových incidentov na samostatný typ „HW disk“ a pridali sme k nemu polia „názov zariadenia bloku“, „veľkosť“ a „typ disku“, aby sa tieto informácie uložili do tiketu a nemusíte sa neustále vymieňať v chate.
Dohodli sme sa aj na tom, že počas jedného incidentu vymeníme len jeden disk. To výrazne zjednodušilo proces automatizácie, zber štatistík a prácu v budúcnosti.
Okrem toho sme pridali pole „zodpovedný správca“. Automaticky sa tam vloží službukonajúci správca systému. To je veľmi výhodné, pretože teraz inžinier vždy vidí, kto je zodpovedný. Netreba ísť do kalendára a hľadať. Práve toto pole umožnilo zobraziť lístky na palubnej doske správcu, ktoré si mohli vyžadovať jeho pomoc.
Aby sme zaistili, že všetci účastníci získajú maximálny úžitok z inovácií, vytvorili sme filtre a dashboardy a povedali o nich chlapcom. Keď ľudia pochopia zmeny, nedištancujú sa od nich ako niečo zbytočné. Pre inžiniera je dôležité poznať číslo racku, kde je server umiestnený, veľkosť a typ disku. Administrátor musí v prvom rade pochopiť, o aký druh skupiny serverov ide a aký to môže mať efekt pri výmene disku.
Prítomnosť polí a ich zobrazovanie je pohodlné, no nezachránilo nás to od nutnosti používať chaty. Aby sme to dosiahli, museli sme zmeniť pracovný postup.
Predtým to bolo takto:
Takto inžinieri pokračujú v práci aj dnes, keď nepotrebujú pomoc správcu.
Prvá vec, ktorú sme urobili, bolo zavedenie nového statusu vyšetrovať. Lístok je v tomto stave, keď sa inžinier ešte nerozhodol, či bude potrebovať správcu alebo nie. Prostredníctvom tohto stavu môže inžinier preniesť lístok na správcu. Okrem toho tento stav používame na označenie lístkov, keď je potrebné vymeniť disk, ale samotný disk nie je na mieste. Stáva sa to v prípade sietí CDN a vzdialených lokalít.
Pridali sme aj status Pripravený. Lístok sa naň prenesie po výmene disku. To znamená, že všetko už bolo urobené, ale HW/SW RAID je synchronizovaný na serveri. To môže trvať pomerne dlho.
Ak je do práce zapojený administrátor, schéma sa trochu skomplikuje.
Zo stavu Otvorený Lístok môže preložiť správca systému aj technik. V stave Prebieha administrátor odstráni disk z rotácie, aby ho technik mohol jednoducho vytiahnuť: zapne podsvietenie, odpojí disk, zastaví aplikácie, v závislosti od konkrétnej skupiny serverov.
Lístok sa potom prenesie na Pripravený na zmenu: Toto je signál pre inžiniera, že disk možno vytiahnuť. Všetky polia v Jire sú už vyplnené, inžinier vie, aký typ a veľkosť disku. Tieto údaje sú zadávané buď automaticky pri predchádzajúcom stave alebo administrátorom.
Po výmene disku sa stav lístka zmení na zmenený. Skontroluje, či bol vložený správny disk, vykoná sa rozdelenie, spustí sa aplikácia a niektoré úlohy obnovy dát. Lístok je možné preniesť aj do stavu Pripravený, v tomto prípade zostane zodpovedný administrátor, pretože dal disk do rotácie. Kompletný diagram vyzerá takto.
Pridávanie nových polí nám výrazne uľahčilo život. Chlapci začali pracovať so štruktúrovanými informáciami, bolo jasné, čo je potrebné urobiť a v akom štádiu. Priority sa stali oveľa relevantnejšími, keďže ich teraz určuje správca.
O chaty nie je núdza. Samozrejme, administrátor môže inžinierovi napísať „toto treba vymeniť rýchlejšie“ alebo „už je večer, stihneš to vymeniť?“ Ale o týchto otázkach už nekomunikujeme denne v chatoch.
Disky sa začali meniť po dávkach. Ak administrátor prišiel do práce trochu skôr, má voľný čas a zatiaľ sa nič nestalo, môže pripraviť niekoľko serverov na výmenu: vyplniť polia, odstrániť disky z rotácie a preniesť úlohu na inžiniera. Inžinier príde do dátového centra o niečo neskôr, vidí úlohu, vezme potrebné disky zo skladu a okamžite ich vymení. V dôsledku toho sa miera náhrady zvýšila.
Ponaučenia získané pri budovaní pracovného toku
- Pri zostavovaní postupu musíte zbierať informácie z rôznych zdrojov.
Niektorí naši správcovia nevedeli, že si mechanik vymieňa disky sám. Niektorí ľudia si mysleli, že synchronizáciu MD RAID majú na starosti inžinieri, aj keď niektorí z nich k tomu ani nemali prístup. Niektorí poprední inžinieri to urobili, ale nie vždy, pretože proces nebol nikde opísaný. - Postup by mal byť jednoduchý a zrozumiteľný.
Pre človeka je ťažké udržať si v pamäti veľa krokov. Najdôležitejšie susedné stavy v Jira by mali byť umiestnené na hlavnej obrazovke. Môžete ich premenovať, napríklad voláme Prebieha Pripravené na zmenu. A ďalšie statusy je možné skryť v rozbaľovacom menu, aby z nich nebolel zrak. Ale je lepšie neobmedzovať ľudí, dať im príležitosť na prechod.
Vysvetlite hodnotu inovácií. Keď ľudia pochopia, viac akceptujú nový postup. Bolo pre nás veľmi dôležité, aby sa ľudia celý proces nepreklikávali, ale sledovali. Potom sme na tom postavili automatizáciu. - Počkajte, analyzujte, zistite.
Vybudovanie postupu, technickej implementácie, stretnutí a diskusií nám trvalo približne mesiac. A implementácia trvá viac ako tri mesiace. Videl som, ako ľudia pomaly začínajú inováciu využívať. V počiatočných štádiách bolo veľa negativity. Ale bolo to úplne nezávislé od samotného postupu a jeho technickej realizácie. Napríklad jeden administrátor nepoužíval Jira, ale plugin Jira v Confluence a niektoré veci mu neboli dostupné. Ukázali sme mu Jiru a produktivita správcu sa zvýšila pri všeobecných úlohách aj pri výmene diskov.
Automatizácia výmeny diskov
K automatizácii výmeny diskov sme pristupovali niekoľkokrát. Už sme mali vývoj a skripty, ale všetky fungovali buď interaktívne alebo manuálne a vyžadovali si spustenie. A až po zavedení nového postupu sme si uvedomili, že práve toto nám chýba.
Keďže je teraz náš proces výmeny rozdelený na etapy, z ktorých každá má konkrétneho interpreta a zoznam akcií, môžeme automatizáciu povoliť v etapách, a nie všetky naraz. Napríklad najjednoduchšiu fázu – Ready (kontrola RAID/synchronizácie dát) možno jednoducho delegovať na robota. Keď sa robot trochu naučí, môžete mu dať dôležitejšiu úlohu - uviesť disk do rotácie atď.
Zoo nastavenia
Predtým, ako si povieme niečo o robotovi, urobme si krátku exkurziu do našej zoo s inštaláciami. V prvom rade je to kvôli gigantickej veľkosti našej infraštruktúry. Po druhé, snažíme sa vybrať optimálnu hardvérovú konfiguráciu pre každú službu. Máme asi 20 hardvérových modelov RAID, väčšinou LSI a Adaptec, ale existujú aj HP a DELL rôznych verzií. Každý radič RAID má svoj vlastný nástroj na správu. Sada príkazov a ich vydávanie sa môže líšiť od verzie k verzii pre každý radič RAID. Ak sa nepoužíva HW-RAID, možno použiť mdraid.
Takmer všetky nové inštalácie robíme bez zálohy disku. Snažíme sa už nepoužívať hardvérový a softvérový RAID, pretože naše systémy zálohujeme na úrovni dátových centier, nie serverov. Ale samozrejme existuje veľa starších serverov, ktoré je potrebné podporovať.
Niekde sa disky v RAID radičoch prenesú do raw zariadení, niekde sa používajú JBODy. Na serveri sú konfigurácie s jedným systémovým diskom a ak je potrebné ho vymeniť, musíte server preinštalovať s inštaláciou OS a aplikácií rovnakých verzií, potom pridať konfiguračné súbory, spustiť aplikácie. Existuje tiež veľa skupín serverov, kde sa zálohovanie nevykonáva na úrovni diskového subsystému, ale priamo v samotných aplikáciách.
Celkovo máme viac ako 400 jedinečných skupín serverov s takmer 100 rôznymi aplikáciami. Na pokrytie takého obrovského množstva možností sme potrebovali multifunkčný automatizačný nástroj. Najlepsie s jednoduchym DSL, aby to podporil nielen ten, kto to pisal.
Vybrali sme Ansible, pretože je bez agentov: nebolo potrebné pripravovať infraštruktúru, rýchly štart. Navyše je napísaný v Pythone, ktorý je v rámci tímu akceptovaný ako štandard.
Všeobecná schéma
Pozrime sa na všeobecnú schému automatizácie na príklade jedného incidentu. Zabbix zistí, že sdb disk zlyhal, spúšť sa rozsvieti a v Jira sa vytvorí lístok. Administrátor sa na to pozrel, uvedomil si, že nejde o duplikát a nie o falošný poplach, čiže treba vymeniť disk a preniesol tiket do In progress.
Aplikácia DiskoBot, napísaná v Pythone, pravidelne žiada Jiru o nové lístky. Všimne si, že sa objavil nový lístok In progress, spustí sa príslušné vlákno, ktoré spustí playbook v Ansible (toto sa robí pre každý stav v Jira). V tomto prípade sa spustí Prepare2change.
Ansible sa odošle hostiteľovi, odstráni disk z rotácie a nahlási stav aplikácii prostredníctvom spätných volaní.
Na základe výsledkov robot automaticky prenesie lístok do Ready to change. Inžinier dostane upozornenie a ide vymeniť disk, potom prenesie lístok do Changed.
Podľa schémy opísanej vyššie sa tiket vráti späť k robotovi, ktorý spustí ďalšiu príručku, prejde k hostiteľovi a uvedie disk do rotácie. Bot zatvorí lístok. Hurá!
Teraz si povedzme o niektorých komponentoch systému.
Diskobot
Táto aplikácia je napísaná v jazyku Python. Vyberá letenky od Jira podľa JQL. V závislosti od stavu tiketu prejde k príslušnému spracovateľovi, ktorý následne spustí Ansible playbook zodpovedajúci stavu.
JQL a intervaly výziev sú definované v konfiguračnom súbore aplikácie.
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
Napríklad medzi tiketmi v stave Prebieha sú vybraté len tie, ktoré majú vyplnené polia Veľkosť disku a Názov zariadenia. Názov zariadenia je názov blokového zariadenia potrebného na spustenie playbooku. Veľkosť disku je potrebná, aby technik vedel, aká veľkosť disku je potrebná.
A medzi tiketmi so stavom Pripravené sú vyfiltrované lístky s označením dbot_ignore. Mimochodom, Jira štítky používame ako na takéto filtrovanie, tak aj na označovanie duplicitných tiketov a zbieranie štatistík.
Ak playbook zlyhá, Jira priradí označenie dbot_failed, aby sa to dalo vyriešiť neskôr.
Interoperabilita s Ansible
Aplikácia komunikuje s Ansible cez . Do playbook_executor odovzdáme názov súboru a množinu premenných. To vám umožňuje ponechať projekt Ansible vo forme bežných súborov yml, namiesto toho, aby ste ho popisovali v kóde Python.
Aj v Ansible cez *extra_vars* názov blokového zariadenia, stav tiketu, ako aj callback_url, ktorý obsahuje kľúč vydania – používa sa na spätné volanie v HTTP.
Pre každé spustenie sa vygeneruje dočasný inventár pozostávajúci z jedného hostiteľa a skupiny, do ktorej tento hostiteľ patrí, takže sa použijú premenné skupiny.
Tu je príklad úlohy, ktorá implementuje spätné volanie HTTP.
Získame výsledok spustenia playbookov pomocou callaback(ov). Sú dvoch typov:
- poskytuje údaje o výsledkoch vykonávania playbooku. Popisuje úlohy, ktoré boli spustené, dokončené úspešne alebo neúspešne. Toto spätné volanie sa zavolá po skončení prehrávania zošita.
- Spätné volanie HTTP na prijímanie informácií počas prehrávania zošita. V úlohe Ansible vykonáme požiadavku POST/GET do našej aplikácie.
Premenné sa prenášajú prostredníctvom spätných volaní HTTP, ktoré boli definované počas vykonávania príručky a ktoré chceme uložiť a použiť v nasledujúcich spusteniach. Tieto údaje zapisujeme do sqlite.
Zanechávame tiež komentáre a meníme stav lístka prostredníctvom spätného volania HTTP.
Spätné volanie HTTP
# 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
Rovnako ako mnoho úloh rovnakého typu, vložíme ho do samostatného spoločného súboru a v prípade potreby ho zahrnieme, aby sa neustále opakoval v playbookoch. To zahŕňa adresu URL spätného volania, ktorá obsahuje kľúč problému a názov hostiteľa. Keď Ansible vykoná túto požiadavku POST, robot pochopí, že to prišlo ako súčasť takého a takého incidentu.
A tu je príklad z príručky, v ktorej vydávame disk z MD zariadenia:
# 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
Táto úloha prenesie lístok Jira do stavu „Pripravené na zmenu“ a pridá komentár. Premenná mdam_data tiež ukladá zoznam zariadení md, z ktorých bol disk odstránený, a parted_info ukladá výpis oddielov z parted.
Keď inžinier vloží nový disk, môžeme tieto premenné použiť na obnovenie výpisu oddielu, ako aj na vloženie disku do md zariadení, z ktorých bol odstránený.
Povolený režim kontroly
Bolo desivé zapnúť automatiku. Preto sme sa rozhodli spustiť všetky playbooky v režime
, v ktorom Ansible nevykonáva žiadne akcie na serveroch, ale iba ich emuluje.
Takéto spustenie prebieha cez samostatný modul spätného volania a výsledok spustenia playbooku sa uloží do Jira ako komentár.
Po prvé, toto umožnilo overiť prácu robota a playbookov. Po druhé, zvýšilo to dôveru správcov v robota.
Keď sme prešli overením a uvedomili sme si, že Ansible môžete spustiť nielen v režime suchého chodu, vytvorili sme v Jira tlačidlo Run Diskobot, aby sme spustili rovnakú príručku s rovnakými premennými na rovnakom hostiteľovi, ale v normálnom režime.
Okrem toho sa tlačidlo používa na reštartovanie playbooku, ak sa zrúti.
Štruktúra zošitov
Už som spomenul, že v závislosti od stavu lístka Jira, bot spúšťa rôzne playbooky.
Po prvé, je oveľa jednoduchšie zorganizovať vchod.
Po druhé, v niektorých prípadoch je to jednoducho nevyhnutné.
Napríklad pri výmene systémového disku musíte najprv prejsť do systému nasadenia, vytvoriť úlohu a po správnom nasadení sa server sprístupní cez ssh a môžete naň spustiť aplikáciu. Ak by sme to všetko urobili v jednej príručke, Ansible by to nedokázal dokončiť kvôli nedostupnosti hostiteľa.
Pre každú skupinu serverov používame roly Ansible. Tu môžete vidieť, ako sú zošity usporiadané v jednom z nich.
Je to výhodné, pretože je hneď jasné, kde sa ktoré úlohy nachádzajú. Do main.yml, ktorý je vstupom pre rolu Ansible, môžeme jednoducho zahrnúť podľa stavu lístka alebo všeobecných úloh vyžadovaných pre každého, napríklad odovzdanie identifikácie alebo prijatie tokenu.
vyšetrovanie.yml
Beží na lístky v stave Vyšetrovanie a Otvorené. Najdôležitejšou vecou pre túto príručku je názov blokového zariadenia. Tieto informácie nie sú vždy dostupné.
Aby sme to získali, analyzujeme súhrn Jira, poslednú hodnotu zo spúšťača Zabbix. Môže obsahovať názov blokového zariadenia - šťastie. Alebo môže obsahovať bod pripojenia, potom musíte prejsť na server, analyzovať ho a vypočítať požadovaný disk. Spúšťač môže tiež prenášať scsi adresu alebo iné informácie. Stáva sa však aj to, že neexistujú žiadne stopy a musíte analyzovať.
Po zistení názvu blokového zariadenia z neho zhromažďujeme informácie o type a veľkosti disku, aby sme vyplnili polia v Jira. Odstránime tiež informácie o predajcovi, modeli, firmvéri, ID, SMART a to všetko vložíme do komentára v tikete Jira. Správca a inžinier už nemusia tieto údaje hľadať. 🙂
priprav2zmena.yml
Vybratie disku z rotácie, príprava na výmenu. Najťažšia a najdôležitejšia etapa. Tu môžete zastaviť aplikáciu, keď by nemala byť zastavená. Alebo vyberte disk, ktorý nemal dostatok replík, a to má vplyv na používateľov, ktorí prídu o niektoré údaje. Tu máme najviac kontrol a upozornení v chate.
V najjednoduchšom prípade hovoríme o odstránení disku z HW/MD RAID.
V zložitejších situáciách (v našich úložných systémoch), keď sa záloha vykonáva na aplikačnej úrovni, je potrebné prejsť do aplikácie cez API, nahlásiť výstup na disk, deaktivovať ho a spustiť obnovu.
Teraz masovo migrujeme do a ak je server založený na cloude, Diskobot zavolá cloudové API, povie, že bude pracovať s týmto prisluhovačom – serverom, na ktorom sú spustené kontajnery – a spýta sa „migrujte všetky kontajnery z tohto prisluhovača“. A zároveň zapne podsvietenie disku, aby inžinier hneď videl, ktorý z nich treba vytiahnuť.
zmenený.yml
Po výmene disku najskôr skontrolujeme jeho dostupnosť.
Inžinieri nie vždy inštalujú nové disky, preto sme pridali kontrolu hodnôt SMART, ktoré nás uspokojujú.
Na aké atribúty sa pozeráme?Počet prerozdelených sektorov (5) < 100
Aktuálny počet čakajúcich sektorov (107) == 0
Ak disk neprejde testom, technik dostane upozornenie, aby ho znova vymenil. Ak je všetko v poriadku, podsvietenie sa vypne, aplikujú sa značky a disk sa otočí.
pripravený.yml
Najjednoduchší prípad: kontrola HW/SW raid synchronizácie alebo dokončenie synchronizácie dát v aplikácii.
API aplikácie
Niekoľkokrát som spomenul, že bot často pristupuje k aplikačným API. Samozrejme, nie všetky aplikácie disponovali potrebnými metódami, preto ich bolo potrebné upraviť. Tu sú najdôležitejšie metódy, ktoré používame:
- Postavenie. Stav klastra alebo disku, aby ste pochopili, či sa s ním dá pracovať;
- Štart stop. Aktivácia/deaktivácia disku;
- Migrovať/obnoviť. Migrácia a obnova dát počas výmeny a po nej.
Poučenie od Ansible
Naozaj milujem Ansible. Ale často, keď sa pozerám na rôzne opensource projekty a vidím, ako ľudia píšu playbooky, mám trochu strach. Zložité logické prepletenia kedy/slučky, nedostatok flexibility a idempotencie kvôli častému používaniu shellu/príkazu.
Rozhodli sme sa všetko čo najviac zjednodušiť a využiť výhodu Ansible – modulárnosť. Na najvyššej úrovni sú playbooky; môže ich napísať každý správca, vývojár tretej strany, ktorý sa trochu vyzná v Ansible.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Ak je niektorá logika ťažko implementovateľná do playbookov, presunieme ju do modulu alebo filtra Ansible. Skripty môžu byť napísané v Pythone alebo v akomkoľvek inom jazyku.
Píšu sa ľahko a rýchlo. Napríklad modul podsvietenia disku, ktorého príklad je uvedený vyššie, pozostáva z 265 riadkov.
Na najnižšej úrovni je knižnica. Pre tento projekt sme napísali samostatnú aplikáciu, akúsi abstrakciu nad hardvérovými a softvérovými RAID, ktoré vykonávajú zodpovedajúce požiadavky.
Najväčšou prednosťou Ansible je jednoduchosť a prehľadnosť. Verím, že toto musíte využiť a nie generovať strašidelné yaml súbory a obrovské množstvo podmienok, shell kódu a slučiek.
Ak si chcete zopakovať naše skúsenosti s Ansible API, majte na pamäti dve veci:
- Playbook_executor a playbooks vo všeobecnosti nemôžu mať časový limit. V relácii ssh je časový limit, ale v playbooku nie je žiadny časový limit. Ak sa pokúsime odpojiť disk, ktorý už v systéme neexistuje, playbook bude bežať donekonečna, takže sme jeho spustenie museli zabaliť do samostatného obalu a zabiť ho časovým limitom.
- Ansible beží na rozvetvených procesoch, takže jeho API nie je bezpečné pre vlákna. Všetky naše príručky prevádzkujeme jednovláknovo.
Vďaka tomu sa nám podarilo zautomatizovať výmenu približne 80 % diskov. Celkovo sa miera náhrady zdvojnásobila. Dnes sa správca len pozrie na incident a rozhodne, či je potrebné disk vymeniť alebo nie, a potom urobí jeden klik.
Teraz však začíname narážať na ďalší problém: niektorí noví správcovia nevedia, ako zmeniť disky. 🙂
Zdroj: hab.com