Vagrant para un proyecto Java: ¿debería compilar en la máquina virtual o en el host?

92

Aquí está la pregunta: cuando use Vagrant para un proyecto Java (o cualquier proyecto de lenguaje compilado), ¿debería compilar en la VM o en el host? Además, ¿le gustaría que su IDE y todas sus herramientas de desarrollo se ejecutaran también desde dentro de la máquina virtual o en el host?

Parece no estar muy bien definido exactamente cómo funcionan un IDE de Java y el proceso de compilación / implementación con una máquina virtual Vagrant. En general, mi impresión es que el código se edita en el host y se ejecuta en la máquina virtual, lo que funciona muy bien para lenguajes no compilados. Otras respuestas en Stackoverflow han implicado que Vagrant es menos útil para lenguajes compilados debido al paso de compilación adicional, pero aún quiero ver qué se puede hacer.

Algunas cosas que ya he pensado:

Por qué compilar en la VM

  • si se compila en el host, Java es una pieza más de software para instalar
  • si se compila en el host, la versión de Java en el host debe mantenerse actualizada manualmente con la de la VM
  • es posible que la versión de Java correspondiente en el host no esté disponible (por ejemplo, en una Mac)

Por qué tener IDE en la máquina virtual

  • integración más estrecha entre el entorno y el IDE, puede utilizar accesos directos para ejecutar la aplicación
  • puede conectar el depurador para aplicaciones java sin depuración remota (ejecutar / depurar en un paso)

Por qué compilar en el host

  • tiempos de compilación más rápidos
  • desea mantener la máquina virtual lo más cerca posible del aspecto de producción

Por qué tener IDE en el host

  • es la convención vagabunda de editar código en el host y ejecutarlo en la máquina virtual
  • mejor rendimiento de la interfaz de usuario (el reenvío X y VNC son lentos)

¿Cuáles son sus pensamientos? ¿Debería ejecutar mi IDE desde dentro de la máquina virtual o el host? ¿Debo compilar desde dentro de la máquina virtual o desde el host?

java vagrant Arrendajo
fuente

Respuestas:

61

Después de mucho pensar y experimentar, decidí dónde usar Vagrant y cómo se integra con el flujo de trabajo de desarrollo de Java.

Para las aplicaciones JavaEE / implementadas, la configuración de un servidor web y un servidor de base de datos son definitivamente cosas que tienen "suficiente" complejidad para justificar el uso de Vagrant. Con dos servidores y la miríada de formas de configurarlos, es fácil que la configuración no esté sincronizada de un desarrollador a otro, provocando el síndrome de "funciona en mi máquina". Para este tipo de software, lo mejor sería editar y compilar el código en el host e implementarlo en una VM Vagrant que imite su entorno de producción. La carpeta de implementación para el servidor web podría incluso vincularse simbólicamente a un destino de compilación en el host, eliminando la necesidad de volver a implementar manualmente. Por lo tanto, Vagrant podría ser una parte importante de su ciclo de vida de desarrollo,

Para las aplicaciones Java independientes (como bibliotecas o aplicaciones de escritorio), la historia cambia un poco. En este caso, tiene más sentido editar, compilar y ejecutar en la máquina host, evitando el uso de Vagrant por completo. Si está utilizando uno de los grandes IDE de Java (Eclipse, Netbeans, IntelliJ ...), ya tiene Java instalado en la máquina. En ese punto, hay muy pocas ventajas en comparación con la sobrecarga de usar Vagrant, y solo sirve para agregar una capa adicional de complejidad a su proceso de desarrollo. Esto se debe a que en el momento en que pueda editar Java con un IDE, podrá ejecutar todo en el host de todos modos. Un problema es que la versión de Java requerida para el proyecto puede no coincidir con la versión que ejecuta el IDE en el host. En general (con suerte) esto no es un gran problema; En el momento de escribir estas líneas, JDK6 está al final de su vida útil y JDK8 aún no se ha lanzado (adivinen dónde nos deja eso). Pero si necesita ejecutar varias versiones, debería poder configurar JAVA_HOME en el host según sea necesario. Aunque esto introduce una complejidad adicional, es menos complejo que mantener un tiempo de ejecución de Vagrant solo para trabajar con proyectos que usan diferentes versiones de Java.

