JBoss EAP 애플리케이션을 Azure Kubernetes Service의 WildFly로 마이그레이션Migrate JBoss EAP applications to WildFly on Azure Kubernetes Service

이 가이드에서는 Azure Kubernetes Service 컨테이너의 WildFly에서 실행되도록 기존 JBoss EAP 애플리케이션을 마이그레이션하려는 경우 알아야 할 사항에 대해 설명합니다.This guide describes what you should be aware of when you want to migrate an existing JBoss EAP application to run on WildFly in an Azure Kubernetes Service container.

사전 마이그레이션Pre-migration

마이그레이션을 성공적으로 수행하려면 시작하기 전에 다음 섹션에서 설명하는 평가 및 인벤토리 단계를 완료합니다.To ensure a successful migration, before you start, complete the assessment and inventory steps described in the following sections.

서버 용량 인벤토리화Inventory server capacity

현재 프로덕션 서버의 하드웨어(메모리, CPU, 디스크)와 평균/최대 요청 수 및 리소스 사용량을 문서화합니다.Document the hardware (memory, CPU, disk) of the current production server(s) as well as the average and peak request counts and resource utilization. 선택한 마이그레이션 경로에 관계없이 이 정보가 필요합니다.You'll need this information regardless of the migration path you choose. 예를 들어 노드 풀의 VM 크기, 컨테이너에서 사용할 메모리의 양 및 컨테이너에 필요한 CPU 공유 수를 선택하는 데 도움이 됩니다.It is useful, for example, to help guide selection of the size of the VMs in your node pool, the amount of memory to be used by the container, and how many CPU shares the container would need.

모든 비밀 인벤토리화Inventory all secrets

프로덕션 서버의 모든 속성 및 구성 파일에 비밀과 암호가 있는지 확인합니다.Check all properties and configuration files on the production server(s) for any secrets and passwords. WAR에서 jboss-web.xml 파일을 확인합니다.Be sure to check jboss-web.xml in your WARs. 암호 또는 자격 증명이 포함된 구성 파일은 애플리케이션 내에서도 찾을 수 있습니다.Configuration files that contain passwords or credentials may also be found inside your application.

이러한 비밀은 Azure Key Vault에 저장하는 것이 좋습니다.Consider storing those secrets in Azure KeyVault. 자세한 내용은 Azure Key Vault 기본 개념을 참조하세요.For more information, see Azure Key Vault basic concepts.

모든 인증서 인벤토리화Inventory all certificates

공용 SSL 엔드포인트에 사용되는 모든 인증서를 문서화합니다.Document all the certificates used for public SSL endpoints. 다음 명령을 실행하여 프로덕션 서버에서 모든 인증서를 볼 수 있습니다.You can view all certificates on the production server(s) by running the following command:

keytool -list -v -keystore <path to keystore>

지원되는 Java 버전이 제대로 작동하는지 확인Validate that the supported Java version works correctly

Azure Kubernetes Service에서 WildFly를 사용하려면 특정 버전의 Java가 필요하므로 지원되는 버전을 사용하여 애플리케이션이 올바르게 실행되는지 확인해야 합니다.Using WildFly on Azure Kubernetes Service requires a specific version of Java, so you'll need to confirm that your application runs correctly using that supported version.

참고

현재 서버를 지원되지 않는 JDK(예: Oracle JDK 또는 IBM OpenJ9)에서 실행하는 경우 이 유효성 검사가 특히 중요합니다.This validation is especially important if your current server is running on an unsupported JDK (such as Oracle JDK or IBM OpenJ9).

현재 Java 버전을 가져오려면 프로덕션 서버에 로그인하고 다음 명령을 실행합니다.To obtain your current Java version, sign in to your production server and run the following command:

java -version

WildFly를 실행하는 데 사용할 버전에 대한 지침은 요구 사항을 참조하세요.See Requirements for guidance on what version to use to run WildFly.

JNDI 리소스 인벤토리화Inventory JNDI resources

모든 JNDI 리소스를 인벤토리화합니다.Inventory all JNDI resources. JMS 메시지 브로커와 같은 일부 리소스에는 마이그레이션 또는 재구성이 필요할 수 있습니다.Some, such as JMS message brokers, may require migration or reconfiguration.

세션 복제가 사용되는지 확인Determine whether session replication is used

애플리케이션에서 세션 복제를 사용하는 경우 이 종속성을 제거하도록 애플리케이션을 변경해야 합니다.If your application relies on session replication, you'll have to change your application to remove this dependency.

애플리케이션 내부Inside your application

WEB-INF/jboss-web.xml 및/또는 WEB-INF/web.xml 파일을 검사합니다.Inspect the WEB-INF/jboss-web.xml and/or WEB-INF/web.xml files.

데이터 원본 문서화Document datasources

