Для расширенной настройки, такой как переменные среды или параметры времени выполнения, такие как ограничения одновременного выполнения, ЦП и памяти, вам необходимо создать и отредактировать файл 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
— количество процессоров, используемых для каждого обслуживающего экземпляра (по умолчанию 0). -
memoryMiB
— объем памяти, выделенный для каждого обслуживающего экземпляра в MiB (по умолчанию 512). -
maxInstances
— максимальное количество контейнеров, которые могут быть запущены одновременно (по умолчанию 100 и управляется квотой). -
minInstances
— количество контейнеров, которые всегда будут оставаться активными (по умолчанию 0). -
concurrency
— максимальное количество запросов, которые может получить каждый обслуживающий экземпляр (по умолчанию 80).
Обратите внимание на важную связь между cpu
и memoryMiB
; Для памяти можно задать любое целочисленное значение от 128 до 32768, но увеличение лимита памяти может потребовать увеличения лимитов ЦП:
- Для более 4 ГБ требуется как минимум 2 процессора
- Для более 8 ГБ требуется как минимум 4 процессора
- Для более 16 ГБ требуется как минимум 6 процессоров
- Для более 24 ГБ требуется как минимум 8 процессоров
Аналогичным образом значение cpu
влияет на настройки параллелизма. Если вы установите значение меньше 1 ЦП, необходимо установить для параллелизма значение 1, и ЦП будет выделяться только во время обработки запроса.
Настройте среду сборки
Иногда вам потребуется дополнительная настройка процесса сборки, например ключи стороннего API или настраиваемые параметры. Хостинг приложений предлагает настройку среды в apphosting.yaml
для хранения и получения данных этого типа для вашего проекта.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
Для приложений Next.js файлы dotenv, содержащие переменные среды, также будут работать с хостингом приложений. Мы рекомендуем использовать apphosting.yaml
для детального управления переменными среды в любой платформе.
В apphosting.yaml
вы можете указать, какие процессы имеют доступ к вашей переменной среды, используя свойство availability
. Вы можете ограничить переменную среды, чтобы она была доступна только для среды сборки или доступна только для среды выполнения. По умолчанию он доступен обоим.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- BUILD
- RUNTIME
Для приложений Next.js вы также можете использовать префикс NEXT_PUBLIC_
так же, как и в файле dotenv, чтобы сделать переменную доступной в браузере.
env:
- variable: NEXT_PUBLIC_STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- BUILD
- RUNTIME
Допустимые переменные ключи состоят из символов AZ или символов подчеркивания. Некоторые ключи переменных среды зарезервированы для внутреннего использования. Не используйте ни один из этих ключей в файлах конфигурации:
- Любая переменная, начинающаяся с
X_FIREBASE_
-
PORT
-
K_SERVICE
-
K_REVISION
-
K_CONFIGURATION
Храните и получайте доступ к секретным параметрам
Конфиденциальная информация, такая как ключи API, должна храниться как секрет. Вы можете ссылаться на секреты в apphosting.yaml
, чтобы избежать проверки конфиденциальной информации в системе контроля версий.
Параметры типа secret
представляют собой строковые параметры, значение которых хранится в Cloud Secret Manager . Вместо прямого получения значения секретные параметры проверяют наличие в Cloud Secret Manager и загружают значения во время развертывания.
- variable: API_KEY
secret: myApiKeySecret
Секреты в Cloud Secret Manager могут иметь несколько версий. По умолчанию значение секретного параметра, доступного вашему действующему бэкэнду, привязано к последней доступной версии секрета на момент создания бэкэнда. Если у вас есть требования к управлению версиями и жизненным циклом параметров, вы можете закрепить их за конкретными версиями с помощью 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
.
Синхронизировать состояние аутентификации Firebase
Приложениям, использующим Firebase Auth, следует рассмотреть возможность использования Firebase Web SDK, чтобы обеспечить синхронизацию состояния аутентификации между клиентом и сервером. Этому можно способствовать, реализовав FirebaseServerApp
с помощью сервис-воркера. Основной поток задач таков:
- Реализуйте сервис-воркера , который добавляет правильные заголовки для вашего приложения при запросах к серверу.
- Получите заголовки запроса на сервере и преобразуйте их в пользователя с аутентификацией с помощью
FirebaseServerApp
.