PKOS - 7주차 졸업 과제 RedHat - Red Hat 개발자 워크샵 Container & Cloud-Native hands-on 후기 (2)

JBoss EAP로 마이그레이션

이 단계에서는 표준(Jakarta EE) 인터페이스를 사용하도록 앱의 일부 Weblogic 관련 코드를 마이그레이션합니다.

 

1. 코드로 이동

식별된 마이그레이션 문제가 포함된 코드로 이동해 보겠습니다. MTA 탐색기에서 monolith 소스 프로젝트를 확장하고 monolith > src > main > java > com > redhat > ​​coolstore > utils > StartupListener.java로 이동합니다. 힌트를 확장하고 표시하려면 실제 클래스 이름 StartupListener.java 옆에 있는 화살표를 클릭해야 합니다 .     

CTRL+p ( Mac OSX에서는 CMD+p )를 사용하여 파일을 빠르게 열 수 있습니다. 표시되는 텍스트 상자에 파일 이름을 입력하고 생성된 목록에서 파일을 선택하기만 하면 됩니다.

Explorer에서 MTA 문제는 아이콘을 사용하여 심각도 수준과 상태를 나타냅니다. 다음 표는 다양한 아이콘의 의미를 설명합니다.

2. 마이그레이션 문제에 대한 세부 정보 보기

마이그레이션 문제에 대한 세부 정보를 살펴보겠습니다. StartupListener.java 파일 의 힌트 에서  WebLogic ApplicationLifecycleListenerEvent[rule-id:xxx]를 마우스 오른쪽 버튼으로 클릭합니다 . 세부 정보 보기 를 클릭합니다 .      

 MTA는 또한 보고서 열기를 클릭할 때 문제를 더 깊이 이해하고 마이그레이션에 대한 지침을 제공하는 유용한 링크를 제공합니다 .

WebLogic  ApplicationLifecycleListener  추상 클래스는 서버 시작 및 중지와 같은 기능을 수행하거나 Oracle WebLogic에서 작업을 예약하는 데 사용됩니다. 이 경우 Weblogic이 시작된 후와 종료되기 전에 각각 실행되는  postStart  및  preStop 메서드에 코드가 있습니다. 

Jakarta EE에는 이러한 이벤트를 가로채는 것과 동등한 기능이 없지만 MTA 보고서의 문제에서 제안된 대로 표준 주석이 있는  Singleton EJB를 사용하여 동등한 기능을 얻을 수 있습니다. 

애플리케이션 시작 시 싱글톤 세션 빈을 초기화하도록 컨테이너에 알리기 위해  @Startup 주석을 사용할 것입니다 .  마찬가지로  @PostConstruct  및  @PreDestroy  주석을 사용하여 독점 인터페이스를 사용하지 않고 동일한 결과를 달성하는 애플리케이션 수명 주기의 시작과 끝에서 호출할 메서드를 지정합니다.

이 방법을 사용하면 코드의 이식성이 훨씬 높아집니다.

3. ApplicationLifecycleListener 문제 수정

이 섹션에서는 보고서의 다음 두 가지 문제를 다룰 것입니다.

시작하려면 Monolith 애플리케이션에서 문제를 수정하고 있습니다. StartupListener.java 파일 의 힌트 에서  WebLogic ApplicationLifecycleListenerEvent[rule-id:xxx]를 클릭합니다 .     

프로젝트 트리에서  cloud-native-workshop-v2m1-labs 폴더로 이동한 다음 monolith/src/main/java/com/redhat/coolstore/utils/StartupListener.java 파일을 클릭하여 열 수도 있습니다 .   

파일 내용을 다음으로 바꿉니다.

package com.redhat.coolstore.utils; import javax.annotation.PostConstruct; import javax.annotation.PreDestroy; import javax.ejb.Startup; import javax.inject.Singleton; import javax.inject.Inject; import java.util.logging.Logger; @Singleton @Startup public class StartupListener { @Inject Logger log; @PostConstruct public void postStart() { log.info("AppListener(postStart)"); } @PreDestroy public void preStop() { log.info("AppListener(preStop)"); } }

 

