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

Accesso privato di Cloud Run all'endpoint globale e all'endpoint regionale di Cloud Storage

1. Introduzione

Endpoint API di Google

Le API di Google Cloud offrono diversi tipi di endpoint per accedere ai servizi, che differiscono principalmente per la gestione del routing delle richieste, la residenza dei dati e l'isolamento regionale.

Consulta la documentazione del prodotto sui tipi di endpoint API.

Di seguito è riportata una suddivisione degli endpoint globali, regionali e di località:

Endpoint globali

Formato: {service}.googleapis.com (ad es. storage.googleapis.com)
Descrizione: questi endpoint forniscono un unico punto di accesso globale a un servizio. Non specificano una regione nell'URL.
Routing: le richieste vengono instradate dai Google Front End (GFE) globali e dal bilanciamento del carico del servizio globale, in genere indirizzando il traffico alla regione integra più vicina per ridurre al minimo la latenza.
Terminazione TLS: si verifica nel GFE più vicino al client, che potrebbe trovarsi al di fuori della regione Google Cloud in cui risiedono i dati o le risorse.
Residenza dei dati: non vengono fornite garanzie per i dati in transito. I dati potrebbero superare i confini regionali dopo la decriptazione nel GFE.
Isolamento regionale: limitato. Sebbene i backend siano spesso regionali, il punto di ingresso e il bilanciamento del carico sono globali, il che significa che i problemi in una parte dell'infrastruttura globale potrebbero potenzialmente influire sui servizi in altre regioni.
Caso d'uso: accesso per uso generico in cui la bassa latenza per gli utenti geograficamente dispersi è fondamentale e la residenza dei dati rigorosa in transito non è una preoccupazione primaria.

Endpoint regionali (REP)

Formato: {service}.{location}.rep.googleapis.com (ad es. storage.us-east1.rep.googleapis.com)
Descrizione: sono progettati per fornire garanzie di residenza dei dati e isolamento regionale rigoroso. La località (una regione Google Cloud specifica) viene specificata come sottodominio. Questo è lo standard moderno e sta sostituendo gli endpoint di località.
Routing: utilizza uno stack frontend completamente regionalizzato, inclusi i bilanciatori del carico esterni regionali e il bilanciamento del carico del servizio regionale . L'intero percorso della richiesta, dal DNS al backend del servizio, rimane all'interno della regione specificata.
Terminazione TLS: si verifica all'interno della regione specificata sui bilanciatori del carico esterni regionali.
Residenza dei dati: garantisce che i dati rimangano all'interno della regione designata sia in transito sia in uso, soddisfacendo requisiti rigorosi di conformità e sovranità.
Isolamento regionale: rigoroso. Gli errori nell'infrastruttura frontend di una regione non influiscono sulle altre regioni.
Caso d'uso: applicazioni che richiedono residenza dei dati rigorosa, isolamento regionale elevato e conformità.

Tieni presente che non tutte le API di Google hanno un endpoint regionale e controlla qui tutti gli endpoint regionali supportati.

Gli endpoint regionali multiregionali (mREP) sono anche endpoint regionali, ad esempio us (Stati Uniti), eu (Unione Europea) e così via (ad es. storage.us.rep.googleapis.com)

Endpoint di località (LEP)

Formato: {location}-{service}.googleapis.com (ad es. us-east1-storage.googleapis.com)
Descrizione: questi endpoint erano un approccio precedente per fornire l'accesso specifico per località. La località fa parte del nome host principale. Nota: gli endpoint di località vengono sostituiti dagli endpoint regionali.
Routing: si basa ancora sui Google Front End globali.
Terminazione TLS: in genere si verifica nel GFE, che potrebbe non trovarsi nella regione specificata nel nome host.
Residenza dei dati: non è possibile garantire che i dati rimangano all'interno della regione specificata durante il transito per il traffico proveniente da internet pubblico.
Isolamento regionale: più debole rispetto agli endpoint regionali perché utilizzano l'infrastruttura frontend globale.
Caso d'uso: storicamente utilizzato per alcuni scenari di accesso regionale, ma ora in genere sconsigliato a favore degli endpoint regionali per garanzie più rigorose.

Private Service Connect per l'API di Google

Private Service Connect è una funzionalità di networking di Google Cloud che consente ai consumer di accedere ai servizi dei producer. Ciò include la possibilità di connettersi alle API di Google tramite un endpoint privato ospitato all'interno del VPC dell'utente.

Come utilizzare l'endpoint PSC per accedere all'API di Google:

Endpoint PSC per l'API di Google globale
Endpoint PSC per l'API di Google regionale
Utilizza l'endpoint PSC per l'API di Google globale per accedere privatamente all'API di Google di località.

Come utilizzare il backend PSC per accedere all'API di Google:

Backend PSC per l'API di Google globale
Backend PSC per l'API di Google regionale
Utilizza il backend PSC per l'API di Google globale per accedere privatamente all'API di Google di località.

Cloud Run invia il traffico alla rete VPC

Il traffico in uscita VPC diretto offre un'infrastruttura migliorata e una configurazione del traffico in uscita VPC più semplice per Cloud Run, inclusi i seguenti vantaggi:

