Vérifications d'état de conteneur (services)

Vous pouvez configurer des vérifications de démarrage HTTP, TCP et gRPC, ainsi que des vérifications d'activité HTTP et gRPC pour les services Cloud Run nouveaux et existants. La configuration varie en fonction du type de vérification.

Notez qu'une vérification de démarrage TCP est automatiquement configurée pour un nouveau service Cloud Run. Pour en savoir plus, consultez la section Vérification de démarrage TCP par défaut.

Cas d'utilisation

Vous pouvez configurer deux types de tests de vérification d'état :

  • Les vérifications d'activité déterminent s'il faut redémarrer un conteneur.

    • Dans ce cas, le redémarrage d'un conteneur peut augmenter la disponibilité du service en cas de bugs.
    • Les vérifications d'activité sont destinées à redémarrer des instances individuelles qui ne peuvent pas être récupérées d'une autre manière. Elles doivent principalement être utilisées en cas de défaillance d'instance irrécupérable, par exemple pour détecter un interblocage où un service est en cours d'exécution, mais ne peut pas progresser.

  • Les vérifications de démarrage déterminent si le conteneur a démarré et est prêt à accepter le trafic.

    • Lorsque vous configurez une vérification de démarrage, les vérifications d'activité sont désactivées jusqu'à ce que la vérification de démarrage détermine que le conteneur est démarré, afin d'éviter toute interférence avec le démarrage du service.
    • Les vérifications de démarrage sont particulièrement utiles si vous utilisez des contrôles d'activité sur des conteneurs à démarrage lent, car elles les empêchent de s'arrêter prématurément avant que les conteneurs ne soient opérationnels.

Sachez que lorsqu'un service rencontre des échecs répétés de démarrage ou de vérification d'activité, Cloud Run limite les redémarrages d'instances pour éviter les boucles de plantage non contrôlées.

Vérification de démarrage TCP par défaut

Une vérification de démarrage TCP est automatiquement configurée pour un nouveau service Cloud Run avec des valeurs par défaut. La vérification par défaut est équivalente à la suivante :

startupProbe:
  tcpSocket:
    port: CONTAINER_PORT
  timeoutSeconds: 240
  periodSeconds: 240
  failureThreshold: 1

Remplacez CONTAINER_PORT par le port de conteneur défini pour votre service.

Vous pouvez modifier ces valeurs par défaut en suivant les instructions de la section Configuration de la vérification sur la présente page.

Facturation et allocation de processeurs

  • Les processeurs sont alloués à chaque vérification.
  • Toutes les vérifications sont facturées pour l'utilisation de la mémoire et des processeurs, mais il n'y a pas de frais basés sur les requêtes.

Exigences et comportement de vérification

Type de vérification Conditions requises Comportement
Démarrage TCP Aucune Par défaut, Cloud Run établit une connexion TCP pour ouvrir le socket TCP sur le port spécifié. Si Cloud Run ne parvient pas à établir une connexion, cela indique un échec.

Si une vérification de démarrage n'aboutit pas dans le délai spécifié (failureThreshold * periodSeconds), qui ne peut pas dépasser 240 secondes, le conteneur est arrêté. Consultez également la section Valeurs TCP par défaut.
Démarrage HTTP Créez un point de terminaison de vérification d'état HTTP
Utilisez HTTP/1		 Après la configuration de la vérification, Cloud Run envoie une requête HTTP GET au point de terminaison de la vérification d'état du service (par exemple, /ready). Toute réponse comprise entre 200 et 400 indique un succès, toute autre réponse indique un échec.

Si une vérification de démarrage n'aboutit pas dans le délai spécifié (failureThreshold * periodSeconds ), qui ne peut pas dépasser 240 secondes, le conteneur est arrêté.

Si la vérification de démarrage HTTP réussit dans le délai spécifié et que vous avez configuré une vérification d'activité HTTP, celle-ci est démarrée.
Activité HTTP Créez un point de terminaison de vérification d'état HTTP
Utilisez HTTP/1		 La vérification d'activité ne démarre qu'une fois la vérification de démarrage réussie. Une fois que la vérification est configurée et qu'une vérification de démarrage réussit, Cloud Run envoie une requête HTTP GET au point de terminaison de vérification d'état du service (par exemple, /health). Toute réponse comprise entre 200 et 400 indique un succès, toute autre réponse indique un échec.

Si une vérification d'activité n'aboutit pas dans le délai spécifié (failureThreshold * periodSeconds ), le conteneur est arrêté à l'aide d'un signal SIGKILL. Toute requête restante encore diffusée par le conteneur est interrompue par le code d'état HTTP 503. Une fois le conteneur arrêté, l'autoscaling Cloud Run démarre une nouvelle instance de conteneur.
Démarrage gRPC Mettez en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run. Si une vérification de démarrage échoue dans le délai spécifié (failureThreshold * periodSeconds), qui ne peut pas dépasser 240 secondes, le conteneur est arrêté.
Activité gRPC Mettez en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run. Si vous configurez une vérification de démarrage gRPC, la vérification d'activité ne commence qu'une fois la vérification de démarrage réussie.