애플리케이션에서 데이터베이스를 사용하는 경우 다음 정보를 캡처해야 합니다.If your application uses any databases, you need to capture the following information:

  • 데이터 원본 이름은 무엇인가요?What is the datasource name?
  • 연결 풀 구성이란?What is the connection pool configuration?
  • JDBC 드라이버 JAR 파일은 어디에서 찾을 수 있나요?Where can I find the JDBC driver JAR file?

자세한 내용은 JBoss EAP 설명서의 JBoss EAP 데이터 원본 정보를 참조하세요.For more information, see About JBoss EAP Datasources in the JBoss EAP documentation.

파일 시스템의 사용 여부 및 방법 확인Determine whether and how the file system is used

애플리케이션 서버에서 파일 시스템을 사용하려면 재구성하거나 드물게 아키텍처 변경이 필요합니다.Any usage of the file system on the application server will require reconfiguration or, in rare cases, architectural changes. 파일 시스템은 JBoss EAP 모듈 또는 애플리케이션 코드에서 사용할 수 있습니다.File system may be used by JBoss EAP modules or by your application code. 다음 섹션에서 설명하는 시나리오의 일부 또는 전부를 식별할 수 있습니다.You may identify some or all of the scenarios described in the following sections.

읽기 전용 정적 콘텐츠Read-only static content

애플리케이션에서 현재 정적 콘텐츠를 제공하는 경우 이를 대체할 위치가 필요합니다.If your application currently serves static content, you'll need an alternate location for it. 정적 콘텐츠를 Azure Blob Storage로 이동하고 전역적으로 빠른 다운로드를 위해 Azure CDN을 추가하는 것이 좋습니다.You may wish to consider moving static content to Azure Blob Storage and adding Azure CDN for lightning-fast downloads globally. 자세한 내용은 Azure Storage에서 정적 웹 사이트 호스팅빠른 시작: Azure CDN과 Azure Storage 계정 통합을 참조하세요.For more information, see Static website hosting in Azure Storage and Quickstart: Integrate an Azure storage account with Azure CDN.

동적으로 게시된 정적 콘텐츠Dynamically published static content

애플리케이션이 애플리케이션에서 업로드/생성되었지만 생성 후 변경할 수 없는 정적 콘텐츠를 허용하는 경우, 위에서 설명한 대로 Azure Blob Storage 및 Azure CDN를 사용하여 업로드 및 CDN 새로 고침을 처리할 수 있습니다.If your application allows for static content that is uploaded/produced by your application but is immutable after its creation, you can use Azure Blob Storage and Azure CDN as described above, with an Azure Function to handle uploads and CDN refresh. Azure Functions를 사용하여 정적 콘텐츠 업로드 및 CDN 사전 로드에서 사용할 샘플 구현을 제공했습니다.We've provided a sample implementation for your use at Uploading and CDN-preloading static content with Azure Functions.

동적 또는 내부 콘텐츠Dynamic or internal content

애플리케이션에서 자주 쓰고 읽는 파일(예: 임시 데이터 파일) 또는 애플리케이션에만 표시되는 정적 파일의 경우 Azure Storage 공유를 영구 볼륨으로 탑재할 수 있습니다.For files that are frequently written and read by your application (such as temporary data files), or static files that are visible only to your application, you can mount Azure Storage shares as persistent volumes. 자세한 내용은 Azure Kubernetes Service에서 Azure Files를 사용하여 영구 볼륨을 동적으로 만들어 사용을 참조하세요.For more information, see Dynamically create and use a persistent volume with Azure Files in Azure Kubernetes Service.

애플리케이션에서 예약된 작업을 사용하는지 확인Determine whether your application relies on scheduled jobs

Quartz Scheduler 작업 또는 Unix cron 작업과 같은 예약된 작업을 Azure Kubernetes Service에서 사용해서는 안 됩니다.Scheduled jobs, such as Quartz Scheduler tasks or Unix cron jobs, should NOT be used with Azure Kubernetes Service. Azure Kubernetes Service는 예약된 작업이 포함된 애플리케이션을 내부적으로 배포하는 것을 방지하지 않습니다.Azure Kubernetes Service will not prevent you from deploying an application containing scheduled tasks internally. 그러나 애플리케이션이 확장되는 경우 동일한 예약된 작업이 예약된 기간마다 두 번 이상 실행될 수 있습니다.However, if your application is scaled out, the same scheduled job may run more than once per scheduled period. 이 경우 의도하지 않은 결과가 발생할 수 있습니다.This situation can lead to unintended consequences.

AKS 클러스터에서 예약된 작업을 실행하려면 필요에 따라 Kubernetes CronJob을 정의합니다.To execute scheduled jobs on your AKS cluster, define Kubernetes CronJobs as needed. 자세한 내용은 CronJob을 사용하여 자동화된 작업 실행을 참조하세요.For more information, see Running Automated Tasks with a CronJob.

온-프레미스 연결이 필요한지 확인Determine whether a connection to on-premises is needed

