다음을 통해 공유

WebSphere 애플리케이션을 Azure Red Hat OpenShift로 마이그레이션

  • 아티클

이 가이드에서는 기존 WAS(WebSphere Application Server) 워크로드를 Azure Red Hat OpenShift에서 실행되는 IBM WebSphere Liberty 또는 Open Liberty로 마이그레이션하려는 경우 알아야 할 사항에 대해 설명합니다.

사전 마이그레이션

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

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

WAS 애플리케이션을 Azure로 성공적으로 마이그레이션하는 첫 번째 단계는 가장 적절한 마이그레이션 대상을 선택하는 것입니다.

WAS는 Azure Virtual Machines에서 잘 실행됩니다. VM(가상 머신) 대상은 온-프레미스 배포와 가장 유사하기 때문에 가장 쉬운 선택입니다. 가상 머신에 대한 관리 및 배포 환경은 온-프레미스에 있는 것과 유사합니다.

또 다른 옵션은 WAS 기존 워크로드를 애플리케이션 컨테이너로 변환하여 컨테이너로 마이그레이션하는 것입니다. AKS(Azure Kubernetes Service) 및 Azure Red Hat OpenShift에서 컨테이너 대상을 실행할 수 있습니다. 이러한 용이성을 위한 절상은 경제적 비용입니다.

일반적으로 VM 기반 솔루션의 분당 비용은 컨테이너에 비해 더 높습니다. 컨테이너 기반 솔루션은 실행 비용이 적게 들지만 컨테이너 오케스트레이션 플랫폼의 요구 사항에 맞게 애플리케이션을 제한해야 합니다.

변경을 최소화하는 것이 마이그레이션 작업의 가장 중요한 요소인 경우 VM 기반 마이그레이션을 고려합니다. 이 경우 WebSphere 애플리케이션을 Azure Virtual Machines로 마이그레이션을 참조 하세요.

애플리케이션을 컨테이너 내에서 실행하도록 변환하여 런타임 비용을 줄일 수 있는 경우 AKS 기반 또는 Azure Red Hat OpenShift 기반 마이그레이션을 고려합니다.

AKS 기반 마이그레이션의 경우 무료 계층 사용을 시작할 수 있습니다. 무료 클러스터 관리를 받고 사용된 가상 머신, 연결된 스토리지 및 네트워킹 리소스에 대해서만 비용을 지불합니다. 이 경우 WebSphere 애플리케이션을 Azure Kubernetes Service로 마이그레이션을 참조 하세요.

Azure Red Hat OpenShift 기반 마이그레이션의 경우 컴퓨팅 및 인프라 비용 외에도 애플리케이션 노드에는 OpenShift 라이선스 구성 요소에 대한 또 다른 비용이 있습니다. 이 비용은 애플리케이션 노드 수 및 인스턴스 유형에 따라 청구됩니다. 워크로드 및 비즈니스의 요구를 가장 잘 충족하는 주문형 가격 책정 또는 예약 인스턴스를 사용합니다. 이 경우 WebSphere 애플리케이션을 Azure Red Hat OpenShift로 마이그레이션을 참조하세요.

Azure Red Hat OpenShift 설명서의 방법 가이드는 마이그레이션과 관련된 몇 가지 측면을 다룹니다. 방법 가이드의 전체 목록은 Azure Red Hat OpenShift 설명서를 참조 하세요.

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

Azure Red Hat OpenShift가 적절한 배포 대상이라고 결정한 후에는 IBM WebSphere Liberty 연산자 또는 Open Liberty 운영자(운영자)가 Kubernetes에서 Liberty를 실행하는 유일한 방법임을 동의해야 합니다. 이 사실을 수락한 후에는 미리 빌드 된 Azure Marketplace 제품이 좋은 시작점인지 여부를 결정해야 합니다. 미리 빌드된 Azure Marketplace 제품에 대해 고려해야 할 몇 가지 사항은 다음과 같습니다.

  • IBM과 Microsoft는 Azure Red Hat OpenShift에서 Liberty를 신속하게 프로비전할 수 있도록 이 제품을 만들었습니다. 이 개념은 다음 콘텐츠에 자세히 설명되어 있습니다.
  • 높은 수준에서 제품은 다음 단계를 자동화합니다.
    • 원하는 경우 기존 애플리케이션 이미지를 사용합니다.
    • 원하는 경우 Azure Red Hat OpenShift 클러스터를 프로비전합니다.
    • Azure Red Hat OpenShift에서 IBM WebSphere Liberty 연산자 또는 Open Liberty 연산자를 설치하고 구성합니다.
    • 연산자를 사용하여 모든 작업을 실행합니다. 운영자는 Azure Red Hat OpenShift에서 컨테이너화된 Liberty 애플리케이션을 배포하고 관리합니다. IBM WebSphere Liberty 연산자 및 Open Liberty 연산자에서 참조 설명서를 찾을 수 있습니다.

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

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

