WebLogic Server 애플리케이션을 Azure Kubernetes Service로 마이그레이션

  • 아티클

이 가이드에서는 AKS(Azure Kubernetes Service)에서 실행되도록 기존 WLS(WebLogic Server) 애플리케이션을 마이그레이션할 때 알아야 할 사항에 대해 설명합니다.

사전 마이그레이션

마이그레이션을 성공적으로 수행하려면 시작하기 전에 다음 섹션에서 설명하는 평가 및 인벤토리 단계를 완료합니다.

대상이 마이그레이션 작업에 적합한 대상인지 확인합니다.

WLS 애플리케이션을 Azure로 성공적으로 마이그레이션하는 첫 번째 단계는 가장 적절한 마이그레이션 대상을 선택하는 것입니다. WLS는 Azure VM(가상 머신) 또는 AKS(Azure Kubernetes Service)에서 잘 실행됩니다. VM 대상은 온-프레미스 배포와 가장 유사하기 때문에 가장 쉬운 선택입니다. 가상 머신에 대한 관리 및 배포 환경은 온-프레미스에 있는 것과 매우 유사합니다. 이러한 용이성을 위한 절상은 경제적 비용입니다. 일반적으로 VM 기반 솔루션의 분당 비용은 AKS에 비해 더 높습니다. AKS 기반 솔루션은 실행 비용이 적게 들지만 AKS의 요구 사항에 맞게 애플리케이션을 제한해야 합니다. 변경을 최소화하는 것이 마이그레이션 작업의 가장 중요한 요소인 경우 VM 기반 마이그레이션을 고려합니다. 이 경우 WebLogic 애플리케이션을 Azure Virtual Machines로 마이그레이션을 참조 하세요. 런타임 비용을 줄이기 위해 Kubernetes 내에서 실행되도록 애플리케이션을 변환하는 것을 허용할 수 있는 경우 AKS 기반 마이그레이션을 고려하세요. 이 경우 WebLogic Server 애플리케이션을 Azure Kubernetes Service로 마이그레이션합니다.

미리 빌드된 Azure Marketplace 제품이 좋은 시작점인지 확인

AKS가 적절한 배포 대상이라고 결정한 후에는 Oracle WLS Kubernetes 연산자(연산자)가 Kubernetes에서 WLS를 실행하는 유일한 방법임을 동의해야 합니다. 이 사실을 수락한 후에는 미리 빌드 된 Azure Marketplace 제품이 좋은 시작점인지 여부를 결정해야 합니다. 다음은 미리 빌드된 Azure Marketplace 제품에 대해 고려해야 할 몇 가지 사항입니다.

  • Oracle과 Microsoft는 이미지의 모델을 사용하여 AKS에서 WLS를 신속하게 프로비전할 수 있도록 이 제품을 만들었습니다기본 홈 소스 유형입니다. 이 개념은 이 문서의 뒷부분에 자세히 설명되어 있습니다.
  • 높은 수준에서 제품은 다음 단계를 자동화합니다.
    • 원하는 경우 기존 WAR 또는 EAR 배포를 수행합니다.
    • WIT(WebLogic Image Tool)를 사용하여 컨테이너에 래핑합니다. 자세한 내용은 Oracle 설명서의 WebLogic 이미지 도구를 참조하세요.
    • AKS에서 WebLogic Kubernetes 연산자를 설치하고 구성합니다.
    • 연산자를 사용하여 모든 작업을 실행합니다. 연산자는 WDT(WebLogic Deploy Tooling)를 호출하여 WebLogic 환경을 설정하고 메타데이터 모델을 기반으로 반복 가능한 방식으로 기본 수명 주기 작업을 수행합니다. 자세한 내용은 Oracle 설명서의 WebLogic 배포 도구를 참조하세요.
  • 미리 빌드된 제품은 App Gateway, 탄력적 로깅, 데이터베이스 통합 등과 같은 다양한 Azure 서비스 통합을 제공하지만 많은 간소화된 가정을 만듭니다. 이러한 가정을 통해 오퍼는 운영자를 직접 마스터하고 사용하는 것만큼 유연하지 않습니다.

미리 빌드된 Azure Marketplace 제품을 사용하지 않는 경우 운영자를 직접 사용하는 방법을 배워야 합니다. 연산자 마스터는 이 문서의 범위를 벗어납니다. WLS Kubernetes 연산자에 대한 전체 설명서는 Oracle에서 확인할 수 있습니다.