애플리케이션에서 온-프레미스 서비스에 액세스해야 하는 경우 Azure의 연결 서비스 중 하나를 프로비저닝해야 합니다.If your application needs to access any of your on-premises services, you'll need to provision one of Azure's connectivity services. 자세한 내용은 온-프레미스 네트워크를 Azure에 연결하기 위한 솔루션 선택을 참조하세요.For more information, see Choose a solution for connecting an on-premises network to Azure. 또는 온-프레미스 리소스에서 노출하는 공개적으로 사용 가능한 API를 사용하도록 애플리케이션을 리팩터링해야 합니다.Alternatively, you'll need to refactor your application to use publicly available APIs that your on-premises resources expose.

JMS(Java Message Service) 큐 또는 토픽을 사용하는지 확인Determine whether Java Message Service (JMS) Queues or Topics are in use

애플리케이션에서 JMS 큐 또는 토픽을 사용하는 경우 외부에서 호스팅되는 JMS 서버로 마이그레이션해야 합니다.If your application is using JMS Queues or Topics, you'll need to migrate them to an externally hosted JMS server. Azure Service Bus 및 AMQP(고급 메시지 큐 프로토콜)는 JMS를 사용하는 애플리케이션에 매우 유용한 마이그레이션 전략이 될 수 있습니다.Azure Service Bus and the Advanced Message Queuing Protocol (AMQP) can be a great migration strategy for those using JMS. 자세한 내용은 Azure Service Bus 및 AMQP 1.0에서 JMS 사용을 참조하세요.For more information, see Use JMS with Azure Service Bus and AMQP 1.0.

JMS 영구 저장소가 구성된 경우 해당 구성을 캡처하여 마이그레이션 후에 적용해야 합니다.If JMS persistent stores have been configured, you must capture their configuration and apply it after the migration.

애플리케이션에서 JBoss-EAP 관련 API를 사용하는지 확인Determine whether your application uses JBoss-EAP-specific APIs

애플리케이션에서 JBoss-EAP 관련 API를 사용하는 경우 해당 종속성을 제거하도록 애플리케이션을 리팩터링해야 합니다.If your application uses JBoss-EAP-specific APIs, you'll need to refactor it to remove those dependencies.

애플리케이션에서 Entity Beans를 사용하는지, EJB 2.x 스타일의 CMP Beans를 사용하는지 확인합니다.Determine whether your application uses Entity Beans or EJB 2.x-style CMP Beans

애플리케이션에서 Entity Beans 또는 EJB 2.x 스타일 CMP Beans를 사용하는 경우 애플리케이션을 리팩터링하여 이러한 종속성을 제거해야 합니다.If your application uses Entity Beans or EJB 2.x style CMP beans, you'll need to refactor your application to remove these dependencies.

Java EE 애플리케이션 클라이언트 기능이 사용 중인지 확인Determine whether the Java EE Application Client feature is in use

Java EE 애플리케이션 클라이언트 기능을 사용하여 (서버) 애플리케이션에 연결하는 클라이언트 애플리케이션이 있는 경우 HTTP API를 사용하려면 클라이언트 애플리케이션과 (서버) 애플리케이션을 모두 리팩터링해야 합니다.If you have client applications that connect to your (server) application using the Java EE Application Client feature, you'll need to refactor both your client applications and your (server) application to use HTTP APIs.

OS 관련 코드가 애플리케이션에 포함되어 있는지 확인Determine whether your application contains OS-specific code

호스트 OS에 대한 종속성이 있는 코드가 애플리케이션에 포함되어 있는 경우 해당 종속성을 제거하려면 이 코드를 리팩터링해야 합니다.If your application contains any code with dependencies on the host OS, then you'll need to refactor it to remove those dependencies. 예를 들어 파일 시스템 경로에서 사용하고 있는 / 또는 \File.Separator 또는 Paths.get으로 바꿔야 할 수 있습니다.For example, you may need to replace any use of / or \ in file system paths with File.Separator or Paths.get.

EJB 타이머가 사용 중인지 확인Determine whether EJB timers are in use

애플리케이션에서 EJB 타이머를 사용하는 경우 각 WildFly 인스턴스에서 독립적으로 EJB 타이머 코드를 트리거할 수 있는지 확인해야 합니다.If your application uses EJB timers, you'll need to validate that the EJB timer code can be triggered by each WildFly instance independently. 이 유효성 검사는 Azure Kubernetes 서비스 배포 시나리오에서 각 EJB 타이머가 자체 WildFly 인스턴스에서 트리거되기 때문에 필요합니다.This validation is needed because, in the Azure Kubernetes Service deployment scenario, each EJB timer will be triggered on its own WildFly instance.

JCA 커넥터가 사용되는지 확인Determine whether JCA connectors are in use

