인프라 추천을 코드로 사용하기

---

개요

Google Cloud Policy Intelligence는 기업에서 정책을 이해하고 관리하여 위험을 줄일 수 있도록 도와줍니다. 우수한 가시성과 자동화 덕분에 고객이 워크로드를 늘리지 않고도 보안을 강화할 수 있습니다.

추천자를 사용하면 Google Cloud 리소스 권장사항을 검색할 수 있으므로 클라우드 보안을 개선하고 비용을 절약할 수 있습니다. 지원되는 권장사항 목록은 추천자 문서를 참조하세요. 이 가이드에서는 VM 인스턴스에 대한 크기 권장사항과 ID 및 액세스 관리(IAM) 권장사항을 사용하는 방법을 설명합니다. 추천자는 더 효율적인 리소스 사용을 위해 Google Cloud 리소스에 대한 불필요한 액세스를 삭제하고 Compute Engine 인스턴스의 크기를 조정하기 위한 권장사항을 관리자에게 제공하기 위해 머신러닝을 사용합니다.

각 권장사항에는 제안 작업과 그 영향이 포함됩니다. 확인된 영향과 환경별 기타 고려사항에 대한 권장사항을 검토한 후 적용할 권장사항을 선택할 수 있습니다. Google Cloud 콘솔에서 수동으로 추천을 적용하거나 코드형 인프라(IaC) 파이프라인에 통합하여 프로그래매틱 방식으로 적용할 수 있습니다.

IaC를 사용하면 Google Cloud 리소스 생성을 자동화할 수 있습니다. IaC 저장소를 최신 상태로 유지하고 이 저장소를 통해 Google Cloud 조직에 만든 변경 사항을 라우팅해야 합니다. 조직의 IaC 전략은 일반적으로 엄격하게 구현되고 클라우드 인프라의 단일 버전 역할을 할 때 유용한 것으로 판명됩니다. IaC 저장소가 반영된 인프라 버전과 조직에 있는 인프라 사이의 드리프트를 방지하기 위해서 IaC 저장소를 최신 상태로 유지하는 것이 중요합니다.

IAM 권장사항

또 다른 주요 권장사항 중 일반적인 것은 최소 권한의 보안 원칙과 조직 변경사항을 출시하고 IaC 저장소와 동기화하는 방법을 신중하게 고려하는 것입니다.

VM의 크기 권장사항

크기 권장사항을 사용하면 인스턴스 리소스를 보다 효율적으로 사용할 수 있도록 인스턴스의 머신 유형 크기 조절하는 방법을 제공하여 비용을 절감할 수 있습니다.

이 가이드에서는 Policy Intelligence 권장사항을 프로그래매틱 방식으로 적용하기 위해 자동화 파이프라인을 설계하고 빌드하는 방법을 설명합니다. 이 자동화 파이프라인의 일부로 추천자가 제공하는 VM 크기 조정 및 IAM 정책 바인딩 추천에 따라 Google Cloud 조직에 적용하기로 결정한 변경사항으로 IaC 저장소를 최신 상태로 유지하는 방법을 알아봅니다.

이 튜토리얼에서는 Hashicorp Terraform을 IaC 도구로 사용합니다. 하지만 Deployment Manager와 같은 다른 IaC 관리 도구를 사용하더라도 설명된 자동 파이프라인에 사용된 아키텍처 패턴과 구성요소를 활용할 수 있습니다. 특정 IaC 구현에 적합하도록 이 가이드에서 사용할 수 있게 만든 오픈소스 코드베이스를 수정해야 합니다.

이 가이드는 Google Cloud의 관리, 보안, 인프라 계획을 담당하는 설계자, 제품 소유자, 개발자를 대상으로 합니다.

자동화 파이프라인 아키텍처

다음 다이어그램에서는 이 자동화 파이프라인에서 사용하는 구성요소를 보여줍니다.

예약된 Cloud Scheduler 작업은 Recommender Parser 서비스를 실행합니다. 서비스는 Recommender API를 호출하여 지정한 프로젝트의 추천자 권장사항을 가져옵니다. 그런 다음 이러한 VM 크기 조정 및 IAM 권장사항을 파싱하여 Terraform 매니페스트에 있는 구성에 매핑합니다. 서비스가 이러한 권장사항을 반영하도록 IaC 매니페스트를 업데이트합니다. 변경사항을 검토할 수 있도록 변경사항이 포함된 pull 요청을 생성합니다. pull 요청을 검토하고 병합하면 Cloud Build 작업이 Google Cloud 조직의 인프라에 변경사항을 적용합니다.

처리된 권장사항 추적, 빌드 완료에 대한 알림 생성, Terraform 상태 저장을 위해 파이프라인에서 여러 가지 기본 Google Cloud 서비스가 사용됩니다. 이 가이드를 통해 이러한 서비스에 대해 자세히 알아봅니다.

다음 목록에서는 구성요소 용도와 액세스 제어 요구사항을 설명합니다.

플랫폼 인텔리전스 추천자

용도: 보안 및 VM 크기 권장사항을 생성합니다.

액세스 제어: Google Cloud 서비스 계정에는 Recommender API를 사용하여 권장사항을 검색하는 데 필요한 IAM 권한이 있어야 합니다.

