Azure App Service에서 Java SE, Tomcat 또는 JBoss EAP 앱 배포 및 구성

이 문서에서는 Azure App Service에서 Java 앱에 대한 가장 일반적인 배포 및 런타임 구성을 보여줍니다. Azure App Service를 처음 사용하는 경우 먼저 Java 빠른 시작을 읽어야 합니다. App Service FAQ에서 Java 개발과 관련이 없는 App Service 사용에 대한 일반적인 질문에 대한 답변을 찾을 수 있습니다.

Azure App Service는 세 가지 변형으로 완전 관리형 서비스에서 Java 웹 애플리케이션을 실행합니다.

• SE(Java Standard Edition): 포함된 서버(예: Spring Boot, Quarkus, Dropwizard 또는 포함된 Tomcat 또는 Jetty 서버가 있는 앱)가 포함된 JAR(Java Archive) 패키지로 배포된 앱을 실행할 수 있습니다.
• Tomcat: 기본 제공 Tomcat 서버는 WAR(웹 애플리케이션 보관) 패키지로 배포된 앱을 실행할 수 있습니다.
• JBoss EAP(엔터프라이즈 애플리케이션 플랫폼): 기본 제공 JBoss EAP 서버는 WAR 또는 EAR(엔터프라이즈 보관) 패키지로 배포된 앱을 실행할 수 있습니다. 무료, Premium v3 및 Isolated v2.gti를 포함하는 가격 책정 계층 집합에서 Linux 앱에 대해 지원됩니다.

Java 버전 표시

리눅스

현재 Java 버전을 표시하려면 Azure Cloud Shell에서 다음 명령을 실행합니다.

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

지원되는 모든 Java 버전을 표시하려면 Cloud Shell에서 다음 명령을 실행합니다.

az webapp list-runtimes --os linux | grep "JAVA\|TOMCAT\|JBOSSEAP"

Linux 컨테이너에서 Java 버전 가져오기

Linux 컨테이너의 자세한 버전 정보를 보려면 컨테이너를 사용하여 SSH 세션을 엽니다. 다음은 실행할 수 있는 항목의 몇 가지 예입니다.

SSH 세션에서 Java 버전을 보려면 다음을 수행합니다.

java -version

SSH 세션에서 Tomcat 서버 버전을 보려면 다음을 수행합니다.

sh /usr/local/tomcat/version.sh

또는 Tomcat 서버가 사용자 지정 위치에 있는 경우 다음을 사용하여 version.sh를 찾습니다.

find / -name "version.sh"

SSH 세션에서 JBoss EAP 서버 버전을 보려면 다음을 수행합니다.

$JBOSS_HOME/bin/jboss-cli.sh --connect --commands=:product-info

Windows

현재 Java 버전을 표시하려면 Azure Cloud Shell에서 다음 명령을 실행합니다.

az webapp config show --name <app-name> --resource-group <resource-group-name> --query "[javaVersion, javaContainer, javaContainerVersion]"

지원되는 모든 Java 버전을 표시하려면 Cloud Shell에서 다음 명령을 실행합니다.

az webapp list-runtimes --os windows | grep java

버전 지원에 대한 자세한 내용은 App Service 언어 런타임 지원 정책을 참조하세요.

App Service에서 오래된 런타임은 어떻게 되나요?

오래된 런타임은 유지 관리 조직에서 더 이상 사용되지 않거나 심각한 취약성이 있는 것으로 확인됩니다. 따라서 포털의 만들기 및 구성 페이지에서 제거됩니다. 오래된 런타임이 포털에서 숨겨지면 해당 런타임을 계속 사용하는 모든 앱이 계속 실행됩니다.

더 이상 포털에 표시되지 않는 오래된 런타임 버전으로 앱을 만들려면 Azure CLI, ARM 템플릿 또는 Bicep을 사용합니다. 이러한 배포 대안을 사용하면 포털에서 제거되었지만 여전히 지원되는 사용되지 않는 런타임을 만들 수 있습니다.

런타임이 App Service 플랫폼에서 완전히 제거된 경우 Azure 구독 소유자는 제거 전에 이메일 알림을 받습니다.

앱 배포

빌드 도구

메이븐

Azure Web Apps용 Maven 플러그 인을 사용하면 프로젝트 루트에서 하나의 명령으로 프로젝트를 쉽게 준비할 수 있습니다.

mvn com.microsoft.azure:azure-webapp-maven-plugin:2.13.0:config

이 명령은 기존 Azure Web App을 선택하거나 새 웹앱을 만들라는 메시지를 표시하여 플러그 인 및 관련 구성을 추가 azure-webapp-maven-plugin 합니다. 구성 중에 애플리케이션을 Java SE, Tomcat 또는 (Linux 전용) JBoss EAP에 배포해야 하는지 여부를 감지하려고 시도합니다. 그런 다음, 다음 명령을 사용하여 Java 앱을 Azure에 배포할 수 있습니다.

mvn package azure-webapp:deploy

다음은 pom.xml의 샘플 구성입니다.

