Présentation de Cloud Run Functions

Le déploiement d'une fonction Cloud Run coordonne automatiquement les services Google Cloud sous-jacents, y compris Cloud Storage, Cloud Build et Artifact Registry, pour empaqueter et exécuter votre code. Comprendre ces interactions entre les services vous aide à configurer les autorisations Identity and Access Management requises, à suivre les dépendances des ressources et à résoudre les problèmes de déploiement ou de compilation.

Avant de commencer

Familiarisez-vous avec les concepts de Cloud Run Functions et de déploiement de sources en consultant le guide Options de déploiement et modèle de ressources Cloud Run.

Présentation de l'architecture

Lorsque vous déployez le code source de votre fonction dans Cloud Run Functions, ce code source est stocké dans un bucket Cloud Storage. Cloud Build compile ensuite automatiquement votre code dans une image de conteneur, puis transfère cette image dans un registre d'images Artifact Registry. Cloud Run Functions accède à cette image lorsqu'il doit exécuter le conteneur pour exécuter votre fonction.

Dans le diagramme suivant, la zone Cloud Run Functions représente une fonction déployée dans Cloud Run, à l'aide de l'API Cloud Run Admin ou de l'API Cloud Functions. En règle générale, les fonctions plus récentes sont déployées à l'aide de l'API Cloud Run Admin, et les fonctions plus anciennes sont déployées à l'aide de l'API Cloud Functions.

Appelez l'API Cloud Run Admin depuis la console Google Cloud .
Figure 1. Un utilisateur prépare le code source des fonctions et le déploie sur Cloud Run.

Selon l'API utilisée lors du déploiement d'une fonction, les événements suivants se produisent :

  • Si vous avez déployé votre fonction à l'aide de l'API Cloud Run Admin, voici ce qui se produit :

    1. Votre code source est importé dans un bucket Cloud Storage sans durée de conservation.

      1. Si vous utilisez le chiffrement par défaut, le nom du bucket est généré automatiquement et nommé run-sources-PROJECT_ID-REGION.
      2. Si vous protégez vos données avec des clés de chiffrement gérées par le client (CMEK), le nom du bucket n'est pas généré automatiquement et vous devez en fournir un.

    2. Le code source est envoyé à Cloud Build, où les buildpacks Google Cloud et le framework des fonctions créent une image de conteneur. Notez que le compte de service Cloud Build crée l'image de conteneur. Par défaut, Cloud Run utilise le type de machine e2-standard-2 fourni par Cloud Build.

    3. Votre image de conteneur est ensuite importée dans Artifact Registry via un bucket créé automatiquement, nommé REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy.

    4. L'image est déployée sur Cloud Run en tant que service.

    5. Vous pouvez déclencher ou appeler la fonction avec Eventarc, Pub/Sub ou d'autres déclencheurs HTTP.

  • Si vous avez déployé votre fonction à l'aide de l'API Cloud Functions (v2), voici ce qui se produit :

    1. Votre code source est importé dans un bucket Cloud Storage sans durée de conservation.

      Le nom du bucket est généré automatiquement et suit ce format :

      1. Si vous utilisez le chiffrement par défaut, ce bucket est nommé gcf-v2-sources-PROJECT_NUMBER-REGION.
      2. Si vous protégez vos données avec des CMEK, le bucket est nommé gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.

    2. Le code source est envoyé à Cloud Build, où les buildpacks Google Cloud et Functions Framework créent une image de conteneur. Notez que le compte de service Cloud Build crée l'image de conteneur. Par défaut, Cloud Run utilise le type de machine e2-standard-2 fourni par Cloud Build.

    3. Votre image de conteneur est ensuite importée dans Artifact Registry via un bucket créé automatiquement, nommé REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts.

    4. L'image est déployée sur Cloud Run en tant que service.

    5. Vous pouvez déclencher ou appeler la fonction avec Eventarc, Pub/Sub ou d'autres déclencheurs HTTP.

Étapes suivantes