Liberty 버전이 호환되는지 확인

Kubernetes 기반 클러스터에서 애플리케이션을 배포하고 관리하려면 Open Liberty 연산 자 또는 WebSphere Liberty 연산 자가 필요합니다. 기존 Liberty 버전이 운영자가 지원하는 버전 중 하나인지 확인합니다. Open Liberty 버전은 GitHub OpenLiberty/open-liberty에서 유지 관리됩니다. IBM은 IBM WebSphere Application Server Liberty 버전을 유지 관리합니다. 자세한 내용은 WebSphere Application Server Liberty를 참조하세요.

미리 빌드된 Azure Marketplace 제품을 사용하면 공용 레지스트리에서 애플리케이션 이미지를 선택할 수 있으므로 모든 버전을 암시적으로 지원합니다.

라이선스가 필요한지 확인

IBM WebSphere Liberty의 경우 애플리케이션 컨테이너의 IBM 프로그램 버전에 해당하는 사용권 계약에 대한 조건에 동의해야 합니다. 이 IBM 프로그램에 적용되는 사용권 계약은 WebSphere Liberty 운영자에 대한 라이선스 정보 보기를 참조하세요. 자세한 내용은 Microsoft Azure에서 WebSphere Liberty 실행을 참조 하세요.

제품 버전이 기본 IBM WebSphere 애플리케이션 서버(기본) .spec.license.edition value 이외의 버전인 경우 제품 버전을 지정해야 합니다. 다른 사용 가능한 값은 IBM WebSphere Application Server Liberty Core 및 IBM WebSphere 애플리케이션 서버 네트워크 배포입니다. 미리 빌드된 Azure Marketplace 제품을 사용하면 지원되는 제품 버전을 선택할 수 있습니다.

IBM 마이그레이션 도구를 사용하는 인벤토리 차이점

애플리케이션을 WebSphere Application Server Liberty 또는 Open Liberty로 이동하려면 마이그레이션을 계획하고, 애플리케이션을 분석하고, 소스 코드를 업데이트해야 합니다. IBM은 현재 환경과 Java EE 7 또는 Java EE 8, Java SE 8 또는 Java SE 11과 같은 새로운 Liberty 환경의 기술 간의 차이를 식별하는 데 도움이 되는 마이그레이션 도구를 제공합니다. 자세한 내용은 Liberty로 애플리케이션 마이그레이션을 참조하세요.

서버 용량 인벤토리화

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

사용하지 않는 용량을 상당한 비용 절감으로 활용하려면 Azure Red Hat OpenShift에서 Azure Spot Virtual Machines를 사용할 수 있습니다. 방법을 알아보려면 Azure Red Hat OpenShift 클러스터에서 Azure Spot Virtual Machines 사용을 참조 하세요.

모든 비밀 인벤토리화

Azure Key Vault와 같은 "서비스로 구성" 기술이 도입되기 전에는 "비밀"이라는 개념이 잘 정의되지 않았습니다. 그 대신 우리가 현재 "비밀"이라고 부르는 기능을 효율적으로 수행하는 별도의 구성 세트가 있었습니다. WAS와 같은 앱 서버를 사용하면 이러한 비밀은 다양한 구성 파일 및 구성 저장소에 있습니다. 프로덕션 서버의 모든 속성 및 구성 파일에 비밀과 암호가 있는지 확인합니다. 애플리케이션 내에서도 암호 또는 자격 증명을 포함하는 구성 파일을 찾을 수 있습니다. WAS는 여러 문서에 구성 데이터를 디렉터리의 연속 계층 구조에 저장합니다. 대부분의 구성 문서에는 XML 콘텐츠가 있습니다. 자세한 내용은 구성 문서 및 Azure Key Vault 기본 개념을 참조하세요.

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

모든 인증서 인벤토리화

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

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

인증서의 견고한 인벤토리가 있으면 다음 문서를 사용하여 구성합니다.

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

Liberty를 사용하려면 특정 버전의 Java가 필요하므로 지원되는 버전을 사용하여 애플리케이션이 올바르게 실행되는지 확인해야 합니다.

