Wdróż w swojej witrynie przy użyciu interfejsu Hosting REST API

Interfejs Firebase Hosting REST API umożliwia programowe i dostosowywane wdrożenia w witrynach hostowanych w Firebase. Użyj tego interfejsu REST API, aby wdrożyć nowe lub zaktualizowane treści Hosting i konfigurację.

Zamiast używać interfejsu Firebase CLI do wdrożeń, możesz użyć interfejsu Firebase Hosting REST API, aby programowo utworzyć nową version zasobów witryny, przesłać pliki do tej wersji, a następnie wdrożyć ją w witrynie.

Na przykład za pomocą interfejsu Firebase Hosting REST API możesz:

  • Planować wdrożenia. Używając interfejsu REST API w połączeniu z zadaniem cron, możesz regularnie zmieniać treści hostowane w Firebase (na przykład wdrażać specjalną wersję treści związaną ze świętami lub wydarzeniami).

  • Integrować się z narzędziami dla programistów. Możesz utworzyć w narzędziu opcję wdrażania projektów aplikacji internetowych w Firebase Hosting za pomocą jednego kliknięcia (na przykład, klikając przycisk wdrożenia w IDE).

  • Automatyzować wdrożenia, gdy generowane są treści statyczne. Gdy proces programowo generuje treści statyczne (na przykład treści użytkowników, takie jak witryna wiki lub artykuł informacyjny), możesz wdrożyć wygenerowane treści jako pliki statyczne zamiast udostępniać je dynamicznie. Pozwoli to zaoszczędzić kosztowną moc obliczeniową i wyświetlać pliki w bardziej skalowalny sposób.

W tym przewodniku najpierw opisujemy, jak włączyć, uwierzytelnić i autoryzować interfejs API. Następnie pokazujemy przykład tworzenia Firebase Hosting wersji, przesyłania do niej wymaganych plików i wdrażania tej wersji.

Więcej informacji o tym interfejsie REST API znajdziesz w pełnej Hosting dokumentacji interfejsu REST API.

Zanim zaczniesz: włącz interfejs REST API

Musisz włączyć interfejs Firebase Hosting REST API w Konsoli interfejsów API Google:

  1. Otwórz stronę interfejsu API Firebase Hosting w Konsoli interfejsów API Google.

  2. Gdy pojawi się taka prośba, wybierz projekt w Firebase.

  3. Na stronie interfejsu Firebase Hosting API kliknij Włącz.

Krok 1. Uzyskaj token dostępu, aby uwierzytelnić i autoryzować żądania do interfejsu API

Projekty Firebase obsługują konta usługi Google, których możesz używać do wywoływania interfejsów API serwera Firebase z serwera aplikacji lub zaufanego środowiska. Jeśli tworzysz kod lokalnie lub wdrażasz aplikację lokalnie, możesz użyć danych logowania uzyskanych za pomocą tego konta usługi, aby autoryzować żądania serwera.

Wszystkie konta usługi w projekcie w Firebase możesz wyświetlić w ustawieniach > Konta usługi na karcie.

Aby uwierzytelnić konto usługi i autoryzować je do uzyskiwania dostępu do usług Firebase, musisz wygenerować plik klucza prywatnego w formacie JSON.

Aby wygenerować plik klucza prywatnego dla konta usługi:

  1. W konsoli Firebase otwórz ustawienia na karcie Ustawienia > Konta usługi.

  2. Kliknij Wygeneruj nowy klucz prywatny, a następnie potwierdź, klikając Wygeneruj klucz.

  3. Bezpiecznie przechowuj plik JSON zawierający klucz.

Użyj danych logowania Firebase razem z biblioteką Google Auth Library w preferowanym języku, aby pobrać krótkotrwały token dostępu 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);
    });
  });
}

W tym przykładzie biblioteka klienta interfejsu Google API uwierzytelnia żądanie za pomocą tokena sieciowego JSON (JWT). Więcej informacji znajdziesz w artykule Tokeny sieciowe JSON.

Python

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

Java

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

Gdy token dostępu wygaśnie, automatycznie zostanie wywołana metoda odświeżania tokena, aby pobrać zaktualizowany token dostępu.

Krok 2. Sprawdź, czy projekt ma domyślną witrynę Hosting

