Azure Red Hat OpenShift에 대한 리소스 organization 고려 사항(선택 사항)
리소스 organization 주로 플랫폼 기반에서 관리됩니다. 플랫폼 기반이 Azure Red Hat OpenShift 랜딩 존 가속기에 영향을 줄 수 있는 몇 가지 방법은 다음과 같습니다.
구독 및 리소스 그룹 디자인은 일반 Azure 랜딩 존 권장 사항의 주요 고려 사항입니다. Azure Red Hat OpenShift 리소스 organization 관리하는 방법에 기본적인 역할을 합니다. 구독은 리소스 거버넌스 및 격리를 위한 관리 경계입니다. 관리 그룹 및 구독 organization 설명한 대로 구독 및 관리 그룹을 사용하여 경계 내의 리소스에 정책을 할당합니다.
예를 들어 퍼블릭 및 프라이빗 애플리케이션이 있는 경우 다른 구독으로 분리하여 및 라는 Corp
Online
적절한 관리 그룹 또는 랜딩 존 아래에 있는 다른 관리 그룹에 배치합니다. 관리 그룹 내에 Corp
있는 구독에는 공용 IP 주소 생성을 방지하는 정책이 있습니다. 관리 그룹 아래에 Online
있는 구독은 인터넷 연결 및 공용 액세스를 직접 허용합니다. ARO 관련 정책을 포함하여 Azure 랜딩 존 디자인의 다양한 수준에서 적용되는 정책에 대한 자세한 내용은 Azure 랜딩 존 참조 구현에 포함된 정책을 참조하세요.
디자인 고려 사항
컨테이너 호스트를 관리할 사용자를 결정합니다.
호스트가 중앙에서 관리되는 경우 랜딩 존 인스턴스 수를 줄일 수 있습니다. 개발자가 정의된 프로세스를 따라 호스트를 배포하고 워크로드 수준 작업에 공유 대시보드 및 경고를 사용하도록 요구합니다.
워크로드 팀이 호스트를 관리하는 경우 호스트 환경을 분할하기 위해 더 많은 랜딩 존 인스턴스가 필요합니다. 워크로드 팀은 배포를 제어할 수 있습니다.
호스트가 워크로드 팀에서 중앙에서 관리되는지 여부에 관계없이 웹 애플리케이션 방화벽, 키 자격 증명 모음, 파이프라인 빌드 에이전트 및 잠재적으로 점프 상자와 같은 인접하고 관련된 리소스로 이 고려 사항을 확장합니다.
클러스터에 대한 테넌시 모델을 선택합니다.
워크로드 팀이 운영하는 단일 테넌트: 단일 워크로드를 지원하는 단일 클러스터 호스트에는 워크로드 팀 세분화 및 제어를 위한 전용 랜딩 존이 필요할 수 있습니다.
기술 플랫폼, 다중 테넌트 호스트: 호스트가 중앙에서 관리되는 경우 운영 효율성은 공유 랜딩 존 구독에서 여러 호스트 및 여러 워크로드를 통합하는 데서 비롯됩니다. 통합은 단일 클러스터 또는 워크로드를 지원하는 전용 랜딩 존 및 호스트 수를 줄입니다.
지역, 사업부, 환경, 중요도 또는 기타 외부 제약 조건에 따라 워크로드를 구분하는 데 세분화가 필요한 경우 랜딩 존 구독을 추가해야 할 수 있습니다.
팁
추가 관리 그룹을 만들기 전에 요구 사항을 충족하도록 Azure 랜딩 존 아키텍처 조정 을 검토합니다.
중앙에서 작동하는 단일 테넌트: 여전히 중앙에서 운영되는 적대적이거나 규제된 워크로드의 경우 워크로드에 대한 전용 호스트가 있는 것이 일반적입니다. 지원 랜딩 존을 통합하여 운영 효율성을 경험할 수 있습니다.
전체 포트폴리오 요구 사항을 지원하는 데 필요한 환경 및 호스트의 일반적인 규모 및 정렬에 따라 관리 그룹 계층 구조를 선택합니다.
- 플랫 구조를 사용하여 각 워크로드 팀에서 실행하는 탈중앙화 작업을 위해 전용 환경에서 많은 전용 호스트를 지원합니다.
- 분할된 구조를 사용하여 중앙에서 관리되는 호스트에 대한 관리 그룹 및 탈중앙화 작업을 위한 별도의 관리 그룹을 만듭니다.
- 계층 구조를 사용하여 환경을 더 세분화하여 청구, 거버넌스 또는 운영 요구 사항을 반영합니다.
사용할 컨테이너 레지스트리를 결정합니다.
- 통합 Red Hat OpenShift Container Platform 레지스트리를 사용합니다. 다음 항목을 고려합니다.
- 기본 제공 컨테이너 레지스트리를 구성해야 합니다.
- 엔터프라이즈 품질 컨테이너 레지스트리의 경우 Red Hat Quay 레지스트리를 사용합니다.
- Azure Container Registry 사용합니다. 다음 항목을 고려합니다.
- Azure Container Registry 모범 사례를 구현합니다.
- 격리 패턴을 사용하여 레지스트리에 취약성 검사된 이미지만 포함되도록 합니다.
- 타사 컨테이너 레지스트리를 사용합니다.
- 통합 Red Hat OpenShift Container Platform 레지스트리를 사용합니다. 다음 항목을 고려합니다.
OCI(Open Container Initiative) 아티팩트 배포에 사용할 컨테이너 레지스트리 토폴로지를 결정합니다.
- 워크로드당 하나의 레지스트리
- 레지스트리에 여러 워크로드가 있는 클러스터당 하나의 레지스트리.
- 동일한 레지스트리에 여러 워크로드 및 클러스터가 있는 랜딩 존의 모든 클러스터에 대한 하나의 레지스트리입니다.
- 여러 랜딩 존의 모든 클러스터에 대한 하나의 레지스트리이며, 동일한 레지스트리에 여러 워크로드 및 클러스터가 있습니다.
Azure Policy에서 컨테이너 레지스트리 정책의 범위를 결정합니다.
- 랜딩 존의 모든 호스트가 정의된 레지스트리를 사용하도록 하려면 구독 수준에서 정책을 설정합니다.
- 리소스 그룹 수준에서 보다 세부적인 정책을 설정합니다.
- 관리 그룹 수준에서 더 광범위한 정책을 설정합니다.
디자인 권장 사항
- Azure에 배포된 모든 컨테이너 리소스에 적용할 명명 및 태그 지정 표준을 정의합니다. 최소한 표준에는 다음이 포함되어야 합니다.
- 워크로드 이름: 각 클러스터에서 지원하는 워크로드 또는 워크로드입니다.
- 클러스터 리소스: 이전 고려 사항에서 클러스터 리소스 맞춤의 권한 상승입니다.
- 호스트 연산자: 호스트 작업을 담당하는 팀입니다.
- organization 컨테이너 레지스트리 토폴로지를 기반으로 하는 특정 OCI 아티팩트 레지스트리를 요구하는 정책을 구현합니다.