Infrastruttura come codice e TDD

Infrastruttura come codice ci dice di utilizzare strumenti che automatizzano le build. Grande. Strumenti come ansible , chef , burattino , catasta di sale e altri ci spingono a scrivere come appare l'infrastruttura, risolvendo le differenze.

In Salt Stack quei bit sono chiamati stati . Se lo stato non corrisponde alla realtà, lo strumento lo risolverà per noi. In altre parole: stiamo scrivendo un test per la nostra infrastruttura e se il test fallisce, lo strumento lo risolverà da solo. Almeno questa è l'idea.

XP ci insegna a usare TDD e la domanda è se è applicabile all'infrastruttura? Gli strumenti suggeriscono che lo sia.

Posso immaginare alcuni tipi di test che possono essere molto utili.

Scriviamo test del fumo in bundle con il servizio distribuito per garantire che il servizio distribuito end-to-end funzioni e funzioni come previsto. Questa sarebbe una chiamata API o / e un controllo systemctl per assicurarsi che ciò che abbiamo appena distribuito funzioni. Molte di queste funzionalità possono essere coperte negli stessi stati poiché strumenti come Ansible hanno stati per assicurarsi che un servizio sia in esecuzione.

Esiste un progetto Molecule che consente di eseguire ruoli individuali (come ansible chiama i suoi stati) contro docker o un altro motore di virtualizzazione temporaneo. Ciò costringe a disaccoppiare i ruoli e consente di eseguirli separatamente dal playbook mentre ci si lavora. I test consentono principalmente di deridere le variabili con cui il ruolo dovrebbe funzionare. Altri esempi sembrano una duplicazione del motore ansible (asserire che un file appartiene a un utente ...).

ThoughtWorks techradar momento loda strumenti come 'ispezione , serverspec o Goss per la convalida che il server soddisfi le specifiche. Ma stiamo scrivendo una specifica, no?

Quindi, è utile approfondire le infrastrutture se stiamo descrivendo l'infrastruttura in stati / ruoli? Potrei sospettare che questo diventi più richiesto nelle organizzazioni più grandi in cui un team fornisce le specifiche e ne seguono altri, oppure se esiste un ampio set di ruoli, potresti voler eseguire un sottoinsieme di questi e ottenere un vantaggio in termini di velocità dai test? Faccio fatica a capire perché potresti scrivere un test se potessi avere in mente un ruolo / stato per la stessa domanda.

In breve, vedo due categorie di test per la tua infrastruttura: 1) ha tutto il necessario per eseguire la tua applicazione e 2) non ha elementi superflui.

Innanzitutto, è possibile trattare la suite di test del proprio software come una sorta di "meta test" per la propria infrastruttura. Fintanto che crei l'infrastruttura da zero per ogni esecuzione di test e la suite di test viene eseguita completamente su quell'infrastruttura (ovvero, non utilizza servizi esterni), il fatto che l'intera suite sia verde significa che anche l'infrastruttura codificata è sufficiente .

In secondo luogo, soprattutto dal punto di vista della sicurezza, è possibile scrivere test sulla propria infrastruttura. Vale a dire, se una parte della tua infrastruttura è una VM che esegue Linux, potresti scrivere un test che esegue una scansione delle porte su quella VM, per assicurarti che non ci siano porte involontarie aperte, che potrebbero essere state installate da un apt-get installeffetto collaterale non intenzionale . Oppure è possibile scrivere test che controllano se eventuali file imprevisti sono stati modificati dopo il completamento della suite di test corretta. Oppure potresti controllare gli psoutput delle tue VM o dei container Docker per processi imprevisti e simili, creare liste bianche ecc. E ottenere così una notifica automatica se alcuni pacchetti di terze parti cambiassero in modo non documentato (o inosservato) in qualche aggiornamento.

Questo secondo tipo di test è, in un certo senso, simile a quello che faresti comunque in un'impostazione classica delle operazioni, vale a dire, rafforzare i tuoi server e controllare le intrusioni, evitando la piena risorsa e così via.