이 섹션의 re기본der는 미리 빌드된 Azure Marketplace 제품을 사용하도록 결정하거나 운영자를 직접 사용하기 위한 몇 가지 고려 사항을 제공합니다.

먼저 WLS "do기본"의 개념을 이해해야 합니다. do기본는 논리적으로 관련된 WLS 리소스 그룹입니다. WLS do기본 정식 정의는 Oracle 설명서를 참조하세요. AKS에서 WLS를 실행하려면 AKS에서 수행하는 작업을 처리하는 방법을 결정해야 기본. 다양한 선택을 "할기본 홈 소스 유형"이라고 합니다. WLS Kubernetes 연산자는 세 가지 할 일기본 홈 소스 유형을 지원합니다. 미리 빌드된 Azure Marketplace 제품은 이 표의 첫 번째 제품을 사용합니다.

할기본 홈 소스 유형 설명 긍정적인 측면 부정적인 측면
이미지의 모델 WLS 및 애플리케이션은 컨테이너 이미지에 있으며 다른 모든 항목은 해당 이미지 외부에 유지됩니다. 미리 빌드된 제품에서 지원됩니다. 공식 샘플로 문서화됨; Oracle을 참조하세요. 대부분 WDT를 많이 사용합니다. 대부분의 "클라우드 네이티브" 옵션입니다. 가장 간단한 CI/CD 통합. 가장 큰 학습 곡선입니다.
PV에서 기본 do기본는 Kubernetes 영구 볼륨에 상주합니다. 개념적으로 VM에서 실행되는 것과 유사합니다. WLS 콘솔을 사용하여 변경할 수 있으며 이러한 변경 내용은 AKS Pod 다시 시작에서 유지됩니다. 공식 샘플로 문서화됨; Oracle을 참조하세요. NFS와 관련된 몇 가지 문제를 완화해야 합니다. 자세한 내용은 Oracle을 참조 하세요. 이 방법은 최소 "클라우드 네이티브" 기술입니다. 상태는 전적으로 AKS 클러스터 외부에 있습니다.
이미지에서 수행기본 do기본 컨테이너 이미지에 있습니다. 애플리케이션은 do기본 이미지에 오버레이된 컨테이너 이미지에 포함됩니다. PV에서 Do기본보다 더 많은 "클라우드 네이티브"입니다. CI/CD가 더 쉽습니다. WLS 콘솔을 사용할 수 없습니다. 기본 더 많은 컨테이너 이미지를 확인해야 합니다.

Important

PV 원본 유형에서 Do기본를 선택하는 경우 SMB 대신 NFS를 사용하는 것이 좋습니다. NFS는 UNIX 운영 체제 및 GNU/Linux와 같은 다른 변형에서 발전했습니다. 이러한 이유로 Docker와 같은 컨테이너 기술과 함께 NFS를 사용하는 경우 동시 읽기 및 파일 잠금에 문제가 있을 가능성이 적습니다.

NFS v4.1을 사용하도록 설정해야 합니다. v4.1보다 낮은 버전에는 문제가 있습니다.

연산자 설명서에는 다양한 옵션을 비교하는 유용한 테이블도 포함되어 있습니다. 자세한 내용은 할 일기본 홈 소스 유형 선택을 참조하세요.

미리 빌드된 Azure Marketplace 제품에 대한 느낌을 얻으려면 빠른 시작: Azure Portal을 사용하여 Azure Kubernetes Service에 WebLogic Server 배포를 참조하세요. 미리 빌드된 Azure Marketplace 제품에 대한 참조 설명서는 Oracle을 참조하세요.

운영자를 직접 사용하는 방법을 알아보려면 운영자 설명서의 샘플을 사용해 보세요.

이제 AKS에서 WLS기본를 처리하는 다양한 방법을 소개했으므로 미리 빌드된 Azure Marketplace 제품을 사용할지 아니면 운영자를 직접 사용하여 직접 사용할지 선택할 수 있습니다.

WebLogic 버전이 호환되는지 확인

기존 WLS 버전은 운영자가 지원하는 버전 중 하나여야 합니다. Oracle 기본 OCR(Oracle Container Registry)에서 이러한 버전을 포함합니다. 다음 단계를 사용하여 지원되는 버전 목록을 확인합니다.

  1. Oracle Container Registry 웹 사이트를 방문하여 로그인합니다. 자세한 내용은 https://container-registry.oracle.com/를 참조하세요.
  2. 지원 자격이 있는 경우 미들웨어를 선택한 다음, weblogic_cpu 검색합니다. weblogic_cpu 선택합니다.
  3. Oracle의 지원 자격이 없는 경우 미들웨어를 선택한 다음 웹 로그를 검색합니다. 웹 로그를 선택합니다.