Une fois la vérification d'activité configurée et une vérification de démarrage réussie, Cloud Run envoie une requête de vérification d'état au service.

Si une vérification d'activité échoue dans le délai spécifié (failureThreshold * periodSeconds), le conteneur est arrêté à l'aide d'un signal SIGKILL. Une fois le conteneur arrêté, l'autoscaling Cloud Run démarre une nouvelle instance de conteneur.

Configurer des vérifications

Tout changement de configuration entraîne la création d'une révision. Les révisions ultérieures obtiennent aussi automatiquement le même paramètre de configuration, à moins que vous ne le mettiez explicitement à jour.

Vous pouvez configurer des vérifications HTTP, TCP et gRPC à l'aide de la console Google Cloud, de YAML ou de Terraform :

Console

Important : si vous configurez votre service Cloud Run pour les vérifications HTTP, vous devez également ajouter un point de terminaison de vérification d'état HTTP dans votre code de service pour répondre à la vérification. Si vous configurez une vérification gRPC, vous devez également mettre en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run.

  1. Dans Google Cloud Console, accédez à la page Cloud Run.

    Accédez à Cloud Run

  2. Pour un nouveau service, développez Conteneur(s), volumes, mise en réseau et sécurité pour afficher les options de vérification d'état. Pour un service existant, cliquez sur le service que vous souhaitez configurer, puis sur Modifier et déployer pour afficher les options de vérification d'état.

  3. Dans la section Conteneur(s) accédez à Vérifications d'état puis cliquez sur Ajouter une vérification d'état afin d'ouvrir le panneau de configuration Ajouter une vérification d'état.

  4. Dans le menu Sélectionner le type de vérification d'état, sélectionnez le type de vérification d'état que vous souhaitez ajouter, par exemple démarrage ou activité.

  5. Dans le menu Sélectionner un type de vérification, sélectionnez le type de vérification que vous souhaitez utiliser, par exemple HTTP ou gRPC. Le formulaire de configuration de vérification s'affiche.

  6. Notez que la configuration de vérification varie selon le type de vérification. Configurez les paramètres de la vérification :

    • Si vous utilisez des vérifications HTTP :
      • Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.
      • Utilisez le champ Chemin d'accès pour spécifier le chemin d'accès relatif au point de terminaison (par exemple, /).
      • Cochez la case En-têtes HTTP pour spécifier des en-têtes personnalisés facultatifs. Spécifiez ensuite le nom de l'en-tête dans le champ Nom et la valeur de l'en-tête dans le champ Valeur. Cliquez sur Ajouter un en-tête HTTP pour spécifier d'autres en-têtes.
    • Pour le champ Port, spécifiez le port de conteneur utilisé pour votre service.
    • Dans le champ Délai initial, spécifiez le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 et 240 secondes. La valeur par défaut est de 0 seconde.
    • Dans le champ Période, spécifiez la périodicité (en secondes) à laquelle effectuer la vérification. Par exemple, 2 pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 240 secondes. La valeur par défaut est de 10 secondes.
    • Pour Seuil d'échec, spécifiez le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
    • Dans le champ Délai avant expiration, spécifiez le nombre de secondes d'attente avant expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour periodSeconds. Définissez une valeur comprise entre 1 et 240. La valeur par défaut est 1.

  7. Cliquez sur Ajouter pour ajouter le nouveau seuil.

YAML

Important : si vous configurez votre service Cloud Run pour les vérifications HTTP, vous devez également ajouter un point de terminaison dans votre code de service pour répondre à la vérification. Si vous configurez une vérification gRPC, vous devez également mettre en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run.

Démarrage TPC

  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. Configurez l'attribut startupProbe comme indiqué ci-dessous :

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: SERVICE
spec:
 template:
   metadata:
   spec:
     containers:
     - image: IMAGE_URL
       startupProbe:
         tcpSocket:
           port: CONTAINER_PORT
         initialDelaySeconds: DELAY
         timeoutSeconds: TIMEOUT
         failureThreshold: THRESHOLD
         periodSeconds: PERIOD

    Remplacer

    • SERVICE par le nom de votre service Cloud Run ;
    • IMAGE_URL par une référence à l'image de conteneur, par exemple us-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 se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
    • DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 seconde et 240 secondes. La valeur par défaut est de 0 seconde.
    • (FACULTATIF) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour periodSeconds. Définissez une valeur comprise entre 1 et 240. La valeur par défaut est 1.
    • THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
    • PERIOD par le délai (en secondes) auquel effectuer la vérification. Par exemple, 2 pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 seconde et 240 secondes. La valeur par défaut est de 10 secondes.
  3. Créez ou mettez à jour le service à l'aide de la commande suivante : 
    gcloud run services replace service.yaml

