Automatizarea înlocuirii discului cu Ansible

Salutare tuturor. Lucrez ca administrator de sistem principal la OK și sunt responsabil pentru funcționarea stabilă a portalului. Vreau să vorbesc despre cum am construit un proces pentru înlocuirea automată a discurilor și apoi cum am exclus administratorul din acest proces și l-am înlocuit cu un bot.

Acest articol este un fel de transliterare spectacole la HighLoad+ 2018

Construirea unui proces de înlocuire a discului

Mai întâi câteva numere

OK este un serviciu gigant folosit de milioane de oameni. Este deservit de aproximativ 7 mii de servere, care sunt situate în 4 centre de date diferite. Serverele conțin peste 70 de mii de discuri. Dacă le stivuiți unul peste altul, obțineți un turn înalt de peste 1 km.

Hard disk-urile sunt componenta serverului care se defectează cel mai des. Cu astfel de volume, trebuie să schimbăm aproximativ 30 de discuri pe săptămână, iar această procedură a devenit o rutină nu tocmai plăcută.

Incidente

Compania noastră a introdus un management complet al incidentelor. Înregistrăm fiecare incident în Jira, apoi îl rezolvăm și îl rezolvăm. Dacă un incident a avut un efect asupra utilizatorilor, atunci cu siguranță ne întâlnim și ne gândim cum să răspundem mai rapid în astfel de cazuri, cum să reducem efectul și, desigur, cum să prevenim o reapariție.

Dispozitivele de stocare nu fac excepție. Starea lor este monitorizată de Zabbix. Monitorizăm mesajele în Syslog pentru erori de scriere/citire, analizăm starea raidurilor HW/SW, monitorizăm SMART și calculăm uzura SSD-urilor.

Cum se schimbau discurile înainte

Când apare un declanșator în Zabbix, un incident este creat în Jira și atribuit automat inginerilor corespunzători din centrele de date. Facem acest lucru cu toate incidentele HW, adică cele care necesită orice lucru fizic cu echipamente din centrul de date.
Un inginer de centru de date este o persoană care rezolvă probleme legate de hardware și este responsabilă de instalarea, întreținerea și dezmembrarea serverelor. După ce a primit biletul, inginerul se apucă de treabă. În rafturile de discuri el schimbă discurile independent. Dar dacă nu are acces la dispozitivul necesar, inginerul apelează la administratorii de sistem de serviciu pentru ajutor. În primul rând, trebuie să scoateți discul din rotație. Pentru a face acest lucru, trebuie să faceți modificările necesare pe server, să opriți aplicațiile și să demontați discul.

Administratorul de sistem de gardă este responsabil pentru funcționarea întregului portal în timpul schimbului de lucru. El investighează incidentele, efectuează reparații și ajută dezvoltatorii să finalizeze sarcini mici. Nu se ocupă doar de hard disk-uri.

Anterior, inginerii centrelor de date comunicau cu administratorul de sistem prin chat. Inginerii au trimis link-uri către biletele Jira, administratorul le-a urmărit, a ținut un jurnal de lucru într-un bloc de note. Dar chat-urile sunt incomode pentru astfel de sarcini: informațiile de acolo nu sunt structurate și se pierd rapid. Și administratorul putea pur și simplu să se îndepărteze de computer și să nu răspundă solicitărilor de ceva timp, în timp ce inginerul stătea la server cu un teanc de discuri și aștepta.

Dar cel mai rău lucru a fost că administratorii nu au văzut întreaga imagine: ce incidente pe disc au existat, unde ar putea apărea o problemă. Acest lucru se datorează faptului că delegăm toate incidentele HW către ingineri. Da, a fost posibilă afișarea tuturor incidentelor pe tabloul de bord al administratorului. Dar sunt foarte mulți, iar administratorul a fost implicat doar pentru unii dintre ei.

În plus, inginerul nu a putut stabili prioritățile corect, deoarece nu știe nimic despre scopul anumitor servere sau despre distribuirea informațiilor între unități.

Nouă procedură de înlocuire

Primul lucru pe care l-am făcut a fost să mutăm toate incidentele de disc într-un tip separat „Disc HW” și să adăugam câmpurile „nume dispozitiv de blocare”, „dimensiune” și „tipul discului”, astfel încât aceste informații să fie stocate în bilet și să fie nu trebuie să faceți schimb constant în chat.