참고 항목

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

미리 빌드된 Azure Marketplace 제품을 사용하면 OCR 및 ACR(Azure Container Registry)에서 WLS 이미지를 선택할 수 있으므로 OCR에서 사용할 수 있는 모든 버전을 암시적으로 지원합니다. 제품을 ACR에서 끌어오도록 지시하는 경우 OCR에 나열된 지원되는 버전 중 하나에서 파생되었는지 확인합니다.

인벤토리 서버 용량

현재 프로덕션 서버의 하드웨어(메모리, CPU, 디스크) 및 평균 및 최대 요청 수 및 리소스 사용률을 문서화합니다. 선택한 마이그레이션 경로에 관계없이 이 정보가 필요합니다. 예를 들어 노드 풀의 VM 크기 선택, 컨테이너에서 사용할 메모리 양 및 컨테이너에 필요한 CPU 공유 수를 안내하는 데 유용합니다.

AKS에서 노드 풀의 크기를 조정할 수 있습니다. 방법을 알아보려면 AKS(Azure Kubernetes Service)의 노드 풀 크기 조정을 참조하세요.

모든 비밀 인벤토리

Azure Key Vault와 같은 "서비스로 구성" 기술이 도입되기 전에는 "비밀"이라는 개념이 잘 정의되지 않았습니다. 대신, 현재 "비밀"이라고 부르는 것으로 효과적으로 작동하는 서로 다른 구성 설정 집합이 있었습니다. WebLogic Server와 같은 앱 서버를 사용하면 이러한 비밀은 다양한 구성 파일 및 구성 저장소에 있습니다. 프로덕션 서버의 모든 속성 및 구성 파일에서 비밀 및 암호를 확인합니다. WAR에서 weblogic.xml을 검사 합니다. 암호 또는 자격 증명을 포함하는 구성 파일도 애플리케이션 내에서 찾을 수 있습니다. 자세한 내용은 Azure Key Vault 기본 개념을 참조 하세요.

비밀의 견고한 인벤토리가 있으면 비밀에 대한 운영자 설명서를 참조하세요. 자세한 내용은 비밀을 참조하세요.

모든 인증서 인벤토리화

공용 SSL 엔드포인트에 사용되는 모든 인증서를 문서화합니다. 다음 명령을 실행하여 프로덕션 서버의 모든 인증서를 볼 수 있습니다.

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

인증서의 견고한 인벤토리가 있으면 미리 빌드된 Azure Marketplace 제품을 사용하여 직접 설치할 수 있습니다. 자세한 내용은 TLS/SSL 구성을 참조하세요. 연산자를 직접 사용하는 경우 운영자 외부 인증서 업데이트를 참조 하세요.

지원되는 Java 버전이 올바르게 작동하는지 확인

WebLogic에서 Azure로의 모든 마이그레이션 경로에는 각 경로에 따라 달라지는 특정 Java 버전이 필요합니다. 지원되는 버전을 사용하여 애플리케이션을 올바르게 실행할 수 있는지 확인해야 합니다.

참고 항목

이 유효성 검사는 현재 서버가 지원되지 않는 JDK(예: Oracle JDK 또는 IBM OpenJ9)에서 실행 중인 경우에 특히 중요합니다.

현재 Java 버전을 가져오려면 프로덕션 서버에 로그인하고 다음 명령을 실행합니다.

java -version

참고 항목

Azure 가상 머신에서 WLS로 마이그레이션할 때 특정 Java 버전에 대한 요구 사항은 가상 머신에 미리 설치된 Java에 의해 결정됩니다. AKS의 WLS로 마이그레이션할 때 특정 Java 버전은 선택한 컨테이너 이미지에 의해 결정됩니다. 다양한 옵션이 있지만 모두 Oracle JDK를 사용합니다.

JNDI 리소스 인벤토리

모든 JNDI 리소스를 인벤토리화합니다. 예를 들어 데이터베이스와 같은 데이터 원본에는 JPA가 특정 데이터베이스에 EntityManager 인스턴스를 올바르게 바인딩할 수 있도록 하는 연결된 JNDI 이름이 있을 수 있습니다. JNDI 리소스 및 데이터베이스에 대한 자세한 내용은 Oracle 설명서의 WebLogic Server 데이터 원본을 참조하세요. JMS 메시지 브로커와 같은 다른 JNDI 관련 리소스에는 마이그레이션 또는 재구성이 필요할 수 있습니다. JMS 구성 에 대한 자세한 내용은 Oracle WebLogic Server 12.2.1.4.0을 참조하세요.

