Compose를 사용하여 서비스 배포

이 페이지에서는 Compose 사양을 기반으로 하는 파일 을 사용하여 Cloud Run에 서비스를 배포하는 방법을 설명합니다.

다음과 같은 방법으로 Compose 파일을 사용하여 Cloud Run에 배포할 수 있습니다.

사전 빌드된 컨테이너 이미지에서
소스 코드에서

Compose를 사용하여 Cloud Run에 배포하는 것은 개발에 적합하며 로컬 환경에서 클라우드 환경으로의 전환을 간소화합니다. 이를 통해 로컬 애플리케이션과 배포된 애플리케이션 모두에 일관된 구성 형식을 유지할 수 있습니다.

코드형 인프라 (IaC) 환경에서 프로덕션 환경을 관리하려면 Terraform을 사용하는 것이 좋습니다.

제한사항

Compose 배포는 여러 컨테이너가 있는 단일 Cloud Run 서비스를 배포합니다.
Compose 배포는 지원되는 Cloud Run 기능의 하위 집합만 변환합니다.
Compose를 사용하여 만든 서비스는 기본적으로 최대 인스턴스 1개로 설정됩니다.
배포를 간소화하지만 Cloud Run Compose 배포는 프로덕션 환경을 위한 포괄적인 코드형 인프라 전략을 대체하지 않습니다.

Compose를 사용하여 컨테이너 이미지에서 서비스 배포

compose.yaml 파일에서 서비스를 정의하고 기존 컨테이너 이미지에서 배포합니다. 자세한 내용은 컨테이너 이미지 배포를 참조하세요.

예: 단일 서비스 애플리케이션

다음 예는 사전 빌드된 컨테이너 이미지를 사용하는 웹 서비스의 compose.yaml 파일을 보여줍니다.

services:
  web:
    image: us-docker.pkg.dev/cloudrun/container/hello
    ports:
      - "8080:8080"

예: Nginx, Flask, MongoDB가 있는 다중 컨테이너 애플리케이션

다음 예는 Nginx 프록시, Flask 백엔드, MongoDB 데이터베이스가 있는 애플리케이션의 compose.yaml 파일을 보여줍니다.

이 예시를 배포하려면 다음 프로젝트 구조가 필요합니다.

compose.yaml: 서비스를 정의하는 Compose 파일입니다.
nginx/nginx.conf: Nginx 프록시의 구성입니다.
flask/: Flask 애플리케이션 코드 (server.py, Dockerfile, requirements.txt)가 포함된 디렉터리입니다.

services:
  web:
    image: nginx
    volumes:
      - ./nginx/nginx.conf:/tmp/nginx.conf
    environment:
      - FLASK_SERVER_ADDR=backend:9091
    command: /bin/bash -c "envsubst < /tmp/nginx.conf > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"
      - 80:80
    x-google-cloudrun:
      ingress-container: true
    depends_on:
      - backend

  backend:
    build:
      context: flask
      target: builder
    stop_signal: SIGINT
    environment:
      - FLASK_SERVER_PORT=9091
    volumes:
      - ./flask:/src
    depends_on:
      -  mongo
    ports:
      - 9091:9091

  mongo:
    image: mongo
    ports:
      - 27017:27017

서비스 배포

서비스를 배포하려면 gcloud run compose up 명령어를 실행합니다.
```
gcloud run compose up compose.yaml
```
필요한 구성요소를 설치하거나 API를 사용 설정하라는 메시지가 표시되면 y로 응답합니다.
선택사항: 서비스에 대한 인증되지 않은 액세스를 허용하려면 서비스를 공개로 설정합니다.

배포 후 Cloud Run 서비스 URL이 표시됩니다. 이 URL을 복사하여 브라우저에 붙여넣어 실행 중인 컨테이너를 확인합니다. 콘솔에서 기본 인증을 사용 중지할 수 있습니다. Google Cloud

Compose를 사용하여 소스에서 배포