IMHO è piuttosto ridondante per scrivere test TDD per articoli interamente coperti dalla specifica dello stato IaaC. Ciò implica che l'efficacia di IaaC è discutibile - perché dovresti utilizzarlo in tal caso?

Guardandolo da un diverso potenziale IaaC stesso (se / se fatto correttamente) incorpora capacità già testate e considerate funzionanti in modo affidabile. Questo è ciò che lo rende attraente e che rende superflua la scrittura di test di abbinamento TDD.

Ad esempio, una configurazione IaaC che specifica un sistema con SSH installato incorpora già un controllo affidabile per SSH installato correttamente e, in caso contrario, meccanismi per installarlo correttamente. Il che rende un test TDD per verificare se SSH è installato ridondante. Se la configurazione IaaC specifica anche che sshd deve essere avviato e in ascolto su una porta specifica, anche i test TDD per l'esecuzione e l'ascolto di sshd sulla rispettiva porta sarebbero ridondanti.

Nota che la mia risposta non riguarda il TDD o qualsiasi altro tipo di test che verifica se la tua configurazione IaaC nel suo insieme si adatta a un determinato scopo. Ciò rimane valido e può essere utilizzato in TDD, CI o controlli simili durante lo sviluppo di quella specifica IaaC - credo che la risposta di @ AnoE sia applicabile in questo caso.

Sembra che tutti qui presumano che uno strumento IAC funzioni sempre come previsto, ma posso dire (dalla mia esperienza) che non è sempre così, altrimenti il ​​test unitario sarebbe effettivamente inutile.

Ricordo un'immagine che diceva "Il playbook di Ansible funzionava, tutto bene" con un edificio in fiamme sullo sfondo ...

Gestire uno stato dichiarativo e avere il server in questo stato dichiarato effettivo sono almeno 2 cose diverse dal mio punto di vista ed esperienza.

Un ambiente ampio ed eterogeneo, distribuito su più DC, raggiungibile attraverso la rete pubblica ecc ... Vi sono molteplici ragioni per le quali uno stato non può essere applicato, in tutto o in parte.

Per tutti questi motivi, c'è spazio per unit test che consente di ottenere un'istantanea dello stato effettivo del server, che, di nuovo, potrebbe differire dallo stato mirato.

Quindi direi di sì, i test unitari sono utili anche in un ambiente gestito IAC.

MODIFICARE

Che dire del lato di non regressione del ramo dev della base di codice IaC? quindi faresti modifiche al tuo codice nel ramo dev e lo uniresti al ramo prod sperando di non rompere tutto? i test unitari sono così preziosi, e di solito semplici da implementare, non vedo perché si debba programmare senza questa funzione.

Riferimento (in francese scusatemi per quello): https://fr.slideshare.net/logilab/testinfra-pyconfr-2017

Nella mia esperienza, una delle principali differenze tra Dev e Ops sono le "dipendenze del tempo di esecuzione pesante". L'installazione di pacchetti dipende in larga misura da repository, reti o chiavi valide o, per esempio, dall'istanza di un nuovo server cloud, dipende dalle risorse del provider.

In termini di provisioning del server anche se non hai modificato il codice di provisioning, l'immagine sarà valida la maggior parte delle volte, ma a volte no. Quindi penso che i test siano davvero essenziali per fornire immagini di lavoro.

Se vai oltre i singoli server le cose peggiorano ancora ... come testerai la raggiungibilità in tutte le configurazioni di rete? Compresi risoluzione DNS, routing e firewalling? Anche se l'API del tuo provider IaaC funziona come previsto (ho visto problemi cablati in quest'area) In questo caso mi piace molto il TDD.

Poiché non ho trovato alcun strumento di test in quest'area, ne abbiamo scritto uno nel nostro tempo libero: https://github.com/DomainDrivenArchitecture/dda-serverspec-crate

Quindi penso che TDD sia davvero importante nel mondo DevOps!