이 페이지는 Cloud Translation API를 통해 번역되었습니다.

App Hosting 백엔드 구성 및 관리

App Hosting은 사용 편의성과 낮은 유지관리 비용, 대부분의 사용 사례에 최적화된 기본 설정으로 사용합니다. 이와 동시에 App Hosting은 백엔드 관리 및 구성을 위한 도구를 제공합니다. 선택하세요. 이 가이드에서는 이러한 도구와 프로세스에 대해 설명합니다.

백엔드 구성

환경 변수 또는 런타임 설정과 같은 고급 구성용 동시 실행, CPU, 메모리 제한과 같은 주요 문제를 해결하려면 apphosting.yaml 파일을 찾습니다. 이 파일 또한 관리형 보안 비밀에 대한 참조를 지원합니다 Cloud Secret Manager와 함께 사용하면 소스 제어에 안전하게 체크인할 수 있습니다.

다음은 설정이 포함된 일반적인 apphosting.yaml 파일의 모습입니다. 백엔드의 Cloud Run 서비스, 일부 환경 변수, Cloud Secret Manager에서 관리하는 보안 비밀에 대한 참조입니다.

# Settings for Cloud Run
runConfig:
  minInstances: 2
  maxInstances: 100
  concurrency: 100
  cpu: 2
  memoryMiB: 1024

# Environment variables and secrets
env:
  - variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
      - BUILD
      - RUNTIME

  - variable: API_KEY
    secret: myApiKeySecret

    # Same as API_KEY above but with a pinned version.
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

    # Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
  - variable: VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID

    # Same as API_KEY above but with the long form secret reference with pinned version.
  - variable: PINNED_VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID/versions/5

이 가이드의 나머지 부분에서는 이 예에 대한 자세한 정보와 컨텍스트를 제공합니다. 설정을 변경할 수 있습니다.

Cloud Run 서비스 설정 구성

apphosting.yaml 설정을 통해 Cloud Run 서비스는 프로비저닝됩니다 이 Cloud Run 서비스는 runConfig 객체에 제공됩니다.

cpu – 각 제공 인스턴스에 사용되는 CPU 수입니다 (기본값 0).
memoryMiB – 각 제공 인스턴스에 할당된 메모리 양(MiB) (기본값 512)
maxInstances – 한 번에 실행할 수 있는 최대 컨테이너 수입니다 (기본값). 할당량으로 관리됨)
minInstances – 항상 활성 상태로 유지할 컨테이너의 수입니다 (기본값 0).
concurrency – 각 제공 인스턴스가 사용할 수 있는 최대 요청 수입니다. 수신 (기본값 80)

cpu와 memoryMiB의 중요한 관계에 유의하세요. 메모리는 설정 가능한 128에서 32768 사이의 정수 값으로 변환하지만 메모리 한도를 늘리면 CPU 한도를 늘려야 합니다.

4GiB를 초과하면 2개 이상의 CPU 필요
8GiB를 초과하면 4개 이상의 CPU 필요
16GiB를 초과하면 6개 이상의 CPU 필요
24GiB를 초과하면 8개 이상의 CPU 필요

마찬가지로 cpu의 값은 동시 실행 설정에 영향을 미칩니다. 값을 설정하는 경우 CPU가 1개 미만인 경우 동시 실행을 1로 설정해야 하며 CPU만 할당됨 요청을 처리하는 동안에도 사용할 수 있게 됩니다

빌드 환경 구성

빌드 프로세스에 다음과 같은 추가 구성이 필요할 때도 있습니다. 서드 파티 API 키 또는 조정 가능한 설정이 있습니다. App Hosting은 환경을 제공하여 이를 저장하고 가져올 수 있는 apphosting.yaml의 구성 데이터 유형을 정의합니다

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com

Next.js 앱의 경우 다음을 포함하는 dotenv 파일 환경 변수 또한 App Hosting과 함께 사용할 수 있습니다 세분화하려면 apphosting.yaml를 사용하는 것이 좋습니다. 환경 변수를 제어할 수 있습니다

apphosting.yaml에서는 데이터에 액세스할 수 있는 프로세스를 지정할 수 있습니다. 환경 변수를 설정합니다.availability 특정 IP 주소를 가진 빌드 환경에서만 사용하거나 런타임 환경에만 적용됩니다 기본적으로 둘 다 사용할 수 있습니다.

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

Next.js 앱의 경우 NEXT_PUBLIC_ 접두사를 사용하는 것과 동일한 방식으로 사용할 수도 있습니다. 를 사용하여 브라우저에서 변수에 액세스할 수 있도록 합니다.

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

유효한 변수 키는 A~Z 문자 또는 밑줄로 구성됩니다. 다소 유용함 환경 변수 키는 내부용으로 예약되어 있습니다. 다음 중 하나라도 사용하지 않음 키를 사용하면 됩니다.

X_FIREBASE_로 시작하는 모든 변수
PORT
K_SERVICE
K_REVISION
K_CONFIGURATION

보안 비밀 매개변수 저장 및 액세스

