Развертывание и настройка приложения Java SE, Tomcat или JBoss EAP в Службе приложений Azure

Чтобы развернуть файлы Java-архива (JAR) в среде Java SE, используйте конечную точку /api/publish сайта Kudu. Дополнительные сведения об этом API см. в этой документации.

Чтобы развернуть WAR-файлы в Tomcat, используйте конечную точку /api/wardeploy/, чтобы загрузить ваш архивный файл POST. Дополнительные сведения об этом API см. в этой документации.

Чтобы развернуть WAR-файлы в JBoss EAP, используйте конечную точку /api/wardeploy/ в POST архивный файл. Дополнительные сведения об этом API см. в этой документации.

Чтобы развернуть файлы EAR, используйте FTP. Приложение EAR развертывается в корневом каталоге контекста, определенном в конфигурации приложения. Например, если корень контекста приложения — <context-root>myapp</context-root>, вы можете найти сайт по пути /myapp: http://my-app-name.azurewebsites.net/myapp. Если вы хотите, чтобы ваше веб-приложение обслуживалось на корневом пути, убедитесь, что оно устанавливает корневой контекст в этот путь: <context-root>/</context-root>. Дополнительные сведения см. в разделе Установка корня контекста веб-приложения.

Tomcat также предоставляет переписывающий модуль.

JBoss EAP также предоставляет модуль для перенаправления запросов.

В портале Azure в разделе Параметры приложения для веб-приложения создайте новый параметр приложения, который JAVA_OPTS содержит другие параметры, например -Xms512m -Xmx1204m.

В портале Azure в разделе Параметры приложения для веб-приложения создайте новый параметр приложения, который CATALINA_OPTS содержит другие параметры, например -Xms512m -Xmx1204m.

Предварительная компиляция JSP-файлов

Чтобы повысить производительность приложений Tomcat, можно скомпилировать JSP-файлы перед развертыванием в службе приложений. Вы можете использовать плагин Maven, предоставленный Apache Sling, или этот файл сборки Ant.

Если вы используете Tomcat, можно закрепить версию исправления Tomcat. На Windows версии исправления виртуальной машины Java и Tomcat можно закрепить независимо друг от друга. В Linux можно закрепить патч-версию Tomcat. Патч-версия JVM также закреплена, но не настраивается отдельно.

Запуск интерфейса командной строки JBoss

В сеансе SSH приложения JBoss EAP можно запустить интерфейс командной строки JBoss с помощью следующей команды:

$JBOSS_HOME/bin/jboss-cli.sh --connect

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

Кроме того, изменения, внесенные на сервер с помощью интерфейса командной строки JBoss в сеансе SSH, не сохраняются после перезапуска приложения. При каждом запуске приложения сервер JBoss EAP начинается с чистой установки. Во время жизненного цикла запуска Служба приложений выполняет необходимые конфигурации сервера и развертывает приложение. Чтобы внести любые постоянные изменения на серверЕ JBoss EAP, используйте пользовательский скрипт запуска или команду запуска. Полный пример см. в разделе "Настройка источников данных" для приложения Java SE, Tomcat или JBoss EAP в службе приложений Azure.

Кроме того, можно вручную настроить Служба приложений для запуска любого файла при запуске. Например:

az webapp config set --resource-group <group-name> --name <app-name> --startup-file /home/site/scripts/foo.sh

Для получения дополнительной информации о командах CLI, которые вы можете выполнить, см. статью:

• Документация по Red Hat JBoss EAP
• Рецепты интерфейса командной строки WildFly

Кластеризация

Служба приложений поддерживает кластеризацию для JBoss EAP версии 7.4.1 и выше. Чтобы включить кластеризацию, веб-приложение должно быть интегрировано с виртуальной сетью. При интеграции веб-приложения с виртуальной сетью она перезапускается, а установка JBoss EAP автоматически запускается с кластеризованной конфигурацией. При запуске нескольких экземпляров с автомасштабированием экземпляры JBoss EAP взаимодействуют друг с другом по подсети, указанной в интеграции виртуальной сети. Кластеризацию можно отключить, создав параметр приложения с именем WEBSITE_DISABLE_CLUSTERING и с любым значением.

Если кластеризация включена, экземпляры JBoss EAP используют FILE_PING протокол обнаружения JGroups для обнаружения новых экземпляров и сохранения сведений о кластере (например, членов кластера, их идентификаторов и IP-адресов). В службе приложений эти файлы находятся в папке /home/clusterinfo/. Первый экземпляр EAP, который запускается, получает права на чтение и запись в файл членства кластера. Другие экземпляры считывают файл, находят основной узел и координируются с этим узлом, чтобы быть включенными в кластер и добавленными в файл.

