Cloud Run에 배포

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

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

시작하기 전에

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

배포 시 필요한 권한

다음 역할 중 하나가 있어야 합니다.

• 소유자
• 편집자
• Cloud Run 관리자 및 서비스 계정 사용자 역할 모두
• 이 특정 권한 목록이 포함된 모든 커스텀 역할

지원되는 Container Registry 및 이미지

Artifact Registry, Container Registry(지원 중단됨) 또는 Docker Hub에 저장된 컨테이너 이미지를 사용할 수 있습니다. Artifact Registry를 사용하는 것이 좋습니다.

다음 유형의 컨테이너 이미지만 사용할 수 있습니다.

• 작업이나 서비스를 만드는 프로젝트와 동일한 프로젝트에 저장된 컨테이너 이미지
• 다른 Google Cloud 프로젝트에서 가져온 컨테이너 이미지(올바른 IAM 권한이 설정된 경우)
• Artifact Registry, Container Registry 또는 Docker Hub의 공개 컨테이너 이미지

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

다른 유형의 Container Registry에 컨테이너 이미지를 저장하는 경우 지원되지 않는 레지스트리에서 이미지 배포의 안내를 따릅니다.

새 서비스 배포

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

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

Google Cloud 콘솔, gcloud 명령줄 또는 YAML 구성 파일을 사용하여 컨테이너를 배포할 수 있습니다.

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

콘솔

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

1. Cloud Run으로 이동

2. 서비스 만들기를 클릭하여 서비스 만들기 양식을 표시합니다.

   1. 양식에서 배포 옵션을 선택합니다.

      1. 컨테이너를 수동으로 배포하려면 기존 컨테이너 이미지에서 하나의 버전 배포를 선택하고 컨테이너 이미지를 지정합니다.

      2. 지속적 배포를 자동화하려면 소스 저장소에서 지속적으로 새 버전 배포를 선택하고 지속적 배포 안내를 따릅니다.

   2. 필요한 서비스 이름을 입력합니다. 서비스 이름은 49자(영문 기준) 이하여야 하며 리전과 프로젝트별로 고유해야 합니다. 서비스 이름은 나중에 변경될 수 있으며 공개적으로 표시됩니다.

   3. 서비스를 배치할 리전을 선택합니다. 리전 선택기는 가격 등급, 도메인 매핑의 가용성을 나타내고, 탄소 배출량이 가장 낮은 리전을 강조표시합니다.

   4. 필요에 따라 CPU 할당 및 가격 책정을 설정합니다.

   5. 자동 확장에서 최소 및 최대 인스턴스를 지정합니다.

   6. 필요에 따라 양식에서 인그레스 설정을 지정합니다.

   7. 인증 아래에서 다음을 구성합니다.

      • 공개 API 또는 웹 사이트를 사용하는 경우 인증되지 않은 호출 허용을 선택합니다. 이를 선택하면 IAM 호출자 역할이 특수 식별자 allUser에 할당됩니다. 서비스를 만든 후 나중에 IAM을 사용하여 이 설정을 수정할 수 있습니다.
      • 보안 서비스를 인증으로 보호하려면 인증 필요를 선택합니다.

3. 컨테이너, 볼륨, 네트워킹, 보안을 클릭하여 해당 탭에서 다른 선택적 설정을 지정합니다.

   • 동시 실행
   • 컨테이너 구성
   • CPU 한도
   • 메모리 한도
   • 요청 제한 시간
   • 보안 비밀
   • 환경 변수
   • 실행 환경
   • HTTP/2
   • 라벨
   • 서비스 계정
   • Cloud SQL 연결
   • VPC 연결

4. 서비스 구성을 마쳤으면 만들기를 클릭하여 이미지를 Cloud Run에 배포하고 배포가 완료되도록 기다립니다.

5. 배포된 서비스의 고유한 공개 버전 엔드포인트를 열려면 표시된 URL을 클릭합니다.

명령줄

1. Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

   Cloud Shell 활성화

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

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

   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를 사용하여 배포할 수 있습니다.

1. 다음 콘텐츠로 새 service.yaml 파일을 만듭니다.

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: SERVICE
   spec:
     template:
       spec:
         containers:
         - image: IMAGE

   다음과 같이 바꿉니다.

   • SERVICE를 Cloud Run 서비스 이름으로 바꿉니다. 서비스 이름은 49자(영문 기준) 이하여야 하며 리전과 프로젝트별로 고유해야 합니다.
   • IMAGE를 컨테이너 이미지의 URL로 바꿉니다.

   또한 환경 변수 또는 메모리 제한과 같은 추가 구성을 지정할 수 있습니다.

2. 다음 명령어를 사용하여 새 서비스를 배포합니다.

   gcloud run services replace service.yaml