미리 빌드된 Azure Marketplace 제품을 사용하는 경우 배포 시 사용자 지정할 수 있는 JNDI 리소스 집합은 제품이 지원하는 항목으로 제한됩니다. 제품 설명서에서 JNDI를 검색합니다. 연산자를 직접 사용하는 경우 선택한 do기본 홈 소스 유형에 따라 JDNI 리소스를 정의할 수 있습니다. PV에서 Do기본 경우 WLST 또는 관리 콘솔을 사용하여 일반적인 방식으로 설정할 수 있습니다. 이미지의 Do기본 또는 이미지의 모델에서 일반적인 재정의를 참조하세요.

do기본 구성 검사

WebLogic Server의 기본 구성 단위는 도메인입니다. 따라서 config.xml 파일에는 마이그레이션을 위해 신중하게 고려해야 하는 다양한 구성이 포함되어 있습니다. 이 파일에는 하위 디렉터리에 저장된 추가 XML 파일의 참조가 포함되어 있습니다. Oracle은 일반적으로 관리주체 콘솔을 사용하여 WebLogic Server의 관리 가능한 개체 및 서비스를 구성하고 WebLogic Server가 config.xml 파일을 기본 수 있도록 해야 한다고 조언합니다. 자세한 내용은 Do기본 구성 파일을 참조하세요.

애플리케이션 내부

WEB-INF/weblogic.xml 파일 및/또는 WEB-INF/web.xml 파일을 검사합니다.

미리 빌드된 Azure Marketplace 제품은 do기본 리소스를 자동으로 만듭니다. 연산자를 직접 사용하는 경우 할 일기본 표현 방법을 완전히 사용자 지정할 수 있습니다. 자세한 내용은 Do기본 리소스를 참조하세요.

세션 복제본(replica) 사용 여부 확인

애플리케이션이 Oracle Coherence*Web을 사용하거나 사용하지 않고 세션 복제본(replica) 의존하는 경우 다음 세 가지 옵션이 있습니다.

  • Coherence*Web은 Azure 가상 머신에서 WebLogic Server와 함께 실행할 수 있지만 제품을 프로비전한 후 이 옵션을 수동으로 구성해야 합니다. 독립 실행형 일관성을 사용하는 경우 Azure 가상 머신에서 실행할 수도 있지만 제품을 프로비전한 후 이 옵션을 수동으로 구성해야 합니다.
  • 세션 관리에 데이터베이스를 사용하도록 애플리케이션을 리팩터링합니다.
  • Azure Redis Service에 세션을 외부화하도록 애플리케이션을 리팩터링합니다. 자세한 내용은 Azure Cache for Redis를 참조하세요.

이러한 모든 옵션의 경우 WebLogic이 HTTP 세션 상태 복제를 수행하는 방법을 마스터하는 것이 좋습니다. 자세한 내용은 Oracle 설명서의 HTTP 세션 상태 복제를 참조하세요.

미리 빌드된 Azure Marketplace 제품은 Application Gateway 수신 컨트롤러를 통한 세션 선호도를 지원합니다. 제품을 배포할 때 쿠키 기반 선호도 사용을 선택합니다. 제품에 대한 설명서에서 쿠키 기반 선호도를 찾습니다.

문서 데이터 원본

애플리케이션에서 데이터베이스를 사용하는 경우 다음 정보를 캡처해야 합니다.

  • 데이터 원본 이름은 무엇인가요?
  • 연결 풀 구성이란?
  • JDBC 드라이버 JAR 파일은 어디에서 찾을 수 있나요?

WebLogic의 JDBC 드라이버에 대한 자세한 내용은 WebLogic Server에서 JDBC 드라이버 사용을 참조 하세요.

미리 빌드된 Azure Marketplace 제품은 가장 인기 있는 데이터베이스를 지원합니다. 자세한 내용은 데이터베이스를 참조 하세요. PV에서 Do기본 경우 WLST 또는 관리 콘솔을 사용하여 일반적인 방식으로 설정할 수 있습니다. 이미지의 Do기본 또는 이미지의 모델에서 일반적인 재정의를 참조하세요.

WebLogic이 사용자 지정되었는지 확인

