다음을 통해 공유


AKS(Azure Kubernetes Service) 클러스터에서 WebLogic Server를 사용하여 Java 애플리케이션 배포

이 문서에서는 다음을 수행하는 방법을 보여줍니다.

  • Oracle WLS(WebLogic Server)에서 Java 애플리케이션을 실행합니다.
  • Azure Marketplace 제품을 사용하여 AKS에서 WebLogic Server 클러스터를 구축합니다.
  • WDT(WebLogic Deploy Tooling) 모델을 포함하는 애플리케이션 Docker 이미지를 빌드합니다.
  • Microsoft Azure SQL에 연결하여 AKS의 WebLogic Server 클러스터에 컨테이너화된 애플리케이션을 배포합니다.

이 문서에서는 WebLogic Server용 Azure Marketplace 제품을 사용하여 AKS로의 전환을 가속화합니다. 이 제품은 다음 리소스를 비롯한 여러 Azure 리소스를 자동으로 프로비전합니다.

  • Azure Container Registry 인스턴스
  • AKS 클러스터
  • Azure AGIC(App Gateway 수신 컨트롤러) 인스턴스
  • WebLogic Kubernetes 연산자
  • WebLogic 런타임을 포함한 컨테이너 이미지
  • 애플리케이션이 없는 WebLogic Server 클러스터

그런 다음 이 문서에서는 WebLogic Server 클러스터를 업데이트하기 위한 이미지 빌드를 소개합니다. 이미지는 애플리케이션과 WDT 모델을 제공합니다.

AKS에 WebLogic을 배포하는 데 덜 자동화된 방식을 선호하는 경우 Oracle의 Azure Kubernetes Service 공식 설명서에 포함된 단계별 지침을 참조하세요.

피드백을 제공하거나 AKS 솔루션에서 WebLogic을 개발하는 엔지니어링 팀과 함께 마이그레이션 시나리오에 대해 긴밀히 작업하려는 경우 WebLogic 마이그레이션에 대한 이 간단한 설문 조사를 작성하고 연락처 정보를 포함하세요. 프로그램 관리자, 설계자 및 엔지니어 팀이 즉시 연락을 취하여 긴밀한 공동 작업을 시작합니다.

필수 조건

  • Azure를 구독하고 있지 않다면 시작하기 전에 Azure 체험 계정을 만듭니다.
  • 로그인하고 이 문서를 완료하는 데 사용하는 Azure ID에 현재 구독의 소유자 역할 또는 현재 구독의 기여자사용자 액세스 관리자 역할이 있는지 확인합니다. Azure 역할의 개요는 Azure RBAC(역할 기반 액세스 제어)란?을 참조하세요. AKS에서 WLS에 필요한 특정 역할에 대한 자세한 내용은 Azure 기본 제공 역할을 참조하세요.
  • Oracle SSO(Single Sign-On) 계정의 자격 증명이 있어야 합니다. 계정을 만들려면 Oracle 계정 만들기를 참조하세요.
  • WebLogic Server 사용 조건에 동의합니다.
    • Oracle Container Registry를 방문하여 로그인합니다.
    • 지원 자격이 있는 경우 미들웨어를 선택한 다음, weblogic_cpu를 검색하여 선택합니다.
    • Oracle 지원 자격이 없는 경우 미들웨어를 선택한 다음, weblogic을 검색하여 선택합니다.
    • 사용권 계약에 동의합니다.

    참고 항목

    프로덕션으로 전환하기 전에 Oracle에서 지원 자격을 얻으세요. 이렇게 하지 않으면 중요한 보안 결함에 대한 패치가 적용되지 않은 안전하지 않은 이미지를 실행하게 됩니다. Oracle의 중요한 패치 업데이트에 대한 자세한 내용은 Oracle의 중요 패치 업데이트, 보안 경고 및 공지를 참조하세요.

  • Unix 계열 운영 체제(예: Ubuntu, Azure Linux 또는 macOS, Linux용 Windows 하위 시스템)가 설치된 로컬 컴퓨터를 준비합니다.
    • Azure CLI az --version을 사용하여 az가 작동하는지 테스트합니다. 이 문서는 버전 2.55.1로 테스트되었습니다.
    • kubectl. kubectl version을 사용하여 kubectl이 작동하는지 테스트합니다. 이 문서는 버전 v1.21.2로 테스트되었습니다.
    • JDK(Java Development Kit)입니다. 이 문서에서는 Microsoft Build of OpenJDK 11을 설치하도록 지시합니다. 명령을 실행하는 셸에서 JAVA_HOME 환경 변수가 올바르게 설정되었는지 확인합니다.
    • Maven 3.5.0 이상.
    • zip/unzip 유틸리티가 설치되어 있는지 확인합니다. zip/unzip -v를 사용하여 zip/unzip이 작동하는지 테스트합니다.

Azure SQL Database 만들기

이 섹션에서는 관리 ID 연결을 사용하도록 설정된 Microsoft Entra 인증을 사용하여 Azure SQL Database를 만듭니다.

리소스 그룹 만들기

az group create를 사용하여 리소스 그룹을 만듭니다. 리소스 그룹은 구독 내에서 고유해야 하므로 고유한 이름을 선택합니다. 고유한 이름을 갖는 쉬운 방법은 이니셜, 오늘 날짜 및 일부 식별자의 조합을 사용하는 것입니다. 예들 들어 abc1228rg입니다. 이 예제에서는 위치에 명명된 abc1228rg eastus 리소스 그룹을 만듭니다.

export RESOURCE_GROUP_NAME="abc1228rg"
az group create \
    --name ${RESOURCE_GROUP_NAME} \
    --location eastus

데이터베이스 서버 및 데이터베이스 만들기

az sql server create 명령을 사용하여 서버를 만듭니다. 이 예제에서는 관리자 사용자 azureuser 및 관리자 암호를 사용하여 명명된 myazuresql20130213 서버를 만듭니다. <your-password>를 암호로 바꿉니다. 자세한 내용은 빠른 시작: 단일 데이터베이스 만들기 - Azure SQL Database를 참조 하세요.

참고 항목

여기서 사용자 이름 및 암호를 사용하더라도 이러한 자격 증명은 데이터베이스 외부에 노출되지 않습니다. 애플리케이션 계층과 데이터베이스 간의 연결은 관리 ID로 보호됩니다.