추천자 역할 및 권한을 검토하여 recommender-parser 서비스를 실행하는 데 사용하는 서비스 계정에 가장 적합한 역할을 선택합니다.

• IAM 추천자의 권한
• Compute Engine 인스턴스 크기를 조정할 수 있는 권한

Cloud Scheduler

용도: Cloud Scheduler가 Recommender Parser 서비스를 트리거합니다. Cloud Scheduler를 사용하면 필요한 만큼의 파서 서비스의 인스턴스를 호출하는 여러 작업을 설정할 수 있습니다. 각 호출은 다음 입력을 전달해야 합니다.

• 권장사항을 처리해야 하는 프로젝트 목록
• 권장사항 유형
• IaC 저장소 이름

참고: 기업에 IaC 저장소가 두 개 이상 있는 경우 여러 스케줄러 작업을 설정하려 할 수 있습니다. 이는 일반적으로 대기업의 일반적인 공통 패턴입니다.

액세스 제어: Cloud Scheduler에서 Recommender Parser 서비스로의 호출에 사용할 Google Cloud 서비스 계정을 만들거나 식별합니다.

서비스 계정이 Cloud Scheduler 작업을 실행할 수 있도록 이 계정에 Cloud Scheduler 서비스 에이전트 역할을 부여합니다. 또한 서비스 계정에서 Cloud Run 서비스를 호출하므로 이 계정에 Cloud Run 호출자 역할을 부여합니다.

자세한 내용은 스케줄러 작업에 대한 인증된 액세스 구성에 대한 문서를 참조하세요.

Cloud Run

용도: recommender-parser 서비스는 모든 처리 로직이 상주하는 곳입니다. 여기에는 여러 경로가 있으며 각 경로는 특정 용도로 사용됩니다.

• 각 권장사항 유형의 권장사항 파싱
• 처리 중인 권장사항의 상태 업데이트

액세스 제어: IAM을 사용하여 이 서비스에 대한 액세스 권한을 관리합니다.

또한 전용 서비스 계정에 서비스를 할당합니다. 이렇게 하면 서비스만 Firestore와 같은 다른 서비스를 호출할 수 있습니다.

Hashicorp Terraform

용도: Terraform 0.12는 IaC 도구입니다.

Terraform용 Cloud Build 빌더는 Terraform 명령어를 호출하는 데 사용되며 Cloud Build 서비스 계정은 이러한 용도로 사용됩니다.

Cloud Build

용도: Google Cloud Build는 Policy Intelligence 권장사항에 따라 IaC 매니페스트의 변경사항을 기준으로 인프라 배포를 자동화합니다.

액세스 제어: Cloud Build 서비스 계정에 테스트 프로젝트의 리소스와 상호작용할 수 있는 적절한 권한 집합이 있어야 합니다.

Cloud Build 서비스 계정 구성 문서를 참조하세요.

GitHub

용도: IaC 저장소는 소스 제어를 위해 GitHub를 사용합니다. GitHub의 IaC 저장소는 Cloud Build와 통합됩니다. 마스터 브랜치에 커밋이 수행되면 사전 구성된 작업 집합을 실행하도록 Cloud Build 작업이 트리거됩니다.

액세스 제어: IaC 저장소에 대한 액세스를 사용 설정하려면 SSH 키를 생성해야 합니다.

또한 GitHub에서 커밋을 푸시하려면 개인 액세스 토큰을 생성해야 합니다.

참고: GitHub에서 호스팅되는 비공개 저장소와 상호작용하는 경우 SSH 키와 개인 액세스 토큰이 필요합니다. 저장소가 공개되면(권장되지 않음) 이 단계가 적용되지 않습니다.

Firestore

Firestore는 이 아키텍처에서 사용되는 완전 관리형 확장형 NoSQL 문서 데이터베이스로, Git 커밋과 관련된 해당 세부정보와 함께 Recommender Parser 서비스에서 파싱한 권장사항 ID와 관련된 정보를 유지합니다.

Firestore에 유지되는 세부정보는 엔드 투 엔드 파이프라인의 일부인 피드백 루프에서 중요한 역할을 합니다. Recommender API가 생성한 권장사항을 선택하고 권장사항을 처리하기 전에 서비스가 권장사항 상태를 CLAIMED로 표시합니다. 권장사항이 성공적으로 적용되면 서비스가 데이터베이스에 쿼리하여 Cloud Build 작업에서 성공적으로 적용된 권장사항 ID를 검색하고 권장사항 상태를 SUCCEEDED로 변경합니다. Cloud Build 작업이 실패하면 권장사항 상태가 FAILED로 변경됩니다.

액세스 제어: 자세한 내용은 Firestore 역할을 참조하세요. recommender-parser 서비스는 Firestore에서 데이터를 읽고 이를 위해 roles/datastore.user 역할이 필요합니다.

Pub/Sub

용도: Cloud Build는 빌드 상태가 변경될 때(예: 빌드가 생성될 때, 빌드가 작동 상태로 전환될 때, 빌드가 완료될 때) Pub/Sub 주제에 메시지를 게시합니다.

Cloud Build가 메시지를 게시하는 Pub/Sub 주제를 cloud-builds라고 하고 프로젝트에서 Cloud Build API를 사용 설정하면 자동으로 생성됩니다.