WebSphere Application Server Liberty의 런타임에는 JRE(Java 런타임 환경)의 최소 수준에 대한 특정 요구 사항이 있습니다. 자세한 내용은 기능에 대한 Java 버전 종속성을 참조 하세요.

Open Liberty에는 Java SE 런타임이 필요합니다. JRE(Java Runtime Environment) 또는 JDK(Java SE Development Kit) 배포를 사용하여 실행할 수 있습니다. 자세한 내용은 지원되는 Java SE 릴리스를 참조 하세요.

JNDI 리소스 인벤토리화

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

미리 빌드된 Azure Marketplace 제품을 사용하는 경우 배포 시 사용자 지정할 수 있는 JNDI 리소스 집합은 제품이 지원하는 항목으로 제한됩니다. AKS(Azure Kubernetes Service)의 WebSphere Liberty의 경우 기본 JNDI(Java Naming and Directory Interface) 네임스페이스에서 개체를 사용할 수 있도록 할 수 있습니다. 자세한 내용은 Liberty 기능에서 JNDI 기본 네임스페이스를 사용하여 개발을 참조 하세요. Open Liberty의 경우 Java 명명 및 디렉터리 인터페이스를 참조 하세요.

프로필 구성 검사

WAS의 기본 구성 단위는 프로필입니다. 따라서 resources.xml 파일에는 마이그레이션을 위해 신중하게 고려해야 하는 다양한 구성이 포함되어 있습니다. 파일에는 하위 디렉터리에 저장된 다른 XML 파일에 대한 참조가 포함됩니다. 자세한 내용은 분산 및 IBM i 운영 체제의 프로필 관리를 참조 하세요.

애플리케이션 내부

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

Azure Red Hat OpenShift가 실행되는 컨테이너 이미지에서 이러한 사용자 지정을 캡처해야 합니다. 미리 빌드된 Azure Marketplace 제품을 사용하는 경우 이러한 사용자 지정은 사용자 지정 컨테이너 이미지를 만들고 공용 레지스트리에서 사용할 수 있게 한 다음 배포 시 해당 레지스트리를 가리키는 방식으로 가장 잘 처리됩니다.

WebSphere Application Server 네트워크 배포 셀을 사용하는 경우 각 클러스터 멤버는 기존 WAS 설치에서 실행됩니다. Liberty는 WebSphere 애플리케이션 서버의 경량 프로필입니다. WAS 서버가 사용 가능한 대규모 JEE 구성 요소 집합을 배포하는 대신 필요한 사용자 지정 기능만 배포할 수 있도록 하는 WAS의 유연하고 동적 프로필입니다.

세션 복제 사용 여부 확인

애플리케이션이 세션 복제를 사용하는 경우 다음과 같은 옵션이 있습니다.

  • HTTP 세션의 경우 세션 관리 수준에 따라 캐시 또는 데이터베이스를 사용하여 세션 데이터를 수집할 수 있습니다.
  • 분산 세션의 경우 데이터베이스 세션 지속성을 사용하여 데이터베이스에 세션을 저장할 수 있습니다.
  • 동적 캐시의 경우 캐시 또는 데이터베이스에서 세션 데이터를 관리할 수 있습니다.
  • 세션 관리에 데이터베이스를 사용하도록 애플리케이션을 리팩터링할 수 있습니다.
  • 애플리케이션을 리팩터링하여 세션을 Azure Redis Service로 외부화할 수 있습니다. 자세한 내용은 Azure Cache for Redis를 참조하세요.

이러한 모든 옵션의 경우 Liberty가 HTTP 세션 상태 복제를 수행하는 방법을 마스터하는 것이 좋습니다. 다음 문서는 Liberty에서 HTTP 세션을 관리하는 방법을 이해하는 데 도움이 됩니다.

문서 데이터 원본

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

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

WAS의 JDBC 드라이버에 대한 자세한 내용은 WebSphere 애플리케이션 서버에서 JDBC 드라이버 사용을 참조 하세요.

JDBC 구성은 Liberty의 핵심 서버 구성입니다. 자세한 내용은 JDBC 드라이버를 참조 하세요.

미리 빌드된 Azure Marketplace 제품은 데이터베이스에 대한 지원이 제한되어 있습니다. 애플리케이션 이미지에서 구성을 처리하고 제품을 배포할 때 이미지를 사용할 수 있습니다.