<plugin> 
  <groupId>com.microsoft.azure</groupId>  
  <artifactId>azure-webapp-maven-plugin</artifactId>  
  <version>2.11.0</version>  
  <configuration>
    <subscriptionId>111111-11111-11111-1111111</subscriptionId>
    <resourceGroup>spring-boot-xxxxxxxxxx-rg</resourceGroup>
    <appName>spring-boot-xxxxxxxxxx</appName>
    <pricingTier>B2</pricingTier>
    <region>westus</region>
    <runtime>
      <os>Linux</os>      
      <webContainer>Java SE</webContainer>
      <javaVersion>Java 17</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin> 

Gradle

1. Azure Web Apps용 Gradle 플러그인을 build.gradle에 추가하여 설정합니다.

   plugins {
     id "com.microsoft.azure.azurewebapp" version "1.10.0"
   }
   

2. 웹앱 세부 정보를 구성합니다. 해당 Azure 리소스가 없으면 만들어집니다. 샘플 구성은 다음과 같습니다. 자세한 내용은 이 문서를 참조하세요.

   azurewebapp {
       subscription = '<your subscription id>'
       resourceGroup = '<your resource group>'
       appName = '<your app name>'
       pricingTier = '<price tier like 'P1v2'>'
       region = '<region like 'westus'>'
       runtime {
         os = 'Linux'
         webContainer = 'Tomcat 10.0' // or 'Java SE' if you want to run an executable jar
         javaVersion = 'Java 17'
       }
       appSettings {
           <key> = <value>
       }
       auth {
           type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
       }
   }
   

3. 하나의 명령으로 배포합니다.

   gradle azureWebAppDeploy
   

IDE

Azure는 다음을 포함하여 인기 있는 Java IDE(통합 개발 환경)에서 원활한 Java App Service 개발 환경을 제공합니다.

• VS Code: Visual Studio Code를 사용하는 Java Web Apps.
• IntelliJ IDEA: IntelliJ를 사용하여 Azure App Service용 Hello World 웹앱을 만듭니다.
• Eclipse IDE: Eclipse를 사용하여 Azure App Service용 Hello World 웹앱을 만듭니다.

Kudu 및 OneDeploy API

Maven 플러그인, azure/webapps-deploy@v3 이상 버전의 GitHub Actions 또는 az webapp deploy 명령과 같은 배포 클라이언트는 Kudu 사이트의 /api/publish 엔드포인트를 호출하여 작동하는 OneDeploy를 사용합니다. 이 API에 대한 자세한 내용은 이 설명서를 참조하세요.

이러한 배포 방법을 사용하면 배포 프로세스 중에 제공된 JAR 파일 app.jar 의 이름을 자동으로 바꿉니다. 이 작업은 /home/site/wwwwroot 아래에 배치됩니다. Java SE에 JAR 파일을 배포하려면 이 설명서를 참조하세요.

참고

FTP 또는 이전 ZipDeploy API와 같은 대체 메서드를 사용하는 경우 제공된 JAR 파일의 이름을 바꾸는 이 메서드는 호출되지 않습니다. 포털의 구성 섹션에서 시작 파일 텍스트 상자를 사용하여 JAR 파일을 명시적으로 호출하는 경우 이를 기록해 둡니다.

이 설명서에 따라 Tomcat 애플리케이션에 WAR 파일을 배포할 수 있습니다. 위의 배포 방법을 사용하면 배포 프로세스 중에 제공된 War 파일 app.war 의 이름을 자동으로 바꿉니다. 이 파일은 아래에 /home/site/wwwwroot 배치되며 기본적으로는 아래에 하나의 WAR 파일 wwwroot만 배포할 수 있습니다. WarDeploy와 같은 배포 API를 사용할 때처럼 디렉터리 아래에 배치/home/site/wwwroot/webapps. 파일 구조 충돌과 관련된 문제를 방지하려면 하나 또는 다른 배포 유형만 사용하는 것이 좋습니다.

JBoss EAP에 WAR 파일을 배포하려면 이 설명서를 참조하세요. OneDeploy를 사용할 경우, WAR 파일의 이름이 app.war로 자동 변경되어 /home/site/wwwroot에 위치하게 됩니다.

EAR 파일을 배포하려면 FTP를 사용합니다. EAR 애플리케이션은 애플리케이션의 구성에 정의된 컨텍스트 루트에 배포됩니다. 웹앱을 루트 경로에 제공하려면 앱이 컨텍스트 루트를 루트 경로로 설정했는지 확인합니다. <context-root>/</context-root> 자세한 정보는 웹 애플리케이션의 컨텍스트 루트 설정을 참조하세요.

FTP를 사용하여 WAR 또는 JAR을 배포하지 마세요. FTP 도구는 시작 스크립트, 종속성 또는 기타 런타임 파일을 업로드하기 위해 설계되었습니다. 웹앱을 배포하기 위한 최적의 선택은 아닙니다.

URL 다시 쓰기 또는 리디렉션

URL을 다시 작성하거나 리디렉션하려면 UrlRewriteFilter와 같은 사용 가능한 URL 재작성기 중 하나를 사용합니다.

Tomcat은 또한 다시 쓰기 밸브를 제공합니다.

JBoss EAP는 재작성 밸브도 제공합니다.

앱 로깅 및 디버깅

