Open Liberty 또는 WebSphere Liberty를 사용하여 Azure Kubernetes Service 클러스터에 Java 애플리케이션을 배포합니다.

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

  • Open Liberty 또는 IBM WebSphere Liberty 런타임에서 Java, Java EE, Jakarta EE 또는 MicroProfile 애플리케이션을 실행합니다.
  • Open Liberty 또는 WebSphere Liberty 컨테이너 이미지를 사용하여 애플리케이션의 Docker 이미지를 빌드합니다.
  • Open Liberty Operator 또는 WebSphere Liberty Operator를 사용하여 AKS(Azure Kubernetes Service) 클러스터에 컨테이너화된 애플리케이션을 배포합니다.

Open Liberty Operator는 Kubernetes 클러스터에서 실행되는 애플리케이션의 배포 및 관리를 간소화합니다. Open Liberty Operator 또는 WebSphere Liberty Operator를 사용하여 추적 및 덤프 수집과 같은 고급 작업을 수행할 수도 있습니다.

이 문서에서는 AKS로의 과정을 가속화하기 위해 Open Liberty 또는 WebSphere Liberty용 Azure Marketplace 제안을 사용합니다. 이 제품은 다음을 포함하여 일부 Azure 리소스를 자동으로 프로비전합니다.

  • Azure Container Registry 인스턴스.
  • AKS 클러스터.
  • AGIC(Application Gateway 수신 컨트롤러) 인스턴스입니다.
  • Open Liberty Operator 및 WebSphere Liberty Operator.
  • 선택적으로 Liberty 및 애플리케이션을 포함하는 컨테이너 이미지.

AKS에서 Liberty를 실행하기 위한 수동 단계별 지침을 선호하는 경우 AKS(Azure Kubernetes Service) 클러스터에서 Open Liberty 또는 WebSphere Liberty를 사용하여 Java 애플리케이션 수동 배포를 참조하세요.

이 문서는 빠르게 배포할 수 있도록 지원하기 위한 것입니다. 프로덕션으로 이동하기 전에 Liberty 튜닝에 관한 IBM 설명서를 살펴봅니다.

Azure를 구독하고 있지 않다면 시작하기 전에 Azure 체험 계정을 만듭니다.

필수 조건

  • Azure CLI를 설치합니다. Windows 또는 macOS에서 실행 중인 경우 Docker 컨테이너에서 Azure CLI를 실행하는 것이 좋습니다. 자세한 내용은 Docker 컨테이너에서 Azure CLI를 실행하는 방법을 참조하세요.
  • az login 명령을 사용하여 Azure CLI에 로그인합니다. 인증 프로세스를 완료하려면 터미널에 표시되는 단계를 수행합니다. 다른 로그인 옵션은 Azure CLI를 사용하여 로그인을 참조하세요.
  • 메시지가 표시되면 처음 사용할 때 Azure CLI 확장을 설치합니다. 확장에 대한 자세한 내용은 Azure CLI에서 확장 사용을 참조하세요.
  • az version을 실행하여 설치된 버전과 종속 라이브러리를 찾습니다. 최신 버전으로 업그레이드하려면 az upgrade를 실행합니다. 이 문서에는 Azure CLI 버전 2.31.0 이상이 필요합니다.
  • Java SE 구현 버전 17 이상을 설치합니다. 예를 들면 Eclipse Open J9입니다.
  • Maven 3.5.0 이상을 설치합니다.
  • 해당 OS용 Docker를 설치합니다.
  • Git이 설치되어 있는지 확인합니다.
  • 구독에서 Owner 역할이나 ContributorUser Access Administrator 역할이 할당되어 있는지 확인합니다. 사용자 또는 그룹에 대한 역할 할당 나열의 단계에 따라 이를 확인할 수 있습니다.

참고 항목