Configurazione: i servizi e i job Cloud Run possono inviare traffico a una rete VPC senza il sovraccarico della gestione di un connettore di accesso VPC serverless.
Costo: paghi solo gli addebiti per il traffico di rete, che vengono scalati a zero proprio come il servizio stesso.
Sicurezza: puoi utilizzare i tag di rete direttamente sulle revisioni del servizio per una sicurezza di rete più granulare.
Prestazioni: latenza inferiore, throughput più elevato.

Puoi abilitare il servizio, la funzione, il job o il pool di worker Cloud Run per inviare tutto il traffico a una rete VPC utilizzando il traffico in uscita VPC diretto.

2. Obiettivi didattici

Come creare un endpoint PSC per l'API di Google globale.
Come creare un endpoint PSC per l'API di Google regionale.
Come modificare l'endpoint API nel codice Cloud Run e configurare il networking per il traffico in uscita.

3. Architettura complessiva del lab

4. Passaggi di preparazione

Ruoli IAM richiesti per lavorare nel lab

Inizia assegnando i ruoli IAM richiesti all'account GCP a livello di progetto.

Compute Network Admin (roles/compute.networkAdmin) Questo ruolo ti consente di controllare completamente le risorse di networking di Compute Engine.
Logging Admin (roles/logging.admin) Questo ruolo ti consente di accedere a tutte le autorizzazioni di logging e alle autorizzazioni dipendenti.
Service Usage Admin (roles/serviceusage.serviceUsageAdmin) Questo ruolo ti consente di abilitare, disabilitare e analizzare gli stati dei servizi, analizzare le operazioni e utilizzare la quota e la fatturazione per un progetto consumer.
Amministratore DNS (roles/dns.admin) Questo ruolo ti fornisce l'accesso in lettura/scrittura a tutte le risorse Cloud DNS.
Amministratore di Cloud Run (roles/run.admin) Questo ruolo ti consente di controllare completamente tutte le risorse Cloud Run.
Storage Admin (roles/storage.admin) Questo ruolo ti consente di controllare completamente gli oggetti e i bucket.

Abilita API

In Cloud Shell, assicurati che il progetto sia configurato correttamente e imposta le variabili di ambiente.

In Cloud Shell, esegui le seguenti operazioni:

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

Abilita tutte le API di Google necessarie nel progetto. In Cloud Shell, esegui le seguenti operazioni:

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

Crea VPC

Nel progetto, crea una rete VPC con la modalità subnet personalizzata. Esegui le seguenti operazioni in Cloud Shell:

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

Crea subnet

In Cloud Shell, esegui le seguenti operazioni per creare una subnet IPV4:

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

Crea Cloud NAT e router Cloud

Cloud NAT viene utilizzato per consentire ai job Cloud Run di connettersi a siti web esterni.

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. Crea un endpoint PSC per Cloud Storage

Creerai due endpoint PSC per Cloud Storage, uno con ambito globale e l'altro con ambito regionale.

Crea un endpoint PSC con ambito globale

Con Private Service Connect, puoi creare endpoint privati con ambito globale utilizzando indirizzi IP interni globali all'interno della tua rete VPC.

Dovrai allocare un indirizzo IP univoco non definito nel tuo VPC. Consulta il documento relativo a questo requisito dell'indirizzo IP.

In Cloud Shell, esegui le seguenti operazioni per creare un indirizzo IP. Modifica –addresses=<pscendpointip> in modo da utilizzare l'indirizzo IP che hai allocato.

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

Crea una regola di forwarding per connettere l'endpoint alle API e ai servizi di Google.

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

Controlla p.googleapis.com in Cloud DNS

Quando crei un endpoint, vengono create automaticamente le seguenti configurazioni DNS:

Viene creata una zona DNS privata di Service Directory per p.googleapis.com.
I record DNS vengono creati in p.googleapis.com per alcune API di Google e alcuni servizi di Google di uso comune disponibili tramite Private Service Connect e con nomi DNS predefiniti che terminano con googleapis.com.

Gli endpoint globali sono registrati in Service Directory. Utilizzerai storage-[psc endpoint name].p.googleapis.com per accedere a Cloud Storage. Per maggiori dettagli, consulta la documentazione del prodotto.

Verifica se la zona p.googleaps.com è già stata creata eseguendo il comando.

gcloud dns managed-zones list

Se vuoi utilizzare il nome DNS predefinito, storage.googleapis.com, crea una zona privata storage.googleapis.com in Cloud DNS e aggiungi il record apex che punta all'indirizzo IP dell'endpoint PSC con ambito globale.

Crea un endpoint PSC con ambito regionale per Cloud Storage

Avrai bisogno di un indirizzo IP dalla subnet VPC. Esegui il comando riportato di seguito. Verrà allocato un indirizzo IP dalla subnet per l'endpoint 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

Recupera l'indirizzo IP dell'endpoint creato nel passaggio precedente.

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

