Panoramica di Cloud Run Functions

Questa guida fornisce una panoramica introduttiva di come sono coinvolti altri servizi Google Cloud nel processo di deployment di Cloud Run Functions.

Prima di iniziare

Acquisisci familiarità con i concetti di deployment delle funzioni Cloud Run e dell'origine dalla guida Opzioni di deployment e modello di risorse di Cloud Run.

Panoramica dell'architettura

Quando esegui il deployment del codice sorgente della funzione in Cloud Run Functions, questo codice sorgente viene archiviato in un bucket Cloud Storage. Cloud Build crea automaticamente il codice in un'immagine container ed esegue il push dell'immagine in un registro di immagini di Artifact Registry. Le funzioni Cloud Run accedono a questa immagine quando devono eseguire il container per eseguire la tua funzione.

Nel seguente diagramma, la casella Cloud Run Functions rappresenta una funzione di cui è stato eseguito il deployment in Cloud Run, utilizzando l'API Cloud Run Admin o l'API Cloud Functions. In genere, le funzioni più recenti vengono eseguite il deployment utilizzando l'API Cloud Run Admin, mentre quelle meno recenti utilizzano l'API Cloud Functions.

Chiama l'API Cloud Run Admin dalla console Google Cloud .
Figura 1. Un utente prepara il codice sorgente delle funzioni e ne esegue il deployment su Cloud Run.

A seconda dell'API utilizzata durante il deployment di una funzione, si verifica quanto segue:

  • Se hai eseguito il deployment della funzione utilizzando l'API Cloud Run Admin, si verifica quanto segue:

    1. Il codice sorgente viene caricato in un bucket Cloud Storage senza periodo di conservazione.

      1. Se utilizzi la crittografia predefinita, il nome del bucket viene generato automaticamente e denominato run-sources-PROJECT_ID-REGION.
      2. Se proteggi i tuoi dati con le chiavi di crittografia gestite dal cliente (CMEK), il nome del bucket non viene generato automaticamente e devi fornire un nome.

    2. Il codice sorgente viene inviato a Cloud Build, dove i buildpack di Google Cloud e Functions Framework creano un'immagine container. Tieni presente che il account di servizio Cloud Build crea l'immagine container. Per impostazione predefinita, Cloud Run utilizza il tipo di macchina e2-standard-2 fornito da Cloud Build.

    3. L'immagine container viene quindi caricata su Artifact Registry tramite un bucket creato automaticamente denominato REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy.

    4. L'immagine viene sottoposta a deployment su Cloud Run come servizio.

    5. Puoi attivare o richiamare la funzione con Eventarc, Pub/Sub o altri trigger HTTP.

  • Se hai eseguito il deployment della funzione utilizzando l'API Cloud Functions (v2), si verifica quanto segue:

    1. Il codice sorgente viene caricato in un bucket Cloud Storage senza periodo di conservazione.

      Il nome del bucket viene generato automaticamente e segue questo formato:

      1. Se utilizzi la crittografia predefinita, questo bucket si chiama gcf-v2-sources-PROJECT_NUMBER-REGION.
      2. Se proteggi i tuoi dati con CMEK, il bucket si chiama gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.

    2. Il codice sorgente viene inviato a Cloud Build, dove i buildpack di Google Cloud e Functions Framework creano un'immagine container. Tieni presente che il account di servizio Cloud Build crea l'immagine container. Per impostazione predefinita, Cloud Run utilizza il tipo di macchina e2-standard-2 fornito da Cloud Build.

    3. L'immagine container viene quindi caricata su Artifact Registry tramite un bucket creato automaticamente denominato REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts.

    4. L'immagine viene sottoposta a deployment su Cloud Run come servizio.

    5. Puoi attivare o richiamare la funzione con Eventarc, Pub/Sub o altri trigger HTTP.

Passaggi successivi