Типы планов службы приложений уровня "Премиум" версии 3 и "Изолированный" версии 2 могут быть распределены по зонам доступности для повышения устойчивости и надежности рабочих нагрузок, критически важных для бизнеса. Эта архитектура также называется избыточностью между зонами. Функция кластеризации JBoss EAP совместима с функцией зональной избыточности.

Правила автомасштабирования

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

• Операция: "Уменьшить число на"
• Остывание: "5 минут" или больше.
• Число экземпляров: 1.

Вам не нужно добавочно добавлять экземпляры (масштабирование). Одновременно можно добавить несколько экземпляров в кластер.

Планы службы приложений

JBoss EAP доступен в следующих ценовых категориях: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3 и P5mv3.

Жизненный цикл сервера JBoss EAP

Приложение JBoss EAP в службе приложений проходит пять отдельных этапов перед запуском сервера:

1. Этап настройки среды
2. Этап запуска сервера
3. Этап настройки сервера
4. Этап развертывания приложений
5. Этап перезагрузки сервера

Дополнительные сведения и возможности настройки (например, с помощью параметров приложения) см. в следующих разделах.

1. Этап установки среды

• Служба SSH запускается для включения безопасных сеансов SSH с контейнером.
• Хранилище ключей среды выполнения Java обновляется с помощью всех общедоступных и частных сертификатов, определенных на портале Azure.
  • Общедоступные сертификаты предоставляются платформой в каталоге /var/ssl/certs и загружаются в $JRE_HOME/lib/security/cacerts.
  • Частные сертификаты предоставляются платформой в каталоге /var/ssl/private и загружаются в $JRE_HOME/lib/security/client.jks.
• Если все сертификаты загружаются в хранилище ключей Java на этом шаге, свойства javax.net.ssl.keyStorejavax.net.ssl.keyStorePasswordи javax.net.ssl.keyStoreType добавляются в JAVA_OPTS переменную среды.
• Определяется некоторая начальная конфигурация JVM, например каталоги ведения журнала и параметры кучи памяти Java:
  • Если вы предоставляете –Xms или –Xmx флаги для памяти в параметре JAVA_OPTSприложения, эти значения переопределяют те, которые предоставляются платформой.
  • При настройке параметра WEBSITES_CONTAINER_STOP_TIME_LIMITприложения значение передается свойству org.wildfly.sigterm.suspend.timeoutсреды выполнения, которое управляет максимальным временем ожидания завершения работы (в секундах) при остановке JBoss EAP.
• Если приложение интегрировано с виртуальной сетью, среда выполнения Службы приложений передает список портов, которые будут использоваться для взаимодействия между серверами в переменной WEBSITE_PRIVATE_PORTS среды и запускает JBoss EAP с помощью clustering конфигурации. В противном случае используется конфигурация standalone.
  • clustering Для конфигурации используется файл standalone-azure-full-ha.xml конфигурации сервера.
  • standalone Для конфигурации используется файл standalone-full.xml конфигурации сервера.

2. Этап запуска сервера

• Если JBoss EAP запускается в clustering конфигурации:
  • Каждому экземпляру JBoss EAP назначается внутренний идентификатор в диапазоне от 0 до количества экземпляров, на которые приложение масштабируется.
  • Если некоторые файлы находятся в пути хранилища транзакций для этого экземпляра сервера (с помощью внутреннего идентификатора), это означает, что экземпляр сервера занимает место идентичного экземпляра службы. Другой экземпляр службы ранее вышел из строя и оставил за собой незафиксированные транзакции. Сервер настроен для возобновления работы с этими транзакциями.
• Независимо от того, запускается ли JBoss EAP в clustering или standalone конфигурации, если сервер версии 7.4 или более поздней, а среда выполнения использует Java 17, конфигурация обновляется, чтобы включить подсистему Elytron для обеспечения безопасности.
• При настройке параметра WEBSITE_JBOSS_OPTSприложения значение передается в скрипт запуска JBoss. Этот параметр можно использовать для предоставления путей к файлам свойств и дополнительным флагам, влияющим на запуск JBoss EAP.

3. Этап настройки сервера

• В начале этого этапа служба приложений сначала ожидает, пока и сервер JBoss EAP, и интерфейс администрирования не будут готовы принять запросы, перед тем как продолжить. Этот процесс может занять несколько секунд, если Application Insights включен.