액세스 제어: 푸시 구독은 서비스에서 요청을 승인하도록 인증 헤더를 제공하도록 구성할 수 있습니다. 자세한 내용은 푸시 구독 사용을 참조하세요.

목표

• 다음을 위한 자동화 파이프라인 빌드
  • 플랫폼 Policy Intelligence 권장사항 사전 모니터링
  • 권장사항 파싱 및 기존 IaC 저장소에 업데이트 적용
• Google Cloud 서비스 모음인 Hashicorp Terraform 및 GitHub를 사용하여 이 파이프라인을 빌드하는 방법을 알아보기
• 이 파이프라인을 빌드하기 위해 염두에 두어야 하는 가정과 권장사항 이해
• 파이프라인 테스트

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

• Cloud Run
• Cloud Build
• Compute Engine
• Cloud Storage
• Firestore
• Pub/Sub
• Cloud Scheduler
• Recommender

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

시작하기 전에

이 튜토리얼에서는 GitHub 계정이 있고 Git, Node.js, Terraform, Docker에 익숙하다고 가정합니다.

출시 노트 및 가정

IaC 도구 및 매니페스트를 사용하는 방식에는 많은 변수가 있습니다.

다음 정보를 검토하여 이 가이드를 IaC 파이프라인에 적용하는 방법 및 필요한 변경 유형을 확인합니다.

• 이 파이프라인은 Terraform 버전 0.12를 사용합니다. HCL 구성 구문의 중요 변경사항이나 Terraform 상태 파일의 구조 변경사항으로 인해 호환되지 않는 문제가 발생할 수 있습니다.
• 이 파이프라인은 IaC 디렉터리 구조가 중첩되지 않으며 IaC 저장소 하나가 Google Cloud 프로젝트 한 개 이상의 리소스를 관리한다고 가정합니다.
• 환경 변수로 전달된 Terraform 변수는 명령줄 인수가 지원되지 않습니다. 프로토타입은 tfvars 파일에 있는 Terraform 변수의 선언적 구성을 가정합니다.
• 역할의 권한 하위 집합이 60일 동안 사용되지 않았고 VM 크기 권장사항이 유사한 패턴을 따르는 경우 추천자는 IAM 권장사항을 생성합니다. 이 가이드에서는 파이프라인 테스트에 사용할 수 있는 샘플 권장사항 페이로드가 제공됩니다.
• 이 출시 버전에서는 Terraform 내 루프가 지원되지 않습니다.
• Terraform 모듈은 지원되지 않습니다. 코드베이스는 오픈소스이며, 디렉터리 구조와 모듈 사용법에 맞추도록 파싱 흐름에 필요한 특정 강화를 수행한다고 가정합니다.

현재 오픈소스 Recommender Parser 서비스 버전은 다음과 같은 알려진 IAM 권장사항 제한사항에 맞게 조정됩니다.

• 권장사항은 다음에 해당하는 Cloud IAM 정책 binding을 대상으로만 가능합니다.
  • 프로젝트 수준
  • 사용자 계정 및 사용자 관리 서비스 계정과 연결됨
• IAM 권장사항은 기본 역할과 사전 정의된 역할만 지원합니다. 커스텀 역할과 조건부 binding은 평가 및 권장되지 않습니다.
• 권장사항 역할에는 현재 역할 권한의 하위 집합만 포함됩니다. 권장사항 역할로 새 권한이 추가되지는 않습니다.

기본 요건

1. Google Cloud 프로젝트 두 개를 선택하거나 만듭니다.

   프로젝트 선택기 페이지로 이동

   • 자동화 파이프라인을 호스팅하고 실행하는 build 프로젝트
   • 자동화 파이프라인을 테스트하는 데 사용되는 Google Cloud 리소스를 호스팅하는 test 프로젝트

2. Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

3. test 프로젝트에서 Recommender 및 Compute Engine API를 사용 설정합니다.

   Enable the APIs

4. build 프로젝트에서 Cloud Run, Firestore, Pub/Sub, Cloud Scheduler, IAM, CloudResourceManager API를 사용 설정합니다.

   Enable the APIs

이 가이드를 마치면 만든 리소스를 삭제하여 비용이 계속 청구되지 않도록 할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

환경 설정하기

1. Google Cloud 콘솔에서 build 프로젝트를 선택합니다.

2. Google Cloud 콘솔에서 Cloud Shell로 이동합니다.

   Cloud Shell로 이동

   Google Cloud 콘솔 하단에서 Cloud Shell 세션이 열리고 명령줄 프롬프트가 표시됩니다. Cloud Shell은 Google Cloud CLI가 사전 설치된 셀 환경으로, 현재 프로젝트의 값이 이미 설정되어 있습니다. 세션이 초기화되는 데 몇 초 정도 걸릴 수 있습니다.

   이 가이드의 모든 터미널 명령어에 Cloud Shell을 사용합니다.

3. 다음 명령어를 사용하여 build 프로젝트의 프로젝트 번호를 저장할 환경 변수를 만듭니다.

   export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID
   

