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

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

이 가이드에서는 프로덕션 및 스테이징 환경을 각각 배포하는 방법을 설명합니다. 만들 수 있습니다 동일한 원칙에 따라 다른 종류의 환경이 있습니다. 환경에 대해 자세히 알아보려면 개요: 환경 및 일반 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, 동시 실행, 메모리 한도 등) 및 환경 변수입니다. 또한 Google Cloud로 관리되는 보안 비밀에 대한 Cloud Secret Manager는 소스 제어에 안전하게 체크인할 수 있습니다. 자세한 내용은 자세한 내용은 백엔드를 사용합니다.

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

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

1단계: 환경 이름 설정

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

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

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

백엔드 (git에서 또는 git에서)에 대해 App Hosting 출시가 트리거될 때 푸시하거나 콘솔을 통해 수동으로) App Hosting는 다음 날짜 이전에 파일 apphosting.ENVIRONMENT_NAME.yaml개 apphosting.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

이 환경 이름으로 태그가 지정된 모든 백엔드가 특정 재정의를 사용합니다. 기존 값으로 돌아가 apphosting.yaml: 값을 찾을 수 없는 경우 연결된 애플리케이션이 없는 백엔드의 경우 Apphosting.yaml을 계속 사용할 수 있습니다.

다음 단계