Integrazione continua tramite Docker

Question

Integrazione continua tramite Docker

#1 da (1 voti)
#2 da (0 voti)

5

Uno dei principali vantaggi di Docker è l'ambiente isolato che porta, e voglio sfruttare questo vantaggio nel mio flusso di lavoro di integrazione continua.

Un flusso di lavoro della configurazione "normale" è simile a questo:

Archivio sondaggi per le modifiche
Estrai dal repository
Installa le dipendenze
Esegui test

In un flusso di lavoro Dockerized, sarebbe qualcosa di simile a questo:

Archivio sondaggi per le modifiche
Estrai dal repository
Crea immagine finestra mobile
Esegui immagine finestra mobile come contenitore
Esegui test
Elimina il contenitore mobile

Il mio problema è con il passaggio "Esegui test": poiché Docker è un ambiente isolato, intuitivamente mi piacerebbe trattarlo come uno; questo significa che i metodi di comunicazione preferiti sono le prese. Tuttavia, questo funziona bene solo in determinate situazioni (una webapp, per esempio). Quando si testano diversi tipi di servizi (ad esempio, un servizio in background che comunica solo con un database), sarebbe necessario un approccio diverso.

Qual è il modo migliore per affrontare questo problema? È un problema con il design della mia applicazione e dovrei progettarlo in un TDD più orientato al servizio che ascolti sempre su qualche socket? O dovrei semplicemente rinunciare all'isolamento, e fare qualcosa del genere:

Archivio sondaggi per le modifiche
Estrai dal repository
Crea immagine finestra mobile
Esegui immagine finestra mobile come contenitore
Apri la sessione SSH nel contenitore
Esegui test
Elimina il contenitore mobile

L'inserimento di SS nel contenitore mi sembra una brutta soluzione, poiché richiede una profonda conoscenza del contenuto del contenitore e quindi rompere l'isolamento.

Mi piacerebbe sentire i diversi approcci di SO a questo problema.

testing continuous-integration docker

posta Leon Mergen 10.06.2014 - 06:06

fonte

2 risposte

Leggi altre domande sui tag testing continuous-integration docker

Licenze GPLv3 e app Web Software-as-a-Service [duplicate] Che cos'è una licenza e come posso usare il codice sotto una licenza?

score 1 · Answer 1

È possibile invertire la logica spostando il corridore di prova sull'immagine mobile:

I test vengono eseguiti all'interno dell'immagine della finestra mobile, quindi accedono all'applicazione come in qualsiasi altro contesto e la presenza della finestra mobile non cambia nulla.
I risultati del test di aggregazione sono dove la connessione diventa un problema. L'attuale tecnologia utilizzata dipenderà dalla tua attuale infrastruttura. Potrebbe anche essere una coda di messaggi, un'API personalizzata o un accesso diretto al database.
Poiché appartiene al processo eseguito all'interno di un'immagine mobile per segnalare i risultati del test e non al servizio centrale per estrarre i risultati dai test runner, significa che ancora una volta la presenza dell'immagine docker non non fare alcuna differenza.

score 0 · Answer 2

Un modo abbastanza standard per eseguire test con le immagini Docker è:

Crea un'immagine di prova, in base all'immagine che stai testando, ma aggiungendo il test runner e i test. (Non devi farlo, potresti includere tutti i test nell'immagine di base, ma è più semplice separarli).
La comunicazione con le immagini Docker viene spesso eseguita in modo pulito con sovrapposizioni di file system. Quindi, installa una directory dall'host nel contenitore (ad esempio con -v /path/to/workspace/:/tests o qualcosa di simile).
Il test runner potrebbe generare un file di risultati, ad es. junit.xml o qualcosa del genere. Se viene esportato nella cartella / tests, l'ambiente CI può essere prelevato da lì.
richiama il runner di prova sostituendo il punto di accesso sulla riga docker run . Per esempio. docker run container --entrypoint=/test-runner.py (o qualsiasi cosa sia appropriata per la tua applicazione). Questo funziona bene per i test unitari.

Per i test di integrazione, in genere devi orchestrare lo spin-up di diversi contenitori all'esterno di Docker.