다음 중 어떤 사용자 지정이 수행되었는지 확인하고 수행된 작업을 캡처합니다.

  • 시작 스크립트가 변경되었나요? 이러한 스크립트에는 setDo기본Env, commEnv, startWebLogic 및 stopWebLogic이 포함됩니다.
  • JVM에 전달된 특정 매개 변수가 있나요?
  • 서버 클래스 경로에 JAR이 추가되어 있나요?

AKS에서 실행하는 컨테이너 이미지에서 이러한 사용자 지정을 캡처해야 합니다. 미리 빌드된 Azure Marketplace 제품의 경우 사용자 지정 컨테이너 이미지를 만들고 Azure Container Registry에서 사용할 수 있도록 한 다음 배포 시 해당 레지스트리를 가리키는 방식으로 이러한 사용자 지정을 가장 잘 처리합니다. 자세한 내용은 이미지 선택을 참조 하세요. 연산자를 직접 사용하는 경우 JVM 메모리 및 Java 옵션 환경 변수를 참조 하세요.

REST를 통해 관리가 사용되는지 여부 확인

애플리케이션의 수명 주기에 REST를 통한 관리 사용이 포함되는 경우 REST API 액세스에 사용되는 포트를 캡처하고 포트의 권한 부여 및 노출 방법을 결정해야 합니다. 마이그레이션 후에는 애플리케이션 수명 주기가 마이그레이션 전과 비슷한 방식으로 작동할 수 있도록 동일한 포트 및 인증 메커니즘이 노출되도록 해야 합니다. 자세한 내용은 관리 RESTful Management Services를 사용하여 Oracle WebLogic Server 등록을 참조하세요.

REST를 통해 관리를 계속 사용하는 것이 적합한 유일한 기본 홈 소스 유형은 PV에서 Do기본입니다. 다른 할 일기본 홈 소스 유형과 함께 사용할 수 있지만 변경 내용은 임시이며 Pod 다시 시작에서 지속되지 않습니다.

온-프레미스에 대한 연결이 필요한지 확인

애플리케이션이 온-프레미스 서비스에 액세스해야 하는 경우 Azure의 연결 서비스 중 하나를 프로비전해야 합니다. 자세한 내용은 온-프레미스 네트워크를 Azure에 연결하기 위한 솔루션 선택을 참조하세요. 또는 온-프레미스 리소스가 노출하는 공개적으로 사용 가능한 API를 사용하도록 애플리케이션을 리팩터링해야 합니다.

JMS(Java Message Service) 큐 또는 토픽을 사용하는지 확인

애플리케이션에서 JMS 큐 또는 토픽을 사용하는 경우 외부에 호스트되는 JMS 서버로 마이그레이션해야 합니다. Azure Service Bus 및 고급 메시지 큐 프로토콜은 JMS를 사용하는 사람들에게 훌륭한 마이그레이션 전략이 될 수 있습니다. 자세한 내용은 Azure Service Bus 및 AMQP 1.0에서 JMS 사용을 참조 하세요.

JMS 영구 저장소가 구성된 경우 해당 구성을 캡처하고 마이그레이션 후에 적용해야 합니다.

Oracle Message Broker를 사용하는 경우 이 소프트웨어를 Azure 가상 머신으로 마이그레이션하고 있는 그대로 사용할 수 있습니다.

사용자 지정으로 만든 공유 Java EE 라이브러리를 사용하고 있는지 확인

공유 Java EE 라이브러리 기능을 사용하는 경우 다음과 같은 두 가지 옵션이 있습니다.

  • 애플리케이션 코드를 리팩터링하여 라이브러리에 대한 모든 종속성을 제거하고 대신 기능을 애플리케이션에 직접 통합합니다.
  • 서버 클래스 경로에 라이브러리를 추가합니다.

이러한 라이브러리는 WebLogic이 사용자 지정되었는지 확인에 설명된 것과 동일한 기술을 사용하여 처리할 수 있습니다.

OSGi 번들이 사용되는지 확인

WebLogic 서버에 추가된 OSGi 번들을 사용한 경우에는 동등한 JAR 파일을 웹 애플리케이션에 직접 추가해야 합니다.

미리 빌드된 Azure Marketplace 제품에 제공된 WAR 또는 EAR에 포함하거나 운영자를 직접 사용할 수 있습니다.

애플리케이션에 OS 관련 코드가 포함되어 있는지 확인

호스트 OS에 대한 종속성이 있는 코드가 애플리케이션에 포함되어 있는 경우 해당 종속성을 제거하려면 이 코드를 리팩터링해야 합니다. 예를 들어 파일 시스템 경로에서 사용하고 있는 / 또는 \를 File.Separator 또는 Paths.get으로 바꿔야 할 수 있습니다.