애플리케이션에서 JCA 커넥터를 사용하는 경우 WildFly에서 JCA 커넥터를 사용할 수 있는지 확인합니다.If your application uses JCA connectors, validate that you can use the JCA connector on WildFly. JCA 구현이 JBoss EAP에 연결되는 경우 애플리케이션을 리팩터링하여 해당 종속성을 제거해야 합니다.If the JCA implementation is tied to JBoss EAP, you must refactor your application to remove that dependency. WildFly에서 JCA 커넥터를 사용할 수 있는 경우 JAR을 서버 클래스 경로에 추가하고 필요한 구성 파일을 WildFly 서버 디렉터리의 올바른 위치에 배치해야 합니다.If you can use the JCA connector on WildFly, then for it to be available, you must add the JARs to the server classpath and put the necessary configuration files in the correct location in the WildFly server directories.

JAAS가 사용 중인지 확인Determine whether JAAS is in use

애플리케이션에서 JAAS를 사용 중인 경우 JAAS가 구성된 방식을 캡처해야 합니다.If your application is using JAAS, you'll need to capture how JAAS is configured. JAAS가 데이터베이스를 사용 중인 경우 WildFly의 JAAS 도메인으로 변환할 수 있습니다.If it's using a database, you can convert it to a JAAS domain on WildFly. 사용자 지정 구현인 경우 WildFly에서 사용할 수 있는지 확인해야 합니다.If it's a custom implementation, you'll need to validate that it can be used on WildFly.

애플리케이션에서 리소스 어댑터를 사용하는지 확인Determine whether your application uses a Resource Adapter

RA(리소스 어댑터)가 필요한 애플리케이션은 WildFly와 호환되어야 합니다.If your application needs a Resource Adapter (RA), it needs to be compatible with WildFly. RA를 서버에 배포하고 적절하게 구성하여 WildFly의 독립 실행형 인스턴스에서 제대로 작동하는지 확인합니다.Determine whether the RA works fine on a standalone instance of WildFly by deploying it to the server and properly configuring it. RA가 제대로 작동하면 JAR을 Docker 이미지의 서버 클래스 경로에 추가하고 필요한 구성 파일을 WildFly 서버 디렉터리의 올바른 위치에 배치해야 합니다.If the RA works properly, you'll need to add the JARs to the server classpath of the Docker image and put the necessary configuration files in the correct location in the WildFly server directories for it to be available.

애플리케이션이 여러 WAR로 구성되었는지 확인Determine whether your application is composed of multiple WARs

애플리케이션이 여러 WAR로 구성된 경우 각 WAR를 별도의 애플리케이션으로 처리하고 각각에 대해 이 가이드를 수행해야 합니다.If your application is composed of multiple WARs, you should treat each of those WARs as separate applications and go through this guide for each of them.

애플리케이션이 EAR로 패키징되는지 확인Determine whether your application is packaged as an EAR

애플리케이션이 EAR 파일로 패키지되는 경우 application.xml 파일을 검사하고 해당 구성을 캡처합니다.If your application is packaged as an EAR file, be sure to examine the application.xml file and capture the configuration.

참고

AKS 리소스를 더 효율적으로 사용하기 위해 각 웹 애플리케이션의 크기를 독립적으로 조정하려면 EAR을 별도의 웹 애플리케이션으로 분리해야 합니다.If you want to be able to scale each of your web applications independently for better use of your AKS resources you should break up the EAR into separate web applications.

프로덕션 서버에서 실행되는 모든 외부 프로세스 및 디먼 확인Identify all outside processes and daemons running on the production servers

디먼 모니터링과 같이 애플리케이션 서버 외부에서 실행되는 프로세스가 있는 경우 이러한 프로세스를 제거하거나 다른 곳으로 마이그레이션해야 합니다.If you have any processes running outside the application server, such as monitoring daemons, you'll need to eliminate them or migrate them elsewhere.

내부 테스트 수행Perform in-place testing

컨테이너 이미지를 만들기 전에 애플리케이션을 AKS에서 사용하려는 JDK 및 WildFly 버전으로 마이그레이션합니다.Prior to creating your container images, migrate your application to the JDK and WildFly versions that you intend to use on AKS. 호환성과 성능을 보장하기 위해 애플리케이션을 철저히 테스트합니다.Test the application thoroughly to ensure compatibility and performance.

마이그레이션Migration

Azure Container Registry 및 Azure Kubernetes Service 프로비저닝Provision Azure Container Registry and Azure Kubernetes Service

다음 명령을 사용하여 서비스 주체가 레지스트리에서 읽기 권한자 역할을 갖는 컨테이너 레지스트리와 Azure Kubernetes 클러스터를 만듭니다.Use the following commands to create a container registry and an Azure Kubernetes cluster with a Service Principal that has the Reader role on the registry. 클러스터의 네트워킹 요구 사항에 적합한 네트워크 모델을 선택해야 합니다.Be sure to choose the appropriate network model for your cluster's networking requirements.

