I vantaggi di sviluppo dell'utilizzo di Docker sono negati quando si utilizza Java rispetto ad altri linguaggi più vicini ai binari di Unix?

Assolutamente no.

Immagina di eseguire la versione 1.8.0 di Java sul tuo computer di sviluppo e sul server. A proposito, stai lavorando contemporaneamente su due progetti, entrambi con Java.

Un giorno, un errore viene trovato in JVM e i server che eseguono il primo progetto su cui stai lavorando sono migrati a 1.8.1. A proposito, i server che eseguono il secondo progetto non sono interessati dal bug e sono gestiti da un diverso team di amministratori di sistema, che potrebbero non essere disposti ad aggiornare a 1.8.1.

Ora, almeno per uno dei progetti, stai utilizzando una versione diversa di Java.

Questo potrebbe non infastidirti troppo (fino a quando un server non migra a 1.9, mentre l'altro mantiene la vecchia versione), ma questo significherebbe che non stai più replicando l'ambiente di produzione sul tuo computer locale, il che lo rende possibile che piccoli bug si insinuino.

Se immagini che il tuo file system, le tue dipendenze, le tue impostazioni di sicurezza, la tua configurazione locale e la tua versione di Linux differiscono dalla produzione, ti stai mettendo a rischio di scrivere codice che fallirà nella produzione. Invece di correre questo rischio, potresti utilizzare la virtualizzazione o la finestra mobile, con una perdita di produttività minima o nulla.

Raramente si distribuisce solo una "app Java". La tua applicazione java ha molti programmi di supporto diversi attorno ad essa. Utilizziamo Apache HTTPD, Apache Tomcat, ActiveMQ per la messaggistica, FTP Deamon, MySQL e una manciata di servizi personalizzati da integrare con programmi che non funzionano direttamente con Java.

Questo non entra nemmeno nel software di sviluppo che lo accompagna - eclipse, ant, adobe flex, groovy, firefox e subversion (ne sto saltando alcuni)

Ci vuole tra un giorno intero e una settimana per impostare una nuova workstation - abbiamo discusso del passaggio a Docker per semplificare questo problema. Sarebbe fantastico se potessimo installare una nuova workstation in un paio d'ore in modo affidabile.

Per non parlare del fatto che quando installiamo è necessario mantenere più di 20 server; Docker sta iniziando a sembrare un buon affare!

(20 sembra abbastanza doloroso per un'app che funziona solo su un singolo server alla volta ... ma moltiplica quel server per cluster (x2), test / staging / prod (x3), Interno / Esterno (x2) e sito principale / sito di backup (x2) e ci si arriva abbastanza rapidamente)

Questa domanda sarebbe anche pertinente per golang, dove puoi semplicemente estrarre binari collegati staticamente ed eseguirli da qualche parte, al contrario di Python o C ++, dove solitamente hai un gran numero di librerie collegate che porta le persone a costruire semplicemente un container fuori dall'ambiente di sviluppo.

Ci sono due punti per rispondere qui:

Uno: là deve essere un modo migliore , e c'è: puoi costruire container più piccoli (e più efficienti) usando semplicemente l'ambiente di installazione, il che porta a vantaggi simili come nel caso di contenitori Golang-con-ambiente contro Golang-solo-binari. Nel caso di Java, è possibile creare un jar fat o un'app installabile che contenga tutti i jar della libreria e uno script della shell; nel caso di Python, è possibile utilizzare auditwheel per creare ruote indipendenti indipendenti dall'ambiente di generazione (e si potrebbe usare C ++ con collegamento statico quasi allo stesso effetto).

Due: per cosa hai bisogno di docker? In Java land, puoi fare molta separazione tra diversi componenti usando i programmi di caricamento di classi, ma il punto principale è ciò che è intorno all'applicazione Java. Nessuna applicazione Java viene eseguita da sola: se non viene eseguita nella finestra mobile, di solito deve essere controllata da supervisord, systemd o simili. Inserisci il cloud Kubernetes, Marathon o Docker, che utilizza l'astrazione del contenitore per virtualizzare non l'host stesso, ma in realtà virtualizza l'intera rete in modo tale che puoi semplicemente distribuire i contenitori e questi vengono eseguiti su un host casuale.

I microservizi di solito funzionano su cloud basati su docker perché consentono di trattare gli host di docker come bestiame, non come animali domestici e in modo simile con le applicazioni ancorate. Naturalmente, questa astrazione perde quando si montano i volumi host sulla finestra mobile e occorre eseguire contenitori docker esattamente sull'host con questi volumi. Alcune persone si aggirano intorno a questo.

Questa è una domanda davvero buona, ma dopo aver lavorato con Docker, vorrei girarlo intorno:

Are the benefits of the JVM negated by containerization (e.g. Docker)?

I contenitori sfidano davvero molte delle ipotesi che ho sullo sviluppo derivate dalla mia esperienza. Ad esempio, se qualcuno dovesse codificare un percorso su un file di risorse in un'applicazione, molti sviluppatori esperti saprebbero che questo è problematico e dovresti renderlo configurabile. Ma se stai prendendo di mira un container, è davvero così? Quando costruisci il contenitore, gli dici quali sono le strutture di directory. Stai configurando il percorso lì. Quindi dovresti configurarlo due volte? Qual è il vantaggio? Se non li fai corrispondere, non funzionerà così ... ASCIUTTO?

Recentemente ho creato un'applicazione prototipo con Java e Docker che essenzialmente guardavano gli eventi del GC e quando la vecchia porzione dell'heap ha raggiunto una percentuale di soglia, si chiudeva automaticamente. La finestra mobile (modalità sciame) ne creava una nuova. Essenzialmente, ha eliminato la necessità di importanti cicli GC nella JVM e ha consentito alla docker di gestirli. Non ha funzionato come avrei potuto sperare (i client hanno avuto un impatto sull'interruzione), ma è stato abbastanza funzionale per fare una dimostrazione dal vivo alla folla.

Dovresti davvero provare i contenitori se sei curioso. È davvero una tecnologia dirompente e dovrai affrontarla. Docker è un ottimo punto di partenza, ma esiste almeno un'alternativa valida che va bene per tutti, IMO.