Przed pierwszym wdrożeniem w Firebase Hosting projekt w Firebase musi mieć domyślny Hosting SITE.

  1. Sprawdź, czy projekt ma już domyślną witrynę Hosting wywołując sites.list punkt końcowy.

    Przykład:

    Polecenie cURL

    curl -H "Content-Type: application/json" \
       -H "Authorization: Bearer ACCESS_TOKEN" \

https://firebasehosting.googleapis.com/v1beta1/projects/PROJECT_ID/sites

    Surowe żądanie HTTPS

    Host: firebasehosting.googleapis.com

POST /v1beta1/projects/PROJECT_ID/sites HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json

    • Jeśli jedna z witryn ma wartość "type": "DEFAULT_SITE", oznacza to, że projekt ma już domyślną witrynę Hosting. Pomiń pozostałą część tego kroku, i przejdź do następnego kroku: Utwórz nową wersję witryny.

    • Jeśli otrzymasz pustą tablicę, oznacza to, że nie masz domyślnej witryny Hosting. Wykonaj pozostałą część tego kroku.

  2. Określ SITE_ID domyślnej witryny Hosting. Przy podejmowaniu decyzji o tym SITE_ID pamiętaj o tych kwestiach:

    • Ten SITE_ID służy do tworzenia domyślnych subdomen Firebase:
      SITE_ID.web.app i SITE_ID.firebaseapp.com.

    • SITE_ID musi spełniać te wymagania:

      • Musi być prawidłową etykietą nazwy hosta, co oznacza, że nie może zawierać znaków ., _ itp.
      • Musi mieć maksymalnie 30 znaków.
      • Musi być unikalny w skali globalnej w Firebase.

    Zwykle zalecamy używanie identyfikatora projektu jako SITE_ID dla Twojej domyślnej Hosting witryny. Dowiedz się, jak znaleźć ten identyfikator, w artykule Informacje o projektach Firebase.

  3. Utwórz domyślną witrynę Hosting, wywołując punkt końcowy sites.create z parametrem siteId ustawionym na żądany SITE_ID.

    Przykład:

    Polecenie cURL

    curl -H "Content-Type: application/json" \
       -H "Authorization: Bearer ACCESS_TOKEN" \

https://firebasehosting.googleapis.com/v1beta1/projects/PROJECT_ID/sites?siteId=SITE_ID

    Surowe żądanie HTTPS

    Host: firebasehosting.googleapis.com

POST /v1beta1/projects/PROJECT_ID/sites?siteId=SITE_ID
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json

    To wywołanie interfejsu API do sites.create zwraca ten kod JSON:

    {
  "name": "projects/PROJECT_ID/sites/SITE_ID",
  "defaultUrl": "https://SITE_ID.web.app",
  "type": "DEFAULT_SITE"
}

Krok 3. Utwórz nową wersję witryny

Pierwsze wywołanie interfejsu API służy do utworzenia nowego Version witryny. W dalszej części tego przewodnika prześlesz pliki do tej wersji, a następnie wdrożysz ją w witrynie.

  1. Określ SITE_ID witryny, w której chcesz wdrożyć.

  2. Wywołaj punkt końcowy versions.create , używając w wywołaniu SITE_ID.

    (Opcjonalnie) Możesz też przekazać w Firebase Hosting wywołaniu obiekt konfiguracji , w tym ustawić nagłówek, który będzie buforować wszystkie pliki przez określony czas.

    Przykład:

    Polecenie 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

    Surowe żądanie 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"
      }
    }]
  }
}

To wywołanie interfejsu API do versions.create zwraca ten kod JSON:

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

Ta odpowiedź zawiera unikalny identyfikator nowej wersji w formacie: sites/SITE_ID/versions/VERSION_ID. Będziesz potrzebować tego unikalnego identyfikatora w całym przewodniku, aby odwoływać się do tej konkretnej wersji.

Krok 4. Określ listę plików, które chcesz wdrożyć

Teraz, gdy masz już identyfikator nowej wersji, musisz poinformować Firebase Hosting które pliki chcesz ostatecznie wdrożyć w tej nowej wersji.

Pamiętaj, że Hosting ma maksymalny rozmiar pojedynczego pliku wynoszący 2 GB dla.

Ten interfejs API wymaga identyfikowania plików za pomocą skrótu SHA256. Zanim więc wywołasz interfejs API, musisz najpierw obliczyć skrót każdego pliku statycznego, kompresując pliki za pomocą gzip, a następnie obliczając skrót SHA256 każdego nowo skompresowanego pliku.

