Vagrant per un progetto Java: dovresti compilare nella VM o sull'host?

92

Ecco la domanda: quando si utilizza Vagrant per un progetto Java (o qualsiasi progetto di linguaggio compilato per quella materia), è necessario compilare nella VM o sull'host? Inoltre, vorresti che il tuo IDE e tutti i tuoi strumenti di sviluppo vengano eseguiti anche dall'interno della VM o sull'host?

Sembra non essere ben definito esattamente come funzionano un IDE Java e il processo di compilazione / distribuzione con una VM Vagrant. In genere la mia impressione è che il codice venga modificato sull'host ed eseguito sulla VM, che funziona alla grande per i linguaggi non compilati. Altre risposte su Stackoverflow hanno implicato che Vagrant è meno utile per i linguaggi compilati a causa del passaggio di compilazione aggiuntivo, ma voglio comunque vedere cosa si può fare.

Alcune cose a cui ho già pensato:

Perché compilare sulla VM

  • se si compila su host, java è un altro software da installare
  • se si compila su host, la versione java su host deve essere aggiornata manualmente con quella sulla VM
  • la versione java corrispondente sull'host potrebbe non essere disponibile (ad esempio, su un Mac)

Perché avere IDE sulla VM

  • più stretta integrazione tra ambiente e IDE, può utilizzare scorciatoie per eseguire l'applicazione
  • può collegare il debugger per le applicazioni java senza debug remoto (esecuzione / debug in un passaggio)

Perché compilare sull'host

  • tempi di compilazione più rapidi
  • desidera mantenere la VM il più vicino possibile all'aspetto della produzione

Perché avere IDE sull'host

  • è la convenzione vagabonda per modificare il codice sull'host ed eseguirlo sulla VM
  • migliori prestazioni dell'interfaccia utente (l'inoltro X e VNC sono lenti)

Cosa ne pensi: devo eseguire il mio IDE dall'interno della VM o dall'host? Devo compilare dall'interno della VM o dell'host?

java  vagrant 
— Jay
fonte

Risposte:

61

Dopo molte riflessioni e sperimentazioni, ho deciso dove utilizzare Vagrant e come si integra con il flusso di lavoro di sviluppo Java.

Per le applicazioni JavaEE / distribuite, la configurazione di un server web e un server database sono sicuramente cose che hanno una complessità "sufficiente" per garantire l'uso di Vagrant. Con due server e la miriade di modi per configurarli, è facile che la configurazione non sia sincronizzata da uno sviluppatore all'altro, provocando la sindrome dei "lavori sulla mia macchina". Per questo tipo di software, sarebbe meglio modificare e compilare il codice sull'host e distribuirlo a una VM Vagrant che imita il tuo ambiente di produzione. La cartella di distribuzione per il server Web potrebbe anche essere collegata a una destinazione di compilazione sull'host, eliminando la necessità di ridistribuire manualmente. Quindi Vagrant potrebbe essere una parte importante del tuo ciclo di vita di sviluppo,

Per le applicazioni Java autonome (come le librerie o le applicazioni desktop) la storia cambia leggermente. In questo caso ha più senso modificare, compilare ed eseguire sulla macchina host, evitando del tutto l'uso di Vagrant. Se stai usando uno dei grandi IDE Java (Eclipse, Netbeans, IntelliJ ...), hai già Java installato sulla macchina. A quel punto c'è un vantaggio molto piccolo rispetto al sovraccarico dell'utilizzo di Vagrant e serve solo a mettere un ulteriore livello di complessità nel processo di sviluppo. Questo perché quando sarai in grado di modificare Java con un IDE, sarai comunque in grado di eseguire tutto sull'host. Un problema è che la versione di Java richiesta per il progetto potrebbe non corrispondere alla versione che esegue l'IDE sull'host. In generale (si spera) questo non è un grosso problema; al momento della stesura di questo documento JDK6 è esaurito e JDK8 non è ancora stato rilasciato (indovina dove questo ci lascia). Ma se hai bisogno di eseguire più versioni, dovresti essere in grado di impostare JAVA_HOME sull'host secondo necessità. Anche se questo introduce una complessità extra, è meno complessa rispetto al mantenimento di un runtime Vagrant solo per lavorare con progetti che utilizzano versioni diverse di Java.