저장 버튼은 어디에 있습니까? CodeReady 작업 공간은 변경 사항을 자동 저장하므로 SAVE 버튼을 찾을 수 없습니다. 저장하는 것을 잊었기 때문에 더 이상 코드가 손실되지 않습니다.  CTRL-Z  ( Mac에서는  CMD-Z )를 사용하거나 편집 → 실행 취소 메뉴 옵션을 사용하여 실행을 취소할 수 있습니다 .

 

4. 빌드 테스트

 quarkus-tools  컨테이너(오른쪽) 에서 새 터미널 창을 엽니다 . 터미널에서 다음 명령을 실행하여 빌드를 테스트합니다.

mvn -f $CHE_PROJECTS_ROOT/cloud-native-workshop-v2m1-labs/monolith clean package

성공적으로 빌드되면(BUILD SUCCESS가 표시됨  ) 다음 문제로 넘어갑시다! 컴파일되지 않으면 모든 변경 사항을 올바르게 적용했는지 확인하고 빌드를 다시 시도하십시오.

차이점 보기

변경한 내용을 검토할 수 있습니다. 왼쪽에서 변경된 파일 목록을 표시하는  버전 관리 아이콘을 클릭합니다. StartupListener.java를  두 번 클릭하여 변경한 차이점을 확인합니다.  

CodeReady는 변경 사항을 Git을 사용하여 추적하고 버전 제어를 사용하여 변경 시 파일을 체크인, 업데이트 및 비교할 수 있습니다.

 지금은 탐색기 트리 로 돌아가서  나머지 문제를 해결해 보겠습니다.

5. 로거 문제 수정

이 섹션에서는 마이그레이션 보고서의 이 부분을 수정하려고 합니다.

일부 응용 프로그램은 국제화된 콘텐츠 로깅 및 클라이언트-서버 로깅과 관련된 기능을 제공하는 NonCatalogLogger와 같은 Weblogic 관련 로깅 방법을 사용합니다  .

WebLogic  NonCatalogLogger는  JBoss EAP(또는 기타 Java EE 플랫폼)에서 지원되지 않으며 JDK Logger 또는 JBoss Logging과 같은 지원되는 로깅 프레임워크로 마이그레이션해야 합니다.

훨씬 이식성이 뛰어난 프레임워크인 표준 Java 로깅 프레임워크를 사용할 것입니다. 프레임워크도 국제화 지원 필요한 경우.

동일한  모놀리식 디렉터리에서 src/main/java/com/redhat/coolstore/service/OrderServiceMDB.java 파일을  열고 내용을 다음으로 바꿉니다.  

package com.redhat.coolstore.service; import javax.ejb.ActivationConfigProperty; import javax.ejb.MessageDriven; import javax.inject.Inject; import javax.jms.JMSException; import javax.jms.Message; import javax.jms.MessageListener; import javax.jms.TextMessage; import com.redhat.coolstore.model.Order; import com.redhat.coolstore.utils.Transformers; import java.util.logging.Logger; @MessageDriven(name = "OrderServiceMDB", activationConfig = { @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "topic/orders"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"), @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge")}) public class OrderServiceMDB implements MessageListener { @Inject OrderService orderService; @Inject CatalogService catalogService; private Logger log = Logger.getLogger(OrderServiceMDB.class.getName()); @Override public void onMessage(Message rcvMessage) { TextMessage msg = null; try { if (rcvMessage instanceof TextMessage) { msg = (TextMessage) rcvMessage; String orderStr = msg.getBody(String.class); log.info("Received order: " + orderStr); Order order = Transformers.jsonToOrder(orderStr); log.info("Order object is " + order); orderService.save(order); order.getItemList().forEach(orderItem -> { catalogService.updateInventoryItems(orderItem.getProductId(), orderItem.getQuantity()); }); } } catch (JMSException e) { throw new RuntimeException(e); } } }

 

그것은 꽤 쉬웠습니다.

6. 빌드 테스트

이전과 마찬가지로 앱을 다시 빌드하고 패키징합니다.

mvn -f $CHE_PROJECTS_ROOT/cloud-native-workshop-v2m1-labs/monolith clean package

성공적으로 빌드되면(BUILD SUCCESS가 표시됨  ) 다음 문제로 넘어가겠습니다! 컴파일되지 않으면 모든 변경 사항을 올바르게 적용했는지 확인하고 빌드를 다시 시도하십시오.

7. Weblogic EJB 디스크립터 제거

