Моя вики: Удаленный JMX-доступ к WildFly (или JBoss AS7) с использованием JConsole

Одной из целей JBoss AS7 было сделать его намного более безопасным по умолчанию, по сравнению с предыдущими версиями. Одна из областей, на которую непосредственно повлияла эта цель, заключалась в том, что вы больше не могли ожидать, что сервер предоставит какой-либо сервис порту и получит к нему доступ без какой-либо аутентификации / авторизации. Помните, что в предыдущих версиях JBoss AS вы могли получить доступ к порту JNDI, порту JMX без какой-либо аутентификации / авторизации, если эти порты были открыты для связи удаленно. Более тонкая авторизация на таких портах для связи в JBoss AS7 позволяет серверу контролировать, кто получает возможность вызывать операции через этот порт.

Конечно, это не ограничивается JBoss AS7, но продолжает оставаться целью в WildFly (переименовании сервера приложений JBoss). Фактически, WildFly пошел еще дальше и теперь имеет функцию «единого порта» для всех коммуникаций.

Связь JMX в JBoss AS7 и WildFly

Исходя из этого, теперь мы сосредоточимся на коммуникации JMX в JBoss AS7 и WildFly. Я буду использовать WildFly (8.2.0 Final) в качестве ссылки для остальной части этой статьи, но те же подробности применимы (с небольшими изменениями) к другим основным версиям JBoss AS7 и WildFly, которые были выпущены до настоящего времени.

Сервер WildFly состоит из «подсистем», каждая из которых предоставляет определенный набор функций. Например, есть подсистема EE, которая поддерживает набор функций Java EE. Тогда есть подсистема Undertow, которая поддерживает функциональность веб / HTTP-сервера. Аналогично, существует подсистема JMX, которая предоставляет набор функций JMX на сервере. Как вы все знаете, я уверен, что служба JMX стандартно используется для мониторинга и даже управления серверами Java, включая удаленное управление серверами. Подсистема JMX в WildFly обеспечивает удаленный доступ к службе JMX, а порт 9990 используется для этой удаленной связи JMX.

JConsole для удаленного доступа JMX к JBoss AS7 и WildFly

Java (JDK) поставляется в комплекте с инструментом JConsole, который позволяет подключаться к локальным или удаленным средам исполнения Java, которые предоставляют сервис JMX. Утилита проста в использовании, все, что вам нужно сделать, это запустить команду jconsole, она покажет графическое меню, в котором перечислены все локальные процессы Java, а также возможность указать удаленный URL-адрес для подключения к удаленному процессу:

Предположим, что вы запустили автономный сервер WildFly локально. Теперь, когда вы запустите jconsole, вы заметите, что Java-процесс WildFly указан в списке локальных запущенных процессов, к которым вы можете подключиться. Когда вы выберете экземпляр WildFly Java, вы автоматически подключитесь к нему и заметите MBean-компоненты, предоставляемые сервером. Однако в контексте этой статьи этот режим «локального процесса» в JConsole не является тем, что нас интересует.

Давайте используем опцию «Удаленный процесс» в этом меню JConsole, которая позволяет вам указать удаленный URL-адрес для подключения к среде выполнения Java, а также имя пользователя и пароль для подключения к этому экземпляру. Несмотря на то, что наш сервер WildFly работает локально, мы можем использовать эту опцию «Удаленный процесс», чтобы попытаться подключиться к нему. Итак, давайте попробуем это. Однако до этого давайте рассмотрим следующие несколько моментов:

1. Помните, что подсистема JMX в WildFly разрешает удаленный доступ через порт 9990
2. Для удаленного доступа к JMX URL-адрес имеет формат: service: jmx: [vendor-specific-protocol]: // [host]: [port]. Интересным здесь является протокол для конкретного поставщика. В случае WildFly этот протокол для конкретного поставщика — http-remoting-jmx.
3. Помните, что WildFly по умолчанию защищен, что означает, что только потому, что подсистема JMX предоставляет порт 9990 для удаленного общения, это не означает, что он открыт для общения с кем-либо. Для обеспечения возможности связи через этот порт клиент-клиент должен пройти проверку подлинности и авторизацию. Это поддерживается «ManagementRealm» в WildFly. Пользователи, прошедшие проверку подлинности и авторизованные в этой области, имеют доступ к этому порту.

Помня об этом, давайте сначала создадим пользователя в области управления. Это можно сделать с помощью сценария командной строки add-user (который находится в папке JBOSS_HOME / bin). Я не буду вдаваться в подробности этого, так как для этого достаточно документации. Давайте просто предположим, что я создал пользователя с именем «wflyadmin» с соответствующим паролем в области управления. Чтобы убедиться, что пользователь был правильно создан, в правой области откройте консоль администратора WildFly по URL-адресу http: // localhost: 9990 / console. Вам будет предложено ввести имя пользователя и пароль для доступа. Используйте то же имя пользователя и пароль вновь созданного пользователя. Если логин работает, значит у вас все хорошо. Если нет, то убедитесь, что вы сделали все правильно при добавлении нового пользователя (как я уже сказал, я не буду вдаваться в подробности добавления нового пользователя, так как он будет просто растягивать эту статью излишне долго).

