Назад | Перейти на главную страницу

Каковы передовые методы работы с несколькими JVM на сервере?

Многие сторонние продукты требуют определенной версии JRE или JDK, и многие из наших серверов выполняют несколько задач. Команды разработчиков утверждают, что им все равно, где установлена ​​Java. Большинство приложений просто полагаются на переменные среды (или что-то еще, что Java валяется), но тем командам, которым требуются определенные версии, нужно сообщить, где найти их конкретную версию. Мне не нравится то, что теперь я не могу переместить JVM, не посетив все приложения, которые могут ее использовать. Очевидный ответ - создать программу, которая скрывает от них детали и раскрывает местоположение через API. Это решение потребовало бы, чтобы каждое приложение Java было обернуто некоторым скриптом, запрашивающим среду.

Я не люблю излишних сложностей или изобретения велосипеда. Есть ли какая-то стандартная практика, встроенная функция Java или очевидное решение, которое мне не хватает?

Я придумал, что каждое приложение должно управлять ссылкой на своем пути, чтобы указать на Java, которую оно хочет, но мне все равно нужно будет сообщить им, где она находится.

Виртуализация - вот как мы с этим справляемся там, где я работаю.

обновление - Извините, если я не понял - мы размещаем каждое приложение на собственном виртуальном сервере только с той версией JVM, которая ему требуется

В идеале вам нужно установить две переменные среды:

export JAVA_HOME=/java/location
export PATH=$JAVA_HOME/bin:$PATH

Вы можете создавать разные сценарии для запуска различных программ и устанавливать эти переменные по-разному в каждом случае. Или вы можете настроить каждое приложение для запуска под другой учетной записью пользователя и установить эти переменные в соответствующем пользователю сценарии запуска.

$ JAVA_HOME / bin должен быть первым в PATH, чтобы вместо этого не запускались другие двоичные файлы java по пути по умолчанию.

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

Если вы имеете дело с критически важными приложениями, вам может потребоваться одна JVM для каждого приложения или чтобы каждое приложение указывало непосредственно на определенную версию JVM.

Например, там, где я работаю, есть приложение (назовите его A), которое специально работает и было протестировано для определенного JDK и версии (JDK 1.5.0_03), более поздние версии, как известно, нарушают его.

Если приложение A и другое приложение B указали на символическую ссылку с именем java-5, а затем при развертывании приложения B я решил обновить java-5, чтобы он указывал на JDK 1.5.0_14, тогда приложение A сломалось бы.

Как упоминалось в разделе «Как лучше всего обрабатывать системную информацию при управлении версиями?», Путь JVM может быть частью фазы де-вариабилизации.
Т.е. ваш файл конфигурации можно переписать по адресу:

  • время развертывания, замена некоторых переменных значениями, зависящими от среды
  • время выполнения (в начале), заменяя некоторые другие переменные значениями, зависящими от сеанса.

Это означает, что как раз в самом начале приложения мы помещаем в полную программу запрос к базе данных, которая содержит значения, которые могут изменяться от сеанса к сеансу.
Последний путь JVM - один из них.
Запрос основан на имени сервера (или пула серверов) и имени программы.

В системах на базе * nix вы можете использовать программные ссылки. Затем просто напишите свой сценарий запуска, чтобы использовать наименее конкретную версию, которую он предпочитает. JRE_HOME = / usr / lib / jre / java-5

/usr/lib/jre/...

java -> java-5
java-4 -> java-4-sun
java-5 -> java-5-sun
java-6 -> java-6-sun

java-4-sun -> java-4-sun-1.4.0.0
java-5-sun -> java-5-sun-1.5.0.14
java-6-sun -> java-6-sun-1.6.0.10

java-4-sun-1.4.0.1
java-5-sun-1.5.0.12
java-5-sun-1.5.0.14
java-6-sun-1.6.0.10

Этот метод используется во многих системах на базе Linux. см. примеры в / etc / alternitives и / usr / lib / jre.

В Windows вы можете использовать переменные среды, чтобы делать что-то подобное. Тогда ваш сценарий запуска может «установить JRE_HOME =% JAVA_5%».

Команды приложений не могут использовать оба варианта.

Если приложение поддерживает только одну версию JRE, оно должно поставляться вместе с ней. Его следует установить вместе с приложением.

Я не понимаю, зачем им это нужно по-другому. Это гарантирует, что точную версию JRE они протестировали свое приложение с тот же, что вы развертываете в производственной среде. Думать, что вам не нужно «заботиться» о JVM, - хороший идеал, когда вы учитесь в школе, а Java - это «напиши один раз, запусти где угодно». Но, честно говоря, это мнение не согласуется с реальным миром, где Java фактически «напиши один раз, протестируй везде».

Для команды разработчиков было бы кошмаром заботиться о проблемах, связанных с JVM. Устраните эту неопределенность, возьмите ее и используйте JVM для каждого приложения. Место на диске дешевое.

Мы просто используем символические ссылки на версии, которые хотим использовать. У нас есть несколько машин, на которых Java установлена ​​в разных местах, и приложению не нужно знать, где они находятся в разных ящиках.

Другой вариант - использовать java webstart для ваших приложений. В этом случае он даже загрузит и установит нужную версию, если у вас ее нет.

Я помещаю все в / opt / java-version, используя извлеченную загрузку из Sun (сохраняя имя каталога по умолчанию). Приложения обычно запускаются как собственный пользователь, запускаются и останавливаются с помощью сценария инициализации, который устанавливает все переменные для этого приложения, включая $ JAVA_HOME.

Если у меня есть приложение, я хочу всегда использовать «текущую» установку в / opt. Я создаю символические ссылки в / opt и заставляю сценарий инициализации указывать на эту символическую ссылку. Затем символическая ссылка настраивается при установке новой среды выполнения Java.