Automatizzazione della sostituzione del disco con Ansible

Ciao a tutti. Lavoro come amministratore di sistema leader presso OK e sono responsabile del funzionamento stabile del portale. Voglio parlare di come abbiamo creato un processo per la sostituzione automatica dei dischi e di come abbiamo escluso l'amministratore da questo processo e lo abbiamo sostituito con un bot.

Questo articolo è una sorta di traslitterazione spettacoli all'HighLoad+ 2018

Creazione di un processo di sostituzione del disco

Prima alcuni numeri

OK è un servizio enorme utilizzato da milioni di persone. È servito da circa 7mila server, che si trovano in 4 diversi data center. I server contengono più di 70mila dischi. Se li impili uno sopra l'altro, ottieni una torre alta più di 1 km.

I dischi rigidi sono il componente del server che si guasta più spesso. Con tali volumi dobbiamo cambiare circa 30 dischi a settimana e questa procedura è diventata una routine poco piacevole.

incidenti

La nostra azienda ha introdotto una gestione degli incidenti completa. Registriamo ogni incidente in Jira, quindi lo risolviamo e lo risolviamo. Se un incidente ha avuto un effetto sugli utenti, allora ci riuniamo sicuramente e pensiamo a come reagire più rapidamente in questi casi, a come ridurre l'effetto e, naturalmente, a come prevenire il ripetersi.

I dispositivi di archiviazione non fanno eccezione. Il loro stato è monitorato da Zabbix. Monitoriamo i messaggi in Syslog per individuare errori di scrittura/lettura, analizziamo lo stato dei raid HW/SW, monitoriamo SMART e calcoliamo l'usura degli SSD.

Come venivano cambiati i dischi prima

Quando si verifica un trigger in Zabbix, un incidente viene creato in Jira e assegnato automaticamente agli ingegneri appropriati nei data center. Lo facciamo con tutti gli incidenti HW, ovvero quelli che richiedono interventi fisici sulle apparecchiature del data center.
Un ingegnere del data center è una persona che risolve i problemi relativi all'hardware ed è responsabile dell'installazione, della manutenzione e dello smantellamento dei server. Ricevuto il biglietto, l'ingegnere si mette al lavoro. Negli scaffali dei dischi cambia i dischi in modo indipendente. Ma se non ha accesso al dispositivo richiesto, l'ingegnere si rivolge agli amministratori di sistema in servizio per chiedere aiuto. Prima di tutto, devi rimuovere il disco dalla rotazione. Per fare ciò, è necessario apportare le modifiche necessarie sul server, arrestare le applicazioni e smontare il disco.

L'amministratore di sistema in servizio è responsabile del funzionamento dell'intero portale durante il turno di lavoro. Indaga sugli incidenti, esegue riparazioni e aiuta gli sviluppatori a completare piccole attività. Non si occupa solo di dischi rigidi.

In precedenza, i tecnici del data center comunicavano con l'amministratore di sistema tramite chat. Gli ingegneri hanno inviato collegamenti ai ticket Jira, l'amministratore li ha seguiti, ha tenuto un registro del lavoro in un blocco note. Ma le chat sono scomode per tali compiti: le informazioni non sono strutturate e si perdono rapidamente. E l'amministratore poteva semplicemente allontanarsi dal computer e non rispondere alle richieste per un po', mentre l'ingegnere restava davanti al server con una pila di dischi e aspettava.

Ma la cosa peggiore è che gli amministratori non hanno visto il quadro completo: quali incidenti del disco si sono verificati, dove potrebbe sorgere un problema. Ciò è dovuto al fatto che deleghiamo tutti gli incidenti HW agli ingegneri. Sì, era possibile visualizzare tutti gli incidenti sulla dashboard dell'amministratore. Ma ce ne sono molti e l'amministratore è intervenuto solo per alcuni di essi.

Inoltre, l'ingegnere non è in grado di impostare correttamente le priorità perché non sa nulla dello scopo di determinati server o della distribuzione delle informazioni tra le unità.

Nuova procedura di sostituzione

La prima cosa che abbiamo fatto è stata spostare tutti gli incidenti del disco in un tipo separato "disco HW" e aggiungere i campi "nome dispositivo blocco", "dimensione" e "tipo disco" in modo che queste informazioni venissero archiviate nel ticket e non dover scambiare costantemente in chat.

