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

Java SE에 .jar 파일을 배포하려면 Kudu 사이트의 /api/publish 엔드포인트를 사용합니다. 이 API에 대한 자세한 내용은 이 설명서를 참조하세요.

.war 파일을 Tomcat에 배포하려면 /api/wardeploy/ 엔드포인트를 사용하여 보관 파일을 게시합니다. 이 API에 대한 자세한 내용은 이 설명서를 참조하세요.

JBoss에 .war 파일을 배포하려면 /api/wardeploy/ 엔드포인트를 사용하여 보관 파일을 게시합니다. 이 API에 대한 자세한 내용은 이 설명서를 참조하세요.

.ear 파일을 배포하려면 FTP를 사용합니다. .ear 애플리케이션은 애플리케이션 구성에 정의된 컨텍스트 루트에 배포됩니다. 예를 들어 앱의 컨텍스트 루트가 <context-root>myapp</context-root>인 경우, /myapp 경로에서 사이트를 찾아 볼 수 있습니다. http://my-app-name.azurewebsites.net/myapp 웹앱을 루트 경로에 제공하려면 앱이 컨텍스트 루트를 루트 경로로 설정했는지 확인합니다. <context-root>/</context-root> 자세한 정보는 웹 애플리케이션의 컨텍스트 루트 설정을 참조하세요.

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

JBoss는 또한 다시 쓰기 밸브를 제공합니다.

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

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

JSP 파일 미리 컴파일

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

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

JBoss CLI 실행

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

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

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

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

또는 시작 시 모든 파일을 실행하도록 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 레시피

Clustering

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

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

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

자동 크기 조정 규칙

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

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

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

App Service 계획

JBoss EAP는 F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3 및 P5mv3 가격 책정 계층에서 사용할 수 있습니다.

JBoss 서버 수명 주기

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.keyStorejavax.net.ssl.keyStorePassword javax.net.ssl.keyStoreType 이 환경 변수에 JAVA_TOOL_OPTIONS 추가됩니다.
• 로깅 디렉터리 및 Java 메모리 힙 매개 변수와 같은 일부 초기 JVM 구성이 결정됩니다.
  • 앱 설정JAVA_OPTS에서 메모리에 –Xms 대한 플래그 또는 –Xmx 플래그를 제공하는 경우 이러한 값은 플랫폼에서 제공하는 값을 재정의합니다.
  • 앱 설정을 WEBSITES_CONTAINER_STOP_TIME_LIMIT구성하면 값이 런타임 속성으로 전달됩니다. 이 속성 org.wildfly.sigterm.suspend.timeout은 JBoss가 중지될 때 최대 종료 대기 시간(초)을 제어합니다.
• 앱이 가상 네트워크와 통합된 경우 App Service 런타임은 환경 변수 WEBSITE_PRIVATE_PORTS 에서 서버 간 통신에 사용할 포트 목록을 전달하고 구성을 사용하여 JBoss를 clustering 시작합니다. 그렇지 않으면 구성이 standalone 사용됩니다.
  • 구성의 clustering 경우 서버 구성 파일 standalone-azure-full-ha.xml 사용됩니다.
  • 구성의 standalone 경우 서버 구성 파일 standalone-full.xml 사용됩니다.

2. 서버 시작 단계

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

3. 서버 구성 단계

• 이 단계가 시작될 때 App Service는 먼저 JBoss 서버와 관리자 인터페이스가 모두 요청을 받을 준비가 될 때까지 기다린 후 계속합니다. Application Insights를 사용하는 경우 몇 초 더 걸릴 수 있습니다.
• JBoss Server와 관리 인터페이스가 모두 준비되면 App Service는 다음을 수행합니다.
  • App Service와의 로깅 및 통합을 위한 유틸리티 클래스를 제공하는 JBoss 모듈 azure.appservice을 추가합니다.
  • 로그 파일이 색 이스케이프 시퀀스로 가득 차 있지 않도록 콘솔 로거가 무색 모드를 사용하도록 업데이트합니다.
  • Azure Monitor 로그와의 통합을 설정합니다.
  • WSDL 및 관리 인터페이스의 바인딩 IP 주소를 업데이트합니다.
  • App Service 인증 및 Microsoft Entra ID와 통합하기 위한 JBoss 모듈 azure.appservice.easyauth 을 추가합니다.
  • 액세스 로그의 로깅 구성과 주 서버 로그 파일의 이름 및 회전을 업데이트합니다.
• 앱 설정 WEBSITE_SKIP_AUTOCONFIGURE_DATABASE 이 정의되지 않는 한 App Service는 App Service 앱 설정에서 JDBC URL을 자동으로 검색합니다. PostgreSQL, MySQL, MariaDB, Oracle, SQL Server 또는 Azure SQL Database에 유효한 JDBC URL이 있는 경우 해당 드라이버를 서버에 추가하고 각 JDBC URL에 대한 데이터 원본을 추가하고 각 데이터 원본 java:jboss/env/jdbc/<app-setting-name>_DS의 JNDI 이름을 앱 설정의 이름인 위치 <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 설치/사용자 지정 명령(데이터 원본 만들기, 리소스 어댑터 설치)을 수행할 수 있습니다. Ubuntu 패키지 관리 명령에 대한 자세한 내용은 Ubuntu Server 설명서를 참조 하세요. JBoss CLI 명령은 JBoss 관리 CLI 가이드를 참조 하세요.

4. 앱 배포 단계

시작 스크립트는 우선 순위에 따라 다음 위치를 확인하여 JBoss에 앱을 배포합니다.

• 앱 설정을 구성한 경우 앱에서 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 서버가 다시 로드되어 서버를 다시 로드해야 하는 변경 내용을 적용합니다.
• 서버가 다시 로드되면 JBoss EAP 서버에 배포된 애플리케이션이 요청에 응답할 준비가 되어 있어야 합니다.
• 서버는 App Service 앱이 중지되거나 다시 시작될 때까지 실행됩니다. App Service 앱을 수동으로 중지하거나 다시 시작하거나, 파일을 배포하거나 App Service 앱에 구성을 변경할 때 다시 시작을 트리거할 수 있습니다.
• 구성에서 JBoss 서버가 비정상적으로 clustering 종료되면 호출 emit_alert_tx_store_not_empty 된 최종 함수가 실행됩니다. 함수는 JBoss 프로세스가 디스크에 비어 있지 않은 트랜잭션 저장소 파일을 남겼는지 확인합니다. 그렇다면 콘솔 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 설정을 구성하는 방법을 알아야 합니다. 애플리케이션을 성공적으로 배포하고 서버에서 원활하게 실행하려면 이러한 세부 정보를 이해하는 것이 필수적입니다.

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의 값을 변경하는 데 사용할 수 있는 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

<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>