Sortie VPC directe avec un réseau VPC

Vous pouvez activer votre service ou votre job Cloud Run service, fonction, job ou pool de nœuds de calcul

Les services et les jobs Cloud Run ne sont pas compatibles avec l'entrée VPC directe. Pour configurer l'entrée VPC directe pour les pools de nœuds de calcul uniquement, consultez Entrée des pools de nœuds de calcul Cloud Run.

Avant de commencer

Limites

Les limites suivantes s'appliquent aux services et aux jobs Cloud Run , aux services, aux fonctions, aux jobs et aux pools de nœuds de calcul :

  • Lorsque vous utilisez la sortie VPC directe, vous pouvez rencontrer des délais d'établissement de connexion d'une minute ou plus au démarrage de l'instance. Nous vous recommandons de configurer une vérification de démarrage HTTP qui teste une connexion à une destination de sortie utilisée par l'application avant que celle-ci n'accepte les requêtes. Ce test de connectivité de sortie doit implémenter des nouvelles tentatives ou la vérification de démarrage doit être définie avec des configurations de période et de seuil appropriées pour agir en tant que nouvelle tentative.
  • Les jobs Cloud Run exécutés pendant plus d'une heure peuvent subir des interruptions de connexion. Cela peut se produire lors d'événements de maintenance liés à la migration du job d'une machine à une autre. Le conteneur reçoit un signal SIGTSTP 10 secondes avant l'événement et un signal SIGCONT après l'événement. Une fois que le conteneur a reçu le signal SIGCONT, réessayez la connexion.
  • Avec Cloud NAT, vous pouvez rencontrer des délais de démarrage à froid de 30 secondes ou plus au démarrage de l'instance lorsque vous utilisez la sortie VPC directe. Pour de meilleures performances de démarrage, nous vous recommandons d'utiliser des connecteurs d'accès au VPC sans serveur avec Cloud NAT.
  • Cloud Run accepte un débit pouvant atteindre 1 Gbit/s par instance individuelle. Au-delà de ce nombre, les performances sont limitées.
  • Un quota d'utilisation de Cloud Run limite le nombre maximal d'instances que vous pouvez configurer pour utiliser la sortie VPC directe. Le nombre maximal est configuré par révision ou exécution de job Cloud Run. Pour augmenter les limites par défaut, consultez la section Augmenter les quotas.

  • Les services et jobs Cloud Run , peuvent rencontrer des interruptions de connexion lors d'événements de maintenance de l'infrastructure de mise en réseau. Nous vous recommandons d'utiliser des bibliothèques clientes pouvant gérer les réinitialisations occasionnelles des connexions.
  • Network Intelligence Center n'est compatible qu'avec les tests de connectivité et Flow Analyzer pour les plages de sous-réseaux IPv4 et IPv6.
  • Les services et les jobs Cloud Run ne sont pas compatibles avec l'entrée VPC directe.

Les éléments suivants ne sont pas compatibles avec la sortie VPC directe :

  • Les journaux de flux VPC n'indiquent pas le nom de la révision Cloud Run.
  • Journalisation des règles de pare-feu VPC
  • Mise en miroir de paquets
  • Tags réseau ou identité de service dans les règles de pare-feu d'entrée.
  • Les règles de pare-feu ne peuvent pas utiliser de tags Resource Manager associés à des charges de travail Cloud Run.
  • Inspection du trafic sortant avec Cloud Next Generation Firewall Enterprise, comme le service de détection et de prévention des intrusions, le service de filtrage des URL et l'inspection TLS.

Allocation d'adresses IP

Pour placer votre service ou votre job Cloud Run service, job ou pool de nœuds de calcul Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau. Cloud Run alloue les adresses IP de votre sous-réseau.

Les adresses IP étant éphémères, ne créez pas de règles basées sur des adresses IP individuelles. Si vous devez créer une règle basée sur les adresses IP, par exemple dans les règles de pare-feu, vous devez utiliser la plage d'adresses IP de l'ensemble du sous-réseau.

Pour modifier le réseau ou le sous-réseau utilisé par votre service , votre job , déployez une nouvelle révision ou exécutez une nouvelle tâche de job utilisant les nouvelles valeurs de réseau et de sous-réseau.

Scaling à la hausse et à la baisse

Pour un scaling plus rapide à la hausse en cas de surcharge du trafic, Cloud Run réserve les adresses IP par blocs de 16 (masque de sous-réseau 28) à la fois. Afficher les adresses IP allouées par Cloud Run Pour vous assurer que vous disposez de suffisamment d'adresses IPv4 à utiliser dans Cloud Run, la plage d'adresses IPv4 de votre sous-réseau doit être /26 ou plus grande.