compose.yaml 파일에서 서비스를 정의하고 소스 코드에서 빌드하여 배포합니다. 자세한 내용은 소스 코드에서 서비스 배포를 참조하세요.

예: 단일 서비스 애플리케이션

다음 예는 현재 디렉터리의 소스에서 빌드되는 웹 서비스의 compose.yaml 파일을 보여줍니다.

services:
  web:
    build: .
    ports:
      - "8080:8080"

서비스 배포

프로젝트 디렉터리에서 서비스 정의가 포함된 compose.yaml 파일을 만듭니다.
1. 서비스를 배포하려면 gcloud run compose up 명령어를 실행합니다.
```
gcloud run compose up compose.yaml
```
2. 필요한 구성요소를 설치하거나 API를 사용 설정하라는 메시지가 표시되면 y로 응답합니다.
3. 선택사항: 서비스에 대한 인증되지 않은 액세스를 허용하려면 서비스를 공개로 설정합니다.
배포 후 Cloud Run 서비스 URL이 표시됩니다. 이 URL을 복사하여 브라우저에 붙여넣어 실행 중인 컨테이너를 확인합니다. 콘솔에서 기본 인증을 사용 중지할 수 있습니다. Google Cloud

강제로 다시 빌드

기본적으로 Cloud Run Compose 배포는 마지막 빌드 이후 소스 코드가 변경되지 않은 경우 빌드 프로세스를 건너뜁니다. 서비스를 강제로 다시 빌드하려면 build 구성으로 정의된 서비스를 강제로 다시 빌드하려면 다음과 같이 --build 플래그를 사용합니다.

gcloud run compose up compose.yaml --build

이는 원격 저장소, 이미지 또는 다이제스트가 삭제되었지만 로컬 소스 코드는 동일하게 유지되는 경우에 특히 유용합니다. --build 및 --no-build 플래그는 상호 배타적입니다.

지원되는 기능

compose.yaml 파일을 사용하여 배포하면 Cloud Run에서 Compose 파일에 정의된 대로 기타 Google Cloud 리소스를 자동으로 프로비저닝할 수 있습니다. 리소스가 필요한 경우 Cloud Run에서 리소스를 만들기 전에 동의를 요청합니다.

Cloud Run은 다음과 같은 Compose 기능의 하위 집합을 지원합니다.

Compose 필드	Cloud Run 매핑 및 설명
`services`	서비스는 배포된 Cloud Run 서비스의 개별 컨테이너에 매핑됩니다.
`volumes`	일부 지원됨. `bind`, `volume`, `tmpfs` 마운트를 Cloud Run에 상응하는 항목으로 변환합니다.
`secrets`	지원됨. Secret Manager 사용
`configs`	지원됨. Cloud Storage 사용
`build`	지원됨. 빌드 컨텍스트를 사용하여 컨테이너를 빌드하고 Artifact Registry의 `cloud-run-source-deploy` 저장소에 태그를 지정하고 푸시합니다. 마지막 빌드 이후 소스 코드가 변경되지 않은 경우에도 `--build` 플래그를 사용하여 강제로 다시 빌드합니다.
`image`	지원되는 레지스트리에서 사전 빌드된 컨테이너 이미지를 배포합니다. 사전 빌드된 이미지가 있는 경우 사용합니다. Docker Hub 및 Artifact Registry 이미지만 지원합니다. 커스텀 이미지의 경우 Artifact Registry에 이미지를 푸시하고 사용할 수 있습니다.
`ports`	인그레스 컨테이너를 결정하는 포트 매핑 목록(예: `8080:8080`)입니다.
`expose`	종속 서비스가 통신에 사용할 수 있는 포트를 갖도록 하기 위해 노출은 하지만 게시하지 않는 포트 목록(예: `3000`)입니다.
`depends_on`	컨테이너 시작 순서를 정의합니다. 이렇게 하면 다른 컨테이너가 통신할 수 있도록 `run-compose`에 나열된 모든 서비스에 `ports` 또는 `expose`로 정의된 포트가 있습니다.
`cpus`	다음 로직에 따라 리소스를 자동으로 할당하여 Cloud Run CPU 및 메모리 한도를 설정하는 데 사용되는 힌트입니다. `<= 2 CPU: 1Gi Memory` `<= 4 CPU: 2Gi Memory` `> 4 CPU: 4Gi Memory`
`container_name`	종속 항목 확인을 위해 컨테이너의 이름을 설정합니다. 지정하지 않으면 기본적으로 서비스 이름으로 설정됩니다.
`environment`	환경 변수를 Cloud Run의 해당 컨테이너에 전달합니다.
`command`	Cloud Run의 `args` 속성에 매핑하여 컨테이너에서 선언한 컨테이너의 기본 명령어를 재정의합니다(예: Dockerfile의 `CMD` 명령어).
`entrypoint`	지원됨.
`env_file`	지원됨.
`x-google-cloudrun:ingress-container`	(확장 프로그램) 이 Google별 확장 프로그램을 서비스에 추가하고 `true`로 설정하여 모든 외부 트래픽을 수신하는 인그레스 컨테이너로 표시합니다.
`x-google-cloudrun:volume-type: in-memory`	(확장 프로그램) 이 Google별 확장 프로그램을 볼륨에 추가하고 Cloud Storage에서 지원하는 기본 볼륨 대신 `in-memory`로 설정합니다.