az group create -g $resourceGroup -l eastus
az acr create -g $resourceGroup -n $acrName --sku Standard
az aks create -g $resourceGroup -n $aksName --attach-acr $acrName --network-plugin azure

WildFly용 Docker 이미지 만들기Create a Docker image for WildFly

Dockerfile을 만들려면 다음과 같은 필수 조건을 갖추어야 합니다.To create a Dockerfile, you'll need the following prerequisites:

  • 지원되는 JDKA supported JDK.
  • WildFly 설치An install of WildFly.
  • JVM 런타임 옵션.Your JVM runtime options.
  • 환경 변수를 전달하는 방법(해당하는 경우).A way to pass in environment variables (if applicable).

그런 다음, 다음 섹션에 설명된 단계를 수행할 수 있습니다(해당하는 경우).You can then perform the steps described in the following sections, where applicable. Dockerfile 및 웹 애플리케이션의 시작 지점으로 WildFly 컨테이너 빠른 시작 리포지토리를 사용할 수 있습니다.You can use the WildFly Container Quickstart repo as a starting point for your Dockerfile and web application.

  1. KeyVault FlexVolume 구성Configure KeyVault FlexVolume
  2. 데이터 원본 설정Set up data sources
  3. JNDI 리소스 설정Set up JNDI resources
  4. WildFly 구성 검토Review WildFly configuration

KeyVault FlexVolume 구성Configure KeyVault FlexVolume

Azure KeyVault를 만들고 필요한 모든 비밀을 채웁니다.Create an Azure KeyVault and populate all the necessary secrets. 자세한 내용은 빠른 시작: Azure CLI를 사용하여 Azure Key Vault에서 비밀을 설정하고 검색합니다.For more information, see Quickstart: Set and retrieve a secret from Azure Key Vault using Azure CLI. 그런 다음, Pod에서 이러한 비밀을 액세스할 수 있도록 KeyVault FlexVolume을 구성합니다.Then, configure a KeyVault FlexVolume to make those secrets accessible to pods.

WildFly를 부트스트랩하는 데 사용되는 시작 스크립트도 업데이트해야 합니다.You will also need to update the startup script used to bootstrap WildFly. 이 스크립트는 서버를 시작하기 전에 WildFly에서 사용하는 키 저장소로 인증서를 가져와야 합니다.This script must import the certificates into the keystore used by WildFly before starting the server.

데이터 원본 설정Set up data sources

데이터 원본에 액세스하도록 WildFly를 구성하려면 JDBC 드라이버 JAR을 Docker 이미지에 추가하고 적절한 JBoss CLI 명령을 실행해야 합니다.To configure WildFly to access a data source, you'll need to add the JDBC driver JAR to your Docker image, and then execute the appropriate JBoss CLI commands. 이러한 명령은 Docker 이미지를 빌드할 때 데이터 원본을 설정해야 합니다.These commands must set up the data source when building your Docker image.