Azure Portal을 통해 각 앱에 대한 성능 보고서, 트래픽 시각화 및 상태 확인을 사용할 수 있습니다. 자세한 내용은 Azure App Service 진단 개요를 참조하세요.

진단 로그를 스트리밍하기

리눅스

컨테이너 내부에서 생성된 콘솔 로그에 액세스할 수 있습니다.

컨테이너 로깅을 켜려면 다음 명령을 실행합니다.

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

<app-name>과 <resource-group-name>을 웹앱에 적절한 이름으로 바꿉니다.

컨테이너 로깅을 켠 후 다음 명령을 실행하여 로그 스트림을 확인합니다.

az webapp log tail --name <app-name> --resource-group <resource-group-name>

콘솔 로그가 즉시 나타나지 않으면 30초 후에 다시 확인합니다.

언제든지 로그 스트리밍을 중지하려면 Ctrl+를 선택합니다.

Windows

App Service의 애플리케이션 코드 내에서 생성된 콘솔 로그에 액세스하려면 Cloud Shell에서 다음 명령을 실행하여 진단 로깅을 설정합니다.

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

가능한 값 --level 은 Error, Warning, Info및 Verbose. 각 후속 수준에는 이전 수준이 포함됩니다. 예를 들어 Error 오류 메시지만 포함합니다. Verbose 에는 모든 메시지가 포함됩니다.

진단 로깅을 켠 후 다음 명령을 실행하여 로그 스트림을 확인합니다.

az webapp log tail --resource-group <resource-group-name> --name <app-name>

콘솔 로그가 즉시 나타나지 않으면 30초 후에 다시 확인합니다.

언제든지 로그 스트리밍을 중지하려면 Ctrl+를 선택합니다.

자세한 내용은 Cloud Shell에서 로그 스트리밍을 참조하세요.

Linux의 SSH 콘솔 액세스

컨테이너를 사용하여 직접 SSH 세션을 열려면 앱이 실행 중이어야 합니다.

az webapp ssh 명령을 사용합니다.

아직 인증을 받지 못한 경우 연결하기 위해서는 Azure 구독에서 인증을 받아야 합니다. 인증되면 컨테이너 내부에서 명령을 실행할 수 있는 브라우저 내부 셸을 확인합니다.

참고

디렉터리 외부에서 /home 변경한 내용은 컨테이너 자체에 저장되며 앱 다시 시작 후에도 유지되지 않습니다.

로컬 컴퓨터에서 원격 SSH 세션을 열려면 원격 셸에서 SSH 세션 열기를 참조하세요.

Linux 문제 해결 도구

기본 제공 Java 이미지는 Alpine Linux 운영 체제를 기반으로 합니다. apk 패키지 관리자를 사용하여 문제 해결 도구 또는 명령을 설치합니다.

Java 프로파일러

Azure App Service의 모든 Java 런타임에는 Java 워크로드를 프로파일링하기 위한 JDK(Java Development Kit) 플라이트 레코더가 함께 제공됩니다. 이를 사용하여 JVM(Java Virtual Machine), 시스템 및 애플리케이션 이벤트를 기록하고 애플리케이션의 문제를 해결할 수 있습니다.

Java 프로파일러에 대한 자세한 내용은 Azure Application Insights 설명서를 참조하세요.

Java 플라이트 레코더

App Service의 모든 Java 런타임은 Java Flight Recorder와 함께 제공됩니다. JVM, 시스템 및 애플리케이션 이벤트를 기록하고 Java 애플리케이션의 문제를 해결하는 데 사용할 수 있습니다.

리눅스

App Service에 SSH하고 명령을 실행 jcmd 하여 실행 중인 모든 Java 프로세스의 목록을 확인합니다. jcmd 자체 외에도 PID(프로세스 ID) 번호로 실행되는 Java 애플리케이션이 표시되어야 합니다.

078990bbcd11:/home# jcmd
Picked up JAVA_TOOL_OPTIONS: -Djava.net.preferIPv4Stack=true
147 sun.tools.jcmd.JCmd
116 /home/site/wwwroot/app.jar

다음 명령을 실행하여 JVM의 30초 기록을 시작합니다. JVM을 프로파일하고 홈 디렉터리에 이름이 지정된 jfr_example.jfr JFR(Java Flight Recorder) 파일을 만듭니다. 116을 Java 앱의 PID로 바꿉니다.

jcmd 116 JFR.start name=MyRecording settings=profile duration=30s filename="/home/jfr_example.jfr"

30초 간격 동안 jcmd 116 JFR.check을(를) 실행하여 기록이 발생하는지 확인할 수 있습니다. 이 명령은 지정된 Java 프로세스에 대한 모든 기록을 표시합니다.

연속 기록

Java Flight Recorder를 사용하여 런타임 성능에 대한 영향을 최소화하면서 Java 애플리케이션을 지속적으로 프로파일링할 수 있습니다. 이렇게 하려면 다음 Azure CLI 명령을 실행하여 필요한 구성으로 명명된 JAVA_OPTS 앱 설정을 만듭니다. 앱이 시작되면 JAVA_OPTS 앱 설정의 콘텐츠가 java 명령으로 전달됩니다.

