Wdróż podstawową wersję Tłumacza Google Aplikacja Express.js w App Engine, Cloud Functions i Cloud Run

1. Przegląd

Ta seria ćwiczeń z programowania (samodzielnych samouczków praktycznych) ma pomóc deweloperom w poznaniu różnych opcji wdrażania aplikacji. Dowiesz się, jak korzystać z interfejsu Google Cloud Translation API w prostej aplikacji internetowej. Aplikację można uruchomić lokalnie lub wdrożyć na bezserwerowej platformie obliczeniowej w chmurze (App Engine, Cloud Functions lub Cloud Run).

W tym samouczku dotyczącym JavaScriptu użyjesz Node.js z platformą internetową Express.js. Dowiesz się też, jak uzyskiwać dostęp do interfejsów Google Cloud API z poziomu naszych platform bezserwerowych. Wszystkie wersje tej aplikacji pochodzą z repozytorium open source „nebulous serverless”, które zawiera wersję tej aplikacji w języku Python i niezależne ćwiczenia z programowania. W repozytorium znajdują się też podobne aplikacje, które pokazują programistom, jak uzyskiwać dostęp do interfejsów API Google spoza chmury z naszych platform bezserwerowych.

Ten przewodnik skupia się na wdrażaniu tej aplikacji na wytłuszczonych platformach wymienionych powyżej.

Dowiesz się, jak:

korzystać z interfejsów Google Cloud API, w szczególności z Cloud Translation API (zaawansowanego/wersji 3);
Uruchamianie podstawowej aplikacji internetowej lokalnie lub wdrażanie jej na bezserwerowej platformie obliczeniowej w chmurze

Czego potrzebujesz

projekt Google Cloud z aktywnym kontem rozliczeniowym Cloud;
Zainstalowana platforma internetowa do uruchamiania lokalnego ( Flask w przypadku osób korzystających z samouczka dotyczącego języka Python lub Express w przypadku osób korzystających z samouczka dotyczącego języka JavaScript/Node.js).
Co najmniej 1 bezserwerowa platforma obliczeniowa włączona na potrzeby wdrożeń w Google Cloud
podstawowe umiejętności programowania (Python lub JavaScript/Node.js),
Praktyczna znajomość podstawowych poleceń systemu operacyjnego

Ankieta

Jak zamierzasz korzystać z tego samouczka?

Przeczytaj i wykonaj ćwiczenia

Przeczytaj

Jak oceniasz swoje doświadczenie w programowaniu w języku Python lub Node.js?

Początkujący

Średnio zaawansowany

Zaawansowany

Jak oceniasz korzystanie z usług Google Cloud?

Początkujący

Średnio zaawansowany

Zaawansowany

2. Konfiguracja i wymagania

Samodzielne konfigurowanie środowiska

Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub użyj istniejącego. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.

Nazwa projektu to wyświetlana nazwa uczestników tego projektu. Jest to ciąg znaków, który nie jest używany przez interfejsy API Google. Możesz go w dowolnym momencie zaktualizować.
Identyfikator projektu musi być unikalny we wszystkich projektach Google Cloud i jest niezmienny (nie można go zmienić po ustawieniu). Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się nim przejmować. W większości modułów z kodem musisz odwoływać się do identyfikatora projektu (zwykle oznaczanego jako PROJECT_ID). Jeśli Ci się nie podoba, wygeneruj inny losowy identyfikator lub spróbuj użyć własnego i sprawdź, czy jest dostępny. Po utworzeniu projektu jest on „zamrażany”.
Istnieje też trzecia wartość, czyli numer projektu, którego używają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.

Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Ukończenie tego laboratorium nie powinno wiązać się z dużymi kosztami, a nawet z żadnymi. Aby wyłączyć zasoby i uniknąć naliczenia opłat po zakończeniu tego samouczka, postępuj zgodnie z instrukcjami „czyszczenia” na końcu ćwiczenia. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.

3. Włączanie interfejsu Translation API

Z tej sekcji dowiesz się, jak włączyć interfejsy API Google. W przypadku naszej przykładowej aplikacji włączysz Cloud Translation API. Włączysz też App Engine, Cloud Functions lub Cloud Run (oraz Cloud Artifact Registry) w zależności od tego, na których platformach chcesz wdrożyć przykładową aplikację.