Utilizzerai storage.us-central1.rep.googleapis.com per accedere a Cloud Storage. Devi creare una zona privata per storage.us-central1.rep.googleapis.com e il record apex dell'indirizzo IP che hai appena creato per l'endpoint regionale in Cloud DNS.

Crea una zona privata per l'endpoint regionale di Cloud Storage

Utilizzerai storage.[region name].rep.googleapis.com per accedere all'endpoint regionale di Cloud Storage.

Dovrai creare una zona privata in Cloud DNS e aggiungere un record apex che punta all'indirizzo IP dell'endpoint regionale di Cloud Storage.

Nel comando riportato di seguito, us-central1 è la regione di esempio. Devi creare la zona con il nome della tua regione.

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. Configura il job Cloud Run con l'endpoint PSC con ambito globale

Ottieni il codice

Per prima cosa, esplora un'applicazione Node.js per acquisire screenshot di pagine web e archiviarli in Cloud Storage. In un secondo momento, crei un'immagine container per l'applicazione e la esegui come job in Cloud Run.

Da Cloud Shell, esegui il comando seguente per clonare il codice dell'applicazione da questo repository:

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

Vai alla directory contenente l'applicazione:

cd jobs-demos/screenshot

Dovresti vedere questo layout di file:

├── Dockerfile

├── README.md

├── screenshot.js

├── package.json

Ecco una breve descrizione di ogni file:

screenshot.js contiene il codice Node.js per l'applicazione. L'applicazione acquisisce screenshot di pagine web e li archivia in Cloud Storage.
package.json definisce le dipendenze della libreria.
Dockerfile definisce l'immagine container.

Apri il codice screenshot.js. Modificherai apiEndpoint in modo che punti all'endpoint PSC globale. Cerca il codice e sostituisci const storage = new Storage(); con quanto segue:

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

Esegui il deployment di un job

Prima di creare un job, devi creare un account di servizio che utilizzerai per eseguirlo.

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

Concedi il ruolo storage.admin all'account di servizio, in modo che possa essere utilizzato per creare bucket e oggetti.

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

Concedi il ruolo Storage Object User , il ruolo Logs Writer e il ruolo Artifact Registry Repository Administrator all'account di servizio Compute predefinito.

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

Abiliterai il traffico in uscita VPC diretto per i job Cloud Run in modo da inviare tutto il traffico a una rete VPC.

In Cloud Shell, esegui le seguenti operazioni:

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

Esegui il job

In Cloud Shell, esegui le seguenti operazioni:

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

Controlla lo stato del job e i log. Vai alla console Cloud Run e cerca il job. Fai clic sul job e controlla la cronologia del log. Vedrai un risultato di esecuzione del job simile a quello riportato di seguito.

Per i log di esecuzione dettagliati del job, fai clic su Visualizza log nell'attività. Vedrai log del job simili a quelli riportati di seguito.

È stato creato un nuovo bucket. Puoi andare alla console Cloud Storage e controllare il nuovo bucket creato. Tieni presente che, poiché utilizzi l'endpoint globale di Cloud Storage, il bucket è un bucket multiregionale. Puoi controllare le immagini caricate nel bucket.

Il risultato del test mostra che Cloud Run ha eseguito l'accesso privato all'endpoint globale di Cloud Storage che hai modificato nel job Cloud Run:

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

7. Configura il job Cloud Run con l'endpoint PSC con ambito regionale

Nel codice, modificherai apiEndpoint in modo che punti all'endpoint PSC con ambito regionale.

Cerca il codice e sostituisci const storage = new Storage(); con quanto segue ( utilizziamo us-central1 come esempio. Modifica in modo da utilizzare la tua regione) :

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

Esegui il deployment di un job

Assicurati di trovarti nella directory contenente l'applicazione (jobs-demos/screenshot).

pwd

Abilita il traffico in uscita VPC diretto per i job in modo da inviare tutto il traffico a una rete VPC.

In Cloud Shell, esegui le seguenti operazioni:

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

Esegui il job

In Cloud Shell, esegui le seguenti operazioni:

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

Controlla lo stato del job e i log. Vai alla console Cloud Run e cerca il job. Fai clic sul job e controlla la cronologia del job. Vedrai un risultato di esecuzione del job simile a quello riportato di seguito.

Per i log di esecuzione dettagliati del job, fai clic su Visualizza log. Vedrai log del job simili a quelli riportati di seguito.

È stato creato un nuovo bucket. Puoi andare alla console Cloud Storage e controllare il nuovo bucket creato. Tieni presente che, poiché utilizzi l'endpoint regionale di Cloud Storage, il bucket è un bucket a regione singola. Puoi controllare le immagini caricate nel bucket.

Il risultato del test mostra che Cloud Run ha eseguito l'accesso privato all'endpoint regionale di Cloud Storage che hai modificato nel job Cloud Run:

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

8. Libera spazio

Esegui la pulizia del job 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

Esegui la pulizia dell'endpoint 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

Libera spazio in Cloud NAT, router Cloud e 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. Complimenti

Hai testato correttamente l'accesso privato di Cloud Run a Cloud Storage tramite l'endpoint globale e l'endpoint regionale.