Azure Cloud Shell에서 이 문서의 명령을 실행할 수도 있습니다. 이 방식에는 Docker를 제외한 모든 필수 구성 요소 도구가 미리 설치되어 있습니다.

  • 이 가이드의 명령을 (Azure Cloud Shell 대신) 로컬로 실행하는 경우:
    • Unix 계열 운영 체제(예: Ubuntu, Azure Linux 또는 macOS, Linux용 Windows 하위 시스템)가 설치된 로컬 컴퓨터를 준비합니다.
    • Java SE 구현 버전 17 이상을 설치합니다. 예를 들면 Eclipse Open J9입니다.
    • Maven 3.5.0 이상을 설치합니다.
    • 해당 OS용 Docker를 설치합니다.
  • 구독에서 Owner 역할이나 ContributorUser Access Administrator 역할이 할당되어 있는지 확인합니다. 사용자 또는 그룹에 대한 역할 할당 나열의 단계에 따라 이를 확인할 수 있습니다.

포털을 사용하여 AKS 배포에서 Liberty 만들기

다음 단계는 AKS에서 Liberty 런타임을 작성하도록 안내합니다. 이러한 단계를 완료하면 컨테이너화된 애플리케이션을 배포하기 위한 Container Registry 인스턴스와 AKS 클러스터가 준비됩니다.

  1. Azure Portal로 이동합니다. 페이지 상단의 검색 상자에 IBM Liberty on AKS를 입력합니다. 제안이 나타나면 Marketplace 섹션에서 유일하게 일치하는 항목을 선택합니다.

    원하는 경우 제안으로 직접 이동할 수 있습니다.

  2. 만들기를 실행합니다.

  3. 기본 창에서 다음을 수행합니다.

    1. 새 리소스 그룹 만들기 리소스 그룹은 구독 내에서 고유해야 하므로 고유한 이름을 선택합니다. 이름이 고유하도록 하는 쉬운 방법은 이니셜, 오늘 날짜, 일부 식별자의 조합을 사용하는 것입니다(예: ejb0913-java-liberty-project-rg).

    2. 지역에 대해 미국 동부를 선택합니다.

    3. 클러스터 및 데이터베이스의 리소스 그룹 이름에 대한 셸에서 환경 변수를 만듭니다.

      export RESOURCE_GROUP_NAME=<your-resource-group-name>
      

  4. 다음을 선택합니다. 배포 시 새 인스턴스를 만드는 대신 AKS 창에서 선택적으로 기존 AKS 클러스터 및 Container Registry 인스턴스를 선택할 수 있습니다. 이 선택을 통해 Azure 아키텍처 센터에 표시된 대로 사이드카 패턴을 사용할 수 있습니다. AKS 노드 풀에 있는 가상 머신의 크기 및 수에 대한 설정을 조정할 수도 있습니다.

    이 문서의 목적에 따라 이 창의 모든 기본값을 유지합니다.

  5. 다음을 선택합니다. 부하 분산 창에서 Azure Application Gateway에 연결하려고 하나요? 옆에 있는 를 선택합니다. 이 섹션에서는 다음 배포 옵션을 사용자 지정할 수 있습니다.

    • 가상 네트워크서브넷의 경우 배포 시 리소스가 배치되는 가상 네트워크와 서브넷을 선택적으로 사용자 지정할 수 있습니다. 기본값에서 나머지 값을 변경할 필요가 없습니다.

    • TLS/SSL 인증서의 경우 Azure Application Gateway에서 TLS/SSL 인증서를 제공할 수 있습니다. 제품이 자체 서명된 인증서를 생성하도록 하려면 이러한 값을 기본값으로 둡니다.

      자체 서명된 인증서를 사용하여 프로덕션으로 이동하지 마세요. 자체 서명된 인증서에 대한 자세한 내용은 애플리케이션 인증을 위한 자체 서명된 공용 인증서 만들기를 참조하세요.

    • 고정 세션이라고도 하는 쿠키 기반 선호도 사용을 선택할 수 있습니다. 이 문서에서는 고정 세션을 사용하므로 이 옵션을 선택해야 합니다.

  6. 다음을 선택합니다. 이 문서에서는 연산자 및 애플리케이션 창에서 모든 기본값을 사용합니다. 그러나 다음 배포 옵션을 사용자 지정할 수 있습니다.

    • IBM에서 지원 옵션에 를 선택하여 WebSphere Liberty Operator를 배포할 수 있습니다. 기본값을 그대로 두면 Open Liberty Operator가 배포되지 않습니다.
    • 애플리케이션 배포 옵션에 를 선택하여 선택한 연산자의 애플리케이션을 배포할 수 있습니다. 기본값을 그대로 두면 애플리케이션이 배포되지 않습니다.
  7. 검토 + 만들기를 선택하여 선택한 옵션의 유효성을 검사합니다. 검토 + 만들기 창에서 유효성 검사를 통과한 후 만들기를 사용할 수 있게 되면 이를 선택합니다.

    배포는 최대 20분까지 걸릴 수 있습니다. 배포가 완료될 때까지 기다리는 동안 Azure SQL Database 인스턴스 만들기 섹션의 단계를 따를 수 있습니다. 해당 섹션을 완료한 후 여기로 돌아와 계속합니다.