az webapp config appsettings set -g <your_resource_group> -n <your_app_name> --settings JAVA_OPTS=-XX:StartFlightRecording=disk=true,name=continuous_recording,dumponexit=true,maxsize=1024m,maxage=1d

녹음이 시작된 후에는 명령을 사용하여 언제든지 현재 기록 데이터를 덤프할 JFR.dump 수 있습니다.

jcmd <pid> JFR.dump name=continuous_recording filename="/home/recording1.jfr"

Windows

시간 기록

시간 제한 기록을 수행하려면 Java 애플리케이션의 PID(프로세스 ID)가 필요합니다. PID를 찾으려면 Azure Portal에서 서비스를 엽니다. 개발 도구> 선택한 다음, 이동을 선택합니다. Kudu에서 프로세스 탐색기를 선택합니다. 이 페이지는 웹앱에서 실행 중인 프로세스를 표시합니다. 테이블에서 "java"라는 프로세스를 찾아 해당 PID를 복사합니다.

다음으로, SCM 사이트의 상단 도구 모음에서 디버그 콘솔을 열고 다음 명령을 실행합니다. <pid>를 이전에 복사한 PID로 바꾸세요. 이 명령은 Java 애플리케이션의 30초 프로파일러 기록을 시작하고 timed_recording_example.jfr 디렉터리에 C:\home이라는 파일을 생성합니다.

jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s filename="C:\home\timed_recording_example.JFR"

JFR 파일 분석

FTPS를 사용하여 JFR 파일을 로컬 컴퓨터에 다운로드합니다. JFR 파일을 분석하려면 JMC(Java Mission Control)를 다운로드하여 설치합니다. Java Mission Control을 사용하는 방법에 대한 지침은 JMC 설명서 및 설치 지침을 참조하세요.

앱 로깅

리눅스

애플리케이션의 표준 콘솔 출력 및 표준 콘솔 오류 스트림을 로컬 파일 시스템 또는 Azure Blob Storage에 쓰도록 App Service를 구성하려면 다음을 수행합니다. Azure Portal 또는 Azure CLI를 통해 애플리케이션 로깅을 사용하도록 설정합니다. 더 긴 보존이 필요한 경우 Blob Storage 컨테이너에 출력을 쓰도록 애플리케이션을 구성합니다.

Java 및 Tomcat 앱 로그는 디렉터리에서 /home/LogFiles/Application/ 찾을 수 있습니다.

Linux 기반 앱에 대한 Azure Blob Storage 로깅은 Azure Monitor를 사용해야만 구성할 수 있습니다.

Windows

애플리케이션의 표준 콘솔 출력 및 표준 콘솔 오류 스트림을 로컬 파일 시스템 또는 Azure Blob Storage에 쓰도록 App Service를 구성하려면 다음을 수행합니다. Azure Portal 또는 Azure CLI를 통해 애플리케이션 로깅을 사용하도록 설정합니다. 애플리케이션 로깅을 사용하도록 설정한 후 12시간 후에 로컬 App Service 파일 시스템 인스턴스에 대한 로깅을 사용할 수 없습니다. 더 긴 보존이 필요한 경우 Blob Storage 컨테이너에 출력을 쓰도록 애플리케이션을 구성합니다.

Java 및 Tomcat 앱 로그는 디렉터리에서 /home/LogFiles/Application/ 찾을 수 있습니다.

애플리케이션이 추적에 Logback 또는 Log4j 를 사용하는 경우 검토를 위해 이러한 추적을 Azure Application Insights로 전달할 수 있습니다. Application Insights에서 Java 추적 로그 탐색의 로깅 프레임워크 구성 지침을 사용합니다.

참고

알려진 취약성 CVE-2021-44228으로 인해 Log4j 버전 2.16 이상을 사용해야 합니다.

사용자 지정 및 튜닝

Azure App Service는 Azure Portal 및 Azure CLI를 통해 기본 제공 튜닝 및 사용자 지정을 지원합니다. 비 Java 관련 웹앱 구성에 대한 다음 문서를 검토하세요.

• 앱 설정 구성
• 사용자 지정 도메인 설정
• TLS/SSL 바인딩 구성
• CDN 추가
• Kudu 사이트 구성

로컬로 앱 콘텐츠 복사

앱 설정 JAVA_COPY_ALL을 true로 설정하여 앱 콘텐츠를 공유 파일 시스템에서 로컬 작업자로 복사합니다. 이 설정은 파일 잠금 문제를 해결하는 데 도움이 됩니다.

Java 런타임 옵션 설정

할당된 메모리 또는 기타 JVM 런타임 옵션을 설정하려면 라는 JAVA_OPTS을 옵션과 함께 만듭니다. App Service는 시작될 때 이 설정을 Java 런타임에 환경 변수로 전달합니다.

Azure Portal에서, 웹앱의 애플리케이션 설정 아래에서 JAVA_OPTS처럼 다른 설정을 포함하는 -Xms512m -Xmx1204m라고 하는 새 앱 설정을 만듭니다.

Azure Portal에서, 웹앱의 애플리케이션 설정 아래에서 CATALINA_OPTS처럼 다른 설정을 포함하는 -Xms512m -Xmx1204m라고 하는 새 앱 설정을 만듭니다.

