如果您在构建服务器端渲染的 Angular 或 Next.js 应用，不妨试试我们新一代的 Firebase App Hosting，这是一款适用于现代 Web 框架的全栈解决方案。

Эта страница переведена с помощью Cloud Translation API.

Развертывание на своем сайте с помощью API REST хостинга.

REST API Firebase Hosting обеспечивает программные и настраиваемые развёртывания на ваших сайтах, размещённых в Firebase. Используйте этот REST API для развёртывания нового или обновлённого контента и конфигурации Hosting .

В качестве альтернативы использованию Firebase CLI для развертываний вы можете использовать Firebase Hosting REST API для программного создания новой version ресурсов для вашего сайта, загрузки файлов в версию, а затем развертывания версии на вашем сайте.

Например, с помощью Firebase Hosting REST API вы можете:

Планирование развёртываний. Используя REST API в сочетании с cron-заданием, вы можете регулярно изменять контент, размещённый в Firebase (например, для развёртывания версии контента, приуроченной к празднику или событию).
Интеграция с инструментами разработчика. Вы можете создать в своём инструменте опцию для развертывания проектов веб-приложений на Firebase Hosting всего одним щелчком мыши (например, нажатием кнопки «Развернуть» в IDE).
Автоматизируйте развёртывание при генерации статического контента. Когда процесс генерирует статический контент программно (например, пользовательский контент, такой как вики или новостная статья), вы можете развернуть сгенерированный контент как статические файлы, а не предоставлять их динамически. Это экономит дорогостоящие вычислительные мощности и обеспечивает более масштабируемое обслуживание файлов.

В этом руководстве сначала описывается, как включить, аутентифицировать и авторизовать API. Затем рассматривается пример создания версии Firebase Hosting , загрузки необходимых файлов в неё и, наконец, её развертывания.

Дополнительную информацию об этом REST API можно найти в полной справочной документации по Hosting REST API .

Прежде чем начать: включите REST API

Необходимо включить Firebase Hosting REST API в консоли API Google:

Откройте страницу Firebase Hosting API в консоли Google API.
При появлении запроса выберите свой проект Firebase.
Примечание: каждому проекту Firebase соответствует проект в консоли API Google.
Нажмите «Включить» на странице Firebase Hosting API.

Шаг 1: Получите токен доступа для аутентификации и авторизации запросов API.

Проекты Firebase поддерживают учётные записи служб Google, которые можно использовать для вызова API сервера Firebase с сервера приложений или доверенной среды. Если вы разрабатываете код локально или развёртываете приложение локально, вы можете использовать учётные данные, полученные через эту учётную запись службы, для авторизации запросов к серверу.

Чтобы аутентифицировать учетную запись службы и предоставить ей доступ к службам Firebase, необходимо сгенерировать файл закрытого ключа в формате JSON.

Чтобы создать файл закрытого ключа для вашей учетной записи службы:

В консоли Firebase откройте Настройки > Учетные записи служб .
Нажмите «Сгенерировать новый закрытый ключ» , затем подтвердите, нажав «Сгенерировать ключ» .
Надежно сохраните JSON-файл, содержащий ключ.

Используйте свои учетные данные Firebase вместе с библиотекой Google Auth Library для предпочитаемого вами языка, чтобы получить кратковременный токен доступа OAuth 2.0:

node.js

const {google} = require('googleapis');
function getAccessToken() {
  return new Promise(function(resolve, reject) {
    var key = require('./service-account.json');
    var jwtClient = new google.auth.JWT(
      key.client_email,
      null,
      key.private_key,
      SCOPES,
      null
    );
    jwtClient.authorize(function(err, tokens) {
      if (err) {
        reject(err);
        return;
      }
      resolve(tokens.access_token);
    });
  });
}

В этом примере клиентская библиотека API Google аутентифицирует запрос с помощью веб-токена JSON (JWT). Подробнее см. в разделе Веб-токены JSON .