Démarrage HTTP

  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. Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.

  3. Configurez l'attribut startupProbe comme indiqué ci-dessous :

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
    spec:
      containers:
      - image: IMAGE_URL
        startupProbe:
          httpGet:
            path: PATH
            port: CONTAINER_PORT
            httpHeaders:
              - name: HEADER_NAME
                value: HEADER_VALUE
          initialDelaySeconds: DELAY
          timeoutSeconds: TIMEOUT
          failureThreshold: THRESHOLD
          periodSeconds: PERIOD

    replace

    • SERVICE par le nom de votre service Cloud Run ;
    • IMAGE_URL par une référence à l'image de conteneur, par exemple us-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 se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • PATH par le chemin relatif au point de terminaison HTTP, par exemple, /ready.
    • (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
    • (FACULTATIF) httpHeaders peut être utilisé pour fournir des en-têtes personnalisés multiples ou répétés à l'aide des champs HEADER_NAME et HEADER_VALUE, comme indiqué.
    • (FACULTATIF) DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 seconde et 240 secondes. La valeur par défaut est de 0 seconde.
    • (FACULTATIF) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour periodSeconds. Définissez une valeur comprise entre 1 et 240. La valeur par défaut est 1.
    • (FACULTATIF) THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
    • (FACULTATIF) PERIOD par le délai (en secondes) auquel effectuer la vérification. Par exemple, 2 pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 240 secondes. La valeur par défaut est de 10 secondes.
  4. Créez ou mettez à jour le service à l'aide de la commande suivante : 
    gcloud run services replace service.yaml

Activité HTTP

  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. Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.

  3. Configurez l'attribut livenessProbe comme indiqué ci-dessous :

    apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: SERVICE
  spec:
    template:
      metadata:
      spec:
        containers:
        - image: IMAGE_URL
          livenessProbe:
            httpGet:
              path: PATH
              port: CONTAINER_PORT
              httpHeaders:
                - name: HEADER_NAME
                  value: HEADER_VALUE
            initialDelaySeconds: DELAY
            timeoutSeconds: TIMEOUT
            failureThreshold: THRESHOLD
            periodSeconds: PERIOD

    Remplacer

    • SERVICE par le nom de votre service Cloud Run ;
    • IMAGE_URL par une référence à l'image de conteneur, par exemple us-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 se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • PATH par le chemin relatif au point de terminaison HTTP, par exemple, /ready.
    • (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
    • (FACULTATIF) httpHeaders peut être utilisé pour fournir des en-têtes personnalisés multiples ou répétés à l'aide des champs HEADER_NAME et HEADER_VALUE, comme indiqué.
    • (FACULTATIF) DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 seconde et 240 secondes. La valeur par défaut est de 0 seconde.
    • (FACULTATIF) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour periodSeconds. Définissez une valeur comprise entre 1 et 3 600. La valeur par défaut est 1.
    • (FACULTATIF) THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
    • (FACULTATIF) PERIOD par le délai (en secondes) auquel effectuer la vérification. Par exemple, 2 pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 3 600 secondes. La valeur par défaut est de 10 secondes.
  4. Créez ou mettez à jour le service à l'aide de la commande suivante : 
    gcloud run services replace service.yaml

Démarrage gRPC

  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. Configurez l'attribut startupProbe comme indiqué ci-dessous :

    apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: SERVICE
  spec:
    template:
      metadata:
      spec:
        containers:
        - image: IMAGE_URL
          startupProbe:
            grpc:
              service: GRPC_SERVICE
              port: CONTAINER_PORT
            initialDelaySeconds: DELAY
            timeoutSeconds: TIMEOUT
            failureThreshold: THRESHOLD
            periodSeconds: PERIOD

    Remplacer

    • SERVICE par le nom de votre service Cloud Run ;
    • IMAGE_URL par une référence à l'image de conteneur, par exemple us-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 se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • GRPC_SERVICE par le nom du service gRPC auquel envoyer la vérification d'état.
    • (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
    • (FACULTATIF) DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 et 240 secondes. La valeur par défaut est de 0 seconde.
    • (Facultatif) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour periodSeconds. Définissez une valeur comprise entre 1 et 240. La valeur par défaut est 1.
    • (FACULTATIF) THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
    • (FACULTATIF) PERIOD par le délai (en secondes) auquel effectuer la vérification. Par exemple, 2 pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 240 secondes. La valeur par défaut est de 10 secondes.
  3. Créez ou mettez à jour le service à l'aide de la commande suivante : 
    gcloud run services replace service.yaml

Activité gRPC

  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. Configurez l'attribut livenessProbe comme indiqué ci-dessous :

    apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: SERVICE
  spec:
    template:
      metadata:
      spec:
        containers:
        - image: IMAGE_URL
          livenessProbe:
            grpc:
              port: CONTAINER_PORT
              service: GRPC_SERVICE
            initialDelaySeconds: DELAY
            timeoutSeconds: TIMEOUT
            failureThreshold: THRESHOLD
            periodSeconds: PERIOD

    Remplacer

    • SERVICE par le nom de votre service Cloud Run ;
    • IMAGE_URL par une référence à l'image de conteneur, par exemple us-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 se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • (FACULTATIF) CONTAINER_PORT doit être défini sur le port de conteneur utilisé pour votre service.
    • GRPC_SERVICE par le nom du service gRPC auquel envoyer la vérification d'état.
    • (FACULTATIF) DELAY par le nombre de secondes d'attente après le démarrage du conteneur avant d'effectuer la première vérification. Spécifiez une valeur comprise entre 0 seconde et 240 secondes. La valeur par défaut est de 0 seconde.
    • (FACULTATIF) TIMEOUT par le nombre de secondes d'attente jusqu'à l'expiration de la vérification. Cette valeur ne peut pas dépasser la valeur spécifiée pour periodSeconds. Définissez une valeur comprise entre 1 et 3 600. La valeur par défaut est 1.
    • (FACULTATIF) THRESHOLD par le nombre de tentatives d'exécution de la vérification à effectuer avant d'arrêter le conteneur. La valeur par défaut est "3".
    • (FACULTATIF) PERIOD par le délai (en secondes) auquel effectuer la vérification. Par exemple, 2 pour effectuer la vérification toutes les deux secondes. Spécifiez une valeur comprise entre 1 et 3 600 secondes. La valeur par défaut est de 10 secondes.
  3. Créez ou mettez à jour le service à l'aide de la commande suivante : 
    gcloud run services replace service.yaml

Terraform

Important : si vous configurez votre service Cloud Run pour les vérifications HTTP, vous devez également ajouter un point de terminaison dans votre code de service pour répondre à la vérification. Si vous configurez une vérification gRPC, vous devez également mettre en œuvre le protocole de vérification d'état gRPC dans votre service Cloud Run.

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

Démarrage TCP

Configurez votre service Cloud Run avec l'attribut startup_probe comme indiqué ci-dessous :

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        tcp_socket {
          port = 8080
        }
      }
    }
  }
}

