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

동일한 코드베이스에서 여러 환경을 배포하는 것이 일반적이며 각 환경의 구성은 약간 다릅니다. 예를 들어 스테이징 환경에 CPU와 RAM을 적게 할당하거나 프로덕션 환경에서 요청을 처리할 수 있도록 최소 1개의 인스턴스를 활성 상태로 유지할 수 있습니다. 사용하려는 환경과 리소스에 따라 다른 환경 변수와 비밀을 지정할 수도 있습니다.

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

기본 요건

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

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

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

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

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

1단계: 환경 이름 설정

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

백엔드의 환경 이름을 설정하려면 다음 단계를 따르세요.

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

백엔드에 대해 App Hosting 출시가 트리거되면 (git 푸시 또는 콘솔을 통해 수동으로) 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.firebasestorage.app
    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.firebasestorage.app
    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을 계속 사용할 수 있습니다.

다음 단계