Pour optimiser l'attribution d'adresses IP et simplifier la gestion, placez plusieurs ressources sur le même sous-réseau. Si votre espace d'adresses IPv4 est limité, consultez la section Plages d'adresses IPv4 compatibles pour plus d'options.

Pour supprimer le sous-réseau, vous devez d'abord supprimer ou redéployer vos services ou jobs Cloud Runservices, jobs afin de cesser d'utiliser le sous-réseau, puis attendre une à deux heures.

Consommation d'adresses IP pour les services

À l'état stable, Cloud Run utilise deux fois (x 2) plus d'adresses IP que le nombre d'instances. Lorsqu'une révision effectue un scaling à la baisse, Cloud Run conserve ses adresses IP pendant 20 minutes au maximum. Au total, réservez au moins deux fois le nombre d'adresses IP, plus une marge pour tenir compte des mises à jour de révision.

Par exemple, si vous mettez à niveau des révisions de sorte que revision 1 passe de 100 instances à zéro tandis que revision 2 passe de zéro à 100, Cloud Run conserve l'adresse IP revision 1 jusqu'à 20 minutes après le scaling à la baisse. Au cours de cet intervalle de 20 minutes, vous devez réserver au moins 400 adresses IP ((100 + 100) * 2).

Consommation d'adresses IP pour les jobs

Pour les jobs Cloud Run, chaque tâche consomme une adresse IP pendant toute la durée de son exécution, plus sept minutes après sa fin. Assurez-vous que votre sous-réseau est suffisamment grand pour prendre en charge toutes les exécutions simultanées de tâches de job, avec un sous-réseau de réservation minimal de /26 requis.

Exemple :

  • Une tâche unique qui s'exécute quotidiennement et se termine toujours au moins sept minutes avant la prochaine exécution consomme au maximum une adresse IP sur le sous-réseau.
  • Une tâche de 10 tâches exécutée toutes les 10 minutes, chaque tâche s'exécutant pendant 15 minutes, consomme une adresse IP pendant 22 minutes par tâche (trois exécutions consomment des adresses IP en même temps), comme indiqué dans l'exemple suivant. Le job consomme donc 30 adresses IP à l'état stable.
  • Un job à tâche unique qui prend une minute à s'exécuter et qui s'exécute 100 fois par minute nécessite environ 800 adresses IP, selon l'heure exacte d'exécution.

Plages IPv4 acceptées

Cloud Run accepte les plages IPv4 suivantes pour votre sous-réseau :

  • RFC 1918
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • RFC 6598
    • 100.64.0.0/10
  • Classe E
    • 240.0.0.0/4

Configurer les autorisations IAM

Assurez-vous que Cloud Run a accès au réseau VPC à l'aide de l'une des méthodes suivantes :

  • Rôle d'agent de service Cloud Run : par défaut, l'agent de service Cloud Run dispose du rôle Agent de service Cloud Run (roles/run.serviceAgent) contenant les autorisations nécessaires.

  • Autorisations personnalisées : pour un contrôle plus précis, accordez à l'agent de service Cloud Run les autorisations supplémentaires suivantes sur le projet :

    • compute.networks.get
    • compute.subnetworks.get
    • compute.subnetworks.use sur le projet ou le sous-réseau spécifique
    • compute.addresses.get
    • compute.addresses.list
    • compute.addresses.create (obligatoire uniquement pour les sous-réseaux à double pile avec IPv6 externe)
    • compute.addresses.delete (obligatoire uniquement pour les sous-réseaux à double pile avec IPv6 externe)
    • compute.addresses.createInternal
    • compute.addresses.deleteInternal
    • compute.regionOperations.get
  • Rôle d'utilisateur de réseau Compute : si vous n'utilisez pas le rôle d'agent de service Cloud Run par défaut ni les autorisations personnalisées, attribuez le rôle d'utilisateur de réseau Compute (roles/compute.networkUser) sur le compte de service de l'agent de service Cloud Run. Les sous-réseaux avec IPv6 externe nécessitent également le rôle Administrateur d'adresse IP publique Compute (roles/compute.publicIpAdmin).

    Par exemple, pour accorder le rôle d'utilisateur du réseau Compute, exécutez la commande suivante :

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:service-PROJECT_NUMBER@serverless-robot-prod.s3ns-system.iam.gserviceaccount.com" \
    --role "roles/compute.networkUser"

    Remplacez les éléments suivants :

    • PROJECT_ID : par l'ID du projet.
    • PROJECT_NUMBER : numéro du projet dans lequel vous déployez votre ressource Cloud Run.

Connecter des ressources Cloud Run à un réseau VPC

Selon la ressource Cloud Run dont vous disposez, consultez les instructions de l'une des sections suivantes :

Connecter un service à un réseau VPC

