Cloud Run에 컨테이너 이미지 배포

이 페이지에서는 컨테이너 이미지를 새 Cloud Run 서비스 또는 기존 Cloud Run 서비스의 새 버전에 배포하는 방법을 설명합니다.

새 서비스 배포에 대한 둘러보기 예시는 샘플 컨테이너 배포 빠른 시작을 참조하세요.

시작하기 전에

프로젝트에서 인증되지 않은 호출을 제한하는 도메인 제한 조직 정책이 적용되는 경우 비공개 서비스 테스트의 설명대로 배포된 서비스에 액세스해야 합니다.

필요한 역할

Cloud Run 서비스를 배포하는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 부여해 달라고 요청하세요.

Cloud Run 서비스에 대한 Cloud Run 개발자(roles/run.developer) 역할
서비스 ID에 대한 서비스 계정 사용자(roles/iam.serviceAccountUser) 역할

Cloud Run과 연결된 IAM 역할 및 권한 목록은 Cloud Run IAM 역할 및 Cloud Run IAM 권한을 참조하세요. Cloud Run 서비스가 Cloud 클라이언트 라이브러리와 같은 Google Cloud API와 상호작용하는 경우에는 서비스 ID 구성 가이드를 참조하세요. 역할 부여에 대한 자세한 내용은 배포 권한 및 액세스 관리를 참조하세요.

지원되는 Container Registry 및 이미지

Artifact Registry 또는 Docker Hub에 저장된 컨테이너 이미지를 직접 사용할 수 있습니다. Artifact Registry를 사용하는 것이 좋습니다.

Artifact Registry 원격 저장소를 설정하여 다른 공개 또는 비공개 레지스트리(예: JFrog Artifactory, Nexus 또는 GitHub Container Registry)의 컨테이너 이미지를 사용할 수 있습니다.

Docker 공식 이미지 또는 Docker 스폰서 OSS 이미지와 같이 인기 있는 컨테이너 이미지를 배포하기 위해서는 Docker Hub만 고려해야 합니다. 가용성을 높이려면 Artifact Registry 원격 저장소를 통해 이러한 Docker Hub 이미지를 배포하는 것이 좋습니다.

새 서비스 배포

태그(예: us-docker.pkg.dev/my-project/container/my-image:latest) 또는 정확한 다이제스트(예: us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...)로 컨테이너 이미지를 지정할 수 있습니다.

서비스에 처음 배포하면 첫 번째 버전이 생성됩니다. 버전은 변경할 수 없습니다. 컨테이너 이미지 태그로 배포를 수행할 때는 이것이 다이제스트로 확인되고, 버전에는 항상 이 특정 다이제스트가 제공됩니다.

선택한 도구 사용에 관한 안내를 보려면 해당 탭을 클릭하세요.

콘솔

컨테이너 이미지를 배포하려면 다음 안내를 따르세요.

Google Cloud 콘솔에서 Cloud Run 페이지로 이동합니다.

Cloud Run으로 이동
컨테이너 배포를 클릭하고 서비스를 선택하여 서비스 만들기 양식을 표시합니다.
1. 양식에서 배포 옵션을 선택합니다.
  1. 컨테이너를 수동으로 배포하려면 기존 컨테이너 이미지에서 하나의 버전 배포를 선택하고 컨테이너 이미지를 지정합니다.
  2. 지속적 배포를 자동화하려면 소스 저장소에서 지속적으로 새 버전 배포를 선택하고 지속적 배포 안내를 따릅니다.
2. 필요한 서비스 이름을 입력합니다. 서비스 이름은 49자(영문 기준) 이하여야 하며 리전과 프로젝트별로 고유해야 합니다. 서비스 이름은 나중에 변경할 수 없으며 공개적으로 표시됩니다.
3. 서비스를 배치할 리전을 선택합니다. 리전 선택기는 가격 등급, 도메인 매핑의 가용성을 나타내고, 탄소 배출량이 가장 낮은 리전을 강조표시합니다.
4. 필요에 따라 CPU 할당 및 가격 책정을 설정합니다.
5. 자동 확장에서 최소 및 최대 인스턴스를 지정합니다.
6. 필요에 따라 양식에서 인그레스 설정을 지정합니다.
7. 인증 아래에서 다음을 구성합니다.
  - 공개 API 또는 웹 사이트를 사용하는 경우 인증되지 않은 호출 허용을 선택합니다. 이를 선택하면 IAM 호출자 역할이 특수 식별자 allUser에 할당됩니다. 서비스를 만든 후 나중에 IAM을 사용하여 이 설정을 수정할 수 있습니다.
  - 보안 서비스를 인증으로 보호하려면 인증 필요를 선택합니다.