AKS의 WLS는 Oracle Linux에서 실행됩니다. 모든 OS 관련 코드는 Oracle Linux와 호환되어야 합니다. 특정 OS 정보를 검색하는 방법을 알아보려면 WebLogic 버전이 호환되는지 확인의 단계를 수행합니다.

Oracle Service Bus가 사용 중인지 확인

애플리케이션이 OSB(Oracle Service Bus)를 사용하는 경우 OSB가 구성된 방법을 캡처해야 합니다. 자세한 내용은 Oracle Service Bus 설치 정보를 참조하세요.

OSB는 미리 빌드된 Azure Marketplace 제품에서 직접 지원되지 않습니다. OSB를 사용해야 하는 경우 연산자를 직접 사용해야 합니다.

애플리케이션이 여러 WAR로 구성되었는지 확인

애플리케이션이 여러 WAR로 구성된 경우 각 WAR을 별도의 애플리케이션으로 처리하고 각 WAR에 대해 이 가이드를 진행해야 합니다.

애플리케이션이 EAR로 패키지되었는지 확인

애플리케이션이 EAR 파일로 패키지된 경우 application.xml 및 weblogic-application.xml 파일을 검사하고 해당 구성을 캡처해야 합니다.

미리 빌드된 Azure Marketplace 제품은 WAR 및 EAR을 지원합니다. 운영자를 직접 사용하면 WAR 및 EA도 지원됩니다.

프로덕션 서버에서 실행되는 모든 외부 프로세스 및 디먼 식별

애플리케이션 서버 외부에서 실행 중인 프로세스(예: 디먼 모니터링)가 있는 경우 해당 프로세스를 제거하거나 다른 곳으로 마이그레이션해야 합니다.

WLST(WebLogic Scripting Tool)가 사용되는지 확인

현재 WLST를 사용하여 배포를 수행하는 경우 수행 중인 작업을 평가해야 합니다. WLST가 배포의 일부로 애플리케이션의 런타임 매개 변수를 변경하는 경우 마이그레이션 후 애플리케이션을 테스트하는 동안 이 동작이 계속 작동하는지 확인해야 합니다.

WLST 사용과 호환되는 유일한 기본 홈 소스 유형은 PV에서 Do기본입니다. 자세한 내용은 PV의 Do기본 Home을 참조하세요.

파일 시스템의 사용 여부 및 방법 확인

Kubernetes는 PV(영구 볼륨)를 사용하여 파일 시스템을 처리합니다. 미리 빌드된 Azure Marketplace 제품 및 운영자를 직접 사용하는 경우 영구 볼륨 탑재가 지원됩니다. PV에서 Do기본 사용하는 경우 파일 시스템은 구성의 핵심 측면입니다.

읽기 전용 정적 콘텐츠

애플리케이션이 현재 정적 콘텐츠를 제공하는 경우 대체 위치가 필요합니다. 정적 콘텐츠를 Azure Blob Storage로 이동하고 전역적으로 빠른 다운로드를 위해 Azure CDN을 추가하는 것이 좋습니다. 자세한 내용은 Azure Storage 및 빠른 시작에서 정적 웹 사이트 호스팅: Azure CDN과 Azure Storage 계정 통합을 참조하세요. Azure Spring Apps Enterprise 계획의 앱에 정적 콘텐츠를 직접 배포할 수도 있습니다. 자세한 내용은 웹 정적 파일 배포를 참조 하세요.

동적으로 게시된 정적 콘텐츠

애플리케이션이 애플리케이션에서 업로드/생성되었지만 생성 후 변경할 수 없는 정적 콘텐츠를 허용하는 경우, 위에서 설명한 대로 Azure Blob Storage 및 Azure CDN과 Azure Function을 사용하여 업로드 및 CDN 새로 고침을 처리할 수 있습니다. Azure Functions를 사용하여 정적 콘텐츠를 업로드 및 CDN 미리 로드할 때 사용할 샘플 구현을 제공했습니다. Azure Spring Apps Enterprise 계획의 앱에 정적 콘텐츠를 직접 배포할 수도 있습니다. 자세한 내용은 웹 정적 파일 배포를 참조 하세요.

네트워크 토폴로지 확인

현재 Azure Marketplace 제품 집합은 마이그레이션을 위한 시작점입니다. 제품이 마이그레이션해야 하는 아키텍처의 측면을 다루지 않는 경우 기존 배포의 네트워크 토폴로지를 캡처하고 솔루션 템플릿 중 하나를 사용하여 기본 제안을 수행한 후에도 Azure에서 이를 재현해야 합니다.