La sortie directe VPC permet à votre service Cloud Run d'envoyer du trafic vers un réseau VPC sans connecteur d'accès au VPC sans serveur. Les coûts réseau sont réduits à zéro comme le service lui-même. Vous pouvez également ajouter des tags réseau directement sur les révisions du service Cloud Run pour une sécurité réseau plus précise, par exemple en appliquant des règles de pare-feu VPC.

Vous pouvez configurer la sortie directe du VPC avec un service à l'aide de la consoleCloud de Confiance , de Google Cloud CLI, de YAML ou de Terraform.

Console

  1. Dans la console Cloud de Confiance by S3NS , accédez à Cloud Run :

    Accédez à Cloud Run

  2. Cliquez sur Créer un service si vous configurez un nouveau service sur lequel effectuer un déploiement. Si vous configurez et déployez un service existant, cliquez sur ce service.

  3. Si vous configurez un nouveau service, remplissez la page initiale des paramètres du service selon vos besoins, puis cliquez sur Conteneurs, mise en réseau, sécurité pour développer la page de configuration de service.

  4. Cliquez sur l'onglet Réseau.

  5. Cliquez sur Se connecter à un VPC pour le trafic sortant.

  6. Cliquez sur Envoyer le trafic directement à un VPC.

  7. Dans le champ Réseau, sélectionnez le réseau VPC vers lequel vous souhaitez envoyer du trafic.

  8. Dans le champ Sous-réseau, sélectionnez le sous-réseau à partir duquel votre service reçoit des adresses IP. Vous pouvez déployer plusieurs services sur le même sous-réseau.

  9. Facultatif : saisissez les noms des tags réseau que vous souhaitez associer à votre ou vos services. Les tags réseau sont spécifiés au niveau de la révision. Chaque révision de service peut avoir des tags réseau différents, tels que network-tag-2.

  10. Dans le champ Routage du trafic, sélectionnez l'une des options suivantes :

    • N'acheminez que les requêtes adressées à des adresses IP privées vers le VPC pour envoyer uniquement le trafic vers des adresses internes via le réseau VPC.
    • Acheminez tout le trafic vers le VPC pour envoyer tout le trafic sortant via le réseau VPC.
  11. Cliquez sur Créer pour un nouveau service. Cliquez sur Afficher les différences et redéployer, puis sur Déployer les modifications pour un service existant.

  12. Pour vérifier que votre service se trouve sur votre réseau VPC, cliquez sur le service, puis sur l'onglet Mise en réseau. Le réseau et le sous-réseau sont répertoriés dans la fiche VPC.

    Vous pouvez désormais envoyer des requêtes à partir de votre service Cloud Run vers n'importe quelle ressource du réseau VPC, conformément à vos règles de pare-feu.

gcloud

Service

Pour déployer un service Cloud Run sans connecteur à partir de Google Cloud CLI, procédez comme suit :

  1. Mettez à jour les composants gcloud vers la dernière version :

    gcloud components update
  2. Assurez-vous que l'API Compute Engine est activée pour votre projet :

    gcloud services enable compute.googleapis.com
    
  3. Déployez votre service Cloud Run à l'aide de la commande suivante :

    gcloud run deploy SERVICE_NAME \
        --image=IMAGE_URL \
        --network=NETWORK \
        --subnet=SUBNET \
        --network-tags=NETWORK_TAG_NAMES \
        --vpc-egress=EGRESS_SETTING \
        --region=REGION

    Remplacez :

    • SERVICE_NAME par le nom de votre service Cloud Run.
    • IMAGE_URLus-docker.pkg.dev/cloudrun/container/hello:latest. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL est au format LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • NETWORK par le nom de votre réseau VPC ; Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau.
    • SUBNET par le nom de votre sous-réseau. Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
    • Facultatif: NETWORK_TAG_NAMES par les noms des tags réseau séparés par une virgule que vous souhaitez associer à un service. Pour les services, les tags réseau sont spécifiés au niveau de la révision. Chaque révision de service peut avoir des tags réseau différents, tels que network-tag-2.
    • EGRESS_SETTING par une valeur de paramètre de sortie :
      • all-traffic : achemine tout le trafic sortant via le réseau VPC.
      • private-ranges-only : achemine uniquement le trafic destiné à des adresses internes via le réseau VPC.
    • REGION par une région pour votre service.
  4. Pour vérifier que votre service se trouve sur votre réseau VPC, exécutez la commande suivante :

    gcloud run services describe SERVICE_NAME \
        --region=REGION

    Remplacez :

    • SERVICE_NAME par le nom de votre service.
    • REGION par la région du service que vous avez spécifiée à l'étape précédente.

    La sortie doit contenir le nom du réseau, du sous-réseau et du trafic sortant, par exemple :

    VPC access:
      Network:       default
      Subnet:        subnet
      Egress:        private-ranges-only
    

