Utilizzando Docker in fase di sviluppo per le applicazioni Java EE

Question

io aggiungere 300 punti di taglie

Di recente ho iniziato a dare un'occhiata più da vicino a Docker e come posso usarlo per più veloce ottenere nuovo membro della collaborare con l'ambiente di sviluppo e spedire nuove versioni del software alla produzione.

Ho alcune domande su come e in quale fase dovrei aggiungere l'applicazione Java EE al contenitore. Per come la vedo, ci sono molti modi per farlo.

questo era il tipico flusso di lavoro (nella mia squadra) prima di Docker:

1. sviluppatore scrive il codice
2. sviluppatore costruisce il codice con Maven producendo un GUERRA
3. sviluppatore carica la guerra nella console di amministrazione di JBoss/o con il plug-in Maven

Ora dopo che Docker è venuto in giro sono un po 'confuso riguardo a se dovrei creare le immagini di cui ho bisogno e configurarle in modo che tutto ciò sia ft da fare quando si esegue il contenitore JBoss Wildfly è quello di distribuire l'applicazione tramite la console di amministrazione sul web. O dovrei creare un nuovo contenitore per ogni volta che creo l'applicazione in Maven e aggiungerla con il comando ADD nel Dockerfile e quindi eseguire il contenitore senza mai distribuirlo ad esso una volta avviato?

In produzione, suppongo che l'ultimo approccio sia quello che preferisce? Correggimi se sbaglio Ma nello sviluppo come dovrebbe essere fatto? Ci sono altri flussi di lavoro?

Answer 1

Ho usato Docker con Glassfish ampiamente, da molto tempo ormai e ho scritto un blog sull'argomento qualche tempo fa here.

È un ottimo strumento per lo sviluppo di JavaEE.

Per la tua immagine di produzione preferisco raggruppare tutto insieme, costruendo l'immagine di base statica e la stratificazione nella nuova WAR. Mi piace usare il server CI per fare il lavoro e avere una configurazione CI per i rami di produzione che cattureranno una base, un livello nella build di rilascio e quindi pubblicheranno l'artefatto. In genere, la distribuzione viene eseguita manualmente in produzione, ma se si vuole davvero essere fantasiosi è possibile automatizzarla anche con il server CI che esegue la distribuzione in un ambiente di produzione e utilizzando i server proxy per garantire nuove sessioni in modo che ottenga la versione aggiornata.

In fase di sviluppo mi piace adottare lo stesso approccio quando arriva il momento di eseguire localmente qualsiasi cosa si basi sul contenitore (ad esempio i test di integrazione di Arquillian) prima del check in del codice. Ciò mantiene l'ambiente il più vicino possibile alla produzione, il che credo sia importante quando si tratta di test. Questa è una delle ragioni principali per cui sono contrario agli approcci come testare i contenitori incorporati ma distribuire a quelli non incorporati. Ho visto molti casi in cui un test passerà nell'ambiente embedded e fallirà in produzione/non incorporato.

Durante un ciclo di test di sviluppo/distribuzione/manuale, prima di eseguire il codice, penso che l'approccio di distribuzione in un contenitore (che fa parte di un'immagine di base) sia più economico in termini di velocità di tale sviluppo. ciclo vs costruzione nel tuo WAR ogni volta. È anche un approccio migliore se il tuo ambiente di sviluppo utilizza uno strumento come JRebel o XRebel, dove puoi implementare il tuo codice e aggiornare semplicemente il tuo browser per vedere le modifiche.

Answer 2

Il modo in cui normalmente distribuire qualsiasi cosa con Docker è produrre una nuova immagine in cima all'immagine di base della piattaforma. In questo modo segui la filosofia di raggruppamento delle dipendenze di Docker.

In termini di Maven, è possibile produrre un assieme di tarball (diciamo che si chiama jars.tar) e quindi chiamare ADD jars.tar /app/lib in Dockerfile. Potresti anche implementare un plugin Maven che genera anche un Dockerfile.

Questo è l'approccio più sano con Docker oggi, altri approcci, come l'immagine dell'edificio FROM scratch non sono abbastanza applicabili per le applicazioni Java.

Vedere anche Java JVM on Docker/CoreOS.

Answer 3

Si consiglia di dare un'occhiata a rhuss/docker-maven-plugin. Esso consente una perfetta integrazione per l'utilizzo di finestra mobile come l'unità di distribuzione:

• Utilizzare un descrittore di assemblaggio standard Maven per la creazione di immagini con docker:build, in modo da generato file WAR o la vostra Microservice possono essere facilmente aggiunti a un'immagine Docker.
• si può spingere l'immagine creata con docker:push
• Con docker:start e docker:stop si può utilizzare la vostra immagine durante i test di unità.

Questo plugin viene fornito con una documentazione completa, se ci sono delle domande aperte, si prega di aprire un problema.

E come avrete notato, sono l'autore di questo plugin ;-). E francamente, ci sono altri plug-in maven-docker, che hanno tutti un focus leggermente diverso. Per un semplice controllo, è possibile dare un'occhiata a shootout-docker-maven che fornisce configurazioni di esempio per i quattro plug-in maven-docker più attivi.

Il flusso di lavoro sposta quindi semplicemente il limite degli artefatti dai file WAR/EAR alle immagini Docker. mvn docker:push li sposta in un registro Docker da dove viene estratto durante le varie fasi di test utilizzate in una pipeline di distribuzione continua.

