Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Prywatny dostęp Cloud Run do globalnego i regionalnego punktu końcowego Cloud Storage

1. Wprowadzenie

Punkt końcowy API Google

Interfejsy Google Cloud API oferują różne typy punktów końcowych dostępu do usług, które różnią się głównie sposobem obsługi routingu żądań, rezydencji danych i izolacji regionalnej.

Zapoznaj się z dokumentacją produktu dotyczącą typów punktów końcowych API.

Oto zestawienie punktów końcowych globalnych, regionalnych i lokalnych:

Globalne punkty końcowe

Format: {service}.googleapis.com (np. storage.googleapis.com)
Opis: te punkty końcowe zapewniają pojedynczy, globalny punkt dostępu do usługi. Nie określają regionu w adresie URL.
Routing: żądania są kierowane przez globalne interfejsy Google Front End (GFE) i globalne równoważenie obciążenia usług, które zwykle kierują ruch do najbliższego regionu w dobrym stanie, aby zminimalizować opóźnienia.
Zakończenie TLS: następuje w GFE najbliższym klientowi, który może znajdować się poza regionem Google Cloud, w którym znajdują się dane lub zasoby.
Miejsce przechowywania danych: brak gwarancji w przypadku danych w ruchu. Po odszyfrowaniu w GFE dane mogą przekraczać granice regionów.
Izolacja regionalna: ograniczona. Chociaż backendy są często regionalne, punkt wejścia i równoważenie obciążenia mają charakter globalny, co oznacza, że problemy w jednej części infrastruktury globalnej mogą potencjalnie wpływać na usługi w innych regionach.
Przypadek użycia: dostęp do zwykłych obciążeń, w którym kluczowe jest małe opóźnienie dla użytkowników rozproszonych geograficznie, a ścisłe przechowywanie danych podczas przesyłania nie jest głównym problemem.

Regional Endpoints (REP)

Format: {service}.{location}.rep.googleapis.com (np. storage.us-east1.rep.googleapis.com)
Opis: te strefy zostały zaprojektowane tak, aby zapewniać silną izolację regionalną i gwarancje dotyczące przechowywania danych. Lokalizacja (określony region Google Cloud) jest podana jako subdomena. Jest to nowoczesny standard, który zastępuje lokalizacyjne punkty końcowe.
Routing: korzysta z całkowicie zregionalizowanej platformy frontendowej, w tym z regionalnych zewnętrznych systemów równoważenia obciążenia i regionalnego systemu równoważenia obciążenia usługi . Cała ścieżka żądania, od DNS do backendu usługi, pozostaje w określonym regionie.
Zakończenie TLS: następuje w określonym regionie w przypadku regionalnych zewnętrznych systemów równoważenia obciążenia.
Miejsce przechowywania danych: gwarantuje, że dane pozostaną w wyznaczonym regionie zarówno podczas przesyłania, jak i używania, co spełnia surowe wymagania dotyczące zgodności i suwerenności.
Izolacja regionalna: silna. Awarie infrastruktury frontendu w jednym regionie nie mają wpływu na inne regiony.
Przypadek użycia: aplikacje wymagające ścisłego miejsca przechowywania danych, wysokiego poziomu izolacji regionalnej i zgodności.

Pamiętaj, że nie każdy interfejs API Google ma regionalny punkt końcowy. Wszystkie obsługiwane regionalne punkty końcowe znajdziesz tutaj.

Regionalne punkty końcowe obejmujące wiele regionów (mREP) to również regionalne punkty końcowe, takie jak us (Stany Zjednoczone), eu (Unia Europejska) itp. (np.storage.us.rep.googleapis.com).

Punkty końcowe lokalizacji

Format: {location}-{service}.googleapis.com (np. us-east1-storage.googleapis.com)
Opis: te punkty końcowe były wcześniejszym sposobem zapewniania dostępu do danych dotyczących konkretnych lokalizacji. Lokalizacja jest częścią głównej nazwy hosta. Uwaga: punkty końcowe oparte na lokalizacji są zastępowane przez punkty końcowe oparte na regionie.
Routing: nadal korzysta z globalnych interfejsów Google.
Zakończenie TLS: zwykle następuje w GFE, które może nie znajdować się w regionie określonym w nazwie hosta.
Lokalizacja danych: nie możemy zagwarantować, że dane pozostaną w określonym regionie podczas przesyłania ruchu z internetu publicznego.
Izolacja regionalna: słabsza niż w przypadku regionalnych punktów końcowych, ponieważ korzysta z globalnej infrastruktury interfejsu.
Przypadek użycia: w przeszłości używane w niektórych scenariuszach dostępu regionalnego, ale obecnie odradzane na rzecz regionalnych punktów końcowych, które zapewniają większą gwarancję.