4. test 프로젝트의 프로젝트 번호를 저장할 환경 변수를 만듭니다. 테스트 프로젝트 ID를 수동으로 복사하고 PROJECT-ID를 바꿉니다.

   export TEST_PROJECT_ID=PROJECT-ID

5. 리전 및 영역과 같이 가이드 전반에 사용되는 값의 기본 설정을 할당합니다. 이 가이드에서는 us-central1을 기본 리전으로, us-central1-b를 기본 영역으로 사용합니다.

6. 다음 명령어를 실행하여 이 가이드의 기본 리전 및 영역을 설정합니다.

   gcloud config set compute/zone us-central1-b --project $BUILD_PROJECT_ID
   gcloud config set compute/zone us-central1-b --project $TEST_PROJECT_ID
   

7. build 프로젝트를 기본 프로젝트로 설정합니다.

   gcloud config set project $BUILD_PROJECT_ID
   

8. build 프로젝트 번호에 대한 BUILD_PROJECT_NUMBER라는 환경 변수 만들기

   export BUILD_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
   

9. 이 가이드의 GitHub 저장소를 클론합니다.

   참고: 별도로 명시하지 않는 한 Cloud Shell에서 이 가이드의 모든 명령어를 실행합니다.

Terraform 상태용 버킷 만들기

build 프로젝트에서 Terraform 상태 파일을 저장할 Cloud Storage 버킷을 만듭니다.

gcloud storage buckets create gs://recommender-tf-state-$BUILD_PROJECT_ID \
  --project=${BUILD_PROJECT_ID} --location=us-central1

GitHub 저장소 만들기

샘플 IaC 저장소로 사용할 GitHub 저장소를 만듭니다.

1. 새 비공개 GitHub 저장소를 만듭니다. 이 IAC-REPO-NAME 저장소는 이 가이드의 목적에 따라 IaC 저장소 역할을 합니다.

2. 다음 단계에서는 클론된 저장소의 sample-iac 하위 디렉터리에 있는 파일을 GitHub 계정으로 푸시합니다.

   1. Cloud Shell에서 sample-iac 디렉터리를 홈 디렉터리에 복사합니다. 이 디렉터리를 사용하여 새 로컬 저장소를 만들고 GitHub로 푸시합니다.

      cp -r recommender-iac-pipeline-nodejs-tutorial/sample-iac $HOME
      

   2. 새 디렉터리로 이동

      cd $HOME/sample-iac
      

   3. 로컬 머신에서 저장소를 초기화합니다.

      git init
      

   4. IAC-REPO-NAME을 원격 저장소로 추가하고 IAC-REPO-NAME 및 GITHUB-ACCOUNT를 적절한 값으로 바꿉니다.

      git remote add origin https://github.com/GITHUB-ACCOUNT/IAC-REPO-NAME

   5. 이 저장소의 파일에 있는 자리표시자를 test 프로젝트 ID와 Terraform Cloud Storage 버킷 이름으로 바꿉니다.

      sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./terraform.tfvars
      
      sed -i "s|__STATE_BUCKET_NAME__|recommender-tf-state-$BUILD_PROJECT_ID|g" ./backend.tf
      

   6. GitHub에 추가, 커밋, 푸시합니다.

      git add .
      git commit -m "First Commit"
      git push origin master
      

   7. 메시지가 표시되면 GitHub 계정에 로그인합니다.

저장소용 SSH 키 생성

GitHub에서 IaC 저장소로 SSH 키 인증을 설정하고 Cloud Storage에 키를 업로드합니다.

1. GitHub 저장소용 SSH 키를 생성합니다.

   1. SSH 키 쌍을 생성합니다. [e-mail]을 GitHub 이메일 주소로 바꿉니다. Cloud Shell에서 다음을 실행합니다.

      ssh-keygen -t rsa -b 4096 -m PEM -C "[e-mail]"

   2. '키를 저장할 파일을 입력하세요' 메시지가 나타나면 Enter 키를 누릅니다. 그러면 기본 파일 위치가 허용됩니다.

   3. 암호를 입력하라는 메시지가 표시되면 Enter를 누릅니다.

2. 다운로드한 SSH 키를 저장할 SSH-KEYS-DIR 디렉터리를 기록해 둡니다. 기본 위치는 $HOME/.ssh/입니다.

3. 생성한 SSH 공개 키를 GitHub 저장소에 배포 키로 복사합니다.

   1. Cloud Shell에서 생성한 SSH 공개 키를 복사합니다. SSH-KEYS-DIR를 디렉터리 경로로 바꿉니다.

      cat SSH-KEYS-DIR/id_rsa.pub

   2. GitHub 계정에서 IAC-REPO-NAME 저장소로 이동합니다.

   3. 설정 > 키 배포를 클릭합니다.

   4. 배포 키 추가를 클릭하고 복사한 SSH 공개 키를 붙여넣습니다. 키의 제목을 선택합니다.

   5. '쓰기 액세스 허용' 체크박스를 선택합니다.

   6. 저장을 클릭합니다.

4. Cloud Shell 세션으로 돌아가기

5. GitHub용 known_hosts 파일을 만듭니다. Cloud Shell 세션에서 다음 명령어를 실행합니다.

   ssh-keyscan github.com >> ~/.ssh/known_hosts
   