이 토픽은 매우 광범위한 주제이지만, 다음 참고 자료에서 마이그레이션 작업에 대한 약간의 지침을 얻을 수 있습니다.

JCA 어댑터 및 리소스 어댑터 사용 고려

배포가 리소스 어댑터를 사용하는 경우 가장 지원되는 옵션은 PV의 Do기본 홈입니다.

사용자 지정 보안 공급자 및 JAAS 사용 계정

애플리케이션에서 JAAS를 사용하는 경우 보안 공급자의 구성이 올바르게 마이그레이션되었는지 확인해야 합니다. 자세한 내용은 Oracle 설명서에서 WebLogic 보안 공급자 구성 정보를 참조하세요.

배포에서 보안 공급자를 사용하는 경우 가장 지원되는 옵션은 PV의 Do기본 홈입니다.

WebLogic 클러스터링 사용되는지 확인

연산자는 AKS에서 WLS를 실행하는 가능한 모든 방법에 대해 클러스터링 처리합니다.

EJB 클러스터링 검사

애플리케이션이 로컬 EJB를 사용하는 경우 클러스터형 EJB로 마이그레이션해야 합니다. 자세한 내용은 클러스터형 및 로컬 EJB를 참조하세요.

부하 분산 요구 사항 고려

부하 분산을 고려하는 가장 좋은 방법은 기본 제공 Azure Marketplace 제품에서 제공하는 App Gateway 통합을 사용하는 것입니다. 자세한 내용은 자습서: Azure 애플리케이션 Gateway를 부하 분산 장치로 사용하여 WebLogic Server 클러스터를 Azure로 마이그레이션하는 방법을 참조하세요.

Java EE 애플리케이션 클라이언트 기능이 사용되는지 확인

배포가 Java EE 애플리케이션 클라이언트를 사용하는 경우 연산자를 직접 사용하는 것이 가장 좋습니다. 자세한 내용은 외부 클라이언트를 참조 하세요.

여러 컨테이너 이미지가 필요한지 확인

WebLogic Server는 기본 여러 클러스터를 포함할 수 있습니다. 예를 들어 다중 계층 애플리케이션은 단일 do기본 표시될 수 있지만 두 개의 클러스터(예: "프런트 엔드" 및 "백 엔드")가 있습니다. 백 엔드를 업데이트하지 않고 프런트 엔드를 업데이트할 수 있고 그 반대의 경우도 마찬가지입니다. 그러나 Image do기본 홈 소스 형식의 모델에서는 전체 do기본가 하나의 컨테이너 이미지에 표시됩니다. 이 사용 사례를 수용하려면 클러스터를 자체 컨테이너 이미지로 각각 고유한 do기본로 구분해야 합니다. 연산자는 여러 네임스페이스에서 여러 기본 관리할 수 있습니다. 자세한 내용은 do기본 네임스페이스 선택 전략을 참조하세요.

여러 do기본를 채택하면 할 일 사이에 T3 액세스 문제가 발생할 수 기본. 이러한 문제를 해결하려면 알 수 없는 호스트 액세스를 사용하도록 설정해야 하는지 여부를 결정하는 데 설명 된 대로 사용자 지정 채널을 사용하도록 설정합니다.

알 수 없는 호스트 액세스를 사용하도록 설정해야 하는지 확인

다음 시나리오에 대해 WebLogic에 패치를 적용하여 알 수 없는 호스트 액세스를 사용하도록 설정해야 할 수 있습니다.

  • 사용자 지정 채널을 통해 AKS 외부 클라이언트에서 AKS의 WLS 클러스터에 대한 T3 액세스를 허용합니다.
  • 사용자 지정 채널을 통해 AKS에서 서로 다른 WLS 간의 T3 액세스를 허용합니다기본.

패치에 대한 자세한 내용은 MOS(My Oracle 지원)에서 패치 검색을 사용하는 방법의 지침에 따라 패치30656708를 검색합니다.

패치가 적용된 후 알 수 없는 호스트 액세스 사용 설정을 참조하세요.

마이그레이션

이 섹션의 단계에서는 분석을 통해 미리 빌드된 Azure Marketplace 제품을 사용하기로 결정한다고 가정합니다.

제품 프로비전

Azure Portal에서 제품을 열려면 다음을 참조하세요 https://aka.ms/wlsaks. 만들기를 선택한 다음, 제품에 대한 설명서의 지침을 따릅니다. 이전 단계에서 수집한 정보를 사용하여 제품의 필드를 채우는 데 도움을 줍니다.

