Flusso di lavoro di sviluppo Docker

Question

Qual è il flusso di lavoro di sviluppo corretto per il codice eseguito in un contenitore Docker?

Solomon Hykes said che il flusso di lavoro "ufficiale" comporta la creazione e l'esecuzione di una nuova immagine Docker per ogni commit Git. Questo ha senso, ma cosa succede se voglio testare una modifica prima di commetterlo al repo Git?

Mi vengono in mente due modi per farlo:

1. eseguire il codice su un server di sviluppo locale (ad esempio, il server di sviluppo Django). Modifica un file; test sul server di sviluppo; fare un commit Git; ricostruire l'immagine Docker con il nuovo codice; eseguire nuovamente il test sul contenitore Docker locale.

2. Non eseguire un server di sviluppo locale. Invece, crea ed esegui una nuova immagine Docker ogni volta che modifico un file, quindi testiamo la modifica sul contenitore Docker locale.

Entrambi gli approcci sono piuttosto inefficienti. C'è un modo migliore?

Answer 1

Un modo più efficiente consiste nell'eseguire un nuovo contenitore dall'immagine più recente che è stata creata (che quindi ha l'ultimo codice).

Si potrebbe iniziare quel contenitore di iniziare una shell bash in modo che si sarà in grado di modificare i file dal all'interno del contenitore:

docker run -it <some image> bash -l 

Si potrebbe quindi eseguire l'applicazione in tale contenitore per testare il nuovo codice.

Un altro modo per modificare i file in quel contenitore è avviarlo con un volume. L'idea è quella di modificare i file in una directory sull'host finestra mobile, invece di fare scherzi con i file dalla riga di comando dal contenitore stesso:

docker run -it -v /home/joe/tmp:/data <some image> 

Qualsiasi file che si metterà in /home/joe/tmp sul proprio host finestra mobile sarà disponibile sotto /data/ nel contenitore. Cambia /data in qualsiasi percorso adatto al tuo caso e sfreccia via.