Maven 플러그 인에서 앱 설정을 구성하려면 Azure 플러그 인 섹션에서 설정/값 태그를 추가합니다. 다음 예에서는 특정 최소 및 최대 Java 힙 크기를 설정합니다.

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Xms1024m -Xmx1024m</value>
    </property>
</appSettings>

참고

Windows App Service에서 Tomcat을 사용하는 경우 web.config 파일을 만들 필요가 없습니다.

기본적으로 App Service는 JVM 최대 힙 크기를 App Service 계획에 사용할 수 있는 총 메모리의% 70으로 설정합니다. 기본 설정을 사용하지 않도록 설정하려면 앱 설정 WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true"를 사용할 수 있습니다.

플랫폼에서 애플리케이션의 성능을 향상시키려면 특정 요구 사항에 맞게 힙 크기를 조정해야 할 수 있습니다. 애플리케이션 힙 설정을 튜닝할 때 App Service 계획 세부 정보를 검토하고 여러 애플리케이션 및 배포 슬롯의 요구 사항을 고려하여 최적의 메모리 할당을 찾습니다.

웹 소켓 켜기

Azure Portal의 애플리케이션 설정에서 웹 소켓 지원을 켭니다. 설정을 적용하려면 애플리케이션을 다시 시작해야 합니다.

다음 명령으로 Azure CLI를 사용하여 웹 소켓 지원을 켭니다.

az webapp config set --name <app-name> --resource-group <resource-group-name> --web-sockets-enabled true

그런 다음, 애플리케이션을 다시 시작합니다.

az webapp stop --name <app-name> --resource-group <resource-group-name>
az webapp start --name <app-name> --resource-group <resource-group-name>

기본 문자 인코딩 설정

Azure Portal에서, 웹앱의 애플리케이션 설정 아래에 JAVA_OPTS 값을 사용하여 -Dfile.encoding=UTF-8이라고 하는 새 앱 설정을 만듭니다.

또는 App Service Maven 플러그 인을 사용하여 앱 설정을 구성할 수 있습니다. 플러그 인 구성에서 설정 이름 및 값 태그를 추가합니다.

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Dfile.encoding=UTF-8</value>
    </property>
</appSettings>

JSP 파일 미리 컴파일

Tomcat 애플리케이션의 성능을 향상시키기 위해 App Service에 배포하기 전에 JSP 파일을 컴파일할 수 있습니다. Apache Sling에서 제공하는 Maven 플러그 인 을 사용하거나 이 Ant 빌드 파일을 사용할 수 있습니다.

로그에서 robots933456 메시지 무시

컨테이너 로그에 다음 메시지가 표시될 수 있습니다.

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

이 메시지는 무시해도 괜찮습니다. /robots933456.txt는 App Service에서 컨테이너가 요청을 처리할 수 있는지 확인하기 위해 사용하는 더미 URL 경로입니다. 404 응답은 경로가 존재하지 않음을 나타내며, 컨테이너가 정상이며 요청에 응답할 준비가 되었음을 App Service에 알릴 수 있습니다.

Java 런타임 버전 선택

App Service를 사용하면 사용자가 Java 8 또는 Java 11과 같은 JVM의 주 버전과 패치 버전(예: 1.8.0_232 또는 11.0.5)을 선택할 수 있습니다. 새 부 버전을 사용할 수 있게 되면 패치 버전이 자동으로 업데이트되도록 선택할 수도 있습니다. 대부분의 경우 프로덕션 앱은 패치 버전 자동 업데이트 중에 예기치 않은 중단을 방지하는 고정된 패치 JVM 버전을 사용해야 합니다. 모든 Java 웹앱은 64비트 JVM을 사용하며 구성할 수 없습니다.

Tomcat을 사용하는 경우 Tomcat의 패치 버전을 고정하도록 선택할 수 있습니다. Windows에서 JVM 및 Tomcat의 패치 버전을 독립적으로 고정할 수 있습니다. Linux에서 Tomcat의 패치 버전을 고정할 수 있습니다. JVM의 패치 버전도 고정되어 있지만 별도로 구성할 수는 없습니다.

부 버전을 고정하기로 선택한 경우 앱에서 JVM 부 버전을 주기적으로 업데이트해야 합니다. 최신 부 버전에서 애플리케이션을 실행하려면 스테이징 슬롯을 만들고 스테이징 슬롯에서 부 버전을 증가시킵니다. 애플리케이션이 새 부 버전에서 올바르게 실행되는지 확인한 후 스테이징 및 프로덕션 슬롯을 교환할 수 있습니다.

JBoss CLI 실행

JBoss EAP 앱의 SSH 세션에서 다음 명령을 사용하여 JBoss CLI를 실행할 수 있습니다.

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

JBoss EAP가 서버 수명 주기에 있는 위치에 따라 연결할 수 없습니다. 잠시 기다린 다음 다시 시도하십시오. 이 방법은 현재 서버 상태를 빠르게 확인하는 데 유용합니다(예: 데이터 원본이 제대로 구성되었는지 확인).