다음 단계는 PostgreSQL, MySQL 및 SQL Server에 대한 지침을 제공합니다.The following steps provide instructions for PostgreSQL, MySQL and SQL Server.

  1. PostgreSQL, MySQL 또는 SQL Server용 JDBC 드라이버를 다운로드합니다.Download the JDBC driver for PostgreSQL, MySQL, or SQL Server.

    다운로드한 보관 파일의 압축을 풀어 드라이버 .jar 파일을 가져옵니다.Unpack the downloaded archive to get the driver .jar file.

  2. module.xml 같은 이름으로 파일을 만들고 다음 태그를 추가합니다.Create a file with a name like module.xml and add the following markup. <module name> 자리 표시자(꺾쇠 괄호 포함)를 PostgreSQL의 경우 org.postgres, MySQL의 경우 com.mysql, SQL Server의 경우 com.microsoft로 바꿉니다.Replace the <module name> placeholder (including the angle brackets) with org.postgres for PostgreSQL, com.mysql for MySQL, or com.microsoft for SQL Server. <JDBC .jar file path>를 이전 단계의 jar 파일 이름으로 바꿉니다. 예를 들어 Docker 이미지의 파일을 배치할 위치의 전체 경로를 포함합니다(예: /opt/database).Replace <JDBC .jar file path> with the name of the .jar file from the previous step, including the full path to the location you will place the file in your Docker image, for example in /opt/database.

    <?xml version="1.0" ?>
    <module xmlns="urn:jboss:module:1.1" name="<module name>">
        <resources>
           <resource-root path="<JDBC .jar file path>" />
        </resources>
        <dependencies>
            <module name="javax.api"/>
            <module name="javax.transaction.api"/>
        </dependencies>
    </module>
    
  3. datasource-commands.cli 같은 이름으로 파일을 만들고 다음 코드를 추가합니다.Create a file with a name like datasource-commands.cli and add the following code. <JDBC .jar file path>를 이전 단계에서 사용한 값으로 바꿉니다.Replace <JDBC .jar file path> with the value you used in the previous step. <module file path>를 이전 단계의 파일 이름 및 경로로 바꿉니다(예: /opt/database/module.xml).Replace <module file path> with the file name and path from the previous step, for example /opt/database/module.xml.

    PostgreSQLPostgreSQL

    batch
    module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
    /subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
    data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
    reload
    run batch
    shutdown
    

    MySQLMySQL

    batch
    module add --name=com.mysql --resources=<JDBC .jar file path> --module-xml=<module file path>
    /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-class-name=com.mysql.cj.jdbc.Driver)
    data-source add --name=mysqlDS --jndi-name=java:jboss/datasources/mysqlDS --connection-url=$DATABASE_CONNECTION_URL --driver-name=mysql --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=com.mysql.cj.jdbc.Driver --jta=true --use-java-context=true --exception-sorter-class-name=com.mysql.cj.jdbc.integration.jboss.ExtendedMysqlExceptionSorter
    reload
    run batch
    shutdown
    

    SQL ServerSQL Server

    batch
    module add --name=com.microsoft --resources=<JDBC .jar file path> --module-xml=<module file path>
    /subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver,driver-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerDataSource)
    data-source add --name=sqlDS --jndi-name=java:jboss/datasources/sqlDS --driver-name=sqlserver --connection-url=$DATABASE_CONNECTION_URL --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
    reload
    run batch
    shutdown
    
  4. 애플리케이션의 JTA 데이터 원본 구성을 업데이트합니다.Update the the JTA datasource configuration for your application:

    앱의 src/main/resources/META-INF/persistence.xml 파일을 열고 <jta-data-source> 요소를 찾습니다.Open the src/main/resources/META-INF/persistence.xml file for your app and find the <jta-data-source> element. 다음과 같이 내용을 바꿉니다.Replace its contents as shown here:

    PostgreSQLPostgreSQL

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
    

    MySQLMySQL

    <jta-data-source>java:jboss/datasources/mysqlDS</jta-data-source>
    

    SQL ServerSQL Server

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
    
  5. Docker 이미지를 빌드할 때 데이터 원본이 생성되도록 Dockerfile에 다음을 추가합니다.Add the following to your Dockerfile so the data source is created when you build your Docker image

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
    sleep 30 && \
    <WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
    sleep 30
    
  6. DATABASE_CONNECTION_URL은 각 데이터베이스 서버마다 다르고 Azure Portal의 값과 다르므로 무엇을 사용할지 확인합니다.Determine the DATABASE_CONNECTION_URL to use as they are different for each database server, and different than the values on the Azure portal. 여기에 표시된 URL 형식은 WildFly에서 사용해야 합니다.The URL formats shown here are required for use by WildFly:

    PostgreSQLPostgreSQL

    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true
    

    MySQLMySQL

    jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT
    

    SQL ServerSQL Server

    jdbc:sqlserver://<database server name>:1433;database=<database name>;user=<admin name>;password=<admin password>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;
    
  7. 이후 단계에서 배포 YAML을 만들 때는 환경 변수 DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAMEDATABASE_SERVER_ADMIN_PASSWORD를 적절한 값과 함께 전달해야 합니다.When creating your deployment YAML at a later stage you will need to pass the following environment variables, DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME and DATABASE_SERVER_ADMIN_PASSWORD with the appropriate values.

WildFly를 사용하여 데이터베이스 연결을 구성하는 방법에 대한 자세한 내용은 PostgreSQL, MySQL 또는 SQL Server를 참조하세요.For more info on configuring database connectivity with WildFly, see PostgreSQL, MySQL, or SQL Server.

JNDI 리소스 설정Set up JNDI resources

WildFly에 구성해야 하는 각 JNDI 리소스를 설정하려면 일반적으로 다음 단계를 사용합니다.To set up each JNDI resource you need to configure on WildFly, you will generally use the following steps:

  1. 필요한 JAR 파일을 다운로드하여 Docker 이미지에 복사합니다.Download the necessary JAR files and copy them into the Docker image.
  2. 이러한 JAR 파일을 참조하는 WildFly module.xml 파일을 만듭니다.Create a WildFly module.xml file referencing those JAR files.
  3. 특정 JNDI 리소스에 필요한 구성을 만듭니다.Create any configuration needed by the specific JNDI resource.
  4. Docker 빌드 중에 JNDI 리소스를 등록하는 데 사용할 JBoss CLI 스크립트를 만듭니다.Create JBoss CLI script to be used during Docker build to register the JNDI resource.
  5. Dockerfile에 모든 항목을 추가합니다.Add everything to Dockerfile.
  6. 배포 YAML에서 적절한 환경 변수를 전달합니다.Pass the appropriate environment variables in your deployment YAML.