export AZURESQL_SERVER_NAME="myazuresql20130213"
export AZURESQL_ADMIN_USER="azureuser"
export AZURESQL_ADMIN_PASSWORD="<your-password>"
export DATABASE_NAME="mysingledatabase20230213"
az sql server create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $AZURESQL_SERVER_NAME \
    --location westus \
    --admin-user $AZURESQL_ADMIN_USER \
    --admin-password $AZURESQL_ADMIN_PASSWORD

서버리스 컴퓨팅 계층에서 az sql db create 명령을 사용하여 데이터베이스를 만듭니다.

az sql db create \
    --resource-group $RESOURCE_GROUP_NAME \
    --server $AZURESQL_SERVER_NAME \
    --name $DATABASE_NAME \
    --sample-name AdventureWorksLT \
    --edition GeneralPurpose \
    --compute-model Serverless \
    --family Gen5 \
    --capacity 2

Microsoft Entra 관리자 구성

Azure SQL Server가 관리 ID와 상호 작용하는 방법에 대한 자세한 내용은 Microsoft Entra 인증을 사용하여 연결을 참조하세요.

다음 단계를 사용하여 Azure Portal에서 Azure SQL Server로 Microsoft Entra 관리자 계정을 구성합니다.

  1. Azure Portal에서 Azure SQL Server 인스턴스 myazuresql20130213를 엽니다.
  2. 설정을 선택한 다음, Microsoft Entra ID를 선택합니다. Microsoft Entra ID 페이지에서 관리자 설정을 선택합니다.
  3. 관리자 추가 페이지에서 사용자를 검색하고 관리자가 될 사용자 또는 그룹을 선택한 다음 선택을 선택합니다.
  4. Microsoft Entra ID 페이지의 맨 위에서 저장을 선택합니다. Microsoft Entra 사용자 및 그룹의 경우 관리자 이름 옆에 개체 ID가 표시됩니다.
  5. 관리자를 변경하는 데는 몇 분이 걸릴 수 있습니다. 그런 다음 새 관리자가 Microsoft Entra ID 상자에 표시됩니다.

사용자 할당 관리 ID 만들기

다음으로, Azure CLI에서 az identity create 명령을 사용하여 구독에 ID를 만듭니 다. 이 관리 ID를 사용하여 데이터베이스에 연결합니다.

az identity create \
    --resource-group ${RESOURCE_GROUP_NAME} \
    --name myManagedIdentity

관리 ID에 대한 데이터베이스 사용자 만들기

이제 Microsoft Entra 관리자 사용자로 Azure Portal에서 Azure SQL 데이터베이스에 연결하고 관리 ID에 대한 사용자를 만듭니다.

먼저 다음 단계에 표시된 대로 포털에서 Azure SQL Server에 액세스하는 방화벽 규칙을 만듭니다.

  1. Azure Portal에서 Azure SQL Server 인스턴스 myazuresql20130213를 엽니다.
  2. 보안을 선택한 다음 네트워킹을 선택합니다.
  3. 방화벽 규칙에서 클라이언트 IPV4 IP 주소 추가를 선택합니다.
  4. 예외에서 Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용을 선택합니다.
  5. 저장을 선택합니다.

방화벽 규칙을 만든 후 포털에서 Azure SQL 서버에 액세스할 수 있습니다. 다음 단계를 사용하여 데이터베이스 사용자를 만듭니다.

  1. 설정을 선택한 다음, SQL 데이터베이스를 선택합니다. mysingledatabase20230213를 선택합니다.

  2. 쿼리 편집기를 선택합니다. SQL Database 쿼리 편집기 시작 페이지의 Active Directory 인증에서 다음과 같은 Logged in as user@contoso.com메시지를 찾습니다.

  3. 계속을 선택합니다. 여기서 AD 관리자 계정 이름은 다음과 user 같습니다user@contoso.com.

  4. 로그인한 후 쿼리 1 편집기에서 다음 명령을 실행하여 관리 ID에 대한 데이터베이스 사용자를 만듭니다myManagedIdentity.

    CREATE USER "myManagedIdentity" FROM EXTERNAL PROVIDER
    ALTER ROLE db_datareader ADD MEMBER "myManagedIdentity";
    ALTER ROLE db_datawriter ADD MEMBER "myManagedIdentity";
    ALTER ROLE db_ddladmin ADD MEMBER "myManagedIdentity";
    GO
    
  5. 쿼리 1 편집기에서 실행을 선택하여 SQL 명령을 실행합니다.

  6. 명령이 성공적으로 완료되면 다음과 같은 Query succeeded: Affected rows: 0메시지를 찾을 수 있습니다.

다음 명령을 사용하여 다음 섹션에서 사용하는 연결 문자열 가져옵니다.

export CONNECTION_STRING="jdbc:sqlserver://${AZURESQL_SERVER_NAME}.database.windows.net:1433;database=${DATABASE_NAME};encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;"
echo ${CONNECTION_STRING}

샘플 애플리케이션에 대한 스키마 만들기

새 쿼리를 선택한 다음 쿼리 편집기에서 다음 쿼리를 실행합니다.

CREATE TABLE COFFEE (ID NUMERIC(19) NOT NULL, NAME VARCHAR(255) NULL, PRICE FLOAT(32) NULL, PRIMARY KEY (ID));
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT NUMERIC(28) NULL, PRIMARY KEY (SEQ_NAME));
INSERT INTO SEQUENCE VALUES ('SEQ_GEN',0);

성공적으로 실행되면 쿼리 성공: 영향을 받은 행 수: 1 메시지가 표시됩니다. 이 메시지가 표시되지 않으면 문제를 해결한 후 계속 진행합니다.

AKS 제품에 WLS를 계속 배포할 수 있습니다.

AKS에 WebLogic Server 배포

다음 단계를 사용하여 AKS 제품에서 WebLogic Server를 찾고 기본 사항 창을 작성 합니다 .

  1. Azure Portal 위쪽의 검색 창에서 weblogic을 입력합니다. 자동 제안된 검색 결과의 Marketplace 섹션에서 WebLogic Server on AKS를 선택합니다.

    검색 결과에 WebLogic Server를 표시하는 Azure Portal의 스크린샷.

    WebLogic Server on AKS 제품으로 직접 이동할 수도 있습니다.

  2. 제품 페이지에서 만들기를 선택합니다.

  3. 기본 사항 창에서 구독 필드에 표시된 값이 Azure에 로그인하는 데 사용한 값과 동일한지 확인합니다. 구독에 대한 필수 구성 요소 섹션에 나열된 역할이 있는지 확인합니다.

    WebLogic Server on AKS를 보여 주는 Azure Portal의 스크린샷

  4. 빈 리소스 그룹에 제품을 배포해야 합니다. 리소스 그룹 필드에서 새로 만들기를 선택하고 리소스 그룹의 이름을 입력합니다. 리소스 그룹은 구독 내에서 고유해야 하므로 고유한 이름을 선택합니다. 이름이 고유하도록 하는 쉬운 방법은 이니셜, 오늘 날짜, 일부 식별자의 조합을 사용하는 것입니다(예: ejb0723wls).

  5. 인스턴스 세부 정보에서 배포 지역을 선택합니다. AKS를 사용할 수 있는 Azure 지역 목록은 AKS 지역 가용성을 참조하세요.

  6. WebLogic 자격 증명에서 WebLogic 관리자 사용자 이름의 기본값을 그대로 둡니다.

  7. WebLogic 관리자 암호wlsAksCluster2022를 입력합니다. 확인 및 WebLogic 모델 암호화용 암호 필드에 동일한 값을 사용합니다.

  8. 다음을 선택합니다.