De asemenea, am convenit că în timpul unui incident vom schimba doar un disc. Acest lucru a simplificat semnificativ procesul de automatizare, colectarea statisticilor și munca în viitor.

În plus, am adăugat câmpul „administrator responsabil”. Administratorul de sistem de serviciu este introdus automat acolo. Acest lucru este foarte convenabil, deoarece acum inginerul vede întotdeauna cine este responsabil. Nu este nevoie să mergeți la calendar și să căutați. Acest câmp a făcut posibilă afișarea biletelor pe tabloul de bord al administratorului care ar putea necesita ajutorul acestuia.

Pentru a ne asigura că toți participanții au primit beneficii maxime de pe urma inovațiilor, am creat filtre și tablouri de bord și le-am spus băieților despre ele. Când oamenii înțeleg schimbările, nu se distanțează de ele ca fiind ceva inutil. Este important ca un inginer să cunoască numărul de rack în care se află serverul, dimensiunea și tipul discului. Administratorul trebuie, în primul rând, să înțeleagă ce fel de grup de servere este acesta și care ar putea fi efectul la înlocuirea unui disc.

Prezența câmpurilor și afișarea lor este convenabilă, dar nu ne-a scutit de nevoia de a folosi chat-urile. Pentru a face acest lucru, a trebuit să schimbăm fluxul de lucru.

Anterior era asa:

Acesta este modul în care inginerii continuă să lucreze astăzi când nu au nevoie de ajutor de administrator.

Primul lucru pe care l-am făcut a fost să introducem un nou statut Investiga. Biletul se află în această stare când inginerul nu a decis încă dacă va avea nevoie sau nu de administrator. Prin acest statut, inginerul poate transfera biletul către administrator. În plus, folosim această stare pentru a marca biletele atunci când un disc trebuie înlocuit, dar discul în sine nu este pe site. Acest lucru se întâmplă în cazul CDN-urilor și site-urilor la distanță.

Am adăugat și statutul Gata. Biletul este transferat la acesta după înlocuirea discului. Adică totul a fost deja făcut, dar RAID-ul HW/SW este sincronizat pe server. Acest lucru poate dura destul de mult.

Dacă un administrator este implicat în muncă, schema devine puțin mai complicată.

Din stare Operatii Deschise Biletul poate fi tradus atât de administratorul de sistem, cât și de inginer. În stare In progres administratorul scoate discul din rotație, astfel încât inginerul să îl poată scoate pur și simplu: aprinde lumina de fundal, demontează discul, oprește aplicațiile, în funcție de grupul specific de servere.

Biletul este apoi transferat la Gata de schimbare: Acesta este un semnal pentru inginer că discul poate fi scos. Toate câmpurile din Jira sunt deja completate, inginerul știe ce tip și dimensiunea discului. Aceste date sunt introduse fie automat în starea anterioară, fie de către administrator.

După înlocuirea discului, starea biletului este schimbată în schimbată. Verifică dacă a fost introdus discul corect, se face partiționarea, se lansează aplicația și se lansează unele sarcini de recuperare a datelor. Biletul poate fi, de asemenea, transferat la statut Gata, in acest caz administratorul va ramane responsabil, deoarece a pus discul in rotatie. Diagrama completă arată așa.

Adăugarea de noi câmpuri ne-a făcut viața mult mai ușoară. Băieții au început să lucreze cu informații structurate, a devenit clar ce trebuie făcut și în ce stadiu. Prioritățile au devenit mult mai relevante, deoarece sunt stabilite acum de administrator.

Nu este nevoie de chat-uri. Desigur, administratorul poate scrie inginerului „acesta trebuie înlocuit mai repede” sau „este deja seară, vei avea timp să-l înlocuiești?” Dar nu mai comunicăm zilnic în chat-uri pe aceste probleme.

Discurile au început să fie schimbate în loturi. Dacă administratorul a venit la muncă puțin devreme, are timp liber și încă nu s-a întâmplat nimic, poate pregăti o serie de servere pentru înlocuire: completați câmpurile, scoateți discurile din rotație și transferați sarcina unui inginer. Inginerul vine la centrul de date puțin mai târziu, vede sarcina, ia unitățile necesare din depozit și le înlocuiește imediat. Ca urmare, rata de înlocuire a crescut.