컨테이너, 볼륨, 네트워킹, 보안을 클릭하여 해당 탭에서 다른 선택적 설정을 지정합니다.
서비스 구성을 마쳤으면 만들기를 클릭하여 이미지를 Cloud Run에 배포하고 배포가 완료되도록 기다립니다.
배포된 서비스의 고유한 공개 버전 엔드포인트를 열려면 표시된 URL을 클릭합니다.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
컨테이너 이미지를 배포하려면 다음 안내를 따르세요.
1. 다음 명령어를 실행합니다.
```
gcloud run deploy SERVICE --image IMAGE_URL
```
  - SERVICE를 배포하려는 서비스 이름으로 바꿉니다. 서비스 이름은 49자(영문 기준) 이하여야 하며 리전과 프로젝트별로 고유해야 합니다. 서비스가 존재하지 않으면 배포 중 이 명령어로 서비스가 생성됩니다. 이 매개변수를 완전히 생략할 수 있지만 생략하면 서비스 이름을 입력하라는 메시지가 표시됩니다.
  - IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다. --image 플래그를 제공하지 않으면 배포 명령어가 소스 코드에서 배포를 시도합니다.
  공개 API 또는 웹사이트를 만드는 경우 --allow-unauthenticated 플래그를 사용하여 서비스의 인증되지 않은 호출을 허용합니다. 그러면 Cloud Run 호출자 IAM 역할이 allUsers에 할당됩니다. 또한 인증되지 않은 호출을 허용하지 않도록 --no-allow-unauthenticated를 지정할 수 있습니다. 이러한 플래그를 생략하면 deploy 명령어가 실행될 때 확인 메시지가 표시됩니다.
2. 배포가 완료될 때까지 기다립니다. 성공적으로 완료되면 배포된 서비스의 URL이 포함된 성공 메시지가 표시됩니다.
run/region gcloud 속성을 사용하여 설정한 위치와 다른 위치에 배포하려면 다음을 사용합니다.
```
gcloud run deploy SERVICE --region REGION
```

YAML

YAML 파일에 서비스 사양을 저장한 후 gcloud CLI를 사용하여 배포할 수 있습니다.

다음 콘텐츠로 새 service.yaml 파일을 만듭니다.
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: IMAGE
```
다음과 같이 바꿉니다.
- SERVICE를 Cloud Run 서비스 이름으로 바꿉니다. 서비스 이름은 49자(영문 기준) 이하여야 하며 리전과 프로젝트별로 고유해야 합니다.
- IMAGE를 컨테이너 이미지의 URL로 바꿉니다.
또한 환경 변수 또는 메모리 제한과 같은 추가 구성을 지정할 수 있습니다.
다음 명령어를 사용하여 새 서비스를 배포합니다.
```
gcloud run services replace service.yaml
```
선택적으로 서비스에 대한 인증되지 않은 액세스를 허용하려면 서비스를 공개로 설정합니다.

Cloud Code

Cloud Code를 사용하여 배포하려면 IntelliJ 및 Visual Studio Code 가이드를 읽어보세요.

Terraform

Terraform을 사용하는 경우 Google Cloud Platform 제공업체의 google_cloud_run_v2_service 리소스를 사용하여 Terraform 구성에 서비스를 정의합니다.

다음 내용으로 새 main.tf 파일을 만듭니다.
```
provider "google" {
  project = "PROJECT-ID"
}

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  client   = "terraform"

  template {
    containers {
      image = "IMAGE"
    }
  }
}