do기본s 마이그레이션

제품을 프로비전한 후 다음 단계에 따라 do기본 출력합니다.

배포에서 벗어나 진행 중인 페이지로 이동한 경우 다음 단계에서는 해당 페이지로 돌아가는 방법을 보여줍니다. 배포가 완료되었음을 보여 주는 페이지에 있는 경우 5단계로 건너뛸 수 있습니다.

  1. 포털 페이지의 왼쪽 상단에서 햄버거 메뉴를 선택하고 리소스 그룹을 선택합니다.

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

  3. 왼쪽 탐색 창의 설정 섹션에서 배포를 선택하여 이 리소스 그룹에 대한 배포의 순서가 지정된 목록을 먼저 확인합니다.

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

    Screenshot of Azure portal showing the resource group deployments list.

  5. 왼쪽 패널에서 출력을 선택합니다. 이 목록에는 배포의 출력 값이 표시됩니다. 유용한 정보가 출력에 포함됩니다. do기본 검사하고 연산자와 상호 작용할 수 있는 출력에 관심이 있습니다. 출력의 다른 값은 AKS의 WebLogic 사용자 가이드에 자세히 설명되어 있습니다.

  6. 라는 출력을 찾습니다 shellCmdtoConnectAks. 출력 값을 Bash 셸에 붙여넣고 명령을 실행합니다. 이 명령을 사용하면 클러스터에 대한 커넥트 설명된 대로 사용할 kubectl 수 있습니다.

  7. 라는 출력을 찾습니다 shellCmdtoOutputWlsDomainYaml. 출력 값을 Bash 셸에 붙여넣고 명령을 실행합니다. 이 명령은 do기본 리소스를 YAML 파일로 출력합니다.

  8. 현재 배포의 do기본 YAML을 사용했으므로 do기본 리소스 YAML 파일 배포에 대한 지식을 적용하고 이 지침을 검토하여 do기본 마이그레이션하는 방법에 대한 자세한 단서를 확인할 수 있습니다. 이 지침에는 Kubernetes의 작업 방식에 적용하기 위한 적응이 필요하지만 알고 있는 것은 여전히 유용합니다.

KeyStores 계정

애플리케이션에서 사용하는 모든 SSL KeyStore의 마이그레이션을 고려해야 합니다. 자세한 내용은 키 저장소 구성을 참조 하세요.

JMS 원본 커넥트

데이터베이스를 연결한 후에는 Fusion 미들웨어 관리 WebLogic 설명서에서 Oracle WebLogic Server용 JMS 리소스 등록의 지침에 따라 JMS를 구성할 수 있습니다.

로깅 계정

로깅을 마스터하지 않으면 클라우드를 수행할 수 없습니다. 연산자는 Elasticsearch 및 Kibana를 사용하기 위한 샘플을 제공합니다. 자세한 내용은 운영자 설명서를 참조 하세요. Azure는 Elastic에 대한 훌륭한 지원을 제공합니다. 자세한 내용은 Azure와의 탄력적 통합이란?을 참조하세요. 이러한 두 리소스의 지식을 결합하여 AKS의 WLS에 대한 Azure 최적화 로깅 솔루션을 달성할 수 있습니다.

애플리케이션 마이그레이션

배포 시 WAR 또는 EAR 파일을 제공하도록 선택했는지 여부에 관계없이 CI/CD를 통해 애플리케이션을 업데이트해야 합니다. 운영자 설명서에는 이 업데이트를 수행하는 방법을 보여 주는 샘플이 있습니다. 자세한 내용은 업데이트 3을 참조하세요. 다른 업데이트 샘플은 마이그레이션과 관련이 있으며 살펴볼 가치가 있습니다.

테스팅

애플리케이션에 대한 컨테이너 내 테스트는 Azure 내에서 실행되는 새 서버에 액세스하도록 구성해야 합니다. CI/CD 문제와 마찬가지로 필요한 네트워크 보안 규칙을 통해 테스트가 Azure에 배포된 애플리케이션에 액세스할 수 있도록 해야 합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.

마이그레이션 후

마이그레이션 전 단계에서 정의한 마이그레이션 목표에 도달한 후 일부 종단 간 승인 테스트를 수행하여 모든 것이 예상대로 작동하는지 확인합니다. 몇 가지 잠재적인 마이그레이션 후 개선 사항에 대한 지침은 다음 권장 사항을 참조하세요.