Питон

def _get_access_token():
  """Retrieve a valid access token that can be used to authorize requests.

  :return: Access token.
  """
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
      'service-account.json', SCOPES)
  access_token_info = credentials.get_access_token()
  return access_token_info.access_token

Ява

private static String getAccessToken() throws IOException {
  GoogleCredential googleCredential = GoogleCredential
      .fromStream(new FileInputStream("service-account.json"))
      .createScoped(Arrays.asList(SCOPES));
  googleCredential.refreshToken();
  return googleCredential.getAccessToken();
}

По истечении срока действия токена доступа автоматически вызывается метод обновления токена для получения обновленного токена доступа.

Примечание: Хотя использование учётной записи службы подходит для автоматизированных задач в серверных средах, существуют и другие способы получения авторизации для использования REST API Firebase Hosting . Например, участники проекта могут использовать API, если им (1) назначена роль администратора или редактора проекта и (2) предоставлены токены доступа с соответствующей областью действия. Ознакомьтесь с другими сценариями для различных потоков OAuth, которые позволят вам получить авторизацию для использования REST API Firebase Hosting .

Шаг 2: Убедитесь, что у вашего проекта есть сайт Hosting по умолчанию.

Перед первым развертыванием на Firebase Hosting ваш проект Firebase должен иметь Hosting SITE по умолчанию.

Проверьте, есть ли у вашего проекта сайт Hosting по умолчанию, вызвав конечную точку sites.list .
Например:
команда cURL
```
curl -H "Content-Type: application/json" \
       -H "Authorization: Bearer ACCESS_TOKEN" \

https://firebasehosting.googleapis.com/v1beta1/projects/PROJECT_ID/sites
```
Необработанный HTTPS-запрос
```
Host: firebasehosting.googleapis.com

POST /v1beta1/projects/PROJECT_ID/sites HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
```
- Если один из сайтов имеет "type": "DEFAULT_SITE" , то в вашем проекте уже есть сайт Hosting по умолчанию. Пропустите оставшуюся часть этого шага и перейдите к следующему: создайте новую версию для вашего сайта .
- Если вы получили пустой массив, значит, у вас нет Hosting по умолчанию. Выполните оставшуюся часть этого шага.
Выберите SITE_ID для вашего сайта Hosting по умолчанию. При выборе SITE_ID учитывайте следующее:
- Этот SITE_ID используется для создания поддоменов Firebase по умолчанию:
  SITE_ID .web.app и SITE_ID .firebaseapp.com .
- SITE_ID имеет следующие требования:
  - Должна быть допустимой меткой имени хоста, т. е. она не может содержать . , _ и т. д.
  - Должно быть не более 30 символов.
  - Должен быть глобально уникальным в пределах Firebase
Обратите внимание, что мы часто рекомендуем использовать идентификатор вашего проекта в качестве SITE_ID для вашего сайта Hosting по умолчанию. Узнайте, как найти этот идентификатор, в статье «Понимание проектов Firebase» .
Создайте свой сайт Hosting по умолчанию, вызвав конечную точку sites.create , используя желаемый SITE_ID в качестве параметра siteId .
Например:
команда cURL
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer ACCESS_TOKEN" \ https://firebasehosting.googleapis.com/v1beta1/projects/PROJECT_ID/sites?siteId=SITE_ID
Необработанный HTTPS-запрос
Host: firebasehosting.googleapis.com POST /v1beta1/projects/PROJECT_ID/sites?siteId=SITE_ID Authorization: Bearer ACCESS_TOKEN Content-Type: application/json
Этот вызов API к sites.create возвращает следующий JSON:
```
{
  "name": "projects/PROJECT_ID/sites/SITE_ID",
  "defaultUrl": "https://SITE_ID.web.app",
  "type": "DEFAULT_SITE"
}
```
Если вы решили использовать идентификатор своего проекта в качестве SITE_ID , обратите внимание на следующее:
В редких случаях ваш идентификатор проекта уже используется другим проектом для создания сайта Hosting . В таких случаях вызов sites.create возвращает ошибку 400, в которой говорится, что предоставленный SITE_ID reserved by another project . Чтобы устранить эту ошибку, попробуйте вызвать sites.create снова, используя строку, предложенную в сообщении об ошибке, или другую строку, пока вызов не завершится успешно.