resource "google_cloud_run_v2_service_iam_member" "noauth" {
  location = google_cloud_run_v2_service.default.location
  name     = google_cloud_run_v2_service.default.name
  role     = "roles/run.invoker"
  member   = "allUsers"
}
```
다음과 같이 바꿉니다.
- PROJECT-ID를 Google Cloud 프로젝트 ID로 바꿉니다.
- REGION을 Google Cloud 리전으로 바꿉니다.
- SERVICE를 Cloud Run 서비스 이름으로 바꿉니다. 서비스 이름은 49자 이하여야 하며 리전 및 프로젝트별로 고유해야 합니다.
- IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
이 구성은 공개 액세스를 허용합니다(--allow-unauthenticated와 동일). 서비스를 비공개로 설정하려면 google_cloud_run_v2_service_iam_member 스탠자를 삭제합니다.
Terraform을 초기화합니다.
```
terraform init
```
Terraform 구성을 적용합니다.
```
terraform apply
```
yes를 입력하여 기술된 작업 적용을 확인합니다.

클라이언트 라이브러리

코드에서 새 서비스를 배포하려면 다음 안내를 따르세요.

REST API

새 서비스를 배포하려면 POST HTTP 요청을 Cloud Run Admin API service 엔드포인트로 보냅니다.

예를 들어 다음과 같이 curl을 사용합니다.

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X POST \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE

다음과 같이 바꿉니다.

ACCESS_TOKEN을 서비스를 배포할 수 있는 IAM 권한이 있는 계정의 유효한 액세스 토큰으로 바꿉니다. 예를 들어 gcloud에 로그인한 경우 gcloud auth print-access-token을 사용하여 액세스 토큰을 검색할 수 있습니다. Cloud Run 컨테이너 인스턴스 내에서 컨테이너 인스턴스 메타데이터 서버를 사용하여 액세스 토큰을 검색할 수 있습니다.
IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
SERVICE를 배포할 서비스의 이름으로 바꿉니다. 서비스 이름은 49자(영문 기준) 이하여야 하며 리전과 프로젝트별로 고유해야 합니다.
REGION을 서비스의 Google Cloud 리전으로 바꿉니다.
PROJECT-ID를 Google Cloud 프로젝트 ID로 바꿉니다.

Cloud Run 위치

Cloud Run은 리전을 기반으로 합니다. 즉, Cloud Run 서비스를 실행하는 인프라가 특정 리전에 위치해 있으며 해당 리전 내의 모든 영역에서 중복으로 사용할 수 있도록 Google이 관리합니다.

Cloud Run 서비스를 실행하는 리전을 선택하는 데 있어 중요한 기준은 지연 시간, 가용성 또는 내구성 요구사항입니다. 일반적으로 사용자와 가장 가까운 리전을 선택할 수 있지만 Cloud Run 서비스에서 사용하는 다른 Google Cloud 제품 위치도 고려해야 합니다. 여러 위치에서 Google Cloud 제품을 함께 사용하면 서비스 지연 시간과 비용에 영향을 미칠 수 있습니다.

Cloud Run은 다음 리전에서 사용할 수 있습니다.

등급 1 가격 적용

asia-east1(타이완)
asia-northeast1(도쿄)
asia-northeast2(오사카)
europe-north1(핀란드) 낮은 CO₂
europe-southwest1(마드리드) 낮은 CO₂
europe-west1(벨기에) 낮은 CO₂
europe-west4(네덜란드) 낮은 CO₂
europe-west8(밀라노)
europe-west9(파리) 낮은 CO₂
me-west1(텔아비브)
us-central1(아이오와) 낮은 CO₂
us-east1(사우스캐롤라이나)
us-east4(북 버지니아)
us-east5(콜럼버스)
us-south1(댈러스) 낮은 CO₂
us-west1(오리건) 낮은 CO₂

등급 2 가격 적용

africa-south1(요하네스버그)
asia-east2(홍콩)
asia-northeast3(대한민국 서울)
asia-southeast1(싱가포르)
asia-southeast2 (자카르타)
asia-south1(인도 뭄바이)
asia-south2(인도 델리)
australia-southeast1(시드니)
australia-southeast2(멜버른)
europe-central2(폴란드 바르샤바)
europe-west10(베를린) 낮은 CO₂
europe-west12(토리노)
europe-west2(영국 런던) 낮은 CO₂
europe-west3(독일 프랑크푸르트) 낮은 CO₂
europe-west6(스위스 취리히) 낮은 CO₂
me-central1(도하)
me-central2(담맘)
northamerica-northeast1(몬트리올) 낮은 CO₂
northamerica-northeast2(토론토) 낮은 CO₂
southamerica-east1(브라질 상파울루) 낮은 CO₂
southamerica-west1(칠레 산티아고) 낮은 CO₂
us-west2(로스앤젤레스)
us-west3(솔트레이크시티)
us-west4(라스베이거스)

Cloud Run 서비스를 이미 만들었다면 Google Cloud 콘솔의 Cloud Run 대시보드에서 리전을 확인할 수 있습니다.

배포 시 Cloud Run 서비스 에이전트가 배포된 컨테이너에 액세스할 수 있어야 합니다. 이것이 기본 설정입니다.

서비스마다 시간이 지나 새 버전이 배포될 때도 변경되지 않는 고유한 영구 URL이 있습니다.

기존 서비스의 새 버전 배포

Google Cloud 콘솔, gcloud 명령줄 또는 YAML 구성 파일을 사용하여 새 버전을 배포할 수 있습니다.

구성 설정을 변경하면 컨테이너 이미지가 변경되지 않아도 새 버전이 생성됩니다. 생성된 각 버전은 변경할 수 없습니다.

선택한 도구 사용에 관한 안내를 보려면 해당 탭을 클릭하세요.

콘솔

기존 서비스의 새 버전을 배포하려면 다음 안내를 따르세요.

Google Cloud 콘솔에서 Cloud Run 페이지로 이동합니다.

Cloud Run으로 이동
서비스 목록에서 업데이트할 서비스를 찾고 클릭하여 해당 서비스의 세부정보를 엽니다.
새 버전 수정 및 배포를 클릭하여 버전 배포 양식을 표시합니다.
1. 필요한 경우 배포하려는 새 컨테이너 이미지 URL을 제공합니다.
2. 필요에 따라 컨테이너를 구성합니다.
3. 필요에 따라 CPU 할당 및 가격 책정을 설정합니다.
4. 용량에서 메모리 한도와 CPU 한도를 지정합니다.
5. 필요에 따라 요청 제한 시간과 동시 실행을 지정합니다.
6. 필요에 따라 실행 환경을 지정합니다.
7. 자동 확장에서 최소 및 최대 인스턴스를 지정합니다.
8. 필요에 따라 다른 탭을 사용하여 다음을 선택적으로 구성합니다.
모든 트래픽을 새 버전으로 전송하려면 이 버전을 즉시 제공을 선택합니다. 새 버전을 점진적으로 출시하려면 해당 체크박스를 선택 취소합니다. 이렇게 하면 트래픽이 새 버전으로 전송되지 않는 배포가 생성됩니다. 배포 후 점진적 출시 안내를 따릅니다.
배포를 클릭하고 배포가 완료될 때까지 기다립니다.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
컨테이너 이미지를 배포하려면 다음 안내를 따르세요.
1. 다음 명령어를 실행합니다.
```
gcloud run deploy SERVICE --image IMAGE_URL
```
  - SERVICE를 배포할 서비스의 이름으로 바꿉니다. 이 매개변수를 완전히 생략할 수 있지만 생략하면 서비스 이름을 입력하라는 메시지가 표시됩니다.
  - IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
  새 버전의 경우 버전 서픽스가 자동으로 할당됩니다. 고유 버전 서픽스를 제공하려면 gcloud CLI 매개변수 --revision-suffix를 사용합니다.
2. 배포가 완료될 때까지 기다립니다. 성공적으로 완료되면 배포된 서비스의 URL이 포함된 성공 메시지가 표시됩니다.

YAML

기존 서비스 구성을 다운로드하거나 확인해야 할 경우에는 다음 명령어를 사용해서 결과를 YAML 파일로 저장합니다.

gcloud run services describe SERVICE --format export > service.yaml

서비스 구성 YAML 파일에서 필요에 따라 모든 spec.template 하위 속성을 수정하여 버전 설정을 업데이트한 후 새 버전을 배포합니다.

gcloud run services replace service.yaml

Cloud Code

Cloud Code를 사용하여 기존 서비스의 새 버전을 배포하려면 IntelliJ 및 Visual Studio Code 가이드를 참조하세요.

Terraform

새 서비스 배포 예시의 설명대로 Terraform을 설정했는지 확인합니다.

구성 파일을 변경합니다.
Terraform 구성을 적용합니다.
```
terraform apply
```
yes를 입력하여 기술된 작업 적용을 확인합니다.
참고: 구성 변경이 필요하지 않으면 새 버전이 생성되지 않습니다.

클라이언트 라이브러리

코드에서 새 버전 배포:

REST API

새 버전을 배포하려면 PATCH HTTP 요청을 Cloud Run Admin API service 엔드포인트로 보냅니다.

예를 들어 다음과 같이 curl을 사용합니다.

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X PATCH \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE

다음과 같이 바꿉니다.

ACCESS_TOKEN을 버전을 배포할 수 있는 IAM 권한이 있는 계정의 유효한 액세스 토큰으로 바꿉니다. 예를 들어 gcloud에 로그인한 경우 gcloud auth print-access-token을 사용하여 액세스 토큰을 검색할 수 있습니다. Cloud Run 컨테이너 인스턴스 내에서 컨테이너 인스턴스 메타데이터 서버를 사용하여 액세스 토큰을 검색할 수 있습니다.
IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
SERVICE를 배포할 서비스의 이름으로 바꿉니다.
REGION을 서비스의 Google Cloud 리전으로 바꿉니다.
PROJECT-ID를 Google Cloud 프로젝트 ID로 바꿉니다.

Cloud Run 위치

Cloud Run은 다음 리전에서 사용할 수 있습니다.

등급 1 가격 적용

asia-east1(타이완)
asia-northeast1(도쿄)
asia-northeast2(오사카)
europe-north1(핀란드) 낮은 CO₂
europe-southwest1(마드리드) 낮은 CO₂
europe-west1(벨기에) 낮은 CO₂
europe-west4(네덜란드) 낮은 CO₂
europe-west8(밀라노)
europe-west9(파리) 낮은 CO₂
me-west1(텔아비브)
us-central1(아이오와) 낮은 CO₂
us-east1(사우스캐롤라이나)
us-east4(북 버지니아)
us-east5(콜럼버스)
us-south1(댈러스) 낮은 CO₂
us-west1(오리건) 낮은 CO₂

등급 2 가격 적용

africa-south1(요하네스버그)
asia-east2(홍콩)
asia-northeast3(대한민국 서울)
asia-southeast1(싱가포르)
asia-southeast2 (자카르타)
asia-south1(인도 뭄바이)
asia-south2(인도 델리)
australia-southeast1(시드니)
australia-southeast2(멜버른)
europe-central2(폴란드 바르샤바)
europe-west10(베를린) 낮은 CO₂
europe-west12(토리노)
europe-west2(영국 런던) 낮은 CO₂
europe-west3(독일 프랑크푸르트) 낮은 CO₂
europe-west6(스위스 취리히) 낮은 CO₂
me-central1(도하)
me-central2(담맘)
northamerica-northeast1(몬트리올) 낮은 CO₂
northamerica-northeast2(토론토) 낮은 CO₂
southamerica-east1(브라질 상파울루) 낮은 CO₂
southamerica-west1(칠레 산티아고) 낮은 CO₂
us-west2(로스앤젤레스)
us-west3(솔트레이크시티)
us-west4(라스베이거스)

Cloud Run 서비스를 이미 만들었다면 Google Cloud 콘솔의 Cloud Run 대시보드에서 리전을 확인할 수 있습니다.

다른 Google Cloud 프로젝트의 이미지 배포

올바른 IAM 권한을 설정한 경우 다른 Google Cloud 프로젝트에서 가져온 컨테이너 이미지를 배포할 수 있습니다.

Google Cloud 콘솔에서 Cloud Run 서비스의 프로젝트를 엽니다.

IAM 페이지로 이동
Google 제공 역할 부여 포함을 선택합니다.
Cloud Run 서비스 에이전트의 이메일을 복사합니다. 여기에는 @serverless-robot-prod.iam.gserviceaccount.com 서픽스가 포함됩니다.
사용하려는 Container Registry를 소유하는 프로젝트를 엽니다.

IAM 페이지로 이동
추가를 클릭하여 새로운 주 구성원을 추가합니다.
새 주 구성원 필드에 앞에서 복사한 서비스 계정의 이메일을 붙여넣습니다.
Container Registry를 사용하는 경우 역할 선택 드롭다운 메뉴에서 스토리지 -> 스토리지 객체 뷰어 역할을 선택합니다. Artifact Registry를 사용하는 경우 Artifact Registry -> Artifact Registry 리더 역할을 선택합니다.
Cloud Run 서비스가 포함된 프로젝트에 컨테이너 이미지를 배포합니다.

참고: 더 강력한 보안을 위해서는 컨테이너 이미지가 포함된 Cloud Storage 버킷 또는 Artifact Registry 저장소에 대한 액세스 권한만 부여합니다.

다른 레지스트리의 이미지 배포

Artifact Registry 또는 Docker Hub에 저장되지 않은 공개 또는 비공개 컨테이너 이미지를 배포하려면 Artifact Registry 원격 저장소를 설정합니다.

Artifact Registry 원격 저장소를 사용하면 다음을 수행할 수 있습니다.

공개 컨테이너 이미지(예: GitHub Container Registry(ghcr.io))를 배포합니다.
인증이 필요한 비공개 저장소의 컨테이너 이미지를 배포합니다(예: JFrog Artifactory 또는 Nexus).

또는 Artifact Registry 원격 저장소를 사용할 수 없는 경우 docker push를 사용하여 컨테이너 이미지를 임시로 가져오고 Artifact Registry에 푸시하여 Cloud Run에 배포할 수 있습니다. 배포 시 Cloud Run이 컨테이너 이미지를 가져오므로 배포 후 Artifact Registry에서 이미지를 삭제할 수 있습니다.

서비스에 여러 컨테이너 배포(사이드카)

In a Cloud Run deployment with sidecars, there is one ingress container that handles all incoming HTTPS requests at the container PORT you specify, and there are one or more sidecar containers. 사이드카는 인그레스 컨테이너 포트에서 수신되는 HTTP 요청을 리슨할 수 없지만 localhost 포트를 사용해서 서로 그리고 인그레스 컨테이너와 통신할 수 있습니다. 사용되는 localhost 포트는 사용 중인 컨테이너에 따라 달라집니다.

다음 다이어그램에서 인그레스 컨테이너는 localhost:5000을 사용하여 사이드카와 통신합니다.

Cloud Run 멀티 컨테이너

인그레스 컨테이너를 포함하여 인스턴스당 최대 10개까지 컨테이너를 배포할 수 있습니다. 다이어그램과 같이 인스턴스 내에 있는 모든 컨테이너는 같은 네트워크 네임스페이스를 공유하며 메모리 내 공유 볼륨을 사용하여 파일을 공유할 수도 있습니다.

1세대 또는 2세대 실행 환경에 여러 컨테이너를 배포할 수 있습니다.

기본적으로 사이드카에는 인스턴스가 요청을 하나 이상 처리할 때만 CPU가 할당됩니다. 측정항목 컬렉션과 같이 사이드가 요청 처리 이외에 CPU를 사용할 수 있어야 하는 경우에는 CPU가 항상 할당되도록 서비스를 구성합니다. 자세한 내용은 CPU 할당(서비스)을 참조하세요.

커스텀 조직 정책을 만들어서 모든 배포에 특정 사이드카가 사용되도록 지정할 수 있습니다.

사용 사례

Cloud Run 서비스의 사이드카 사용 사례에는 다음이 포함됩니다.

애플리케이션 모니터링, 로깅 및 추적
애플리케이션 컨테이너 앞에서 Nginx, Envoy, Apache2를 프록시로 사용
인증 및 승인 필터 추가(예: Open Policy Agent)
Alloy DB 인증 프록시와 같은 아웃바운드 연결 프록시 실행

사이드카 컨테이너로 서비스 배포

Google Cloud 콘솔, Google Cloud CLI, YAML 또는 Terraform을 사용하여 사이드카 여러 개를 Cloud Run 서비스에 배포할 수 있습니다.

선택한 도구 사용에 관한 안내를 보려면 해당 탭을 클릭하세요.

콘솔

Google Cloud 콘솔에서 Cloud Run 페이지로 이동합니다.

Cloud Run으로 이동
- 기존 서비스에 배포하려면 서비스 목록에서 기존 서비스를 찾고 클릭하여 연 다음 새 버전 수정 및 배포를 클릭하여 버전 배포 양식을 표시합니다.
- 컨테이너 배포를 클릭하고 서비스를 선택하여 서비스 만들기 양식을 표시합니다.
새 서비스의 경우 다음을 수행합니다.
1. 배포하려는 인그레스 컨테이너 이미지에 서비스 이름과 URL을 제공합니다.
2. 컨테이너, 볼륨, 네트워킹, 보안을 클릭합니다.
컨테이너 수정 카드에서 필요에 따라 인그레스 컨테이너를 구성합니다.
컨테이너 추가를 클릭하고 인그레스 컨테이너와 함께 추가할 사이드카 컨테이너를 구성합니다. 사이드카가 서비스의 다른 컨테이너에 종속되는 경우 컨테이너 시작 순서 드롭다운 메뉴에 사이드카를 표시합니다. 배포하는 사이드카 컨테이너마다 이 단계를 반복합니다.
모든 트래픽을 새 버전으로 전송하려면 이 버전을 즉시 제공을 선택합니다. 점진적 출시의 경우 해당 체크박스를 선택 취소합니다. 이렇게 하면 트래픽이 새 버전으로 전송되지 않는 배포가 생성됩니다. 배포 후 점진적 출시 안내를 따릅니다.
새 서비스의 경우 만들기를, 기존 서비스의 경우 배포를 클릭한 후 배포가 완료될 때까지 기다립니다.

gcloud

Google Cloud CLI의 container 매개변수는 미리보기 버전입니다.

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
서비스에 컨테이너 여러 개를 배포하려면 다음 명령어를 실행합니다.
```
gcloud run deploy SERVICE \
 --container INGRESS_CONTAINER_NAME \
 --image='INGRESS_IMAGE' \
 --port='CONTAINER_PORT' \
 --container SIDECAR_CONTAINER_NAME \
 --image='SIDECAR_IMAGE'