다음 단계를 사용하여 배포 프로세스를 시작합니다.

  1. Oracle SSO(Single Sign-On) 계정 제공 레이블이 지정된 섹션으로 스크롤합니다. 사전 조건의 Oracle SSO 자격 증명을 입력합니다.

    구성한 SSO 창을 보여 주는 Azure Portal의 스크린샷

  2. 정보 상자에서 계속 진행하기 전에 Oracle 표준 약관 및 제한 사항에 동의해야 합니다.로 시작하는 단계를 기록해 둡니다.

  3. Oracle SSO 계정에 Oracle 지원 자격이 있는지 여부에 따라 WebLogic Server 이미지 유형 선택에 대해 적절한 옵션을 선택합니다. 계정에 지원 자격이 있는 경우 패치된 WebLogic Server 이미지를 선택합니다. 그렇지 않으면 일반 WebLogic Server 이미지를 선택합니다.

  4. WebLogic Server의 원하는 조합 선택...의 값을 기본값 상태로 둡니다. 다양한 WebLogic Server, JDK 및 OS 버전 중에서 선택할 수 있습니다.

  5. 애플리케이션 섹션의 애플리케이션 배포? 옆에서 아니요를 선택합니다.

다음 단계에서는 WebLogic Server 관리 콘솔 및 샘플 앱이 Application Gateway 수신 추가 기능이 기본 제공된 상태로 공용 인터넷에 공개되도록 합니다. 자세한 내용은 Application Gateway 수신 컨트롤러란?을 참조하세요.

  1. 다음을 선택하여 TLS/SSL 창을 확인합니다.

  2. 다음을 선택하여 부하 분산 창을 확인합니다.

  3. 부하 분산 옵션 옆에 있는 Application Gateway 수신 컨트롤러를 선택합니다.

    Azure Kubernetes Service에서 Oracle WebLogic Server 만들기 페이지의 가능한 가장 간단한 부하 분산 장치 구성을 보여 주는 Azure Portal의 스크린샷

  4. Application Gateway 수신 컨트롤러 아래에 가상 네트워크서브넷에 대한 기본값으로 미리 채워진 모든 필드가 표시됩니다. 기본값을 그대로 둡니다.

  5. 관리 콘솔에 대한 수신 만들기에서 를 선택합니다.

    Azure Kubernetes Service에서 Oracle WebLogic Server 만들기 페이지의 Application Gateway 수신 컨트롤러 구성을 보여 주는 Azure Portal의 스크린샷

  6. DNS 창을 보려면 [다음]을 선택합니다.

  7. 다음을 선택하여 데이터베이스 창을 확인합니다.

관리 ID를 사용하여 데이터베이스 연결을 구성하려면 다음 단계를 사용합니다.

  1. 데이터베이스에 연결하려면 [예]를 선택합니다.
  2. 연결 설정에서 데이터베이스 유형 선택에 대해 드롭다운 메뉴를 열고 Microsoft SQL Server(암호 없는 연결 지원)를 선택합니다.
  3. JNDI 이름의 경우 jdbc/WebLogicCafeDB를 입력합니다.
  4. DataSource 연결 문자열의 경우 마지막 섹션에서 얻은 연결 문자열 입력합니다.
  5. 암호 없는 데이터 원본 연결 사용을 선택합니다.
  6. 사용자가 할당한 관리 ID의 경우 이전 단계에서 만든 관리 ID를 선택합니다. 이 예제에서는 해당 이름이 .입니다 myManagedIdentity.
  7. 추가를 선택합니다.

연결 설정 섹션은 다음 스크린샷과 같습니다.

Azure Kubernetes Service에서 Oracle WebLogic Server 만들기 페이지의 데이터베이스 탭을 보여 주는 Azure Portal의 스크린샷.

다음 단계를 사용하여 배포를 완료합니다.

  1. 검토 + 만들기를 선택합니다. 유효성 검사가 실패하지 않는지 확인합니다. 실패하면 유효성 검사 문제를 해결한 다음, 검토 + 만들기를 선택합니다.
  2. 만들기를 실행합니다.
  3. 배포 진행 중 페이지에서 배포 진행률을 추적합니다.

선택한 지역의 네트워크 조건 및 기타 작업에 따라 배포를 완료하는 데 최대 50분이 걸릴 수 있습니다.

참고 항목

조직에서 공용 IP가 허용되지 않는 회사 가상 네트워크 내에서 워크로드를 배포하도록 요구하는 경우 내부 Load Balancer 서비스를 선택할 수 있습니다. 내부 Load Balancer 서비스를 구성하려면 부하 분산 탭에서 다음 단계를 사용합니다.

  1. 부하 분산 옵션의 경우 표준 Load Balancer 서비스를 선택합니다.

  2. 내부 부하 분산 장치 사용을 선택합니다.

  3. 다음 행을 테이블에 추가합니다.

    서비스 이름 접두사 대상 포트
    wls-admin-internal admin-server 7001
    wls-cluster-internal cluster-1 8001

부하 분산 탭은 다음 스크린샷과 같습니다.

Azure Kubernetes Service에서 Oracle WebLogic Server 만들기 페이지의 부하 분산 탭을 보여 주는 Azure Portal의 스크린샷

배포 후에는 출력에서 관리 서버 및 클러스터의 액세스 URL, 레이블이 지정된 adminConsoleExternalUrl 및 clusterExternalUrl을 찾을 수 있습니다.

배포 출력 검사

이 섹션의 단계를 사용하여 배포가 성공적으로 완료되었는지 확인합니다.

