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

92

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

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

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

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

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

Зачем IDE на ВМ

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

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

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

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

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

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

java vagrant Джей
источник

Ответы:

61

После долгих размышлений и экспериментов я решил, где использовать 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, некоторый контекст о том, как его использовать.

Джей
источник
для хоста с ОС Windows и виртуальной машины с ОС Linux, что вы думаете о запуске IntelliJ на виртуальной машине Linux, работающей на хосте (Windows) через X11?
Кевин Мередит
3
Отличный вопрос: я не упоминал об этом, но я провел много тестов с запуском IDE внутри Vagrant VM и обнаружил, что производительность ужасна ... поскольку нажатие на меню заняло около 12 секунд, чтобы ответить. Я пробовал такие вещи, как: указать более быстрый шифр, использовать сжатие для X11 и увеличить видеопамять виртуальной машины, только чтобы получить время отклика до 4 секунд, которое все еще было непригодным для использования. Поэтому я считаю, что Vagrant не предназначен для запуска IDE.
Джей
Я думаю, вам стоит попробовать - я не включал ускорение VirtualBox 2D, как это делается для хостов Windows (а у меня не было хоста Windows). Другие идеи производительности, которые мне не удалось попробовать, включают: по слухам, провайдер VMWare имеет специальные оптимизации графики, может попробовать VRDP, который может иметь лучшую производительность, чем X11, NX Server должен быть быстрее, чем X11, и, наконец, есть специи- space.org. Если вы найдете что-то, что работает хорошо, пожалуйста, напишите здесь, потому что я хотел бы услышать об этом!
Джей
2
Я не тестировал IntelliJ внутри гостевой виртуальной машины (и, возможно, не могу рассказать коллеге о его медлительности в гостевой машине). Тем не менее, я прочитал следующее в «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.Заявление этой книги (написанное создателем Vagrant), кажется, выступает против компиляции в хост-виртуальной машине, не так ли?
Кевин Мередит
4
В цитате упоминается «серьезное снижение производительности в виртуальной машине» и не упоминается глобальное снижение производительности для хоста, поэтому я думаю, что здесь контекст для производительности / операций внутри виртуальной машины . В этом контексте я интерпретирую эту цитату как предсказание производительности, когда этап компиляции выполняется внутри гостевой системы, а не как рекомендацию компиляции на гостевой машине по сравнению с хостом. Не могли бы вы рассказать подробнее о контексте этой цитаты? Обращается ли книга конкретно к этому сценарию? Конечно, все это подлежит реальным испытаниям :)
Джей
3

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

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

Саверио Феррара
источник