Présentation du processus de compilation

Ce guide présente une vue d'ensemble du processus de compilation des fonctions déployées à l'aide de la commande gcloud functions. Pour découvrir le processus de compilation des fonctions déployées à l'aide de la commande gcloud run, consultez les ressources suivantes:

• Créer des conteneurs Cloud Run
• Définir le compte de service de compilation
• Définir des pools de nœuds de calcul de compilation

Lorsque vous déployez le code source de votre fonction à l'aide de la commande gcloud functions deploy, 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.

Le processus de création de l'image est entièrement automatique et ne nécessite aucune saisie directe de votre part. Toutes les ressources utilisées dans le processus de compilation s'exécutent dans votre propre projet utilisateur.

L'exécution du processus de compilation présente les aspects suivants :

• Vous disposez d'un accès direct à tous les journaux de compilation.

• Il n'y a pas de quota prédéfini pour la durée de compilation, bien que Cloud Build dispose de son propre quota de simultanéité par défaut.

• Vous pouvez afficher l'image de conteneur actuelle et les images de conteneur précédemment déployées, toutes stockées dans Container Registry.

• Cloud Storage est utilisé dans votre projet pour stocker le répertoire du code source de vos fonctions. Veuillez noter les points suivants :

  • Si vous créez une fonction à l'aide de la Google Cloud CLI, un bucket d'importation est créé pour contenir votre code source. Ce bucket d'importation est nommé gcf-v2-uploads-PROJECT_NUMBER-REGION.cloudfunctions.appspot.com.
  • Une fois le code importé, le code de la fonction est stocké dans un bucket source distinct :
    • Si vous utilisez le chiffrement par défaut, ce bucket est nommé gcf-v2-sources-PROJECT_NUMBER-REGION.
    • Si vous protégez vos données avec des CMEK, le bucket est nommé gcf-v2-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.
  • La durée de conservation des buckets source et d'importation n'est pas définie.

Caractéristiques du processus de compilation

Le processus de compilation présente les caractéristiques suivantes :

• L'API Cloud Build doit être activée pour votre projet.

  Pour activer l'API manuellement, cliquez sur le lien précédent, sélectionnez votre projet dans le menu déroulant, puis suivez les instructions pour activer l'interface utilisateur.

• Étant donné que l'intégralité du processus de compilation a lieu dans le contexte de votre projet, celui-ci est soumis à la tarification des ressources incluses :

  • Pour en savoir plus sur les tarifs de Cloud Build, consultez la page Tarifs. Ce processus utilise la taille d'instance par défaut de Cloud Build, car ces instances sont préalablement démarrées et disponibles plus rapidement. Cloud Build propose une version gratuite. Consultez les tarifs pour plus de détails.

  • Pour en savoir plus sur les tarifs de Cloud Storage, consultez la page Tarifs. Cloud Storage propose un quota gratuit : consultez les tarifs pour plus de détails.

  • Pour en savoir plus sur les tarifs d'Artifact Registry, consultez la page Tarifs.

• Comme le processus de compilation est susceptible d'être facturé, votre projet doit être associé à un compte Cloud Billing.

Afficher les journaux de vos images de build

L'un des principaux avantages d'avoir le processus d'image de build dans votre projet utilisateur est de pouvoir accéder aux journaux de compilation. Vous pouvez utiliser gcloud CLI ou la console Google Cloud pour accéder aux journaux, qui sont disponibles via Cloud Logging.

Registre d'images

Artifact Registry permet de stocker les images créées à partir du code source de votre fonction. Les images sont stockées dans un dépôt nommé REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts situé dans le même projet que celui dans lequel votre fonction est créée.

Pour spécifier un dépôt Artifact Registry autogéré, exécutez la commande suivante:

gcloud functions deploy FUNCTION_NAME \
   --docker-repository=REPOSITORY \
   [FLAGS...]

Remplacez les éléments suivants :

• FUNCTION_NAME : nom de la fonction.
• REPOSITORY : nom complet du dépôt Artifact Registry, au format suivant : projects/PROJECT_NAME/locations/LOCATION/repositories/REPOSITORY.

Lorsque vous spécifiez un dépôt Artifact Registry situé dans un autre projet ou une autre région, vous devrez peut-être prendre en compte des configurations supplémentaires:

Configurations IAM:

• Configurations IAM: assurez-vous que le compte de service de compilation est autorisé à lire et à écrire dans le REPOSITORY.
• Configurations réseau: assurez-vous que le REPOSITORY cible est accessible à partir de la configuration du projet actuel.
• VPC Service Controls: assurez-vous que le compte de service de compilation peut atteindre la REPOSITORY cible dans le périmètre VPC-SC.
• Contraintes de résidence des données: spécifier un REPOSITORY dans une région différente de celle de votre fonction entraînera un transfert de données entre les régions.

Sécuriser votre build à l'aide de pools privés

Pour permettre à vos fonctions d'utiliser des dépendances (par exemple, des packages npm), Cloud Build dispose par défaut d'un accès illimité à Internet durant le processus de compilation. Si vous avez configuré un périmètre VPC Service Controls (VPC SC) et que vous souhaitez limiter l'accès de la compilation uniquement aux dépendances stockées dans ce périmètre, vous pouvez utiliser la fonctionnalité de pools de nœuds de calcul privés de Cloud Build.

En général, vous pouvez utiliser la procédure suivante pour configurer votre pool privé :

1. Créez votre pool de nœuds de calcul privé. Consultez la page Créer et gérer des pools privés.

2. Configurez votre périmètre VPC Service Controls. Consultez la page Utiliser VPC Service Controls.

3. Si votre pool de nœuds de calcul privé se trouve dans un projet différent de celui de votre fonction, vous devez attribuer au compte de service de l'agent de service Cloud Functions (service-FUNCTION_PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com) le rôle cloudbuild.workerPoolUser afin que le service Cloud Build puisse accéder au pool de nœuds de calcul.

   gcloud projects add-iam-policy-binding PRIVATE_POOL_PROJECT_ID \
       --member serviceAccount:service-FUNCTION_PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com
       --role roles/cloudbuild.workerPoolUser

   Remplacez FUNCTION_PROJECT_NUMBER par le numéro du projet dans lequel la fonction est exécutée et PRIVATE_POOL_PROJECT_ID par l'ID du projet dans lequel le pool de travailleurs est situé. Pour en savoir plus, consultez la page Exécuter des compilations dans un pool privé.

4. Déployez votre fonction pour qu'elle soit compilée à l'aide d'un pool privé :

   gcloud functions deploy FUNCTION_NAME \
      --runtime RUNTIME \
      --build-worker-pool PRIVATE_POOL_NAME
      [FLAGS...]

   Remplacez FUNCTION_NAME par le nom de la fonction, RUNTIME par l'environnement d'exécution que vous utilisez et PRIVATE_POOL_NAME par le nom de votre pool.

Pour arrêter d'utiliser un pool privé donné et utiliser à la place le pool Cloud Build par défaut, utilisez l'option --clear-build-worker-pool lors du redéploiement.

gcloud functions deploy FUNCTION_NAME \
   --runtime RUNTIME \
   --clear-build-worker-pool
   [FLAGS...]

Remplacez FUNCTION_NAME par le nom de la fonction et RUNTIME par l'environnement d'exécution que vous utilisez.

Sécuriser votre build avec un compte de service personnalisé

Le code source de votre fonction est envoyé à Cloud Build pour être conteneurisé. La fonction conteneurisée est stockée dans Artifact Registry et déployée dans Cloud Run en tant que service. Les fonctions Cloud Run exploitent Cloud Build lors de la compilation et du déploiement de votre fonction Cloud Run. Par défaut, les fonctions Cloud Run utilisent le compte de service Cloud Build par défaut comme compte principal lors de la compilation. Depuis juillet 2024, Cloud Build a modifié le comportement par défaut concernant la façon dont Cloud Build utilise les comptes de service dans les nouveaux projets. En raison de cette modification, les nouveaux projets qui déploient des fonctions pour la première fois peuvent utiliser un compte de service Cloud Build par défaut avec des autorisations insuffisantes pour créer une fonction.

Pour les projets créés avant juillet 2024, Cloud Build utilise l'ancien compte de service Cloud Build. Google Cloud Ce compte de service a été conçu pour aider les utilisateurs à exécuter un large éventail de cas d'utilisation qui peuvent être trop permissifs pour les besoins de votre projet. Si vous souhaitez déplacer vos projets existants de ce compte de service, vous pouvez suivre les étapes ci-dessous pour renforcer la sécurité de votre environnement de compilation de fonctions:

• Empêcher l'ancien compte de service Cloud Build d'être utilisé pour la compilation
• Empêcher l'utilisation du compte de service Compute par défaut pour la compilation
• Configurer un compte de service avec des autorisations de portée appropriées à utiliser pour la compilation

Empêcher l'ancien compte de service Cloud Build d'être utilisé pour la compilation

Vous pouvez vérifier que votre projet utilise l'ancien compte de service Cloud Build en inspectant les détails de la compilation de votre fonction. Le compte de service de compilation par défaut a le format suivant:

PROJECT_NUMBER@cloudbuild.gserviceaccount.com.

Vous pouvez désactiver de force l'utilisation de ce compte de service en définissant la contrainte de règle d'administration cloudbuild.useBuildServiceAccount sur Not Enforced. Vous pouvez également supprimer toutes ses autorisations de rôle pour limiter son accès aux ressources Google Cloud.

Empêcher l'utilisation du compte de service Compute par défaut pour la compilation

Le compte de service Compute par défaut est au format PROJECT_NUMBER-compute@developer.gserviceaccount.com. Vous pouvez désactiver son utilisation par défaut pour la compilation en définissant la règle d'administration de l'organisation cloudbuild.useComputeServiceAccount sur Not Enforced. La désactivation de ce compte de service empêche son utilisation pour accéder aux ressources Google Cloud .

Fournir un compte de service pour créer des fonctions

Lors de la configuration d'une fonction, vous pouvez spécifier un compte de service de compilation lorsque vous déployez la fonction. Lorsque l'ancien compte de service Cloud Build et le compte de service de calcul par défaut ne peuvent pas être utilisés pour la compilation, vous devez spécifier un compte de service de compilation pour déployer une fonction, comme décrit dans cette section.

Si vous êtes concerné par les modifications décrites dans la section Modification du compte de service Cloud Build, vous pouvez effectuer l'une des opérations suivantes:

• Consultez les conseils de Cloud Build concernant les modifications apportées au compte de service par défaut et désactivez ces modifications.

• Ajoutez le rôle "Compte Cloud Build" (roles/cloudbuild.builds.builder) au compte de service Compute Engine par défaut.

• Créez un compte de service Cloud Build personnalisé pour déployer les fonctions.

Voici quelques situations dans lesquelles vous souhaiterez peut-être fournir un autre compte de service à utiliser lorsque Cloud Build compile votre fonction :

• Vous souhaitez avoir davantage de contrôle sur les comptes de service à ajouter à votre périmètre VPC-SC.

• Vous souhaitez que Cloud Build s'exécute avec des autorisations différentes de celles du compte de service par défaut sans avoir à révoquer chaque autorisation individuellement.

• Vous souhaitez définir des autorisations Cloud Build précises pour vos fonctions, et non partager un compte de service Cloud Build optimisé à d'autres fins.

• Votre organisation a désactivé l'utilisation du compte de service par défaut.

Les sections suivantes expliquent comment créer un compte de service Cloud Build personnalisé pour déployer les fonctions.

Créer un compte de service

Créez un compte de service comme décrit dans la section Créer un compte de service.

Octroyer des autorisations

Le compte de service que vous utilisez doit disposer des rôles suivants :

• roles/logging.logWriter : requis pour stocker des journaux de compilation dans Cloud Logging.
• roles/artifactregistry.writer : requis pour stocker les images de compilation dans Artifact Registry. Pour le comportement par défaut, le compte de service doit avoir accès aux dépôts nommés "gcf-artifacts" et "cloud-run-source-deploy". L'accès aux dépôts peut être défini dans la stratégie IAM du dépôt. Vous pouvez également fournir votre propre dépôt d'artefacts via le champ dockerRepository.
• roles/storage.objectViewer : requis pour récupérer la source de la fonction dans le bucket Cloud Storage et stocker les images de compilation dans Container Registry. Pour le comportement par défaut, le compte de service doit avoir accès aux buckets nommés "run-sources-*", "gcf-v2-sources-*" et "gcf-v2-uploads-*". Pour ce faire, vous pouvez ajouter une condition IAM à l'attribution de rôle, par exemple : (resource.type == "storage.googleapis.com/Object" && (resource.name.startsWith("projects/_/buckets/gcf-v2-sources-") || resource.name.startsWith("projects/_/buckets/gcf-v2-uploads-") || resource.name.startsWith("projects/_/buckets/run-sources-")))