배포 진행 중 페이지에서 이동한 경우 다음 단계에서는 해당 페이지로 돌아가는 방법을 보여 줍니다. 배포가 완료됨이라는 페이지가 계속 표시되면 다음 스크린샷 이후에 표시된 5단계로 건너뛸 수 있습니다.

  1. Azure Portal 페이지의 모서리에서 햄버거 메뉴, 리소스 그룹을 차례로 선택합니다.

  2. 모든 필드에 대해 필터링 텍스트가 있는 상자에 이전에 만든 리소스 그룹의 처음 몇 글자를 입력합니다. 권장 규칙을 따른 경우 이니셜을 입력한 다음 적절한 리소스 그룹을 선택합니다.

  3. 탐색 창의 설정 섹션에서 배포를 선택합니다. 이 리소스 그룹에 대한 배포 순서가 지정된 목록이 표시되며, 가장 최근 배포가 먼저 표시됩니다.

  4. 이 목록에서 가장 오래된 항목으로 스크롤합니다. 이 항목은 이전 섹션에서 시작한 배포에 해당합니다. 다음 스크린샷과 같이 가장 오래된 배포를 선택합니다.

    리소스 그룹 배포 목록을 보여 주는 Azure Portal의 스크린샷

  5. 탐색 창에서 출력을 선택합니다. 이 목록에는 배포의 출력 값이 표시됩니다. 출력에 유용한 정보가 포함되어 있습니다.

  6. adminConsoleExternalUrl 값은 이 AKS 클러스터의 WebLogic Server 관리 콘솔에 대한 정규화된 공용 인터넷 표시 링크입니다. 필드 값 옆의 복사 아이콘을 선택하여 링크를 클립보드에 복사합니다. 나중에 사용할 수 있도록 이 값을 따로 저장합니다.

  7. clusterExternalUrl 값은 이 AKS 클러스터의 WebLogic Server에 배포된 샘플 앱에 대한 정규화된 공용 인터넷 표시 링크입니다. 필드 값 옆의 복사 아이콘을 선택하여 링크를 클립보드에 복사합니다. 나중에 사용할 수 있도록 이 값을 따로 저장합니다.

  8. shellCmdtoOutputWlsImageModelYaml 값은 컨테이너 이미지를 빌드하는 데 사용되는 WDT 모델의 base64 문자열입니다. 나중에 사용할 수 있도록 이 값을 따로 저장합니다.

  9. shellCmdtoOutputWlsImageProperties 값은 컨테이너 이미지를 빌드하는 데 사용되는 WDT 모델 속성의 base64 문자열입니다. 나중에 사용할 수 있도록 이 값을 따로 저장합니다.

  10. shellCmdtoConnectAks 값은 이 특정 AKS 클러스터에 연결하기 위한 Azure CLI 명령입니다.

출력의 다른 값은 이 문서의 범위를 벗어나지만 AKS의 WebLogic 사용자 가이드에 자세히 설명되어 있습니다.

응용 프로그램 예제 구성 및 배포

이 제품은 이미지의 모델을 통해 WebLogic Server 클러스터를 프로비전합니다. 현재, WebLogic Server 클러스터에는 배포된 애플리케이션이 없습니다.

이 섹션에서는 보조 이미지를 통해 샘플 애플리케이션을 배포하여 WebLogic Server 클러스터를 업데이트합니다.

애플리케이션 체크 아웃

이 섹션에서는 이 가이드를 위해 샘플 코드를 복제합니다. 이 샘플은 GitHub에서 javaee/weblogic-cafe/ 폴더의 weblogic-on-azure 리포지토리에 있습니다. 다음은 애플리케이션의 파일 구조입니다.

weblogic-cafe
├── pom.xml
└── src
    └── main
        ├── java
        │   └── cafe
        │       ├── model
        │       │   ├── CafeRepository.java
        │       │   └── entity
        │       │       └── Coffee.java
        │       └── web
        │           ├── rest
        │           │   └── CafeResource.java
        │           └── view
        │               └── Cafe.java
        ├── resources
        │   ├── META-INF
        │   │   └── persistence.xml
        │   └── cafe
        │       └── web
        │           ├── messages.properties
        │           └── messages_es.properties
        └── webapp
            ├── WEB-INF
            │   ├── beans.xml
            │   ├── faces-config.xml
            │   └── web.xml
            ├── index.xhtml
            └── resources
                └── components
                    └── inputPrice.xhtml

다음 명령을 사용하여 리포지토리를 복제합니다.

# cd <parent-directory-to-check-out-sample-code>
export BASE_DIR=$PWD

git clone --single-branch https://github.com/microsoft/weblogic-on-azure.git --branch 20240201 $BASE_DIR/weblogic-on-azure

"분리된 HEAD" 상태에 있다는 메시지가 표시되면 이 메시지를 무시해도 안전합니다. 이는 단지 태그를 체크 아웃했음을 의미합니다.

다음 명령을 사용하여 javaee/weblogic-cafe/를 빌드합니다.

mvn clean package --file $BASE_DIR/weblogic-on-azure/javaee/weblogic-cafe/pom.xml

패키지는 성공적으로 생성되고 $BASE_DIR/weblogic-on-azure/javaee/weblogic-café/target/weblogic-cafe.war에 포함되어 있습니다. 이 패키지가 표시되지 않으면 문제를 해결한 후 계속 진행합니다.

Azure Container Registry를 사용하여 보조 이미지 만들기

이 섹션의 단계에서는 보조 이미지 빌드 방법을 보여 줍니다. 이 이미지에는 다음 구성 요소가 포함됩니다.

  • 이미지의 모델 모델 파일
  • 애플리케이션
  • JDBC(Java Database Connectivity) 드라이버 보관 파일
  • WebLogic 배포 도구 설치

보조 이미지는 앱 및 구성을 포함하는 Docker 컨테이너 이미지입니다. WebLogic Kubernetes Operator는 보조 이미지를 WebLogic Server, JDK 및 운영 체제가 포함된 AKS 클러스터의 domain.spec.image에 결합합니다. 보조 이미지에 대한 자세한 내용은 Oracle 설명서의 보조 이미지를 참조하세요.

이 섹션에는 Azure CLI 및 kubectl이 설치된 Linux 터미널이 필요합니다.