이 섹션과 다음 섹션에서는 보고서의 이 부분을 다룰 것입니다.

좀 더 자세히 강조하려면 다음을 수행하십시오.

• JNDI 조회 호출  - 당사 앱은 웹로직 전용 JNDI 조회 체계.
• 독점 InitialContext 초기화  - Weblogic에는 InitialContext 개체에 대해 매우 다른 조회 메커니즘이 있습니다.
• WebLogic InitialContextFactory  - 위 항목과 관련이 있으며 기본적으로 Weblogic 독점 메커니즘입니다.
• WebLogic T3 JNDI 바인딩  - EJB가 Weblogic에서 통신하는 방식은 Weblogic의 독점 구현인 T2를 통해 이루어집니다.

위의 모든 인터페이스는 JBoss에서 동등한 기능을 가지고 있지만 JBoss에서 제공하는 JBoss EAP의 내부 메시지 큐 구현을 사용하는 애플리케이션에 대해 크게 단순화되고 과도합니다. 아파치 ActiveMQ 아르테미스.

JMS에 대한 한마디 이 마지막 단계에서는 앱의 일부 Weblogic 관련 코드를 다시 마이그레이션하여 표준 Java EE 인터페이스와 하나의 JBoss 관련 인터페이스를 사용합니다. 우리의 응용 프로그램은 제이엠에스 소통하다. 애플리케이션에서 주문할 때마다 JMS 메시지가 JMS 토픽으로 전송되고, 해당 토픽에 대한 리스너(구독자)가 이를 사용하여 주문을 처리합니다. 메시지 구동 Bean, Java EE 애플리케이션이 메시지를 비동기적으로 처리할 수 있도록 하는 EJB(Enterprise JavaBeans)의 한 형태입니다. 이 경우  InventoryNotificationMDB 는 ShoppingCartService  의 메시지를 구독하고 수신합니다  . ShoppingCartService 를 통해 주문이 들어오면  메시지가 JMS 주제에 배치됩니다. 그 시점에서  InventoryNotificationMDB는  메시지를 수신하고 재고 서비스가 미리 정의된 임계값 미만인 경우 제품 공급자에게 알려야 한다는 메시지를 로그에 보냅니다. 안타깝게도 이 MDB는 오래 전에 작성되었으며 weblogic 독점 인터페이스를 사용하여 MDB를 구성하고 운영합니다. MTA는 이를 표시하고 여러 가지 문제를 사용하여 보고했습니다. JBoss EAP는 MDB의 라이프사이클을 구성하고 관리하는 훨씬 더 효율적이고 선언적인 방법을 제공합니다. 이 경우 주석을 사용하여 필요한 초기화 및 구성 논리와 설정을 제공할 수 있습니다. Weblogic에서와 동일한 기능을 제공하기 위해 MessageListener 인터페이스 와 함께  @MessageDriven  및  @ActivationConfigProperty 주석을 사용합니다 .    MDB와 같은 EJB 구성 요소에 대한 Weblogic의 인터페이스 대부분은 Weblogic 설명자 XML 파일에 있습니다. CTRL+p (또는 Mac의 경우 CMD+p )를 사용하여 src/main/webapp/WEB-INF/weblogic-ejb-jar.xml을 빠르게 열면 이러한 설명자 중 하나를 볼 수 있습니다. 이 파일에는 EJB 및 MDB에 대한 다양한 구성 가능성이 있지만 운 좋게도 우리 애플리케이션은 그중 하나만 사용합니다. 즉, <trans-timeout-seconds>를 30으로 구성합니다. 완료하는 데 오래(30초 이상) 걸리면 트랜잭션이 롤백되고 예외가 발생합니다. 이 인터페이스는 Weblogic 전용이므로 JBoss에서 이에 상응하는 것을 찾아야 합니다.

첫 번째 단계는 필요하지 않은  weblogic-ejb-jar.xml 파일을 프로젝트 탐색기 ( 마이그레이션 도우미 아님 )  에서 제거하는 것입니다 . 이 파일은 Weblogic의 소유이며 JBoss EAP에서 인식하거나 처리하지 않습니다. 프로젝트 탐색기 에서 src/main/webapp/WEB-INF/weblogic-ejb-jar.xml 파일을 마우스 오른쪽 버튼으로 클릭 하고 삭제 를 선택한 다음 확인 을 클릭하여 파일을 삭제합니다 .         

