자동 확장, 자동 복구, 이미지 업데이트를 사용하여 MIG로 컨피덴셜 스페이스 워크로드 배포

1. 개요

Confidential Space (CS)는 민감한 정보를 처리하기 위한 안전하고 증명된 암호화 환경을 제공합니다. 독립형 VM 인스턴스를 사용하면 미션 크리티컬 서비스에 필요한 확장성이 수동 오케스트레이션에 부족하므로 운영 오버헤드가 발생합니다. 자동화된 오케스트레이션이 없으면 동기화된 순차 업데이트를 실행하거나 전체 기기에 새 OS 이미지를 배포하는 것이 기술적으로 어려워지고 다운타임이 발생하기 쉽습니다.

이 Codelab에서는 관리형 인스턴스 그룹 (MIG)에 컨피덴셜 스페이스 워크로드를 배포하는 방법을 알아봅니다. 또한 상태 점검을 사용한 자동 복구, CPU 사용률 기반 자동 확장, OS 이미지와 워크로드 모두에 대한 롤링 업데이트를 사용 설정하는 방법도 알아봅니다.

이 Codelab에 표시된 프로세스는 미션 크리티컬하고 장기 실행되는 배포를 위해 프로덕션 준비가 완료되고 안전한 자체 Confidential Space를 설정하는 데 도움이 됩니다.

학습할 내용

컨피덴셜 스페이스용 특수 인스턴스 템플릿을 만드는 방법
Google Compute Engine 사용 방법과 MIG 및 인스턴스 그룹 구성 방법
자동 복구를 위한 방화벽 규칙 및 상태 확인을 만드는 방법
템플릿과 상태 점검을 사용하여 영역 MIG를 구성하는 방법
MIG의 자동 확장을 설정하는 방법입니다.
Confidential Space의 워크로드 이미지와 새 OS 이미지 출시 모두에 대해 MIG에서 스크립트를 사용하여 클릭 한 번으로 OS 이미지 업데이트를 설정하는 방법

필요한 항목

결제가 사용 설정된 Google Cloud 프로젝트.
텍스트 편집기, Docker 배포, Bash 스크립트에 대한 지식
gcloud 명령줄 도구가 설치되고 인증되었습니다.
Compute Engine, 컨피덴셜 스페이스, IAM, 컨피덴셜 VM, 컨테이너 기술, 원격 저장소, 서비스 계정, Cloud Run, Cloud Scheduler에 대한 기본적인 이해
이미 빌드되어 Artifact Registry에 푸시된 Confidential Space 워크로드 컨테이너 이미지

2. MIG가 포함된 Confidential Space의 작동 방식

관리형 인스턴스 그룹 (MIG)을 사용하여 Confidential Space 워크로드를 배포하면 보안 애플리케이션이 더 강력하고 확장 가능하며 운영하기 쉬워집니다.

프로덕션 서비스의 보안 및 운영 요구사항은 두 구성요소 간에 논리적으로 나뉩니다. Confidential Space는 신뢰할 수 있는 실행 환경 (TEE)이라는 고도로 격리되고 암호화되고 증명된 환경에서 워크로드를 실행하여 필요한 보안을 제공합니다. 반면 MIG는 Kubernetes와 마찬가지로 안전한 애플리케이션을 대규모로 실행하는 데 필요한 필수 운영 기능을 제공합니다. MIG는 잠재적으로 느리거나 장애가 발생하기 쉬운 단일 VM에서 미션 크리티컬 워크로드를 실행할 때 발생하는 위험을 제거합니다. 이 조합은 데이터 보호와 시스템 안정성을 모두 보장합니다. 이 솔루션은 워크로드가 풀의 여러 VM에서 실행되므로 고가용성과 자동 복구를 보장합니다. VM 하나가 비정상 종료되더라도 부하 분산과 나머지 인스턴스의 존재로 인해 서비스는 완전히 작동합니다.