Vous pouvez désormais envoyer des requêtes à partir de votre service Cloud Run vers n'importe quelle ressource du réseau VPC, conformément à vos règles de pare-feu.

Fonction

Pour déployer une fonction Cloud Run sans connecteur à partir de Google Cloud CLI, procédez comme suit :

  1. Mettez à jour les composants gcloud vers la dernière version :

    gcloud components update
  2. Assurez-vous que l'API Compute Engine est activée pour votre projet :

    gcloud services enable compute.googleapis.com
    
  3. Déployez votre fonction Cloud Run à l'aide de la commande suivante :

    gcloud run deploy FUNCTION_NAME \
        --image=IMAGE_URL \
        --network=NETWORK \
        --subnet=SUBNET \
        --network-tags=NETWORK_TAG_NAMES \
        --vpc-egress=EGRESS_SETTING \
        --region=REGION \
        --function=FUNCTION_ENTRYPOINT

    Remplacez :

    • FUNCTION_NAME par le nom de votre fonction Cloud Run.
    • IMAGE_URLus-docker.pkg.dev/cloudrun/container/hello:latest. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL est au format LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
    • NETWORK par le nom de votre réseau VPC ; Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau.
    • SUBNET par le nom de votre sous-réseau. Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
    • Facultatif : NETWORK_TAG_NAMES par les noms des tags réseau séparés par une virgule que vous souhaitez associer à une fonction. Pour les fonctions, les tags réseau sont spécifiés au niveau de la révision. Chaque révision peut avoir des tags réseau différents, tels que network-tag-2.
    • EGRESS_SETTING par une valeur de paramètre de sortie :
      • all-traffic : achemine tout le trafic sortant via le réseau VPC.
      • private-ranges-only : achemine uniquement le trafic destiné à des adresses internes via le réseau VPC.
    • REGION par une région pour votre fonction.
    • Facultatif : FUNCTION_ENTRYPOINT avec le point d'entrée de votre fonction dans votre code source. Il s'agit du code que Cloud Run exécute lorsque votre fonction s'exécute. La valeur de ce flag doit être un nom de fonction ou un nom de classe complet qui existe dans votre code source.
  4. Pour vérifier que votre fonction se trouve sur votre réseau VPC, exécutez la commande suivante :

    gcloud run services describe FUNCTION_NAME \
        --region=REGION

    Remplacez :

    • FUNCTION_NAME par le nom de votre fonction.
    • REGION par la région de votre fonction que vous avez spécifiée à l'étape précédente.

    Le résultat doit contenir le nom de votre réseau, de votre sous-réseau et de votre paramètre de sortie, par exemple :

    VPC access:
      Network:       default
      Subnet:        subnet
      Egress:        private-ranges-only
    

Vous pouvez désormais envoyer des requêtes à partir de votre fonction Cloud Run vers n'importe quelle ressource du réseau VPC, conformément à vos règles de pare-feu.

YAML

  1. Si vous créez un service, ignorez cette étape. Si vous mettez à jour un service existant, téléchargez sa configuration YAML :

    gcloud run services describe SERVICE --format export > service.yaml
  2. Mettez à jour les attributs suivants :

    apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: SERVICE_NAME
        labels:
          cloud.googleapis.com/location: REGION
      spec:
        template:
          metadata:
            annotations:
              run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
              run.googleapis.com/vpc-access-egress: EGRESS_SETTING
          spec:
            containers:
            - image: IMAGE

    Remplacez :

    • SERVICE_NAME par le nom de votre service Cloud Run. Les noms de service doivent comporter un maximum de 49 caractères et être uniques par région et par projet.
    • REGION par la région de votre service Cloud Run, qui doit correspondre à la région de votre sous-réseau.
    • NETWORK par le nom de votre réseau VPC ; Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau.
    • SUBNET par le nom de votre sous-réseau. Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
    • Facultatif: NETWORK_TAG_NAMES par les noms des tags réseau que vous souhaitez associer à un service. Pour les services, les tags réseau sont spécifiés au niveau de la révision. Chaque révision de service peut avoir des tags réseau différents, tels que network-tag-2.
    • EGRESS_SETTING par une valeur de paramètre de sortie :
      • all-traffic : achemine tout le trafic sortant via le réseau VPC.
      • private-ranges-only : achemine uniquement le trafic destiné à des adresses internes via le réseau VPC.
    • IMAGE par l'URL de votre image de conteneur de service.

    Vous pouvez également spécifier d'autres éléments de configuration, tels que des variables d'environnement ou des limites de mémoire.

  3. Créez ou mettez à jour le service à l'aide de la commande suivante :

    gcloud run services replace service.yaml