Démarrage HTTP

Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.

Configurez votre service Cloud Run avec l'attribut startup_probe comme indiqué ci-dessous :

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        http_get {
          path = "/"
          # Custom headers to set in the request
          # https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service#http_headers
          http_headers {
            name  = "Access-Control-Allow-Origin"
            value = "*"
          }
        }
      }
    }
  }
}

Activité HTTP

Assurez-vous que votre service utilise HTTP/1 (valeur par défaut de Cloud Run) et non HTTP/2.

Configurez votre service Cloud Run avec l'attribut liveness_probe comme indiqué ci-dessous :

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      liveness_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        http_get {
          path = "/"
          # Custom headers to set in the request
          # https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service#http_headers
          http_headers {
            name  = "Access-Control-Allow-Origin"
            value = "*"
          }
        }
      }
    }
  }
}

Démarrage gRPC

Configurez votre service Cloud Run avec l'attribut startup_probe comme indiqué ci-dessous :

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      # Note: Change to the name of your image
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        grpc {
          # Note: Change to the name of your pre-existing grpc health status service
          service = "grpc.health.v1.Health"
        }
      }
    }
  }
}

Activité gRPC

Configurez votre service Cloud Run avec l'attribut liveness_probe comme indiqué ci-dessous :

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      # Note: Change to the name of your image
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      liveness_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        # Note: Change to the name of your pre-existing grpc health status service
        grpc {
          service = "grpc.health.v1.Health"
        }
      }
    }
  }
}

Créer des points de terminaison HTTP de vérification d'état

Si vous configurez votre service Cloud Run pour une vérification de démarrage HTTP ou une vérification d'activité, vous devez ajouter un point de terminaison dans votre code de service pour répondre à la vérification. Le point de terminaison peut porter n'importe quel nom, par exemple /startup ou /ready, mais il doit correspondre aux valeurs que vous spécifiez pour path dans la configuration de la vérification. Par exemple, si vous spécifiez /ready pour une vérification de démarrage HTTP, vous spécifiez path dans votre configuration de vérification, comme indiqué ci-dessous :

startupProbe:
  httpGet:
    path: /ready

Les points de terminaison HTTP de vérification d'état sont accessibles en externe et suivent les mêmes principes que tous les autres points de terminaison de service HTTP exposés en externe.