Шаг 3: Создайте новую версию вашего сайта

Ваш первый вызов API — создание новой Version для вашего сайта. Далее в этом руководстве вы загрузите файлы в эту версию, а затем развернёте её на своём сайте.

Определите SITE_ID для сайта, на котором вы хотите выполнить развертывание.
Примечание: для вашего сайта Hosting по умолчанию SITE_ID — это идентификатор вашего проекта Firebase (который используется для создания ваших поддоменов Firebase SITE_ID .web.app и SITE_ID .firebaseapp.com ).
Если вы создали несколько сайтов в своем проекте Firebase, убедитесь, что вы используете SITE_ID сайта, на котором вы хотите выполнить развертывание.

Вызовите конечную точку versions.create , используя свой SITE_ID в вызове.

(Необязательно) Вы также можете передать объект конфигурации Firebase Hosting в вызов, включая установку заголовка, который кэширует все файлы в течение определенного периода времени.

Например:

команда cURL

curl -H "Content-Type: application/json" \
       -H "Authorization: Bearer ACCESS_TOKEN" \
       -d '{
             "config": {
               "headers": [{
                 "glob": "**",
                 "headers": {
                   "Cache-Control": "max-age=1800"
                 }
               }]
             }
           }' \
https://firebasehosting.googleapis.com/v1beta1/sites/SITE_ID/versions

Необработанный HTTPS-запрос

Host: firebasehosting.googleapis.com

POST /v1beta1/sites/SITE_ID/versions HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
Content-Length: 134

{
  "config": {
    "headers": [{
      "glob": "**",
      "headers": {
        "Cache-Control": "max-age=1800"
      }
    }]
  }
}

Этот вызов API к versions.create возвращает следующий JSON:

{
  "name": "sites/SITE_ID/versions/VERSION_ID",
  "status": "CREATED",
  "config": {
    "headers": [{
      "glob": "**",
      "headers": {
        "Cache-Control": "max-age=1800"
      }
    }]
  }
}

Этот ответ содержит уникальный идентификатор новой версии в формате: sites/ SITE_ID /versions/ VERSION_ID . Этот уникальный идентификатор понадобится вам на протяжении всего руководства для ссылки на эту конкретную версию.

Шаг 4: Укажите список файлов, которые вы хотите развернуть.

Теперь, когда у вас есть идентификатор новой версии, вам нужно сообщить Firebase Hosting , какие файлы вы хотите в конечном итоге развернуть в этой новой версии.

Обратите внимание, что Hosting установлено ограничение по максимальному размеру отдельных файлов в 2 ГБ.

Этот API требует, чтобы файлы идентифицировались по хешу SHA256. Поэтому, прежде чем вы сможете выполнить вызов API, вам сначала нужно вычислить хеш для каждого статического файла, сжав его с помощью Gzip, а затем получить хеш SHA256 для каждого сжатого файла.

Продолжая наш пример, предположим, что вы хотите развернуть три файла в новой версии: file1 , file2 и file3 .

Сжатие файлов в формате Gzip:
```
gzip file1 && gzip file2 && gzip file3
```
Теперь у вас есть три сжатых файла file1.gz , file2.gz и file3.gz .

Получите хэш SHA256 каждого сжатого файла:

cat file1.gz | openssl dgst -sha256

66d61f86bb684d0e35f94461c1f9cf4f07a4bb3407bfbd80e518bd44368ff8f4

cat file2.gz | openssl dgst -sha256