또한 MIG는 구성 가능한 상태 점검을 사용하여 VM의 작동 상태를 지속적으로 모니터링합니다. 인스턴스가 비정상으로 확인되면 MIG는 자동으로 새 정상 VM으로 대체하여 지속적인 작동을 보장합니다.

MIG는 자동 확장 기능을 통해 사용자에게 효과적인 확장성도 제공합니다. 이 기능을 사용하면 수동 개입 없이 용량을 자동으로 관리할 수 있으므로 사용률에 따라 용량을 유연하게 추가하거나 삭제할 수 있습니다.

마지막으로 MIG는 순차적 업데이트를 통해 다운타임 없는 업데이트를 지원합니다. 주요 이점은 서비스 다운타임을 유발하지 않고 기본 Confidential Space OS 이미지 또는 애플리케이션의 컨테이너 이미지 (또는 둘 다)를 '원클릭 업그레이드'할 수 있다는 것입니다. MIG는 업데이트된 이미지를 실행하는 최신 인스턴스로 이전 인스턴스를 점진적으로 교체하여 이 변경사항을 관리하므로 배포 전반에서 지속적인 가용성을 보장합니다. 이러한 유형의 점진적 업그레이드를 지원하려면 애플리케이션이 이전 버전과 호환되어야 할 수 있습니다.

3. 클라우드 리소스 설정

시작하기 전에

Google Cloud 프로젝트 설정 Google Cloud 프로젝트를 만드는 방법에 대한 자세한 내용은 '첫 번째 Google 프로젝트 설정 및 탐색' Codelab을 참고하세요. 프로젝트 만들기 및 관리를 참고하여 프로젝트 ID를 가져오는 방법과 프로젝트 이름 및 프로젝트 번호와 어떻게 다른지 자세히 알아보세요.
프로젝트에 결제를 사용 설정합니다.
Google 프로젝트의 Cloud Shell 중 하나에서 아래와 같이 필수 프로젝트 환경 변수를 설정합니다.

export  CURRENT_PROJECT_ID=<Google Cloud project id of current project>

프로젝트에 대해 컨피덴셜 컴퓨팅 API와 다음 API를 사용 설정합니다.

gcloud config set project $CURRENT_PROJECT_ID
gcloud services enable \
cloudapis.googleapis.com \
container.googleapis.com \
artifactregistry.googleapis.com \
confidentialcomputing.googleapis.com \
compute.googleapis.com \
logging.googleapis.com \
run.googleapis.com \
cloudscheduler.googleapis.com

Google Cloud 프로젝트 Cloud Shell에서 Confidential Space Codelab GitHub 저장소를 클론하고 아래 명령어를 사용하여 이 Codelab을 완료하는 데 필요한 적절한 스크립트를 가져옵니다.

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

디렉터리를 인스턴스 그룹 Codelab의 스크립트 디렉터리로 변경합니다.

cd confidential-space/codelabs/mig_cs_codelab/scripts

선택한 프로젝트를 반영하도록 config_env.sh의 프로젝트 ID 줄을 업데이트합니다.
기존 변수를 설정합니다. 이 변수를 사용하여 리소스 이름 재정의

기존 클라우드 리소스 이름으로 다음 변수를 설정할 수 있습니다. 변수가 설정되면 프로젝트의 기존 클라우드 리소스가 사용됩니다. 설정되지 않은 경우 클라우드 리소스 이름은 config_env.sh 스크립트에서 가져옵니다.

config_env.sh 스크립트를 실행하여 이 프로젝트의 나머지 변수 이름을 리소스 이름의 프로젝트 ID를 기반으로 하는 값으로 설정합니다.

source config_env.sh

프로젝트에 대한 권한을 추가합니다. IAM 역할 부여 웹페이지의 세부정보에 따라 권한을 추가할 수 있습니다.

이 프로젝트에 다음 권한이 필요합니다.