또한 SSH 세션에서 JBoss CLI를 사용하여 서버에 적용한 변경 내용은 앱이 다시 시작되면 유지되지 않습니다. 앱이 시작될 때마다 JBoss EAP 서버가 새로 설치되기 시작합니다. 시작 주기 동안 앱 서비스는 필요한 서버 구성을 만들고 앱을 배포합니다. JBoss EAP 서버에서 영구적으로 변경하려면 사용자 지정 시작 스크립트 또는 시작 명령을 사용합니다. 엔드 투 엔드 예제는 Azure App Service에서 Java SE, Tomcat 또는 JBoss EAP 앱에 대한 데이터 원본 구성을 참조하세요.

또는 시작 시 모든 파일을 실행하도록 App Service를 수동으로 구성할 수 있습니다. 예시:

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

실행할 수 있는 CLI 명령에 대한 자세한 내용은 다음을 참조하세요.

• Red Hat JBoss EAP 설명서
• WildFly CLI 레시피

클러스터링

App Service는 JBoss EAP 버전 7.4.1 이상에 대한 클러스터링을 지원합니다. 클러스터링을 사용하도록 설정하려면 웹앱을 가상 네트워크와 통합해야 합니다. 웹앱이 가상 네트워크와 통합되면 다시 시작되고 JBoss EAP 설치가 클러스터링된 구성으로 자동으로 시작됩니다. 자동 크기 조정을 사용하여 여러 인스턴스를 실행하는 경우 JBoss EAP 인스턴스는 가상 네트워크 통합에 지정된 서브넷을 통해 서로 통신합니다. 모든 값으로 WEBSITE_DISABLE_CLUSTERING(으)로 명명된 앱 설정을 만들어 클러스터링을 사용하지 않도록 설정할 수 있습니다.

참고

ARM 템플릿과 가상 네트워크 통합을 사용하도록 설정하는 경우 vnetPrivatePorts 속성을 수동으로 값 2로 설정해야 합니다. CLI 또는 포털에서 가상 네트워크 통합을 사용하도록 설정하면 이 속성이 자동으로 설정됩니다.

클러스터링을 사용하도록 설정하면 JBoss EAP 인스턴스는 JGroups 검색 프로토콜을 사용하여 FILE_PING 새 인스턴스를 검색하고 클러스터 정보(예: 클러스터 멤버, 식별자 및 해당 IP 주소)를 유지합니다. App Service에서 이러한 파일은 /home/clusterinfo/ 아래에 있습니다. 시작되는 첫 번째 EAP 인스턴스는 클러스터 멤버 자격 파일에 대한 읽기/쓰기 권한을 가져옵니다. 다른 인스턴스는 파일을 읽고, 주 노드를 찾고, 클러스터에 포함되고 파일에 추가될 해당 노드와 조정합니다.

참고

앱 시작 중에 사용되지 않는 검색 파일을 정리하여 JBoss EAP 클러스터링 시간 제한을 방지할 수 있습니다.

프리미엄 V3, 프리미엄 V4 및 격리된 V2 App Service 계획 유형은 필요에 따라 가용성 영역에 분산되어 중요 비즈니스용 워크로드의 복원력과 안정성을 향상시킬 수 있습니다. 이 아키텍처를 영역 중복이라고도 합니다. JBoss EAP 클러스터링 기능은 영역 중복 기능과 호환됩니다.

자동 크기 조정 규칙

수평 크기 조정을 위해 자동 크기 조정 규칙을 구성하는 경우 제거된 각 인스턴스가 해당 작업(예: 데이터베이스 트랜잭션 처리)을 클러스터의 다른 멤버로 전송할 수 있도록 인스턴스를 한 번에 하나씩 제거하는 것이 중요합니다. 규모를 축소하도록 포털에서 자동 크기 조정 규칙을 구성하는 경우 다음 옵션을 사용합니다.

• 작업: "다음을 기준으로 개수 줄이기"
• 휴지 기간: "5분" 이상
• 인스턴스 수: 1

인스턴스를 증분 방식으로 추가할 필요가 없습니다(스케일 아웃). 클러스터에 한 번에 여러 인스턴스를 추가할 수 있습니다.

App Service 계획

JBoss EAP는 다음의 가격 책정 계층에서 사용할 수 있습니다: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4, 및 P5mv4.

JBoss EAP 서버 수명 주기

App Service의 JBoss EAP 앱은 서버를 시작하기 전에 5가지 개별 단계를 수행합니다.

1. 환경 설정 단계
2. 서버 시작 단계
3. 서버 구성 단계
4. 앱 배포 단계
5. 서버 다시 로드 단계

세부 정보 및 사용자 지정 기회(예: 앱 설정을 통해)는 다음 섹션을 참조하세요.

1. 환경 설정 단계

• SSH 서비스는 컨테이너에서 보안 SSH 세션을 사용하도록 설정 하기 시작합니다 .
• Java 런타임 키 저장소는 Azure Portal에 정의된 모든 퍼블릭 및 프라이빗 인증서로 업데이트됩니다.
  • 퍼블릭 인증서는 플랫폼의 /var/ssl/certs 디렉터리에 제공되고, $JRE_HOME/lib/security/cacerts로 로드됩니다.
  • 프라이빗 인증서는 플랫폼에 의해 제공되며 /var/ssl/private 디렉토리에 있으며, $JRE_HOME/lib/security/client.jks으로 로드됩니다.