Lecții învățate la construirea fluxului de lucru

• Când construiți o procedură, trebuie să colectați informații din diferite surse.
  Unii dintre administratorii noștri nu știau că inginerul schimbă singur discurile. Unii oameni au crezut că sincronizarea MD RAID se ocupă de ingineri, chiar dacă unii dintre ei nici măcar nu au avut acces la acest lucru. Unii ingineri de frunte au făcut acest lucru, dar nu întotdeauna pentru că procesul nu a fost descris nicăieri.
• Procedura ar trebui să fie simplă și ușor de înțeles.
  Este dificil pentru o persoană să țină cont de mulți pași. Cele mai importante stări vecine din Jira ar trebui să fie plasate pe ecranul principal. Le puteți redenumi, de exemplu, numim În curs Gata de schimbare. Și alte stări pot fi ascunse într-un meniu derulant, astfel încât să nu fie o criză. Dar este mai bine să nu limitezi oamenii, să le dai posibilitatea de a face tranziția.
  Explicați valoarea inovației. Când oamenii înțeleg, ei acceptă mai mult noua procedură. A fost foarte important pentru noi ca oamenii să nu facă clic pe întregul proces, ci să îl urmeze. Apoi am construit automatizarea pe asta.
• Așteaptă, analizează, află.
  Ne-a luat aproximativ o lună să construim procedura, implementarea tehnică, întâlnirile și discuțiile. Iar implementarea durează mai mult de trei luni. Am văzut cum oamenii încep încetul cu încetul să folosească inovația. A existat multă negativitate în stadiile incipiente. Dar a fost complet independent de procedura în sine și de implementarea sa tehnică. De exemplu, un administrator nu a folosit Jira, ci pluginul Jira în Confluence, iar unele lucruri nu i-au fost disponibile. I-am arătat Jira, iar productivitatea administratorului a crescut atât pentru sarcinile generale, cât și pentru înlocuirea discurilor.

Automatizarea înlocuirii discurilor

Am abordat automatizarea înlocuirii discurilor de mai multe ori. Aveam deja dezvoltări și scripturi, dar toate au funcționat fie interactiv, fie manual și au necesitat lansare. Și abia după introducerea noii proceduri ne-am dat seama că tocmai asta ne lipsea.

Deoarece acum procesul nostru de înlocuire este împărțit în etape, fiecare dintre ele având un anumit interpret și o listă de acțiuni, putem activa automatizarea în etape, și nu toate odată. De exemplu, cea mai simplă etapă - Gata (verificarea sincronizării RAID/date) poate fi delegată cu ușurință unui bot. Când botul a învățat puțin, îi puteți da o sarcină mai importantă - punerea discului în rotație etc.

Configurarea grădinii zoologice

Înainte de a vorbi despre bot, să facem o scurtă excursie în grădina zoologică a instalațiilor noastre. În primul rând, se datorează dimensiunii gigantice a infrastructurii noastre. În al doilea rând, încercăm să selectăm configurația hardware optimă pentru fiecare serviciu. Avem aproximativ 20 de modele hardware RAID, majoritatea LSI și Adaptec, dar există și HP și DELL de diferite versiuni. Fiecare controler RAID are propriul utilitar de gestionare. Setul de comenzi și emiterea acestora pot diferi de la versiune la versiune pentru fiecare controler RAID. Acolo unde nu este utilizat HW-RAID, poate fi utilizat mdraid.

Facem aproape toate instalările noi fără backup pe disc. Încercăm să nu mai folosim RAID hardware și software, deoarece ne facem copii de rezervă la nivelul centrului de date, nu la servere. Dar, desigur, există multe servere vechi care trebuie suportate.

Undeva, discurile din controlerele RAID sunt transferate pe dispozitive brute, undeva sunt folosite JBOD. Există configurații cu un singur disc de sistem în server, iar dacă acesta trebuie înlocuit, atunci trebuie să reinstalați serverul cu instalarea sistemului de operare și a aplicațiilor, din aceleași versiuni, apoi adăugați fișiere de configurare, lansați aplicații. Există, de asemenea, o mulțime de grupuri de servere în care backup-ul se realizează nu la nivel de subsistem de disc, ci direct în aplicațiile în sine.

