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

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

환경 설정하기

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 저장소를 클론합니다.

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 키 쌍을 생성합니다. your_email@example.com을 GitHub 이메일 주소로 바꿉니다. Cloud Shell에서 다음을 실행합니다.

      ssh-keygen -t rsa -b 4096 -m PEM -C "your_email@example.com"

   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:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
     --role roles/compute.admin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
     --role roles/iam.serviceAccountAdmin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
   --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
   --role roles/iam.securityAdmin \
   --project $TEST_PROJECT_ID
   

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

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

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

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

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

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

recommender-parser Cloud Run 서비스 배포

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

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

2. Cloud Run 서비스에 기본 리전을 사용하도록 Google Cloud 를 구성합니다. 이 튜토리얼에서는 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로 전달합니다. 그러면 이 튜토리얼에서 클론한 저장소에 제공되는 샘플 추천자 페이로드를 사용하여 파이프라인을 테스트할 수 있습니다.

   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 }"

추가 단계

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 요청 병합을 클릭합니다.

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

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

   • 배포 시 역할이 editor인 Terraform Test 서비스 계정이 viewer로 변경됩니다.