Private Service Connect dla interfejsu API Google

Private Service Connect to funkcja sieci Google Cloud, która umożliwia konsumentom dostęp do usług producenta. Obejmuje to możliwość łączenia się z interfejsami API Google za pomocą prywatnego punktu końcowego hostowanego w sieci VPC użytkownika.

Jak używać punktu końcowego PSC do uzyskiwania dostępu do interfejsu API Google:

Punkt końcowy PSC dla globalnego interfejsu API Google
Punkt końcowy PSC dla regionalnego interfejsu API Google
Używasz punktu końcowego PSC dla globalnego interfejsu API Google, aby prywatnie uzyskiwać dostęp do interfejsu API Google związanego z lokalizacją.

Jak używać backendu PSC do uzyskiwania dostępu do interfejsu API Google:

Backend PSC dla globalnego interfejsu API Google
Backend PSC dla regionalnego interfejsu API Google
Backendu PSC używasz w przypadku globalnego interfejsu API Google, aby mieć prywatny dostęp do interfejsu API Google opartego na lokalizacji.

Cloud Run wysyła ruch do sieci VPC

Bezpośredni ruch wychodzący VPC zapewnia ulepszoną infrastrukturę i prostszą konfigurację ruchu wychodzącego VPC w Cloud Run, w tym następujące zalety:

Konfiguracja: usługi i zadania Cloud Run mogą wysyłać ruch do sieci VPC bez konieczności zarządzania oprogramowaniem sprzęgającym bezserwerowego dostępu do VPC.
Koszt: płacisz tylko za ruch w sieci, a opłaty są skalowane do zera, tak jak sama usługa.
Bezpieczeństwo: możesz używać tagów sieci bezpośrednio w wersjach usługi, aby uzyskać bardziej szczegółowe zabezpieczenia sieci.
Wydajność: mniejsze opóźnienia, większa przepustowość.

Możesz włączyć wysyłanie całego ruchu do sieci VPC przez usługę, funkcję, zadanie lub pulę pracowników Cloud Run za pomocą bezpośredniego ruchu wychodzącego VPC.

2. Czego się nauczysz

Jak utworzyć punkt końcowy PSC dla globalnego interfejsu API Google.
Jak utworzyć punkt końcowy PSC dla regionalnego interfejsu API Google.
Jak zmienić punkt końcowy interfejsu API w kodzie Cloud Run i skonfigurować sieć na potrzeby ruchu wychodzącego.

3. Ogólna architektura modułu

4. Kroki przygotowawcze

Role uprawnień wymagane do pracy w laboratorium

Zacznij od przypisania wymaganych ról uprawnień do konta GCP na poziomie projektu.

Administrator sieci Compute (roles/compute.networkAdmin) Ta rola zapewnia pełną kontrolę nad zasobami sieciowymi Compute Engine.
Administrator logowania (roles/logging.admin) Ta rola daje dostęp do wszystkich uprawnień związanych z logowaniem i uprawnień zależnych.
Administrator wykorzystania usług (roles/serviceusage.serviceUsageAdmin) – ta rola umożliwia włączanie, wyłączanie i sprawdzanie stanu usług, sprawdzanie operacji, a także zużywanie limitu i płatnych usług w ramach projektu konsumenta.
Administrator DNS (roles/dns.admin) Ta rola zapewnia dostęp do odczytu i zapisu wszystkich zasobów Cloud DNS.
Administrator Cloud Run (roles/run.admin) – ta rola zapewnia pełną kontrolę nad wszystkimi zasobami Cloud Run.
Administrator pamięci masowej (roles/storage.admin) – ta rola zapewnia pełną kontrolę nad obiektami i zasobnikami.

Włącz interfejsy API

W Cloud Shell sprawdź, czy projekt jest prawidłowo skonfigurowany, i ustaw zmienne środowiskowe.

W Cloud Shell wykonaj te czynności:

gcloud auth login
gcloud config set project <your project id>
export project_id=<your project id>
export region=<your region>
export zone=$region-a
echo $project_id
echo $region

Włącz w projekcie wszystkie niezbędne interfejsy API Google. W Cloud Shell wykonaj te czynności:

gcloud services enable \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  run.googleapis.com \
  compute.googleapis.com \
  dns.googleapis.com \
  servicedirectory.googleapis.com \
  networkconnectivity.googleapis.com