Artifact Registry 작성자
Cloud 스케줄러 관리자
Compute 서비스 에이전트
컨피덴셜 컴퓨팅 워크로드 사용자
로그 작성자
Cloud Run 개발자
Cloud Run 호출자

gcloud config set project $CURRENT_PROJECT_ID

# Add Artifact Registry Writer role
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/artifactregistry.writer'

# Add Confidential Space Workload Userd
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/confidentialcomputing.workloadUser'

# Add Logging Log Writer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/logging.logWriter'

# Add Cloud Run Developer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.developer'

# Add Cloud Run Invoker
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.invoker'


# Add Cloud Scheduler Admin
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/cloudscheduler.admin'

test_workload.py를 살펴봅니다.

소스 코드를 검토하여 워크로드의 출력을 확인합니다. 워크로드의 현재 버전이 출력되어야 합니다.
워크로드를 CS에 처음 푸시하고 출력을 확인하면 'version A'가 출력됩니다.

4. 워크로드 설정

먼저 이 Codelab에서 사용되는 워크로드의 Docker 이미지를 만들어야 합니다. 워크로드는 현재 실행 중인 워크로드의 버전을 출력하는 간단한 스크립트입니다. 워크로드가 시작된다고 출력한 다음 워크로드 버전을 출력하고 5초 동안 절전 모드로 전환한 다음 워크로드가 완료되었다고 출력합니다.

워크로드 생성 단계

create_workload.sh를 실행하여 워크로드를 만듭니다. 이 스크립트는 다음을 수행합니다.

워크로드가 게시될 프로젝트가 소유한 Artifact Registry를 만듭니다.
코드를 빌드하고 Docker 이미지에 패키징합니다. 자세한 정보는 연결된 Dockerfile 구성을 참고하세요.
프로젝트 소유의 Artifact Registry에 Docker 이미지를 게시합니다.
서비스 계정 <서비스 계정 이름>에 아티팩트 레지스트리 <아티팩트 레지스트리 저장소 이름>에 대한 읽기 권한을 부여합니다.

5. 인스턴스 템플릿 및 MIG 설정

인스턴스 템플릿을 만드는 단계

먼저 인스턴스 템플릿을 만들어야 합니다. 이 템플릿은 관리형 인스턴스 그룹 (MIG)이 Confidential Space 내에서 워크로드를 프로비저닝하고 실행하는 데 사용하는 필수 청사진입니다.

인스턴스 템플릿은 모든 전문화된 매개변수를 정의하므로 필수입니다.

머신 유형: 이 예에서는 AMD SEV 컨피덴셜 컴퓨팅 기술 (--confidential-compute-type=SEV)을 지원하는 컨피덴셜 VM 머신 유형 (예: n2d-standard-2)을 사용합니다.
VM OS 이미지: confidential-space-images 프로젝트와 confidential-space-debug 이미지 계열을 사용하여 최신 Confidential Space 운영체제 이미지를 가져옵니다.
참고: 이 가이드에서는 더 쉬운 문제 해결을 위해 debug 이미지를 사용합니다. 프로덕션 이미지와 달리 디버그 버전은 워크로드가 완료된 후에도 VM을 계속 실행하고 테스트를 위해 SSH 액세스를 허용합니다. 실제 민감한 데이터를 사용하는 프로덕션 배포의 경우 프로덕션 이미지 계열로 전환해야 합니다.
워크로드 참조: 메타데이터의 필수tee-image-reference 줄에는 Confidential Space VM이 실행할 특정 컨테이너 이미지 (애플리케이션 워크로드)가 포함되어 있습니다.

이 설정을 사용하면 MIG에서 생성된 모든 VM이 워크로드를 실행할 준비가 된 컨피덴셜 스페이스로 올바르게 구성됩니다.

관리형 인스턴스 그룹을 만드는 단계