Abbiamo anche concordato che durante un incidente avremmo cambiato solo un disco. Ciò ha notevolmente semplificato il processo di automazione, la raccolta delle statistiche e il lavoro futuro.

Inoltre, abbiamo aggiunto il campo “amministratore responsabile”. L'amministratore di sistema di turno vi viene automaticamente inserito. Questo è molto comodo perché ora l'ingegnere vede sempre chi è responsabile. Non c'è bisogno di andare al calendario e cercare. È stato questo campo che ha permesso di visualizzare i ticket sulla dashboard dell'amministratore che potrebbero richiedere il suo aiuto.

Per garantire che tutti i partecipanti ricevessero i massimi benefici dalle innovazioni, abbiamo creato filtri e dashboard e ne abbiamo parlato ai ragazzi. Quando le persone comprendono i cambiamenti, non se ne allontanano considerandoli qualcosa di superfluo. È importante che un tecnico conosca il numero del rack in cui si trova il server, la dimensione e il tipo di disco. L'amministratore deve, prima di tutto, capire di che tipo di gruppo di server si tratta e quale potrebbe essere l'effetto in caso di sostituzione di un disco.

La presenza dei campi e la loro visualizzazione è comoda, ma non ci ha risparmiato dalla necessità di utilizzare le chat. Per fare ciò, abbiamo dovuto modificare il flusso di lavoro.

Prima era così:

Questo è il modo in cui gli ingegneri continuano a lavorare oggi quando non hanno bisogno dell'aiuto dell'amministratore.

La prima cosa che abbiamo fatto è stata introdurre un nuovo status indagare. Il ticket si trova in questo stato quando l'ingegnere non ha ancora deciso se avrà bisogno o meno di un amministratore. Attraverso questo stato l'ingegnere può trasferire il ticket all'amministratore. Inoltre, utilizziamo questo stato per contrassegnare i ticket quando è necessario sostituire un disco, ma il disco stesso non è sul posto. Ciò accade nel caso di CDN e siti remoti.

Abbiamo anche aggiunto lo stato Pronto. Il biglietto viene trasferito su di esso dopo aver sostituito il disco. Cioè è già stato fatto tutto, ma il RAID HW/SW è sincronizzato sul server. Questo può richiedere molto tempo.

Se nel lavoro è coinvolto un amministratore, lo schema diventa un po’ più complicato.

Dallo stato Apri Il ticket può essere tradotto sia dall'amministratore di sistema che dal tecnico. Nello stato in corso l'amministratore rimuove il disco dalla rotazione in modo che l'ingegnere possa semplicemente estrarlo: accende la retroilluminazione, smonta il disco, interrompe le applicazioni, a seconda del gruppo specifico di server.

Il biglietto viene quindi trasferito a Pronto a cambiare: Questo è un segnale al tecnico che il disco può essere estratto. Tutti i campi in Jira sono già compilati, l'ingegnere sa quale tipo e dimensione del disco. Questi dati vengono inseriti automaticamente nello stato precedente o dall'amministratore.

Dopo aver sostituito il disco, lo stato del ticket passa a Cambiato. Controlla che sia stato inserito il disco corretto, che il partizionamento sia stato eseguito, che l'applicazione venga avviata e che vengano avviate alcune attività di ripristino dei dati. Il biglietto può anche essere trasferito nello stato Pronto, in questo caso la responsabilità resterà dell'amministratore, perché ha messo in rotazione il disco. Il diagramma completo è simile a questo.

L'aggiunta di nuovi campi ci ha reso la vita molto più semplice. I ragazzi hanno iniziato a lavorare con informazioni strutturate, è diventato chiaro cosa era necessario fare e in quale fase. Le priorità sono diventate molto più rilevanti, poiché ora vengono stabilite dall'amministratore.

Non c'è bisogno di chat. Certo, l'amministratore può scrivere all'ingegnere "questo deve essere sostituito più velocemente" oppure "è già sera, avrai tempo per sostituirlo?" Ma non comunichiamo più quotidianamente nelle chat su questi temi.

I dischi iniziarono a essere cambiati in lotti. Se l'amministratore è arrivato al lavoro un po' presto, ha tempo libero e non è ancora successo nulla, può preparare un numero di server per la sostituzione: compilare i campi, rimuovere i dischi dalla rotazione e trasferire l'attività a un ingegnere. L'ingegnere arriva al data center poco dopo, vede l'attività, prende le unità necessarie dal magazzino e le sostituisce immediatamente. Di conseguenza, il tasso di sostituzione è aumentato.