Utwórz VPC

W projekcie utwórz sieć VPC w trybie podsieci niestandardowej. W Cloud Shell wykonaj te czynności:

gcloud compute networks create mynet \
    --subnet-mode=custom

Tworzenie podsieci

W Cloud Shell wykonaj te czynności, aby utworzyć podsieć IPv4:

gcloud compute networks subnets create mysubnet \
    --network=mynet \
    --range=10.0.0.0/24 \
    --region=$region

Tworzenie Cloud NAT i routera Cloud Router

Cloud NAT umożliwia łączenie się zadań Cloud Run z zewnętrznymi witrynami.

gcloud compute routers create $region-cr \
   --network=mynet \
   --region=$region 
gcloud compute routers nats create $region-nat \
    --router=$region-cr \
    --region=$region \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

5. Tworzenie punktu końcowego PSC dla Cloud Storage

Utworzysz 2 punkty końcowe PSC dla Cloud Storage: jeden o zakresie globalnym, a drugi o zakresie regionalnym.

Tworzenie punktu końcowego PSC o zakresie globalnym

Dzięki Private Service Connect możesz tworzyć prywatne punkty końcowe o zasięgu globalnym, używając globalnych wewnętrznych adresów IP w sieci VPC.

Musisz przydzielić unikalny adres IP, który nie jest zdefiniowany w Twojej sieci VPC. Więcej informacji znajdziesz w dokumencie dotyczącym wymagań dotyczących adresu IP.

Aby utworzyć adres IP w Cloud Shell, wykonaj te czynności: Zmień wartość –addresses=<pscendpointip>, aby używać przydzielonego adresu IP.

gcloud compute addresses create pscglobalip \
    --global \
    --purpose=PRIVATE_SERVICE_CONNECT \
    --addresses=<pscendpointip> \
    --network=mynet
pscendpointip=$(gcloud compute addresses list --filter=name:pscglobalip --format="value(address)")
echo $pscendpointip

Utwórz regułę przekierowania, aby połączyć punkt końcowy z interfejsami API Google i usługami.

gcloud compute forwarding-rules create pscendpoint \
    --global \
    --network=mynet \
    --address=pscglobalip \
    --target-google-apis-bundle=all-apis

Sprawdzanie p.googleapis.com w Cloud DNS

Gdy tworzysz punkt końcowy, automatycznie tworzone są te konfiguracje DNS:

Dla p.googleapis.com tworzona jest prywatna strefa DNS Service Directory.
Rekordy DNS są tworzone w domenie p.googleapis.com w przypadku niektórych powszechnie używanych interfejsów API i usług Google, które są dostępne za pomocą usługi Private Service Connect i mają domyślne nazwy DNS kończące się na googleapis.com.

Globalne punkty końcowe są zarejestrowane w katalogu usług. Aby uzyskać dostęp do Cloud Storage, użyjesz adresu storage-[nazwa punktu końcowego PSC].p.googleapis.com. Szczegółowe informacje znajdziesz w dokumentacji produktu.

Sprawdź, czy strefa p.googleaps.com jest już utworzona. W tym celu uruchom to polecenie:

gcloud dns managed-zones list

Jeśli chcesz używać domyślnej nazwy DNS, storage.googleapis.com, utwórz w Cloud DNS prywatną strefę storage.googleapis.com i dodaj rekord wierzchołka, który wskazuje punkt końcowy PSC globalnego adresu IP.

Tworzenie punktu końcowego PSC o zasięgu regionalnym dla Cloud Storage

Potrzebujesz 1 adresu IP z podsieci VPC. Uruchom to polecenie. Adres IP z podsieci zostanie przydzielony do punktu końcowego PSC.

gcloud network-connectivity regional-endpoints create psc-regional-endpoint \
    --region=$region \
    --network=projects/$project_id/global/networks/mynet \
    --subnetwork=projects/$project_id/regions/$region/subnetworks/mysubnet \
    --target-google-api=storage.us-central1.rep.googleapis.com

Uzyskaj adres IP punktu końcowego utworzonego w poprzednim kroku.

regionalip=$(gcloud network-connectivity regional-endpoints describe psc-regional-endpoint --region=$region --format="value(address)")
echo $regionalip

Do uzyskiwania dostępu do Cloud Storage będziesz używać adresu storage.us-central1.rep.googleapis.com. Musisz utworzyć strefę prywatną dla storage.us-central1.rep.googleapis.com i rekord główny adresu IP, który został utworzony dla regionalnego punktu końcowego w Cloud DNS.