다음 단계는 방금 정의한 템플릿을 사용하여 관리형 인스턴스 그룹 (MIG)을 만드는 것입니다. MIG는 동일한 여러 VM의 배포, 관리, 확장을 자동화하므로 필수적입니다.

create_launch_mig.sh 스크립트는 다음 세 가지 주요 목표를 달성합니다.

1. MIG 만들기

명령어: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
용도: 이 명령어는 VM을 관리할 그룹을 만듭니다.
--size 3: MIG가 워크로드의 인스턴스 3개를 처음부터 만들고 유지해야 함을 지정합니다.
--template ${TEMPLATE_NAME}: 중요한 점은 이전에 생성된 인스턴스 템플릿을 참조하여 3개의 인스턴스가 모두 특정 tee-image-reference 워크로드 컨테이너를 실행하는 컨피덴셜 스페이스 VM으로 구성되도록 한다는 것입니다.
--zone ${CURRENT_PROJECT_ZONE}: 인스턴스의 배포 위치를 지정합니다.

2. 프로젝트 번호 가져오기

명령어: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
용도: 스크립트가 프로젝트의 숫자 ID를 가져옵니다. 이 번호는 서비스 계정 역할 및 권한을 만드는 데 필요한 경우가 많으며, 특히 Google 관리 서비스 에이전트의 경우 더욱 그렇습니다.

3. IAM 권한 부여

명령어: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
목적: 이 단계에서는 워크로드의 서비스 계정 (${SERVICE_ACCOUNT)에 Compute Engine 서비스 에이전트 역할을 부여합니다. 이 권한은 서비스 계정이 프로젝트의 Compute Engine 서비스를 대신하여 작업을 수행할 수 있도록 하므로 중요합니다. 이는 인스턴스 관리, 네트워킹 설정, 다른 Google Cloud 서비스와의 상호작용과 같은 MIG의 자동화된 기능에 필요한 경우가 많습니다.

create_launch_mig.sh를 실행하여 관리형 인스턴스 그룹을 만듭니다.

6. 자동 복구 및 자동 확장을 사용 설정하는 단계

자동 복구 설정

고가용성을 보장하기 위해 워크로드가 응답하는지 확인합니다. 애플리케이션이 멈추면 MIG가 VM을 교체해야 합니다. 소스 IP 범위의 방화벽 규칙은 이 문서에 정의되어 있습니다.

# 1. Create Health Check (TCP Port 22)
gcloud compute health-checks create tcp ${HEALTH_CHECK_NAME} \
  --port 22 \
  --check-interval 30s \
  --healthy-threshold 1 \
  --timeout 10s \
  --unhealthy-threshold 3 \
  --global

# 2. Allow Health Check Traffic (Firewall)
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:22 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default \
    --project="${CURRENT_PROJECT_ID}" \ 

# 3. Apply to MIG
gcloud compute instance-groups managed update ${CURRENT_MIG_NAME} \
    --health-check ${HEALTH_CHECK_NAME} \
    --initial-delay 60 \
    --zone ${CURRENT_PROJECT_ZONE}

자동 확장 설정

트래픽 급증을 처리하기 위해 1~5개의 인스턴스 사이에서 자동으로 확장되도록 그룹을 구성합니다.

gcloud compute instance-groups managed set-autoscaling ${CURRENT_MIG_NAME} \
    --max-num-replicas 5 \
    --target-cpu-utilization 0.80 \
    --cool-down-period 90 \
    --zone ${CURRENT_PROJECT_ZONE}

7. 워크로드 확인 및 이미지 업데이트 설정

워크로드 확인

관리형 인스턴스 그룹 (MIG)에서 VM을 실행하면 컨피덴셜 스페이스 워크로드가 올바르게 실행되는지 확인해야 합니다.

Google Cloud 콘솔 또는 명령줄을 통해 이 작업을 수행할 수 있습니다.

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} \
    --zone ${CURRENT_PROJECT_ZONE}