Włączanie interfejsów API Google

Wprowadzenie

Niezależnie od tego, którego interfejsu Google API chcesz używać w swojej aplikacji, musi on być włączony. Interfejsy API można włączyć w wierszu poleceń lub w konsoli Cloud. Proces włączania interfejsów API jest identyczny, więc po włączeniu jednego interfejsu API możesz włączyć kolejny w ten sam sposób.

Opcja 1: `gcloud` interfejs wiersza poleceń (Cloud Shell lub środowisko lokalne)

Włączanie interfejsów API w konsoli Cloud jest bardziej powszechne, ale niektórzy programiści wolą wykonywać wszystkie czynności w wierszu poleceń. Aby to zrobić, musisz wyszukać „nazwę usługi” interfejsu API. Wygląda na adres URL: SERVICE_NAME.googleapis.com. Znajdziesz je w tabeli obsługiwanych usług lub możesz wysłać do nich zapytanie programowe za pomocą interfejsu Google Discovery API.

Mając te informacje, możesz włączyć interfejs API za pomocą Cloud Shell (lub lokalnego środowiska programistycznego z zainstalowanym gcloud narzędziem wiersza poleceń):

gcloud services enable SERVICE_NAME.googleapis.com

Przykład 1. Włączanie interfejsu Cloud Vision API

gcloud services enable vision.googleapis.com

Przykład 2. Włączanie Google App Engine

gcloud services enable appengine.googleapis.com

Przykład 3. Włączanie wielu interfejsów API za pomocą jednego żądania. Jeśli na przykład w tym module z kodem uczestnicy wdrażają aplikację korzystającą z interfejsu Cloud Translation API w usługach App Engine, Cloud Functions i Cloud Run, wiersz poleceń będzie wyglądać tak:

gcloud services enable appengine.googleapis.com cloudfunctions.googleapis.com artifactregistry.googleapis.com run.googleapis.com translate.googleapis.com

To polecenie włącza App Engine, Cloud Functions, Cloud Run i Cloud Translation API. Umożliwia też korzystanie z Cloud Artifact Registry, ponieważ to w nim system Cloud Build musi rejestrować obrazy kontenerów, aby można było je wdrożyć w Cloud Run.

Opcja 2. Cloud Console

Interfejsy API Google możesz też włączyć w Menedżerze interfejsów API. W konsoli Cloud otwórz Menedżera interfejsów API i wybierz Biblioteka.

Zacznij wpisywać nazwę interfejsu API w pasku wyszukiwania, aby wyświetlić pasujące wyniki:

Wybierz interfejs API, który chcesz włączyć, i kliknij przycisk Włącz:

Proces włączania wszystkich interfejsów API jest podobny niezależnie od tego, którego interfejsu Google API chcesz używać.

Koszt

Wiele interfejsów API Google można używać bez opłat, ale korzystanie z większości usług i interfejsów API Google Cloud wiąże się z kosztami. Podczas włączania interfejsów API Google Cloud możesz zostać poproszony(-a) o podanie aktywnego konta rozliczeniowego. Niektóre usługi Google Cloud mają jednak poziom „Zawsze bezpłatny”, który musisz przekroczyć, aby ponieść opłaty.

Nowi użytkownicy GCP mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD na pierwsze 90 dni. Codelaby zwykle nie generują dużych kosztów lub nie generują ich wcale, dlatego sugerujemy, aby nie korzystać z bezpłatnego okresu próbnego, dopóki nie będziesz gotowy(-a) na jego wypróbowanie. Jest to oferta jednorazowa. Limity na poziomie bezpłatnym nie wygasają i obowiązują niezależnie od tego, czy korzystasz z bezpłatnego okresu próbnego.

Przed włączeniem dowolnego interfejsu API użytkownicy powinni zapoznać się z informacjami o cenach (np. na stronie cennika Cloud Vision API ), zwracając szczególną uwagę na to, czy jest on dostępny w ramach bezpłatnego limitu, a jeśli tak, to jaki jest ten limit. Jeśli nie przekroczysz określonych dziennych lub miesięcznych limitów, nie poniesiesz żadnych opłat. Ceny i bezpłatne poziomy różnią się w zależności od interfejsów API grup produktów Google. Przykłady:

Google Cloud/GCP – każda usługa jest rozliczana inaczej, zwykle w modelu płatności za wykorzystanie. Informacje o poziomie bezpłatnym znajdziesz powyżej.
Mapy Google – obejmują zestaw interfejsów API i oferują użytkownikom bezpłatne środki o wartości 200 USD miesięcznie.
Interfejsy API Google Workspace (wcześniej G Suite) – zapewniają wykorzystanie (do określonych limitów) objęte miesięczną opłatą za subskrypcję Workspace, więc nie ma bezpośrednich opłat za korzystanie z interfejsów API w aplikacjach takich jak Gmail, Dysk Google, Kalendarz, Dokumenty, Arkusze czy Prezentacje.

Różne usługi Google są rozliczane w różny sposób, dlatego zapoznaj się z odpowiednią dokumentacją, aby uzyskać te informacje.

Sprawdzanie, czy wybrane usługi są włączone

Sprawdź, czy interfejs Cloud Translation API jest włączony w Menedżerze interfejsów API, zgodnie z powyższymi instrukcjami. Jeśli nie włączysz platform bezserwerowych z wiersza poleceń, możesz to zrobić na poszczególnych panelach w konsoli Google Cloud: App Engine, Cloud Functions i Cloud Run.

Włączanie interfejsów API w konsoli Cloud jest przydatne, ale szybsze jest użycie narzędzia gcloud, które włącza wszystkie usługi w kilka sekund:

$ gcloud services enable appengine.googleapis.com \
cloudfunctions.googleapis.com artifactregistry.googleapis.com \
run.googleapis.com translate.googleapis.com
Operation "operations/acf.p2-xxxxxx035451-704918f2-5470-4436-9bdd-c3b204yyyyyy" finished successfully.

Więcej informacji o kosztach

Sekcja powyżej dotycząca kosztów ma charakter ogólny i odnosi się do wszystkich interfejsów API Google. W tym samouczku omówimy więcej szczegółów. Chociaż miesięczny limit nie jest wymieniony na stronie podsumowania ogólnego poziomu „Zawsze bezpłatnie”, na stronie z cennikiem interfejsu Translation API jest podana stała miesięczna liczba przetłumaczonych znaków, którą otrzymują wszyscy użytkownicy. Jeśli nie przekroczysz tego progu, nie zostaną naliczone żadne opłaty za korzystanie z interfejsu API. Więcej informacji o kosztach korzystania z bezserwerowych platform Google Cloud znajdziesz w sekcji Koszty w repozytorium. W sekcji „Sprzątanie” na końcu znajdziesz informacje o tym, jak uniknąć naliczania opłat po zakończeniu tego modułu.

4. Pobieranie kodu przykładowej aplikacji

Pobierz plik ZIP lub sklonuj repozytorium

Pobierz plik ZIP lub skopiuj repozytorium za pomocą polecenia git clone https://github.com/googlecodelabs/cloud-nebulous-serverless.git.
Jeśli nie masz lokalnego środowiska deweloperskiego i chcesz wykonać ten samouczek w Cloud Shell, możesz sklonować repozytorium za pomocą tego samego polecenia git clone.
Możesz też otworzyć plik ZIP, klikając zielony przycisk Code (Kod), jak pokazano na tym zrzucie ekranu:

Teraz, gdy masz już wszystko, utwórz pełną kopię folderu, aby wykonać ten samouczek, ponieważ prawdopodobnie będziesz usuwać lub zmieniać pliki. Jeśli chcesz przeprowadzić inne wdrożenie, możesz zacząć od skopiowania oryginału, aby nie musieć go ponownie klonować ani pobierać.

5. Potwierdzanie środowiska Node.js

Aby skonfigurować środowisko Node.js:

Sprawdź, czy masz zainstalowane aktualne wersje Node (>=10) i NPM (>=6).
Otwórz miejsce, w którym sklonowano repozytorium (lub rozpakowano plik ZIP), a następnie przejdź do folderu cloud/nodejs.
Sprawdź, czy występuje package.json, a następnie uruchom npm install.

W przypadku punktu 1 powyżej możesz sprawdzić, jakie wersje masz w wierszu poleceń:

$ node -v
v17.0.1
$ npm -v
8.1.0

6. Prezentacja przykładowej aplikacji

Przykładowa aplikacja to prosta pochodna Tłumacza Google, która prosi użytkowników o wpisanie tekstu w języku angielskim i wyświetla jego odpowiednik w języku hiszpańskim.

Plik konfiguracji package.json określa, które pakiety innych firm są wymagane w przypadku aplikacji (pamiętaj, że wersje pakietów mogą być aktualizowane poza te wymienione poniżej):

{
  "name": "cloud-nebulous-serverless-nodejs",
  "version": "0.0.1",
  "description": "Nebulous Serverless sample app",
  "main": "index.js",
  "scripts": {
    "start": "node index.js",
    "test": "mocha test/test_neb.js"
  },
  "author": "Google LLC",
  "license": "Apache-2.0",
  "dependencies": {
    "@google-cloud/translate": "^6.3.1",
    "express": "^4.17.1",
    "nunjucks": "^3.2.3"
  },
  "devDependencies": {
    "mocha": "^9.1.3",
    "supertest": "^6.1.6"
  }
}

Teraz otwórz plik index.js, aby zobaczyć, jak to działa. Po pominięciu wierszy z komentarzami dotyczącymi licencjonowania wygląda to tak:

const express = require('express');
const nunjucks = require('nunjucks');
const {TranslationServiceClient} = require('@google-cloud/translate');

const app = express();
app.use(express.urlencoded({extended: true}));
nunjucks.configure('templates', {autoescape: true, express: app});
const TRANSLATE = new TranslationServiceClient();

const PORT = process.env.PORT || 8080;
const SOURCE = ['en', 'English'];
const TARGET = ['es', 'Spanish'];
let parent;
TRANSLATE.getProjectId().then(result => {
    parent = `projects/${result}`;
});


if (!process.env.FUNCTION_TARGET) {
    app.listen(PORT, () =>
        console.log(`Listening on port ${PORT}`)
    );
}

# . . . [translate() function definition] . . .

app.all('/', translate);
module.exports = {
    app
};

require zapewniają funkcje frameworka i szablonów oraz bibliotekę klienta interfejsu Cloud Translation API.
Zmienne globalne reprezentują aplikację internetową, identyfikator projektu w chmurze, klienta interfejsu Translation API, ścieżkę nadrzędną „location path” dla wywołań interfejsu Translation API oraz języki SOURCE i TARGET. W tym przypadku są to języki angielski (en) i hiszpański (es), ale możesz zmienić te wartości na inne kody języków obsługiwanych przez Cloud Translation API.
Pierwszy element każdej pary (SOURCE i TARGET) to kod języka, a drugi to nazwa języka (używana tylko do wyświetlania, ponieważ nie ma znaczenia dla interfejsu API).
Kilka wierszy u dołu służy do wysyłania wszystkich żądań HTTP do translate(), a następnie do eksportowania obiektu aplikacji app.

W środku funkcji index.js znajduje się najważniejsza część aplikacji, czyli funkcja translate():

async function translate(req, rsp) {
    let text = null;
    let translated = null;
    if (req.method === 'POST') {
        text = req.body.text.trim();
        if (text) {
            const data = {
                contents: [text],
                parent: parent,
                targetLanguageCode: TARGET[0]
            };
            const [response] = await TRANSLATE.translateText(data);
            translated = response.translations[0].translatedText;
        }
    }
    const context = {
        orig:  {text: text, lc: SOURCE},
        trans: {text: translated, lc: TARGET}
    };
    rsp.render('index.html', context);
}

Główna funkcja przetwarza dane wejściowe użytkownika i wywołuje interfejs Translation API, aby wykonać większość pracy. Przyjrzyjmy się temu bliżej:

Zresetuj podstawowe zmienne formularza. Dotyczy to głównie żądań GET, ponieważ żądania POST będą zawierać dane, które je zastąpią.
Jeśli jest to żądanie POST, pobierz tekst do przetłumaczenia, a jeśli nie jest pusty, utwórz strukturę JSON reprezentującą wymagania metadanych interfejsu API. Następnie wywołaj interfejs API usługi.
Nie przekazaliśmy do interfejsu API wartości SOURCE[0] w przypadku konkretnego źródła w języku angielskim. Jeśli pominiesz język źródłowy, poprosisz interfejs API o automatyczne wykrycie języka źródłowego (patrz sourceLanguageCode w dokumentacji).
Niezależnie od tego sformatuj rzeczywiste wyniki (POST) lub brak danych (GET) w kontekście szablonu i wyrenderuj.

