Descripción general de Cloud Run Functions

El acto de implementar una función de Cloud Run coordina automáticamente los servicios de Google Cloud subyacentes, incluidos Cloud Storage, Cloud Build y Artifact Registry, para empaquetar y ejecutar tu código. Comprender estas interacciones de servicio te ayuda a configurar los permisos de Identity and Access Management necesarios, hacer un seguimiento de las dependencias de recursos y solucionar problemas de implementación o compilación.

Antes de comenzar

Familiarízate con los conceptos de Cloud Run Functions y de implementación de fuentes en la guía Opciones de implementación y modelo de recursos de Cloud Run.

Descripción general de la arquitectura

Cuando implementas el código fuente de la función en Cloud Run Functions, ese código fuente se almacena en un bucket de Cloud Storage. Luego, Cloud Build compila el código automáticamente en una imagen de contenedor y la envía a un registro de imágenes de Artifact Registry. Cloud Run Functions accede a esta imagen cuando necesita ejecutar el contenedor para ejecutar la función.

En el siguiente diagrama, el cuadro de Cloud Run Functions representa una función que se implementa en Cloud Run, con la API de Cloud Run Admin o la API de Cloud Functions. Por lo general, las funciones más nuevas se implementan con la API de Cloud Run Admin, y las funciones más antiguas se implementan con la API de Cloud Functions.

Llama a la API de Cloud Run Admin desde la consola de Google Cloud .
Figura 1. Un usuario prepara el código fuente de las funciones y lo implementa en Cloud Run.

Según la API que se use cuando se implemente una función, ocurrirá lo siguiente:

  • Si implementaste tu función con la API de Cloud Run Admin, ocurrirá lo siguiente:

    1. Tu código fuente se sube a un bucket de Cloud Storage que no tiene un período de retención.

      1. Si usas la encriptación predeterminada, el nombre del bucket se genera automáticamente y se llama run-sources-PROJECT_ID-REGION.
      2. Si proteges tus datos con claves de encriptación administradas por el cliente (CMEK), el nombre del bucket no se genera automáticamente y debes proporcionar uno.

    2. El código fuente se envía a Cloud Build, donde los buildpacks de Google Cloud y Functions Framework crean una imagen de contenedor. Ten en cuenta que la cuenta de servicio de Cloud Build compila la imagen de contenedor. De forma predeterminada, Cloud Run usa el tipo de máquina e2-standard-2 que proporciona Cloud Build.

    3. Luego, la imagen de contenedor se sube a Artifact Registry a través de un bucket creado automáticamente llamado REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy.

    4. La imagen se implementa en Cloud Run como un servicio.

    5. Puedes activar o invocar la función con Eventarc, Pub/Sub o con otros activadores HTTP.

  • Si implementaste tu función con la API de Cloud Functions (v2), ocurrirá lo siguiente:

    1. Tu código fuente se sube a un bucket de Cloud Storage que no tiene un período de retención.

      El nombre del bucket se genera de forma automática y tiene el siguiente formato:

      1. Si usas la encriptación predeterminada, este bucket se llama gcf-v2-sources-PROJECT_NUMBER-REGION.
      2. Si proteges tus datos con CMEK, el bucket se llama gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.

    2. El código fuente se envía a Cloud Build, donde los buildpacks de Google Cloud y Functions Framework crean una imagen de contenedor. Ten en cuenta que la cuenta de servicio de Cloud Build compila la imagen de contenedor. De forma predeterminada, Cloud Run usa el tipo de máquina e2-standard-2 que proporciona Cloud Build.

    3. Luego, la imagen de contenedor se sube a Artifact Registry a través de un bucket creado automáticamente llamado REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts.

    4. La imagen se implementa en Cloud Run como un servicio.

    5. Puedes activar o invocar la función con Eventarc, Pub/Sub o con otros activadores HTTP.

¿Qué sigue?