Dopo aver creato un servizio o una funzione, Cloud Run ti fornisce un endpoint HTTPS per il servizio. Puoi abilitare il servizio per l'esecuzione in risposta alle richieste HTTPS.
Tutti i servizi Cloud Run hanno un URL HTTPS stabile, che rappresenta l'endpoint HTTPS predefinito per il servizio, anche se puoi configurare domini personalizzati.
Alcuni casi d'uso includono quanto segue:
- API web RESTful personalizzata
- Microservizio privato
- Middleware HTTP o proxy inverso per le tue applicazioni web
- Applicazione web preconfigurata
Creare servizi pubblici
La creazione di un servizio pubblico su Cloud Run richiede quanto segue:
- Accesso al servizio da internet pubblico
- Un URL destinato all'uso pubblico
Per rendere pubblico un servizio, impostalo in modo da consentire l'accesso non autenticato (pubblico) durante la deployment o in qualsiasi momento dopo il deployment.
URL del servizio
Cloud Run assegna un URL non deterministico basato su hash a tutti i servizi. Se la lunghezza del nome del servizio lo consente, Cloud Run assegna anche un URL deterministico al servizio.
Puoi disattivare questi URL run.app
predefiniti.
Puoi recuperare l'URL del servizio facendo clic sul nome del servizio nella consoleGoogle Cloud o eseguendo il seguente comando in gcloud CLI:
gcloud run services describe SERVICE --format 'value(status.url)'
L'URL deterministico ha la priorità quando viene visualizzato.
Se il servizio Cloud Run è stato creato come
funzione con l'API Cloud Functions v2, al servizio
viene assegnato anche un
URL cloudfunctions.net
.
URL deterministico
L'URL deterministico ti consente di prevedere l'URL del servizio prima della creazione del servizio, il che può essere utile per la comunicazione tra servizi.
L'URL deterministico è disponibile solo per i segmenti DNS di 63 caratteri o meno. Il segmento DNS contiene il nome del servizio, il numero di progetto e qualsiasi tag o tag di traffico.
L'URL deterministico per un servizio Cloud Run ha il seguente formato:
https://[TAG---]SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
dove:
- TAG è il tag di traffico facoltativo per la revisione che stai richiedendo.
- PROJECT_NUMBER è il Google Cloud numero di progetto.
- SERVICE_NAME è il nome del servizio Cloud Run.
- REGION è il nome della regione, ad esempio
europe-west1
.
URL non deterministico
Gli URL non deterministici non hanno un formato deterministico, il che significa che poiché il secondo campo dell'URL è un hash casuale, non puoi prevedere quale sarà l'URL completo prima di eseguire il deployment dei servizi. Dopo il deployment del servizio, tuttavia, l'URL rimane stabile.
L'URL non deterministico per un servizio Cloud Run ha il formato
https://[
TAG---]
SERVICE_IDENTIFIER.run.app
,
dove TAG si riferisce al tag di traffico facoltativo per la revisione che stai
richiedendo e SERVICE_IDENTIFIER è un identificatore stabile e univoco
per un servizio Cloud Run. Non analizzare
SERVICE_IDENTIFIER perché non ha un formato fisso e la
logica per la generazione di SERVICE_IDENTIFIER è soggetta a modifiche.
Visualizzazione progressiva risposte
Cloud Run supporta le risposte HTTP in streaming.
Per attivare la funzionalità non è necessaria alcuna configurazione.
Il server deve rispondere con un'intestazione di risposta Transfer-Encoding: chunked
.
Reindirizzamento da HTTP a HTTPS
Cloud Run reindirizza tutte le richieste HTTP a HTTPS, ma termina
TLS prima che raggiungano il tuo servizio web. Se il tuo servizio genera una risorsa web
che fa riferimento ad altre risorse web con URL non protetti (http://
), la tua pagina
potrebbe essere soggetta a errori o avvisi relativi a contenuti misti.
Utilizza il protocollo https
per tutti gli URI web di riferimento o l'account
per le direttive proxy nella richiesta HTTP, ad esempio l'intestazione
HTTP X-Forwarded-Proto
.
HTTP e HTTP/2
Per impostazione predefinita, Cloud Run esegue il downgrade delle richieste HTTP/2 a HTTP/1 quando queste richieste vengono inviate al container. Se vuoi impostare esplicitamente il tuo servizio in modo che utilizzi HTTP/2 end-to-end, consulta Utilizzo di HTTP/2.
Crea servizi privati
La creazione di un servizio privato su Cloud Run richiede di limitare l'accesso al servizio sfruttando l'autorizzazione IAM invoker.
Puoi anche limitare l'accesso a un servizio utilizzando un meccanismo di autenticazione e autorizzazione a livello di applicazione, ad esempio utilizzando Identity Platform.
Testare i servizi privati
Il modo più semplice per testare i servizi privati è utilizzare il
proxy Cloud Run in Google Cloud CLI.
Questo proxy il servizio privato su http://localhost:8080
(o sulla porta specificata con --port
),
fornendo il token dell'account attivo o un altro token specificato.
In questo modo puoi utilizzare un browser web o uno strumento come curl
.
Questo è il modo consigliato per testare privatamente un sito web o un'API nel browser.
Puoi eseguire il proxy di un servizio localmente utilizzando la seguente riga di comando in un ambiente Linux, macOS, WSL (preferito), o cygwin:
gcloud run services proxy SERVICE --project PROJECT-ID
Puoi anche testare i servizi privati senza il proxy utilizzando uno strumento
come curl
, passando un token di autenticazione nell'intestazione Authorization
:
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" SERVICE_URL
Servizio privato a servizio
Un servizio Cloud Run può chiamare un altro servizio Cloud Run con l'autenticazione da servizio a servizio.
Codice di esempio che richiama un servizio privato
Per esempi di codice che mostrano come ottenere un token ID ed effettuare una richiesta HTTP a un servizio privato, consulta l'argomento Autenticazione da servizio a servizio.
Utilizzare un middleware per migliorare il servizio
I proxy HTTPS possono scaricare funzionalità comuni da un servizio HTTP, come memorizzazione nella cache, convalida delle richieste o autorizzazione. Per i microservizi, molti proxy HTTP fanno parte di una soluzione API Gateway o di un mesh di servizi come Istio.
I prodottiGoogle Cloud che puoi utilizzare per migliorare il tuo servizio Cloud Run includono:
API Gateway, che puoi utilizzare per creare, proteggere e monitorare le API da utilizzare come proxy per altri servizi Cloud Run.
Firebase Hosting, che puoi utilizzare per creare un frontend dell'applicazione web da utilizzare con Cloud Run come backend dinamico.