Lezioni apprese durante la creazione del flusso di lavoro

• Quando si costruisce una procedura, è necessario raccogliere informazioni da diverse fonti.
  Alcuni dei nostri amministratori non sapevano che l'ingegnere cambia lui stesso i dischi. Alcune persone pensavano che la sincronizzazione MD RAID fosse gestita da ingegneri, anche se alcuni di loro non avevano nemmeno l'accesso per farlo. Alcuni importanti ingegneri lo hanno fatto, ma non sempre perché il processo non è stato descritto da nessuna parte.
• La procedura dovrebbe essere semplice e comprensibile.
  È difficile per una persona tenere a mente molti passaggi. Gli stati vicini più importanti in Jira dovrebbero essere posizionati nella schermata principale. Puoi rinominarli, ad esempio, chiameremo In corso Pronto a cambiare. E altri stati possono essere nascosti in un menu a discesa in modo che non siano un pugno nell'occhio. Ma è meglio non limitare le persone, dare loro l’opportunità di compiere la transizione.
  Spiegare il valore dell'innovazione. Quando le persone capiscono, accettano di più la nuova procedura. Per noi era molto importante che le persone non cliccassero lungo l'intero processo, ma lo seguissero. Quindi abbiamo creato l'automazione su questo.
• Aspetta, analizza, scoprilo.
  Abbiamo impiegato circa un mese per costruire la procedura, l'implementazione tecnica, gli incontri e le discussioni. E l’implementazione richiede più di tre mesi. Ho visto come le persone stanno lentamente iniziando a utilizzare l'innovazione. C'era molta negatività nelle prime fasi. Ma era completamente indipendente dalla procedura stessa e dalla sua implementazione tecnica. Ad esempio, un amministratore non ha utilizzato Jira, ma il plug-in Jira in Confluence e alcune cose non erano disponibili per lui. Gli abbiamo mostrato Jira e la produttività dell'amministratore è aumentata sia per le attività generali che per la sostituzione dei dischi.

Automazione della sostituzione del disco

Ci siamo avvicinati più volte all'automazione della sostituzione del disco. Avevamo già sviluppi e script, ma funzionavano tutti in modo interattivo o manuale e richiedevano l'avvio. E solo dopo aver introdotto la nuova procedura ci siamo resi conto che era proprio quello che ci mancava.

Poiché ora il nostro processo di sostituzione è suddiviso in fasi, ognuna delle quali ha un esecutore specifico e un elenco di azioni, possiamo abilitare l'automazione in fasi e non tutta in una volta. Ad esempio, la fase più semplice, Pronto (controllo RAID/sincronizzazione dei dati), può essere facilmente delegata a un bot. Quando il bot avrà imparato un po', potrai assegnargli un compito più importante: mettere in rotazione il disco, ecc.

Allestimenti dello zoo

Prima di parlare del bot, facciamo una breve escursione nel nostro zoo di installazioni. Innanzitutto è dovuto alle dimensioni gigantesche delle nostre infrastrutture. In secondo luogo, proviamo a selezionare la configurazione hardware ottimale per ciascun servizio. Abbiamo circa 20 modelli RAID hardware, principalmente LSI e Adaptec, ma ci sono anche HP e DELL in diverse versioni. Ogni controller RAID dispone della propria utilità di gestione. L'insieme di comandi e la loro emissione possono differire da versione a versione per ciascun controller RAID. Laddove non viene utilizzato HW-RAID, è possibile utilizzare mdraid.

Eseguiamo quasi tutte le nuove installazioni senza backup del disco. Cerchiamo di non utilizzare più RAID hardware e software, poiché eseguiamo il backup dei nostri sistemi a livello di data center, non di server. Ma ovviamente ci sono molti server legacy che devono essere supportati.

Da qualche parte i dischi nei controller RAID vengono trasferiti su dispositivi grezzi, da qualche parte vengono utilizzati i JBOD. Esistono configurazioni con un disco di sistema nel server e, se deve essere sostituito, è necessario reinstallare il server con l'installazione del sistema operativo e delle applicazioni, delle stesse versioni, quindi aggiungere file di configurazione, avviare le applicazioni. Esistono anche molti gruppi di server in cui il backup viene eseguito non a livello del sottosistema del disco, ma direttamente nelle applicazioni stesse.