weblogic-ejb-jar.xml 파일 에 대한 탭이 열려 있는 경우 (또는 편리한 경우) 표시된 대로 탭을 마우스 오른쪽 버튼으로 클릭한 다음 탐색기에 표시를  선택하여 프로젝트 탐색기에서 빠르게 찾을 수 있습니다. ALT+R (또는 Mac의 경우 Option+R ) 을 사용할 수도 있습니다 .

그 동안 시나리오의 일부로 추가된 스텁 weblogic 구현 클래스를 제거하겠습니다.

여전히 프로젝트 탐색기에 있는 동안  src/main/java/weblogic  폴더를 마우스 오른쪽 버튼으로 클릭하고 삭제를 선택하여 폴더를 삭제합니다.  

8. 코드 수정

CTRL+p (또는 Mac에서는 CMD+p )를 사용하여 monolith/src/main/java/com/redhat/coolstore/service/InventoryNotificationMDB.java 파일을 빠르게 열고 내용을 다음으로 바꿉니다.      

package com.redhat.coolstore.service; import com.redhat.coolstore.model.Order; import com.redhat.coolstore.utils.Transformers; import javax.ejb.ActivationConfigProperty; import javax.ejb.MessageDriven; import javax.inject.Inject; import javax.jms.JMSException; import javax.jms.Message; import javax.jms.MessageListener; import javax.jms.TextMessage; import java.util.logging.Logger; @MessageDriven(name = "InventoryNotificationMDB", activationConfig = { @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "topic/orders"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"), @ActivationConfigProperty(propertyName = "transactionTimeout", propertyValue = "30"), @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge")}) public class InventoryNotificationMDB implements MessageListener { private static final int LOW_THRESHOLD = 50; @Inject private CatalogService catalogService; @Inject private Logger log; public void onMessage(Message rcvMessage) { TextMessage msg; { try { if (rcvMessage instanceof TextMessage) { msg = (TextMessage) rcvMessage; String orderStr = msg.getBody(String.class); Order order = Transformers.jsonToOrder(orderStr); order.getItemList().forEach(orderItem -> { int old_quantity = catalogService.getCatalogItemById(orderItem.getProductId()).getInventory().getQuantity(); int new_quantity = old_quantity - orderItem.getQuantity(); if (new_quantity < LOW_THRESHOLD) { log.warning("Inventory for item " + orderItem.getProductId() + " is below threshold (" + LOW_THRESHOLD + "), contact supplier!"); } }); } } catch (JMSException jmse) { System.err.println("An exception occurred: " + jmse.getMessage()); } } } }

 

 

weblogic-ejb-jar.xml 파일 의  <trans-timeout-seconds> 설정을 기억하십니까 ? 이것은 이제 새 코드에서 @ActivationConfigProperty 로 설정됩니다 . 주석과 XML 디스크립터를 사용하는 것에는 장단점이 있으며 응용 프로그램의 요구 사항을 고려하는 데 주의를 기울여야 합니다.

이제 MDB가 JBoss EAP로 제대로 마이그레이션되어야 합니다.

마지막으로 org.jboss.spec.javax.rmi:jboss-rmi-api_1.0_spec 에 대한 Maven 종속성을 제거합니다 . JBoss EAP 7.3(이상)에서 groupId org.jboss.spec.javax.rmi 및 artifactId jboss-rmi-api_1.0_spec 이 있는 아티팩트 는 지원되지 않는 종속성입니다. monolith/pom.xml 에서 다음 종속성을 제거합니다 .      

9. 빌드 테스트

다시 한 번 빌드:

mvn -f $CHE_PROJECTS_ROOT/cloud-native-workshop-v2m1-labs/monolith clean package

 성공적으로 빌드되면( BUILD SUCCESS가 표시됨 ). 컴파일되지 않으면 모든 변경 사항을 올바르게 적용했는지 확인하고 빌드를 다시 시도하십시오.

10. MTA 보고서를 다시 실행합니다.

이 단계에서는 MTA 보고서를 다시 실행하여 마이그레이션이 성공했는지 확인합니다.

 Run 아이콘을 클릭하여  WebLogic 애플리케이션을 분석합니다.