배포에서 선택한 정보 캡처

배포 진행 중 창에서 다른 곳으로 이동한 경우 다음 단계에 따라 해당 창으로 돌아가는 방법이 표시됩니다. 여전히 배포가 완료되었습니다라고 표시된 창에 있는 경우 새로 만들어진 리소스 그룹으로 이동하여 세 번째 단계로 건너뜁니다.

  1. 포털 페이지 모서리에서 메뉴 단추를 선택한 다음 리소스 그룹을 선택합니다.

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

  3. 리소스 그룹의 리소스 목록에서 유형 값이 컨테이너 레지스트리인 리소스를 선택합니다.

  4. 탐색 창의 설정에서 액세스 키를 선택합니다.

  5. 로그인 서버, 레지스트리 이름, 사용자 이름암호 값을 따로 저장합니다. 각 필드 옆에 있는 복사 아이콘을 사용하여 값을 시스템 클립보드에 복사할 수 있습니다.

  6. 리소스를 배포한 리소스 그룹으로 돌아갑니다.

  7. 설정 섹션에서 배포를 선택합니다.

  8. 목록에서 맨 아래에 있는 배포를 선택합니다. 배포 이름 값은 제품의 게시자 ID와 일치합니다. 여기에는 ibm 문자열이 포함되어 있습니다.

  9. 탐색 창에서 출력을 선택합니다.

  10. 이전 값과 동일한 복사 기술을 사용하여 다음 출력에 대한 값을 따로 저장합니다.

    • cmdToConnectToCluster
    • 배포에 애플리케이션이 포함되지 않은 경우 appDeploymentTemplateYaml입니다. 즉, Marketplace 제품을 배포할 때 애플리케이션을 배포하려고 하나요?에 대해 아니요를 선택했습니다.
    • 배포에 애플리케이션이 포함된 경우 appDeploymentYaml입니다. 즉, 애플리케이션을 배포하려고 하나요?에 대해 를 선택했습니다.

    appDeploymentTemplateYaml 또는 appDeploymentYaml 값을 Bash 셸에 붙여넣고 | grep secretName을 추가한 후 명령을 실행합니다.

    이 명령의 출력은 수신 TLS 비밀 이름(예: - secretName: secret785e2c)입니다. secretName 값을 따로 저장합니다.

이 문서의 뒷부분에서 이러한 값을 사용하게 됩니다. 출력에는 몇 가지 다른 유용한 명령이 나열되어 있습니다.

Azure SQL Database 관리형 인스턴스 생성

