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

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

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

기본 요건

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

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

App Hosting은 앱의 런타임 설정 (CPU, 동시 실행, 메모리 한도 등) 및 환경 변수를 관리하기 위해 apphosting.yaml이라는 구성 파일을 지원합니다. 또한 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 또는 콘솔을 통해 수동으로) 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을 계속 사용할 수 있습니다.

다음 단계