3. 선택적으로 서비스에 대한 인증되지 않은 액세스를 허용하려면 서비스를 공개로 설정합니다.

Cloud Code

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

Terraform

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

1. 다음 내용으로 새 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 스탠자를 삭제합니다.

2. Terraform을 초기화합니다.

   terraform init

3. Terraform 구성을 적용합니다.

   terraform apply

   yes를 입력하여 기술된 작업 적용을 확인합니다.

클라이언트 라이브러리

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

• Go
• Java
• Node.js
• Python
• Ruby
• PHP
• .NET

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(마드리드)
• europe-west1(벨기에) 낮은 CO₂
• europe-west4(네덜란드)
• europe-west8(밀라노)
• europe-west9(파리) 낮은 CO₂
• me-west1(텔아비브)
• us-central1(아이오와) 낮은 CO₂
• us-east1(사우스캐롤라이나)
• us-east4(북 버지니아)
• us-east5(콜럼버스)
• us-south1(댈러스)
• 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(베를린)
• 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 구성 파일을 사용하여 새 버전을 배포할 수 있습니다.

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

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

콘솔

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

1. Cloud Run으로 이동

2. 서비스 목록에서 업데이트할 서비스를 찾고 클릭하여 해당 서비스의 세부정보를 엽니다.

3. 새 버전 수정 및 배포를 클릭하여 버전 배포 양식을 표시합니다.

   1. 필요한 경우 배포하려는 새 컨테이너 이미지 URL을 제공합니다.

   2. 필요에 따라 컨테이너를 구성합니다.

   3. 필요에 따라 CPU 할당 및 가격 책정을 설정합니다.

   4. 용량에서 메모리 한도와 CPU 한도를 지정합니다.

   5. 필요에 따라 요청 제한 시간과 동시 실행을 지정합니다.

   6. 필요에 따라 실행 환경을 지정합니다.

   7. 자동 확장에서 최소 및 최대 인스턴스를 지정합니다.

   8. 필요에 따라 다른 탭을 사용하여 다음을 선택적으로 구성합니다.

      • 보안 비밀
      • 환경 변수
      • HTTP/2
      • 라벨
      • 서비스 계정
      • Cloud SQL 연결
      • VPC 연결

4. 모든 트래픽을 새 버전으로 전송하려면 이 버전을 즉시 제공을 선택합니다. 새 버전을 점진적으로 출시하려면 해당 체크박스를 선택 취소합니다. 이렇게 하면 트래픽이 새 버전으로 전송되지 않는 배포가 생성됩니다. 배포 후 점진적 출시 안내를 따릅니다.

5. 배포를 클릭하고 배포가 완료될 때까지 기다립니다.

명령줄

1. Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

   Cloud Shell 활성화

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

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

   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 파일에 지정된 구성으로 바꿉니다. 따라서 YAML을 사용하여 버전을 변경할 때는 YAML을 사용할 때 덮어쓰지 않도록 Google Cloud 콘솔 또는 gcloud CLI를 사용해서 구성 변경을 수행하지 않도록 해야 합니다.

기존 서비스 구성을 다운로드하거나 확인해야 할 경우에는 다음 명령어를 사용해서 결과를 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을 설정했는지 확인합니다.

1. 구성 파일을 변경합니다.

2. Terraform 구성을 적용합니다.

   terraform apply

   yes를 입력하여 기술된 작업 적용을 확인합니다.

   참고: 구성 변경이 필요하지 않으면 새 버전이 생성되지 않습니다.

클라이언트 라이브러리

코드에서 새 버전 배포:

• Go
• Java
• Node.js
• Python
• Ruby
• PHP
• .NET

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은 리전을 기반으로 합니다. 즉, 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(마드리드)
• europe-west1(벨기에) 낮은 CO₂
• europe-west4(네덜란드)
• europe-west8(밀라노)
• europe-west9(파리) 낮은 CO₂
• me-west1(텔아비브)
• us-central1(아이오와) 낮은 CO₂
• us-east1(사우스캐롤라이나)
• us-east4(북 버지니아)
• us-east5(콜럼버스)
• us-south1(댈러스)
• 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(베를린)
• 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 프로젝트에서 가져온 컨테이너 이미지를 배포할 수 있습니다.

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

   IAM 페이지로 이동

2. Google 제공 역할 부여 포함을 선택합니다.

3. Cloud Run 서비스 에이전트의 이메일을 복사합니다. 여기에는 @serverless-robot-prod.iam.gserviceaccount.com 서픽스가 포함됩니다.

4. 사용하려는 Container Registry를 소유하는 프로젝트를 엽니다.

   IAM 페이지로 이동

5. 추가를 클릭하여 새로운 주 구성원을 추가합니다.

