코드베이스에서 여러 환경 배포

동일한 코드베이스에서 배포된 여러 환경이 각각 약간 다른 구성을 갖는 경우가 일반적입니다. 예를 들어 스테이징 환경에 CPU와 RAM을 더 적게 할당하거나 프로덕션 환경에서 인스턴스를 1개 이상 활성 상태로 유지하여 요청을 처리할 준비를 갖추도록 할 수 있습니다. 사용할 환경 및 리소스에 따라 다른 환경 변수와 보안 비밀을 지정할 수도 있습니다.

이 가이드에서는 프로덕션 및 스테이징 환경을 각각 별도의 Firebase 프로젝트에 배포하는 방법을 설명합니다. 동일한 원칙에 따라 다른 종류의 환경에 배포할 수 있습니다. 환경에 관해 자세히 알아보려면 환경 개요 및 Firebase 프로젝트 설정을 위한 일반적인 권장사항을 확인하세요.

기본 요건

  • 애플리케이션 코드는 이미 GitHub에 저장되어 있습니다.
  • 환경마다 고유한 프로젝트를 이미 만들었습니다(예: my-production-firebase-project 및 my-staging-firebase-project). 프로덕션 Firebase 프로젝트에 'production' 환경 유형으로 태그를 지정해야 합니다.
  • 각 프로젝트에서 App Hosting 백엔드를 만들었으며, 배포하려는 GitHub 브랜치 (예: main)를 실시간 브랜치로 설정했습니다. 자세한 내용은 App Hosting 시작하기를 참고하세요.

0단계: apphosting.yaml에서 기본 구성 만들기

App Hosting는 apphosting.yaml라는 구성 파일을 지원하여 앱의 런타임 설정 (CPU, 동시 실행, 메모리 제한 등) 및 환경 변수를 관리합니다. 또한 Cloud Secret Manager로 관리되는 보안 비밀에 대한 참조를 지원하므로 소스 제어에 안전하게 체크인할 수 있습니다. 자세한 내용은 백엔드 구성을 참고하세요.

시작하려면 앱의 루트 디렉터리에 apphosting.yaml 파일을 만듭니다. 환경별 구성 파일을 찾을 수 없는 경우에 사용되는 대체 구성 파일입니다. apphosting.yaml에 저장된 값은 모든 환경에서 안전하게 사용할 수 있는 기본값이어야 합니다.

다음 섹션에서는 특정 환경에서 apphosting.yaml의 기본값을 재정의하는 방법을 설명합니다. 이 흐름 예시에서는 스테이징 환경을 만듭니다.

1단계: 환경 이름 설정

각 App Hosting 백엔드에는 환경 이름 설정이 있습니다. 이 필드는 백엔드를 환경별 구성 파일에 매핑하는 데 사용되며 언제든지 변경할 수 있습니다. 백엔드당 환경 이름을 하나만 설정할 수 있습니다.

백엔드의 환경 이름을 설정하려면

  1. Firebase Console에서 스테이징 프로젝트 (이 예에서는 my-staging-firebase-project)를 선택합니다.
  2. 왼쪽 탐색 메뉴에서 App Hosting를 선택합니다.
  3. 선택한 백엔드에서 대시보드 보기를 클릭합니다.
  4. 설정 탭에서 배포를 선택합니다.
  5. 환경 이름에 환경 이름을 입력합니다. 환경 이름은 원하는 대로 지정할 수 있습니다. 이 예시에서는 스테이징입니다.
  6. 저장을 클릭합니다.

백엔드에 대해 App Hosting 출시가 트리거되면 (git push 또는 Console을 통해 수동으로) App Hosting는 apphosting.yaml로 대체하기 전에 apphosting.ENVIRONMENT_NAME.yaml 파일을 확인합니다.

2단계: 환경별 apphosting.yaml 파일 만들기

환경별 구성의 경우 환경별 재정의를 지정하려면 이름이 apphosting.ENVIRONMENT_NAME.yaml인 파일을 만듭니다. 이 파일은 기본 apphosting.yaml과 형식이 동일하며 apphosting.yaml와 함께 앱의 루트 디렉터리에 있어야 합니다.

빌드 시 App Hosting는 이러한 두 파일을 병합하며, 기본 apphosting.yaml 파일보다 환경별 YAML 파일의 값에 우선순위를 둡니다.

이 예에서는 앱의 루트 디렉터리에 apphosting.staging.yaml라는 파일을 만듭니다.


runConfig:
  cpu: 1
  memoryMiB: 512
  concurrency: 5

env:
  -   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

  -   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

다음과 같이 이미 apphosting.yaml가 있다고 가정해 보겠습니다.

runConfig:
  cpu: 3
  memoryMiB: 1024
  maxInstances: 4
  minInstances: 0
  concurrency: 100

env:
  -   variable: API_URL
    value: api.service.com
    availability:
      -   BUILD
      -   RUNTIME

  -   variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
      -   RUNTIME

  -   variable: API_KEY
    secret: secretIDforAPI

Cloud Build 로그에서 검사할 수 있는 최종 병합 출력은 다음과 같습니다.

runConfig:
  cpu: 1
  memoryMiB: 512
  maxInstances: 4
  minInstances: 0
  concurrency: 5

env:
  -   variable: API_URL
    value: api.staging.service.com
    availability:
      -   BUILD

  -   variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
      -   RUNTIME

  -   variable: API_KEY
    secret: secretIDforAPI

  -   variable: DATABASE_URL
    secret: secretStagingDatabaseURL

CPU와 같은 특정 runConfig 값과 겹치는 환경 변수도 덮어쓰기되었습니다.

3단계: 코드베이스 배포

환경별 apphosting.ENVIRONMENT_NAME.yaml 파일 수정을 완료하면 파일을 GitHub에 푸시합니다.

$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push

이 환경 이름으로 태그된 모든 백엔드는 해당 YAML 파일에 지정한 특정 재정의 값을 사용하고 값을 찾을 수 없는 경우 apphosting.yaml로 대체됩니다. 연결된 환경 이름이 없는 백엔드의 경우 apphosting.yaml을 계속 사용할 수 있습니다.

다음 단계