Tworzenie strefy prywatnej dla regionalnego punktu końcowego Cloud Storage

Aby uzyskać dostęp do regionalnego punktu końcowego Cloud Storage, użyj storage.[nazwa regionu].rep.googleapis.com.

Musisz utworzyć strefę prywatną w Cloud DNS i dodać rekord wierzchołka, który będzie wskazywał adres IP regionalnego punktu końcowego Cloud Storage.

W poniższym poleceniu us-central1 to przykładowy region. Utwórz strefę o nazwie regionu.

gcloud dns managed-zones create psc-regional-endpoint-zone \
  --description="" \
  --dns-name="storage.us-central1.rep.googleapis.com" \
  --visibility="private" \
  --networks="mynet"

gcloud dns record-sets create storage.us-central1.rep.googleapis.com. \
  --rrdatas=$regionalip \
  --ttl=300 \
  --type=A \
  --zone=psc-regional-endpoint-zone

6. Konfigurowanie zadania Cloud Run z punktem końcowym PSC o zakresie globalnym

Pobierz kod

Najpierw zapoznasz się z aplikacją Node.js, która robi zrzuty ekranu stron internetowych i zapisuje je w Cloud Storage. Następnie utworzysz obraz kontenera dla aplikacji i uruchomisz go jako zadanie w Cloud Run.

W Cloud Shell uruchom to polecenie, aby sklonować kod aplikacji z tego repozytorium:

git clone https://github.com/GoogleCloudPlatform/jobs-demos.git

Przejdź do katalogu zawierającego aplikację:

cd jobs-demos/screenshot

Plik powinien wyglądać tak:

├── Dockerfile

├── README.md

├── screenshot.js

├── package.json

Oto krótki opis każdego pliku:

Plik screenshot.js zawiera kod aplikacji w Node.js. Aplikacja robi zrzuty ekranu stron internetowych i zapisuje je w Cloud Storage.
Plik package.json określa zależności biblioteki.
Plik Dockerfile definiuje obraz kontenera.

Otwórz kod screenshot.js i zmień apiEndpoint na globalny punkt końcowy PSC. Wyszukaj w kodzie const storage = new Storage(); i zastąp go tymi wartościami:

const storage = new Storage(
    {
      apiEndpoint:'https://storage-pscendpoint.p.googleapis.com.',
      useAuthWithCustomEndpoint: true
    }
  );

Wdrażanie zadania

Zanim utworzysz zadanie, musisz utworzyć konto usługi, którego będziesz używać do jego uruchamiania.

gcloud iam service-accounts create screenshot-sa --display-name="Screenshot app service account"

Przypisz do konta usługi rolę storage.admin, aby można było jej używać do tworzenia zasobników i obiektów.

gcloud projects add-iam-policy-binding $project_id \
  --role roles/storage.admin \
  --member serviceAccount:screenshot-sa@$project_id.iam.gserviceaccount.com

Przyznaj domyślnemu kontu usługi Compute role Użytkownik obiektów Cloud Storage , Zapisujący logi i Administrator repozytorium Artifact Registry.

project_number=$(gcloud projects describe $project_id --format="value(projectNumber)")

gcloud projects add-iam-policy-binding $project_id \
  --role roles/storage.objectUser \
  --member serviceAccount:$project_number-compute@developer.gserviceaccount.com

gcloud projects add-iam-policy-binding $project_id \
  --role roles/logging.logWriter \
  --member serviceAccount:$project_number-compute@developer.gserviceaccount.com

gcloud projects add-iam-policy-binding $project_id \
  --role roles/artifactregistry.repoAdmin \
  --member serviceAccount:$project_number-compute@developer.gserviceaccount.com

Włączysz bezpośredni ruch wychodzący VPC dla zadań Cloud Run, aby wysyłać cały ruch do sieci VPC.

W Cloud Shell wykonaj te czynności:

gcloud run jobs deploy screenshot-1 \
  --source=. \
  --args="https://example.com" \
  --args="https://cloud.google.com" \
  --tasks=2 \
  --task-timeout=5m \
  --region=$region \
  --set-env-vars=BUCKET_NAME=screenshot-$project_id-$RANDOM \
  --service-account=screenshot-sa@$project_id.iam.gserviceaccount.com \
  --vpc-egress=all-traffic \
  --network=mynet \
  --subnet=mysubnet

Uruchamianie zadania

W Cloud Shell wykonaj te czynności:

gcloud run jobs execute screenshot-1 --region=$region

