Cloud Run에서 셸 작업 빌드 및 만들기

간단한 Cloud Run 작업을 만든 후 소스에서 배포하여 자동으로 코드를 컨테이너 이미지로 패키징하고, 컨테이너 이미지를 Artifact Registry에 업로드하고, Cloud Run에 배포하는 방법을 알아봅니다. 표시된 언어 외에 다른 언어도 사용할 수 있습니다.

시작하기 전에

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Cloud Run Admin API 및 Cloud Build API를 사용 설정합니다.
```
gcloud services enable run.googleapis.com \
    cloudbuild.googleapis.com
```
Cloud Run Admin API를 사용 설정하면 Compute Engine 기본 서비스 계정이 자동으로 생성됩니다.
Cloud Build가 소스를 빌드할 수 있게 하려면 다음을 실행하여 Compute Engine 기본 서비스 계정에 Cloud Build 서비스 계정 역할을 부여합니다.
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role=roles/cloudbuild.builds.builder
```
PROJECT_NUMBER를 Google Cloud 프로젝트 번호로, PROJECT_ID를 Google Cloud 프로젝트 ID로 바꿉니다. 프로젝트 ID와 프로젝트 번호를 찾는 방법은 프로젝트 만들기 및 관리를 참조하세요.

Compute Engine 기본 서비스 계정에 Cloud Build 서비스 계정 역할을 부여하려면 전파하는 데 몇 분 정도 걸립니다.

참고:
iam.automaticIamGrantsForDefaultServiceAccounts 조직 정책 제약조건은 편집자 역할이 기본 서비스 계정에 자동으로 부여되지 않도록 합니다. 2024년 5월 3일 이후에 조직을 만든 경우 기본적으로 이 제약조건이 적용됩니다.

이 제약조건을 적용하여 자동 역할 부여를 사용 중지하는 것이 좋습니다. 자동 역할 부여를 중지한 경우 기본 서비스 계정에 부여할 역할을 결정한 후 직접 이러한 역할을 부여해야 합니다.

기본 서비스 계정에 이미 편집자 역할이 있으면 편집자 역할을 권한이 더 낮은 역할로 바꾸는 것이 좋습니다. 서비스 계정 역할을 안전하게 수정하려면 정책 시뮬레이터를 사용하여 변경사항의 영향을 확인한 후 적절한 역할을 부여하고 취소합니다.

샘플 작업 작성

셸 스크립트를 실행하는 Cloud Run 작업을 작성하려면 다음 안내를 따르세요.

jobs라는 새 디렉터리를 만들고 이 디렉터리로 이동합니다.
```
mkdir jobs
cd jobs
```

다음 콘텐츠가 포함된 Dockerfile 파일을 만듭니다.


# Use the official Ubuntu image from Docker Hub as
# a base image
FROM ubuntu:24.04

# Execute next commands in the directory /workspace
WORKDIR /workspace

# Copy over the script to the /workspace directory
COPY script.sh .

# Just in case the script doesn't have the executable bit set
RUN chmod +x ./script.sh

# Run the script when starting the container
CMD [ "./script.sh" ]

같은 디렉터리에 실제 작업 코드에 대한 script.sh 파일을 만듭니다. 다음 샘플 줄을 복사합니다.

#!/bin/bash
set -euo pipefail

# In production, consider printing commands as they are executed. 
# This helps with debugging if things go wrong and you only 
# have the logs.
#
# Add -x:
# `set -euox pipefail`

CLOUD_RUN_TASK_INDEX=${CLOUD_RUN_TASK_INDEX:=0}
CLOUD_RUN_TASK_ATTEMPT=${CLOUD_RUN_TASK_ATTEMPT:=0}

echo "Starting Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT}..."

# SLEEP_MS and FAIL_RATE should be a decimal
# numbers. parse and format the input using 
# printf. 
#
# printf validates the input since it 
# quits on invalid input, as shown here:
#
#   $: printf '%.1f' "abc"
#   bash: printf: abc: invalid number
#
SLEEP_MS=$(printf '%.1f' "${SLEEP_MS:=0}")
FAIL_RATE=$(printf '%.1f' "${FAIL_RATE:=0}")

# Wait for a specific amount of time to simulate
# performing some work
SLEEP_SEC=$(echo print\("${SLEEP_MS}"/1000\) | perl)
sleep "$SLEEP_SEC" # sleep accepts seconds, not milliseconds

# Fail the task with a likelihood of $FAIL_RATE

# Bash does not do floating point arithmetic. Use perl 
# to convert into integer and multiply by 100.
FAIL_RATE_INT=$(echo print\("int(${FAIL_RATE:=0}*100"\)\) | perl)

# Generate a random number between 0 and 100
RAND=$(( RANDOM % 100))
if (( RAND < FAIL_RATE_INT )); then 
    echo "Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT} failed."
    exit 1
else 
    echo "Completed Task #${CLOUD_RUN_TASK_INDEX}."
fi

Cloud Run 작업을 사용하면 작업이 실행될 태스크의 수를 지정할 수 있습니다. 이 샘플 코드에서는 기본 제공 CLOUD_RUN_TASK_INDEX 환경 변수를 사용하는 방법을 보여줍니다. 각 태스크는 실행 중인 컨테이너의 복사본 하나를 나타냅니다. 태스크는 일반적으로 병렬로 실행됩니다. 각 태스크에서 데이터 하위 집합을 독립적으로 처리할 수 있는 경우 여러 태스크를 사용하는 것이 유용합니다.

각 태스크는 CLOUD_RUN_TASK_INDEX 환경 변수에 저장된 색인을 인식합니다. 기본 제공 CLOUD_RUN_TASK_COUNT 환경 변수에는 작업 실행 시 --tasks 매개변수를 통해 제공되는 태스크 수가 포함됩니다.

또한 표시된 코드는 기본 제공 CLOUD_RUN_TASK_ATTEMPT 환경 변수를 사용하여 태스크를 재시도하는 방법을 보여줍니다. 이 환경 변수에는 처음 시도할 때 0부터 시작하여 연속으로 재시도할 때마다 1씩 증가하여 --max-retries까지 이 태스크를 재시도한 횟수가 포함됩니다.

또한 코드를 사용하면 재시도를 테스트하기 위한 방법으로 오류를 생성하고 오류 로그를 생성하여 어떻게 표시되는지 확인할 수 있습니다.

코드가 완료되었으며 컨테이너에 패키징될 수 있습니다.

작업 컨테이너를 빌드하여 Artifact Registry로 전송하고 Cloud Run에 배포

중요: 이 빠른 시작에서는 빠른 시작에 사용 중인 프로젝트에 소유자 역할이나 편집자 역할이 있다고 가정합니다. 그렇지 않은 경우 소스에서 Cloud Run 리소스를 배포하는 데 필요한 권한은 Cloud Run 소스 개발자 역할을 참조하세요.

이 빠른 시작에서는 소스에서 배포를 사용하여 컨테이너를 빌드하고, Artifact Registry에 업로드하고, Cloud Run에 작업을 배포합니다.

gcloud run jobs deploy job-quickstart \
    --source . \
    --tasks 50 \
    --set-env-vars SLEEP_MS=10000 \
    --set-env-vars FAIL_RATE=0.1 \
    --max-retries 5 \
    --region REGION \
    --project=PROJECT_ID

여기서 PROJECT_ID는 프로젝트 ID이고 REGION은 리전입니다(예: us-central1). 다양한 매개변수를 테스트 목적으로 사용할 값으로 변경할 수 있습니다. SLEEP_MS는 작업을 시뮬레이션하고 FAIL_RATE로 인해 태스크의 X%가 실패하므로 동시 로드를 사용하여 실패한 태스크를 재시도할 수 있습니다.

Cloud Run에서 작업 실행

방금 만든 작업을 실행하려면 다음 명령어를 실행합니다.

gcloud run jobs execute job-quickstart --region REGION

REGION을 작업을 만들고 배포할 때 사용한 리전으로 바꿉니다(예: us-central1).

다음 단계

코드 소스에서 컨테이너를 빌드하고 저장소로 푸시하는 방법에 대한 자세한 내용은 다음을 참조하세요.