In totale, disponiamo di oltre 400 gruppi di server unici che eseguono quasi 100 applicazioni diverse. Per coprire un numero così elevato di opzioni, avevamo bisogno di uno strumento di automazione multifunzionale. Preferibilmente con una semplice DSL, in modo che non solo chi lo ha scritto possa supportarlo.

Abbiamo scelto Ansible perché è agentless: non c'era bisogno di predisporre l'infrastruttura, un avvio veloce. Inoltre, è scritto in Python, che è accettato come standard all'interno del team.

Schema generale

Diamo un'occhiata allo schema di automazione generale utilizzando un incidente come esempio. Zabbix rileva che il disco sdb è guasto, il trigger si accende e viene creato un ticket in Jira. L'amministratore lo guardò, si accorse che non era un duplicato e non un falso positivo, cioè il disco doveva essere cambiato, e trasferì il ticket in In progress.

L'applicazione DiskoBot, scritta in Python, interroga periodicamente Jira per nuovi ticket. Si nota che è apparso un nuovo ticket In progress, viene attivato il thread corrispondente, che avvia il playbook in Ansible (questo viene fatto per ogni stato in Jira). In questo caso viene avviato Prepare2change.

Ansible viene inviato all'host, rimuove il disco dalla rotazione e segnala lo stato all'applicazione tramite callback.

In base ai risultati, il bot trasferisce automaticamente il ticket su Pronto a cambiare. L'ingegnere riceve una notifica e va a cambiare il disco, dopodiché trasferisce il ticket su Modificato.

Secondo lo schema sopra descritto, il ticket torna al bot, che lancia un altro playbook, va all'host e mette in rotazione il disco. Il bot chiude il ticket. Evviva!

Parliamo ora di alcuni componenti del sistema.

Discobot

Questa applicazione è scritta in Python. Seleziona i biglietti da Jira secondo JQL. A seconda dello stato del ticket, quest'ultimo va al gestore corrispondente, che a sua volta lancia il playbook Ansible corrispondente allo stato.

JQL e gli intervalli di polling sono definiti nel file di configurazione dell'applicazione.

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

Ad esempio, tra i ticket nello stato In corso, vengono selezionati solo quelli con i campi Dimensione disco e Nome dispositivo compilati. Il nome del dispositivo è il nome del dispositivo a blocchi necessario per eseguire il playbook. La dimensione del disco è necessaria in modo che l'ingegnere sappia quale dimensione del disco è necessaria.

Inoltre, tra i ticket con stato Pronto, i ticket con l'etichetta dbot_ignore vengono filtrati. A proposito, utilizziamo le etichette Jira sia per tale filtraggio che per contrassegnare i biglietti duplicati e raccogliere statistiche.

Se un playbook fallisce, Jira assegna l'etichetta dbot_failed in modo che il problema possa essere risolto in seguito.

Interoperabilità con Ansible

L'applicazione comunica con Ansible tramite API Ansible Python. A playbook_executor passiamo il nome del file e un insieme di variabili. Ciò consente di mantenere il progetto Ansible sotto forma di normali file yml, anziché descriverlo nel codice Python.

Anche in Ansible, tramite *extra_vars*, il nome del dispositivo a blocchi, lo stato del ticket, nonché callback_url, che contiene la chiave di rilascio - viene utilizzato per il callback in HTTP.

Per ogni lancio viene generato un inventario temporaneo, composto da un host e dal gruppo a cui appartiene tale host, in modo che vengano applicati group_vars.

Di seguito è riportato un esempio di attività che implementa il callback HTTP.

Otteniamo il risultato dell'esecuzione dei playbook utilizzando i callaback(s). Sono di due tipi:

• Plug-in di richiamata Ansible, fornisce dati sui risultati dell'esecuzione del playbook. Descrive le attività avviate, completate con successo o senza successo. Questa richiamata viene chiamata al termine della riproduzione del playbook.
• Richiamata HTTP per ricevere informazioni durante la riproduzione di un playbook. Nell'attività Ansible eseguiamo una richiesta POST/GET alla nostra applicazione.

Le variabili vengono passate attraverso callback HTTP definiti durante l'esecuzione del playbook e che vogliamo salvare e utilizzare nelle esecuzioni successive. Scriviamo questi dati in sqlite.

Lasciamo anche commenti e modifichiamo lo stato del ticket tramite richiamata HTTP.