```
다음과 같이 바꿉니다.
- SERVICE를 배포할 서비스의 이름으로 바꿉니다. 이 매개변수를 완전히 생략할 수 있지만 생략하면 서비스 이름을 입력하라는 메시지가 표시됩니다.
- INGRESS_CONTAINER_NAME을 요청을 수신하는 컨테이너의 이름으로 바꿉니다(예: app).
- INGRESS_IMAGE를 요청을 수신해야 하는 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다.
- CONTAINER_PORT를 인그레스 컨테이너에서 수신 요청을 리슨하는 포트로 바꿉니다. 단일 컨테이너 서비스와 달리 사이드카가 포함된 서비스에는 인그레스 컨테이너에 대한 기본 포트가 없습니다. 인그레스 컨테이너의 컨테이너 포트를 명시적으로 구성해야 하며 포트는 컨테이너 하나에만 노출될 수 있습니다.
- SIDECAR_CONTAINER_NAME을 사이드카 컨테이너 이름으로 바꿉니다(예: sidecar).
- SIDECAR_IMAGE를 사이드카 컨테이너 이미지에 대한 참조로 바꿉니다.
배포 명령어에서 각 컨테이너를 구성하려면 각 컨테이너 구성을 container 매개변수 다음에 제공합니다. 예를 들면 다음과 같습니다.
```
gcloud run deploy SERVICE \
  --container CONTAINER_1_NAME \
  --image='INGRESS_IMAGE' \
  --set-env-vars=KEY=VALUE \
  --port='CONTAINER_PORT' \
  --container SIDECAR_CONTAINER_NAME \
  --image='SIDECAR_IMAGE' \
  --set-env-vars=KEY_N=VALUE_N