6. build 프로젝트에 Cloud Storage 버킷을 만들고 SSH 키와 known_hosts 파일을 버킷에 업로드합니다. SSH-KEYS-DIR를 SSH 키를 생성한 디렉터리의 경로로 바꿉니다.

   gcloud storage buckets create gs://github-keys-$BUILD_PROJECT_ID --project=${BUILD_PROJECT_ID} --location=us-central1
   
   gcloud storage cp SSH-KEYS-DIR/id_rsa* gs://github-keys-$BUILD_PROJECT_ID
   gcloud storage cp SSH-KEYS-DIR/known_hosts gs://github-keys-$BUILD_PROJECT_ID

7. GitHub용 개인 액세스 토큰을 생성합니다. 이 토큰은 recommender-parser 서비스가 pull 요청, 업데이트된 체크인 IaC 매니페스트를 생성하는 API 호출을 사용하여 Git 작업을 수행할 때 사용됩니다.

   1. GitHub 계정의 페이지 오른쪽 상단에 있는 프로필 사진을 클릭한 후 설정을 클릭합니다.

   2. 왼쪽 사이드바에서 개발자 설정을 클릭합니다.

   3. 왼쪽 사이드바에서 개인 액세스 토큰을 클릭합니다.

   4. 새 토큰 생성을 클릭합니다.

   5. 토큰에 설명이 포함된 이름을 지정합니다.

   6. 범위를 저장소로 선택합니다.

   7. 토큰 생성을 클릭합니다.

   8. 클립보드에 토큰을 복사합니다.

   9. Cloud Shell 세션에서 환경 변수를 만듭니다.

      export GITHUB_PAT=personal-access-token-you-copied

Cloud Build 설정

1. IAC-REPO-NAME Git 저장소를 연결하여 Cloud Build와 통합합니다.

   1. GitHub Marketplace의 Cloud Build 앱 페이지로 이동합니다.
   2. 아래로 스크롤하여 페이지 하단에 있는 Google Cloud Build로 설정을 클릭합니다.
   3. 메시지가 표시되면 GitHub에 로그인합니다.
   4. 저장소만 선택을 선택합니다. 저장소 선택 드롭다운 목록을 사용하여 Cloud Build 앱에서 IAC-REPO-NAME에 대한 액세스 권한만 사용 설정합니다.
   5. 설치를 클릭합니다.

   6. Google Cloud에 로그인합니다.

      승인 페이지가 표시되고 여기에 Google Cloud Build 앱이 Google Cloud에 연결되도록 승인하라는 메시지가 표시됩니다.

   7. Authorize Google Cloud Build by GoogleCloudBuild(GoogleCloudBuild로 Google Cloud Build 승인)를 클릭합니다. Google Cloud Console로 리디렉션됩니다.

   8. Google Cloud 프로젝트를 선택합니다.

   9. 동의 체크박스를 사용 설정하고 다음을 클릭합니다.

   10. 저장소 선택 페이지가 표시되면 IAC-REPO-NAME GitHub 저장소를 선택합니다.

   11. 저장소 연결을 클릭합니다.

   12. 트리거 만들기를 클릭합니다. 자동으로 트리거 정의가 생성됩니다.

   13. 만들기를 클릭하여 빌드 트리거를 저장합니다.

   자세한 내용은 GitHub에서 빌드 실행을 참조하세요.

2. 복사한 디렉터리에는 cloudbuild.yaml 파일이 있습니다. 이 구성 파일은 Cloud Build 작업이 트리거될 때 실행하는 단계를 간략하게 설명합니다.

   steps:
   - name: hashicorp/terraform:0.12.0
     args: ['init']
   - name: hashicorp/terraform:0.12.0
     args: ['apply', '-auto-approve']
   

3. Cloud Build 서비스 계정에 권한을 추가하여 테스트 프로젝트에서 서비스 계정, 연결 역할, 가상 머신(Compute Engine 인스턴스)을 만들 수 있습니다.

   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:$[e-mail] \
     --role roles/compute.admin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:$[e-mail] \
     --role roles/iam.serviceAccountAdmin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
   --member serviceAccount:$[e-mail] \
   --role roles/iam.securityAdmin \
   --project $TEST_PROJECT_ID
   

4. Google Cloud 콘솔에서 트리거 페이지를 엽니다.

5. build 프로젝트를 선택하고 열기를 클릭합니다.

6. 트리거 정의를 업데이트합니다.

   1. 메뉴를 클릭한 다음 수정을 클릭합니다.
   2. 구성에서 Cloud Build 구성 파일(yaml 또는 json) 옵션을 선택하고 텍스트 필드에 cloudbuild.yaml를 입력합니다.
   3. 저장을 클릭합니다.

7. 빌드 트리거를 수동으로 테스트하려면 트리거 목록의 트리거 항목에서 실행을 클릭합니다.

8. tf-compute-1이라는 Compute Engine 인스턴스와 Terraform Recommender Test라는 서비스 계정이 이전 단계에서 실행한 Cloud Build 작업으로 테스트 프로젝트에 생성되었는지 확인합니다.

참고: 테스트 프로젝트에서 리소스 생성을 확인하기 전에 Cloud Build 작업이 완료될 때까지 잠시 기다려야 할 수 있습니다.