WAS가 사용자 지정되었는지 확인

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

  • 시작 스크립트가 변경되었나요? 이러한 스크립트에는 wsadmin, AdminControl, AdminConfig, AdminApp 및 AdminTask가 포함됩니다.
  • JVM에 전달된 특정 매개 변수가 있나요?
  • 서버 클래스 경로에 JAR이 추가되어 있나요?
  • 서버를 다시 시작한 후 WAS 구성 요소가 자동으로 시작되도록 하는 데 사용되는 OS systemd 수준 기능이 있나요?

이러한 질문에 대한 답변에 따라 마이그레이션 고려 사항을 고려해야 합니다.

Azure Red Hat OpenShift가 실행되는 컨테이너 이미지에서 이러한 사용자 지정을 캡처해야 합니다. 미리 빌드된 Azure Marketplace 제품을 사용하는 경우 이러한 사용자 지정은 사용자 지정 컨테이너 이미지를 만들고 공용 레지스트리에서 사용할 수 있게 한 다음 배포 시 해당 레지스트리를 가리키는 방식으로 가장 잘 처리됩니다.

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

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

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

애플리케이션에서 JMS 큐 또는 토픽을 사용하는 경우 외부에 호스트된 JMS 서버로 마이그레이션해야 합니다. JMS를 사용하는 사람들을 위한 한 가지 전략은 Azure Service Bus 및 고급 메시지 큐 프로토콜을 사용하는 것입니다. 자세한 내용은 Azure Service Bus 표준 및 AMQP 1.0에서 Java Message Service 1.1 사용을 참조 하세요.

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

IBM MQ를 사용하는 경우 이 소프트웨어를 Azure Virtual Machines로 마이그레이션하고 있는 그대로 사용할 수 있습니다.

Microsoft에는 IBM MQ와 Logic Apps를 통합하는 솔루션이 있습니다. 자세한 내용은 Azure Logic Apps의 워크플로에서 IBM MQ 서버에 연결을 참조하세요.

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

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

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

Java EE 애플리케이션에서 타사 API 액세스에 설명된 것과 동일한 기술을 사용하여 이러한 라이브러리를 처리할 수 있습니다.

OSGi 번들이 사용되는지 확인

WAS에 추가된 OSGi 번들을 사용한 경우 해당 JAR 파일을 웹 애플리케이션에 직접 추가해야 합니다.

미리 빌드된 Azure Marketplace 제품에 제공된 이미지에 번들을 포함할 수 있습니다. 자세한 내용은 OSGi 애플리케이션에 대한 라이브러리 구성을 참조 하세요.

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

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

Azure Red Hat OpenShift의 Liberty는 Linux x86_64 실행됩니다. 모든 OS 관련 코드는 Linux와 호환되어야 합니다. 특정 OS 정보를 검색하는 방법을 알아보려면 Liberty 버전이 호환되는지 여부 확인 섹션의 단계를 따르세요.

IBM Integration Bus가 사용 중인지 확인

애플리케이션이 IBM Integration Bus를 사용하는 경우 IBM Integration Bus가 구성된 방법을 캡처해야 합니다. 자세한 내용은 IBM Integration Bus 설명서를 참조 하세요.

IBM Integration Bus는 미리 빌드된 Azure Marketplace 제품에서 직접 지원되지 않습니다. 이 기능을 사용하도록 설정하려면 LIBERTY에서 JMS 애플리케이션을 사용하도록 설정하여 IBM 설명서의 서비스 통합 버스 에 연결하기 위한 지침을 따릅니다.

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

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

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

애플리케이션이 EAR 파일로 패키지된 경우 application.xml, ibm-application-bnd.xmi 및 ibm-application-ext.xmi 파일을 검사하고 해당 구성을 캡처해야 합니다. 자세한 내용은 WebSphere에서 EAR(Enterprise Archive) 패키지 빌드를 참조 하세요.

미리 빌드된 Azure Marketplace 제품을 사용하면 기존 컨테이너 이미지를 사용할 수 있습니다. 비즈니스 요구 사항에 따라 애플리케이션을 준비할 수 있습니다.

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

디먼 모니터링과 같이 애플리케이션 서버 외부에서 실행되는 프로세스가 있는 경우 이러한 프로세스를 제거하거나 다른 곳으로 마이그레이션해야 합니다.

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

Kubernetes는 PV(영구 볼륨)를 사용하는 파일 시스템을 처리합니다. 미리 빌드된 Azure Marketplace 제품에서는 영구 볼륨 탑재가 지원되지 않습니다. Azure Files StorageClass를 만들려면 Azure Red Hat OpenShift 4에서 Azure Files StorageClass 만들기의 지침을 따릅니다.