```
중요: --container 플래그를 사용할 때 컨테이너 수준 플래그 앞에 모든 비컨테이너 수준 플래그를 지정해야 합니다. 그렇지 않으면 배포 명령어가 실패하고 해당 효과에 대한 오류 메시지가 표시됩니다. 예를 들어 "gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G" 명령어에서 --execution-environment 플래그를 --container 플래그 앞에 전달해야 합니다.
배포가 완료될 때까지 기다립니다. 성공적으로 완료되면 배포된 서비스의 URL이 포함된 성공 메시지가 표시됩니다.

YAML

이 안내에서는 사이드카가 포함된 Cloud Run 서비스의 기본 YAML 파일을 보여줍니다. service.yaml이라는 파일을 만들고 여기에 다음을 추가합니다.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: INGRESS_IMAGE
        ports:
          - containerPort: CONTAINER_PORT
      - image: SIDECAR_IMAGE

다음과 같이 바꿉니다.

SERVICE를 Cloud Run 서비스 이름으로 바꿉니다. 서비스 이름은 49자 이하(영문 기준)여야 합니다.
CONTAINER_PORT를 인그레스 컨테이너에서 수신 요청을 리슨하는 포트로 바꿉니다. 단일 컨테이너 서비스와 달리 사이드카가 포함된 서비스에는 인그레스 컨테이너에 대한 기본 포트가 없습니다. 인그레스 컨테이너의 컨테이너 포트를 명시적으로 구성해야 하며 포트는 컨테이너 하나에만 노출될 수 있습니다.
INGRESS_IMAGE를 요청을 수신해야 하는 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다.
SIDECAR_IMAGE를 사이드카 컨테이너 이미지에 대한 참조로 바꿉니다. YAML의 containers 배열에 요소를 더 추가하여 여러 사이드카를 지정할 수 있습니다.

인그레스 및 사이드카 컨테이너를 포함하도록 YAML을 업데이트한 후 다음 명령어를 사용해서 Cloud Run에 배포합니다.

gcloud run services replace service.yaml

Terraform

Terraform 구성을 적용하거나 삭제하는 방법은 기본 Terraform 명령어를 참조하세요.

Terraform 구성에서 다음을 google_cloud_run_v2_service 리소스에 추가합니다.

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  ingress = "INGRESS_TRAFFIC_ALL"
  template {
    containers {
      name = "INGRESS_CONTAINER_NAME"
      ports {
        container_port = CONTAINER_PORT
      }
      image = "INGRESS_IMAGE"
      depends_on = ["SIDECAR_CONTAINER_NAME"]
    }
    containers {
      name = "SIDECAR_CONTAINER_NAME"
      image = "SIDECAR_IMAGE"
      }
    }
  }

CONTAINER_PORT는 인그레스 컨테이너에서 수신 요청을 리슨하는 포트를 나타냅니다. 단일 컨테이너 서비스와 달리 사이드카가 포함된 서비스에는 인그레스 컨테이너에 대한 기본 포트가 없습니다. 인그레스 컨테이너의 컨테이너 포트를 명시적으로 구성해야 하며 포트는 컨테이너 하나에만 노출될 수 있습니다.

사이드카 포함 배포에서 사용 가능한 기능

배포에서 다른 컨테이너보다 먼저 일부 컨테이너를 시작해야 하는 종속 항목이 있으면 여러 컨테이너가 포함된 배포 내에서 컨테이너 시작 순서를 지정할 수 있습니다.

다른 컨테이너에 종속된 컨테이너가 있으면 배포에서 상태 점검을 사용해야 합니다. 상태 점검을 사용하면 Cloud Run은 컨테이너 시작 순서를 따르고 각 컨테이너의 상태를 검사하여 Cloud Run이 순서대로 다음 컨테이너를 시작하기 전에 각 컨테이너가 성공적으로 통과했는지 확인합니다. 상태 점검을 사용하지 않으면 종속된 컨테이너가 실행되고 있지 않더라도 정상 상태의 컨테이너가 시작됩니다.

단일 인스턴스 내의 여러 컨테이너는 생성된 마운트 지점을 사용하여 각 컨테이너에 액세스할 수 있는 공유된 인메모리 볼륨에 액세스할 수 있습니다.

다음 단계

새 서비스를 배포한 후에는 다음을 수행할 수 있습니다.

Cloud Build 트리거를 사용하여 Cloud Run 서비스의 빌드 및 배포를 자동화할 수 있습니다.

지속적 배포 설정

Cloud Deploy를 사용하여 지속적 배포 파이프라인을 설정해 Cloud Run 서비스를 여러 환경에 배포할 수도 있습니다.

Cloud Deploy를 사용하여 Cloud Run에 앱 배포