490423ebae5dcd6c2df695aea79f1f80555c62e535a2808c8115a6714863d083

cat file3.gz | openssl dgst -sha256

59cae17473d7dd339fe714f4c6c514ab4470757a4fe616dfdb4d81400addf315

Теперь у вас есть три хеша SHA256 трех сжатых файлов.

Отправьте эти три хеша в API-запросе к конечной точке versions.populateFiles . Укажите каждый хеш по желаемому пути для загруженного файла (в этом примере /file1 , /file2 и /file3 ).

Например:

команда cURL

$ curl -H "Content-Type: application/json" \
         -H "Authorization: Bearer ACCESS_TOKEN" \
         -d '{
               "files": {
                 "/file1": "66d61f86bb684d0e35f94461c1f9cf4f07a4bb3407bfbd80e518bd44368ff8f4",
                 "/file2": "490423ebae5dcd6c2df695aea79f1f80555c62e535a2808c8115a6714863d083",
                 "/file3": "59cae17473d7dd339fe714f4c6c514ab4470757a4fe616dfdb4d81400addf315"
               }
             }' \
https://firebasehosting.googleapis.com/v1beta1/sites/SITE_ID/versions/VERSION_ID:populateFiles

Необработанный HTTPS-запрос

Host: firebasehosting.googleapis.com

POST /v1beta1/sites/SITE_ID/versions/VERSION_ID:populateFiles HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
Content-Length: 181

{
  "files": {
    "/file1": "66d61f86bb684d0e35f94461c1f9cf4f07a4bb3407bfbd80e518bd44368ff8f4",
    "/file2": "490423ebae5dcd6c2df695aea79f1f80555c62e535a2808c8115a6714863d083",
    "/file3": "59cae17473d7dd339fe714f4c6c514ab4470757a4fe616dfdb4d81400addf315"
  }
}

Этот вызов API к versions.populateFiles возвращает следующий JSON:

{
  "uploadRequiredHashes": [
    "490423ebae5dcd6c2df695aea79f1f80555c62e535a2808c8115a6714863d083",
    "59cae17473d7dd339fe714f4c6c514ab4470757a4fe616dfdb4d81400addf315"
  ],
  "uploadUrl": "https://upload-firebasehosting.googleapis.com/upload/sites/SITE_ID/versions/VERSION_ID/files"
}

Этот ответ включает в себя:

Хеш каждого файла , который необходимо загрузить. Например, в этом примере file1 уже был загружен в предыдущей версии, поэтому его хеш не включен в список uploadRequiredHashes .
Примечание: некоторые файлы в новой версии загружать не нужно, например, если файл уже был в предыдущей версии и не был изменен для новой версии.
uploadUrl , специфичный для новой версии.

На следующем этапе для загрузки двух новых файлов вам понадобятся хеши и uploadURL из ответа versions.populateFiles .

Шаг 5: Загрузите необходимые файлы

Вам необходимо загрузить каждый необходимый файл (файлы, перечисленные в uploadRequiredHashes из ответа versions.populateFiles на предыдущем шаге). Для загрузки этих файлов вам понадобятся хэши файлов и uploadUrl из предыдущего шага.

Добавьте косую черту и хэш файла к uploadUrl , чтобы создать URL-адрес для конкретного файла в формате: https://upload-firebasehosting.googleapis.com/upload/sites/ SITE_ID /versions/ VERSION_ID /files/ FILE_HASH .

Загрузите все необходимые файлы по одному (в этом примере только file2.gz и file3.gz ) на URL-адрес конкретного файла с помощью серии запросов.

Например, чтобы загрузить сжатый file2.gz :

команда cURL

curl -H "Authorization: Bearer ACCESS_TOKEN" \
       -H "Content-Type: application/octet-stream" \
       --data-binary @./file2.gz \
https://upload-firebasehosting.googleapis.com/upload/sites/SITE_ID/versions/VERSION_ID/files/FILE_HASH