Richiamata 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

Come molte attività dello stesso tipo, lo inseriamo in un file comune separato e lo includiamo se necessario, in modo da non ripeterlo costantemente nei playbook. Ciò include l'URL callback_, che contiene la chiave del problema e il nome host. Quando Ansible esegue questa richiesta POST, il bot capisce che si è verificata come parte di questo o quell'incidente.

Ed ecco un esempio dal playbook, in cui produciamo un disco da un dispositivo 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

Questa attività trasferisce il ticket Jira allo stato "Pronto per la modifica" e aggiunge un commento. Inoltre, la variabile mdam_data memorizza un elenco di dispositivi md da cui è stato rimosso il disco e parted_info memorizza un dump della partizione da parted.

Quando l'ingegnere inserisce un nuovo disco, possiamo utilizzare queste variabili per ripristinare il dump della partizione, nonché inserire il disco nei dispositivi md da cui è stato rimosso.

Modalità di controllo Ansible

È stato spaventoso accendere l'automazione. Pertanto, abbiamo deciso di eseguire tutti i playbook nella modalità
funzionamento a secco, in cui Ansible non esegue alcuna azione sui server, ma si limita a emularli.

Tale lancio viene eseguito tramite un modulo di callback separato e il risultato dell'esecuzione del playbook viene salvato in Jira come commento.

In primo luogo, ciò ha permesso di convalidare il lavoro del bot e dei playbook. In secondo luogo, ha aumentato la fiducia degli amministratori nel bot.

Quando abbiamo superato la convalida e ci siamo resi conto che è possibile eseguire Ansible non solo in modalità di prova, abbiamo creato un pulsante Esegui Diskobot in Jira per avviare lo stesso playbook con le stesse variabili sullo stesso host, ma in modalità normale.

Inoltre, il pulsante viene utilizzato per riavviare il playbook in caso di arresto anomalo.

Struttura dei playbook

Ho già detto che, a seconda dello stato del ticket Jira, il bot avvia diversi playbook.

Innanzitutto è molto più semplice organizzare l’ingresso.
In secondo luogo, in alcuni casi è semplicemente necessario.

Ad esempio, quando si sostituisce un disco di sistema, è necessario prima accedere al sistema di distribuzione, creare un'attività e, dopo la corretta distribuzione, il server diventerà accessibile tramite ssh e sarà possibile distribuire l'applicazione su di esso. Se facessimo tutto questo in un unico playbook, Ansible non sarebbe in grado di completarlo perché l'host non è disponibile.

Utilizziamo ruoli Ansible per ciascun gruppo di server. Qui puoi vedere come sono organizzati i playbook in uno di essi.

Questo è comodo perché è immediatamente chiaro dove si trovano le attività. In main.yml, che è l'input per il ruolo Ansible, possiamo semplicemente includere tramite lo stato del ticket o le attività generali richieste a tutti, ad esempio passare l'identificazione o ricevere un token.

Investigazione.yml

Viene eseguito per i ticket con stato Investigazione e Aperto. La cosa più importante per questo playbook è il nome del dispositivo a blocchi. Questa informazione non è sempre disponibile.

Per ottenerlo analizziamo il riepilogo di Jira, l'ultimo valore del trigger Zabbix. Potrebbe contenere il nome del dispositivo a blocchi: fortunato. Oppure potrebbe contenere un punto di montaggio, quindi è necessario andare al server, analizzarlo e calcolare il disco richiesto. Il trigger può anche trasmettere un indirizzo SCSI o altre informazioni. Ma succede anche che non ci siano indizi e bisogna analizzare.

Dopo aver scoperto il nome del dispositivo a blocchi, raccogliamo da esso informazioni sul tipo e sulla dimensione del disco per compilare i campi in Jira. Rimuoviamo anche le informazioni su fornitore, modello, firmware, ID, SMART e inseriamo tutto questo in un commento nel ticket Jira. L'amministratore e il tecnico non devono più cercare questi dati. 🙂

prepare2change.yml

Rimozione del disco dalla rotazione, preparazione alla sostituzione. La fase più difficile e importante. Qui è dove puoi interrompere l'applicazione quando non dovrebbe essere interrotta. Oppure estrarre un disco che non aveva abbastanza repliche e quindi avere un effetto sugli utenti, perdendo alcuni dati. Qui abbiamo il maggior numero di controlli e notifiche nella chat.