Część wizualna aplikacji znajduje się w pliku szablonu index.html. Wyświetla wcześniej przetłumaczone wyniki (w przeciwnym razie jest puste), a następnie formularz z prośbą o przetłumaczenie:

<!doctype html>
<html><head><title>My Google Translate 1990s</title><body>
<style>
body {
  font-family: Verdana, Helvetica, sans-serif;
  background-color: #DDDDDD;
}
</style>
<h2>My Google Translate (1990s edition)</h2>

{% if trans['text'] %}
    <h4>Previous translation</h4>
    <li><b>Original</b>:   {{ orig['text'] }}  (<i>{{ orig['lc'][0] }}</i>)</li>
    <li><b>Translated</b>: {{ trans['text'] }} (<i>{{ trans['lc'][0] }}</i>)</li>
{% endif %}

<h4>Enter <i>{{ orig['lc'][1] }}</i> text to translate to <i>{{ trans['lc'][1] }}</i>:</h4>
<form method="POST"><input name="text"><input type="submit"></form>
</body></html>

W pozostałej części samouczka możesz wybrać dowolną lub wszystkie z 4 opcji wdrażania i uruchamiania tej aplikacji. Wszystkie wdrożenia są opcjonalne, co oznacza, że możesz wykonać dowolne z nich lub wszystkie.

Uruchamianie usługi lokalnie
Wdrażanie w App Engine (środowisko standardowe)
Wdrażanie w Cloud Functions
Wdrożenie w Cloud Run

7. OPCJA 1. Uruchom usługę lokalnie

Ta sekcja ćwiczenia jest przeznaczona tylko do uruchamiania lokalnego. Jeśli wdrażasz tylko w chmurze, przejdź do następnej sekcji.

Aby uruchomić przykładową aplikację lokalnie, musisz wykonać 3 kroki:

Tworzenie konta usługi
Tworzenie pary kluczy publicznego i prywatnego konta usługi
Pobierz plik danych logowania i dołącz go do kodu aplikacji
Uruchamianie usługi

Więcej informacji o kontach usługi

Konta usług to mechanizm zabezpieczeń umożliwiający aplikacjom w chmurze dostęp do interfejsów API Google w przypadku danych, które nie należą do użytkowników. Podczas wdrażania w chmurze, aby skrócić czas potrzebny na wprowadzenie użytkowników do chmury, wszystkie platformy obliczeniowe Google Cloud (bezserwerowe i inne) udostępniają domyślne konta usługi.

Domyślne konta usługi mają szeroki zakres uprawnień, aby „przebić się przez biurokrację”, ale gdy przygotowujesz się do uruchomienia usługi produkcyjnej, zdecydowanie zalecamy, aby użytkownicy stosowali sprawdzoną metodę „najmniejszych uprawnień”, tworząc konta usługi zarządzane przez użytkowników z uprawnieniami wystarczającymi do prawidłowego działania aplikacji. W przypadku wdrożeń lokalnych nie ma domyślnych kont usługi, więc musisz utworzyć konto usługi i klucz konta usługi (w rzeczywistości parę kluczy publiczny/prywatny) oraz udostępnić te dane logowania kodowi aplikacji.

Utwórz parę kluczy konta usługi i pobierz plik danych logowania

Aby utworzyć konto usługi i parę kluczy publiczny/prywatny do uruchamiania lokalnego, postępuj zgodnie z instrukcjami na tej stronie. Podczas tworzenia klucza konta usługi pojawi się prośba o podanie odpowiednich uprawnień. Pamiętaj, aby wybrać roles/cloudtranslate.user, aby uzyskać dostęp do interfejsu API.