Необработанный HTTPS-запрос

Host: upload-firebasehosting.googleapis.com

POST /upload/sites/SITE_ID/versions/VERSION_ID/files/FILE_HASH HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/octet-stream
Content-Length: 500

content-of-file2.gz

Успешные загрузки возвращают ответ HTTPS 200 OK .

Шаг 6: Обновите статус версии на «ФИНАЛИЗИРОВАНО».

После загрузки всех файлов, перечисленных в ответе versions.populateFiles , вы можете обновить статус своей версии на FINALIZED .

Вызовите конечную точку versions.patch , установив поле status в запросе API на FINALIZED .

Например:

команда cURL

curl -H "Content-Type: application/json" \
       -H "Authorization: Bearer ACCESS_TOKEN" \
       -X PATCH \
       -d '{"status": "FINALIZED"}' \
https://firebasehosting.googleapis.com/v1beta1/sites/SITE_ID/versions/VERSION_ID?update_mask=status

Необработанный HTTPS-запрос

Host: firebasehosting.googleapis.com

PATCH /v1beta1/sites/SITE_ID/versions/VERSION_ID?update_mask=status HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
Content-Length: 23

{"status": "FINALIZED"}

Этот вызов API к versions.patch возвращает следующий JSON-код. Убедитесь, что status обновлен до FINALIZED .

{
  "name": "sites/SITE_ID/versions/VERSION_ID",
  "status": "FINALIZED",
  "config": {
    "headers": [{
      "glob": "**",
      "headers": {"Cache-Control": "max-age=1800"}
    }]
  },
  "createTime": "2018-12-02T13:41:56.905743Z",
  "createUser": {
    "email": "SERVICE_ACCOUNT_EMAIL@SITE_ID.iam.gserviceaccount.com"
  },
  "finalizeTime": "2018-12-02T14:56:13.047423Z",
  "finalizeUser": {
    "email": "USER_EMAIL@DOMAIN.tld"
  },
  "fileCount": "5",
  "versionBytes": "114951"
}

Шаг 7: Выпуск версии для развертывания

Теперь, когда у вас есть финальная версия, выпустите её для развёртывания. Для этого вам необходимо создать Release вашей версии, содержащий конфигурацию хостинга и все файлы контента для новой версии.

Вызовите конечную точку releases.create , чтобы создать свой релиз.

Например:

команда cURL

curl -H "Authorization: Bearer ACCESS_TOKEN" \
       -X POST
https://firebasehosting.googleapis.com/v1beta1/sites/SITE_ID/releases?versionName=sites/SITE_ID/versions/VERSION_ID

Необработанный HTTPS-запрос

Host: firebasehosting.googleapis.com

POST /v1beta1/sites/SITE_ID/releases?versionName=sites/SITE_ID/versions/VERSION_ID HTTP/1.1
Authorization: Bearer ACCESS_TOKEN

Этот вызов API releases.create возвращает следующий JSON:

{
  "name": "sites/SITE_ID/releases/RELEASE_ID",
  "version": {
    "name": "sites/SITE_ID/versions/VERSION_ID",
    "status": "FINALIZED",
    "config": {
    "headers": [{
      "glob": "**",
      "headers": {"Cache-Control": "max-age=1800"}
    }]
  }
  },
  "type": "DEPLOY",
  "releaseTime": "2018-12-02T15:14:37Z"
}

Конфигурация хостинга и все файлы новой версии теперь должны быть развернуты на вашем сайте, и вы можете получить доступ к своим файлам, используя URL-адреса:

https:// SITE_ID .web.app/file1
https:// SITE_ID .web.app/file2
https:// SITE_ID .web.app/file3

Эти файлы также доступны по URL-адресам, связанным с вашим доменом SITE_ID .firebaseapp.com .

Вы также можете увидеть свой новый релиз в списке на панели Hosting консоли Firebase .