앱에서 사용할 Azure SQL Database 단일 데이터베이스를 만들려면 빠른 시작: Azure SQL Database에서 단일 데이터베이스 만들기 단계를 따릅니다. 다음 차이점을 주의 깊게 살펴봅니다.

  • 기본 사항 단계에서 리소스 그룹, 데이터베이스 이름, <server-name>.database.windows.net, 서버 관리자 로그인암호에 대한 값을 적어둡니다. 이 문서에서는 데이터베이스 리소스 그룹 값을 <db-resource-group>으로 참조하세요.

  • 네트워킹 단계에서 연결 방법공용 엔드포인트로 설정하고, Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용로 설정하고, 현재 클라이언트 IP 주소 추가로 설정합니다.

    연결 방법 및 방화벽 규칙 설정이 강조 표시된 SQL Database 만들기 페이지의 네트워킹 탭을 보여 주는 Azure Portal의 스크린샷.

참고 항목

이 데이터베이스에 대해 선택한 서버리스 컴퓨팅 계층은 비활성 기간 동안 데이터베이스를 절전 모드로 전환하여 비용을 절약합니다. 앱이 시작될 때 데이터베이스가 절전 상태가 되면 샘플 앱이 실패합니다.

데이터베이스의 절전 모드를 강제로 해제하려면 쿼리 편집기를 사용하여 쿼리를 실행하면 됩니다. 데이터베이스 쿼리의 단계를 따릅니다. 다음은 쿼리 예입니다. SELECT * FROM COFFEE;

데이터베이스의 리소스 그룹 이름에 대한 셸에서 환경 변수를 만듭니다.

export DB_RESOURCE_GROUP_NAME=<db-resource-group>

이제 데이터베이스와 AKS 클러스터를 만들었으므로 Open Liberty 애플리케이션을 호스팅하기 위해 AKS를 준비할 수 있습니다.

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

이 섹션의 단계에 따라 Liberty 런타임에 샘플 애플리케이션을 배치합니다. 이러한 단계에서는 Maven을 사용합니다.

애플리케이션 체크 아웃

이 문서의 샘플 코드를 복제합니다. 샘플은 GitHub에 있습니다.

리포지토리에 몇 가지 샘플이 있습니다. 이 문서에서는 java-app/을 사용합니다. 샘플을 가져오려면 다음 명령을 실행합니다.

git clone https://github.com/Azure-Samples/open-liberty-on-aks.git
cd open-liberty-on-aks
export BASE_DIR=$PWD
git checkout 20240220

"분리된 HEAD" 상태에 관한 메시지가 표시되면 무시해도 됩니다. 이 메시지는 사용자가 태그를 체크 아웃했다는의미일 뿐입니다.

애플리케이션의 파일 구조는 다음과 같습니다.

java-app
├─ src/main/
│  ├─ aks/
│  │  ├─ db-secret.yaml
│  │  ├─ openlibertyapplication-agic.yaml
│  │  ├─ openlibertyapplication.yaml
│  │  ├─ webspherelibertyapplication-agic.yaml
│  │  ├─ webspherelibertyapplication.yaml
│  ├─ docker/
│  │  ├─ Dockerfile
│  │  ├─ Dockerfile-wlp
│  ├─ liberty/config/
│  │  ├─ server.xml
│  ├─ java/
│  ├─ resources/
│  ├─ webapp/
├─ pom.xml

Java, 리소스웹앱 디렉터리에는 응용 프로그램 예제의 소스 코드가 포함됩니다. 이 코드는 jdbc/JavaEECafeDB(이)라는 데이터 원본을 선언하고 사용합니다.