Kontynuując nasz przykład, załóżmy, że chcesz wdrożyć w nowej wersji 3 pliki: file1, file2 i file3.

  1. Skompresuj pliki za pomocą gzip:

    gzip file1 && gzip file2 && gzip file3

    Masz teraz 3 skompresowane pliki: file1.gz, file2.gz i file3.gz.

  2. Pobierz skrót SHA256 każdego skompresowanego pliku:

    cat file1.gz | openssl dgst -sha256

66d61f86bb684d0e35f94461c1f9cf4f07a4bb3407bfbd80e518bd44368ff8f4

    cat file2.gz | openssl dgst -sha256

490423ebae5dcd6c2df695aea79f1f80555c62e535a2808c8115a6714863d083

    cat file3.gz | openssl dgst -sha256

59cae17473d7dd339fe714f4c6c514ab4470757a4fe616dfdb4d81400addf315

    Masz teraz 3 skróty SHA256 3 skompresowanych plików.

  3. Wyślij te 3 skróty w żądaniu do interfejsu API do versions.populateFiles punktu końcowego. Wymień każdy skrót według żądanej ścieżki przesłanego pliku (w tym przykładzie /file1, /file2, i /file3).

    Przykład:

    Polecenie 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

    Surowe żądanie 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"
  }
}

To wywołanie interfejsu API do versions.populateFiles zwraca ten kod JSON:

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

Ta odpowiedź zawiera:

  • Skrót każdego pliku , który trzeba przesłać. Na przykład w tym przykładzie plik file1 został już przesłany w poprzedniej wersji, więc jego skrót nie jest uwzględniony na liście uploadRequiredHashes.

  • uploadUrl, który jest specyficzny dla nowej wersji.

W następnym kroku, aby przesłać 2 nowe pliki, będziesz potrzebować skrótów i uploadURL z odpowiedzi versions.populateFiles.

Krok 5. Prześlij wymagane pliki

Musisz przesłać osobno każdy wymagany plik (czyli te pliki, które są wymienione w uploadRequiredHashes z odpowiedzi versions.populateFiles w poprzednim kroku). Do tych przesłań plików będziesz potrzebować skrótów plików i uploadUrl z poprzedniego kroku.

  1. Dołącz ukośnik i skrót pliku do uploadUrl, aby utworzyć adres URL specyficzny dla pliku w formacie: https://upload-firebasehosting.googleapis.com/upload/sites/SITE_ID/versions/VERSION_ID/files/FILE_HASH.

  2. Prześlij wszystkie wymagane pliki jeden po drugim (w tym przykładzie tylko file2.gz i file3.gz) do adresu URL specyficznego dla pliku za pomocą serii żądań.

    Aby na przykład przesłać skompresowany plik file2.gz:

    Polecenie 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

    Surowe żądanie 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

Pomyślne przesłania zwracają odpowiedź HTTPS 200 OK.

Krok 6. Zaktualizuj stan wersji na FINALIZED

Po przesłaniu wszystkich plików wymienionych w odpowiedzi versions.populateFiles możesz zaktualizować stan wersji na FINALIZED.

Wywołaj punkt końcowy versions.patch z polem status w żądaniu do interfejsu API ustawionym na FINALIZED.

Przykład:

Polecenie 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

Surowe żądanie 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"}

To wywołanie interfejsu API do versions.patch zwraca ten kod JSON. Sprawdź, czy status został zaktualizowany do 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"
}

Krok 7. Udostępnij wersję do wdrożenia

Teraz, gdy masz już sfinalizowaną wersję, udostępnij ją do wdrożenia. W tym kroku, musisz utworzyć Release swojej wersji zawierającą konfigurację hostingu i wszystkie pliki treści nowej wersji.

Aby utworzyć wersję, wywołaj punkt końcowy releases.create.

Przykład:

Polecenie 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

Surowe żądanie 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

To wywołanie interfejsu API do releases.create zwraca ten kod 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"
}

Konfiguracja hostingu i wszystkie pliki nowej wersji powinny być teraz wdrożone w witrynie. Możesz uzyskać dostęp do plików za pomocą tych adresów URL:

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

Te pliki są też dostępne pod adresami URL powiązanymi z domeną SITE_ID.firebaseapp.com.

Nową wersję możesz też zobaczyć na liście w Hosting panelu w Firebase konsoli.