이미지를 빌드하려면 다음 단계를 사용합니다.

  1. 다음 명령을 사용하여 모델 및 애플리케이션을 스테이징할 디렉터리를 만듭니다.

    mkdir -p ${BASE_DIR}/mystaging/models
    cd ${BASE_DIR}/mystaging/models
    
  2. 배포 출력에서 저장한 shellCmdtoOutputWlsImageModelYaml 값을 복사하고, Bash 창에 붙여 넣고, 해당 명령을 실행합니다. 이 명령은 다음 예제와 비슷하게 표시됩니다.

    echo -e IyBDb3B5cmlna...Cgo= | base64 -d > model.yaml
    

    이 명령은 다음 예제와 유사한 내용이 포함된 ${BASE_DIR}/mystaging/models/model.yaml 파일을 생성합니다.

    # Copyright (c) 2020, 2021, Oracle and/or its affiliates.
    # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
    
    # Based on ./kubernetes/samples/scripts/create-weblogic-domain/model-in-image/model-images/model-in-image__WLS-v1/model.10.yaml
    # in https://github.com/oracle/weblogic-kubernetes-operator.
    
    domainInfo:
      AdminUserName: "@@SECRET:__weblogic-credentials__:username@@"
      AdminPassword: "@@SECRET:__weblogic-credentials__:password@@"
      ServerStartMode: "prod"
    
    topology:
      Name: "@@ENV:CUSTOM_DOMAIN_NAME@@"
      ProductionModeEnabled: true
      AdminServerName: "admin-server"
      Cluster:
        "cluster-1":
          DynamicServers:
            ServerTemplate: "cluster-1-template"
            ServerNamePrefix: "@@ENV:MANAGED_SERVER_PREFIX@@"
            DynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
            MaxDynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
            MinDynamicClusterSize: "0"
            CalculatedListenPorts: false
      Server:
        "admin-server":
          ListenPort: 7001
      ServerTemplate:
        "cluster-1-template":
          Cluster: "cluster-1"
          ListenPort: 8001
      SecurityConfiguration:
        NodeManagerUsername: "@@SECRET:__weblogic-credentials__:username@@"
        NodeManagerPasswordEncrypted: "@@SECRET:__weblogic-credentials__:password@@"
    
    resources:
      SelfTuning:
        MinThreadsConstraint:
          SampleMinThreads:
            Target: "cluster-1"
            Count: 1
        MaxThreadsConstraint:
          SampleMaxThreads:
            Target: "cluster-1"
            Count: 10
        WorkManager:
          SampleWM:
            Target: "cluster-1"
            MinThreadsConstraint: "SampleMinThreads"
            MaxThreadsConstraint: "SampleMaxThreads"
    
  3. 비슷한 방식으로 shellCmdtoOutputWlsImageProperties 값을 복사하여 Bash 창에 붙여 넣고 해당 명령을 실행합니다. 이 명령은 다음 예제와 비슷하게 표시됩니다.

    echo -e IyBDb3B5cml...pFPTUK | base64 -d > model.properties
    

    이 명령은 다음 예제와 유사한 내용이 포함된 ${BASE_DIR}/mystaging/models/model.properties 파일을 생성합니다.

    # Copyright (c) 2021, Oracle Corporation and/or its affiliates.
    # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
    
    # Based on ./kubernetes/samples/scripts/create-weblogic-domain/model-in-image/model-images/model-in-image__WLS-v1/model.10.properties
    # in https://github.com/oracle/weblogic-kubernetes-operator.
    
    CLUSTER_SIZE=5
    
  4. 다음 단계를 따라 애플리케이션 모델 파일을 만듭니다.

    1. 다음 명령을 사용하여 weblogic-cafe.war을 복사하고 wlsdeploy/applications에 저장합니다.

      mkdir -p ${BASE_DIR}/mystaging/models/wlsdeploy/applications
      cp $BASE_DIR/weblogic-on-azure/javaee/weblogic-cafe/target/weblogic-cafe.war ${BASE_DIR}/mystaging/models/wlsdeploy/applications/weblogic-cafe.war
      
    2. 다음 명령을 사용하여 표시된 내용이 포함된 애플리케이션 모델 파일을 만듭니다. 모델 파일을 ${BASE_DIR}/mystaging/models/appmodel.yaml에 저장합니다.

      cat <<EOF >appmodel.yaml
      appDeployments:
        Application:
          weblogic-cafe:
            SourcePath: 'wlsdeploy/applications/weblogic-cafe.war'
            ModuleType: ear
            Target: 'cluster-1'
      EOF
      
  5. 다음 단계를 사용하여 데이터 원본 연결을 구성합니다.

    1. 다음 단계를 사용하여 Azure 관리 ID를 사용하여 데이터베이스 연결 수 있도록 하는 Microsoft SQL Server JDBC 드라이버 및 Azure ID 확장을 다운로드하고 설치합니다.

      1. 다음 명령을 사용하여 Microsoft SQL Server JDBC 드라이버를 다운로드하여 설치합니다 wlsdeploy/externalJDBCLibraries.

        export DRIVER_VERSION="10.2.1.jre8"
        export MSSQL_DRIVER_URL="https://repo.maven.apache.org/maven2/com/microsoft/sqlserver/mssql-jdbc/${DRIVER_VERSION}/mssql-jdbc-${DRIVER_VERSION}.jar"
        
        mkdir ${BASE_DIR}/mystaging/models/wlsdeploy/externalJDBCLibraries
        curl -m 120 -fL ${MSSQL_DRIVER_URL} -o ${BASE_DIR}/mystaging/models/wlsdeploy/externalJDBCLibraries/mssql-jdbc-${DRIVER_VERSION}.jar
        
      2. 다음 명령을 사용하여 Azure ID 확장을 설치합니다 wlsdeploy/classpathLibraries.

        curl -LO https://github.com/oracle/weblogic-azure/raw/refs/heads/main/weblogic-azure-aks/src/main/resources/azure-identity-extensions.xml
        
        mvn dependency:copy-dependencies -f azure-identity-extensions.xml
        
        mkdir -p ${BASE_DIR}/mystaging/models/wlsdeploy/classpathLibraries/azureLibraries
        mkdir ${BASE_DIR}/mystaging/models/wlsdeploy/classpathLibraries/jackson
        # fix JARs conflict issue in GA images, put jackson libraries to PRE_CLASSPATH to upgrade the existing libs.
        mv target/dependency/jackson-annotations-*.jar ${BASE_DIR}/mystaging/models/wlsdeploy/classpathLibraries/jackson/
        mv target/dependency/jackson-core-*.jar ${BASE_DIR}/mystaging/models/wlsdeploy/classpathLibraries/jackson/
        mv target/dependency/jackson-databind-*.jar ${BASE_DIR}/mystaging/models/wlsdeploy/classpathLibraries/jackson/
        mv target/dependency/jackson-dataformat-xml-*.jar ${BASE_DIR}/mystaging/models/wlsdeploy/classpathLibraries/jackson/
        # Thoes jars will be appended to CLASSPATH
        mv target/dependency/*.jar ${BASE_DIR}/mystaging/models/wlsdeploy/classpathLibraries/azureLibraries/
        
      3. 다음 명령을 사용하여 리소스를 정리합니다.

        rm target -f -r
        rm azure-identity-extensions.xml
        
    2. 이전에 저장한 shellCmdtoConnectAks 값을 복사하고 Bash 창에 붙여 넣은 다음, 해당 명령을 실행하여 AKS 클러스터에 연결합니다. 이 명령은 다음 예제와 비슷하게 표시됩니다.

      az account set --subscription <subscription>;
      az aks get-credentials \
          --resource-group <resource-group> \
          --name <name>
      

      다음 예제와 비슷한 내용이 출력됩니다. 이 출력이 표시되지 않으면 문제를 해결한 후 계속 진행합니다.

      Merged "<name>" as current context in /Users/<username>/.kube/config
      
    3. 데이터베이스 연결 모델을 내보내고 ${BASE_DIR}/mystaging/models/dbmodel.yaml에 저장합니다. 다음 단계에서는 ConfigMap sample-domain1-wdt-config-map에서 데이터베이스 구성 모델을 추출합니다. 이름은 제품 배포 중에 설정된 형식 <domain-uid>-wdt-config-map<domain-uid> 을 따릅니다. 기본값을 수정한 경우 사용자 고유의 도메인 UID로 바꿉다.

      1. 데이터 키는 db-secret-name.yaml>입니다<. 다음 명령을 사용하여 데이터베이스 비밀 이름을 검색합니다.

        export WLS_DOMAIN_UID=sample-domain1
        export WLS_DOMAIN_NS=${WLS_DOMAIN_UID}-ns
        export DB_K8S_SECRET_NAME=$(kubectl get secret -n ${WLS_DOMAIN_NS} | grep "ds-secret" | awk '{print $1}')
        
      2. 다음으로, 다음 명령을 사용하여 데이터베이스 모델을 추출합니다.

        kubectl get configmap sample-domain1-wdt-config-map -n ${WLS_DOMAIN_NS} -o=jsonpath="{['data']['${DB_K8S_SECRET_NAME}\.yaml']}" >${BASE_DIR}/mystaging/models/dbmodel.yaml
        
      3. 마지막으로 다음 명령을 사용하여 dbmodel.yaml콘텐츠를 확인합니다.

        cat ${BASE_DIR}/mystaging/models/dbmodel.yaml
        

        이 명령의 출력은 다음 구조와 유사해야 합니다.

        # Copyright (c) 2020, 2021, Oracle and/or its affiliates.
        # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
        
        resources:
          JDBCSystemResource:
            jdbc/WebLogicCafeDB:
              Target: 'cluster-1'
              JdbcResource:
              JDBCDataSourceParams:
                 JNDIName: [
                    jdbc/WebLogicCafeDB
                 ]
                 GlobalTransactionsProtocol: OnePhaseCommit
              JDBCDriverParams:
                 DriverName: com.microsoft.sqlserver.jdbc.SQLServerDriver
                 URL: '@@SECRET:ds-secret-sqlserver-1727147748:url@@'
                 PasswordEncrypted: '@@SECRET:ds-secret-sqlserver-1727147748:password@@'
                 Properties:
                    user:
                    Value: '@@SECRET:ds-secret-sqlserver-1727147748:user@@'
              JDBCConnectionPoolParams:
                    TestTableName: SQL SELECT 1
                    TestConnectionsOnReserve: true
        
  6. 다음 명령을 사용하여 보관 파일을 만든 다음 더 이상 필요하지 않은 wlsdeploy 폴더를 제거합니다.

    cd ${BASE_DIR}/mystaging/models
    zip -r archive.zip wlsdeploy
    
    rm -f -r wlsdeploy
    
  7. 다음 명령을 사용하여 스테이징 디렉터리에 WDT(WebLogic 배포 도구)를 다운로드하여 설치하고 UNIX 환경에서 사용되지 않는 weblogic-deploy/bin/*.cmd 파일을 제거합니다.

    cd ${BASE_DIR}/mystaging
    curl -m 120 -fL https://github.com/oracle/weblogic-deploy-tooling/releases/latest/download/weblogic-deploy.zip -o weblogic-deploy.zip
    
    unzip weblogic-deploy.zip -d .
    rm ./weblogic-deploy/bin/*.cmd
    
  8. 다음 명령을 사용하여 WDT 설치 관리자를 정리합니다.

    rm weblogic-deploy.zip
    
  9. 다음 명령을 사용하여 Docker 파일을 만듭니다.

    cd ${BASE_DIR}/mystaging
    cat <<EOF >Dockerfile
    FROM busybox
    ARG AUXILIARY_IMAGE_PATH=/auxiliary
    ARG USER=oracle
    ARG USERID=1000
    ARG GROUP=root
    ENV AUXILIARY_IMAGE_PATH=\${AUXILIARY_IMAGE_PATH}
    RUN adduser -D -u \${USERID} -G \$GROUP \$USER
    COPY --chown=\$USER:\$GROUP ./ \${AUXILIARY_IMAGE_PATH}/
    USER \$USER
    EOF
    
  10. 다음 예제와 같이 ${BASE_DIR}/mystaging/Dockerfile을 사용하여 az acr build 명령을 실행합니다.

    export ACR_NAME=<value-from-clipboard>
    export IMAGE="wlsaks-auxiliary-image:1.0"
    
  11. 다음 명령을 사용하여 준비 파일을 다시 확인합니다.

    cd ${BASE_DIR}/mystaging
    find -maxdepth 2 -type f -print
    

    이러한 명령은 다음 예제와 유사한 출력을 생성합니다.

    ./models/model.properties
    ./models/model.yaml
    ./models/appmodel.yaml
    ./models/dbmodel.yaml
    ./models/archive.zip
    ./Dockerfile
    ./weblogic-deploy/VERSION.txt
    ./weblogic-deploy/LICENSE.txt
    
  12. 다음 예제와 az acr build같이 이미지를 빌드합니다.

    az acr build -t ${IMAGE} --build-arg AUXILIARY_IMAGE_PATH=/auxiliary -r ${ACR_NAME} --platform linux/amd64 .
    

    이미지를 성공적으로 빌드하면 출력은 다음 예제와 유사하게 표시됩니다.

    ...
    Step 1/9 : FROM busybox
    latest: Pulling from library/busybox
    Digest: sha256:9ae97d36d26566ff84e8893c64a6dc4fe8ca6d1144bf5b87b2b85a32def253c7
    Status: Image is up to date for busybox:latest
    ---> 65ad0d468eb1
    Step 2/9 : ARG AUXILIARY_IMAGE_PATH=/auxiliary
    ---> Running in 1f8f4e82ccb6
    Removing intermediate container 1f8f4e82ccb6
    ---> 947fde618be9
    Step 3/9 : ARG USER=oracle
    ---> Running in dda021591e41
    Removing intermediate container dda021591e41
    ---> f43d84be4517
    Step 4/9 : ARG USERID=1000
    ---> Running in cac4df6dfd13
    Removing intermediate container cac4df6dfd13
    ---> e5513f426c74
    Step 5/9 : ARG GROUP=root
    ---> Running in 8fec1763270c
    Removing intermediate container 8fec1763270c
    ---> 9ef233dbe279
    Step 6/9 : ENV AUXILIARY_IMAGE_PATH=${AUXILIARY_IMAGE_PATH}
    ---> Running in b7754f58157a
    Removing intermediate container b7754f58157a
    ---> 4a26a97eb572
    Step 7/9 : RUN adduser -D -u ${USERID} -G $GROUP $USER
    ---> Running in b6c1f1a81af1
    Removing intermediate container b6c1f1a81af1
    ---> 97d3e5ad7540
    Step 8/9 : COPY --chown=$USER:$GROUP ./ ${AUXILIARY_IMAGE_PATH}/
    ---> 21088171876f
    Step 9/9 : USER $USER
    ---> Running in 825e0abc9f6a
    Removing intermediate container 825e0abc9f6a
    ---> b81d6430fcda
    Successfully built b81d6430fcda
    Successfully tagged wlsaksacru6jyly7kztoqu.azurecr.io/wlsaks-auxiliary-image:1.0
    2024/08/28 03:06:19 Successfully executed container: build
    2024/08/28 03:06:19 Executing step ID: push. Timeout(sec): 3600, Working directory: '', Network: ''
    2024/08/28 03:06:19 Pushing image: wlsaksacru6jyly7kztoqu.azurecr.io/wlsaks-auxiliary-image:1.0, attempt 1
    The push refers to repository [wlsaksacru6jyly7kztoqu.azurecr.io/wlsaks-auxiliary-image]
    ee589b3cda86: Preparing
    c1fd1adab3b9: Preparing
    d51af96cf93e: Preparing
    c1fd1adab3b9: Pushed
    d51af96cf93e: Pushed
    ee589b3cda86: Pushed
    1.0: digest: sha256:c813eb75576eb07a179c3cb4e70106ca7dd280f933ab33a2f6858de673b12eac size: 946
    2024/08/28 03:06:21 Successfully pushed image: wlsaksacru6jyly7kztoqu.azurecr.io/wlsaks-auxiliary-image:1.0
    2024/08/28 03:06:21 Step ID: build marked as successful (elapsed time in seconds: 8.780235)
    2024/08/28 03:06:21 Populating digests for step ID: build...
    2024/08/28 03:06:22 Successfully populated digests for step ID: build
    2024/08/28 03:06:22 Step ID: push marked as successful (elapsed time in seconds: 1.980158)
    2024/08/28 03:06:22 The following dependencies were found:
    2024/08/28 03:06:22
    - image:
       registry: wlsaksacru6jyly7kztoqu.azurecr.io
       repository: wlsaks-auxiliary-image
       tag: "1.0"
       digest: sha256:c813eb75576eb07a179c3cb4e70106ca7dd280f933ab33a2f6858de673b12eac
    runtime-dependency:
       registry: registry.hub.docker.com
       repository: library/busybox
       tag: latest
       digest: sha256:9ae97d36d26566ff84e8893c64a6dc4fe8ca6d1144bf5b87b2b85a32def253c7
    git: {}
    
    Run ID: ca1 was successful after 14s
    

    이미지가 빌드 성공 후 ACR로 푸시됩니다.

  13. 다음 예제와 같이 az acr repository show를 실행하여 이미지가 원격 리포지토리에 성공적으로 푸시되는지 여부를 테스트할 수 있습니다.

    az acr repository show --name ${ACR_NAME} --image ${IMAGE}
    

    이 명령은 다음 예제와 유사한 출력을 생성합니다.

    {
       "changeableAttributes": {
          "deleteEnabled": true,
          "listEnabled": true,
          "readEnabled": true,
          "writeEnabled": true
       },
       "createdTime": "2024-01-24T06:14:19.4546321Z",
       "digest": "sha256:a1befbefd0181a06c6fe00848e76f1743c1fecba2b42a975e9504ba2aaae51ea",
       "lastUpdateTime": "2024-01-24T06:14:19.4546321Z",
       "name": "1.0",
       "quarantineState": "Passed",
       "signed": false
    }
    

보조 이미지 적용

이전 단계에서는 모델 및 WDT를 포함한 보조 이미지를 만들었습니다. 다음 단계를 수행하여 WebLogic Server 클러스터에 보조 이미지를 적용합니다.

  1. kubectl patch 명령을 통해 도메인 CRD(사용자 지정 리소스 정의)를 패치하여 보조 이미지를 적용합니다.

    보조 이미지는 다음 예제와 spec.configuration.model.auxiliaryImages같이 정의됩니다.

    spec:
      clusters:
      - name: sample-domain1-cluster-1
      configuration:
        model:
          auxiliaryImages:
          - image: wlsaksacrafvzeyyswhxek.azurecr.io/wlsaks-auxiliary-image:1.0
            imagePullPolicy: IfNotPresent
            sourceModelHome: /auxiliary/models
            sourceWDTInstallHome: /auxiliary/weblogic-deploy
    

    다음 명령을 사용하여 restartVersion 값을 늘리고 kubectl patch를 사용하여 표시된 정의로 도메인 CRD에 보조 이미지를 적용합니다.

    export VERSION=$(kubectl -n ${WLS_DOMAIN_NS} get domain ${WLS_DOMAIN_UID} -o=jsonpath='{.spec.restartVersion}' | tr -d "\"")
    export VERSION=$((VERSION+1))
    
    export ACR_LOGIN_SERVER=$(az acr show --name ${ACR_NAME} --query "loginServer" --output tsv)
    
    cat <<EOF >patch-file.json
    [
      {
        "op": "replace",
        "path": "/spec/restartVersion",
        "value": "${VERSION}"
      },
      {
        "op": "add",
        "path": "/spec/configuration/model/auxiliaryImages",
        "value": [{"image": "$ACR_LOGIN_SERVER/$IMAGE", "imagePullPolicy": "IfNotPresent", "sourceModelHome": "/auxiliary/models", "sourceWDTInstallHome": "/auxiliary/weblogic-deploy"}]
      },
      {
       "op": "remove",
       "path": "/spec/configuration/model/configMap"
      }
    ]
    EOF
    
    kubectl -n ${WLS_DOMAIN_NS} patch domain ${WLS_DOMAIN_UID} \
        --type=json \
        --patch-file patch-file.json
    
  2. 데이터베이스 연결이 보조 이미지에 구성되었으므로 다음 명령을 실행하여 ConfigMap을 제거합니다.

    kubectl delete configmap sample-domain1-wdt-config-map -n ${WLS_DOMAIN_NS}
    

계속하기 전에 다음 명령이 관리 서버 및 관리 서버에 대해 다음 출력을 생성할 때까지 기다립니다.

kubectl get pod -n ${WLS_DOMAIN_NS} -w
NAME                             READY   STATUS    RESTARTS   AGE
sample-domain1-admin-server      1/1     Running   0          20m
sample-domain1-managed-server1   1/1     Running   0          19m
sample-domain1-managed-server2   1/1     Running   0          18m

시스템이 이 상태에 도달하는 데 5-10분 정도 소요될 수 있습니다. 다음 목록에서는 대기하는 동안 발생하는 결과를 간단히 설명합니다.

  • sample-domain1-introspector가 먼저 실행 중인 것으로 표시됩니다. 이 소프트웨어는 Kubernetes 클러스터에서 필요한 작업을 수행할 수 있도록 도메인 사용자 지정 리소스에 대한 변경 내용을 찾습니다.
  • 변경 내용이 검색되면 도메인 Introspector가 Pod를 종료한 후 새 Pod를 시작하여 변경 내용을 롤아웃합니다.
  • 다음으로 sample-domain1-admin-server Pod가 종료되었다가 다시 시작되는 것을 볼 수 있습니다.
  • 그런 다음, 두 개의 관리되는 서버가 종료되었다가 다시 시작되는 것을 볼 수 있습니다.
  • 모든 세 Pod가 1/1 Running 상태를 나타내면 계속 진행해도 됩니다.

배포 기능 확인

다음 단계에 따라 WebLogic Server 관리 콘솔 및 샘플 앱을 보고 배포의 기능을 확인합니다.

  1. adminConsoleExternalUrl 값을 인터넷에 연결된 웹 브라우저의 주소 표시줄에 붙여 넣습니다. 친숙한 WebLogic Server 관리 콘솔 로그인 화면이 표시됩니다.

  2. Azure Portal에서 WebLogic Server를 배포할 때 입력한 사용자 이름 weblogic 및 암호로 로그인합니다. 이 값은 wlsAksCluster2022입니다.

  3. 도메인 구조 상자에서 서비스를 선택합니다.

  4. 서비스 아래에서 데이터 원본을 선택합니다.

  5. JDBC 데이터 원본 요약 패널에서 모니터링을 선택합니다. 화면은 다음 예제와 유사합니다. 관리형 서버에서 데이터 원본 상태가 실행 중으로 나타납니다.

    데이터 원본 상태의 스크린샷

  6. 도메인 구조 상자에서 배포를 선택합니다.

  7. 배포 테이블에는 하나의 행이 있습니다. 이름은 appmodel.yaml 파일의 Application 값과 같아야 합니다. 이름을 선택합니다.

  8. 테스트 탭을 선택합니다.

  9. weblogic-cafe를 선택합니다.

  10. weblogic-cafe 설정 패널에서 테스트 탭을 선택합니다.

  11. weblogic-cafe 옆에 있는+ 아이콘을 확장합니다. 화면은 다음 예제와 유사합니다. 특히 테스트 지점 열에 http://sample-domain1-managed-server1:8001/weblogic-cafe/index.xhtml과 유사한 값이 표시됩니다.

    weblogic-cafe 테스트 지점의 스크린샷

    참고 항목

    관리 콘솔을 실행 중인 외부 URL로 구성하지 않았기 때문에 테스트 지점 열의 하이퍼링크를 선택할 수 없습니다. 이 문서에서는 단지 데모를 통해서만 WebLogic Server 관리 콘솔을 보여 줍니다. AKS에서 WebLogic Server를 실행할 때 지속성 구성 변경에 WebLogic Server 관리 콘솔을 사용하지 마세요. AKS에서 WebLogic Server의 클라우드 네이티브 디자인을 사용하려면 Oracle 설명서에 설명된 대로 모델 업데이트와 같은 CI/CD 기술을 사용하여 모든 지속성 구성을 초기 Docker 이미지에 표시하거나 실행 중인 AKS 클러스터에 적용해야 합니다.

  12. 배포한 샘플 앱의 context-path 값을 이해합니다. 권장 샘플 앱을 배포했다면 context-pathweblogic-cafe입니다.

  13. context-pathclusterExternalUrl 값에 추가하여 샘플 앱의 정규화된 URL을 생성합니다. 권장 샘플 앱을 배포했다면 정규화된 URL은 http://wlsgw202401-wls-aks-domain1.eastus.cloudapp.azure.com/weblogic-cafe/와 비슷합니다.

  14. 인터넷에 연결된 웹 브라우저에 정규화된 URL을 붙여넣습니다. 권장 샘플 앱을 배포한 경우 다음 스크린샷과 유사한 결과가 표시됩니다.

    테스트 웹앱 스크린샷

리소스 정리

Azure 요금을 방지하려면 불필요한 리소스를 정리해야 합니다. 클러스터가 더 이상 필요하지 않은 경우 az group delete 명령을 사용합니다. 다음 명령은 리소스 그룹, 컨테이너 서비스, 컨테이너 레지스트리, 데이터베이스 및 모든 관련 리소스를 제거합니다.

az group delete --name <resource-group-name> --yes --no-wait
az group delete --name <db-resource-group-name> --yes --no-wait

다음 단계

다음 링크를 따라 AKS 또는 가상 머신에서 WebLogic Server를 실행하는 방법에 대해 자세히 알아봅니다.

Azure Marketplace의 Oracle WebLogic 제품에 대한 자세한 내용은 Azure의 Oracle WebLogic Server를 참조하세요. 이러한 제안은 모두 사용자 라이선스가 필요합니다. Oracle을 사용하여 적절한 라이선스를 이미 확보했으며 Azure에서 제품을 실행할 수 있는 적절한 라이선스를 보유하고 있다고 가정합니다.