• Когда сервер JBoss EAP и интерфейс администрирования готовы, служба приложений выполняет следующие действия:

  • Добавляет модуль azure.appserviceJBoss EAP, который предоставляет служебные классы для ведения журнала и интеграции с службой приложений.
  • Обновляет средство ведения журнала консоли, чтобы оно работало в бесцветном режиме. Это предотвращает заполнение файлов журналов последовательностями экранирования цветов.
  • Настраивает интеграцию с журналами Azure Monitor.
  • Обновляет IP-адреса привязки языков описания веб-служб (WSDL) и интерфейсов управления.
  • Добавляет модуль azure.appservice.easyauth JBoss EAP для интеграции с проверкой подлинности службы приложений и идентификатором Microsoft Entra.
  • Обновляет конфигурацию журналов доступа, а также имя и ротацию файла логов основного сервера.

• Если параметр WEBSITE_SKIP_AUTOCONFIGURE_DATABASE приложения не определен, Служба приложений автоматически обнаруживает URL-адреса подключения к базе данных Java (JDBC) в параметрах приложения. Если допустимые URL-адреса JDBC существуют для PostgreSQL, MySQL, MariaDB, Oracle, SQL Server или Базы данных SQL Azure, он добавляет соответствующие драйверы на сервер, добавляет источник данных для каждого URL-адреса JDBC и задает имя интерфейса JNDI Java для каждого источника java:jboss/env/jdbc/<app-setting-name>_DSданных, где <app-setting-name> указано имя параметра приложения.

• Если конфигурация clustering включена, необходимо настроить и проверить ведение журнала консоли.

• Если в каталоге /home/site/libs находятся JAR-файлы, создается новый глобальный модуль, содержащий все эти JAR-файлы.

• В конце этапа Служба приложений запускает пользовательский скрипт запуска, если он существует. Логика поиска для пользовательского скрипта запуска определяется следующим образом:

  • Если вы настроили команду запуска (например, с помощью портала Azure или Azure CLI), выполните ее; иначе
  • Если путь /home/site/scripts/startup.sh существует, используйте его; в противном случае
  • Если путь /home/startup.sh существует, используйте его.

Пользовательская команда запуска или скрипт выполняются как корневой пользователь (не требуется sudo), чтобы они могли устанавливать пакеты Linux или запускать интерфейс командной строки JBoss для выполнения дополнительных команд установки и настройки JBoss EAP, таких как создание источников данных и установка адаптеров ресурсов. Сведения о командах управления пакетами Ubuntu см. в документации по Ubuntu Server. Сведения о командах интерфейса командной строки JBoss см. в руководстве по интерфейсу командной строки JBoss.

4. Этап развертывания приложений

Стартовый скрипт развертывает приложения в JBoss EAP, просматривая следующие расположения в порядке убывания приоритета.

• Если вы настроили параметр WEBSITE_JAVA_WAR_FILE_NAMEприложения, разверните файл, назначенный им.
• Если /home/site/wwwroot/app.war существует, разверните его.
• Если в /home/site/wwwroot существуют другие файлы EAR и WAR, разверните их.
• Если /home/site/wwwroot/webapps существует, разверните файлы и каталоги в этой директории. WAR-файлы развертываются как сами приложения, а каталоги развертываются как "взрывные" (несжатые) веб-приложения.
• Если какие-либо автономные страницы JSP существуют /home/site/wwwroot, скопируйте их в корневой каталог веб-сервера и разверните их как одно веб-приложение.
• Если развертываемые файлы не найдены, разверните страницу приветствия по умолчанию (страницу парковки) в корневом контексте.

5. Этап перезагрузки сервера

• После завершения действий развертывания сервер JBoss EAP перезагрузится, чтобы применить любые изменения, требующие перезагрузки сервера.
• После перезагрузки сервера приложения, развернутые на сервере JBoss EAP, должны быть готовы к реагированию на запросы.
• Сервер запускается до тех пор, пока приложение Служба приложений не будет остановлено или перезапущено. Вы можете вручную остановить или перезапустить приложение Служба приложений или запустить перезапуск при развертывании файлов или внести изменения конфигурации в приложение Служба приложений.
• Если сервер JBoss EAP завершает работу нештатно в clustering конфигурации, выполняется заключительная функция emit_alert_tx_store_not_empty. Функция проверяет, оставил ли процесс JBoss EAP файл хранилища транзакций с содержимым на диске. Если это так, в консоли регистрируется ошибка: Error: finishing server with non-empty store for node XXXX При запуске нового экземпляра сервера он ищет эти непустые файлы хранилища транзакций для возобновления работы (см. 2. Этап запуска сервера).

Базовая конфигурация Tomcat

Разработчики Java могут настраивать параметры сервера, устранять проблемы и развертывать приложения в Tomcat с уверенностью, если они знают о файле server.xml и конфигурации Tomcat. Возможные настройки:

• Настройка конфигурации Tomcat: когда вы понимаете файл server.xml и сведения о конфигурации Tomcat, можно точно настроить параметры сервера в соответствии с потребностями своих приложений.
• Отладка. При развертывании приложения на сервере Tomcat разработчики должны знать конфигурацию сервера для отладки любых проблем, которые могут возникнуть. Этот процесс включает проверку журналов сервера, изучение файлов конфигурации и выявление ошибок, которые могут возникнуть.
• Устранение неполадок Tomcat: неизбежно разработчики Java сталкиваются с проблемами с сервером Tomcat, такими как проблемы с производительностью или ошибки конфигурации. Когда вы понимаете файл server.xml и сведения о конфигурации Tomcat, разработчики могут быстро диагностировать и устранять эти проблемы, что может сэкономить время и усилия.
• Развертывание приложений в Tomcat. Чтобы развернуть веб-приложение Java в Tomcat, разработчикам необходимо знать, как настроить файл server.xml и другие параметры Tomcat. Эти сведения необходимо понять для успешного развертывания приложений и обеспечить их плавное выполнение на сервере.

При создании приложения со встроенным Tomcat для размещения Java-нагрузки (WAR-файла или JAR-файла) существуют определенные параметры, которые вы получаете по умолчанию для конфигурации Tomcat. Вы можете ознакомиться с официальной документацией Apache Tomcat для получения детальной информации, включая конфигурацию по умолчанию для веб-сервера Tomcat.

Кроме того, существуют некоторые преобразования, применяемые поверх server.xml распределения Tomcat при запуске. Эти преобразования включают изменения параметров соединителя, узла и клапана .

Последние версии Tomcat имеют server.xml (8.5.58 и 9.0.38 далее). Старые версии Tomcat не используют преобразования и могут иметь другое поведение в результате.

Соединитель

<Connector port="${port.http}" address="127.0.0.1" maxHttpHeaderSize="16384" compression="on" URIEncoding="UTF-8" connectionTimeout="${site.connectionTimeout}" maxThreads="${catalina.maxThreads}" maxConnections="${catalina.maxConnections}" protocol="HTTP/1.1" redirectPort="8443"/>

• maxHttpHeaderSize задан как 16384.
• URIEncoding задан как UTF-8.
• connectionTimeout установлено на WEBSITE_TOMCAT_CONNECTION_TIMEOUT, которое по умолчанию 240000.
• maxThreads установлено на WEBSITE_CATALINA_MAXTHREADS, которое по умолчанию равно 200.
• maxConnections имеет значение WEBSITE_CATALINA_MAXCONNECTIONS, которое по умолчанию равно 10000.

Ниже приведены примеры команд CLI, которые можно использовать для изменения значений connectionTimeout, maxThreadsили maxConnections:

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXCONNECTIONS=5000

Соединитель использует адрес контейнера вместо 127.0.0.1.

Хост

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">

• appBase имеет значение AZURE_SITE_APP_BASE, для которого по умолчанию задано значение local WebappsLocalPath.
• xmlBase устанавливается в AZURE_SITE_HOME, которое по умолчанию равно /site/wwwroot.
• unpackWARs устанавливается на AZURE_UNPACK_WARS, по умолчанию равное true.
• workDir установлено в JAVA_TMP_DIR, что по умолчанию задается для TMP.
• errorReportValveClass использует наш настраиваемый клапан фиксации ошибок.

Клапан

<Valve prefix="site_access_log.${catalina.instance.name}" pattern="%h %l %u %t &quot;%r&quot; %s %b %D %{x-arr-log-id}i" directory="${site.logdir}/http/RawLogs" maxDays="${site.logRetentionDays}" className="org.apache.catalina.valves.AccessLogValve" suffix=".txt"/>

• directory равен AZURE_LOGGING_DIR, которое по умолчанию равно home\logFiles.
• maxDays имеет значение WEBSITE_HTTPLOGGING_RETENTION_DAYS, которое по умолчанию устанавливается на 7. Это значение соответствует платформе ведения журнала приложений по умолчанию.

В Linux она имеет одну и ту же настройку, а также добавляет некоторые страницы отчетов и ошибок в клапан:

<xsl:attribute name="appServiceErrorPage">
    <xsl:value-of select="'${appService.valves.appServiceErrorPage}'"/>
</xsl:attribute>

<xsl:attribute name="showReport">
    <xsl:value-of select="'${catalina.valves.showReport}'"/>
</xsl:attribute>

<xsl:attribute name="showServerInfo">
    <xsl:value-of select="'${catalina.valves.showServerInfo}'"/>
</xsl:attribute>