• 만약 이 단계에서 인증서가 Java 키 저장소에 로드된다면, 속성 javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword, javax.net.ssl.keyStoreType이 JAVA_OPTS 환경 변수에 추가됩니다.
• 로깅 디렉터리 및 Java 메모리 힙 매개 변수와 같은 일부 초기 JVM 구성이 결정됩니다.
  • 앱 설정에서 –Xms 또는 –Xmx 플래그를 메모리 설정으로 제공하는 경우, 이러한 값은 플랫폼에서 제공하는 값을 재정의합니다.
  • 앱 설정을 WEBSITES_CONTAINER_STOP_TIME_LIMIT구성하면 값이 런타임 속성으로 전달됩니다. 이 속성 org.wildfly.sigterm.suspend.timeout은 JBoss EAP가 중지될 때 최대 종료 대기 시간(초)을 제어합니다.
• 앱이 가상 네트워크와 통합된 경우 App Service 런타임은 환경 변수 WEBSITE_PRIVATE_PORTS 에서 서버 간 통신에 사용할 포트 목록을 전달하고 구성을 사용하여 JBoss EAP를 clustering 시작합니다. 구성이 그렇지 않으면 standalone 사용됩니다.
  • 구성의 clustering 경우 서버 구성 파일이 standalone-azure-full-ha.xml 사용됩니다.
  • 구성의 standalone 경우 서버 구성 파일이 standalone-full.xml 사용됩니다.

2. 서버 시작 단계

• clustering 구성에서 JBoss EAP가 시작된 경우:
  • 각 JBoss EAP 인스턴스는 0과 앱이 확장되는 인스턴스 수 사이의 내부 식별자를 받습니다.
  • 내부 식별자를 사용하여 이 서버 인스턴스의 트랜잭션 저장소 경로에 일부 파일이 있는 경우 이 서버 인스턴스가 동일한 서비스 인스턴스를 대신하고 있음을 의미합니다. 다른 서비스 인스턴스가 이전에 충돌하여 커밋되지 않은 트랜잭션을 남겼습니다. 서버는 이러한 트랜잭션에 대한 작업을 다시 시작하도록 구성됩니다.
• JBoss EAP가 구성에서 clusteringstandalone 시작되는지 여부에 관계없이 서버 버전이 7.4 이상이고 런타임에서 Java 17을 사용하는 경우 보안을 위해 Elytron 하위 시스템을 사용하도록 구성이 업데이트됩니다.
• 앱 설정을 WEBSITE_JBOSS_OPTS구성하면 값이 JBoss 시작 관리자 스크립트에 전달됩니다. 이 설정을 사용하여 속성 파일에 대한 경로와 JBoss EAP의 시작에 영향을 주는 더 많은 플래그를 제공할 수 있습니다.

3. 서버 구성 단계

• 이 단계가 시작될 때 App Service는 먼저 JBoss EAP 서버와 관리자 인터페이스가 모두 요청을 받을 준비가 될 때까지 기다린 후 계속합니다. Application Insights를 사용하는 경우 이 프로세스는 몇 초 더 걸릴 수 있습니다.

• JBoss EAP 서버와 관리자 인터페이스가 모두 준비되면 App Service는 다음 작업을 수행합니다.

  • 로깅 및 App Service와의 통합을 위한 유틸리티 클래스를 제공하는 JBoss EAP 모듈 azure.appservice을 추가합니다.
  • 로그 파일에 색 이스케이프 시퀀스가 포함되지 않도록 콘솔 로거가 무색 모드를 사용하도록 업데이트합니다.
  • Azure Monitor 로그와의 통합을 설정합니다.
  • WSDL(Web Services Description Language) 및 관리 인터페이스의 바인딩 IP 주소를 업데이트합니다.
  • azure.appservice.easyauth 및 Microsoft Entra ID와 통합하기 위한 JBoss EAP 모듈 을 추가합니다.
  • 액세스 로그의 로깅 구성과 주 서버 로그 파일의 이름 및 회전을 업데이트합니다.

• 앱 설정 WEBSITE_SKIP_AUTOCONFIGURE_DATABASE 이 정의되지 않는 한 App Service는 App Service 앱 설정에서 JDBC(Java Database Connectivity) URL을 자동으로 검색합니다. PostgreSQL, MySQL, MariaDB, Oracle, SQL Server 또는 Azure SQL Database에 유효한 JDBC URL이 있는 경우 해당 드라이버를 서버에 추가하고, 각 JDBC URL에 대한 데이터 원본을 추가하고, 각 데이터 원본 java:jboss/env/jdbc/<app-setting-name>_DS에 대한 JNDI(Java Naming and Directory Interface) 이름을 설정합니다. 여기서 앱 설정의 이름은 다음과 <app-setting-name> 같습니다.

• clustering 구성이 사용하도록 설정된 경우 구성할 콘솔 로거가 확인됩니다.

• 디렉터리에 배포된 /home/site/libs JAR 파일이 있는 경우 이러한 모든 JAR 파일을 사용하여 새 전역 모듈이 만들어집니다.