아래 예제에서는 Azure Service Bus에 대한 JMS 연결을 위한 JNDI 리소스를 만드는 데 필요한 단계를 보여줍니다.The example below shows the steps needed to create the JNDI resource for JMS connectivity to Azure Service Bus.

  1. Apache Qpid JMS 공급자를 다운로드합니다.Download the Apache Qpid JMS provider

    다운로드한 보관 파일의 압축을 풀어 드라이버 .jar 파일을 가져옵니다.Unpack the downloaded archive to get the .jar files.

  2. module.xml 같은 이름으로 파일을 만들고 /opt/servicebus에 다음 태그를 추가합니다.Create a file with a name like module.xml and add the following markup in /opt/servicebus. JAR 파일의 버전 번호가 이전 단계의 JAR 파일 이름과 일치하는지 확인합니다.Make sure the version numbers of the JAR files align with the names of the JAR files of the previous step.

    <?xml version="1.0" ?>
    <module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
     <resources>
      <resource-root path="proton-j-0.31.0.jar"/>
      <resource-root path="qpid-jms-client-0.40.0.jar"/>
      <resource-root path="slf4j-log4j12-1.7.25.jar"/>
      <resource-root path="slf4j-api-1.7.25.jar"/>
      <resource-root path="log4j-1.2.17.jar"/>
      <resource-root path="netty-buffer-4.1.32.Final.jar" />
      <resource-root path="netty-codec-4.1.32.Final.jar" />
      <resource-root path="netty-codec-http-4.1.32.Final.jar" />
      <resource-root path="netty-common-4.1.32.Final.jar" />
      <resource-root path="netty-handler-4.1.32.Final.jar" />
      <resource-root path="netty-resolver-4.1.32.Final.jar" />
      <resource-root path="netty-transport-4.1.32.Final.jar" />
      <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
      <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
      <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
      <resource-root path="qpid-jms-discovery-0.40.0.jar" />
     </resources>
     <dependencies>
      <module name="javax.api"/>
      <module name="javax.jms.api"/>
     </dependencies>
    </module>
    
  3. /opt/servicebusjndi.properties 파일을 만듭니다.Create a jndi.properties file in /opt/servicebus.

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
    queue.${MDB_QUEUE}=${SB_QUEUE}
    topic.${MDB_TOPIC}=${SB_TOPIC}
    
  4. servicebus-commands.cli 같은 이름으로 파일을 만들고 다음 코드를 추가합니다.Create a file with a name like servicebus-commands.cli and add the following code.

    batch
    /subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
    /system-property=property.mymdb.queue:add(value=myqueue)
    /system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
    /subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
    /subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
    /subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
    /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
    /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
    /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
    /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
    /subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
    run-batch
    reload
    shutdown
    
  5. Docker 이미지를 빌드할 때 JNDI 리소스가 생성되도록 Dockerfile에 다음을 추가합니다.Add the following to your Dockerfile so the JNDI resource is created when you build your Docker image

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
    sleep 30 && \
    <WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
    sleep 30
    
  6. 이후 단계에서 배포 YAML을 만들 때는 환경 변수 MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPICSB_TOPIC를 적절한 값과 함께 전달해야 합니다.When creating your deployment YAML at a later stage you will need to pass the following environment variables, MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE and SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC and SB_TOPIC with the appropriate values.

WildFly 구성 검토Review WildFly configuration

이전 지침에서 다루지 않은 추가 마이그레이션 전 단계를 설명하는 WildFly 관리자 가이드를 검토합니다.Review the WildFly Admin Guide to cover any additional pre-migration steps not covered by the previous guidance.

Docker 이미지를 빌드하고 Azure Container Registry로 푸시Build and push the Docker image to Azure Container Registry

Dockerfile을 만든 후 Docker 이미지를 빌드하고 Azure Container Registry에 게시해야 합니다.After you've created the Dockerfile, you'll need to build the Docker image and publish it to your Azure container registry.

WildFly 컨테이너 빠른 시작 GitHub 리포지토리를 사용한 경우 이미지를 빌드하고 Azure Container Registry로 게시하는 과정은 다음 3개 명령을 호출하는 것과 같습니다.If you used our WildFly Container Quickstart GitHub repo, the process of building and pushing your image to your Azure container registry would be the equivalent of invoking the following three commands.

이 예제에서 MY_ACR 환경 변수는 Azure Container Rregistry의 이름을 포함하고 MY_APP_NAME 변수는 Azure Container Rregistry에서 사용하려는 웹 애플리케이션의 이름을 포함합니다.In these examples, the MY_ACR environment variable holds the name of your Azure container registry and the MY_APP_NAME variable holds the name of the web application you want to use on your Azure container registry.

WAR 파일을 빌드합니다.Build the WAR file:

mvn package

Azure Container Registry에 로그인합니다.Log into your Azure container registry:

az acr login -n ${MY_ACR}

이미지를 빌드하고 푸시합니다.Build and push the image:

az acr build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME} -f src/main/docker/Dockerfile .