특정 인스턴스의 직렬 포트 출력을 확인하여 워크로드의 로그를 확인할 수도 있습니다.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

이미지 업데이트 설정

프로덕션 환경에서는 다음 두 가지 시나리오를 해결하기 위해 관리형 인스턴스 그룹 (MIG)을 정기적으로 업데이트해야 합니다.

워크로드 업데이트: 애플리케이션 코드의 새 버전 출시 (예: test_workload.py를 v1에서 v2로 업데이트)
인프라 업데이트: Google에서 기본 Confidential Space OS의 보안 패치 또는 업데이트를 출시합니다. 최소한 매월 최신 CS 이미지를 선택하는 것이 좋습니다.

동적 이미지 링크 (.../images/family/...)와 동적 컨테이너 태그 (:latest)로 인스턴스 템플릿을 구성했으므로 단일 '롤링 교체' 작업으로 두 가지 시나리오를 모두 처리할 수 있습니다. 이렇게 하면 다운타임 없이 항상 최신 스택을 실행할 수 있으며, 사소한 변경사항이 있을 때마다 새 인스턴스 템플릿을 만들지 않아도 됩니다.

순차 교체 스크립트

update_images 디렉터리에서 update_images_script.sh로 이동합니다. 이 스크립트는 그룹의 모든 VM을 점진적으로 삭제하고 다시 만드는 순차적 교체를 트리거합니다.

#!/bin/bash

# Initialize the template
gcloud compute instance-groups managed set-instance-template "${CURRENT_MIG_NAME}" \
--template=projects/"${PROJECT_ID}"/global/instanceTemplates/"${TEMPLATE_NAME}" \
--zone="${CURRENT_PROJECT_ZONE}" \
--project="${PROJECT_ID}"

# Trigger the rolling replace
gcloud compute instance-groups managed rolling-action replace "${CURRENT_MIG_NAME}" \
    --version=template="${TEMPLATE_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --version-target-reached "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${PROJECT_ID}"

이 스크립트에서는 다시 시작하는 대신 바꾸기를 사용할 수 있습니다.

다시 시작은 머신을 다시 부팅하기만 합니다. 기존 OS 디스크를 유지하므로 새 OS 패치를 선택하지 않습니다.
바꾸기는 VM을 삭제하고 템플릿에서 새 VM을 만듭니다. 이렇게 하면 시스템에서 계열의 최신 Confidential Space OS 이미지를 조회하고 레지스트리에서 '최신' 컨테이너 이미지를 가져오게 됩니다.

–max-surge=1: MIG가 대상 크기보다 1개의 VM을 일시적으로 추가로 만들 수 있습니다. 새 (업데이트된) VM을 스핀업하고 이전 (오래된) VM을 삭제하기 전에 정상 상태가 될 때까지 기다립니다.

–max-unavailable=0: 다운타임이 없도록 합니다. 이는 MIG에 교체용을 이미 성공적으로 급증시키지 않은 한 머신을 오프라인으로 전환하는 것이 허용되지 않음을 알려줍니다.

순차적 재시작 스크립트

update_images 디렉터리에는 update_workload_image_script.sh라는 다른 스크립트도 있습니다. 이 스크립트는 순차적 다시 시작을 트리거합니다. 이는 워크로드를 새로고침하는 데만 사용되는 더 빠른 방법입니다. Confidential Space는 부팅할 때마다 레지스트리에서 컨테이너 이미지를 가져오므로 기본 호스트를 변경하지 않고도 다시 시작하는 것만으로 애플리케이션을 :latest 버전으로 업데이트할 수 있습니다.

#!/bin/bash
# Reboots the existing VMs to refresh the container
gcloud compute instance-groups managed rolling-action restart "${CURRENT_MIG_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --stable "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${CURRENT_PROJECT_ID}"

업데이트된 워크로드 확인