읽기 전용 정적 콘텐츠

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

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

애플리케이션이 애플리케이션에서 업로드/생성되었지만 생성 후 변경할 수 없는 정적 콘텐츠를 허용하는 경우, 위에서 설명한 대로 Azure Blob Storage 및 Azure CDN과 Azure Function을 사용하여 업로드 및 CDN 새로 고침을 처리할 수 있습니다. Azure Functions를 사용하여 정적 콘텐츠 업로드 및 CDN 사전 로드에서 사용할 샘플 구현을 제공했습니다.

네트워크 토폴로지 확인

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

네트워크 토폴로지는 광범위한 항목이지만 다음 참조는 마이그레이션 노력에 대한 몇 가지 방향을 제시할 수 있습니다.

JCA 어댑터 및 리소스 어댑터 사용 계정

기존 애플리케이션이 JCA 어댑터 또는 리소스 어댑터를 사용하여 다른 엔터프라이즈 시스템에 연결하는 경우 AKS(Azure Kubernetes Service)에서 실행되는 Liberty 서버에 이러한 아티팩트 구성을 적용해야 합니다. 자세한 내용은 JCA 구성 요소 및 Java 커넥터 아키텍처 개요를 참조하세요.

클러스터링 사용 여부 확인

운영자는 Azure Red Hat OpenShift에서 WAS 워크로드를 실행하는 가능한 모든 방법에 대해 클러스터링을 처리합니다.

EJB 클러스터링 검사

애플리케이션이 로컬 EJB(Enterprise Java Beans)를 사용하는 경우 클러스터형 EJB로 마이그레이션해야 할 수 있습니다. 자세한 내용은 Liberty에서 EJB 애플리케이션 개발을 참조하세요.

부하 분산 요구 사항 고려

미리 빌드된 Azure Marketplace 제품은 OpenShift 기본 제공 경로를 사용하여 공용 URL에서 애플리케이션을 호스트하고 부하 분산을 고려합니다. 자세한 내용은 OpenShift 경로 구성을 참조하세요.

마이그레이션

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

제품 프로비전

Azure Portal에서 제품을 열려면 Azure Red Hat OpenShift에서 IBM WebSphere Liberty 및 Open Liberty를 참조하세요. 만들기를 선택한 다음, 이전 단계에서 수집한 정보를 사용하여 제품의 필드를 작성하는 데 도움을 줍니다.

KeyStores 계정

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

JMS 원본 연결

데이터베이스를 연결한 후에는 IBM 설명서의 JCA 구성 요소 개요 지침에 따라 JMS를 구성할 수 있습니다.

로깅 계정

로깅을 마스터하지 않으면 클라우드를 수행할 수 없습니다. 연산자는 모니터링을 위한 다양한 접근 방식을 제공합니다. 자세한 내용은 Liberty 서버 런타임 환경 모니터링을 참조 하세요. Red Hat OpenShift에서 로깅 및 모니터링 시스템을 마스터하는 것이 유용합니다. 자세한 내용은 Red Hat OpenShift 및 OpenShift Container Platform 모니터링에 대한 로깅 하위 시스템 이해를 참조하세요. Azure Red Hat OpenShift에 대한 Azure Monitor 컨테이너 인사이트를 구성할 수 있습니다. 자세한 내용은 Azure Red Hat OpenShift에 대한 Azure Monitor 컨테이너 인사이트 구성을 참조하세요. Elastic Stack을 사용하는 것을 선호하는 경우 Azure는 Elastic에 대한 훌륭한 지원을 제공합니다. 자세한 내용은 Azure와 탄력적 통합이란? 이러한 리소스에 대한 지식을 결합하여 Azure Red Hat OpenShift의 Liberty에 대한 Azure 최적화 로깅 솔루션을 달성할 수 있습니다.

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

배포 시 애플리케이션 이미지를 제공하도록 선택했는지 여부에 관계없이 CI/CD를 통해 애플리케이션을 업데이트해야 합니다. OpenShift 설명서에는 이 업데이트를 수행하는 방법을 보여 주는 샘플이 있습니다. 자세한 내용은 OpenShift Container Platform CI/CD 개요를 참조 하세요.

테스트 구성

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

마이그레이션 후

마이그레이션 전 단계에서 정의한 마이그레이션 목표에 도달한 후 일부 종단 간 승인 테스트를 수행하여 모든 것이 예상대로 작동하는지 확인합니다. 다음 문서에서는 마이그레이션 후 개선 사항에 대한 정보를 제공합니다.