App Hosting는 일련의 복잡한 백그라운드 작업을 처리하여 앱 배포를 간소화합니다. 이 페이지에서는 이러한 태스크 흐름의 주요 부분을 설명하고 앱의 요구사항에 따라 흐름을 맞춤설정할 수 있는 지점에 관한 정보를 제공합니다.
프레임워크 통합
App Hosting는 다음 프레임워크에서 개발된 웹 앱에 사전 구성된 빌드 및 배포 지원을 제공합니다.
- Next.js 13 이상
- Angular 17.2 이상
App Hosting는 저장소의 package-lock.json 파일 또는 기타 잠금 파일을 검사하여 사용 중인 프레임워크를 식별합니다. 잠금 파일이 없는 Node.js 앱을 배포하려고 하면 App Hosting에서 앱을 빌드하고 실행하지 못합니다. 루트 디렉터리에서 npm
install를 실행하여 package-lock.json를 만들 수 있습니다.
프레임워크 어댑터
App Hosting 프레임워크 어댑터에는 두 가지 주요 역할이 있습니다.
- 소스 코드와 프레임워크별 구성 파일 (예:
next.config.js)을 파싱하고 나머지 앱 호스팅 인프라에서 처리할 수 있는 출력 번들을 생성합니다. - 앱의 빌드 명령어를 실행하여 정적 애셋을 생성하고 프로덕션용으로 최적화된 앱 버전을 만듭니다.
프레임워크 어댑터는 npm run build로 Node.js 앱을 빌드하며 각 프레임워크의 기본 빌드 스크립트(Next.js의 경우 next build, Angular의 경우 ng build)와 가장 잘 작동합니다. App Hosting는 맞춤 빌드 명령어로 빌드를 시도하지만 성공을 확실하게 보장할 수는 없습니다.
Next.js 및 Angular 어댑터의 소스는 firebase-framework-tools에서 사용할 수 있습니다.
기타 프레임워크
App Hosting은 Nextjs 및 Angular 외에도 출력 번들 사양과 일치하는 빌드 출력을 제공할 수 있는 모든 웹 프레임워크를 지원합니다. 프레임워크 작성자는 출력 번들 사양을 활용하여 앱 호스팅에서 프레임워크가 지원되도록 할 수 있습니다.
추가 프레임워크를 지원하려면 어댑터를 만들거나 프레임워크의 유지관리자에게 문의하여 빌드 출력을 앱 호스팅 형식으로 변환할 수 있습니다. Nextjs 및 Angular 어댑터는 어댑터를 만드는 모든 사용자에게 좋은 참조 예시입니다.
지원되는 프레임워크는 Firebase 오픈소스에서 확인할 수 있습니다.
App Hosting 저장소 통합 작동 방식
GitHub 저장소와 App Hosting 백엔드 간의 중요한 연결은 외부 DevOps 도구를 위한 Google Cloud의 연결 플랫폼인 Developer Connect에서 처리합니다. App Hosting 백엔드를 만드는 동안 Developer Connect의 UI 워크플로에 따라 Firebase GitHub 앱을 설치할 수 있습니다. 이 프로세스의 주요 단계는 다음과 같습니다.
- Developer Connect에 Secret Manager 관리자 역할을 부여합니다. 이렇게 하면 시스템이 사용자 인증 정보를 Cloud Secret Manager에 '보안 비밀'로 안전하게 저장할 수 있습니다.
- Firebase GitHub 앱이 GitHub 저장소에 액세스하도록 승인합니다.
- Developer Connect는 프로젝트의 Secret Manager 저장소에 전용 GitHub 승인 토큰을 저장합니다. 이 토큰을 수정하거나 삭제하지 마세요.
또한 App Hosting는 GitHub Checks API와 통합되어 출시를 확인합니다. 이 검사를 통해 GitHub에서 출시 상태를 확인하고 오류가 있는 경우 배포 프로세스를 디버그할 수 있습니다.
Firebase 및 기타 Google 서비스와의 통합
App Hosting는 빌드 환경과 런타임 환경을 모두 설정하여 Google 애플리케이션 기본 사용자 인증 정보로 Firebase Admin SDK를 초기화할 수 있도록 합니다. 이렇게 하면 백엔드가 빌드와 배포 중에 다른 Firebase 제품과 통신할 수 있습니다.
위치 App Hosting개
App Hosting 배포는 특정 위치에 백엔드 리소스를 만듭니다. 웹 앱의 위치를 유연하게 지정할 수 있으면 다음과 같은 주요 이점이 있습니다.
- 데이터를 사용자와 지리적으로 더 가까운 위치에 가져와 성능을 개선하고 지연 시간을 줄였습니다.
- 한 리전에서 App Hosting의 심각한 장애가 발생해도 다른 리전에 배포된 웹 앱에는 영향을 미치지 않습니다.
콘솔 또는 Firebase CLI에서 App Hosting 백엔드를 만들 때 다음 리전 중 하나를 선택할 수 있습니다.
us-central1(아이오와)asia-east1(타이완)europe-west4(네덜란드)
App Hosting 백엔드 서비스 계정
빌드 중과 런타임에 App Hosting 백엔드는 서비스 계정으로 다른 Google 서비스에 인증합니다. 이러한 목적을 위한 기본 서비스 계정은 Firebase 프로젝트에서 App Hosting를 처음 사용 설정할 때 생성됩니다.
firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com
이 서비스 계정은 기본적으로 모든 백엔드에 적용되며 앱을 빌드, 실행, 모니터링할 수 있는 최소한의 권한 집합이 있습니다. 또한 Cloud Firestore에서 데이터를 로드하는 등의 작업을 실행하기 위해 애플리케이션 기본 사용자 인증 정보로 Admin SDK를 인증할 권한도 있습니다. Firebase App Hosting 역할을 참고하세요.
앱이 빌드 시간 또는 실행 중인 백엔드에서 추가 Google 서비스와 상호작용해야 하는 경우 역할을 추가하여 기본 서비스 계정을 맞춤설정할 수 있습니다. 예를 들어 앱에 Vertex AI 권한이 필요한 경우 roles/aiplatform.user 또는 관련 역할을 추가해야 할 수 있습니다.
핵심 용어 및 정의
- 백엔드: App Hosting가 웹 앱을 빌드하고 실행하기 위해 만드는 관리형 리소스 모음입니다.
- 출시: git 커밋에 연결된 실행 중인 앱의 특정 버전입니다.
- 실제 브랜치: 실제 URL에 배포되는 GitHub 저장소의 브랜치입니다. 기능 브랜치 또는 개발 브랜치가 병합되는 브랜치인 경우가 많습니다.
알려진 문제 및 제한사항
App Hosting 미리보기에는 몇 가지 알려진 제한사항이 있습니다.
- 경우에 따라 App Hosting 백엔드가 앱의 URL에서
Intermittent connection error메시지를 반환할 수 있습니다. 수정사항은 향후 출시에서 제공될 예정입니다. - Cache-Control 헤더가 CDN 캐시를 60초로 제한하도록 수정되었습니다. 향후 App Hosting가 배포 시 캐시를 빠르게 삭제할 수 있는 기능이 있으면 이 제한이 해제됩니다.
- 이미지 최적화는 기본적으로 Cloud Run에서 실행되며 최적화된 이미지는 유지되지 않습니다. 더 나은 솔루션을 사용할 수 있을 때까지 이미지 최적화를 사용 중지하거나 로더를 수동으로 지정하는 것이 좋습니다.
- 캐시되지 않은 정적 파일은 Cloud Run에서 제공됩니다. 이후 버전에서는 성능 향상을 위해 App Hosting 출처에서 저장되고 제공됩니다.
- App Hosting SKU가 Firebase 콘솔의 백엔드 사용량 페이지에 표시되지 않을 수 있습니다. 이 기능은 향후 버전에서 제공될 예정입니다.
- 백엔드 생성 시 Firebase 콘솔에 '빌드가 없으며 유효하지 않음' 오류가 간헐적으로 표시될 수 있습니다.
- 현재 동일한 프로젝트의 모든 백엔드는 GitHub 조직/계정을 공유합니다. 해당 조직/계정의 여러 저장소에 연결할 수 있습니다. 서로 다른 GitHub 계정에 연결된 백엔드를 만들려면 별도의 프로젝트에 배치합니다.
- Next.js 미들웨어, 재작성, 리디렉션은 CDN 뒤의 Cloud Run에서 실행됩니다. 캐시된 응답은 보호되지 않으므로 렌더링하는 콘텐츠에 적절한 제어 디렉티브를 설정해야 합니다.