Terraform

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la page Commandes Terraform de base.

  1. Ajoutez le code ci-dessous à votre fichier main.tf :

    /**
     * Copyright 2024 Google LLC
     *
     * Licensed under the Apache License, Version 2.0 (the "License");
     * you may not use this file except in compliance with the License.
     * You may obtain a copy of the License at
     *
     *      http://www.apache.org/licenses/LICENSE-2.0
     *
     * Unless required by applicable law or agreed to in writing, software
     * distributed under the License is distributed on an "AS IS" BASIS,
     * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
     * See the License for the specific language governing permissions and
     * limitations under the License.
     */
    
    # Example configuration of a Cloud Run service with direct VPC
    
    resource "google_cloud_run_v2_service" "default" {
      name     = "cloudrun-service"
      location = "us-central1"
    
      deletion_protection = false # set to "true" in production
    
      template {
        containers {
          image = "us-docker.pkg.dev/cloudrun/container/hello"
        }
        vpc_access {
          network_interfaces {
            network    = "default"
            subnetwork = "default"
            tags       = ["tag1", "tag2", "tag3"]
          }
        }
      }
    }
    

Vous pouvez éventuellement rendre votre service public si vous souhaitez autoriser un accès non authentifié à celui-ci.

Connecter un job à un réseau VPC

La sortie directe de VPC permet à votre job Cloud Run d'envoyer du trafic vers un réseau VPC sans connecteur d'accès au VPC sans serveur. Vous pouvez également ajouter des tags réseau directement sur les jobs Cloud Run pour une sécurité réseau plus précise, par exemple en appliquant des règles de pare-feu VPC.

Vous pouvez configurer une sortie VPC directe avec un job à l'aide de la consoleCloud de Confiance , de Google Cloud CLI ou de YAML.

Console

  1. Accédez à Cloud Run

  2. Si vous configurez un nouveau job, cliquez sur l'onglet Jobs et remplissez la page des paramètres initiaux du job selon vos besoins. Si vous configurez un job existant, cliquez sur celui-ci, puis sur Modifier.

  3. Cliquez sur Conteneur, variables et secrets, connexions, sécurité pour développer la page des propriétés du job.

  4. Cliquez sur l'onglet Connexions.

  5. Cliquez sur Se connecter à un VPC pour le trafic sortant.

  6. Cliquez sur Envoyer le trafic directement à un VPC.

  7. Dans le champ Réseau, sélectionnez le réseau VPC auquel vous souhaitez envoyer du trafic.

  8. Dans le champ Sous-réseau, sélectionnez le sous-réseau à partir duquel votre job reçoit des adresses IP. Vous pouvez exécuter plusieurs jobs sur le même sous-réseau.

  9. Dans le champ Routage du trafic, sélectionnez l'une des options suivantes :

    • N'acheminez que les requêtes adressées à des adresses IP privées vers le VPC pour envoyer uniquement le trafic vers des adresses internes via le réseau VPC.
    • Acheminez tout le trafic vers le VPC pour envoyer tout le trafic sortant via le réseau VPC.
  10. Facultatif : saisissez les noms des tags réseau que vous souhaitez associer à votre ou vos services. Les tags réseau sont spécifiés au niveau de la révision. Chaque révision de service peut avoir des tags réseau différents, tels que network-tag-2.

  11. Facultatif : saisissez les noms des tags réseau que vous souhaitez associer à votre ou vos jobs. Pour les jobs, les tags réseau sont spécifiés au niveau de l'exécution. Chaque exécution de job peut avoir des tags réseau différents, tels que network-tag-2.

  12. Cliquez sur Créer ou Mettre à jour.

  13. Pour vérifier que votre job se trouve sur votre réseau VPC, cliquez sur le job, puis sur l'onglet Configuration. Le réseau et le sous-réseau sont répertoriés dans la fiche VPC.

    Vous pouvez maintenant exécuter votre job Cloud Run et envoyer des requêtes à partir du job vers n'importe quelle ressource du réseau VPC, conformément à vos règles de pare-feu.

gcloud