recommender-parser Cloud Run 서비스 배포

1. Cloud Shell에서 디렉터리를 저장소를 클론하여 만든 디렉터리로 변경합니다.

   cd $HOME/recommender-iac-pipeline-nodejs-tutorial/parser-service
   

2. Google Cloud가 Cloud Run 서비스의 기본 리전을 사용하도록 구성합니다. 이 가이드에서는 us-central1 리전을 사용하지만 원하는 경우 지원되는 다른 리전을 선택할 수 있습니다.

   gcloud config set run/region us-central1
   

3. parser-service 디렉터리에는 recommender-parser 서비스를 테스트할 수 있는 샘플 페이로드 JSON이 몇 개 있는 스터브 하위 디렉터리가 있습니다. 다음 sed 명령어를 실행하여 이러한 JSON의 PROJECT_ID 자리표시자를 테스트 프로젝트 ID로 바꿉니다.

   sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/iam.json
   sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/vm.json
   

4. 다음 명령어를 실행하여 Docker 이미지의 환경 변수를 만듭니다.

   export IMAGE=gcr.io/$BUILD_PROJECT_ID/recommender-parser:1.0
   

5. 이미지를 빌드하고 Container Registry에 업로드합니다.

   gcloud builds submit --tag $IMAGE .
   

6. recommender-parser 서비스의 서비스 계정을 만들어 파이프라인의 다른 Google Cloud 서비스와 상호작용합니다. Cloud Run 서비스에 보다 세분화된 권한을 부여하는 것이 좋습니다. 자세한 내용은 Cloud Run 서비스 ID를 참조하세요.

   gcloud beta iam service-accounts create recommender-parser-sa \
     --description "Service account that the recommender-parser service uses to invoke other Google Cloud services" \
     --display-name "recommender-parser-sa" \
     --project $BUILD_PROJECT_ID
   

7. recommender-parser 서비스는 앞에서 만든 Cloud Storage 버킷에 업로드한 GitHub SSH 키와 Terraform 상태에 액세스해야 합니다. 서비스 계정을 Cloud Storage 버킷에 구성원으로 추가합니다.

   gcloud storage buckets add-iam-policy-binding gs://github-keys-$BUILD_PROJECT_ID \
     --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/storage.objectUser
   
   gcloud storage buckets add-iam-policy-binding gs://recommender-tf-state-$BUILD_PROJECT_ID \
     --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/storage.objectUser
   

8. recommender-parser 서비스의 서비스 계정에 Firestore, Recommender, Service Usage API에 대한 액세스 권한을 부여합니다.

   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/datastore.user
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.iamAdmin
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.iamViewer
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.computeAdmin
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/serviceusage.serviceUsageConsumer
   

9. 다음 명령어를 실행하여 recommender-parser라는 Cloud Run 서비스를 배포합니다. GITHUB-ACCOUNT를 이메일이 아닌 GitHub 계정 사용자 이름으로 바꿉니다. 시스템 프롬프트를 허용합니다.

   gcloud run deploy \
    --image=${IMAGE} \
    --no-allow-unauthenticated \
    --region us-central1 \
    --platform managed \
    --service-account recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --set-env-vars="GITHUB_ACCOUNT=github.com:GITHUB-ACCOUNT,GITHUB_PAT=${GITHUB_PAT},SSH_KEYS_BUCKET=github-keys-${BUILD_PROJECT_ID},TERRAFORM_STATE_BUCKET=recommender-tf-state-$BUILD_PROJECT_ID" \
    --project $BUILD_PROJECT_ID \
    recommender-parser

Firestore 설정

1. Google Cloud Console의 build 프로젝트에서 Firestore 페이지로 이동합니다.
2. 모드 선택 메시지가 표시되면 기본 모드 선택을 클릭합니다.
3. 기본 위치로 us-east1을 선택합니다.
4. 데이터베이스 만들기를 클릭합니다.

recommender-parser 서비스는 다음 목적으로 문서를 이 데이터베이스에 씁니다.

• Recommender API에서 검색한 권장사항을 추적하려면 다음 안내를 따르세요.
• 권장사항이 처리되면 각 처리된 권장사항의 상태를 적절하게 SUCCEEDED 또는 FAILED로 업데이트하기 위해 Recommender API를 호출합니다. 이는 권장사항이 불완전하게 또는 여러 번 처리되지 않도록 하여 파이프라인이 멱등성을 갖도록 하는 핵심 단계입니다.

Cloud Scheduler 작업 설정

1. Cloud Scheduler 작업이 recommender-parser 서비스를 실행하는 데 사용하는 서비스 계정을 만듭니다.

   gcloud beta iam service-accounts create recommender-scheduler-sa \
     --description "Service Account used by Cloud Scheduler to invoke the recommender-parser service" \
     --display-name "recommender-scheduler-sa" \
     --project $BUILD_PROJECT_ID
   

2. 서비스 계정에 Cloud Run 서비스를 호출할 수 있는 run/invoker 역할을 부여합니다.

   gcloud beta run services add-iam-policy-binding recommender-parser \
   --member=serviceAccount:recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/run.invoker \
   --region=us-central1
   