aks 디렉터리에는 배포 파일 5개가 있습니다.

  • db-secret.xml: 이 파일을 사용하여 데이터베이스 연결 자격 증명으로 Kubernetes 비밀을 만듭니다.
  • openlibertyapplication-agic.yaml: 이 파일을 사용하여 AGIC와 함께 Open Liberty 애플리케이션을 배포합니다. 이 문서에서는 이 파일을 사용한다고 가정합니다.
  • openliberty application.yml: MAGIC 없이 Open Liberty 애플리케이션을 배포하려면 이 파일을 사용합니다.
  • webspherelibertyapplication-agic.yaml: 이 문서의 앞부분에서 WebSphere Liberty Operator를 배포한 경우 이 파일을 사용하여 AGIC와 함께 WebSphere Liberty 애플리케이션을 배포합니다.
  • webspherelibertyapplication.yaml: 이 문서의 앞부분에서 WebSphere Liberty Operator를 배포한 경우 이 파일을 사용하여 AGIC 없이 WebSphere Liberty 애플리케이션을 배포합니다.

docker 디렉터리에는 애플리케이션 이미지를 만들기 위한 두 개의 파일이 있습니다.

  • Dockerfile: 이 문서에서는 이 파일을 사용하여 Open Liberty로 애플리케이션 이미지를 빌드합니다.
  • Dockerfile-wlp: 이 문서의 앞부분에서 WebSphere Liberty Operator를 배포한 경우 이 파일을 사용하여 WebSphere Liberty로 애플리케이션 이미지를 빌드합니다.

liberty/config 디렉터리에서 server.xml 파일을 사용하여 Open Liberty 및 WebSphere Liberty 클러스터에 대한 데이터베이스 연결을 구성합니다.

프로젝트 빌드

이제 필요한 속성이 있으므로 애플리케이션을 빌드할 수 있습니다. 프로젝트의 POM 파일은 환경에서 많은 변수를 읽습니다. Maven 빌드의 일부로 이러한 변수는 src/main/aks에 있는 YAML 파일의 값을 채우는 데 사용됩니다. 원하는 경우 Maven 외부에서 애플리케이션에 대해 비슷한 작업을 수행할 수 있습니다.

cd $BASE_DIR/java-app
# The following variables are used for deployment file generation into the target.
export LOGIN_SERVER=<Azure-Container-Registry-Login-Server-URL>
export REGISTRY_NAME=<Azure-Container-Registry-name>
export USER_NAME=<Azure-Container-Registry-username>
export PASSWORD='<Azure-Container-Registry-password>'
export DB_SERVER_NAME=<server-name>.database.windows.net
export DB_NAME=<database-name>
export DB_USER=<server-admin-login>@<server-name>
export DB_PASSWORD='<server-admin-password>'
export INGRESS_TLS_SECRET=<ingress-TLS-secret-name>

mvn clean install

(선택 사항) 로컬로 프로젝트 테스트

Azure에 배포하기 전에 로컬에서 프로젝트를 실행하고 테스트합니다. 편의상 이 문서에서는 liberty-maven-plugin을 사용합니다. liberty-maven-plugin에 대해 자세히 알아보려면 Open Liberty 문서 Maven을 사용하여 웹 애플리케이션 빌드을 참조하세요.

애플리케이션의 경우 로컬 개발 환경과 같은 다른 메커니즘을 사용하여 유사한 작업을 수행할 수 있습니다. 컨테이너를 통한 개발에 사용되는 liberty:devc 옵션을 사용하는 것도 고려할 수 있습니다. Open Liberty 설명서에서 liberty:devc에 대한 자세한 내용을 읽을 수 있습니다.

  1. liberty:run을 사용하여 애플리케이션을 시작합니다. liberty:run도 이전에 정의한 환경 변수를 사용합니다.

    cd $BASE_DIR/java-app
    mvn liberty:run
    
  2. 테스트가 성공하면 명령 출력에 [INFO] [AUDIT] CWWKZ0003I: The application javaee-cafe updated in 1.930 seconds와 유사한 메시지가 나타납니다. 브라우저의 http://localhost:9080/으로 이동하여 애플리케이션에 액세스할 수 있고 모든 함수가 작동하는지 확인합니다.

  3. 중지하려면 Ctrl+C를 선택합니다.

