Come utilizzare al meglio Docker in modalità di consegna continua?

Question

Qual è il modo migliore per utilizzare Docker in una pipeline di fornitura continua?

Il manufatto di costruzione dovrebbe essere un'immagine Docker piuttosto che un Jar/War? In tal caso, come funzionerebbe? Ho difficoltà a capire come utilizzare Docker in sviluppo (sul laptop) e poi utilizzare il server CI per usare la stessa immagine di base per costruire il manufatto.

Answer 1

Bene, ci sono ovviamente molte migliori pratiche e molti approcci su come farlo. Un approccio che ho trovato di successo è la seguente:

• separare il codice schierabili (vasetti/guerre ecc) dai contenitori Docker VCS-repos separati (abbiamo utilizzato due differenti Git-repos nel mio ultimo progetto). Ciò significa che le immagini del docker che utilizzi per distribuire il tuo codice sono costruite in un passaggio separato. A finestra mobile-build per così dire. Qui puoi, ad es. costruire le immagini del docker per il database, il server applicazioni, la cache redis o simili. Quando un file "Dockerfile" o simile è cambiato nel tuo VCS, Jenkins o qualsiasi altra cosa tu usi può innescare la costruzione delle immagini del docker. Queste immagini dovrebbero essere taggate e inviate ad un registro (potrebbe essere Docker Hub o un registro locale).
• Il codice distribuibile (vasi/guerre ecc.) Deve essere compilato come al solito usando Jenkins e commit-hooks. In uno dei miei progetti abbiamo effettivamente gestito Jenkins in un contenitore Docker come described here.
• Tutti i contenitori di finestre mobili che utilizzano dati dinamici (come la memoria per un database, i file di guerra per un Tomcat/Jetty oi file di configurazione che fanno parte della base di codice) devono montare questi file come data volumes or as data volume containers.
• I server di prova o tutti i passaggi che fanno parte della pipeline devono essere impostati in base a una specifica nota al server di generazione. Abbiamo utilizzato un descrittore che collegava il tag appena costruito dalla base del codice al tag sui contenitori della finestra mobile. Il plug-in della pipeline Jenkins potrebbe quindi eseguire uno script che prima spostava le risorse di build sul server host, tirava le immagini corrette del docker dal registro locale e avviava tutti i processi utilizzando i contenitori del volume di dati (abbiamo usato Fig per la gestione del ciclo di vita della finestra mobile

Con questo approccio, siamo stati anche in grado di eseguire i nostri processi locali (database ecc.) Come contenitori Docker. Questi contenitori erano ovviamente basati sulle stesse immagini di quelli in produzione e potrebbero anche essere sviluppati sulle macchine dev. solo la vera differenza tra l'ambiente di sviluppo locale e l'ambiente di produzione era il sistema operativo.Le macchine di sviluppo in genere eseguivano Mac OS X/Boot2Docker e prodavano su Linux.

Answer 2

Sì, dovresti passare dai file jar/war alle immagini come artefatti di costruzione. Il processo descritto da @wassgren dovrebbe funzionare bene, tuttavia ho trovato quanto segue per adattarsi meglio al nostro caso d'uso, in particolare per lo sviluppo:

1- Creare un'immagine di base. Sembra che tu sia un negozio Java così come un esempio, facciamo finta che la tua immagine di base sia FROM ubuntu:14.04 e installi jdk e alcune delle librerie più comuni. Chiamiamolo myjava.

2- Durante lo sviluppo, utilizzare fico per richiamare il/i contenitore/i localmente e montare il codice dev nel punto giusto. Fig usa l'immagine di base myjava e non si preoccupa del Dockerfile.

3- Quando si genera il progetto per la distribuzione, utilizza il Dockerfile e da qualche parte fa un COPY del codice/build artefatti nel posto giusto. L'immagine viene quindi etichettata in modo appropriato e distribuita.

Answer 3

semplici passaggi da seguire.

1) Installare Jenkins in contenitore

2) Installare strumento del quadro nello stesso contenitore. (I usato SBT).

3) Creare un progetto in Jenkins con plugin necessari per integrare i dati da gitlab e costruire tutto vaso di un formato compresso (diciamo build.tgz).

4) Questo build.tgz può essere spostato ovunque e attivato, ma dovrebbe soddisfare tutte le sue dipendenze ambientali (ad esempio, ad esempio, richiede mysql).

5) Ora creiamo un'immagine di ambiente di base (nel nostro caso mysql installato).

6) Con ogni generazione attivata, dovremmo attivare un file di posta sul server che combinerà build.tgz e l'immagine dell'ambiente.

7) Ora abbiamo il nostro build.tgz insieme al suo ambiente soddisfatto. Questa immagine deve essere inserita nel registro. Questa è la nostra immagine finale. È portatile e può essere implementata ovunque.

8) Questa immagine finale può essere conservata in un contenitore con i punti di montaggio necessari per ottenere le uscite e uno script (script.sh) può essere attivato menzionando il comando entrypoint nel file docker.

9) Questo script.sh sarà all'interno dell'immagine (immagine di base) e sarà configurato per fare le cose in base al nostro scopo.

10) Prima di rendere questo contenitore, è necessario arrestare il contenitore precedente.

Note importanti:

Un'immagine viene creato ogni volta che costruire e vengono memorizzati in Registro di sistema. Quindi può essere riutilizzato. Questa immagine può essere inserita nel server di produzione principale e può essere attivata. Questo aiuta a mantenere un ambiente pulito ogni volta perché stiamo usando l'immagine di base.

Answer 4

È inoltre possibile creare una pipeline CD stabile con Bamboo e Docker. Le integrazioni di Bamboo Docker sono disponibili sia in un modulo di build agent che come attività in bundle all'interno dell'applicazione. È possibile trovare questo articolo utile: http://blogs.atlassian.com/2015/06/docker-containers-bamboo-winning-continuous-delivery/

È possibile utilizzare l'attività per creare un'immagine di Docker che è possibile utilizzare in un altro ambiente o distribuire l'applicazione in un contenitore.

Buona fortuna!