În total, avem peste 400 de grupuri de servere unice care rulează aproape 100 de aplicații diferite. Pentru a acoperi un număr atât de mare de opțiuni, aveam nevoie de un instrument de automatizare multifuncțional. De preferat cu un simplu DSL, pentru ca nu doar persoana care a scris-o să-l suporte.

Am ales Ansible pentru că este fără agent: nu a fost nevoie să pregătim infrastructura, o pornire rapidă. În plus, este scris în Python, care este acceptat ca standard în cadrul echipei.

Schema generală

Să ne uităm la schema generală de automatizare folosind un incident ca exemplu. Zabbix detectează că discul sdb a eșuat, declanșatorul se aprinde și un bilet este creat în Jira. Administratorul s-a uitat la el, și-a dat seama că nu era o copie și nici un fals pozitiv, adică discul trebuia schimbat și a transferat biletul în În curs.

Aplicația DiskoBot, scrisă în Python, chestionează periodic Jira pentru noi bilete. Se observă că a apărut un nou bilet în curs, se declanșează thread-ul corespunzător, care lansează playbook-ul în Ansible (asta se face pentru fiecare stare din Jira). În acest caz, este lansat Prepare2change.

Ansible este trimis gazdei, scoate discul din rotație și raportează starea aplicației prin apeluri inverse.

Pe baza rezultatelor, botul transferă automat biletul în Ready to change. Inginerul primește o notificare și merge să schimbe discul, după care transferă biletul la Schimbat.

Conform schemei descrise mai sus, biletul se întoarce la bot, care lansează un alt playbook, merge la gazdă și pune discul în rotație. Botul închide biletul. Ura!

Acum să vorbim despre câteva componente ale sistemului.

Diskobot

Această aplicație este scrisă în Python. Selectează bilete de la Jira conform JQL. În funcție de statutul biletului, acesta din urmă merge la handlerul corespunzător, care la rândul său lansează playbook-ul Ansible corespunzător statusului.

JQL și intervalele de interogare sunt definite în fișierul de configurare a aplicației.

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

De exemplu, dintre biletele în starea În curs, sunt selectate doar cele cu câmpurile Dimensiunea discului și Numele dispozitivului completate. Numele dispozitivului este numele dispozitivului bloc necesar pentru a executa playbook-ul. Dimensiunea discului este necesară pentru ca inginerul să știe ce dimensiune este necesară.

Și dintre biletele cu starea Gata, biletele cu eticheta dbot_ignore sunt filtrate. Apropo, folosim etichetele Jira atât pentru astfel de filtrare, cât și pentru marcarea biletelor duplicate și colectarea de statistici.

Dacă playbook-ul eșuează, Jira atribuie eticheta dbot_failed, astfel încât să poată fi rezolvată mai târziu.

Interoperabilitate cu Ansible

Aplicația comunică cu Ansible prin API-ul Ansible Python. La playbook_executor îi transmitem numele fișierului și un set de variabile. Acest lucru vă permite să păstrați proiectul Ansible sub formă de fișiere yml obișnuite, mai degrabă decât să-l descrieți în cod Python.

De asemenea, în Ansible, prin *extra_vars*, numele dispozitivului de blocare, starea biletului, precum și callback_url, care conține cheia de emisiune - este folosită pentru apel invers în HTTP.

Pentru fiecare lansare se generează un inventar temporar, format dintr-o gazdă și grupul căruia îi aparține această gazdă, astfel încât să se aplice group_vars.

Iată un exemplu de sarcină care implementează apel invers HTTP.

Obținem rezultatul executării playbook-urilor folosind callaback(e). Sunt de două feluri:

• Plugin pentru apel invers Ansible, oferă date despre rezultatele execuției playbook-ului. Descrie sarcinile care au fost lansate, finalizate cu succes sau fără succes. Acest apel invers este apelat când playbook-ul s-a terminat de redat.
• apel invers HTTP pentru a primi informații în timpul redării unui playbook. În sarcina Ansible executăm o solicitare POST/GET către aplicația noastră.

Variabilele sunt transmise prin apeluri HTTP care au fost definite în timpul execuției playbook-ului și pe care dorim să le salvăm și să le folosim în rulările ulterioare. Scriem aceste date în sqlite.

De asemenea, lăsăm comentarii și modificăm starea biletului prin apel invers HTTP.