API 키와 같은 민감한 정보는 보안 비밀로 저장해야 합니다. 다음과 같은 작업을 할 수 있습니다. 민감한 정보를 확인하지 않도록 apphosting.yaml에서 보안 비밀을 참조하세요. 소스 제어에 삽입합니다

secret 유형의 매개변수는 값이 있는 문자열 매개변수를 나타냅니다. Cloud Secret Manager에 저장됩니다. 대신 값을 직접 도출하므로 보안 비밀 매개변수는 Cloud Storage에 존재하는지 여부를 확인합니다. Secret Manager로 설정하고, 출시 중에 값을 로드합니다.

  -   variable: API_KEY
      secret: myApiKeySecret

Cloud Secret Manager의 보안 비밀에는 여러 버전이 있을 수 있습니다. 기본적으로 라이브 백엔드에서 사용할 수 있는 보안 비밀 매개변수 값이 백엔드가 빌드된 시점에 사용 가능한 최신 버전의 보안 비밀입니다. 만약 매개변수의 버전 관리 및 수명 주기 관리에 대한 요구사항이 있다면 특정 버전에 고정할 수 있습니다 예를 들어 버전 5:

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

CLI 명령어 firebase apphosting:secrets:set를 사용하여 보안 비밀을 만들 수 있습니다. 필요한 권한을 추가하라는 메시지가 표시됩니다. 이 과정을 통해 apphosting.yaml에 보안 비밀 참조를 자동으로 추가하는 옵션

Cloud Secret Manager 기능의 전체 제품군을 사용하려면 대신 Cloud Secret Manager 콘솔 이렇게 하면 CLI 명령어 firebase apphosting:secrets:grantaccess를 사용하여 App Hosting 백엔드에 대한 권한을 부여하세요.

Firebase 인증 상태 동기화

Firebase 인증을 사용하는 앱은 Firebase 웹 SDK를 사용하여 클라이언트와 서버 간에 동기화된 인증 상태 이는 서비스 워커로 FirebaseServerApp를 구현하여 촉진됩니다. 기본 작업 흐름은 다음과 같습니다.

서비스 워커 구현 는 서버에 대한 요청에서 앱의 올바른 헤더를 추가합니다.
서버의 요청에서 헤더를 가져와 인증으로 변환 FirebaseServerApp를 사용하는 사용자

백엔드 관리

App Hosting 백엔드의 기본 관리를 위한 명령어는 다음과 같습니다. Firebase CLI에서 제공하세요. 다소 유용함 작업을 Firebase Console에서도 사용할 수 있습니다. 이 섹션에서는 생성 및 관리 등 보다 일반적인 관리 작업을 백엔드를 삭제하는 경우가 있습니다

백엔드 만들기

App Hosting 백엔드는 애플리케이션에 액세스할 수 있는 App Hosting은 웹 앱을 빌드하고 실행하기 위해 생성합니다. Google Cloud 콘솔의 Firebase Console을 사용하는 App Hosting 백엔드 또는 Firebase CLI

Firebase Console: 빌드 메뉴에서 App Hosting을 선택한 다음 시작하기

CLI: (버전 3.9 이상) 백엔드를 만들려면 다음 명령어를 실행합니다. 로컬 프로젝트 디렉터리의 루트에서 프로젝트 ID를 인수로 사용합니다 (미리보기의 경우 us-central1 리전만 지원됩니다).

firebase apphosting:backends:create --project PROJECT_ID --location us-central1

콘솔 또는 CLI의 경우 프롬프트에 따라 백엔드에 이름을 할당하고 설정해 GitHub 연결 아래의 기본 배포 설정을 구성합니다.

앱의 루트 디렉터리 (기본값은 /)를 설정합니다.

일반적으로 package.json 파일은 여기에 있습니다.

라이브 브랜치 설정

이는 프로젝트에 배포되는 GitHub 저장소의 브랜치입니다. 라이브 URL을 사용합니다. 기능 브랜치 또는 개발이 이뤄지는 병합됩니다
자동 출시 수락 또는 거부

자동 출시는 기본적으로 사용 설정되어 있습니다. 백엔드 생성이 완료되면 앱을 App Hosting에 즉시 배포하도록 선택할 수 있습니다.

백엔드 삭제

백엔드를 완전히 삭제하려면 먼저 Firebase CLI를 사용한 다음 수동으로 삭제하세요. 관련 애셋을 삭제합니다. 이때 특별히 주의해야 하는 리소스는 다른 백엔드 또는 Firebase 프로젝트의 다른 측면에 사용될 수 있습니다.

다음 명령어를 실행하여 App Hosting 백엔드를 삭제합니다. 백엔드의 모든 도메인이 사용 중지되고 연결된 Cloud Run 서비스:
```
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1
```
(선택사항) Artifact Registry의 Google Cloud 콘솔 탭 'firebaseapphosting-images'에서 백엔드의 이미지를 삭제합니다.
Cloud Secret Manager에서 'apphosting'으로 보안 비밀 삭제 이름은 특별히 유의하여 이러한 보안 비밀을 다른 백엔드 또는 다른 측면도 살펴보겠습니다.