실제 애플리케이션 출시를 시뮬레이션하여 '원클릭 업그레이드'를 테스트할 수 있습니다. 워크로드 코드를 수정하고 Artifact Registry에 푸시하고 MIG를 업데이트하고 새 버전이 다운타임 없이 실행되는지 확인합니다.

1단계: 새 워크로드 버전 배포하기

먼저 애플리케이션의 '새' 버전을 만들어야 합니다.

로컬 test_workload.py 파일을 엽니다.
버전 출력 문을 print("Workload Version A")에서 print("Workload Version B")로 변경합니다.
create_workload.sh를 실행하여 컨테이너 이미지를 다시 빌드하고 Artifact Registry에 푸시합니다. 동일한 태그 (:latest)로 푸시합니다.

2단계: 순차적 업데이트 실행하기

이전 섹션에서 만든 업데이트 스크립트를 실행합니다. 이렇게 하면 MIG가 모든 VM을 교체하여 :latest와 연결된 새 컨테이너 해시를 가져옵니다.

# Run your update script
./update_images/update_images_script.sh

스크립트가 완료될 때까지 기다립니다.

3단계: 직렬 포트를 통해 업데이트 확인하기

업데이트가 완료되면 새 VM이 업데이트된 코드를 실행하는지 확인합니다.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

새 인스턴스의 이름을 가져옵니다.

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} --zone ${CURRENT_PROJECT_ZONE}

로그를 확인합니다.

# Replace <NEW_INSTANCE_NAME> with one of the names of the running VMs
gcloud compute instances get-serial-port-output <NEW_INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

인스턴스가 실행되면 이전 gcloud 명령어에서 인스턴스 이름을 선택하여 직렬 포트를 확인합니다.

예상 출력: 배포가 성공했음을 확인하는 업데이트된 로그 메시지가 표시됩니다.

... 워크로드 버전 B ...

4단계: 인프라 구성 확인 (선택사항)

메타데이터를 검사하여 인스턴스 템플릿이 OS와 워크로드 모두의 동적 업데이트를 가져오도록 올바르게 구성되었는지 확인할 수도 있습니다.

다음 명령어를 실행하여 동적 컨테이너 참조를 확인합니다.

gcloud compute instance-templates describe ${TEMPLATE_NAME} \
    | grep -A 1 tee-image-reference

결과: 컨테이너 이미지가 :latest로 끝나는 것을 확인할 수 있습니다.

의미: 템플릿이 특정 해시가 아닌 tag를 가리키므로 모든 순차적 교체 작업은 1단계에서 푸시한 최신 코드를 가져옵니다.

(선택사항) 자동 업데이트

수동 업데이트는 주요 버전 출시에 유용하지만, 사람의 개입 없이 최신 보안 패치나 정기 배포 빌드를 자동으로 선택하는 것이 좋습니다.

업데이트 스크립트를 Cloud Run 작업으로 패키징하여 '순차적 교체' 프로세스를 자동화할 수 있습니다. 이 Codelab에서는 15분마다 트리거합니다. 프로덕션 환경에서는 훨씬 덜 자주 실행해야 합니다. 사용자의 필요에 따라 주별 또는 월별로 구성할 수 있습니다.

1단계: 업데이터 스크립트 컨테이너화

먼저 클라우드에서 실행할 수 있도록 gcloud ... rolling-action replace 로직이 포함된 update_images_script.sh를 Docker 컨테이너로 패키징해야 합니다.

이 컨테이너를 빌드하고 Artifact Registry에 푸시하는 도우미 스크립트가 준비되어 있습니다.

다음 명령어를 실행합니다.

# Build and Push the "Updater" Container
# This packages your update logic into a docker image
./update_images/deploy_docker_script_image.sh

기능:

update_images/ 디렉터리에서 update_images_script.sh를 가져옵니다.
Google Cloud SDK와 스크립트가 포함된 Docker 이미지를 만듭니다.
이미지를 ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest로 푸시합니다.

2단계: 작업 배포 및 예약하기

