Come testare il provisioning e la configurazione nell'installazione Ansible?

Cercando di provare a creare un po 'di resilienza nella nostra configurazione Ansible che si occupa di provisioning e configurazione.

Comprendo alcuni metodi di test sul lato della configurazione delle cose, ma mi chiedo come implementare meglio i test sul lato del provisioning delle cose e se ci sono strumenti che possono aiutare con questo tipo di implementazione.

Attualmente molti dei nostri test vengono eseguiti in serie durante il playbook, il che ha molto senso per cose come "è arrivato il servizio; è il vip disponibile; ha terminato questo compito asincrono", ma ciò che veramente mi preoccupa è la nostra capacità di gestire la deriva di configurazione a livello di applicazione e di provisioning (come la configurazione della macchina virtuale). Sono consapevole che Ansible non è lo strumento migliore per lavorare con la deriva della configurazione, ma sono curioso di vedere le tue opinioni.

Se hai qualcosa per automatizzare completamente il processo ancora meglio. (abbiamo alcuni brutti script che riportano quotidianamente in forma rilassata).

Nota : al momento abbiamo alcune condizioni in cui potrebbe verificarsi una riprovision (ad es. Ricostruzione da backup, problema di sistemi critici) ma in genere passa in rassegna alcune delle attività di configurazione rispondenti e non ci pensa più.

Alcune opzioni là fuori ..

Strumenti di test: ordinati per stelle github

• Serverspec - Ruby, lo strumento più popolare là fuori, costruito su rspec di ruby
• Goss - YAML, semplice, binario autonomo <10 MB, estremamente veloce, può generare test dallo stato del sistema
• Inspec - Ruby, lo considera un serverpec migliorato, quasi la stessa sintassi, creato dai ragazzi dello chef. Costruito per essere più semplice da estendere rispetto a serverpec
• Testinfra - Python, ha la caratteristica interessante di poter usare l'inventario / i varianti di Ansible

Principali differenze tra loro:

Alla fine, suggerirei di trascorrere una giornata a sperimentare con tutti loro per avere un'idea per loro prima di decidere da soli.

• Ad eccezione di Goss, tutti i framework possono essere eseguiti su una macchina remota (es. Su ssh). Goss funziona solo localmente o nella finestra mobile con dgoss.
• Tutti i framework possono essere eseguiti localmente su un server, ma richiedono l'installazione o l'incorporamento di Python o Ruby. Inspec fornisce un pacchetto autonomo <150 MB con una versione integrata di ruby. Goss è un singolo binario <10 MB senza dipendenze esterne.
• Goss ha integrato il supporto per l'output nagios / sensu, ciò consente una più facile integrazione con gli strumenti di monitoraggio.
• I test di goss tendono ad essere più semplici, ma meno flessibili poiché basati su YAML. Altri framework consentono di sfruttare tutta la potenza del linguaggio sottostante Python / Ruby per scrivere test o estendere le funzionalità dello strumento. (semplicità vs flessibilità)
• Goss ti consente di generare test dallo stato attuale del sistema
• Per quanto ne so, Testinfra è l'unico che ha il supporto integrato per l'inventario e le variabili responsabili
• Inspec è supportato da Chef

Test continuo / divergenza:

• Conformità dello chef : collabora con inspec per testare continuamente i server, i prodotti a pagamento
• Goss - Può essere facilmente agganciato a Nagios o Sensu. Supporta inoltre l'esposizione dei test del server come endpoint http.

Test di imbracature per lo sviluppo:

• cucina - Testing harness tool, avvia istanza, esegue il codice di gestione della configurazione, esegue la suite di test. Realizzato dai ragazzi dello chef
• Molecola - Simile alla cucina di prova, ma scritta appositamente per ansible

Full Disclosure: sono l'autore di goss

AGGIORNAMENTO: InSpec 4.xo superiore utilizza una licenza mista commerciale / open source - vedi commenti.

I due strumenti che ho visto per questo sono InSpec e ServerSpec . Serverspec è uno strumento basato su Ruby che si basa su RSpec . InSpec si ispira a RSpec e ServerSpec.

Ho usato ServerSpec. È bello, ma forse non stabile al 100%. Ho avuto problemi con i test per versioni specifiche di software su Ubuntu.

Ho letto i documenti InSpec ma non ho approfondito. Fa essenzialmente la stessa cosa di Serverspec.

A giudicare dagli impegni di Github, sembra che il lavoro su ServerSpec sia leggermente diminuito, mentre InSpec si sta appena intensificando.

AGGIORNAMENTO: InSpec 4.xo superiore utilizza una licenza mista commerciale / open source - vedi commenti.

Quando si utilizzano strumenti di gestione della configurazione, come Ansible, lo strumento stesso sarebbe responsabile di impedire la deriva della configurazione. Dopo aver utilizzato Ansible per impostare una determinata configurazione, l'esecuzione ripetitiva di Ansible assicurerà che la configurazione sia come definita. Questo richiede anche che il tuo codice Ansible sia scritto in modo idempotente.

Alla luce di quanto sopra, è possibile ottenere il provisioning dei test eseguendo i playbook Ansible in loop da alcuni server. Ad esempio, un lavoro cron, o Jenkins, può eseguire i playbook ogni 30 minuti e riferire in caso di errore. Non avere errori significa che la tua configurazione è sotto controllo, avere errori significa che c'è un problema nel portare i server nello stato desiderato .

Nel caso in cui non ci si possa fidare che il proprio codice sia scritto come idempotente, e quindi non è possibile eseguire Ansible ripetutamente in un ciclo da un server automatico, esiste una soluzione alternativa. Puoi fare come sopra (esegui Ansible in un ciclo) ma usa la sua modalità di esecuzione a secco . Ogni volta che Ansible segnala che sono necessarie modifiche, il lavoro Jenkins (o cron job) può avvisare che la configurazione fornita è stata modificata e che i server non sono nello stato desiderato .

Per assicurarti che il tuo codice Ansible stia effettivamente facendo quello che pensi che dovrebbe fare, si applicano le soluzioni menzionate da Dave Swersky. Sia InSpec che Serverspec sono strumenti che verificano in modo diverso che i tuoi playbook facciano realmente ciò che intendi. Un ottimo modo per eseguire questo tipo di strumenti in ambienti di test (anche contenitori docker) è usare kitchen.ci che gestisce tutta la colla tra i vari strumenti di test all'interno dell'unità e l'esecuzione dei tuoi playbook / moduli / libri di cucina.

Kitchen.ci è stato originariamente utilizzato per testare i libri di cucina dello chef, ma esistono plugin per Ansible e altri strumenti CM.

Test Kitchen ha un plug-in di provisioning in cucina per il test del codice Ansible. Non è così profondo come l'integrazione dello Chef, ma svolge il lavoro nella maggior parte dei casi. Esiste anche il più recente progetto Molecule che è un sistema di test Ansible dedicato.

È possibile tenere traccia delle discrepanze / deriva della configurazione / dell'infrastruttura utilizzando Outthentic , è facile creare una suite di test per "correggere" lo stato desiderato ed eseguirlo nuovamente ogni volta che è necessario tenere traccia delle modifiche indesiderate.