Po utworzeniu pary kluczy pojawi się prośba o pobranie pliku klucza konta usługi. Nazwij go credentials.json i przenieś do folderu najwyższego poziomu aplikacji. Teraz musisz poinformować (pakiet) SDK Cloud, aby używał tych danych logowania: ustaw zmienną środowiskową GOOGLE_APPLICATION_CREDENTIALS tak, aby wskazywała ten plik. Więcej informacji o tym procesie znajdziesz też na tej stronie dotyczącej korzystania z kont usługi.

Uruchom usługę

Gdy wszystko będzie gotowe, uruchom lokalnie serwer Express za pomocą tego polecenia:

$ npm start

> cloud-nebulous-serverless-nodejs@0.0.1 start
> node index.js

Listening on port 8080

Otwórz przeglądarkę i połącz się z nią pod adresem localhost:8080. Powinien pojawić się mniej więcej taki widok:

Przetłumacz coś, aby zobaczyć, jak to działa.

Gdy będziesz zadowolony z wyniku, zamknij serwer, naciskając ^C (Ctrl+C), i zakończ działanie. Gratulujemy uruchomienia wdrożenia lokalnego. Mamy dobrą wiadomość: wdrażanie w chmurze jest znacznie łatwiejsze.

Rozwiązywanie problemów

Czy podczas przesyłania prośby o tłumaczenie pojawia się taki błąd?

node:fs:2486
      handleErrorFromBinding(ctx);
      ^

Error: The file at credentials.json does not exist, or it is not a file. ENOENT: no such file or directory, lstat '/tmp/nodejs/credentials.json'
    . . .

ROZWIĄZANIE: ten błąd oznacza, że nie udało Ci się utworzyć konta usługi i pobrać pliku pary kluczy publiczny/prywatny credentials.json. Wróć do sekcji „OPCJA 1. Uruchom usługę lokalnie”, wykonaj opisane tam czynności i zainstaluj dane logowania w folderze głównym, zanim przejdziesz dalej.

8. OPCJA 2. Wdrażanie w App Engine (środowisko standardowe)

Ta sekcja laboratorium kodu dotyczy tylko wdrażania w Node App Engine. Jeśli nie jesteś zainteresowany(-a), przejdź do następnej sekcji.

To wdrożenie korzysta z app.yaml pliku konfiguracji, który informuje App Engine, którego środowiska wykonawczego użyć, za pomocą jednego wiersza:

runtime: nodejs16

Plik app.yaml nie jest używany ani przez Cloud Functions, ani przez Cloud Run. Jeśli nie planujesz korzystać z App Engine, możesz bezpiecznie usunąć ten plik. Gdy wszystko będzie gotowe do wdrożenia w App Engine, uruchom to polecenie:

$ gcloud app deploy

Po wybraniu regionu gcloud app deploy będzie znacznie mniej szczegółowy i powinien wyglądać tak:

Services to deploy:

descriptor:                  [/private/tmp/nodejs/app.yaml]
source:                      [/private/tmp/nodejs]
target project:              [PROJECT_ID]
target service:              [default]
target version:              [2021...]
target url:                  [https://PROJECT_ID.REG_ABBR.appspot.com]
target service account:      [App Engine default service account]


Do you want to continue (Y/n)?

Beginning deployment of service [default]...
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 2 files to Google Cloud Storage                          ═╣
╚════════════════════════════════════════════════════════════╝
File upload done.
Updating service [default]...⠏WARNING: *** Improve build performance by generating and committing package-lock.json.

Updating service [default]...done.
Setting traffic split for service [default]...done.
Deployed service [default] to [https://PROJECT_ID.REG_ABBR.appspot.com]

You can stream logs from the command line by running:
  $ gcloud app logs tail -s default

To view your application in the web browser run:
  $ gcloud app browse

To take a quick anonymous survey, run:
  $ gcloud survey

Teraz, gdy Twoja aplikacja jest dostępna na całym świecie, możesz uzyskać do niej dostęp pod adresem URL zawierającym identyfikator projektu. Powinna wyświetlać dane wyjściowe podobne do lokalnej wersji Express, ale pamiętaj, że działa ona w chmurze i jest dostępna na całym świecie:

Jeśli prześlesz prośbę, zobaczysz, że działa ona tak samo jak wszystkie inne wdrożenia.

9. OPCJA 3. Wdrażanie w Cloud Functions

Ta sekcja samouczka jest przeznaczona tylko do wdrażania w funkcjach Cloud Functions w Node. Jeśli nie jesteś zainteresowany(-a), przejdź do następnej sekcji.

W Cloud Functions nie ma plików konfiguracyjnych, więc gdy zechcesz wdrożyć funkcję w Cloud Functions, uruchom to polecenie:

$ gcloud functions deploy translate \
  --runtime nodejs16 \
  --entry-point app \
  --trigger-http \
  --region REGION \
  --allow-unauthenticated

Twój projekt GCP może mieć domyślny region REGION, ale możesz użyć flagi --region, aby wdrożyć funkcję w określonym regionie. Cloud Functions nie wyświetla takich komunikatów jak inne usługi Cloud. Niezależnie od wybranego regionu dane wyjściowe gcloud functions deploy powinny wyglądać tak:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/15ac7fc1-731d-4f3b-bc15-8f2614xxxxxx?project=062269xxxxxx
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: aaf7e0cd-fbbd-4624-abeb-3e7437xxxxxx
buildName: projects/062269xxxxxx/locations/REGION/builds/aaf7e0cd-fbbd-4624-abeb-3e7437xxxxxx
entryPoint: app
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/translate
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/translate
runtime: nodejs16
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/gcf-upload-REGION-01de94c2-6eb4-4c49-aaff-09276cdb7ae9/a1db9f2d-3511-414b-aeeb-de6042xxxxxx.zip
status: ACTIVE
timeout: 60s
updateTime: '2021...'
versionId: '...'

Teraz, gdy aplikacja jest dostępna na całym świecie, możesz uzyskać do niej dostęp pod adresem URL zawierającym identyfikator projektu, jak pokazano w danych wyjściowych wdrożenia (w sekcji „httpsTrigger/url”). Adres URL powinien wyglądać podobnie do tego: https://REGION-PROJECT_ID.cloudfunctions.net/translate. Różni się on w zależności od wybranego regionu i identyfikatora projektu w chmurze.

10. OPCJA 4. Wdrażanie w Cloud Run

Ta sekcja instrukcji dotyczy tylko wdrażania w Cloud Run. Jeśli nie jesteś zainteresowany(-a), przejdź do następnej sekcji.

W Cloud Run nie ma plików konfiguracyjnych, więc gdy będziesz gotowy(-a) do wdrożenia w Cloud Run, postępuj zgodnie z instrukcjami poniżej.

Teraz możesz wdrożyć usługę tłumaczenia w Cloud Run, uruchamiając to polecenie:

$ gcloud run deploy translate --source . --allow-unauthenticated --platform managed

Dane wyjściowe powinny wyglądać tak jak poniżej i zawierać kilka sugestii dotyczących kolejnych kroków:

Please specify a region:
 [1] asia-east1
 [2] asia-east2
. . . (other regions) . . .
 [28] us-west4
 [29] cancel
Please enter your numeric choice:  REGION_CHOICE

To make this the default region, run `gcloud config set run/region REGION`.

Deploying from source requires an Artifact Registry repository to
store build artifacts. A repository named [cloud-run-source-deploy] in
 region [REGION] will be created.

Do you want to continue (Y/n)?

This command is equivalent to running "gcloud builds submit --pack image=[IMAGE] ." and "gcloud run deploy translate --image [IMAGE]"

Building . . . and deploying container to Cloud Run service [translate] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Creating Container Repository...
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/60e1b
  9bb-b991-4b4e-8d8a-HASH?project=PROJECT_NUMBER].
  ✓ Creating Revision...
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [translate] revision [translate-00001-xyz] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

Cloud Buildpacks wdraża aplikacje w Cloud Run w podobny sposób jak w przypadku uruchamiania aplikacji lokalnie. W przypadku użytkowników Node.js uruchamia npm install i npm start. W przypadku Pythona uruchamia polecenie pip install -r requirements.txt i rozpoczyna działanie aplikacji zgodnie z instrukcjami w pliku Procfile. (To samo dotyczy wszystkich innych języków obsługiwanych przez pakiety Cloud Buildpack). Po zakończeniu procesu kompilacji aplikacja będzie gotowa do użycia.

Aplikacja jest wtedy (wdrażana regionalnie, ale) dostępna globalnie i można ją otworzyć pod adresem URL zawierającym identyfikator projektu, jak pokazano w danych wyjściowych wdrożenia (w sekcji „Service URL:”).

Przetłumacz coś, aby zobaczyć, jak to działa.

11. Podsumowanie

Gratulacje! Dowiedzieliśmy się, jak włączyć i używać interfejsu Cloud Translation API, uzyskać niezbędne dane logowania oraz wdrożyć prostą aplikację internetową w Express lokalnie, w App Engine, Cloud Functions lub Cloud Run. Więcej informacji znajdziesz w folderze repozytorium. Znajdziesz tam też inne wersje tej aplikacji i inne ćwiczenia z programowania.

Czyszczenie danych

Interfejs Cloud Translation API umożliwia bezpłatne przetłumaczenie określonej liczby znaków miesięcznie. App Engine ma też bezpłatny limit, podobnie jak Cloud Functions i Cloud Run. Jeśli przekroczysz którykolwiek z tych limitów, zostaną naliczone opłaty. Jeśli planujesz przejść do następnych ćwiczeń, nie musisz zamykać aplikacji.

Jeśli nie chcesz jeszcze przechodzić do następnego samouczka lub obawiasz się, że internet odkryje właśnie wdrożoną aplikację, wyłącz aplikację App Engine, usuń funkcję w Cloud Functions lub wyłącz usługę Cloud Run, aby uniknąć naliczania opłat. Gdy zechcesz przejść do kolejnych ćwiczeń, możesz ponownie włączyć tę funkcję. Jeśli nie zamierzasz kontynuować pracy nad tą aplikacją ani innymi Codelabs i chcesz wszystko całkowicie usunąć, możesz wyłączyć projekt.

Wdrażanie na bezserwerowej platformie obliczeniowej Google Cloud wiąże się też z niewielkimi kosztami kompilacji i przechowywania. Cloud Build ma własny bezpłatny limit, podobnie jak Cloud Storage. Aby zapewnić większą przejrzystość, Cloud Build kompiluje obraz aplikacji, który jest następnie przechowywany w Cloud Container Registry lub w Artifact Registry, czyli w usłudze, która ją zastąpiła. Przechowywanie tego obrazu wykorzystuje część tego limitu, podobnie jak ruch wychodzący w sieci podczas przesyłania obrazu do usługi. Możesz jednak mieszkać w regionie, w którym nie ma takiego bezpłatnego pakietu, więc kontroluj wykorzystanie miejsca na dane, aby zminimalizować potencjalne koszty.

12. Dodatkowe materiały

W kolejnych sekcjach znajdziesz dodatkowe materiały do czytania oraz zalecane ćwiczenia, które pomogą Ci poszerzyć wiedzę zdobytą podczas tego samouczka.

Dodatkowe materiały

Masz już pewne doświadczenie w korzystaniu z interfejsu Translation API, więc wykonajmy kilka dodatkowych ćwiczeń, aby jeszcze bardziej rozwinąć Twoje umiejętności. Aby kontynuować ścieżkę szkoleniową, zmodyfikuj naszą przykładową aplikację w ten sposób:

Wykonaj wszystkie pozostałe wersje tego laboratorium, aby uruchomić je lokalnie lub wdrożyć na bezserwerowych platformach obliczeniowych Google Cloud (patrz plik README repozytorium).
Ukończ ten samouczek, korzystając z innego języka programowania.
Zmień tę aplikację, aby obsługiwała inne języki źródłowe lub docelowe.
Uaktualnij tę aplikację, aby można było tłumaczyć tekst na więcej niż 1 język. Zmień plik szablonu, aby zawierał menu obsługiwanych języków docelowych.

Więcej informacji

Google App Engine

Google Cloud Functions

Google Cloud Run

Google Cloud Buildpacks, Container Registry, Artifact Registry

Google Cloud Translation i Google ML Kit

Inne usługi i strony Google Cloud

Linki do Pythona

Linki do Node.js

Licencja

Ten samouczek jest licencjonowany na podstawie ogólnej licencji Creative Commons Uznanie autorstwa 2.0, a kod źródłowy w repozytorium jest licencjonowany na podstawie licencji Apache 2.