3. recommender-service URL을 가져옵니다.

   gcloud beta run services list --platform managed --project $BUILD_PROJECT_ID
   

   Cloud Scheduler 작업은 IAM 권장사항 항목을 파싱하기 위한 recommender-parser 서비스의 /recommendation/iam 경로를 호출하고 VM 크기 권장사항을 파싱하기 위한 /recommender/vm 경로를 호출합니다.

4. Cloud Scheduler 작업이 호출하는 엔드포인트의 변수를 만듭니다. RECOMMENDER-SERVICE-URL을 이전 단계에서 복사한 recommender-service URL로 바꿉니다.

   export RECOMMENDER_ROUTE_TO_INVOKE_IAM=RECOMMENDER-SERVICE-URL/recommendation/iam

   경로 정보를 추가한 후에 URL이 이 샘플 URL과 같아야 합니다.

   RECOMMENDER-SERVICE-URL/recommendation/iam
   

5. recommender-iam-scheduler.라는 Cloud Scheduler 작업을 만듭니다.

   • 개발자 위치를 기준으로 선택된 시간대를 변경합니다.
   • IAC-REPO-NAME를 생성한 GitHub 저장소의 이름으로 바꿉니다.

   메시지 본문은 세 가지 입력을 사용하므로 다음과 같이 구성되어야 합니다.

   • repo: GitHub 저장소 만들기에서 만든 GitHub 저장소 IAC-REPO-NAME의 이름입니다.

   • projects: 이 IaC GitHub 저장소가 매핑되는 Google Cloud 프로젝트 ID의 목록/배열입니다. 이 가이드에서는 test 프로젝트입니다.

   • stub: 역할의 권한 하위 집합이 60일 동안 사용되지 않고 VM 크기 권장사항이 유사한 패턴을 따르는 경우 추천자는 IAM 권장사항을 생성합니다. 요청 시 이 파이프라인을 테스트하기 위해 stub를 true로 전달하여 이 가이드에서 클론한 저장소에 제공되는 Recommender 페이로드를 사용하여 파이프라인을 테스트할 수 있습니다.

   gcloud beta scheduler jobs create http recommender-iam-scheduler \
     --project $BUILD_PROJECT_ID \
     --time-zone "America/Los_Angeles" \
     --schedule="0 */3 * * *" \
     --uri=$RECOMMENDER_ROUTE_TO_INVOKE_IAM \
     --description="Scheduler job to invoke recommendation pipeline" \
     --oidc-service-account-email="recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com" \
     --headers="Content-Type=application/json" \
     --http-method="POST" \
     --message-body="{ \"repo\": \"IAC-REPO-NAME\", \"projects\": [\"$TEST_PROJECT_ID\"], \"location\": \"global\", \"stub\": true }"

참고: --schedule="0 */3 * * *"는 3시간마다 스케줄러 작업을 실행합니다. 요구사항에 맞게 변경하세요. 또한 VM 크기 조정 권장사항을 파싱하는 스케줄러 작업을 만들어야 하는 경우에는 your-recommender-parser 서비스 URL을 /recommendation/vm과 함께 추가하고 --message-body 매개변수의 location 속성을 유효한 영역으로 설정해야 합니다.

추가 단계

Cloud Build는 빌드 프로젝트에서 Cloud Build API를 사용 설정할 때 자동으로 생성된 cloud-builds라는 Pub/Sub 주제에 빌드 정보를 게시합니다.

1. 다음 명령어를 실행하여 build 프로젝트에 cloud-builds 주제가 있는지 확인합니다.

   gcloud pubsub topics describe cloud-builds
   

   주제가 있으면 다음 출력이 표시됩니다. 여기서 BUILD-PROJECT-ID는 빌드 프로젝트 ID입니다.

   name: projects/BUILD-PROJECT-ID/topics/cloud-builds
   

   리소스를 찾을 수 없다는 오류 메시지가 표시되면 빌드 알림 구독의 안내에 따라 주제를 수동으로 만듭니다.

2. Pub/Sub이 recommender-parser 서비스 엔드포인트를 호출하는 데 사용하는 서비스 계정을 만듭니다.

   gcloud beta iam service-accounts create recommender-ci-subscription-sa \
     --description "Service Account used by Cloud Pub/Sub to push Cloud Build events to the recommender-parser service" \
     --display-name "recommender-ci-subscription-sa" \
     --project $BUILD_PROJECT_ID
   

3. Pub/Sub 서비스 계정은 메시지를 게시하고 recommender-parser 서비스를 호출하는 데 필요한 역할과 연결되어야 합니다.

   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/pubsub.publisher \
     --project $BUILD_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/pubsub.subscriber \
     --project $BUILD_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/run.invoker \
     --project $BUILD_PROJECT_ID
   

4. 생성한 recommender-ci-subscription-sa 서비스 계정을 invoker 역할이 있는 recommender-parser 서비스에 구성원으로 추가합니다.

   gcloud beta run services add-iam-policy-binding recommender-parser \
     --member=serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/run.invoker --region=us-central1
   

5. Google Cloud Console에서 Pub/Sub로 이동합니다.

6. cloud-builds 주제를 클릭합니다.

7. 구독 만들기를 클릭합니다.

8. 구독 ID에 recommender-service-build-events를 입력합니다.