Attribuez les rôles suivants à l'aide de Google Cloud CLI ou utilisez la consoleGoogle Cloud .

gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:SA_EMAIL \
    --role=roles/logging.logWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:SA_EMAIL \
--role=roles/artifactregistry.writer

gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:SA_EMAIL \
--role=roles/storage.objectViewer

Remplacez les éléments suivants :

• PROJECT_ID: ID de votre projetGoogle Cloud .
• SA_EMAIL : adresse e-mail de votre compte de service.

Considérations concernant VPC Service Controls

Si vous disposez d'un périmètre VPC Service Controls protégeant à la fois votre projet et l'API des fonctions Cloud Run, et si vous utilisez le compte de service Compute Engine par défaut comme rôle Compte de service Cloud Build pour les fonctions Cloud Run, vous devez créer les règles d'entrée suivantes:

• Autorisez l'accès du compte de service par défaut Compute Engine à toutes les méthodes des API Cloud Storage et Cloud Logging.
• Autorisez l'entrée du compte de service service-[PROJECT_NUMBER]@gcf-admin-robot.iam.gserviceaccount.com dans toutes les méthodes des API Cloud Storage et Cloud Logging.

Déployer une fonction avec un compte de service personnalisé

Pour transmettre un compte de service créé par l'utilisateur, qui sera utilisé par Cloud Build lors du déploiement de votre fonction, exécutez la commande gcloud suivante:

• L'option --build-service-account spécifie un compte de service IAM dont les identifiants seront utilisés pour l'étape de compilation. Si aucun compte de service personnalisé n'est fourni, la fonction utilise le compte de service par défaut du projet pour Cloud Build.
• Vous pouvez éventuellement utiliser un pool privé que vous spécifiez à l'aide de l'option --build-worker-pool.

gcloud functions deploy FUNCTION_NAME \
   --gen2 \
   --region=REGION \
   --project=PROJECT_ID \
   --runtime=RUNTIME \
   --entry-point=CODE_ENTRYPOINT \
   --build-service-account=projects/PROJECT_ID/serviceAccounts/SA_EMAIL \
   --memory=256Mi \
   --trigger-http \
   --source=.

Remplacez les éléments suivants :

• FUNCTION_NAME : nom sous lequel vous avez déployé votre fonction.
• REGION: nom de la régionGoogle Cloud dans laquelle vous souhaitez déployer votre fonction (par exemple, us-west1).
• PROJECT_ID: ID de votre projetGoogle Cloud .
• RUNTIME : ID d'exécution d'une version d'exécution compatible pour exécuter votre fonction, par exemple, nodejs18.
• CODE_ENTRYPOINT : point d'entrée de votre fonction dans votre code source. Il s'agit du code qui sera exécuté lors de l'exécution de votre fonction.
• SA_EMAIL : adresse e-mail de votre compte de service.

Accorder au compte de service Cloud Build l'accès au périmètre de VPC Service Controls

Cloud Run Functions crée votre code source dans un conteneur exécutable à l'aide de Cloud Build. Pour utiliser les fonctions Cloud Run avec VPC Service Controls, vous devez configurer votre compte de service Cloud Build (par défaut ou personnalisé) pour accéder à votre périmètre de service.

Rechercher le nom du compte de service

Si vous utilisez le compte de service Cloud Build par défaut, vous pouvez trouver son nom comme suit :

1. Utilisez la page IAM de la console Google Cloud pour trouver le compte de service Cloud Build.

   Ouvrir la page AM

2. Assurez-vous que le bon projet figure dans la liste déroulante des projets.

3. Recherchez cloudbuild.gserviceaccount.com. Le nom du compte de service correspond à une adresse e-mail au format PROJECT_NUMBER@cloudbuild.gserviceaccount.com.

Si vous disposez d'un compte de service Cloud Build personnalisé, utilisez plutôt ce nom.

Accorder au compte de service l'accès au périmètre de service

Une fois que vous disposez du nom du compte de service, suivez les instructions de la section Limiter l'accès par utilisateur ou compte de service pour créer un niveau d'accès pour le compte de service. Suivez ensuite les instructions de la section Ajouter un niveau d'accès à un périmètre existant pour ajouter le niveau d'accès à votre périmètre de service.