Итак, на данный момент мы создали пользователя с именем «wflyadmin», принадлежащего ManagementRealm. Мы будем использовать эту же учетную запись для доступа к сервису JMX в WildFly через JConsole. Итак, давайте теперь вызовем jconsole как обычно:

В меню JConsole давайте снова выберем опцию «Удаленный процесс» и используем следующий URL в текстовом поле URL:

Примечание. Для JBoss AS 7.x и JBoss EAP 6.x протокол поставщика — remoting-jmx, а порт для связи — 9999 . Таким образом, URL будет службой: jmx: remoting-jmx: // localhost: 9999

В текстовых полях имени пользователя и пароля используйте того же пользователя / пароль, который вы только что создали. Наконец, нажмите на Connect. Что ты видишь? Это не работает! Сбой соединения. Так что пошло не так?

Почему не работает удаленный доступ JConsole к WildFly?

Вы сделали все очевидные вещи, необходимые для удаленного доступа к сервису WildFly JMX, но продолжаете видеть, что JConsole не может подключиться к нему. Что может быть причиной? Помните, в одном из этих моментов ранее я отмечал, что «протокол конкретного производителя» интересен? Мы используем http-remoting-jmx, и этот протокол внутренне зависит от определенных библиотек WildFly / JBoss, в первую очередь для удаленной связи, аутентификации и авторизации. Эти библиотеки зависят от сервера WildFly и, следовательно, не являются частью стандартной среды выполнения Java. Когда вы запускаете jconsole, он использует стандартный путь к классам, который просто имеет соответствующие библиотеки, которые являются частью JDK / JRE.

Чтобы решить эту проблему, вам нужно добавить библиотеки библиотек WildFly в classpath JConsole. Перед тем, как посмотреть, как это сделать, давайте посмотрим, какие библиотеки WildFly необходимы. Все необходимые классы для этого являются частью jboss-cli-client.jar, который находится в папке JBOSS_HOME / bin / client /. Поэтому все, что нам нужно сделать, это включить jar в путь к классу инструмента jconsole. Для этого мы используем опцию -J инструмента jconsole, которая позволяет передавать параметры во время выполнения Java jconsole. Команда для этого:

(Обратите внимание, что для Windows разделитель пути к классам — это точка с запятой вместо двоеточия)

Обратите внимание, что специфичный для сервера jar для JBoss AS 7.x и JBoss EAP 6.x называется jboss-client.jar и находится в том же каталоге JBOSS_HOME / bin / client.

Таким образом, мы передаем -Djava.class.path в качестве параметра в среду выполнения jconsole Java, используя опцию -J. Обратите внимание, что в этом пути к классам мы указали больше, чем просто jar для конкретного сервера. Это потому, что использование -Djava.class.path должно содержать полный путь к классам. Мы включаем файлы jar из папки lib JDK Java, которые необходимы для JConsole, а также файлы jar, специфичные для нашего сервера, в этот путь к классам.

Выполнение этой команды должно запустить JConsole как обычно, и давайте продолжим, выбрав опцию «Удаленный процесс» и указав тот же URL, что и раньше:

и то же имя пользователя и пароль, что и раньше, и нажмите кнопку Подключиться. На этот раз вы должны иметь возможность подключиться и начать видеть MBeans и другие сервисы, открытые через JMX.

Как насчет предоставления сценария, который выполняет эту необходимую настройку classpath?

Поскольку использование JConsole для удаленного доступа по отношению к WildFly является обычной практикой, разумно ожидать наличия сценария, который устанавливает путь к классам (как указано выше), и затем вы можете просто использовать этот сценарий. Вот почему WildFly поставляет такой скрипт. Он находится в папке JBOSS_HOME / bin и называется jconsole.sh (и jconsole.bat для Windows). Это просто скрипт-обертка, который внутренне вызывает инструмент jconsole, присутствующий в Java JDK, после соответствующей настройки пути к классам. Все, что вам нужно сделать, это запустить:

Как насчет использования JConsole с действительно удаленной машины против WildFly?

До сих пор мы использовали инструмент jconsole, который присутствовал на том же компьютере, что и экземпляр WildFly, что означало, что у нас есть доступ файловой системы к специальным jar-серверам WildFly, присутствующим в каталоге установки WildFly в файловой системе. Это позволило нам настроить classpath для jconsole, чтобы он указывал на jar в локальной файловой системе?

Что делать, если вы хотите запустить jconsole с удаленного компьютера на сервере WildFly, который установлен и работает на другом компьютере. В этом случае ваш удаленный клиентский компьютер не будет иметь доступа файловой системы к каталогу установки WildFly. Таким образом, чтобы запустить jconsole в таком сценарии, вам нужно скопировать JBOSS_HOME / bin / jboss-cli-client.jar на удаленный клиентский компьютер, в каталог по вашему выбору, а затем настроить путь к классу для инструмента jconsole, как описано выше. раньше и наведите его на эту банку. Это должно дать вам доступ к службам JMX WildFly из jconsole на удаленной машине.