Nel caso più semplice si tratta della rimozione di un disco da un RAID HW/MD.

Nelle situazioni più complesse (nei nostri sistemi di storage), quando il backup viene eseguito a livello applicativo, è necessario accedere all'applicazione tramite API, segnalare l'output del disco, disattivarlo e avviare il ripristino.

Ora stiamo migrando in massa verso nuvolae se il server è basato su cloud, Diskobot chiama l'API cloud, dice che funzionerà con questo servitore - il server che esegue i contenitori - e chiede "migra tutti i contenitori da questo servitore". E allo stesso tempo accende la retroilluminazione del disco in modo che l'ingegnere possa immediatamente vedere quale deve essere estratto.

cambiato.yml

Dopo aver sostituito un disco, ne controlliamo innanzitutto la disponibilità.

Gli ingegneri non installano sempre nuove unità, quindi abbiamo aggiunto un controllo per i valori SMART che ci soddisfano.

Quali attributi stiamo esaminando?Conteggio settori riallocati (5) < 100
Conteggio settore attuale in sospeso (107) == 0

Se l'unità non supera il test, al tecnico viene inviata una notifica per sostituirla nuovamente. Se tutto è in ordine, la retroilluminazione si spegne, vengono applicati i contrassegni e il disco viene messo in rotazione.

pronto.yml

Il caso più semplice: verificare la sincronizzazione raid HW/SW o terminare la sincronizzazione dei dati nell'applicazione.

API dell'applicazione

Ho menzionato più volte che il bot accede spesso alle API dell'applicazione. Naturalmente non tutte le applicazioni disponevano dei metodi necessari, quindi è stato necessario modificarle. Ecco i metodi più importanti che utilizziamo:

• Stato. Stato di un cluster o di un disco per capire se è possibile lavorarci;
• Avvia/arresta. Attivazione/disattivazione del disco;
• Migrare/ripristinare. Migrazione e ripristino dei dati durante e dopo la sostituzione.

Lezioni apprese da Ansible

Adoro Ansible. Ma spesso, quando guardo diversi progetti opensource e vedo come le persone scrivono playbook, mi spavento un po’. Complessi intrecci logici di quando/loop, mancanza di flessibilità e idempotenza dovuti all'uso frequente di shell/command.

Abbiamo deciso di semplificare tutto il più possibile, sfruttando il vantaggio di Ansible: la modularità. Al livello più alto ci sono i playbook; possono essere scritti da qualsiasi amministratore, sviluppatore di terze parti che conosca un po' Ansible.

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

Se una parte della logica è difficile da implementare nei playbook, la spostiamo in un modulo o filtro Ansible. Gli script possono essere scritti in Python o in qualsiasi altro linguaggio.

Sono facili e veloci da scrivere. Ad esempio, il modulo di retroilluminazione del disco, un esempio del quale è mostrato sopra, è composto da 265 linee.

Al livello più basso c'è la biblioteca. Per questo progetto abbiamo scritto un'applicazione separata, una sorta di astrazione su RAID hardware e software che esegue le richieste corrispondenti.

I maggiori punti di forza di Ansible sono la sua semplicità e i suoi schemi chiari. Credo che tu debba usarlo e non generare file yaml spaventosi e un numero enorme di condizioni, codice shell e loop.

Se vuoi ripetere la nostra esperienza con l'API Ansible, tieni a mente due cose:

• A Playbook_executor e ai playbook in generale non è possibile concedere un timeout. C'è un timeout nella sessione ssh, ma non c'è alcun timeout nel playbook. Se proviamo a smontare un disco che non esiste più nel sistema, il playbook verrà eseguito all'infinito, quindi abbiamo dovuto racchiudere il suo avvio in un wrapper separato e terminarlo con un timeout.
• Ansible viene eseguito su processi biforcati, quindi la sua API non è thread-safe. Eseguiamo tutti i nostri playbook a thread singolo.

Di conseguenza, siamo riusciti ad automatizzare la sostituzione di circa l'80% dei dischi. Nel complesso, il tasso di sostituzione è raddoppiato. Oggi l'amministratore esamina semplicemente l'incidente e decide se il disco deve essere cambiato o meno, quindi fa un clic.

Ma ora stiamo iniziando a riscontrare un altro problema: alcuni nuovi amministratori non sanno come cambiare unità. 🙂

Fonte: habr.com