Vagrant для Java-проекта: компилировать на виртуальной машине или на хосте?

Вот вопрос: при использовании Vagrant для проекта Java (или любого скомпилированного языкового проекта в этом отношении) следует ли компилировать в виртуальной машине или на хосте? Кроме того, вы бы хотели, чтобы ваша IDE и все инструменты разработки запускались изнутри виртуальной машины или на хосте?

Кажется, не очень хорошо определено , как именно Java IDE и процесс компиляции / развертывания работают с Vagrant VM. Как правило, у меня сложилось впечатление, что код редактируется на хосте и запускается на виртуальной машине, что отлично подходит для некомпилированных языков. Другие ответы на Stackoverflow предполагают, что Vagrant менее полезен для скомпилированных языков из-за дополнительного этапа компиляции, но я все же хочу посмотреть, что можно сделать.

Некоторые вещи я уже продумал:

Зачем компилировать на ВМ

• при компиляции на хосте java - еще одна часть программного обеспечения для установки
• при компиляции на хосте версия Java на хосте должна обновляться вручную с версией на виртуальной машине
• соответствующая версия java на хосте может быть недоступна (скажем, на Mac)

Зачем IDE на ВМ

• более тесная интеграция между средой и IDE, можно использовать ярлыки для запуска приложения
• можно подключить отладчик для Java-приложений без удаленной отладки (одноэтапный запуск / отладка)

Зачем компилировать на хосте

• более быстрое время компиляции
• хотите, чтобы виртуальная машина была как можно ближе к тому, как выглядит производственная среда

Зачем IDE на хосте

• это бродячая конвенция редактировать код на хосте и запускать его на виртуальной машине
• лучшая производительность пользовательского интерфейса (пересылка X и VNC медленные)

Что вы думаете: следует ли мне запускать свою IDE из виртуальной машины или хоста? Должен ли я компилировать из виртуальной машины или хоста?

После долгих размышлений и экспериментов я решил, где использовать Vagrant и как он интегрируется с рабочим процессом разработки Java.

Для JavaEE / развернутых приложений настройка веб-сервера и сервера базы данных определенно имеет «достаточную» сложность, чтобы гарантировать использование Vagrant. С двумя серверами и множеством способов их настройки легко нарушить синхронизацию конфигурации от одного разработчика к другому, что приведет к синдрому «работает на моей машине». Для этого типа программного обеспечения лучше всего отредактировать и скомпилировать код на хосте и развернуть его на Vagrant VM, которая имитирует вашу производственную среду. Папка развертывания для веб-сервера может быть даже связана с целью компиляции на хосте, что устраняет необходимость в повторном развертывании вручную. Так что Vagrant может стать важной частью вашего жизненного цикла разработки,

Для автономных приложений Java (например, библиотек или настольных приложений) история немного меняется. В этом случае имеет смысл редактировать, компилировать и запускать на хост-машине, полностью избегая использования Vagrant. Если вы используете одну из больших Java IDE (Eclipse, Netbeans, IntelliJ ...), у вас уже установлена ​​Java на машине. На этом этапе существует очень небольшое преимущество по сравнению с накладными расходами на использование Vagrant, и оно служит только для добавления дополнительного уровня сложности в ваш процесс разработки. Это потому, что к тому времени, когда вы сможете редактировать Java с помощью IDE, вы в любом случае сможете запускать все на хосте. Одна из проблем заключается в том, что версия Java, необходимая для проекта, может не соответствовать версии, в которой работает IDE на хосте. В общем (надеюсь) это не такая уж большая проблема; на момент написания этой статьи срок службы JDK6 истек, а JDK8 еще не выпущен (угадайте, что нам остается). Но если вам нужно было запустить несколько версий, вы сможете установить JAVA_HOME на хосте по мере необходимости. Хотя это вносит дополнительную сложность, это менее сложно, чем поддержка среды выполнения Vagrant только для работы с проектами, использующими разные версии Java.

Интересный вопрос: что делать с бесконтейнерными веб-приложениями. Должен ли веб-сервер (в данном случае внутренний по отношению к приложению) запускаться внутри виртуальной машины, как мы это делали для внешнего веб-сервера? Или запустить на хосте, как мы сделали для автономного приложения? Для бесконтейнерных веб-приложений нет необходимости беспокоиться о внешнем веб-сервере, но, скорее всего, существует база данных. В этой ситуации мы можем использовать гибридный подход. Запуск бесконтейнерного веб-приложения по существу аналогичен запуску автономного приложения, поэтому было бы эффективно скомпилировать и запустить ваш код на хост-машине. Но с задействованной базой данных все еще достаточно сложности и конфигурации, поэтому имеет смысл разместить сервер базы данных на собственной Vagrant VM.

Надеюсь, это даст разработчикам Java, которые интересуются Vagrant, некоторый контекст о том, как его использовать.

Последний год интересовался этой темой :)

Мое решение - иметь бродячую машину, настраиваемую с помощью флагов. Например, один из этих флагов включает графический интерфейс рабочего стола, потому что некоторые разработчики предпочитают кодировать на хост-машине, в то время как другие предпочитают иметь гораздо более интегрированную среду с рабочим столом и IDE в нем.

Чтобы справиться с медлительностью рабочего стола, вы должны установить очень полезный плагин vagrant (да ... у vagrant есть плагины, которые значительно улучшают среду разработки) следующим образом: vagrant plugin install vagrant-vbguest Этот плагин установит гостевое дополнение виртуального ящика на каждом госте в сделать его пригодным для использования при использовании интерфейса виртуального бокса. Затем, чтобы включить графический интерфейс, отредактируйте Vagrantfile следующим образом:

config.vm.provider "virtualbox" do | vb | vb.gui = истинный конец

Вместо того, чтобы ускорить работу общих папок, я предлагаю использовать rsync: config.vm.synced_folder "./git", "/ home / vagrant / git", введите: "rsync", rsync__exclude: ".git /" В этом способ редактирования исходного кода на хосте, а затем rsync-ed с гостем.