apel invers 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

La fel ca multe sarcini de același tip, îl punem într-un fișier comun separat și îl includem dacă este necesar, pentru a nu-l repeta constant în playbooks. Aceasta include callback_ url, care conține cheia problemei și numele gazdei. Când Ansible execută această solicitare POST, botul înțelege că a venit ca parte a unui astfel de incident.

Și iată un exemplu din playbook, în care scoatem un disc de pe un dispozitiv MD:

  # 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

Această sarcină transferă biletul Jira în starea „Gata de schimbat” și adaugă un comentariu. De asemenea, variabila mdam_data stochează o listă de dispozitive md de pe care discul a fost eliminat, iar parted_info stochează un dump de partiție de la parted.

Când inginerul inserează un disc nou, putem folosi aceste variabile pentru a restabili dump-ul partiției, precum și pentru a introduce discul în dispozitivele md de pe care a fost eliminat.

Modul de verificare Ansible

A fost înfricoșător să pornesc automatizarea. Prin urmare, am decis să rulăm toate manualele în modul
alergare uscată, în care Ansible nu efectuează nicio acțiune pe servere, ci doar le emulează.

O astfel de lansare este rulată printr-un modul separat de callback, iar rezultatul execuției playbook-ului este salvat în Jira ca comentariu.

În primul rând, acest lucru a făcut posibilă validarea activității botului și a manualelor. În al doilea rând, a crescut încrederea administratorilor în bot.

Când am trecut de validare și am realizat că poți rula Ansible nu numai în modul de rulare uscată, am creat un buton Run Diskobot în Jira pentru a lansa același playbook cu aceleași variabile pe aceeași gazdă, dar în modul normal.

În plus, butonul este folosit pentru a reporni playbook-ul dacă acesta se blochează.

Structura cărților de joc

Am menționat deja că, în funcție de statutul biletului Jira, botul lansează diferite playbook-uri.

În primul rând, este mult mai ușor să organizezi intrarea.
În al doilea rând, în unele cazuri este pur și simplu necesar.

De exemplu, atunci când înlocuiți un disc de sistem, mai întâi trebuie să mergeți la sistemul de implementare, să creați o sarcină, iar după o implementare corectă, serverul va deveni accesibil prin ssh și puteți lansa aplicația pe el. Dacă am face toate acestea într-un singur manual, atunci Ansible nu l-ar putea finaliza, deoarece gazda nu este disponibilă.

Folosim roluri Ansible pentru fiecare grup de servere. Aici puteți vedea cum sunt organizate cărțile de joc într-una dintre ele.

Acest lucru este convenabil deoarece este imediat clar unde sunt situate sarcinile. În main.yml, care este intrarea pentru rolul Ansible, putem include pur și simplu prin starea biletului sau sarcini generale necesare pentru toată lumea, de exemplu, trecerea identificării sau primirea unui token.

Investigaţie.yml

Se rulează pentru bilete în starea Investigație și Deschis. Cel mai important lucru pentru acest manual este numele dispozitivului bloc. Aceste informații nu sunt întotdeauna disponibile.

Pentru a-l obține, analizăm rezumatul Jira, ultima valoare din trigger-ul Zabbix. Poate conține numele dispozitivului de blocare - norocos. Sau poate conține un punct de montare, atunci trebuie să mergeți la server, să îl analizați și să calculați discul necesar. Declanșatorul poate transmite și o adresă scsi sau alte informații. Dar se mai întâmplă să nu existe indicii, și trebuie să analizezi.

După ce am aflat numele dispozitivului bloc, colectăm informații despre tipul și dimensiunea discului de pe acesta pentru a completa câmpurile din Jira. De asemenea, eliminăm informații despre furnizor, model, firmware, ID, SMART și inserăm toate acestea într-un comentariu din biletul Jira. Administratorul și inginerul nu mai trebuie să caute aceste date. 🙂

prepare2change.yml

Scoaterea discului din rotație, pregătirea pentru înlocuire. Cea mai dificilă și importantă etapă. Aici puteți opri aplicația când nu ar trebui să fie oprită. Sau scoateți un disc care nu a avut suficiente replici și, prin urmare, au un efect asupra utilizatorilor, pierzând unele date. Aici avem cele mai multe verificări și notificări în chat.