MTA(Migration Toolkit for Applications) CLI가 새 터미널에서 자동으로 실행된 후 분석을 완료하는 데 몇 분 정도 걸립니다. 보고서 열기 를 클릭합니다  .

시간이 너무 오래 걸리면 다음 섹션을 건너뛰고 13 단계로 진행한 다음 나중에 다시 분석으로 돌아가서 모든 문제가 제거되었는지 확인하십시오.

11. 결과 보기

최신 결과를 클릭하여 보고서 웹 페이지로 이동하고 이제 스토리 포인트가 0으로 보고되는지 확인합니다.

이 앱을 JBoss EAP로 성공적으로 마이그레이션했습니다. 축하합니다!

이 유형의 마이그레이션은 이전 단계보다 더 복잡하며 실제 응용 프로그램에서는 마이그레이션을 위해 한 번에 한 줄씩 변경하는 것처럼 간단하지 않습니다. 를 참조하십시오 MTA 문서 Red Hat의 애플리케이션 마이그레이션 전략에 대한 자세한 내용은 Red Hat이 마이그레이션 경로에서 어떻게 도움을 줄 수 있는지 현지 Red Hat 담당자에게 문의하십시오.

12. OpenShift 프로필 추가

이제 앱을 마이그레이션했으므로 이를 배포하고 테스트하고 JBoss EAP와 Red Hat OpenShift가 제공하는 몇 가지 기능을 살펴보겠습니다.

CTRL+p ( Mac에서는 CMD+p )를 사용하여 monolith/pom.xml 파일을 빠르게 엽니다.      

<!-- TODO: 여기 에  OpenShift 프로필 추가 -->에서  다음 구성을 pom.xml에 추가합니다.

<profile> <id>openshift</id> <build> <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.6</version> <configuration> <webResources> <resource> <directory>${basedir}/src/main/webapp/WEB-INF</directory> <filtering>true</filtering> <targetPath>WEB-INF</targetPath> </resource> </webResources> <outputDirectory>${basedir}/deployments</outputDirectory> <warName>ROOT</warName> </configuration> </plugin> </plugins> </build> </profile>

 

13. OpenShift 프로젝트 생성

먼저 다음을 사용하여 새 브라우저를 엽니다. OpenShift 웹 콘솔:

자격 증명을 사용하여 로그인:

• 사용자 이름:  페이지 상단에 USERID를 입력하십시오.
• 암호:  ex) xxxxxxx

액세스 권한이 있는 프로젝트 목록이 표시됩니다.

랜딩 페이지에 표시되는 프로젝트는 오늘 실행할 랩에 따라 다릅니다.

프로젝트 링크 만들기 를 클릭 하고 필드를 채운 다음 만들기를 클릭합니다 .   

• 이름:  페이지 상단에 USERID를 입력하십시오-coolstore-dev
• 표시 이름:  페이지 상단에 USERID를 입력하십시오. Coolstore Monolith - Dev
• 설명:  이 필드는 비워두세요

프로젝트 이름으로 PAGE-coolstore-dev 상단에 USERID를 입력해야 합니다 . 이 이름 은 나중에 참조되므로 이름을 지정하지 않으면 실패가 발생합니다. PAGE-coolstore-dev 상단에 USERID를 입력하세요!

개발자 콘솔로 이동합니다. 아직 아무것도 없지만 곧 변경될 예정입니다.

개발자 관점으로 전환

OpenShift 4는 콘솔에서  관리자  및  개발자 보기를 모두 제공합니다. 아직 개발자 관점  에 있지 않은 경우 왼쪽의 드롭다운을 사용하여 개발자 관점 으로 전환할 수 있습니다 .    

Developer  Perspective는  프로젝트에 배포된 애플리케이션의 개발자 중심 보기를 제공합니다. 아직 배포된 것이 없으므로 응용 프로그램을 배포하는 일련의 방법이 제공됩니다.

14. 모놀리스 배포

사용할 애플리케이션  템플릿을 미리 설치했습니다 . 토폴로지 보기 에서 애플리케이션 빌드 시작을  클릭하십시오 .    

검색 상자에  coolstore를 입력하고 바이너리 빌드를 사용하는 Coolstore Monolith를  선택한 다음 템플릿 인스턴스화를 클릭합니다 .   