La domanda interessante è cosa fare con le applicazioni web senza container. Il web server (in questo caso interno all'applicazione) deve essere eseguito all'interno della VM come abbiamo fatto per il web server esterno? O eseguito sull'host come abbiamo fatto per l'applicazione standalone? Per le applicazioni web senza container, non c'è nessun server web esterno di cui preoccuparsi, ma probabilmente c'è ancora un database. In questa situazione possiamo adottare un approccio ibrido. L'esecuzione di un'app Web senza contenitore è essenzialmente uguale all'esecuzione di un'applicazione standalone, quindi sarebbe efficace compilare ed eseguire il codice sul computer host. Ma con un database coinvolto, c'è ancora abbastanza complessità e configurazione che ha senso avere il server del database sulla propria VM Vagrant.

Si spera che questo dia agli sviluppatori Java interessati a Vagrant un contesto su come usarlo.

— Jay
fonte
per un host del sistema operativo Windows e una VM del sistema operativo Linux, cosa ne pensi di eseguire IntelliJ sulla VM Linux, in esecuzione sull'host (Windows) tramite X11?
— Kevin Meredith,
3
Ottima domanda: non l'ho menzionato ma ho fatto molti test eseguendo l'IDE all'interno della VM Vagrant, e ho scoperto che le prestazioni erano orribili ... come nel fare clic su un menu ci sono voluti circa 12 secondi per rispondere. Ho provato cose come: specificare una cifra più veloce, utilizzare la compressione per X11 e aumentare la RAM video della VM, solo per ottenere il tempo di risposta a 4 secondi che era ancora inutilizzabile. Quindi i miei pensieri sono che Vagrant non è inteso per eseguire un IDE.
— Jay
Penso che dovresti provarlo però: non ho abilitato l'accelerazione 2D di VirtualBox poiché è per gli host Windows (e non avevo un host Windows). Altre idee sulle prestazioni che non sono riuscito a provare includono: si dice che il provider di VMWare abbia ottimizzazioni grafiche speciali, potrebbe provare VRDP che potrebbe avere prestazioni migliori di X11, il server NX dovrebbe essere più veloce di X11, e infine c'è spice- space.org. Se trovi qualcosa che funziona bene, ti preghiamo di ripubblicare qui perché mi piacerebbe saperne di più!
— Jay
2
Non ho testato IntelliJ all'interno di una VM guest (e potrei non aver dato le esperienze di un collega con la sua lentezza nell'ospite). Tuttavia, ho letto quanto segue in "Vagrant - Up and Running": Shared folders incur a heavy performance penalty within the virtual machine when there is heavy I/ O, so they should only be used for source files. Any compilation step, database files, and so on should be done outside the shared folder filesystem inside the guest filesystem itself.La dichiarazione di questo libro (scritta dal creatore di Vagrant) sembra essere contraria alla compilazione nell'host VM, no?
— Kevin Meredith
4
La citazione menziona "una pesante penalizzazione delle prestazioni all'interno della macchina virtuale" e non menziona una penalizzazione globale delle prestazioni per l'host, quindi penso che il contesto qui sia per le prestazioni / operazioni all'interno della VM . In quel contesto, interpreto questa citazione come una previsione delle prestazioni quando una fase di compilazione viene eseguita all'interno dell'ospite invece di raccomandare la compilazione sull'ospite rispetto all'host. Puoi dire di più sul contesto di questa citazione? Il libro sta affrontando questo scenario in modo specifico? Ovviamente tutto questo è soggetto a veri e propri test :)
— Jay
3

Ero interessato a questo argomento durante l'ultimo anno :)

La mia soluzione è avere una macchina vagabonda configurabile con flag. Ad esempio, uno di questi flag abilita la grafica del desktop perché alcuni sviluppatori preferiscono codificare sulla macchina host mentre altri preferiscono avere un ambiente molto più integrato con il desktop e l'IDE al suo interno.

Per affrontare la lentezza del desktop dovresti installare un plug-in vagrant molto utile (sì ... vagrant ha plug-in che migliorano notevolmente l'ambiente di sviluppo) in questo modo: plug-in vagrant installa vagrant-vbguest Questo plug-in installerà l'aggiunta guest box virtuale su ogni ospite a renderlo utilizzabile durante l'utilizzo dell'interfaccia virtualbox. Quindi per abilitare la gui modificare il file Vagrant in questo modo:

config.vm.provider "virtualbox" fai | vb | vb.gui = vero fine

Invece per velocizzare le prestazioni delle cartelle condivise suggerisco di usare rsync: config.vm.synced_folder "./git", "/ home / vagrant / git", scrivi: "rsync", rsync__exclude: ".git /" In questo modo in cui il codice sorgente viene modificato sull'host e quindi rsync-ed al guest.

— Saverio Ferrara
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.