2016-01-18 24 views
6

Sto lavorando su un servizio in un 'sistema' orchestrato tramite docker-compose. Il servizio è scritto in un linguaggio compilato e ho bisogno di ricostruirlo quando apporto una modifica. Sto cercando di trovare il modo migliore per scorrere rapidamente le modifiche.Flusso di lavoro di sviluppo Docker per componenti compilati in una finestra mobile: comporre il setup

Ho provato 2 "flussi di lavoro", entrambi si basano sull'essere collegati alla directory di origine tramite uno volume: per ottenere l'ultima fonte.

A.
  • far apparire tutti i contenitori di supporto con docker-compose up -d
  • Arrestare il contenitore per il servizio in fase di sviluppo
  • eseguire un nuovo contenitore utilizzando l'immagine docker-compose run --name SERVICE --rm SERVICE /bin/bash
  • All'interno di questa corsa contenitore compilare ed eseguire l'applicazione alla porta esposta.
  • Riavviare arrestando il processo in esecuzione e quindi ricostruendo.
B.
  • (richiede Dockerfile CMD per costruire e quindi eseguire il servizio)
  • Arrestare il servizio: docker-compose kill SERVICE
  • Riavviare il servizio docker-compose up -d --no-deps SERVICE

Il problema è sia impiegare troppo tempo per riavviare o riavviare il servizio localmente (in esecuzione sul mio portatile in modo indipendente o f docker). Questa configurazione sembra essere ok con linguaggi interpretati che possono hot-ricaricare i file modificati, ma non ho ancora trovato un sistema sufficientemente veloce per servizi linguistici compilati.

+1

La finestra mobile è in esecuzione sul laptop o in remoto? Ti chiedi cosa intendi con "vs riavviare il servizio localmente". Che cosa sta causando il "troppo lungo per riavviarlo"? La compilazione è più lenta? Di partenza? – thaJeztah

+0

Ho cercato di rendere più chiaro questo nella domanda. Docker è in esecuzione tramite docker-machine. Quando dico "in esecuzione a livello locale" intendo la costruzione e l'esecuzione del servizio senza utilizzare la finestra mobile. Questa è un'opzione ma significa che ho bisogno di cambiare cose come l'URL del database ecc. –

+0

Ah, giusto, la mia ipotesi migliore qui è che, prima di tutto, la condivisione dei file tra l'host e la VirtualBox VM è (per dire bene) non molto performante; questa è una limitazione della condivisione di file di VirtualBox. In secondo luogo, la VM potrebbe non essere ottimizzata per le massime prestazioni, il che potrebbe fare la differenza nella durata della compilazione. Hai provato a, ad es. aumentare la quantità di memoria e/o il numero di CPU per la VM? – thaJeztah

risposta

3

farei questo:

Run docker-compose up ma:

  • utilizzare un volume host per la directory del compilato binario al posto della fonte
  • utilizzare un entrypoint che fa qualcosa di simile

entrypoint.sh:

trap "pkill -f the_binary_name" SIGHUP 
trap "exit" SIGTERM 

while [[ 1 ]]; do 
    ./the_binary_name; 
done 

scrivere uno script per ricostruire il binario, e copiarlo nella volume utilizzato dal servizio in docker-compose.yml:

# Run a container to compile and build the binary 
docker run -ti -v $SOURCE:/path -v $DEST:/target some_image build_the_binary 

# copy it to the host volume directory 
copy $DEST/... /volume/shared/with/running/container 

# signal the container 
docker kill -s SIGHUP container_name 

Quindi, per compilare il binario si utilizza questo script, che monta la fonte e un directory di destinazione come volumi. È possibile saltare il passaggio di copia se lo $DEST è uguale alla directory del volume condivisa con il contenitore "run". Infine, lo script segnalerà al contenitore in esecuzione di farlo uccidere il vecchio processo (che stava eseguendo il vecchio binario) e avviare quello nuovo.

Se il volume condiviso sta rendendo la compilazione in un contenitore troppo lento, è anche possibile eseguire la compilazione sull'host e solo eseguire la copia e il segnale per farlo girare in un contenitore.

Questa soluzione ha l'ulteriore vantaggio che l'immagine "runtime" non ha bisogno di tutte le dipendenze di sviluppo. Potrebbe essere un'immagine molto snella con solo una base del sistema operativo.

+1

Ciao, grazie per questa risposta approfondita. Questo ha spiegato molto. Sono riuscito a farlo funzionare molto mentre descrivi qui. Una differenza, non ero in grado di far funzionare 'docker kill -s SIGHUP', sto usando' docker exec web pkill -f nome_contenitore '. Questo potrebbe non essere altrettanto veloce, ma il passaggio a questo metodo ha ridotto significativamente il tempo di una singola "iterazione". Grazie. –