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

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

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

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

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

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

Зачем нужна среда IDE на виртуальной машине

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

Мне было интересно эту тему за последний год:)

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

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

config.vm.provider "virtualbox" do | vb | vb.gui = true конец

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