În cel mai simplu caz, vorbim despre scoaterea unui disc dintr-un HW/MD RAID.

În situații mai complexe (în sistemele noastre de stocare), când backup-ul este efectuat la nivel de aplicație, trebuie să accesați aplicația prin API, să raportați ieșirea discului, să o dezactivați și să începeți recuperarea.

Acum migrăm în masă către nor, iar dacă serverul este bazat pe cloud, atunci Diskobot apelează API-ul cloud, spune că va funcționa cu acest minion - serverul care rulează containere - și întreabă „migrați toate containerele de la acest minion”. Și, în același timp, pornește lumina de fundal a discului, astfel încât inginerul să poată vedea imediat care dintre ele trebuie scos.

schimbat.yml

După înlocuirea unui disc, verificăm mai întâi disponibilitatea acestuia.

Inginerii nu instalează întotdeauna unități noi, așa că am adăugat o verificare pentru valorile SMART care ne mulțumesc.

La ce atribute ne uităm?Număr de sectoare realocate (5) < 100
Număr curent de sector în așteptare (107) == 0

Dacă unitatea eșuează testul, inginerul este notificat să o înlocuiască din nou. Dacă totul este în ordine, lumina de fundal se stinge, se aplică marcaje și discul este pus în rotație.

gata.yml

Cel mai simplu caz: verificarea sincronizării raid HW/SW sau finalizarea sincronizării datelor în aplicație.

Aplicație API

Am menționat de mai multe ori că botul accesează adesea API-urile aplicației. Desigur, nu toate aplicațiile aveau metodele necesare, așa că trebuiau modificate. Iată cele mai importante metode pe care le folosim:

• Stare. Starea unui cluster sau a unui disc pentru a înțelege dacă poate fi lucrat cu acesta;
• Start Stop. Activare/dezactivare disc;
• Migrați/restaurați. Migrarea și recuperarea datelor în timpul și după înlocuire.

Lecții învățate de la Ansible

Îmi place foarte mult Ansible. Dar adesea, când mă uit la diferite proiecte opensource și văd cum scriu oamenii cărți de joc, mă sperie puțin. Impletiuni logice complexe de cand/bucla, lipsa de flexibilitate si idempotenta datorita folosirii frecvente a shell/comandei.

Am decis să simplificăm totul cât mai mult, profitând de avantajul Ansible - modularitatea. La cel mai înalt nivel există manuale, acestea pot fi scrise de orice administrator, dezvoltator terță parte care cunoaște puțin Ansible.

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

Dacă o anumită logică este dificil de implementat în playbooks, o mutăm într-un modul sau filtru Ansible. Scripturile pot fi scrise în Python sau în orice alt limbaj.

Sunt ușor și rapid de scris. De exemplu, modulul de iluminare de fundal a discului, al cărui exemplu este prezentat mai sus, este format din 265 de linii.

La cel mai de jos nivel se află biblioteca. Pentru acest proiect, am scris o aplicație separată, un fel de abstractizare peste RAID-uri hardware și software care execută solicitările corespunzătoare.

Cele mai mari puncte forte ale Ansible sunt simplitatea și manualele clare. Cred că trebuie să utilizați acest lucru și să nu generați fișiere yaml înfricoșătoare și un număr mare de condiții, cod shell și bucle.

Dacă doriți să repetați experiența noastră cu API-ul Ansible, rețineți două lucruri:

• Playbook_executor și playbook-urilor în general nu li se poate acorda un timeout. Există un timeout în sesiunea ssh, dar nu există timeout în playbook. Dacă încercăm să demontăm un disc care nu mai există în sistem, playbook-ul va rula la nesfârșit, așa că a trebuit să-i înfășurăm lansarea într-un wrapper separat și să-l omorâm cu un timeout.
• Ansible rulează pe procese bifurcate, deci API-ul său nu este sigur pentru fire. Rulem toate manualele noastre cu un singur thread.

Drept urmare, am reușit să automatizăm înlocuirea a aproximativ 80% din discuri. În general, rata de înlocuire s-a dublat. Astăzi, administratorul doar se uită la incident și decide dacă discul trebuie schimbat sau nu, apoi face un clic.

Dar acum începem să ne confruntăm cu o altă problemă: unii administratori noi nu știu cum să schimbe unitățile. 🙂

Sursa: www.habr.com