9. 전송 유형에서 푸시를 선택합니다.

10. 엔드포인트에 /ci에서 추가된 recommender-service URL을 입력합니다.

11. 인증 사용 설정을 선택합니다.

    1. 만든 서비스 계정 recommender-ci-subscription-sa를 선택합니다.
    2. 프롬프트 메시지에 대한 응답으로 권한 부여를 클릭합니다.

12. 확인 기한 60초를 선택합니다.

13. 나머지 기본값을 유지합니다.

14. 만들기를 클릭합니다.

파이프라인 테스트

역할의 권한 하위 집합이 60일 동안 사용되지 않은 경우 추천자는 IAM 권장사항을 생성합니다. VM 크기 권장사항은 유사한 패턴을 따릅니다. 이 파이프라인을 주문형으로 테스트하려면 이 가이드의 클론된 저장소에 제공된 stub 하위 디렉터리에 제공된 샘플 권장사항 JSON 페이로드를 사용합니다. 그러면 recommender-parser가 Recommender API 엔드포인트에 수행한 API 호출을 제외하고 파이프라인을 테스트하여 성공적으로 적용된 권장사항 상태를 업데이트할 수 있습니다.

또는 Google Cloud 프로젝트에 활성 권장사항이 있는 경우 스터브를 사용하지 않고도 파이프라인을 엔드 투 엔드로 테스트할 수 있습니다. 아래 설명된 결과는 샘플 페이로드를 사용하여 파이프라인을 테스트하는 경우와 관련이 있습니다. 그러나 샘플 없이 이 파이프라인을 테스트하는 단계는 동일합니다.

1. Google Cloud 콘솔에서 테스트 프로젝트로 이동하여 생성된 리소스를 검토합니다. 다음 항목이 있어야 합니다.

   1. 머신 유형이 g1-small인 tf-compute-1이라는 Compute Engine 인스턴스
   2. 테스트 프로젝트의 editor 역할로 Terraform Recommender Test라는 서비스 계정

2. build 프로젝트의 Cloud Scheduler 콘솔 페이지에서 recommender-iam-scheduler 작업에 대한 지금 실행을 클릭합니다.

3. 작업을 클릭하여 로그를 봅니다. recommender-parser 서비스 로그를 보고 서비스에서 실행되는 단계를 자세히 살펴볼 수도 있습니다.

4. 서비스 실행이 완료되면 GitHub IAC-REPO-NAME 저장소로 이동합니다. recommender-parser 서비스가 자동으로 pull 요청을 생성했습니다. 이 pull 요청을 구성하는 수정된 IaC 매니페스트를 검토하고 IaC 매니페스트의 변경사항이 만족스러우면 pull 요청 병합을 클릭합니다.

   경고: 프로덕션 환경에서는 변경사항을 병합하기 전에 pull 요청을 사람이 직접 검토하는 강력한 승인 워크플로를 적용하는 것이 좋습니다. 검토자는 권장사항에서 식별된 영향을 평가하고, 인프라 및 비즈니스와 관련된 영향을 평가할 수 있는 지식이 있어야 합니다. 적절한 평가 없이 권장사항을 적용하면 시스템 성능 문제, 안정성 저하 또는 필수 권한 손실과 같은 예상치 못한 변경사항이 발생할 수 있습니다. 검토 프로세스 설정 안내는 GitHub 문서를 참조하세요.

5. pull 요청을 병합하면 마스터 브랜치에 대한 새 커밋이 생성됩니다. 이렇게 하면 test 프로젝트의 Google Cloud 리소스에 대한 수정사항이 출시되는 Cloud Build 작업이 트리거됩니다. Cloud Build 작업이 완료될 때까지 잠시 기다립니다. Google Cloud 콘솔에서 상태를 검토할 수 있습니다.

   참고: DevOps 파이프라인을 설정할 때 기능적 롤백 전략을 갖추는 것이 좋습니다. 예를 들어 이 가이드에서 빌드한 자동화 파이프라인에서 출시한 인프라 변경사항은 이전 Git 커밋으로 되돌려 롤백할 수 있습니다. 자세한 내용은 https://git-scm.com/docs/git-reset 및 이 Git 문서의 git revert 명령어를 참조하세요.

6. 작업이 완료되면 테스트 프로젝트로 이동합니다. 제공된 샘플 페이로드는 테스트 프로젝트의 리소스를 다음과 같이 변경합니다.

   • 배포 시 역할이 editor인 Terraform Test 서비스 계정이 viewer로 변경됩니다.
   참고: Cloud Scheduler 서비스를 실행하여 /recommendation/vm 엔드포인트에서 파싱 VM 크기 권장사항을 호출하면 원래 머신 유형이 g1-small인 Compute Engine 인스턴스 tf-compute-1이 f1-micro로 변경됩니다.

삭제

이 가이드에서 사용한 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 만든 두 프로젝트를 모두 삭제합니다.

비용이 청구되지 않도록 하는 가장 쉬운 방법은 가이드에서 만든 프로젝트를 삭제하는 것입니다.

프로젝트를 삭제하는 방법은 다음과 같습니다.

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

• 프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
• 커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

다음 단계

• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기
• 문서에서 Google Cloud Policy Intelligence에 대해 자세히 알아보세요.