이제 Google Cloud에 이 컨테이너를 주기적으로 실행하도록 지시해야 합니다. 컨테이너를 실행하는 데는 Cloud Run Jobs를 사용하고, 컨테이너를 트리거하는 데는 Cloud Scheduler를 사용합니다.

일정 구성 스크립트를 실행합니다.

# Create the Cloud Run Job and the Scheduler Trigger
./create_configs/create_schedule_job.sh

스크립트 내부: 이 스크립트는 두 가지 중요한 작업을 실행합니다.

Cloud Run 작업 생성: 방금 푸시한 컨테이너를 실행하는 mig-updater-job이라는 작업을 정의합니다.
스케줄러 트리거 생성: 15분마다 Cloud Run 작업 API를 호출하는 Cloud Scheduler 작업을 설정합니다.

# (Snippet from create_schedule_job.sh for reference)
# The schedule is set to run every 15 minutes for testing purposes
gcloud scheduler jobs create http ${SCHEDULER_NAME} \
    --schedule "*/15 * * * *" \
    --uri "https://${CURRENT_PROJECT_REGION}-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/${PROJECT_ID}/jobs/${JOB_NAME}:run" \
    --http-method POST \
    --oauth-service-account-email ${SERVICE_ACCOUNT}

3단계: 자동화 확인

테스트를 위해 15분 동안 기다리지 않아도 됩니다. 스케줄러를 강제로 즉시 실행하여 파이프라인을 확인할 수 있습니다.

작업 강제 실행:

gcloud scheduler jobs run ${SCHEDULER_NAME} --location ${CURRENT_PROJECT_REGION}

실행 확인: Cloud Run 콘솔 > 작업으로 이동합니다. 새 실행이 시작됩니다.
MIG 확인: gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}을 실행합니다. 작업에서 순차적 업데이트를 트리거하면 인스턴스가 RECREATING 상태로 전환됩니다.

15분인 이유 이 Codelab에서는 결과를 빠르게 확인할 수 있도록 일정을 */15 * * * * 로 설정합니다. 실제 프로덕션 환경에서는 매일 (예: 오전 3시의 경우 0 3 * * *) 또는 매주 실행되도록 변경할 수 있습니다.

8. 삭제

정리 스크립트 cleanup.sh를 사용하여 이 Codelab의 일부로 만든 리소스를 정리할 수 있습니다. 이 정리의 일환으로 다음 리소스가 삭제됩니다.

관리형 인스턴스 그룹 (${CURRENT_MIG_NAME}) 및 기본 VM
인스턴스 템플릿 (${TEMPLATE_NAME})
상태 점검 및 방화벽 규칙 (${HEALTH_CHECK_NAME})
Artifact Registry 저장소 (${REPOSITORY})
서비스 계정 (이 실습을 위해 전용 계정을 만든 경우)

탐색을 완료한 후에는 프로젝트 종료 (삭제)의 안내에 따라 프로젝트를 삭제하는 것이 좋습니다.

축하합니다

축하합니다. Codelab을 완료했습니다.

관리형 인스턴스 그룹 (MIG)을 사용하여 컨피덴셜 스페이스 워크로드를 안전하게 확장하는 방법을 알아봤습니다. 실패로부터 복구하기 위해 자동 복구를 구성하고, 트래픽 급증을 처리하기 위해 자동 확장을 구성하고, Confidential Space OS 이미지와 워크로드 컨테이너 모두에 대해 무중단 업데이트를 실행했습니다.

다음 단계

추가 Confidential Space Codelab을 확인하세요.

Confidential Space를 사용하여 ML 모델 및 지식 재산 보호하기
다자간 컴퓨팅 및 Confidential Space로 디지털 애셋을 거래하는 방법
Confidential Space로 기밀 데이터 분석
클라우드 제공업체에 저장되지 않은 보호된 리소스와 함께 Confidential Space 사용