Secret Manager에 매핑된 보안 비밀

compose.yaml 파일에서 secrets를 정의하는 경우 gcloud CLI는 이 데이터를 저장하기 위해 Secret Manager 보안 비밀을 프로비저닝합니다.

Cloud Storage에 매핑된 볼륨 및 구성

compose.yaml 파일에서 최상위 volumes 또는 configs를 정의하는 경우 gcloud CLI는 이 데이터를 관리하기 위해 Cloud Storage 버킷을 프로비저닝합니다. 볼륨과 구성을 구분하는 폴더를 사용하여 배포당 단일 버킷이 생성됩니다.

명명된 볼륨: 볼륨 이름에 해당하는 빈 폴더가 버킷에 생성됩니다.
바인드 마운트: 바인드 마운트의 경우 Cloud Run은 배포 전에 로컬 소스 디렉터리의 콘텐츠를 버킷의 폴더에 업로드합니다.
구성: file: 소스로 정의된 각 구성에 대해 Cloud Run 은 로컬 파일의 콘텐츠를 버킷의 폴더에 업로드합니다.

필요한 역할

배포 중에 Cloud Run은 프로비저닝된 리소스에 액세스하는 데 필요한 역할을 배포된 서비스의 서비스 ID에 자동으로 부여합니다.

Cloud Storage 버킷: roles/storage.objectUser
Secret Manager 보안 비밀: roles/secretmanager.secretAccessor

동일한 인스턴스의 컨테이너 간 통신

Cloud Run은 각 컨테이너의 /etc/hosts 파일에 항목을 추가합니다. 이 항목은 compose.yaml 파일의 서비스 이름을 내부 IP 주소에 매핑하므로 서비스가 서비스 이름을 사용하여 서로 통신할 수 있습니다.

Compose를 사용하여 서비스 배포 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

제한사항

Compose를 사용하여 컨테이너 이미지에서 서비스 배포

예: 단일 서비스 애플리케이션

예: Nginx, Flask, MongoDB가 있는 다중 컨테이너 애플리케이션

서비스 배포

Compose를 사용하여 소스에서 배포

예: 단일 서비스 애플리케이션

서비스 배포

강제로 다시 빌드

지원되는 기능

Secret Manager에 매핑된 보안 비밀

Cloud Storage에 매핑된 볼륨 및 구성

필요한 역할

동일한 인스턴스의 컨테이너 간 통신

다음 단계

Compose를 사용하여 서비스 배포