• 단계의 끝에서 App Service는 사용자 지정 시작 스크립트(있는 경우)를 실행합니다. 사용자 지정 시작 스크립트에 대한 검색 논리는 다음과 같이 정의됩니다.

  • 시작 명령(예: Azure Portal 또는 Azure CLI를 통해)을 구성한 경우 실행합니다. 그렇지 않으면
  • 경로 /home/site/scripts/startup.sh 가 있는 경우 사용합니다. 그렇지 않으면
  • 경로 /home/startup.sh 가 있는 경우 사용합니다.

사용자 지정 시작 명령 또는 스크립트는 루트 사용자(필요 sudo없음)로 실행되므로 Linux 패키지를 설치하거나 JBoss CLI를 시작하여 데이터 원본 만들기 및 리소스 어댑터 설치와 같은 더 많은 JBoss EAP 설치/사용자 지정 명령을 수행할 수 있습니다. Ubuntu 패키지 관리 명령에 대한 자세한 내용은 Ubuntu Server 설명서를 참조하세요. JBoss CLI 명령은 JBoss 관리 CLI 가이드를 참조 하세요.

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 서버에 배포된 애플리케이션이 요청에 응답할 준비가 되어 있어야 합니다.
• 서버는 App Service 앱이 중지되거나 다시 시작될 때까지 실행됩니다. App Service 앱을 수동으로 중지하거나 다시 시작하거나, 파일을 배포하거나 App Service 앱에 구성을 변경할 때 다시 시작을 트리거할 수 있습니다.
• clustering 구성에서 JBoss EAP 서버가 비정상적으로 종료되면 emit_alert_tx_store_not_empty라는 최종 함수가 실행됩니다. 이 함수는 JBoss EAP 프로세스가 디스크에 비어 있지 않은 트랜잭션 저장소 파일을 남겼는지 확인합니다. 이 경우 콘솔 Error: finishing server with non-empty store for node XXXX에 오류가 기록됩니다. 새 서버 인스턴스가 시작되면 이러한 비어 있지 않은 트랜잭션 저장소 파일을 검색하여 작업을 다시 시작합니다(2 참조 ). 서버 시작 단계).

Tomcat 기준 구성

참고

이 섹션은 Linux에만 적용됩니다.

Java 개발자는 Tomcat의 server.xml 파일 및 구성 세부 정보를 알고 있으면 자신 있게 서버 설정을 사용자 지정하고, 문제를 해결하고, 애플리케이션을 Tomcat에 배포할 수 있습니다. 가능한 사용자 지정은 다음과 같습니다.

• Tomcat 구성 사용자 지정: server.xml 파일 및 Tomcat의 구성 세부 정보를 이해하면 해당 애플리케이션의 요구 사항에 맞게 서버 설정을 미세 조정할 수 있습니다.
• 디버깅: 애플리케이션이 Tomcat 서버에 배포될 때 개발자는 발생할 수 있는 모든 문제를 디버깅하기 위해 서버 구성을 알아야 합니다. 이 프로세스에는 서버 로그 확인, 구성 파일 검사 및 발생할 수 있는 오류 식별이 포함됩니다.
• Tomcat 문제 해결: Java 개발자는 성능 문제나 구성 오류와 같은 Tomcat 서버 관련 문제에 직면하게 됩니다. server.xml 파일 및 Tomcat의 구성 세부 정보를 이해하면 개발자는 이러한 문제를 신속하게 진단하고 해결하여 시간과 노력을 절약할 수 있습니다.
• Tomcat에 애플리케이션 배포: Java 웹 애플리케이션을 Tomcat에 배포하려면 개발자는 server.xml 파일 및 기타 Tomcat 설정을 구성하는 방법을 알아야 합니다. 애플리케이션을 성공적으로 배포하고 서버에서 원활하게 실행되도록 하려면 이러한 세부 정보를 이해해야 합니다.

Java 워크로드(WAR 파일 또는 JAR 파일)를 호스팅하기 위해 Tomcat이 기본 제공된 앱을 만들 때 Tomcat 구성을 위해 기본 제공할 수 있는 특정 설정이 있습니다. Tomcat 웹 서버에 대한 기본 구성을 포함하여 자세한 내용은 공식 Apache Tomcat 설명서를 참조할 수 있습니다.

또한 시작 시 Tomcat 배포에 대한 server.xml 위에 적용되는 특정 변환이 있습니다. 이러한 변환에는 커넥터, 호스트 및 밸브 설정에 대한 변경 내용 이 포함됩니다.

최신 버전의 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

참고

connectionTimeout앱 설정으로 , maxThreads및 maxConnections 설정을 조정할 수 있습니다.

다음은 connectionTimeout, maxThreads, 또는 maxConnections의 값을 변경하는 데 사용할 수 있는 CLI 명령 예제입니다.

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로 설정되며, 기본적으로 로컬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>

관련 콘텐츠

Java 개발자용 Azure 센터를 방문하여 Azure 빠른 시작, 자습서 및 Java 참조 설명서를 찾아보세요.

• App Service Linux FAQ
• 환경 변수 및 앱 설정 참조