Как запустить Java-приложение с конкретной версией
У меня на компьютере (Ubuntu) установлены две версии Java, 8 и 11.
Версия 11 стоит по умолчанию, и все программы работают с ней, но есть программа, которая требует версию 8. Скажите, как мне запускать эту программу, чтоб она использовала версию 8, а не 11.
Может скрипт какой-то нужен? Раньше никогда с этим не сталкивался, поэтому даже не знаю с какой стороны к этому подходить.
Со стороны поисковых запросов в гугл подходи, не ошибёшься.
Найти в системе где там в Ubuntu у вас java 8-ой версии. Затем выполнить в терминале (как пример): /usr/lib/jdk8/bin/java -jar
Я бы ещё переопределил JAVA_HOME (она может указывать на 11-ю версию), и JAVA_HOME/bin добавил бы в начало PATH.
Классные иконки/тема. Подскажи название пожалуйста. Или это в Ubuntu дефолт так вылизали?
Ubuntu + Cinnamon + mate-icon-theme-faenza.
В меню Themes выставлены оформление — menta, иконки — matefaenza, всё остальное — adwaita. Не без косяков, но мне норм.
Источник
Как запустить программу на Java в Ubuntu
Добавьте команду &>/dev/null к команде для отправки stdout и stderr в /dev/null, нирваны систем Linux:
Кстати, неважно, куда вы помещаете перенаправление, это тоже прекрасно:
2 ответа
Откройте терминал и выполните:
, а затем скомпилируйте вашу Java-программу, как раньше, с помощью: javac abc.java . Затем запустите его с помощью:
Вы также можете заменить openjdk-6-jdk вместо openjdk-7-jdk в первой команде. В Ubuntu 15.10 и новее вы также можете заменить openjdk-8-jdk вместо openjdk-7-jdk в первой команде. В Ubuntu 17.10 вы также можете заменить openjdk-9-jdk. В Ubuntu 17.10 и более поздних версиях вы также можете заменить openjdk-11-jdk.
Если вы предпочитаете устанавливать Oracle JDK, в этой статье объясняется пошаговая инструкция по установке Oracle JDK 8: Установка последней версии Oracle JDK в Ubuntu
Шаг 1 : Загрузите последнюю версию JDK (jdk-Xuxx-linux-xXX.tar.gz) по этой официальной ссылке .
Шаг 2: Откройте терминал (Ctrl + Alt + T) и введите следующую команду.
Шаг 3: Введите следующую команду, чтобы изменить каталог.
Шаг 4: Извлеките файл jdk-Xuxx-linux-xXX.tar.gz из этого каталога с помощью этой команды.
Шаг 5: Введите следующую команду, чтобы открыть файл переменных среды.
Шаг 6: В открывшемся файле добавьте следующие папки bin в существующую переменную PATH.
Переменные PATH должны быть разделены точкой с запятой. Обратите внимание, что установленная версия JDK — обновление 1.8, версия 45. В зависимости от версии JDK пути могут быть разными. Добавьте следующие переменные окружения в конец файла.
Источник
Как сделать простым и понятным запуск Java-процессов в Linux / Docker
По профилю работы DevOps-инженером я часто занимаюсь автоматизацией установки и настройки разнообразных IT-систем в различных средах: от контейнеров до облака. Приходилось работать со многими системами, основанными на Java-стеке: от небольших (вроде Tomcat), до масштабных (Hadoop, Cassandra и др.).
При этом почти каждая такая система, даже самая простая, почему-то имела сложную неповторимую систему запуска. Как минимум, это были многострочные shell-скрипты, как в Tomcat, а то и целые фреймворки, как в Hadoop. Мой нынешний «пациент» из этой серии, вдохновивший меня на написание этой статьи — хранилище артефактов Nexus OSS 3, скрипт запуска которого занимает
Непрозрачность, избыточность, запутанность startup-скриптов создает проблемы даже при ручной установке одного компонента на локальной системе. А теперь представьте, что набор таких компонентов и сервисов нужно запаковать в Docker-контейнер, попутно написав еще один слой абстракции для мало-мальски адекватного оркестрирования, развернуть в Kubernetes-кластере и реализовать этот процесс в виде CI/CD-пайплайна.
Короче говоря, давайте на примере упомянутого Nexus 3 разберемся, как вернуться из лабиринта shell-скриптов к чему-то более похожему на java -jar
, учитывая наличие удобных современных DevOps-инструментов.
Откуда такая сложность?
Если в двух словах, то в древние времена, когда при упоминании UNIX не переспрашивали: «в смысле, Linux?», не было Systemd и Docker и др., для управления процессами использовались переносимые shell-скрипты (init-скрипты) и PID-файлы. Init-скрипты задавали необходимые настройки окружения, которые в разных UNIX-ах были свои, и, в зависимости от аргументов, запускали процесс или перезапускали/останавливали его с помощью ID из PID-файла. Подход простой и понятный, но эти скрипты переставали работать при каждой нестандартной ситуации, требуя ручного вмешательства, не позволяли запустить несколько копий процесса… но не суть.
Так вот, если внимательно посмотреть на упомянутые выше startup-скрипты в Java-проектах, то можно в них разглядеть явные признаки этого доисторического подхода, включая даже упоминания SunOS, HP-UX и других UNIX-ов. Как правило, такие скрипты делают примерно следующее:
- используют синтаксис POSIX shell со всеми его костылями для UNIX/Linux-переносимости
- определяют версию и релиз ОС через uname , /etc/*release и т.п.
- ищут JRE/JDK в укромных уголках файловой системы и выбирают наиболее «подходящую» версию по хитрым правилам, иногда еще и специфичным для каждой ОС
- рассчитывают числовые параметры JVM, например, размер памяти ( -Xms , -Xmx ), количество потоков GC и др.
- оптимизируют JVM через -XX -параметры с учетом специфики выбранной версии JRE/JDK
- отыскивают свои компоненты, библиотеки, пути к ним по окружающим директориям, конфигурационным файлам и т.п.
- настраивают окружение: ulimits, переменные среды и т.п.
- генерируют CLASSPATH циклом типа: for f in $path/*.jar; do CLASSPATH=»$
:$f»; done - парсят аргументы командной строки: start|stop|restart|reload|status|.
- собирают Java-команду, которую в итоге нужно выполнить, из перечисленного выше
- и, наконец, выполняют эту Java-команду. Зачастую при этом явно или неявно используются все те же пресловутые PID-файлы, & , nohup , специальные TCP-порты и прочие трюки из прошлого столетия (см. пример из Karaf)
Упомянутый скрипт запуска Nexus 3 — подходящий пример такого скрипта.
По сути, вся перечисленная выше скриптовая логика, как бы, пытается заменить системного администратора, который бы установил и настроил все вручную под конкретную систему от начала до конца. Но вообще любые требования самых разнообразных систем учесть, в принципе, невозможно. Поэтому получается, наоборот, головная боль, как для разработчиков, которым нужно поддерживать эти скрипты, так и для системных инженеров, которым в этих скриптах потом нужно разбираться. С моей точки зрения, системному инженеру гораздо проще один раз разобраться в параметрах JVM и настроить ее как надо, чем каждый раз при установке новой системы разбираться в тонкостях ее startup-скриптов.
Что же делать?
У — про — щать! KISS и YAGNI нам в руки. Тем более, что на дворе 2018-й год, а это значит, что:
- за очень редким исключением, UNIX == Linux
- задача управления процессами решена как для отдельного сервера (Systemd, Docker), так и для кластеров (Kubernetes и т.п.)
- появилась куча удобных инструментов управления конфигурациями (Ansible и др.)
- в администрирование пришла и уже основательно закрепилась тотальная автоматизация: вместо ручной настройки хрупких неповторимых «серверов-снежинок» теперь можно автоматически собирать унифицированные репродуцируемые виртуальные машины и контейнеры с помощью целого ряда удобных инструментов, включая упомянутые выше Ansible и Docker
- повсеместно используются инструменты сбора runtime-статистики, как для самой JVM (пример), так и для Java-приложения (пример)
- и, самое главное, появились специалисты: системные и DevOps-инженеры, которые умеют использовать перечисленные выше технологии и понимают, как правильно установить JVM на конкрентной системе и впоследствии подстроить ее с учетом собранной runtime-статистики
Так что давайте снова пройдемся по функционалу startup-скриптов еще раз с учетом перечисленных пунктов, не пытаясь при этом делать работу за системного инженера, и уберем оттуда все «лишнее».
- синтаксис POSIX shell ⇒ /bin/bash
- определение версии ОС ⇒ UNIX == Linux, если есть ОС-специфичные параметры, можно описать их в документации
- поиск JRE/JDK ⇒ у нас единственная версия, и это OpenJDK (ну или Oracle JDK, если уж очень нужно), java и компания есть в стандартном системном пути
- расчет числовых параметров JVM, тюнинг JVM ⇒ это можно описать в документации по скалированию приложения
- поиск своих компонентов и библиотек ⇒ описать структуру приложения и способы ее настройки в документации
- настройка окружения ⇒ описать в документации требования и особенности
- генерация CLASSPATH ⇒ -cp path/to/my/jars/* или даже, вообще, Uber-JAR
- парсинг аргументов командной строки ⇒ аргументов не будет, т.к. обо всем, кроме запуска, позаботится менеджер процессов
- сборка Java-команды
- выполнение Java-команды
В итоге, нам нужно просто собрать и выполнить Java-команду вида java -jar
с помощью выбранного менеджера процессов (Systemd, Docker и т.п.). Все параметры и опции ( ) мы оставляем на усмотрение системного инженера, который подстроит их под конкретную среду. Если список опций довольно длинный, можно вновь вернуться к идее startup-скрипта, но, в этом случае, максимально компактного и декларативного, т.е. не содержащего никакой программной логики.
Пример
В качестве примера давайте посмотрим, как можно упростить скрипт запуска Nexus 3.
Самый простой вариант, чтобы не залезать в дебри этого скрипта — просто запустить его в реальных условиях ( ./nexus start ) и посмотреть на результат. Например, можно найти полный список аргументов запущенного приложения в таблице процессов (через ps -ef ), или запустить скрипт в режиме отладки ( bash -x ./nexus start ), чтобы наблюдать весь процесс его выполнения и в самом конце — команду запуска.
Вначале применим к ней пару простых приемов:
- поменяем /the/long/and/winding/road/to/my/java на java , ведь она есть в системном пути
- поместим список Java-параметров в отдельный массив, отсортируем его и уберем дубликаты
Теперь можно идти в глубину.
Install4j — это такой графический Java-инсталлятор. Похоже, что он используется для начальной установки системы. На сервере он нам не нужен, убираем.
Договоримся о размещении компоненты и данные Nexus на файловой системе:
- поместим само приложение в /opt/nexus-
- для удобства создадим символическую ссылку /opt/nexus -> /opt/nexus-
- сам скрипт разместим вместо исходного как /opt/nexus/bin/nexus
- все данные нашего Nexus будут лежать на отдельной файловой системе, смонтированной как /data/nexus
Само создание каталогов и ссылок — удел систем управления конфигурациями (на все про все 5-10 строчек в Ansible), поэтому оставим эту задачу системным инженерам.
Пусть наш скрипт при запуске меняет рабочий каталог на /opt/nexus — тогда мы сможем поменять пути к компонентам Nexus на относительные.
Опции вида -Dkaraf.* — это настройки Apache Karaf, OSGi-контейнера, в который, очевидно, «запакован» наш Nexus. Поменяем karaf.home , karaf.base , karaf.etc и karaf.data соответственно размещению компонентов, по возможности используя относительные пути.
Видя, что CLASSPATH состоит из списка jar-файлов, которые лежат в одном каталоге lib/ , заменим весь этот список на lib/* (придется также выключить wildcard expansion с помощью set -o noglob ).
Поменяем java на exec java , чтобы наш скрипт на запускал java как дочерний процесс (менеджер процессов этот дочерний процесс просто не увидит), а «заменял» себя на java (описание exec).
Посмотрим, что нас получилось:
Итого всего 27 строчек вместо >400, прозрачно, понятно, декларативно, никакой лишней логики. При необходимости этот скрипт легко превратить в темплейт для Ansible/Puppet/Chef и добавить туда только ту логику, которая нужна для конкретной ситуации.
Этот скрипт можно использовать в качестве ENTRYPOINT в Dockerfile или вызывать в unit-файле Systemd, заодно подстроив там ulimits и другие системные параметры, например:
Заключение
Какие выводы можно сделать из этой статьи? В принципе, все сводится к паре пунктов:
- У каждой системы свое предназначение, т.е., не нужно забивать гвозди микроскопом.
- Простота (KISS, YAGNI) рулит — реализовывать только то, что нужно для данной конкретной ситуации.
- И самое главное: круто, что есть IT-специалисты разного профиля. Давайте будем взаимодействовать и делать наши IT-системы проще, понятнее и лучше! 🙂
Спасибо за внимание! Буду рад обратной связи и конструктивной дискуссии в комментариях.
Источник
Запуск приложения Java как службы в Linux
Я написал серверное приложение Java, которое работает на стандартном виртуальном размещенном решении Linux. Приложение работает все время прослушивания сокетов соединений и создания новых обработчиков для них. Это реализация на стороне сервера для клиент-серверного приложения.
Как я начинаю это, включив его в start up rc.местные скрипт сервера. Однако после запуска я не знаю, как получить к нему доступ, чтобы остановить его, и если я хочу установить обновление, поэтому я должен перезапустить сервер, чтобы перезапустить приложение.
на ПК с windows для этого типа приложений я мог бы создать службу windows, а затем я могу остановить и запустить ее, как я хочу. Есть ли что-то подобное в Linux box, чтобы при запуске этого приложения я мог остановить его и перезапустить без полного перезапуска сервера.
мое приложение называется WebServer.исполняемый. Он запускается при запуске сервера, включая его в мой rc.местные такие как:
Я немного нуб в Linux, поэтому любой пример будет оценен с любыми сообщениями. Однако у меня есть SSH и полный FTP-доступ к коробке для установки любых обновлений, а также доступ к панели Plesk.
14 ответов
Я написал здесь еще одну простую обертку:
вы можете следовать полный учебник для init.d здесь и для systemd (ubuntu 16+) здесь
Если вам нужен журнал вывода, замените 2
простым решением является создание скрипта start.sh это запускает Java через nohup, а затем сохраняет PID в файл:
тогда ваш сценарий остановки stop.sh прочитал бы PID из файла и убил бы приложение:
конечно, я опустил некоторые детали, например, проверить, существует ли процесс и удалить pid.txt Если вы закончили.
скрипт инициализации службы Linux хранятся в /etc/init.d . Вы можете копировать и настраивать /etc/init.d/skeleton файл, а затем вызов
см.http://www.ralfebert.de/blog/java/debian_daemon/. Его для Debian (так, Ubuntu также), но подходит больше дистрибутива.
возможно, не лучшее решение для dev-ops, но хорошо для общего использования сервера для вечеринки lan или аналогичного.
использовать screen для запуска сервера, а затем отсоединить перед выходом из системы, это будет держать процесс работает, вы можете повторно подключить в любой момент.
документооборот:
пуск экран: screen
запустить сервер: java -jar minecraft-server.jar
отключить нажатием: Ctl-a , d
прикрепления: screen -r
Другой альтернативой, которая также довольно популярна, является Java Service Wrapper. Это также довольно популярно в сообществе OSS.
ссыль приложение Spring Boot в качестве службы а также, я бы пошел на systemd версия, так как это самый простой, наименее подробный и лучше всего интегрирован в современные дистрибутивы (и даже не очень современные, такие как CentOS 7.икс.)
вот пример сценария оболочки (убедитесь, что вы заменили математическое имя на имя вашего приложения):
С приложение Spring Boot в качестве службы, Я могу порекомендовать Python-based supervisord приложение. См. этот вопрос переполнения стека для получения дополнительной информации. Это очень просто настроить.
Источник
