엔터프라이즈 애플리케이션 청사진은 일련의 자동화된 시스템 및 파이프라인을 통해 배포됩니다. 각 파이프라인은 청사진의 특정 측면을 배포합니다. 파이프라인은 청사진을 빌드할 수 있도록 제어 가능하고 감사 및 반복 가능한 메커니즘을 제공합니다. 다음 다이어그램은 다양한 파이프라인, 저장소, 캐릭터의 상호작용을 보여줍니다.
청사진은 다음 파이프라인을 사용합니다.
- 기반 인프라 파이프라인(엔터프라이즈 기반 청사진의 일부)은 애플리케이션 팩토리, 멀티 테넌트 인프라 파이프라인, Fleet 범위 파이프라인을 배포합니다.
- 멀티 테넌트 인프라 파이프라인은 GKE 클러스터와 엔터프라이즈 애플리케이션 청사진이 의존하는 다른 관리형 서비스를 배포합니다.
- Fleet 범위 파이프라인은 Fleet 범위, 네임스페이스, RBAC 역할 및 결합을 구성합니다.
- 애플리케이션 팩토리는 템플릿 프로세스를 통해 새 애플리케이션 파이프라인을 배포하는 메커니즘을 제공합니다.
- 애플리케이션 CI/CD 파이프라인은 GKE 클러스터에 서비스를 배포하기 위한 CI/CD 파이프라인을 제공합니다.
- 구성 동기화는 정책 컨트롤러 제약조건을 포함한 추가 Kubernetes 구성을 배포하고 유지관리합니다.
저장소, 저장소 참여자, 저장소 변경 승인자
청사진 파이프라인은 Git 저장소 변경사항을 통해 트리거됩니다. 다음 표에서는 청사진 전반에 사용되는 저장소, 저장소에 기여하는 사람, 저장소 변경을 승인하는 사람, 저장소를 사용하는 파이프라인, 저장소에 포함된 항목에 대해 설명합니다.
| 저장소 | 저장소 참여자 | 저장소 변경 승인자 | 파이프라인 | 설명 |
|---|---|---|---|---|
|
개발자 플랫폼 개발자 |
개발자 플랫폼 관리자 |
기반 인프라 파이프라인 |
멀티 테넌트 인프라 파이프라인, 애플리케이션, Fleet 범위 파이프라인을 배포하기 위한 코드가 포함된 저장소 |
|
개발자 플랫폼 개발자 |
개발자 플랫폼 관리자 |
멀티 테넌트 인프라 |
개발자 플랫폼 팀이 인프라를 만들 때 사용하는 Terraform 모듈 |
|
개발자 플랫폼 개발자 |
개발자 플랫폼 관리자 |
Fleet 범위 |
Fleet에서 Fleet 팀 범위 및 네임스페이스를 정의하는 저장소 |
|
개발자 플랫폼 개발자 |
개발자 플랫폼 관리자 |
애플리케이션 팩토리 |
애플리케이션 저장소를 정의하고 |
|
애플리케이션 개발자 |
애플리케이션 운영자 |
애플리케이션 팩토리 |
저장소가 처음 생성될 때 |
|
개발자 플랫폼 개발자 |
개발자 플랫폼 관리자 |
애플리케이션 팩토리 멀티 테넌트 인프라 |
애플리케이션 및 인프라를 정의하는 Terraform 모듈 |
|
애플리케이션 개발자 |
애플리케이션 운영자 |
애플리케이션 CI/CD |
GKE 클러스터에 배포되는 애플리케이션 코드 |
|
개발자 플랫폼 개발자 |
개발자 플랫폼 관리자 |
구성 동기화 |
구성 유지를 위해 GKE 클러스터에 사용되는 정책 |
자동화된 파이프라인은 보안, 감사 가능성, 추적 가능성, 반복 가능성, 제어 가능성 및 규정 준수를 배포 프로세스에 구축할 수 있습니다. 다른 권한을 가진 서로 다른 시스템을 사용하고 여러 사용자를 각기 다른 운영 그룹에 배치하여 책임을 분리하고 최소 권한의 원칙을 따릅니다.
기반 인프라 파이프라인
기반 인프라 파이프라인은 엔터프라이즈 기반 청사진에 설명되어 있으며, 추가 리소스 배포를 위한 일반 진입점으로 사용됩니다. 다음 표는 파이프라인이 만드는 구성요소에 대해 설명합니다.
| 구성요소 | 설명 |
|---|---|
개발자 플랫폼의 모든 테넌트가 사용하는 공유 인프라를 만듭니다. |
|
네임스페이스와 RBAC 역할 바인딩을 만듭니다. |
|
서비스를 배포하기 위해 사용되는 애플리케이션 CI/CD 파이프라인을 만듭니다. |
멀티 테넌트 인프라 파이프라인
멀티 테넌트 인프라 파이프라인은 Fleet, GKE 클러스터, 관련 공유 리소스를 배포합니다. 다음 다이어그램은 멀티 테넌트 인프라 파이프라인의 구성요소를 보여줍니다.
다음 표는 멀티 테넌트 인프라 파이프라인이 빌드하는 구성요소를 설명합니다.
| 구성요소 | 설명 |
|---|---|
GKE 클러스터 |
컨테이너화된 애플리케이션의 서비스를 위한 호스팅을 제공합니다. |
정책 컨트롤러 |
GKE 클러스터 및 서비스의 적절한 구성을 보장하는 데 도움이 되는 정책을 제공합니다. |
구성 동기화 |
정책 컨트롤러 정책을 클러스터에 적용하고 정책의 일관된 적용을 유지합니다. |
GKE용 고객 관리 암호화 키(CMEK), PostgreSQL용 AlloyDB, Secret Manager를 기반으로 하는 암호화 키를 만듭니다. |
|
Secret Manager 보안 비밀 |
JSON 웹 토큰(JWT)으로 사용자 인증에 사용되는 RSA 키 쌍을 위한 보안 비밀 저장소를 제공합니다. |
Google Cloud Armor 보안 정책 |
Google Cloud Armor 웹 애플리케이션 방화벽에서 사용하는 정책을 제공합니다. |
Fleet 범위 파이프라인
Fleet 범위 파이프라인은 Fleet의 GKE 클러스터에서 네임스페이스 및 RBAC 바인딩을 구성합니다. 다음 표에서는 Fleet 범위 파이프라인이 빌드하는 구성요소를 설명합니다.
| 구성요소 | 설명 |
|---|---|
물리적 클러스터 내에서 논리적 클러스터를 정의합니다. |
|
클러스터 수준 또는 네임스페이스 수준에서 Kubernetes 서비스 계정의 승인을 정의합니다. |
애플리케이션 팩토리
애플리케이션 팩토리는 기반 인프라 파이프라인에 의해 배포되며 각각의 새로운 애플리케이션을 위한 인프라를 구축하는 데 사용됩니다. 이 인프라에는 애플리케이션 CI/CD 파이프라인을 보유하는 Google Cloud 프로젝트가 포함되어 있습니다.
엔지니어링 조직이 확장됨에 따라 애플리케이션팀은 애플리케이션 팩토리를 사용하여 새 애플리케이션을 온보딩할 수 있습니다. 확장을 통해 개별 애플리케이션 CI/CD 파이프라인을 추가하고 멀티 테넌트 아키텍처 내에 새 애플리케이션을 배포할 수 있는 인프라를 지원함으로써 성장을 가능하게 합니다. 다음 다이어그램은 애플리케이션 팩토리를 보여줍니다.
애플리케이션 팩토리에는 다음과 같은 구성요소가 포함됩니다.
- 애플리케이션 팩토리 저장소: 선언적 애플리케이션 정의를 저장하는 Git 저장소입니다.
- 애플리케이션 생성을 위한 파이프라인: 다음을 완료하기 위해 Cloud Build가 필요한 파이프라인입니다.
- 선언적 애플리케이션 정의를 만들고 애플리케이션 카탈로그에 저장합니다.
- 선언적 애플리케이션 정의를 적용하여 애플리케이션 리소스를 만듭니다.
- 시작 애플리케이션 템플릿 저장소: 간단한 애플리케이션(예: Python, Golang, 자바 마이크로서비스)을 만들기 위한 템플릿입니다.
- 공유 모듈: 표준 관행에 따라 생성되고 애플리케이션 온보딩 및 배포를 포함하여 여러 목적으로 사용되는 Terraform 모듈입니다.
다음 표는 애플리케이션 팩토리가 각 애플리케이션에 대해 만드는 구성요소를 보여줍니다.
| 구성요소 | 설명 |
|---|---|
애플리케이션 소스 코드 저장소 |
특정 애플리케이션을 빌드하고 배포하는 데 사용되는 소스 코드와 관련 구성을 포함합니다. |
애플리케이션 CI/CD 파이프라인 |
소스 코드 저장소에 연결하는 데 사용되고 애플리케이션 서비스 배포를 위한 CI/CD 파이프라인을 제공하는 Cloud Build 기반 파이프라인입니다. |
애플리케이션 CI/CD 파이프라인
애플리케이션 CI/CD 파이프라인은 컨테이너 기반 애플리케이션의 자동화된 빌드 및 배포를 사용 가능하게 합니다. 파이프라인은 지속적 통합(CI) 및 지속적 배포(CD) 단계로 구성됩니다. 파이프라인 아키텍처는 보안 CI/CD 청사진을 기반으로 합니다.
애플리케이션 CI/CD 파이프라인은 환경 전반에 변경할 수 없는 컨테이너 이미지를 사용합니다. 변경 불가 컨테이너 이미지는 모든 환경 전반에 동일한 이미지가 배포되고 컨테이너가 실행되는 동안 수정되지 않게 하는 데 도움이 됩니다. 애플리케이션 코드를 업데이트하거나 패치를 적용해야 하는 경우 새 이미지를 빌드하고 다시 배포합니다. 변경 불가 컨테이너 이미지를 사용하기 위해서는 런타임 중 구성 정보가 읽혀지도록 컨테이너 구성을 외부화해야 합니다.
애플리케이션 CI/CD 파이프라인은 비공개 네트워크 경로를 통해 GKE 클러스터에 도달하고 kubeconfig 인증을 관리하기 위해 Connect 게이트웨이를 통해 GKE 클러스터와 상호작용합니다. 이 파이프라인은 CI/CD 환경에 비공개 풀도 사용합니다.
각 애플리케이션 소스 코드 저장소에는 Kubernetes 구성이 포함됩니다. 이러한 구성을 사용하면 애플리케이션이 GKE에서 Kubernetes 서비스로 성공적으로 실행될 수 있습니다. 다음 표에서는 애플리케이션 CI/CD 파이프라인이 적용하는 Kubernetes 구성 유형을 설명합니다.
| 구성요소 | 설명 |
|---|---|
확장된 포드 집합(컨테이너)을 정의합니다. |
|
클러스터 네트워크를 통해 배포할 수 있도록 합니다. |
|
서비스 메시의 서비스 부분을 만듭니다. |
|
서비스 메시의 피어가 가상 서비스에 연결하는 방법을 정의합니다. 청사진에서 횡방향 트래픽용 지역 부하 분산을 구성하는 데 사용됩니다. |
|
서비스 메시에서 워크로드 간 액세스 제어를 설정합니다. |
|
Kubernetes 서비스에서 사용되는 ID를 정의합니다. 워크로드 아이덴티티는 Google Cloud 리소스에 액세스하는 데 사용되는 Google Cloud 서비스 계정을 정의합니다. |
|
외부 인그레스 트래픽이 서비스에 도달하도록 허용합니다. 게이트웨이는 외부 트래픽을 수신하는 배포에서만 필요합니다. |
|
외부 트래픽을 수신하는 배포에 SSL, Google Cloud Armor, 세션 어피니티, 연결 드레이닝을 구성합니다. GCPBackendPolicy는 외부 트래픽을 수신하는 배포에서만 사용됩니다. |
|
애플리케이션에서 내보낸 Prometheus 측정항목 수집을 구성합니다. |
지속적 통합
다음 다이어그램은 지속적 통합 프로세스를 보여줍니다.
프로세스는 다음과 같습니다.
- 개발자가 애플리케이션 소스 저장소에 애플리케이션 코드를 커밋합니다. 이 작업은 Cloud Build를 트리거하여 통합 파이프라인을 시작합니다.
- Cloud Build가 컨테이너 이미지를 만들고, 컨테이너 이미지를 Artifact Registry에 푸시하여, 이미지 다이제스트를 만듭니다.
- Cloud Build는 애플리케이션에 대해 자동화된 테스트를 수행합니다. 애플리케이션 언어에 따라 다른 테스트 패키지가 수행될 수 있습니다.
- Cloud Build는 컨테이너 이미지에 대해 다음과 같은 스캔을 수행합니다.
- Cloud Build는 컨테이너 구조 테스트 프레임워크를 사용하여 컨테이너를 분석합니다. 이 프레임워크는 명령어 테스트, 파일 존재 테스트, 파일 콘텐츠 테스트, 메타데이터 테스트를 수행합니다.
- Cloud Build는 취약점 스캔을 사용하여 Google Cloud에서 유지되는 취약점 데이터베이스에 대해 컨테이너 이미지의 취약점을 식별합니다.
- Cloud Build는 스캔 결과 성공 시 이미지가 파이프라인에서 계속 사용되게 합니다.
- Binary Authorization이 이미지를 서명합니다. Binary Authorization은 Google Cloud에서 정책, 규칙, 참고, 증명, 증명자, 서명자를 사용해서 컨테이너 기반 애플리케이션에 대해 소프트웨어 공급망 보안을 제공하는 서비스입니다. 배포 시 Binary Authorization 정책 시행자는 컨테이너 배포를 허용하기 전 컨테이너의 출처를 확인하는 데 도움이 됩니다.
- Cloud Build는 Cloud Deploy에 출시 버전을 만들어 배포 프로세스를 시작합니다.
빌드에 대한 보안 정보를 보려면 보안 통계 패널로 이동하세요. 이러한 통계에는 Artifact Analysis를 사용하여 감지된 취약점과 SLSA 가이드라인으로 명시된 빌드의 보안 보장 수준이 포함됩니다.
애플리케이션을 빌드할 때는 컨테이너 빌드 권장사항을 따라야 합니다.
지속적 배포
다음 다이어그램은 지속적 배포 프로세스를 보여줍니다.
프로세스는 다음과 같습니다.
- 빌드 프로세스가 끝나면 애플리케이션 CI/CD 파이프라인이 새 Cloud Deploy 출시 버전을 만들어 새로 빌드된 컨테이너 이미지를 각 환경에 점진적으로 실행합니다.
- Cloud Deploy는 일반적으로 개발 중인 배포 파이프라인의 첫 번째 환경으로 출시를 시작합니다. 각 배포 단계는 수동 승인이 필요하도록 구성됩니다.
- Cloud Deploy 파이프라인은 순차적 배포를 사용해서 환경의 각 클러스터에 이미지를 순서대로 배포합니다.
- 각 배포 단계가 끝날 때 Cloud Deploy는 배포된 컨테이너의 기능을 검사합니다. 이 단계는 애플리케이션에 대한 Skaffold 구성 내에서 구성할 수 있습니다.
새 애플리케이션 배포
다음 다이어그램은 애플리케이션 팩토리와 애플리케이션 CI/CD 파이프라인이 어떻게 함께 작동하여 새 애플리케이션을 만들고 배포하는 방법을 보여줍니다.
새 애플리케이션을 정의하는 프로세스는 다음과 같습니다.
- 애플리케이션 운영자는 Cloud Build 트리거를 실행해서 애플리케이션 정의를 생성하여 테넌트 내에서 새 애플리케이션을 정의합니다.
- 트리거가 Terraform에서 애플리케이션의 새 항목을 추가하고 변경사항을 애플리케이션 팩토리 저장소에 커밋합니다.
- 커밋된 변경사항은 애플리케이션별 저장소 및 프로젝트 생성을 트리거합니다.
- Cloud Build는 다음을 완료합니다.
- 애플리케이션의 소스 코드와 IaC를 호스팅하기 위해 두 개의 새로운 Git 저장소를 만듭니다.
- 네트워크 정책에 대한 Kubernetes 매니페스트와 워크로드 아이덴티티를 구성 관리 저장소로 푸시합니다.
- 애플리케이션의 CI/CD 프로젝트 및 Cloud Build IaC 트리거를 만듭니다.
- 애플리케이션에 대한 Cloud Build IaC 트리거는 애플리케이션의 CI/CD 프로젝트에 애플리케이션 CI/CD 파이프라인과 Artifact Registry 저장소를 만듭니다.
- 구성 동기화는 네트워크 정책 및 워크로드 아이덴티티 구성을 멀티 테넌트 GKE 클러스터에 배포합니다.
- Fleet 범위 만들기 파이프라인은 멀티 테넌트 GKE 클러스터에서 애플리케이션에 대한 Fleet 범위 및 네임스페이스를 만듭니다.
- 애플리케이션의 CI/CD 파이프라인은 GKE 클러스터에 애플리케이션의 초기 배포를 수행합니다.
- 선택적으로 애플리케이션팀은 Cloud Build IaC 트리거를 사용하여 프로젝트 및 추가 리소스(예: 데이터베이스 및 기타 관리형 서비스)를 각 환경에 하나씩 전용 단일 테넌트 프로젝트에 배포합니다.
GKE Enterprise 구성 및 정책 관리
청사진에서 개발자 플랫폼 관리자는 구성 동기화를 사용하여 각 환경에서 클러스터 수준 구성을 만듭니다. 구성 동기화는 선택한 클러스터 구성 상태에 대한 정보 소스로 사용되는 Git 저장소에 연결됩니다. 구성 동기화는 클러스터에 있는 구성의 실제 상태를 지속적으로 모니터링하고 수동 변경 여부에 관계없이 선택된 상태를 준수하도록 업데이트를 적용하여 불일치를 조정합니다. 구성은 저장소에서 분기 전략을 사용하여 환경(개발, 비프로덕션, 프로덕션)에 적용됩니다.
이 청사진에서 구성 동기화는 정책 컨트롤러 제약조건을 적용합니다. 이러한 구성은 조직의 개발자 플랫폼 관리자가 정의한 보안 및 규정 준수 제어를 정의합니다. 이 청사진은 다른 파이프라인을 사용하여 다른 구성을 적용합니다. 즉, 애플리케이션 CI/CD 파이프라인은 애플리케이션별 구성을 적용하고 Fleet 범위 파이프라인은 네임스페이스와 관련 역할 바인딩을 만듭니다.
다음 단계
- Cymbal Bank 애플리케이션 아키텍처 알아보기(이 시리즈의 다음 문서)