다음 필드를 채우십시오.

• 네임스페이스 :  페이지 상단에 USERID를 입력하십시오-coolstore-dev  (이미 선택되어 있어야 함)
• 사용자 ID :  페이지 상단에 사용자 ID를 입력하세요.

다른 값은 그대로 두고 만들기를 클릭합니다 . 

 토폴로지 보기 에 배포된 요소가 표시됩니다  .

템플릿은 배후에서 약간의 작업을 수행했습니다!  위에서 입력한 정보를 사용하여 새로 마이그레이션된 .war 바이너리 를 배포하는 데 필요한 Kubernetes(및 OpenShift) "인프라"를 생성했습니다  . 다음은 그것이 만든 것들 중 일부입니다. EAP 7.3 이후 PostgreSQL 템플릿이 제거되었습니다. 따라서 Galleon 프로비저닝 레이어로 이러한 기능을 프로비저닝할 수 있습니다. GALLEON_PROVISION_FEATURE_PACKS -  org.jboss.eap:eap-datasources-galleon-pack:7.4.0.GA-redhat-00003 POSTGRESQL_DRIVER_VERSION -  42.2.19 이전 배포 에 필요한 모든  서비스,  ConfigMap 및  비밀   GALLEON_PROVISION_LAYERS -  클라우드 서버, ejb, postgresql-데이터 소스

웹 콘솔의 개발자 관점에 있는 토폴로지 보기는 프로젝트 내의 모든 응용 프로그램, 해당 빌드 상태, 관련 구성 요소 및 서비스에 대한 시각적 표현을 제공합니다.    

 실행 중인 postgres 데이터베이스(진한 파란색 원 포함)와 아직 배포되지 않았거나 시작되지 않은 coolstore 모놀리스가 .war  파일을 실행하는 JBoss EAP가 포함된 첫 번째 컨테이너가 빌드되기를 기다리고 있는 것을 볼 수 있습니다 . 다음에 다루겠습니다.  

CLI를 사용하여 모놀리식 배포

Eclipse Che 작업공간이 Kubernetes 클러스터에서 실행 중이지만 대부분의 리소스 유형을 생성하지 못하도록 하는 기본 제한된  서비스 계정 으로 실행 중입니다 .  다른 모듈을 완료한 경우 이미 로그인되어 있을 수 있지만 다시 로그인하겠습니다. OpenShift에 로그인을 클릭하십시오 . 

이것을 클릭하면 CodeReady Workspaces는 다음 명령을 실행합니다. oc login  https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT --insecure-skip-tls-verify=true --username=페이지 상단에 사용자 ID를 입력하십시오 --password=r3dh4t1!

다음과 같이 표시되어야 합니다(프로젝트 이름은 다를 수 있음).

Login successful. You have access to the following projects and can switch between them with 'oc project <projectname>': * PLEASE ENTER USERID AT TOP OF PAGE-bookinfo PLEASE ENTER USERID AT TOP OF PAGE-catalog PLEASE ENTER USERID AT TOP OF PAGE-cloudnative-pipeline PLEASE ENTER USERID AT TOP OF PAGE-cloudnativeapps PLEASE ENTER USERID AT TOP OF PAGE-inventory PLEASE ENTER USERID AT TOP OF PAGE-istio-system Using project "PLEASE ENTER USERID AT TOP OF PAGE-bookinfo". Welcome! See 'oc help' to get started.

OpenShift에 로그인을 사용하여 로그인한 후에 는 터미널을 더 이상 일반 터미널로 사용할 수 없습니다. 터미널 창을 닫을 수 있습니다. 나중에 더 많은 터미널을 열면 계속 로그인됩니다!

CodeReady Workspaces 터미널 창을 통해 이전에 생성한 개발자 프로젝트로 전환합니다.

oc project PLEASE ENTER USERID AT TOP OF PAGE-coolstore-dev

그런 다음 CodeReady 터미널에서 다음 명령을 실행하여 구성 요소에 레이블을 지정하여 적절한 아이콘을 얻습니다.