Pour créer un job Cloud Run sans connecteur à partir de Google Cloud CLI, procédez comme suit :

  1. Mettez à jour les composants gcloud vers la dernière version :

    gcloud components update
  2. Assurez-vous que l'API Compute Engine est activée pour votre projet :

    gcloud services enable compute.googleapis.com
    
  3. Créez un job Cloud Run à l'aide de la commande suivante :

    gcloud run jobs create JOB_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --vpc-egress=EGRESS_SETTING \
    --region=REGION

    Remplacez :

    • JOB_NAME par le nom de votre job Cloud Run
    • IMAGE_URL : référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/job:latest
    • NETWORK par le nom de votre réseau VPC ; Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau.
    • SUBNET par le nom de votre sous-réseau. Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
    • Facultatif: NETWORK_TAG_NAMES par les noms des tags réseau que vous souhaitez associer à un job. Pour les jobs, les tags réseau sont spécifiés au niveau de l'exécution. Chaque exécution de job peut avoir des tags réseau différents, tels que network-tag-2.
    • EGRESS_SETTING par une valeur de paramètre de sortie :
      • all-traffic : achemine tout le trafic sortant via le réseau VPC.
      • private-ranges-only : achemine uniquement le trafic destiné à des adresses internes via le réseau VPC.
    • REGION par une région pour votre job.
  4. Pour vérifier que le job se trouve sur votre réseau VPC, exécutez la commande suivante :

    gcloud run jobs describe JOB_NAME \
      --region=REGION
      

    Remplacez :

    • JOB_NAME par le nom de votre tâche.
    • REGION par la région de votre job que vous avez spécifié à l'étape précédente.

    Le résultat doit contenir le nom de votre réseau et de votre sous-réseau, par exemple :

    VPC network:
      Network:       default
      Subnet:        default
    

Vous pouvez maintenant exécuter votre job Cloud Run et envoyer des requêtes à partir du job vers n'importe quelle ressource du réseau VPC, conformément à vos règles de pare-feu.

YAML

  1. Si vous créez un job, ignorez cette étape. Si vous mettez à jour un job existant, téléchargez sa configuration YAML :

    gcloud run jobs describe JOB_NAME --format export > job.yaml
  2. Mettez à jour les attributs suivants :

    apiVersion: run.googleapis.com/v1
      kind: Job
      metadata:
        name: JOB_NAME
        labels:
          cloud.googleapis.com/location: REGION
      spec:
        template:
          metadata:
            annotations:
              run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
              run.googleapis.com/vpc-access-egress: EGRESS_SETTING
          spec:
            containers:
            - image: IMAGE

    Remplacez :

    • JOB_NAME par le nom de votre job Cloud Run Les noms de job doivent comporter un maximum de 49 caractères et être uniques par région et par projet.
    • REGION par la région de votre job Cloud Run, qui doit correspondre à la région de votre sous-réseau.
    • NETWORK par le nom de votre réseau VPC ; Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau.
    • SUBNET par le nom de votre sous-réseau. Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
    • Facultatif: NETWORK_TAG_NAMES par les noms des tags réseau que vous souhaitez associer à un job. Pour les jobs, les tags réseau sont spécifiés au niveau de l'exécution. Chaque exécution de job peut avoir des tags réseau différents, tels que network-tag-2.
    • EGRESS_SETTING par une valeur de paramètre de sortie :
      • all-traffic : achemine tout le trafic sortant via le réseau VPC.
      • private-ranges-only : achemine uniquement le trafic destiné à des adresses internes via le réseau VPC.
    • IMAGE par l'URL de votre image de conteneur de job.
  3. Créez ou mettez à jour le job à l'aide de la commande suivante :

    gcloud run jobs replace job.yaml

Configurer une double pile (IPv4 et IPv6)

Pour ajouter un sous-réseau à double pile avec une plage IPv6 sur une ressource Cloud Run, consultez Configurer une double pile.

Restreindre l'accès avec des règles de pare-feu

Limitez l'accès aux ressources d'un réseau VPC à l'aide de règles de pare-feu VPC. Ajoutez ces restrictions en utilisant l'une des stratégies suivantes :

  • Créez une règle de pare-feu d'entrée qui fait référence à votre service ou à votre job à l'aide de la plage d'adresses IP du sous-réseau.
  • Créez une règle de pare-feu de sortie qui fait référence à votre service ou à votre job.

    Dans la règle de pare-feu de sortie, faites référence à votre service ou à votre job en utilisant l'identité de service du compte de service associé, la plage d'adresses IP du sous-réseau ou les tags réseau associés.

Tags réseau pour la sortie

Ajoutez une couche de sécurité réseau supplémentaire en utilisant des tags réseau dans les règles de pare-feu de sortie.

Console

Pour associer des tags réseau à un service ou à un job, procédez comme suit :

  1. Dans la console Cloud de Confiance , accédez à la page Cloud Run.

    Accédez à Cloud Run

  2. Cliquez sur le service ou le job auquel vous souhaitez associer des tags réseau, puis sur Modifier pour les jobs.

  3. Cliquez sur l'onglet Mise en réseau pour les services ou sur l'onglet Connexions pour les jobs.

  4. Assurez-vous d'avoir sélectionné Se connecter à un VPC pour le trafic sortant et Envoyer le trafic directement vers un VPC.

  5. Dans le champ Sous-réseau, sélectionnez le sous-réseau à partir duquel votre service reçoit des adresses IP. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.

  6. Dans le champ Tags réseau, saisissez les noms des tags réseau que vous souhaitez associer à votre service ou à votre job.

  7. Pour les tâches, cliquez sur Mettre à jour. Pour les services, cliquez sur Afficher les différences et redéployer, puis sur Déployer les modifications.