La pregunta interesante es qué hacer con las aplicaciones web sin contenedor. ¿Debería ejecutarse el servidor web (en este caso interno de la aplicación) dentro de la máquina virtual como lo hicimos para el servidor web externo? ¿O ejecutarlo en el host como lo hicimos para la aplicación independiente? Para las aplicaciones web sin contenedor, no hay un servidor web externo del que preocuparse, pero es probable que todavía exista una base de datos. En esta situación, podemos adoptar un enfoque híbrido. Ejecutar una aplicación web sin contenedor es esencialmente lo mismo que ejecutar una aplicación independiente, por lo que sería efectivo compilar y ejecutar su código en la máquina host. Pero con una base de datos involucrada, todavía hay suficiente complejidad y configuración, por lo que tiene sentido que el servidor de la base de datos esté en su propia máquina virtual Vagrant.

Con suerte, esto les dará a los desarrolladores de Java que estén interesados ​​en Vagrant algo de contexto sobre cómo usarlo.

Arrendajo
fuente
para un host con sistema operativo Windows y una máquina virtual con sistema operativo Linux, ¿qué piensa acerca de ejecutar IntelliJ en la máquina virtual Linux, que se ejecuta en el host (Windows) a través de X11?
Kevin Meredith
3
Gran pregunta: no lo mencioné, pero hice muchas pruebas ejecutando el IDE dentro de la máquina virtual Vagrant y descubrí que el rendimiento era horrible ... ya que hacer clic en un menú tardó unos 12 segundos en responder. Intenté cosas como: especificar un cifrado más rápido, usar compresión para X11 y aumentar la RAM de video de la máquina virtual, solo para obtener el tiempo de respuesta a 4 segundos que aún no se podía usar. Entonces, mi pensamiento es que Vagrant no está diseñado para ejecutar un IDE.
Jay
Sin embargo, creo que debería intentarlo: no habilité la aceleración de VirtualBox 2D ya que es para los hosts de Windows (y no tenía un host de Windows). Otras ideas de rendimiento que no pude probar incluyen: se rumorea que el proveedor de VMWare tiene optimizaciones de gráficos especiales, podría probar VRDP que podría tener un mejor rendimiento que X11, se supone que el servidor NX es más rápido que X11, y finalmente hay especia- space.org. Si encuentra algo que funcione bien, por favor publíquelo aquí porque ¡me encantaría saberlo!
Jay
2
No he probado IntelliJ dentro de una máquina virtual invitada (y es posible que no haya dado las experiencias de un compañero de trabajo con su lentitud en el invitado). Sin embargo, leí lo siguiente en '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 declaración de este libro (escrita por el creador de Vagrant) parece argumentar en contra de la compilación en la máquina virtual anfitriona, ¿no?
Kevin Meredith
4
La cita menciona "una gran penalización de rendimiento dentro de la máquina virtual" y no menciona una penalización de rendimiento global para el host, por lo que creo que el contexto aquí es para el rendimiento / operaciones dentro de la VM . En ese contexto, interpreto que esta cita predice el rendimiento cuando se realiza un paso de compilación dentro del invitado en lugar de recomendar la compilación en el invitado frente al host. ¿Puedes decir más sobre el contexto de esta cita? ¿El libro aborda este escenario específicamente? Por supuesto, todo esto está sujeto a pruebas reales :)
Jay
3

Estuve interesado en este tema durante el último año :)

Mi solución es tener una máquina vagabunda configurable con banderas. Por ejemplo, uno de estos indicadores habilita la interfaz gráfica de usuario del escritorio porque algunos desarrolladores prefieren codificar en la máquina host, mientras que otros prefieren tener un entorno mucho más integrado con el escritorio y el IDE en él.

Para enfrentar la lentitud del escritorio, debe instalar un complemento vagrant muy útil (sí ... vagrant tiene complementos que mejoran enormemente el entorno de desarrollo) de esta manera: complemento vagrant install vagrant-vbguest Este complemento instalará la adición de invitado de caja virtual en cada invitado a hágalo utilizable mientras usa la interfaz virtualbox. Luego, para habilitar la interfaz gráfica de usuario, edite el Vagrantfile de esta manera:

config.vm.provider "virtualbox" hacer | vb | vb.gui = final verdadero

En lugar de acelerar el rendimiento de la carpeta compartida, sugiero usar rsync: config.vm.synced_folder "./git", "/ home / vagrant / git", escriba: "rsync", rsync__exclude: ".git /" En este forma en que se edita el código fuente en el host y luego rsync-ed con el invitado.

Saverio Ferrara
fuente