일관적이고 제어 가능한 방법으로 기반을 배포하는 선언적 인프라를 사용하는 것이 좋습니다. 이 방법은 허용되는 리소스 구성에 대한 정책 제어를 파이프라인에 적용하여 일관적인 거버넌스를 사용 설정하는 데 도움이 됩니다. 청사진은 배포 파이프라인의 코드형 인프라(IaC), 버전 제어 및 코드 승인을 위한 Git 저장소, CI/CD 자동화를 위한 Cloud Build를 정의하는 데 사용되는 Terraform에서 GitOps 흐름을 사용하여 배포됩니다. 이 개념에 대한 소개는 Terraform, Cloud Build, GitOps를 사용하여 인프라를 코드로 관리를 참조하세요.
다음 섹션에서는 조직에서 리소스 관리를 위해 배포 파이프라인이 사용되는 방법을 설명합니다.
파이프라인 레이어
여러 환경 레이어를 관리하는 팀 및 기술 스택을 구분하기 위해서는 각 스택 레이어를 담당하는 여러 다른 파이프라인 및 개인을 사용하는 모델이 권장됩니다.
다음 다이어그램은 기반 파이프라인, 인프라 파이프라인, 애플리케이션 파이프라인을 구분하기 위해 권장되는 모델을 보여줍니다.
이 다이어그램은 이 모델의 파이프라인 레이어를 소개합니다.
- 기반 파이프라인은 플랫폼 전체에서 사용되는 기반 리소스를 배포합니다. 단일 중앙 팀이 여러 사업부 및 워크로드에서 사용되는 기반 리소스를 관리하는 것이 좋습니다.
- 인프라 파이프라인은 VM 인스턴스 또는 데이터베이스와 같이 워크로드에 사용되는 프로젝트 및 인프라를 배포합니다. 이 청사진은 사업부마다 별개의 인프라 파이프라인을 설정합니다. 또는 여러 팀에서 사용되는 단일 인프라 파이프라인을 선호할 수도 있습니다.
- 애플리케이션 파이프라인은 컨테이너 또는 이미지와 같은 각 워크로드에 대해 아티팩트를 배포합니다. 여러 다른 애플리케이션팀에 개별 애플리케이션 파이프라인이 사용될 수 있습니다.
다음 섹션에서는 각 파이프라인 레이어의 사용을 소개합니다.
기반 파이프라인
기반 파이프라인은 기반 리소스를 배포합니다. 또한 워크로드에 사용되는 인프라 배포를 위해 인프라 파이프라인을 설정합니다.
기반 파이프라인을 만들려면 먼저 terraform-example-foundation을 자체 Git 저장소에 클론하거나 포크합니다. 0-bootstrap 리드미 파일의 단계에 따라 부트스트랩 폴더 및 리소스를 구성합니다.
| 단계 | 설명 |
|---|---|
Google Cloud 조직을 부트스트랩합니다. 이 단계에서는 또한 후속 단계의 청사진 코드에 대한 CI/CD 파이프라인을 구성합니다.
|
0-bootstrap 단계에서 기반 파이프라인을 만든 후에는 다음 단계에서 기반 파이프라인에 리소스를 배포합니다. 각 단계의 리드미 안내를 검토하고 각 단계를 순차적으로 구현합니다.
| 단계 | 설명 |
|---|---|
최상위 공유 폴더, 공유 서비스의 프로젝트, 조직 수준 로깅, 조직 정책을 통한 기준 보안 설정을 구성합니다. |
|
사용자가 만든 Google Cloud 조직 내에서 개발, 비프로덕션, 프로덕션 환경을 설정합니다. |
|
또는 |
선택한 토폴로지의 공유 VPC 및 연결된 네트워크 리소스를 설정합니다. |
인프라 파이프라인
인프라 파이프라인은 워크로드에 사용되는 프로젝트 및 인프라(예: VM 인스턴스 및 데이터베이스)를 배포합니다. 기반 파이프라인은 여러 인프라 파이프라인을 배포합니다. 이러한 기반 파이프라인과 인프라 파이프라인 사이의 구분에 따라 플랫폼 전체 리소스와 워크로드별 리소스를 구분할 수 있습니다.
다음 다이어그램은 청사진을 통해 개별 팀에서 사용하도록 의도된 여러 인프라 파이프라인을 구성하는 방법을 보여줍니다.
이 다이어그램은 다음과 같은 주요 개념을 설명합니다.
- 각 인프라 파이프라인은 기반 리소스와 별개로 인프라 리소스를 관리하기 위해 사용됩니다.
- 각 사업부에는
common폴더의 전용 프로젝트에서 관리되는 자체 인프라 파이프라인이 있습니다. - 각 인프라 파이프라인에는 해당 사업부와 연결된 프로젝트에만 리소스 배포 권한이 있는 서비스 계정이 있습니다. 이 전략은 기반 파이프라인에 사용되는 권한 있는 서비스 계정과 각 인프라 파이프라인에 사용되는 서비스 계정 사이에 책임을 구분합니다.
여러 인프라 파이프라인을 사용하는 이 방법은 조직 내에서 인프라를 개별적으로 관리하는 기술 및 성향이 있는 여러 부서가 있을 때, 특히 적용하려는 파이프라인 검증 정책 유형과 같은 여러 다른 요구사항이 있을 때 권장됩니다. 또는 일관된 검증 정책으로 단일 팀에서 관리되는 단일 인프라 파이프라인을 선호할 수 있습니다.
terraform-example-foundation에서 4단계는 인프라 파이프라인을 구성하고 5단계는 인프라 리소스 배포를 위한 파이프라인 사용 예시를 보여줍니다.
| 단계 | 설명 |
|---|---|
폴더 구조, 프로젝트, 인프라 파이프라인을 설정합니다. |
|
|
인프라 파이프라인을 예시로 사용해서 Compute Engine 인스턴스를 사용하여 워크로드 프로젝트를 배포합니다. |
애플리케이션 파이프라인
애플리케이션 파이프라인은 애플리케이션의 비즈니스 로직을 실행하는 이미지 또는 Kubernetes 컨테이너와 같은 개별 워크로드에 대한 애플리케이션 아티팩트를 배포합니다. 이러한 아티팩트는 인프라 파이프라인에서 배포하는 인프라 리소스에 배포됩니다.
엔터프라이즈 기반 청사진은 기반 파이프라인 및 인프라 파이프라인을 설정하지만 애플리케이션 파이프라인을 배포하지 않습니다. 예시 애플리케이션 파이프라인은 엔터프라이즈 애플리케이션 청사진을 참조하세요.
Cloud Build로 파이프라인 자동화
청사진은 Cloud Build를 사용하여 CI/CD 프로세스를 자동화합니다. 다음 표에서는 terraform-example-foundation 저장소를 통해 배포되는 기반 파이프라인 및 인프라 파이프라인에 포함된 제어 기능에 대해 설명합니다. 다른 CI/CD 자동화 도구를 사용해서 자체 파이프라인을 개발하는 경우 비슷한 제어 기능을 적용하는 것이 좋습니다.
| 제어 | 설명 |
|---|---|
배포 전 코드 검증을 위한 빌드 구성 분리 |
이 청사진은 전체 파이프라인에 대한 2개의 Cloud Build 빌드 구성 파일을 사용합니다. 단계마다 연결된 각 저장소에 이러한 빌드 구성 파일과 연결된 2개의 Cloud Build 트리거가 있습니다. 코드가 저장소 브랜치에 푸시되면 빌드 구성 파일이 트리거되어 먼저 |
Terraform 정책 점검 | 청사진에는 Google Cloud CLI의 정책 검증으로 적용된 Open Policy Agent 제약조건 집합이 포함됩니다. 이러한 제약조건은 파이프라인이 배포할 수 있는 허용되는 리소스 구성을 정의합니다. 빌드가 첫 번째 빌드 구성의 정책을 충족하지 않으면 두 번째 빌드 구성이 리소스를 배포하지 않습니다. 청사진에 적용된 정책은 GitHub의 |
최소 권한의 원칙 | 기반 파이프라인에는 단계마다 다른 서비스 계정이 포함되며 해당 단계에 대해 최소 IAM 역할만 부여하는 허용 정책이 있습니다. 각 Cloud Build 트리거는 해당 단계의 특정 서비스 계정으로 실행됩니다. 다른 계정을 사용하면 저장소를 수정할 때 다른 저장소에서 관리되는 리소스에 영향을 줄 수 있는 위험을 줄이는 데 도움이 됩니다. 각 서비스 계정에 적용된 특정 IAM 역할에 대해 알아보려면 부트스트랩 단계에서 |
Cloud Build 비공개 풀 | 청사진은 Cloud Build 비공개 풀을 사용합니다. 비공개 풀을 사용하면 필요에 따라 공개 저장소 액세스 제한 또는 VPC 서비스 제어 경계 내에서 Cloud Build 실행과 같은 추가적인 제어를 적용할 수 있습니다. |
Cloud Build 커스텀 빌더 | 청사진은 Terraform을 실행하기 위해 자체 커스텀 빌더를 만듭니다. 자세한 내용은 |
배포 승인 | 필요에 따라 Cloud Build에 수동 승인 단계를 추가할 수 있습니다. 이러한 승인은 권한 있는 사용자가 빌드를 수동으로 승인할 수 있도록 빌드가 트리거된 후 실행되기 전에 추가적인 체크포인트를 추가합니다. |
브랜칭 전략
Git 시스템에 코드를 제출하고 기반 파이프라인을 통해 리소스를 배포하기 위해서는 영구 브랜치 전략이 권장됩니다. 다음 다이어그램은 영구 브랜치 전략을 설명합니다.
이 다이어그램에서는 해당 Google Cloud 환경이 반영된 Git의 세 가지 영구 브랜치(개발, 비프로덕션, 프로덕션)에 대해 설명합니다. 또한 Google Cloud 환경에 배포되는 리소스에 해당하지 않는 여러 임시 기능 브랜치가 있습니다.
영구 브랜치에 병합되는 코드에 승인된 PR이 포함되도록 Git 시스템에 pull 요청(PR) 프로세스를 적용하는 것이 좋습니다.
이러한 영구 브랜치 전략으로 코드를 개발하려면 다음과 같은 대략적인 단계를 수행하세요.
- 새로운 기능을 개발하거나 버그 수정 작업을 수행할 때 개발 브랜치를 기준으로 새 브랜치를 만듭니다. 변경 유형, 티켓 번호 또는 기타 식별자,
feature/123456-org-policies와 같은 인간이 읽을 수 있는 설명이 포함된 브랜치에 대한 이름 지정 규칙을 사용합니다. - 기능 브랜치 작업이 완료되었으면 개발 브랜치를 대상으로 하는 PR을 시작합니다.
- PR을 제출하면 PR이
terraform plan및terraform validate를 수행하는 기반 파이프라인을 트리거하여 변경사항을 스테이징하고 확인합니다. - 코드 변경사항을 검증한 후 기능 또는 버그 수정을 개발 브랜치에 병합합니다.
- 병합 프로세스는 개발 브랜치의 최신 변경사항을 개발 환경에 배포하기 위해
terraform apply를 실행하는 기반 파이프라인을 트리거합니다. - 사용 사례와 관련된 수동 검토, 기능 테스트, 엔드 투 엔드 테스트를 사용하여 개발 환경의 변경사항을 검토합니다. 그런 후 비프로덕션 브랜치를 대상으로 하는 PR을 열어 비프로덕션 환경으로 변경사항을 승격하고 변경사항을 병합합니다.
- 리소스를 프로덕션 환경에 배포하려면 6단계: 배포된 리소스 검토 및 검증과 동일한 프로세스를 반복하고, 프로덕션 브랜치에 대해 PR을 열고 병합합니다.
다음 단계
- 작업 권장사항(이 시리즈의 다음 문서) 읽어보기