Pour les services, chaque révision peut avoir un ensemble différent de tags réseau, car ceux-ci sont spécifiés au niveau de la révision. Pour un job, une exécution possède les mêmes tags réseau que le job avait lors de la création de l'exécution.

gcloud

Pour associer des tags réseau à un service ou à un job, exécutez la commande gcloud run deploy :

gcloud run deploy SERVICE_JOB_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --region=REGION

Remplacez les éléments suivants :

  • SERVICE_JOB_NAME par le nom de votre service ou de votre job.
  • IMAGE_URL par l'URL de l'image du service ou du job.
  • NETWORK par le nom de votre réseau VPC ;
  • SUBNET par le nom de votre sous-réseau. Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau. Vous pouvez déployer ou exécuter plusieurs services ou jobs sur le même sous-réseau.
  • NETWORK_TAG_NAMES par le nom de votre tag réseau ou liste de tags réseau séparés par une virgule.
  • REGION par le nom de votre région.

Pour les services, chaque révision peut avoir un ensemble différent de tags réseau, car ceux-ci sont spécifiés au niveau de la révision. Pour un job, une exécution possède les mêmes tags réseau que le job avait lors de la création de l'exécution.

Déconnecter une ressource Cloud Run

Selon la ressource Cloud Run dont vous disposez, consultez les instructions de l'une des sections suivantes :

Déconnecter un service

Console

  • Pour supprimer votre service du réseau VPC, procédez comme suit :

    1. Accédez à Cloud Run

    2. Cliquez sur le service.

    3. Cliquez sur l'onglet Réseau.

    4. Désactivez l'option Se connecter à un VPC pour le trafic sortant.

    5. Cliquez sur Afficher les différences et redéployer, puis sur Déployer les modifications.

    6. Pour vérifier que votre service ne se trouve plus sur votre réseau VPC, cliquez sur l'onglet Réseau. Le réseau et le sous-réseau ne sont plus répertoriés dans la fiche VPC.

  • Pour ne supprimer que les tags réseau tout en maintenant le service connecté au réseau VPC, procédez comme suit :

    1. Cliquez sur le service contenant les tags réseau que vous souhaitez supprimer.

    2. Cliquez sur l'onglet Réseau.

    3. Effacez les noms des tags réseau que vous ne souhaitez plus associer à votre service.

    4. Cliquez sur Afficher les différences et redéployer, puis sur Déployer les modifications.

gcloud

  • Pour supprimer votre service du réseau VPC, exécutez la commande suivante :

    gcloud run services update SERVICE_NAME --region=REGION \
    --clear-network
  • Pour ne supprimer que les tags réseau tout en maintenant le service connecté au réseau VPC, exécutez la commande suivante :

    gcloud run services update SERVICE_NAME --region=REGION \
    --clear-network-tags

    Remplacez les éléments suivants :

    • SERVICE_NAME : nom de votre service Cloud Run.
    • REGION : région de votre service Cloud Run.

YAML

  • Pour supprimer votre service du réseau VPC, procédez comme suit :

    1. Téléchargez la configuration YAML du service :

      gcloud run services describe SERVICE_NAME --format export > service.yaml
    2. Supprimez le contenu suivant de votre fichier service.yaml :

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'

      Lieu

      • NETWORK : nom de votre réseau VPC.
      • SUBNET : nom de votre sous-réseau
      • Facultatif : NETWORK_TAG_NAMES : noms des tags réseau si vous les avez associés à un service.
    3. Déployez la révision du service en exécutant la commande suivante :

      gcloud run services replace service.yaml
  • Pour ne supprimer que les tags réseau tout en maintenant le service connecté au réseau VPC, procédez comme suit :

    1. Téléchargez la configuration YAML du service :

      gcloud run services describe SERVICE_NAME --format export > service.yaml
    2. Supprimez la variable tags du contenu de votre fichier service.yaml, en laissant les variables network et subnetwork en place, comme indiqué dans l'exemple suivant :

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'

      Lieu

      • NETWORK : nom de votre réseau VPC.
      • SUBNET : nom de votre sous-réseau
    3. Déployez la révision du service en exécutant la commande suivante :

      gcloud run services replace service.yaml

Déconnecter un job

