I vantaggi di sviluppo dell'utilizzo di Docker sono negati quando si utilizza Java rispetto ad altre lingue più vicine ai binari Unix?

Ho avuto un amico che ha detto:

Docker è fantastico. Puoi usarlo per replicare la produzione e tutte le sue stranezze sul tuo computer locale. Quindi è possibile distribuire quell'istanza direttamente attraverso tutti i flussi di lavoro di gestione temporanea in modo estremamente rapido .

Ora questo sarebbe vero se gli sviluppatori scrivessero Ruby, PHP o Go - dove c'era un collegamento binario di direzione al sistema operativo.

Ma quando si utilizza Java - esiste già un livello virtuale tra il sistema operativo e la lingua, rendendo coerente l'operazione indipendentemente dal sistema operativo sottostante.

Probabilmente, in questo caso, i vantaggi di eseguire Docker per gli sviluppatori localmente per replicare l'ambiente di produzione sono negati . (Rispetto a Ruby, PHP o Go).

Sono aperto alla discussione su questo e sono ansioso di sentire un punto di vista dissenziente (con prove).

I vantaggi di sviluppo dell'utilizzo di Docker sono negati quando si utilizza Java rispetto ad altre lingue più vicine ai binari Unix?

Affatto.

Immagina di eseguire la versione 1.8.0 di Java sia sulla tua macchina di sviluppo che sul server. A proposito, stai lavorando contemporaneamente a due progetti, entrambi usando Java.

Un giorno, viene rilevato un bug in JVM e i server che eseguono il primo progetto su cui stai lavorando vengono migrati alla 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 eseguendo una versione diversa di Java.

Questo potrebbe non disturbarti troppo (fino a quando un server non passa alla 1.9, mentre l'altro mantiene la vecchia versione), ma ciò significherebbe che non stai più replicando l'ambiente di produzione sul tuo computer locale, il che rende possibile per tiny bug per insinuarsi.

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

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

Questo non va nemmeno nel software di sviluppo che lo accompagna - eclissi, formica, adobe flex, groovy, firefox e sovversione (ne sto saltando parecchi)

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

Per non parlare del fatto che quando implementiamo abbiamo bisogno di mantenere fino a - 20 server; Docker sta iniziando a sembrare un ottimo affare!

(20 sembra piuttosto 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 primario / sito di backup (x2) e ci si arriva abbastanza rapidamente)

Questa domanda sarebbe pertinente anche per Golang, dove puoi semplicemente estrarre binari collegati staticamente ed eseguirli da qualche parte, al contrario di Python o C ++ dove di solito hai un gran numero di librerie collegate che portano le persone a costruire un contenitore docker solo dal sviluppo dell'ambiente.

Ci sono due punti per rispondere qui:

Uno: deve esserci un modo migliore , ed esiste: è possibile costruire container docker più piccoli (e più efficienti) usando solo l'ambiente di installazione, il che porta a vantaggi simili come nel caso di Golang-with-environment rispetto a Golang-just contenitori binari. Nel caso di Java, è possibile creare un grosso vaso o un'app installabile che contenga tutti i vasetti della libreria e uno script di shell; nel caso di Python, potresti usare auditwheel per costruire ruote autonome che sono indipendenti dall'ambiente di costruzione (e potresti usare C ++ con collegamento statico per quasi lo stesso effetto).

Due: a cosa ti serve la finestra mobile? Nella terra Java, puoi fare molta separazione tra i diversi componenti usando i caricatori di classi, ma il punto principale è ciò che circonda l'applicazione Java. Nessuna applicazione Java funziona da sola - se non viene eseguita nella finestra mobile, di solito dovrebbe essere supervisionata da Supervord o Systemd o simili. Inserisci Kubernetes, Marathon o Docker cloud, che utilizza l'astrazione del contenitore per virtualizzare non l'host stesso, ma in realtà virtualizza l'intera rete in modo tale che tu possa semplicemente distribuire container e che vengano eseguiti su un host casuale.

I microservizi di solito vengono eseguiti su cloud basati su docker perché consentono di trattare gli host docker come bestiame, non come animali domestici e in modo simile con le applicazioni dockerizzate. Naturalmente, questa astrazione diventa fuoriuscita non appena si montano i volumi host sulla finestra mobile e è necessario eseguire i contenitori della finestra mobile esattamente sull'host che ha questi volumi. Alcune persone lo aggirano.

Questa è davvero una bella domanda, ma dopo aver lavorato con Docker, vorrei cambiarlo:

I vantaggi della JVM sono negati dalla containerizzazione (ad es. Docker)?

I contenitori sfidano davvero molte delle ipotesi che ho sullo sviluppo che derivano dalla mia esperienza. Ad esempio, se qualcuno dovesse codificare un percorso di 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 si crea il contenitore, si indica quali sono le strutture di directory. Stai configurando il percorso lì. Quindi dovresti configurarlo due volte? Qual è il vantaggio? Se non li abbini, non funzionerà così ... ASCIUTTO?

Di recente ho creato un'applicazione prototipo con Java e Docker che essenzialmente guardava gli eventi GC e quando la vecchia porzione dell'heap raggiungeva una percentuale di soglia, si chiudeva automaticamente. La finestra mobile (modalità sciame) ne farebbe girare una nuova. In sostanza, ha eliminato la necessità di importanti cicli GC nella JVM e ha permesso alla docker di gestirli. Non ha funzionato come avrei potuto sperare (i clienti hanno visto un impatto sull'arresto) ma era abbastanza funzionale da fare una demo dal vivo per una folla.

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