Sprawdź stan zadania i logi. Otwórz konsolę Cloud Run i wyszukaj zadanie. Kliknij zadanie i sprawdź historię logu. Zobaczysz podobny wynik wykonania zadania jak poniżej.

Aby wyświetlić szczegółowe logi wykonania zadania, kliknij Wyświetl log w przypadku zadania. Wyświetlą się podobne logi zadań jak poniżej.

Utworzono nowy zasobnik. Możesz przejść do konsoli Cloud Storage i sprawdzić utworzony zasobnik. Pamiętaj, że gdy używasz globalnego punktu końcowego Cloud Storage, zasobnik jest zasobnikiem obejmującym wiele regionów. Możesz sprawdzić obrazy przesłane do zasobnika.

Wynik testu pokazuje, że Cloud Run uzyskał prywatny dostęp do globalnego punktu końcowego Cloud Storage, który został zmieniony w zadaniu Cloud Run:

apiEndpoint:‘https://storage-pscendpoint.p.googleapis.com.'

7. Konfigurowanie zadania Cloud Run z punktem końcowym PSC o zakresie regionalnym

W kodzie zmienisz apiEndpoint na punkt końcowy PSC o zakresie regionalnym.

Wyszukaj w kodzie i zastąp const storage = new Storage(); tymi wartościami ( jako przykładu używamy us-central1): Zmień na swój region:

const storage = new Storage(
    {
      apiEndpoint:'https://storage.us-central1.rep.googleapis.com.',
      useAuthWithCustomEndpoint: true
    }
  );

Wdrażanie zadania

Sprawdź, czy znajdujesz się w katalogu zawierającym aplikację (jobs-demos/screenshot).

pwd

Włącz wychodzący ruch bezpośredniej sieci VPC w przypadku zadań, aby wysyłać cały ruch do sieci VPC.

W Cloud Shell wykonaj te czynności:

gcloud run jobs deploy screenshot-2 \
  --source=. \
  --args="https://example.com" \
  --args="https://cloud.google.com" \
  --tasks=2 \
  --task-timeout=5m \
  --region=$region \
  --set-env-vars=BUCKET_NAME=screenshot-$PROJECT_ID-$RANDOM \
  --service-account=screenshot-sa@$project_id.iam.gserviceaccount.com \
  --vpc-egress=all-traffic \
  --network=mynet \
  --subnet=mysubnet

Uruchamianie zadania

W Cloud Shell wykonaj te czynności:

gcloud run jobs execute screenshot-2 --region=$region

Sprawdź stan zadania i logi. Otwórz konsolę Cloud Run i wyszukaj zadanie. Kliknij zadanie i sprawdź jego historię. Zobaczysz podobny wynik wykonania zadania jak poniżej.

Aby wyświetlić szczegółowe logi wykonania zadania, kliknij Wyświetl log. Wyświetlą się podobne logi zadań jak poniżej.

Utworzono nowy zasobnik. Możesz przejść do konsoli Cloud Storage i sprawdzić utworzony zasobnik. Pamiętaj, że gdy używasz regionalnego punktu końcowego Cloud Storage, zasobnik jest zasobnikiem w jednym regionie. Możesz sprawdzić obrazy przesłane do zasobnika.

Wynik testu pokazuje, że Cloud Run uzyskał prywatny dostęp do regionalnego punktu końcowego Cloud Storage, który został zmieniony w zadaniu Cloud Run:

apiEndpoint:‘https://storage.us-central1.rep.googleapis.com.'

8. Czyszczenie danych

Czyszczenie zadania Cloud Run

gcloud run jobs delete screenshot-1 \
  --region=$region --quiet
gcloud run jobs delete screenshot-2 \
  --region=$region --quiet

gcloud iam service-accounts delete screenshot-sa@$project_id.iam.gserviceaccount.com --quiet

Czyszczenie punktu końcowego PSC

gcloud compute forwarding-rules delete pscendpoint \
    --global --quiet
gcloud network-connectivity regional-endpoints delete psc-regional-endpoint \
    --region=$region --quiet
gcloud compute addresses delete pscglobalip \
    --global --quiet

Zwalnianie miejsca w Cloud NAT, Cloud Router i sieciach VPC

gcloud compute routers nats delete $region-nat \
    --router=$region-cr \
    --region=$region --quiet
gcloud compute routers delete $region-cr \
    --region=$region --quiet
gcloud compute networks subnets delete mysubnet \
    --region=$region --quiet
gcloud compute networks delete mynet --quiet

9. Gratulacje

Udało Ci się przetestować prywatny dostęp Cloud Run do Cloud Storage za pomocą globalnego i regionalnego punktu końcowego.