Answer 4

Il post sulla configurazione JRebel con Docker da Arun Gupta sarebbe probabilmente utile qui: http://blog.arungupta.me/configure-jrebel-docker-containers/

Answer 5

ho cercato uno scenario simular di utilizzare finestra mobile per eseguire la mia applicazione. Nella mia situazione volevo iniziare la finestra mobile con Tomcat che eseguiva la guerra. Quindi, nella fase di test di integrazione di Maven, avviare il test di integrazione cetriolo/phantomjs sulla finestra mobile. L'implementazione di esempio è documentata allo https://github.com/abroer/cucumber-integration-test. È possibile estendere questo esempio per inviare l'immagine della finestra mobile al repository privato quando il test ha esito positivo. L'immagine spinta può essere utilizzata in qualsiasi ambiente dallo sviluppo alla produzione.

Answer 6

Con l'ultima versione di Docker, è possibile ottenerlo facilmente con Link Docker, Docker Volume e Docker Compose. Ulteriori informazioni su questi strumenti dal sito di Docker.

Torna al flusso di lavoro come già menzionato: per qualsiasi applicazione Java EE tipica, sono richiesti un server applicazioni e un server database. Dal momento che nel tuo post non viene menzionato come viene impostato il database, suppongo che il tuo ambiente di sviluppo disponga di un server database separato per ogni sviluppatore.

Considerando tutti questi in ipotesi, potrei suggerire il seguente flusso di lavoro:

• costruire l'application server wildfly base dalla immagine ufficiale. È possibile ottenere che: "finestra mobile pull" comando
• Eseguire l'application server di base con:

finestra mobile eseguire -d -è -p 8080: 8080 -p 9990: 9990 --name baseWildfly jboss/wildfly

Il server di applicazione è in esecuzione ora, è necessario configurarlo per la connessione al server di database e configurare le impostazioni dataSource e altre configurazioni se neccessary al fine di avviare l'applicazione Java EE. Per questo, è necessario effettuare il login nel terminale bash del contenitore Jboss:

finestra mobile exec -i -t baseWildfly/bin/bash/

Si è ora nel terminal di container. È possibile configurare il server delle applicazioni come per qualsiasi ambiente Linux.

È possibile testare la configurazione distribuendo manualmente il file WAR su Wildfly. Questo può essere fatto facilmente con la console di amministrazione, o con il plugin Maven o con il comando AGGIUNGI come hai detto. Di solito lo faccio con la console di amministrazione, solo per testare rapidamente. Quando si verifica che la configurazione funziona, è possibile rimuovere il file WAR e creare uno snapshot del vostro contenitore:

finestra mobile commettere --change "aggiungere le impostazioni di base e configurazioni" baseWildfly yourRepository: tag

Ora puoi inviare l'immagine creata al tuo repository privato e condividerla con il tuo team di sviluppatori. Ora possono estrarre l'immagine ed eseguire il server delle applicazioni per l'implementazione immediata.

Non vogliamo distribuire il file WAR per ogni build di Maven utilizzando la console di amministrazione poiché è troppo macchinoso, quindi l'operazione successiva è di automatizzarla con Docker Volume.

Supponendo che si è configurato Maven per costruire il file WAR "../your_project/deployments/", è possibile collegare che alla distribuzione directory di contenitore Jboss come segue:

finestra mobile run -d - p 8080: 8080 -v ../your_project/deployments:/opt/jboss/wildfly/standalone/deployments

Ora, ogni volta che si ricostruisce l'applicazione con Maven, il server di applicazione esegue la scansione di cambio e ridistribuire il tuo file WAR.

È anche piuttosto problematico disporre di un server di database separato per ogni sviluppatore, in quanto devono configurarlo autonomamente nel contenitore perché potrebbero avere impostazioni diverse (ad esempio l'URL di db, il nome utente, la password, ecc.). Quindi, è bene renderlo disponibile alla fine.

Supponendo di utilizzare Postgres come server di database, è possibile estrarlo dal repository ufficiale di Postgres.Quando si ha l'immagine pronta, è possibile eseguire il server db:

finestra mobile run -d -p 5432: 5432 -t --name Postgres postgresDB

o eseguire il server di database con il collegato directory "dati":

finestra mobile run -d -p 5432: 5432 -v ../your_postgres/data:/var/lib/postgresql -t --name postgresDB Postgres

Il primo comando manterrà i dati nel contenitore, mentre il secondo manterrà i dati nell'inv dell'host.

Ora è possibile collegare il contenitore di database con il wildfly:

corsa finestra mobile -d -p 8080: 8080 --link postgresDB: banca dati -t baseWildfly

seguito è l'uscita di collegamento:

Ora è possibile avere lo stesso ambiente per tutti i membri nel team degli sviluppatori e possono iniziare la codifica con una configurazione minima.

Le stesse immagini di base possono essere utilizzate per l'ambiente di produzione, in modo che ogni volta che si desidera rilasciare una nuova versione, è sufficiente copiare il file WAR nella cartella "your_deployment" dell'host.

L'aspetto positivo del server applicazioni e del server di database è che è possibile raggrupparlo facilmente in futuro per ridimensionarlo o applicare la disponibilità elevata.

Answer 7

Per il mio attuale processo di implementazione uso glassfish e questo trucco, che funziona molto bene.

Una volta eseguito: pacchetto mvn clean, i contenitori entrano in azione e iniziano il dispiegamento dell'ultima guerra.