기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
컨테이너 워크로드를 Azure Red Hat OpenShift(ARO)에서 Red Hat OpenShift Service on AWS (ROSA)로 마이그레이션
작성자: Naveen Ramasamy(AWS), Gireesh Sreekantan(AWS), Srikanth Rangavajhala(AWS)
요약
이 패턴은 컨테이너 워크로드를 Azure Red Hat OpenShift(ARO)에서 Red Hat OpenShift Service on AWS (ROSA)
컨테이너 워크로드를 ARO, 다른 클라우드 또는 온프레미스에서 ROSA로 마이그레이션하려면 한 플랫폼에서 다른 플랫폼으로 애플리케이션, 구성 및 데이터를 전송해야 합니다. 이 패턴은 AWS 클라우드 서비스, 보안 및 비용 효율성을 최적화하면서 원활한 전환을 보장하는 데 도움이 됩니다. 여기에는 워크로드를 ROSA 클러스터로 마이그레이션하는 두 가지 방법인 CI/CD와 컨테이너용 마이그레이션 도구 키트(MTC)가 포함됩니다.
이 패턴은 두 가지 방법을 모두 다룹니다. 선택하는 방법은 마이그레이션 프로세스의 복잡성과 확실성에 따라 달라집니다. 애플리케이션의 상태를 완전히 제어할 수 있고 파이프라인을 통해 일관된 설정을 보장할 수 있는 경우 CI/CD 메서드를 사용하는 것이 좋습니다. 그러나 애플리케이션 상태에 불확실성, 예상치 못한 변경 또는 복잡한 에코시스템이 포함된 경우 MTC를 안정적이고 제어된 경로로 사용하여 애플리케이션과 해당 데이터를 새 클러스터로 마이그레이션하는 것이 좋습니다. 두 메서드의 자세한 비교는 추가 정보 섹션을 참조하세요.
ROSA로 마이그레이션할 때의 이점:
ROSA는 AWS 기본 서비스로와 원활하게 통합됩니다. 를 통해 쉽게 액세스할 수 AWS Management Console 있으며 단일를 통해 요금이 청구됩니다 AWS 계정. 다른와 완벽하게 호환 AWS 서비스 되며 및 AWS Red Hat 모두에서 협업 지원을 제공합니다.
ROSA는 하이브리드 및 멀티 클라우드 배포를 지원합니다. 이를 통해 온프레미스 데이터 센터와 여러 클라우드 환경에서 애플리케이션을 일관되게 실행할 수 있습니다.
ROSA는 Red Hat의 보안 포커스의 이점을 활용하고 역할 기반 액세스 제어(RBAC), 이미지 스캔 및 취약성 평가와 같은 기능을 제공하여 안전한 컨테이너 환경을 보장합니다.
ROSA는 애플리케이션을 쉽게 확장하도록 설계되었으며 고가용성 옵션을 제공합니다. 이를 통해 애플리케이션은 안정성을 유지하면서 필요에 따라 확장할 수 있습니다.
ROSA는 수동 설정 및 관리 방법과 비교하여 Kubernetes 클러스터의 배포를 자동화하고 간소화합니다. 이렇게 하면 개발 및 배포 프로세스가 가속화됩니다.
ROSA는 AWS 클라우드 서비스의 이점을 활용하며 데이터베이스 서비스, 스토리지 솔루션 및 보안 서비스와 같은 AWS 제품과 원활하게 통합됩니다.
사전 조건 및 제한 사항
사전 조건
활성. AWS 계정
AWS 서비스 ROSA에 대해 구성된 권한은 기능을 제공하기 위해에 의존합니다. 자세한 내용은 ROSA 설명서의 사전 조건을 참조하세요.
ROSA 클러스터가 설치 및 구성되었습니다. 자세한 내용은 ROSA 설명서의 ROSA 시작하기를 참조하세요. ROSA 클러스터를 설정하는 다양한 방법을 이해하려면 AWS 권장 가이드 가이드 ROSA 구현 전략을 참조하세요.
온프레미스 네트워크에서 (선호) 또는 AWS Direct Connect ()를 AWS 통해 로 설정된 네트워크 연결AWS Virtual Private NetworkAWS VPN.
aws client, OpenShift CLI() 클라이언트, ROSA 클라이언트 및 Git 바이너리와 같은 도구를 설치하기 위한 Amazon Elastic Compute Cloud(Amazon EC2oc) 인스턴스 또는 다른 가상 서버입니다.
CI/CD 메서드에 대한 추가 사전 조건:
새 파이프라인을 생성하고, 스테이지를 추가하고, OpenShift 클러스터를 추가하고, 빌드를 수행할 수 있는 권한이 있는 온프레미스 Jenkins 서버에 액세스합니다.
새 Git 브랜치를 생성하고 새 브랜치에 대한 커밋을 수행할 수 있는 권한을 사용하여 애플리케이션 소스 코드가 유지되는 Git 리포지토리에 액세스합니다.
MTC 메서드에 대한 추가 사전 조건:
복제 리포지토리로 사용되는 Amazon Simple Storage Service(Amazon S3) 버킷입니다.
소스 ARO 클러스터에 대한 관리 액세스. 이는 MTC 연결을 설정하는 데 필요합니다.
제한 사항
일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전 가용성은 AWS 서비스 리전별
섹션을 참조하세요. 특정 엔드포인트는 서비스 엔드포인트 및 할당량 페이지를 참조하고 서비스 링크를 선택합니다.
아키텍처
ROSA는 퍼블릭, 프라이빗 및 AWS PrivateLink.PrivateLinkenables Red Hat 사이트 신뢰성 엔지니어링(SRE) 팀의 세 가지 네트워크 배포 패턴을 제공하여 기존 VPC에서 클러스터의 PrivateLink 엔드포인트에 연결된 프라이빗 서브넷을 사용하여 클러스터를 관리합니다.
PrivateLinkoption을 선택하면 가장 안전한 구성이 제공됩니다. 따라서 민감한 워크로드 또는 엄격한 규정 준수 요구 사항에 권장됩니다. 퍼블릭 및 프라이빗 네트워크 배포 옵션에 대한 자세한 내용은 Red Hat OpenShift 설명서를
중요
PrivateLink 클러스터는 설치 시에만 생성할 수 있습니다. 설치 후에는 PrivateLink를 사용하도록 클러스터를 변경할 수 없습니다.
다음 다이어그램은가 온프레미스 및 ARO 환경에 연결하는 AWS Direct Connect 데 사용하는 ROSA 클러스터의 PrivateLink 아키텍처를 보여줍니다.
AWS ROSA에 대한 권한
ROSA에 대한 AWS 권한의 경우 수명이 짧은 동적 토큰과 함께 AWS Security Token Service (AWS STS)를 사용하는 것이 좋습니다. 이 방법은 최소 권한 사전 정의된 역할 및 정책을 사용하여 ROSA에에서 작동할 수 있는 최소 권한을 부여 AWS 계정하고 ROSA 설치, 컨트롤 플레인 및 컴퓨팅 기능을 지원합니다.
CI/CD 파이프라인 재배포
CI/CD 파이프라인 재배포는 성숙한 CI/CD 파이프라인이 있는 사용자에게 권장되는 방법입니다. 이 옵션을 선택하면 DevOps 배포 전략을 사용하여 애플리케이션 로드를 ROSA의 배포로 점진적으로 전환할 수 있습니다.
참고
이 패턴은 온프레미스 Git, JFrog Artifactory 및 Jenkins 파이프라인이 있는 일반적인 사용 사례를 가정합니다. 이 접근 방식을 사용하려면 온프레미스 네트워크에서를 AWS 통해 네트워크 연결을 설정하고 AWS Direct Connect에픽 섹션의 지침을 따르기 전에 ROSA 클러스터를 설정해야 합니다. 자세한 내용은 사전 조건 섹션을 참조하세요.
다음 다이어그램은이 메서드의 워크플로를 보여줍니다.
MTC 메서드
컨테이너용 마이그레이션 도구 키트(MTC)
다음 다이어그램은이 메서드의 워크플로를 보여줍니다.
도구
AWS 서비스
AWS DataSync는 AWS 스토리지 서비스 간에 파일 또는 객체 데이터를 이동시키는 데 도움이 되는 온라인 데이터 전송 및 검색 서비스입니다.
AWS Direct Connect는 표준 이더넷 광섬유 케이블을 통해 내부 네트워크를 AWS Direct Connect 위치에 연결합니다. 이 연결을 사용하면 네트워크 경로에서 인터넷 서비스 공급자를 우회 AWS 서비스 하면서 퍼블릭에 직접 가상 인터페이스를 생성할 수 있습니다.
AWS PrivateLink를 사용하면 가상 프라이빗 클라우드(VPCs)에서 VPC 외부의 서비스로의 단방향 프라이빗 연결을 생성할 수 있습니다.
Red Hat OpenShift Service on AWS (ROSA)는 Red Hat OpenShift 사용자가 컨테이너화된 애플리케이션을 구축, 확장 및 관리할 수 있도록 지원하는 관리형 서비스입니다 AWS.
AWS Security Token Service (AWS STS)를 사용하면 사용자에게 제한된 권한의 임시 자격 증명을 요청할 수 있습니다.
기타 도구
Migration Toolkit for Containers(MTC)
는 컨테이너화된 애플리케이션을 ARO에서 ROSA로 마이그레이션하기 위한 콘솔 및 API를 제공합니다.
모범 사례
복원력을 높이고 보안 규정 준수 워크로드가 있는 경우 PrivateLink를 사용하는 다중 AZ ROSA 클러스터를 설정합니다. 자세한 내용은 ROSA 설명서를 참조하세요.
참고
설치 후에는 PrivateLink를 구성할 수 없습니다.
복제 리포지토리에 사용하는 S3 버킷은 퍼블릭이어서는 안 됩니다. 적절한 S3 버킷 정책을 사용하여 액세스를 제한합니다.
MTC 메서드를 선택하는 경우 단계 마이그레이션 옵션을 사용하여 전환 중에 가동 중지 기간을 줄입니다.
ROSA 클러스터를 프로비저닝하기 전과 후에 서비스 할당량을 검토합니다. 필요한 경우 요구 사항에 따라 할당량 증가를 요청합니다. 자세한 내용은 Service Quotas 설명서를 참조하십시오.
ROSA 보안 지침을 검토하고 보안 모범 사례를 구현합니다.
설치 후 기본 클러스터 관리자를 제거하는 것이 좋습니다. 자세한 내용은 Red Hat OpenShift 설명서
를 참조하세요. 머신 풀 자동 조정을 사용하여 ROSA 클러스터에서 사용하지 않는 작업자 노드를 스케일 다운하여 비용을 최적화합니다. 자세한 내용은 ROSA 워크숍
을 참조하세요. OpenShift 컨테이너 플랫폼을 위한 Red Hat 비용 관리 서비스를 사용하여 클라우드 및 컨테이너에 대한 비용을 더 잘 이해하고 추적할 수 있습니다. 자세한 내용은 ROSA 워크숍
을 참조하세요. 를 사용하여 ROSA 클러스터 인프라 서비스 및 애플리케이션을 모니터링하고 감사합니다 AWS 서비스. 자세한 내용은 ROSA 워크숍
을 참조하세요.
에픽
| 작업 | 설명 | 필요한 기술 |
|---|---|---|
새 ROSA 클러스터를 Jenkins에 추가합니다. |
| AWS 관리자, AWS 시스템 관리자, AWS DevOps |
Jenkins 노드에 |
| AWS 관리자, AWS 시스템 관리자, AWS DevOps |
새 Git 브랜치를 생성합니다. | 용 Git 리포지토리에 새 브랜치를 생성합니다 | DevOps |
ROSA용 이미지에 태그를 지정합니다. | 빌드 단계에서 다른 태그를 사용하여 ROSA 파이프라인에서 빌드된 이미지를 식별합니다. | AWS 관리자, AWS 시스템 관리자, AWS DevOps |
파이프라인 생성. | 기존 파이프라인과 유사한 새 Jenkins 파이프라인을 생성합니다. 이 파이프라인의 경우 이전에 생성한 | AWS 관리자, AWS 시스템 관리자, AWS DevOps |
ROSA 배포 단계를 추가합니다. | 새 파이프라인에서 ROSA 클러스터에 배포할 단계를 추가하고 Jenkins 글로벌 구성에 추가한 ROSA 클러스터를 참조합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
새 빌드를 시작합니다. | Jenkins에서 파이프라인을 선택하고 지금 빌드를 선택하거나 Git의 | AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
배포를 확인합니다. | oc 명령 또는 ROSA 콘솔 | AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
대상 클러스터에 데이터를 복사합니다. | 상태 저장 워크로드의 경우 AWS DataSync 또는 rsync와 같은 오픈 소스 유틸리티를 사용하여 소스 클러스터의 데이터를 대상 클러스터로 복사하거나 MTC 메서드를 사용할 수 있습니다. 자세한 내용은 AWS DataSync 설명서를 참조하십시오. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
애플리케이션을 테스트합니다. |
| AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
컷오버. | 테스트가 성공하면 적절한 Amazon Route 53 정책을 사용하여 ARO 호스팅 애플리케이션에서 ROSA 호스팅 애플리케이션으로 트래픽을 이동합니다. 이 단계를 완료하면 애플리케이션의 워크로드가 ROSA 클러스터로 완전히 전환됩니다. | 관리자, 시스템 관리자 |
| 작업 | 설명 | 필요한 기술 |
|---|---|---|
MTC 연산자를 설치합니다. | ARO 및 ROSA 클러스터 모두에 MTC 연산자를 설치합니다.
| AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
복제 리포지토리에 대한 네트워크 트래픽을 구성합니다. | 프록시 서버를 사용하는 경우 복제 리포지토리와 클러스터 간의 네트워크 트래픽을 허용하도록 프록시 서버를 구성합니다. 복제 리포지토리는 MTC가 데이터를 마이그레이션하는 데 사용하는 중간 스토리지 객체입니다. 소스 및 대상 클러스터는 마이그레이션 중에 복제 리포지토리에 대한 네트워크 액세스 권한이 있어야 합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
소스 클러스터를 MTC에 추가합니다. | MTC 웹 콘솔에서 ARO 소스 클러스터를 추가합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
복제 리포지토리로 Amazon S3를 추가합니다. | MTC 웹 콘솔에서 Amazon S3 버킷(사전 조건 참조)을 복제 리포지토리로 추가합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
마이그레이션 계획을 생성합니다. | MTC 웹 콘솔에서 마이그레이션 계획을 생성하고 데이터 전송 유형을 복사로 지정합니다. 이렇게 하면 MTC가 소스(ARO) 클러스터에서 S3 버킷으로, 버킷에서 대상(ROSA) 클러스터로 데이터를 복사하도록 지시합니다. | AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
마이그레이션 계획을 실행합니다. | 스테이지 또는 전환 옵션을 사용하여 마이그레이션 계획을 실행합니다.
| AWS 관리자, AWS DevOps, AWS 시스템 관리자 |
문제 해결
| 문제 | Solution |
|---|---|
연결 문제 | 컨테이너 워크로드를 ARO에서 ROSA로 마이그레이션할 때 성공적인 마이그레이션을 위해 해결해야 하는 연결 문제가 발생할 수 있습니다. 마이그레이션 중에 이러한 연결 문제(이 표에 나열됨)를 해결하려면 세심한 계획, 네트워크 및 보안 팀과의 조정, 철저한 테스트가 중요합니다. 점진적 마이그레이션 전략을 구현하고 각 단계에서 연결을 확인하면 잠재적 중단을 최소화하고 ARO에서 ROSA로 원활하게 전환할 수 있습니다. |
네트워크 구성 차이 | ARO 및 ROSA의 네트워크 구성에는 가상 네트워크(VNet) 설정, 서브넷 및 네트워크 정책과 같은 변형이 있을 수 있습니다. 서비스 간에 적절하게 통신하려면 네트워크 설정이 두 플랫폼 간에 정렬되어야 합니다. |
보안 그룹 및 방화벽 규칙 | ROSA와 ARO의 기본 보안 그룹 및 방화벽 설정은 다를 수 있습니다. 마이그레이션 중에 컨테이너와 서비스 간의 연결을 유지하는 데 필요한 트래픽을 허용하려면 이러한 규칙을 조정하고 업데이트해야 합니다. |
IP 주소 및 DNS 변경 사항 | 워크로드를 마이그레이션할 때 IP 주소와 DNS 이름이 변경될 수 있습니다. 고정 IPs. |
외부 서비스 액세스 | 애플리케이션이 데이터베이스 또는 APIs와 같은 외부 서비스에 의존하는 경우 ROSA의 새 서비스와 통신할 수 있도록 연결 설정을 업데이트해야 할 수 있습니다. |
Azure Private Link 구성 | ARO에서 Azure Private Link 또는 프라이빗 엔드포인트 서비스를 사용하는 경우 리소스 간의 프라이빗 연결을 보장하기 위해 ROSA에서 동등한 기능을 설정해야 합니다. |
AWS VPN 또는 AWS Direct Connect 설정 | 온프레미스 네트워크와 ARO 간에 기존 AWS VPN 또는 AWS Direct Connect 연결이 있는 경우 로컬 리소스와의 중단 없는 통신을 위해 ROSA와 유사한 연결을 설정해야 합니다. |
수신 및 로드 밸런서 설정 | 수신 컨트롤러 및 로드 밸런서에 대한 구성은 ARO와 ROSA 간에 다를 수 있습니다. 서비스에 대한 외부 액세스를 유지하려면 이러한 설정을 재구성합니다. |
인증서 및 TLS 처리 | 애플리케이션에서 SSL 인증서 또는 TLS를 사용하는 경우 ROSA에서 인증서가 유효하고 올바르게 구성되어 있는지 확인합니다. |
컨테이너 레지스트리 액세스 | 컨테이너가 외부 컨테이너 레지스트리에서 호스팅되는 경우 ROSA에 대한 적절한 인증 및 액세스 권한을 설정합니다. |
모니터링 및 로깅 | ROSA의 새 인프라를 반영하도록 모니터링 및 로깅 구성을 업데이트하여 컨테이너의 상태와 성능을 효과적으로 계속 모니터링할 수 있습니다. |
관련 리소스
AWS 참조
란 무엇입니까 Red Hat OpenShift Service on AWS? (ROSA 설명서)
ROSA 시작하기(ROSA 설명서)
Red Hat OpenShift Service on AWS 구현 전략(AWS 권고 가이드)
Red Hat OpenShift Service on AWS Now GA
(AWS 블로그 게시물)
Red Hat OpenShift 설명서
추가 정보
MTC 및 CI/CD 파이프라인 재배포 옵션 선택
한 OpenShift 클러스터에서 다른 클러스터로 애플리케이션을 마이그레이션하려면 신중한 고려가 필요합니다. CI/CD 파이프라인을 사용하여 애플리케이션을 재배포하고 영구 볼륨 데이터의 마이그레이션을 처리하여 원활한 전환을 원하는 것이 가장 좋습니다. 그러나 실제로 클러스터에서 실행 중인 애플리케이션은 시간이 지남에 따라 예기치 않은 변경에 취약합니다. 이러한 변경으로 인해 애플리케이션이 원래 배포 상태에서 점진적으로 벗어나게 될 수 있습니다. MTC는 네임스페이스의 정확한 내용이 불확실하고 모든 애플리케이션 구성 요소를 새 클러스터로 원활하게 마이그레이션하는 것이 중요한 시나리오를 위한 솔루션을 제공합니다.
올바른 선택을 하려면 특정 시나리오를 평가하고 각 접근 방식의 이점을 고려해야 합니다. 이렇게 하면 요구 사항 및 우선순위에 맞는 성공적이고 원활한 마이그레이션을 보장할 수 있습니다. 다음은 두 옵션 중에서 선택하기 위한 추가 지침입니다.
CI/CD 파이프라인 재배포
파이프라인을 사용하여 애플리케이션을 자신 있게 재배포할 수 있는 경우 CI/CD 파이프라인 방법을 사용하는 것이 좋습니다. 이를 통해 마이그레이션을 제어하고 예측 가능하며 기존 배포 관행에 맞게 조정할 수 있습니다. 이 방법을 선택하면 블루/그린 배포 또는 카나리 배포 전략을 사용하여 ROSA에서 로드를 배포로 점진적으로 전환할 수 있습니다. 이 시나리오에서이 패턴은 Jenkins가 온프레미스 환경에서 애플리케이션 배포를 오케스트레이션하고 있다고 가정합니다.
장점:
소스 ARO 클러스터에 대한 관리 액세스 권한이 필요하지 않거나 소스 또는 대상 클러스터에 연산자를 배포할 필요가 없습니다.
이 접근 방식은 DevOps 전략을 사용하여 트래픽을 점진적으로 전환하는 데 도움이 됩니다.
단점:
애플리케이션의 기능을 테스트하려면 더 많은 노력이 필요합니다.
애플리케이션에 영구 데이터가 포함된 경우 AWS DataSync 또는 다른 도구를 사용하여 데이터를 복사하려면 추가 단계가 필요합니다.
MTC 마이그레이션
실제 환경에서 실행 중인 애플리케이션은 예기치 않은 변경으로 인해 초기 배포에서 벗어나게 될 수 있습니다. 소스 클러스터에서 애플리케이션의 현재 상태를 잘 모르는 경우 MTC 옵션을 선택합니다. 예를 들어 애플리케이션 에코시스템이 다양한 구성 요소, 구성 및 데이터 스토리지 볼륨에 걸쳐 있는 경우 MTC를 선택하여 애플리케이션과 전체 환경을 포괄하는 완전한 마이그레이션을 보장하는 것이 좋습니다.
장점:
MTC는 워크로드의 전체 백업 및 복원을 제공합니다.
워크로드를 마이그레이션하는 동안 영구 데이터를 소스에서 대상으로 복사합니다.
소스 코드 리포지토리에 액세스할 필요가 없습니다.
단점:
소스 및 대상 클러스터에 MTC 연산자를 설치하려면 관리 권한이 필요합니다.
DevOps 팀은 MTC 도구를 사용하고 마이그레이션을 수행하기 위한 훈련이 필요합니다.