Console

  • Pour supprimer votre job du réseau VPC, procédez comme suit :

    1. Accédez à Cloud Run

    2. Cliquez sur le job à supprimer, puis sur Modifier et déployer la nouvelle révision.

    3. Cliquez sur l'onglet Connexions.

    4. Désactivez l'option Se connecter à un VPC pour le trafic sortant.

    5. Cliquez sur Mettre à jour.

    6. Pour vérifier que votre job ne se trouve plus sur votre réseau VPC, cliquez sur l'onglet Configuration. Le réseau et le sous-réseau ne sont plus répertoriés dans la fiche VPC.

  • Pour supprimer uniquement les tags réseau tout en maintenant le job connecté au réseau VPC :

    1. Cliquez sur le job contenant les tags réseau à supprimer, puis sur Modifier et déployer la nouvelle révision.

    2. Cliquez sur l'onglet Connexions.

    3. Effacez les noms des tags réseau que vous ne souhaitez plus associer à votre job.

    4. Cliquez sur Mettre à jour.

gcloud

  • Pour supprimer votre job du réseau VPC, exécutez la commande suivante :

    gcloud run jobs update JOB_NAME --region=REGION \
      --clear-network
      
  • Pour ne supprimer que les tags réseau tout en maintenant le job connecté au réseau VPC, exécutez la commande suivante :

    gcloud run jobs update JOB_NAME --region=REGION \
      --clear-network-tags
      

    Remplacez les éléments suivants :

    • JOB_NAME par le nom de votre job Cloud Run
    • REGION : région de votre job Cloud Run.

YAML

  • Pour supprimer votre job du réseau VPC, procédez comme suit :

    1. Téléchargez la configuration YAML du job :

      gcloud run jobs describe JOB_NAME --format export > job.yaml
    2. Supprimez le contenu suivant de votre fichier job.yaml :

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'

      Remplacez les éléments suivants :

      • NETWORK : nom de votre réseau VPC.
      • SUBNET : nom de votre sous-réseau
      • Facultatif : NETWORK_TAG_NAMES par les noms des tags réseau si vous les avez associés à un job.
    3. Mettez à jour le job en exécutant la commande suivante :

      gcloud run jobs replace job.yaml
  • Pour supprimer uniquement les tags réseau tout en maintenant le job connecté au réseau VPC :

    1. Téléchargez la configuration YAML du job :

      gcloud run jobs describe JOB_NAME --format export > job.yaml
    2. Supprimez la variable tags du contenu de votre fichier job.yaml, en laissant les variables network et subnetwork en place, comme indiqué dans l'exemple suivant :

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'

      Remplacez les éléments suivants :

      • NETWORK : nom de votre réseau VPC.
      • SUBNET : nom de votre sous-réseau
    3. Mettez à jour le job en exécutant la commande suivante :

      gcloud run jobs replace job.yaml

Dépannage

Impossible de supprimer le sous-réseau

Pour supprimer un sous-réseau, vous devez d'abord supprimer ou redéployer toutes les ressources qui l'utilisent. Si Cloud Run utilise un sous-réseau, déconnectez le service ou la tâche Cloud Run du réseau VPC ou déplacez-le vers un autre sous-réseau avant de supprimer le sous-réseau.

Le sous-réseau de sortie VPC directe manque d'adresses IPv4

L'erreur suivante se produit lors de votre tentative de déploiement :

Instance failed to start because of insufficient free IP addresses in the
subnetwork SUBNET_ID when attempting to create an address in the
subnetwork. Please consider moving to a subnetwork with more available IP
addresses.

Si le sous-réseau du réseau VPC manque d'adresses IPv4, cela est consigné par Cloud Logging. Lorsque cela se produit, Cloud Run ne peut pas démarrer d'autres instances de service ni tâches de job tant que davantage d'adresses IPv4 ne sont pas disponibles.

Pour résoudre ce problème, suivez les stratégies d'épuisement des adresses IP.

Afficher les adresses IP allouées

Vous ne pouvez pas supprimer manuellement une adresse réservée. L'erreur suivante se produit lorsque vous essayez de supprimer une adresse IP allouée à Cloud Run :

The address resource 'ADDRESS_NAME' is already being used by
'//serverless.googleapis.com/projects/PROJECT_ID/locations/REGION/addressReservations/ADDRESS_NAME'

Pour afficher les adresses IP allouées par Cloud Run, accédez à la page Adresses IP dans la consoleCloud de Confiance et recherchez les adresses pour lesquelles la colonne Utilisée par est définie sur Sans serveur.

Vous pouvez également exécuter la commande suivante à partir de Google Cloud CLI :

gcloud compute addresses list --filter="purpose=SERVERLESS"

Problèmes liés à la MTU personnalisée

Si vous rencontrez des problèmes avec une MTU personnalisée, assurez-vous d'utiliser le paramètre de MTU par défaut pour Cloud Run.