oc label dc/coolstore-postgresql app.openshift.io/runtime=postgresql --overwrite && \ oc label dc/coolstore app.openshift.io/runtime=jboss --overwrite && \ oc label dc/coolstore-postgresql app.kubernetes.io/part-of=coolstore --overwrite && \ oc label dc/coolstore app.kubernetes.io/part-of=coolstore --overwrite && \ oc annotate dc/coolstore app.openshift.io/connects-to=coolstore-postgresql --overwrite && \ oc annotate dc/coolstore app.openshift.io/vcs-uri=https://github.com/RedHat-Middleware-Workshops/cloud-native-workshop-v2m1-labs.git --overwrite && \ oc annotate dc/coolstore app.openshift.io/vcs-ref=ocp-4.10 --overwrite

 

이전 단계에서 빌드한 컨테이너 이미지를 아직 배포하지 않았지만 다음에 수행합니다.

15. 바이너리 빌드를 사용하여 애플리케이션 배포

이 개발 프로젝트에서 우리는 바이너리 빌드라는 프로세스를 사용하기로 선택했습니다  . 즉, 공개 Git 리포지토리를 가리키고 S2I(Source-to-Image) 빌드 프로세스를 다운로드, 빌드한 다음 다음을 위한 컨테이너 이미지를 생성합니다. 우리는 로컬에서 빌드하고 아티팩트(예:  .war  파일)를 업로드할 것입니다. 바이너리 배포는 빌드 프로세스의 속도를 크게 높입니다.

 먼저 OpenShift와 함께 사용하기에 적합한 바이너리를 생성하는 openshift Maven 프로필을 사용하여 프로젝트를 한 번 더 빌드합니다  (이는 아직 컨테이너 이미지가 아니라 .war  파일  일 뿐입니다).  oc 명령줄을 사용하여 이 작업을 수행합니다  .

CodeReady Workspaces Terminal 창을 통해 프로젝트를 빌드합니다.

mvn clean package -Popenshift -f $CHE_PROJECTS_ROOT/cloud-native-workshop-v2m1-labs/monolith

빌드가 완료되고  BUILD SUCCESS  메시지가 나타날 때까지 기다리세요!

마지막으로 템플릿에서 생성된 DeploymentConfig 개체 덕분에  .war 파일을 가져오고 JBoss EAP와 결합하고 프로젝트에 자동으로 배포될 Linux 컨테이너 이미지를 생성하는 빌드 프로세스를 시작합니다 .   

oc start-build coolstore --from-file $CHE_PROJECTS_ROOT/cloud-native-workshop-v2m1-labs/monolith/deployments/ROOT.war --follow

 --follow  플래그를 명령줄에 추가하면 S2I 빌드 로그 출력이 CRW 터미널로 흐르는 것을 볼 수 있습니다.

한편 토폴로지 보기로 돌아가서 모놀리스가 구축되는 것을 볼 수 있습니다.

빌드 로그를 보려면 빌드 아이콘을 클릭하십시오(터미널로 전송되는 내용을 미러링해야 함).

토폴로지 보기로 돌아가 기본 아이콘을 클릭하고 개요를 봅니다  .

배포가 완료되고 진한 파란색 원이 표시될 때까지 기다립니다.

경로 링크를 클릭하여 애플리케이션을 테스트합니다.

이제 OpenShift에서 로컬로 구축한 것과 동일한 애플리케이션을 사용하고 있습니다. 별로 어렵지 않죠?

요약

이제 JBoss 및 OpenShift를 사용하여 기존 Java EE 앱을 클라우드로 마이그레이션했으므로 모놀리식을 증분 단계에서 더 작은 마이크로 서비스로 분할하고 최신 기술을 사용하여 애플리케이션이 분산된 환경에서 원활하게 실행되도록 보장함으로써 애플리케이션 현대화를 시작할 준비가 되었습니다. 컨테이너화된 환경.

 

마무리

RedHat의 OpenShift 플랫폼은 요즘 Container & Cloud-Native와 DevOps환경에 최적화된 좋은 플랫폼이라고 생각한다! 
다만 가격이 비쌀뿐...

끝으로 그동한 PKOS 스터디를 진행하면서 Kubernetes에 대해 궁금했던 많은 정보와 지식들을 습득할 수 있었고 7주가 아쉬울 정도로 좋은 퀄리티의 스터디라고 생각합니다~!

다시 한번 좋은 스터디를 이끌어주신 가시다님께 감사의 말 전합니다!