또는 다음 명령과 같이 Docker CLI를 사용하여 먼저 이미지를 로컬로 빌드하고 테스트할 수 있습니다.Alternatively, you can use Docker CLI to first build and test the image locally, as shown in the following commands. 이 방법을 사용하면 ACR에 처음 배포하기 전에 이미지를 테스트하고 구체화하는 작업을 간소화할 수 있습니다.This approach can simplify testing and refining the image before initial deployment to ACR. 그러나 Docker CLI를 설치하고 Docker 데몬이 실행 중인지 확인해야 합니다.However, it requires you to install the Docker CLI and ensure the Docker daemon is running.

이미지를 빌드합니다.Build the image:

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

로컬에서 이미지를 실행합니다.Run the image locally:

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

이제 http://localhost:8080에서 애플리케이션에 액세스할 수 있습니다.Your can now access your application at http://localhost:8080.

Azure Container Registry에 로그인합니다.Log into your Azure container registry:

az acr login -n ${MY_ACR}

Azure Container Registry로 이미지를 푸시합니다.Push the image to your Azure container registry:

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Azure에서 컨테이너 이미지를 빌드하고 저장하는 방법에 대한 자세한 내용은 Azure Container Registry를 사용하여 컨테이너 이미지 빌드 및 저장 학습 모듈을 참조하세요.For more in-depth information on building and storing container images in Azure, see the Learn module Build and store container images with Azure Container Registry.

공용 IP 주소 프로비저닝Provision a public IP address

내부 또는 가상 네트워크 외부에서 애플리케이션에 액세스할 수 있는 경우 공용 정적 IP 주소가 필요합니다.If your application is to be accessible from outside your internal or virtual network(s), you'll need a public static IP address. 다음 예제와 같이 클러스터의 노드 리소스 그룹 내에서 이 IP 주소를 프로비저닝해야 합니다.You should provision this IP address inside your cluster's node resource group, as shown in the following example:

nodeResourceGroup=$(az aks show -g $resourceGroup -n $aksName --query 'nodeResourceGroup' -o tsv)
publicIp=$(az network public-ip create -g $nodeResourceGroup -n applicationIp --sku Standard --allocation-method Static --query 'publicIp.ipAddress' -o tsv)
echo "Your public IP address is ${publicIp}."

AKS에 배포Deploy to AKS

Kubernetes YAML 파일을 만들고 적용합니다.Create and apply your Kubernetes YAML file(s). 자세한 내용은 빠른 시작: Azure CLI를 사용하여 Azure Kubernetes Service 클러스터 배포를 참조하세요.For more information, see Quickstart: Deploy an Azure Kubernetes Service cluster using the Azure CLI. 외부 부하 분산 장치를 만드는 경우(애플리케이션 또는 수신 컨트롤러에 있는지 여부에 관계없이) 이전 섹션에서 프로비저닝된 IP 주소를 LoadBalancerIP로 제공해야 합니다.If you're creating an external load balancer (whether for your application or for an ingress controller), be sure to provide the IP address provisioned in the previous section as the LoadBalancerIP.

표면화된 매개 변수를 환경 변수로 포함합니다.Include externalized parameters as environment variables. 자세한 내용은 컨테이너의 환경 변수 정의를 참조하세요.For more information, see Define Environment Variables for a Container. 암호, API 키 및 JDBC 연결 문자열과 같은 비밀은 포함하지 않습니다.Don't include secrets (such as passwords, API keys, and JDBC connection strings). 이러한 내용은 다음 섹션에 설명되어 있습니다.These are covered in the following section.

배포 YAML을 만들 때는 컨테이너의 크기가 적절히 조정되도록 메모리 및 CPU 설정을 포함해야 합니다.Be sure to include memory and CPU settings when creating your deployment YAML so your containers are properly sized.

영구 스토리지 구성Configure persistent storage

애플리케이션에 비휘발성 스토리지가 필요한 경우 하나 이상의 영구 볼륨을 구성합니다.If your application requires non-volatile storage, configure one or more Persistent Volumes.

예약된 작업 마이그레이션Migrate scheduled jobs

AKS 클러스터에서 예약된 작업을 실행하려면 필요에 따라 Kubernetes CronJob을 정의합니다.To execute scheduled jobs on your AKS cluster, define Kubernetes CronJobs as needed. 자세한 내용은 CronJob을 사용하여 자동화된 작업 실행을 참조하세요.For more information, see Running Automated Tasks with a CronJob.

마이그레이션 후 작업Post-migration

이제 애플리케이션을 Azure Kubernetes Service로 마이그레이션했으므로 예상대로 작동하는지 확인해야 합니다.Now that you've migrated your application to Azure Kubernetes Service, you should verify that it works as you expect. 이 작업이 완료되면 애플리케이션을 클라우드 네이티브로 만들 수 있는 몇 가지 추천 사항이 있습니다.After you've done that, we have some recommendations for you that can make your application more cloud-native.

권장 사항Recommendations