6. 새 주 구성원 필드에 앞에서 복사한 서비스 계정의 이메일을 붙여넣습니다.

7. Container Registry를 사용하는 경우 역할 선택 드롭다운 메뉴에서 스토리지 -> 스토리지 객체 뷰어 역할을 선택합니다. Artifact Registry를 사용하는 경우 Artifact Registry -> Artifact Registry 리더 역할을 선택합니다.

8. Cloud Run 서비스가 포함된 프로젝트에 컨테이너 이미지를 배포합니다.

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

지원되지 않는 레지스트리에서 이미지 배포

컨테이너 이미지를 지원되지 않는 공개 또는 비공개 컨테이너 레지스트리에 저장하는 경우 docker push를 사용하여 임시로 Artifact Registry에 푸시하여 Cloud Run에 배포합니다. 배포 시 Cloud Run이 컨테이너 이미지를 가져오므로 배포 후 Artifact Registry에서 이미지를 삭제할 수 있습니다.

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

사이드카가 있는 Cloud Run 배포에는 지정한 컨테이너 배포에서 모든 수신되는 HTTPS 요청을 처리하는 하나의 인그레스 컨테이너와 하나 이상의 사이드카 컨테이너가 있습니다. 사이드카는 인그레스 컨테이너 포트에서 수신되는 HTTP 요청을 리슨할 수 없지만 localhost 포트를 사용해서 서로 그리고 인그레스 컨테이너와 통신할 수 있습니다. 사용되는 localhost 포트는 사용 중인 컨테이너에 따라 달라집니다.

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

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

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

사용 사례

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

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

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

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

콘솔

1. Cloud Run으로 이동

   • 기존 서비스에 배포하려면 서비스 목록에서 기존 서비스를 찾고 클릭하여 연 다음 새 버전 수정 및 배포를 클릭하여 버전 배포 양식을 표시합니다.
   • 새 서비스에 배포하려면 서비스 만들기를 클릭합니다.

2. 새 서비스의 경우 다음을 수행합니다.

   1. 배포하려는 인그레스 컨테이너 이미지에 서비스 이름과 URL을 제공합니다.
   2. 컨테이너, 볼륨, 네트워킹, 보안을 클릭합니다.

3. 컨테이너 수정 카드에서 필요에 따라 인그레스 컨테이너를 구성합니다.

4. 컨테이너 추가를 클릭하고 인그레스 컨테이너와 함께 추가할 사이드카 컨테이너를 구성합니다. 사이드카가 서비스의 다른 컨테이너에 종속되는 경우 컨테이너 시작 순서 드롭다운 메뉴에 사이드카를 표시합니다. 배포하는 사이드카 컨테이너마다 이 단계를 반복합니다.

5. 모든 트래픽을 새 버전으로 전송하려면 이 버전을 즉시 제공을 선택합니다. 점진적 출시의 경우 해당 체크박스를 선택 취소합니다. 이렇게 하면 트래픽이 새 버전으로 전송되지 않는 배포가 생성됩니다. 배포 후 점진적 출시 안내를 따릅니다.

6. 새 서비스의 경우 만들기를, 기존 서비스의 경우 배포를 클릭한 후 배포가 완료될 때까지 기다립니다.

명령줄

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

1. Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

   Cloud Shell 활성화

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

2. 서비스에 컨테이너 여러 개를 배포하려면 다음 명령어를 실행합니다.

   gcloud beta 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)로 바꿉니다.
   • SIDECAR_CONTAINER_NAME을 사이드카 컨테이너 이름(예: sidecar)으로 바꿉니다.
   • SIDECAR_IMAGE를 사이드카 컨테이너 이미지에 대한 참조로 바꿉니다.

   배포 명령어에서 각 컨테이너를 구성하려면 각 컨테이너 구성을 container 매개변수 다음에 제공합니다. 예를 들면 다음과 같습니다.

   gcloud beta 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 플래그보다 먼저 전달해야 합니다.

3. 배포가 완료될 때까지 기다립니다. 성공적으로 완료되면 배포된 서비스의 URL이 포함된 성공 메시지가 표시됩니다.

YAML

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

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
  name: SERVICE_NAME
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

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

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

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

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

다음 단계

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

• 점진적 출시, 버전 롤백, 트래픽 마이그레이션
• 서비스 로그 보기
• 서비스 성능 모니터링
• 메모리 제한 설정
• 환경 변수 설정
• 서비스 동시 실행 변경
• 서비스 관리
• 서비스 버전 관리
• Cloud Run OpenTelemetry 사이드카 예시
• Binary Authorization으로 신뢰할 수 있는 이미지만 배포(미리보기)

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

• 지속적 배포 설정

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

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