AKS 배포를 위한 이미지 빌드

이제 docker build 명령을 실행하여 이미지를 빌드할 수 있습니다.

cd $BASE_DIR/java-app/target

docker buildx build --platform linux/amd64 -t javaee-cafe:v1 --pull --file=Dockerfile .

(선택 사항) 로컬로 Docker 이미지 테스트

Azure에 배포하기 전에 Docker 이미지를 로컬로 테스트하려면 다음 단계를 따릅니다.

  1. 다음 명령을 사용하여 이미지를 실행합니다. 이 명령은 이전에 정의한 환경 변수를 사용합니다.

    docker run -it --rm -p 9080:9080 \
       -e DB_SERVER_NAME=${DB_SERVER_NAME} \
       -e DB_NAME=${DB_NAME} \
       -e DB_USER=${DB_USER} \
       -e DB_PASSWORD=${DB_PASSWORD} \
       javaee-cafe:v1
    
  2. 컨테이너가 시작되면 브라우저에서 http://localhost:9080/로 이동하여 애플리케이션에 액세스합니다.

  3. 중지하려면 Ctrl+C를 선택합니다.

Azure Container Registry에 이미지 업로드

제품에서 만든 Container Registry 인스턴스에 빌드된 이미지를 업로드합니다.

docker tag javaee-cafe:v1 ${LOGIN_SERVER}/javaee-cafe:v1
docker login -u ${USER_NAME} -p ${PASSWORD} ${LOGIN_SERVER}
docker push ${LOGIN_SERVER}/javaee-cafe:v1

애플리케이션 배포 및 테스트

다음 단계를 사용하여 애플리케이션을 배포하고 테스트합니다.

  1. AKS 클러스터에 연결합니다.

    cmdToConnectToCluster 값을 셸에 붙여넣고 명령을 실행합니다.

  2. 데이터베이스 비밀을 적용합니다.

    cd $BASE_DIR/java-app/target
    kubectl apply -f db-secret.yaml
    

    secret/db-secret-sql created가 출력됩니다.

  3. 배포 파일을 적용합니다.

    kubectl apply -f openlibertyapplication-agic.yaml
    
  4. 다음 명령을 사용하여 모든 Pod가 성공적으로 다시 시작될 때까지 기다립니다.

    kubectl get pods --watch
    

    다음 예와 유사한 출력은 모든 Pod가 실행 중임을 나타냅니다.

    NAME                                       READY   STATUS    RESTARTS   AGE
    javaee-cafe-cluster-agic-67cdc95bc-2j2gr   1/1     Running   0          29s
    javaee-cafe-cluster-agic-67cdc95bc-fgtt8   1/1     Running   0          29s
    javaee-cafe-cluster-agic-67cdc95bc-h47qm   1/1     Running   0          29s
    
  5. 결과를 확인합니다.

    1. 애플리케이션과 함께 배포된 수신 리소스의 주소를 가져옵니다.

      kubectl get ingress
      

      출력에서 ADDRESS의 값을 복사합니다. 이 값은 배포된 Application Gateway 인스턴스의 프런트 엔드 공용 IP 주소입니다.

    2. https://<ADDRESS>(으)로 이동하여 애플리케이션을 테스트합니다. 편의를 위해 이 셸 명령은 브라우저에 바로 붙여넣을 수 있는 값을 갖는 환경 변수를 만듭니다.

      export APP_URL=https://$(kubectl get ingress | grep javaee-cafe-cluster-agic-ingress | cut -d " " -f14)/
      echo $APP_URL
      

      웹 페이지가 올바르게 렌더링되지 않거나 502 Bad Gateway 오류를 반환하는 경우 앱이 여전히 백그라운드에서 시작되는 것입니다. 몇 분간 기다린 다음 작업을 다시 시도하세요.

리소스 정리

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

다음 단계

다음 참조에서 자세히 알아볼 수 있습니다.