software - Vagrant para un proyecto Java: ¿debería compilar en la VM o en el host?

what is vagrant (2)

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

Para aplicaciones JavaEE / implementadas, la configuración de un servidor web y un servidor de base de datos son definitivamente cosas que tienen una complejidad "suficiente" para garantizar el uso de Vagrant. Con dos servidores y una miríada de formas de configurarlos, es fácil que la configuración se desincronice de un desarrollador a otro, lo que provoca el síndrome de "funciona en mi máquina". Para este tipo de software, sería mejor editar y compilar el código en el host, y desplegarlo 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 objetivo de compilación en el host, lo que eliminaría la necesidad de redesplegar manualmente. Así que Vagrant podría ser una parte importante de su ciclo de vida de desarrollo, pero el tiempo de ciclo para compilar / desplegar código desde el host y ejecutar en la máquina virtual con Java sería más largo que el tiempo del ciclo en el host y ejecutarse en la máquina virtual que vemos con PHP / Ruby / Node / etc.

Para 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 el equipo host, evitando por completo el uso de Vagrant. 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 poca ventaja en comparación con la sobrecarga de usar Vagrant, y solo sirve para poner una capa adicional de complejidad en su proceso de desarrollo. Esto se debe a que, en el momento en que puede editar Java con un IDE, puede 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 (afortunadamente) esto no es un gran problema; a partir de este escrito JDK6 es fin de vida y JDK8 aún no se ha lanzado (adivina dónde nos deja). Pero si necesitó ejecutar varias versiones, debería poder establecer 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 versiones diferentes 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 ejecutar en el host como lo hicimos para la aplicación independiente? Para las aplicaciones web sin contenedor, no hay que preocuparse por un servidor web externo, pero aún existe 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 eficaz 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 que tiene sentido que el servidor de la base de datos esté en su propia VM Vagrant.

Es de esperar que esto brinde a los desarrolladores de Java que estén interesados en Vagrant algún contexto sobre cómo usarlo.

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

Parece que no está muy bien definido exactamente cómo un IDE de Java y el proceso de compilación / implementación funcionan con una VM Vagrant. En general, mi impresión es que el código se edita en el host y se ejecuta en la máquina virtual, que funciona muy bien para los idiomas no compilados. Otras respuestas en Stackoverflow han implicado que Vagrant es menos útil para los 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 compila en 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 actualizarse manualmente con eso en la VM
la versión java correspondiente en el host podría no estar disponible (por ejemplo, en una Mac)

Por qué tener IDE en la VM

una integración más estrecha entre el entorno y el IDE, puede usar accesos directos para ejecutar la aplicación
puede conectar el depurador para aplicaciones Java sin depuración remota (ejecución / depuración de un solo paso)

Por qué compilar en el host

tiempos de compilación más rápidos
quiero mantener la máquina virtual lo más cerca posible de la producción

Por qué tener IDE en el host

es la convención vagabunda para editar el código en el host y ejecutarlo en la VM
mejor rendimiento de UI (X reenvío y VNC son lentos)

¿Cuáles son sus pensamientos: debería ejecutar mi IDE desde dentro de la VM o el host? ¿Debería compilar desde dentro de la VM o el host?

Me interesó 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 de usuario del escritorio porque algunos desarrolladores prefieren codificar en el equipo host, mientras que otros prefieren tener un entorno mucho más integrado con el escritorio y el IDE.

Para hacer frente a la lentitud del escritorio, debe instalar un plugin vagabundo muy útil (sí ... vagabundo tiene complementos que mejoran en gran medida el entorno de desarrollo) de esta manera: vagrant plugin install vagrant-vbguest Este plugin instalará la adición de invitado de cuadro virtual en cada invitado a hacerlo utilizable mientras usa la interfaz de la caja virtual. Luego, para habilitar la GUI, edite el archivo Vagrant de esta manera:

config.vm.provider "virtualbox" do | vb | vb.gui = fin verdadero

En lugar de acelerar las presentaciones de carpetas compartidas, sugiero usar rsync: config.vm.synced_folder "./git", "/ home / vagrant / git", escriba: "rsync", rsync__exclude: ".git /" En este forma en que el código fuente se edita en el host y luego rsync-ed para el invitado.