Créer des tests de disponibilité privés

Console Google Cloud

Pour créer un test de disponibilité à l'aide de la console Google Cloud , procédez comme suit:

1. Dans la console Google Cloud , accédez à la page  Tests de disponibilité:

   Accéder à la page Tests de disponibilité

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet Google Cloud . Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.

3. Cliquez sur Create Uptime Check (Créer un test de disponibilité).

   

4. Spécifiez un test de disponibilité privé:

   1. Sélectionnez le protocole, qui peut être HTTP, HTTPS ou TCP.

   2. Sélectionnez le type de ressource Adresse IP interne.

5. Si aucun service d'annuaire des services n'est configuré pour votre projet ou si vous souhaitez en créer un, cliquez sur Afficher, puis remplissez le volet Conditions préalables à la vérification de l'état de disponibilité:

   1. Si vous y êtes invité, activez l'API Compute Engine ou l'API Service Directory. L'activation des API peut prendre une minute.

   2. Développez arrow_drop_down Compte de service, le cas échéant, puis cliquez sur Créer un compte de service.

      Lorsqu'un compte de service de surveillance n'existe pas, un est créé. Ensuite, Monitoring attribue au compte de service deux rôles Service Directory.

   3. Développez le menu arrow_drop_down Service Directory (Répertoire de services), puis procédez comme suit:

      1. Développez arrow_drop_down Région, puis sélectionnez la région de la VM qui traite les requêtes.
      2. Développez arrow_drop_down Espace de noms, puis sélectionnez un espace de noms de l'annuaire des services existant ou cliquez sur Créer un espace de noms et créez-en un.
      3. Cliquez sur Nom du service, puis saisissez un nom de service. Les services sont les cibles des tests de disponibilité privés.
      4. Cliquez sur Nom du point de terminaison, puis saisissez un nom pour le point de terminaison. Un point de terminaison est une paire d'adresse IP et de valeurs de port qu'un service peut utiliser pour traiter les requêtes. Lorsque votre service contient plusieurs points de terminaison, l'un d'entre eux est choisi au hasard.
      5. Développez arrow_drop_down Réseau, puis sélectionnez votre réseau privé.
      6. Développez arrow_drop_down Instance, puis sélectionnez la VM sur le réseau privé qui traite les requêtes. Une fois l'instance sélectionnée, son adresse IP interne s'affiche.
      7. Cliquez sur OK.

   4. Développez arrow_drop_down Règles de pare-feu:

      1. Développez arrow_drop_down Réseau, puis sélectionnez le réseau auquel la règle réseau est associée.

      2. Cliquez sur Créer des règles de pare-feu.

         La règle de pare-feu autorise le trafic TCP entrant à partir des routes 35.199.192.0/19. Une route à partir de 35.199.192.0/19 accepte la connectivité aux cibles de transfert qui utilisent le routage privé. Pour en savoir plus, consultez Routes VPC.

6. Dans le volet Private Uptime Check (Test de disponibilité privé), pour spécifier le service de l'Annuaire des services à utiliser, effectuez l'une des opérations suivantes:

   • Sélectionnez Utiliser le nom complet du service, puis saisissez le nom complet du service:

     projects/SERVICE_DIRECTORY_PROJECT_ID/locations/REGION/namespaces/PRIVATE_NAMESPACE/services/PRIVATE_SERVICE
     

   • Sélectionnez la région, l'espace de noms et le service à l'aide des menus. Si vous avez créé un service, ces champs sont sélectionnés pour vous.

7. Dans le volet Private Uptime Check (Test de disponibilité privé), complétez la description de la cible du test de disponibilité:

   1. Facultatif: saisissez un composant de chemin d'accès pour la requête.

      Les tests de disponibilité privés qui utilisent le protocole HTTP ou HTTPS envoient une requête à http://target/path. Dans cette expression, target correspond à l'adresse IP interne configurée dans le point de terminaison de l'annuaire des services.

      Si vous laissez le champ Chemin d'accès vide ou si vous définissez la valeur sur /, la requête est envoyée à http://target/.

   2. Facultatif: Pour définir la fréquence d'exécution du test de disponibilité, utilisez le champ Check frequency (Fréquence de vérification).

   3. Facultatif: Pour sélectionner des régions de vérification, ou pour configurer l'authentification, les en-têtes pour les vérifications HTTP et HTTPS, et d'autres valeurs, cliquez sur Autres options de cible:

      • Régions : sélectionnez les régions dans lesquelles les tests de disponibilité doivent recevoir des requêtes. Un test de disponibilité doit comporter au moins trois vérificateurs. Il existe un vérificateur dans toutes les régions, à l'exception des États-Unis, qui comporte trois vérificateurs. Le paramètre par défaut, Global, inclut toutes les régions.
      • Méthode de requête: sélectionnez GET ou POST.
      • Body (Corps) : pour les vérifications POST HTTP, saisissez le corps encodé en URL. Vous devez effectuer l'encodage vous-même. Pour toutes les autres vérifications, laissez ce champ vide.
      • En-tête d'hôte: ne définissez pas ce champ lorsque vous configurez des vérifications de disponibilité privées.
      • Port: toute valeur que vous définissez ici remplace le port dans la configuration de votre point de terminaison de l'annuaire des services. Ne définissez pas de valeur ici si vous souhaitez utiliser la configuration du point de terminaison.
      • En-têtes personnalisés: spécifiez des en-têtes personnalisés, et éventuellement chiffrez-les. Le chiffrement masque les valeurs de l'en-tête dans le formulaire. Utilisez le chiffrement pour les en-têtes liés à l'authentification que vous ne souhaitez pas voir visibles par les autres.
      • Authentification : indiquez un seul nom d'utilisateur et un mot de passe. Ces valeurs sont envoyées sous la forme d'un en-tête d'autorisation. Si vous définissez des valeurs dans ce champ, ne définissez pas un en-tête d'autorisation distinct. Inversement, si vous définissez un en-tête d'autorisation, ne définissez aucune valeur dans ce champ. Les mots de passe sont toujours masqués dans le formulaire.

8. Cliquez sur Continuer, puis configurez les exigences concernant les réponses. Tous les paramètres de cette section ont des valeurs par défaut:

   • Pour définir un délai avant expiration pour le test de disponibilité, utilisez le champ Délai avant expiration de la réponse. Un test de disponibilité échoue si aucune réponse n'est reçue de plusieurs emplacements dans ce délai.

   • Pour configurer le test de disponibilité afin d'effectuer une correspondance de contenu, assurez-vous que le libellé d'activation est La correspondance de contenu est activée:

     • Sélectionnez le type de correspondance du contenu de la réponse dans le menu des options. Ce champ détermine comment le contenu de la réponse est comparé aux données renvoyées. Par exemple, supposons que le contenu de la réponse soit abcd et que le type de correspondance de contenu soit Contient. Le test de disponibilité n'aboutit que lorsque les données de réponse contiennent abcd. Pour en savoir plus, consultez Valider les données de réponse.
     • Saisissez le contenu de la réponse. Le contenu de la réponse doit être une chaîne de 1 024 octets maximum. Dans l'API, ce champ est l'objet ContentMatcher.

   • Pour empêcher la création d'entrées de journal en raison de tests de disponibilité, effacez Échecs de vérification du journal.

   • Pour les vérifications de disponibilité HTTP, configurez les codes de réponse acceptés. Par défaut, les tests de disponibilité HTTP marquent toute réponse 2xx comme une réponse réussie.

9. Cliquez sur Continuer, puis configurez les règles d'alerte et les notifications.

   Pour être averti en cas d'échec d'un test de disponibilité, créez une règle d'alerte et configurez des canaux de notification pour cette règle:

   1. Facultatif: modifiez le nom de la règle d'alerte.
   2. Facultatif: Dans le champ Durée, sélectionnez la durée pendant laquelle les tests de disponibilité doivent échouer avant l'envoi de notifications. Par défaut, des notifications sont envoyées lorsqu'au moins deux régions signalent des échecs de test de disponibilité pendant au moins une minute.

   3. Dans la zone Canaux de notification, développez arrow_drop_down Menu, sélectionnez les canaux à ajouter, puis cliquez sur OK.

      Dans le menu, les canaux de notification sont regroupés par ordre alphabétique pour chaque type de canal.

   Si vous ne souhaitez pas créer de règle d'alerte, assurez-vous que le texte du bouton d'activation est Ne pas créer d'alerte.

10. Cliquez sur Continuer et effectuez le test de disponibilité:

    1. Saisissez un titre descriptif pour le test de disponibilité.

    2. Facultatif: Pour ajouter des libellés définis par l'utilisateur à votre test de disponibilité, procédez comme suit:

       1. Cliquez sur expand_more Afficher les étiquettes utilisateur.
       2. Dans le champ Clé, saisissez un nom pour le libellé. Les noms de libellé doivent commencer par une lettre minuscule et peuvent contenir des lettres minuscules, des chiffres, des traits de soulignement et des tirets. Par exemple, saisissez severity.
       3. Dans le champ Valeur, saisissez une valeur pour votre libellé. Les valeurs de libellé peuvent contenir des lettres minuscules, des chiffres, des traits de soulignement et des tirets. Par exemple, saisissez critical.
       4. Pour chaque libellé supplémentaire, cliquez sur Ajouter un libellé utilisateur, puis saisissez la clé et la valeur du libellé.

    3. Pour vérifier la configuration du test disponibilité, cliquez sur Test (Tester). Si le résultat ne correspond pas à vos attentes, consultez la section Dépannage, corrigez votre configuration, puis répétez l'étape de vérification.

    4. Cliquez sur Créer.

API: projet de définition du périmètre

Pour créer la configuration d'un test de disponibilité privé, vous devez créer un objet UptimeCheckConfig et le transmettre à la méthode uptimeCheckConfigs.create dans l'API Cloud Monitoring.

L'objet UptimeCheckConfig d'un test de disponibilité privé diffère de celui d'un test de disponibilité public comme suit:

• La ressource surveillée spécifiée dans la configuration de test de disponibilité doit être de type servicedirectory_service. Ce type de ressource possède les libellés suivants:

  • project_id: ID de projet associé au service Service Directory.
  • location: région cloud associée au service.
  • namespace_name: espace de noms de l'annuaire des services.
  • service_name: nom du service d'annuaire des services.

• Vous n'avez pas besoin de spécifier de valeur port dans la configuration du test de disponibilité. La valeur du port du point de terminaison de l'annuaire des services remplace toute valeur définie dans la configuration de la vérification de l'état de fonctionnement, et la vérification échoue si aucun port n'est spécifié dans la configuration de l'annuaire des services.

• La configuration du test de disponibilité doit spécifier le champ checker_type avec la valeur VPC_CHECKERS. Cette valeur est requise pour les vérifications de disponibilité privées. Par défaut, les tests de disponibilité sont publics. Vous n'avez donc pas besoin de spécifier ce champ.

Le code JSON suivant illustre un objet UptimeCheckConfig pour un test de disponibilité privé à l'aide des ressources de l'annuaire des services configurées pour une instance de VM sur un réseau privé:

{
  "displayName": "private-check-demo",
  "monitoredResource": {
    "type": "servicedirectory_service",
    "labels": {
      "project_id": "SERVICE_DIRECTORY_PROJECT_ID",
      "service_name": "PRIVATE_SERVICE",
      "namespace_name": "PRIVATE_NAMESPACE",
      "location": "REGION"
    }
  },
  "httpCheck": {
    "requestMethod": "GET"
  },
  "period": "60s",
  "timeout": "10s",
  "checker_type": "VPC_CHECKERS"
}'

Pour créer un test de disponibilité privé lorsque le service Service Directory se trouve dans le même Google Cloud projet que le test de disponibilité, procédez comme suit:

1. Définissez le projet Google Cloud par défaut pour la gcloud CLI:

   gcloud config set project PROJECT_ID
   

2. Créez une variable d'environnement destinée à stocker l'ID de votre projet:

   export PROJECT_ID=$(gcloud config get-value core/project)
   

3. Créez une variable d'environnement contenant un jeton d'accès:

   export TOKEN=`gcloud auth print-access-token`
   

4. Utilisez l'outil curl pour appeler la méthode uptimeCheckConfigs.create et y publier un objet de configuration:

   curl https://monitoring.googleapis.com/v3/projects/${PROJECT_ID}/uptimeCheckConfigs \
   -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
   --request POST --data '{
   "displayName": "private-check-demo",
   "monitoredResource": {
     "type": "servicedirectory_service",
     "labels": {
       "project_id": "'"$PROJECT_ID"'",
       "service_name": "PRIVATE_SERVICE",
       "namespace_name": "PRIVATE_NAMESPACE",
       "location": "REGION"
     }
   },
   "httpCheck": {
     "requestMethod": "GET"
   },
   "period": "60s",
   "timeout": "10s",
   "checker_type": "VPC_CHECKERS"
   }'
   

Si la création du test de disponibilité échoue, vérifiez que le compte de service dispose des rôles nécessaires. Pour en savoir plus, consultez Échec de la création d'un test de disponibilité.

API: projet surveillé

Pour créer la configuration d'un test de disponibilité privé, vous devez créer un objet UptimeCheckConfig et le transmettre à la méthode uptimeCheckConfigs.create dans l'API Cloud Monitoring.

L'objet UptimeCheckConfig d'un test de disponibilité privé diffère de celui d'un test de disponibilité public comme suit:

• La ressource surveillée spécifiée dans la configuration de test de disponibilité doit être de type servicedirectory_service. Ce type de ressource possède les libellés suivants:

  • project_id: ID de projet associé au service Service Directory.
  • location: région cloud associée au service.
  • namespace_name: espace de noms de l'annuaire des services.
  • service_name: nom du service d'annuaire des services.

• Vous n'avez pas besoin de spécifier de valeur port dans la configuration du test de disponibilité. La valeur du port du point de terminaison de l'annuaire des services remplace toute valeur définie dans la configuration de la vérification de l'état de fonctionnement, et la vérification échoue si aucun port n'est spécifié dans la configuration de l'annuaire des services.

• La configuration du test de disponibilité doit spécifier le champ checker_type avec la valeur VPC_CHECKERS. Cette valeur est requise pour les vérifications de disponibilité privées. Par défaut, les tests de disponibilité sont publics. Vous n'avez donc pas besoin de spécifier ce champ.

Le code JSON suivant illustre un objet UptimeCheckConfig pour un test de disponibilité privé à l'aide des ressources de l'annuaire des services configurées pour une instance de VM sur un réseau privé:

{
  "displayName": "private-check-demo",
  "monitoredResource": {
    "type": "servicedirectory_service",
    "labels": {
      "project_id": "SERVICE_DIRECTORY_PROJECT_ID",
      "service_name": "PRIVATE_SERVICE",
      "namespace_name": "PRIVATE_NAMESPACE",
      "location": "REGION"
    }
  },
  "httpCheck": {
    "requestMethod": "GET"
  },
  "period": "60s",
  "timeout": "10s",
  "checker_type": "VPC_CHECKERS"
}'

Pour créer un test de disponibilité privé lorsque le service Directory des services se trouve dans un projet Google Cloud supervisé par le champ d'application des métriques du projetGoogle Cloud du test de disponibilité, procédez comme suit:

1. Configurez la CLI gcloud pour qu'elle utilise par défaut le projet Google Cloud dans lequel la vérification de l'état de disponibilité doit être créée:

   gcloud config set project PROJECT_ID
   

2. Créez une variable d'environnement destinée à stocker l'ID de votre projet:

   export PROJECT_ID=$(gcloud config get-value core/project)
   

3. Créez une variable d'environnement pour stocker l'ID de projet du projetGoogle Cloud dans lequel le service Service Directory est défini:

   export MONITORED_PROJECT_ID=MONITORED_PROJECT_ID
   

   Ce projet doit se trouver dans le champ d'application des métriques du projet du test de disponibilité.

4. Créez une variable d'environnement contenant un jeton d'accès:

   export TOKEN=`gcloud auth print-access-token`
   

5. Utilisez l'outil curl pour appeler la méthode uptimeCheckConfigs.create et y publier un objet de configuration:

   curl https://monitoring.googleapis.com/v3/projects/${PROJECT_ID}/uptimeCheckConfigs \
   -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
   --request POST --data '{
   "displayName": "private-check-demo",
   "monitoredResource": {
     "type": "servicedirectory_service",
     "labels": {
       "project_id": "'"$MONITORED_PROJECT_ID"'",
       "service_name": "PRIVATE_SERVICE",
       "namespace_name": "PRIVATE_NAMESPACE",
       "location": "REGION"
     }
   },
   "httpCheck": {
     "requestMethod": "GET"
   },
   "period": "60s",
   "timeout": "10s",
   "checker_type": "VPC_CHECKERS"
   }'
   

Si la création du test de disponibilité échoue, vérifiez que le compte de service dispose des rôles nécessaires. Pour en savoir plus, consultez Échec de la création d'un test de disponibilité.

Console Google Cloud

Lorsque vous utilisez la console Google Cloud , après avoir sélectionné Adresse IP interne comme type de ressource pour un test de disponibilité, vous êtes invité à créer un répertoire de services et un service.

CLI gcloud : VM

Pour en savoir plus sur les commandes utilisées dans ce document pour les services, les espaces de noms et les points de terminaison, consultez le groupe de commandes gcloud service-directory.

Pour créer des ressources de l'annuaire de services pour une VM, procédez comme suit:

1. Configurez la Google Cloud CLI pour qu'elle utilise par défaut le projet Google Cloud dans lequel les ressources du répertoire de services doivent être créées:

   gcloud config set project PROJECT_ID
   

2. Créez des variables d'environnement pour stocker l'ID et le numéro de votre projet:

   export PROJECT_ID=$(gcloud config get-value core/project)
   
   export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')
   

3. Créez un espace de noms de l'annuaire des services:

   gcloud service-directory namespaces create PRIVATE_NAMESPACE --location=REGION
   

4. Créez un service de l'Annuaire des services dans l'espace de noms:

   gcloud service-directory services create PRIVATE_SERVICE \
   --namespace PRIVATE_NAMESPACE --location=REGION
   

5. Créez une variable d'environnement pour contenir l'adresse IP de la VM sur le réseau privé:

   export INTERNAL_IP=$(gcloud compute instances describe --zone=ZONE \
   PRIVATE_SERVICE_INSTANCE --format='get(networkInterfaces[0].networkIP)')
   

6. Créez un point de terminaison de l'annuaire des services contenant l'adresse IP interne et un port:

   gcloud service-directory endpoints create PRIVATE_ENDPOINT \
   --location=REGION --namespace=PRIVATE_NAMESPACE \
   --service=PRIVATE_SERVICE \
   --network=projects/$PROJECT_NUMBER/locations/global/networks/PRIVATE_CHECK_NETWORK \
   --address=$INTERNAL_IP --port=80
   

CLI gcloud : ILB de niveau 4

Pour en savoir plus sur les commandes utilisées dans ce document pour les services, les espaces de noms et les points de terminaison, consultez le groupe de commandes gcloud service-directory.

Vous pouvez utiliser des tests de disponibilité privés pour surveiller la disponibilité d'un équilibreur de charge interne (ILB) de couche 4 en créant des ressources de l'annuaire des services pour l'ILB de couche 4.

Lorsque vous créez des équilibreurs de charge internes de niveau 4, vous pouvez utiliser l'intégration automatique fournie par l'Annuaire des services. Pour en savoir plus, consultez Configurer des équilibreurs de charge internes dans l'Annuaire des services.

Si vous avez créé des ILB L4 sans utiliser l'intégration automatique fournie par l'Annuaire des services, vous pouvez configurer manuellement les ressources de l'Annuaire des services en procédant comme suit:

1. Configurez la Google Cloud CLI pour qu'elle utilise par défaut le projet Google Cloud dans lequel les ressources du répertoire de services doivent être créées:

   gcloud config set project PROJECT_ID
   

2. Créez des variables d'environnement pour stocker l'ID et le numéro de votre projet:

   export PROJECT_ID=$(gcloud config get-value core/project)
   
   export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')
   

3. Pour autoriser tous les vérificateurs de disponibilité à transférer des données vers votre ILB de niveau 4, activez l'accès global à l'ILB:

   gcloud compute forwarding-rules update ILB_FORWARDING_RULE_NAME \
   --region=ILB_REGION --allow-global-access
   

   Si votre équilibreur de charge interne de couche 4 n'autorise pas l'accès mondial, les métriques de disponibilité ne sont disponibles que si ILB_REGION est l'une des valeurs suivantes:

   • us-east4
   • us-central1
   • us-west1
   • europe-west1
   • southamerica-east1
   • asia-southeast1

4. Créez un espace de noms de l'annuaire des services:

   gcloud service-directory namespaces create PRIVATE_NAMESPACE_FOR_ILB\
   --location=REGION
   

5. Créez un service de l'Annuaire des services dans l'espace de noms:

   gcloud service-directory services create PRIVATE_SERVICE_FOR_ILB \
   --namespace PRIVATE_NAMESPACE_FOR_ILB --location=REGION
   

6. Créez une variable d'environnement pour contenir l'adresse IP de l'équilibreur de charge sur le réseau privé:

   export INTERNAL_IP=$( gcloud compute forwarding-rules describe ILB_FORWARDING_RULE_NAME\
   --region=ILB_REGION --format='get(IPAddress)')
   

7. Créez un point de terminaison de l'annuaire des services contenant l'adresse IP interne et un port:

   gcloud service-directory endpoints create PRIVATE_ENDPOINT_FOR_ILB \
   --location=ILB_REGION --namespace=PRIVATE_NAMESPACE_FOR_ILB \
   --service=PRIVATE_SERVICE_FOR_ILB \
   --network=projects/$PROJECT_NUMBER/locations/global/networks/PRIVATE_CHECK_NETWORK \
   --address=$INTERNAL_IP --port=80
   

Console Google Cloud

Lorsque vous utilisez la console Google Cloud , après avoir sélectionné Adresse IP interne comme type de ressource pour un test de disponibilité, vous êtes invité à autoriser le compte de service.

API: projet de définition du périmètre

Pour attribuer les rôles du service Directory à un compte de service existant, procédez comme suit:

1. Configurez la CLI gcloud pour qu'elle utilise par défaut le projet Google Cloud dans lequel la vérification de l'état de disponibilité doit être créée:

   gcloud config set project PROJECT_ID
   

2. Créez des variables d'environnement pour stocker l'ID et le numéro du projet:

   export PROJECT_ID=$(gcloud config get-value core/project)
   
   export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')
   

3. Exécutez les commandes suivantes :

   gcloud projects add-iam-policy-binding $PROJECT_ID \
   --member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
   --role='roles/servicedirectory.viewer'
   

   gcloud projects add-iam-policy-binding $PROJECT_ID \
   --member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
   --role='roles/servicedirectory.pscAuthorizedService'
   

   Les commandes précédentes attribuent les rôles suivants au compte de service:

   • roles/servicedirectory.viewer
   • roles/servicedirectory.pscAuthorizedService

API: projet surveillé

Pour attribuer les rôles du service Directory à un compte de service existant, procédez comme suit:

1. Configurez la CLI gcloud pour qu'elle utilise par défaut le projet Google Cloud dans lequel la vérification de l'état de disponibilité doit être créée:

   gcloud config set project PROJECT_ID
   

2. Créez des variables d'environnement pour stocker l'ID et le numéro du projet:

   export PROJECT_ID=$(gcloud config get-value core/project)
   
   export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')
   

3. Créez une variable d'environnement contenant l'ID du projet dans lequel le service Service Directory est défini:

   export MONITORED_PROJECT_ID=MONITORED_PROJECT_ID
   

   Ce projet doit se trouver dans le champ d'application des métriques du projet du test de disponibilité.

4. Créez une variable d'environnement contenant l'ID du projet dans lequel le réseau est défini:

   export NETWORK_PROJECT_ID=NETWORK_PROJECT_ID
   

   Ce projet ne doit pas nécessairement être inclus dans le champ d'application des métriques du projet de vérification de l'état de fonctionnement.

5. Exécutez les commandes suivantes :

   gcloud projects add-iam-policy-binding $MONITORED_PROJECT_ID \
   --member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
   --role='roles/servicedirectory.viewer'
   

   gcloud projects add-iam-policy-binding $NETWORK_PROJECT_ID \
   --member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
   --role='roles/servicedirectory.pscAuthorizedService'
   

   Les commandes précédentes attribuent les rôles suivants au compte de service:

   • roles/servicedirectory.viewer pour le projet surveillé dans lequel le service d'annuaire des services est configuré, $SERVICE_MONITORED_PROJECT_ID.
   • roles/servicedirectory.pscAuthorizedService pour le projet dans lequel le réseau privé est configuré, $NETWORK_PROJECT_ID.

Console Google Cloud

Lorsque vous utilisez la console Google Cloud , après avoir sélectionné Adresse IP interne comme type de ressource pour un test de disponibilité, vous êtes invité à configurer les règles de pare-feu.

CLI gcloud

Pour créer une règle de pare-feu qui autorise le trafic TCP entrant via le pare-feu pour l'accès au réseau privé, exécutez la commande suivante:

1. Configurez la CLI gcloud pour qu'elle utilise par défaut le projet Google Cloud dans lequel la vérification de l'état de disponibilité doit être créée:

   gcloud config set project PROJECT_ID
   

2. Créez des variables d'environnement pour stocker l'ID et le numéro du projet:

   export PROJECT_ID=$(gcloud config get-value core/project)
   

3. Créez la règle réseau:

   gcloud compute firewall-rules create PRIVATE_CHECK_NETWORK_HOPE_RULE \
   --network="PRIVATE_CHECK_NETWORK"  \
   --action=allow   --direction=ingress   --source-ranges="35.199.192.0/19" \
   --rules=tcp   --project="$PROJECT_ID"
   

   Dans la commande précédente, PRIVATE_CHECK_NETWORK correspond au réseau auquel cette règle est associée, tandis que PRIVATE_CHECK_NETWORK_HOPE_RULE est le nom de la règle de pare-feu.

Pour en savoir plus sur cette étape, consultez la section Configurer le projet de réseau.

Console Google Cloud

Lorsque vous utilisez la console Google Cloud pour créer le test de disponibilité privé, la console Google Cloud émet les commandes permettant d'attribuer les rôles de l'annuaire des services au compte de service.

Pour savoir comment attribuer des rôles à un compte de service, consultez la section Autoriser le compte de service.

API: projet de définition du périmètre

La première fois que vous créez une vérification de l'état de disponibilité privée pour un service de l'annuaire des services et des ressources privées dans un seul projet Google Cloud , la requête peut réussir ou échouer. Le résultat dépend de la désactivation ou non des attributions automatiques de rôles pour les comptes de service dans votre projet:

• La première création de vérification de l'état de fonctionnement aboutit si votre projet autorise l'attribution automatique de rôles aux comptes de service. Un compte de service est créé pour vous et se voit attribuer les rôles nécessaires.

• La première création de vérification de l'état échoue si votre projet n'autorise pas les attributions automatiques de rôles aux comptes de service. Un compte de service est créé, mais aucun rôle n'est attribué.

Si la création du test de disponibilité échoue, procédez comme suit:

1. Autorisez le compte de service.
2. Attendez quelques minutes que les autorisations soient propagées.
3. Essayez de créer à nouveau le test de disponibilité privé.

API: projet surveillé

La première fois que vous créez une vérification de l'état de disponibilité privée qui cible un service de répertoire de services dans un projet surveillé ou des ressources privées dans un autre projet, la requête échoue et un compte de service Monitoring est créé. Google Cloud

La façon dont vous autorisez le compte de service dépend du nombre de projetsGoogle Cloud que vous utilisez et de leurs relations. Vous pouvez être impliqué dans quatre projets au maximum:

• Projet dans lequel vous avez défini le test de disponibilité privé.
• Projet surveillé dans lequel vous avez configuré le service Directory des services.
• Projet dans lequel vous avez configuré le réseau VPC.
• Projet dans lequel des ressources réseau telles que des VM ou des équilibreurs de charge sont configurées. Ce projet n'a aucun rôle dans l'autorisation de compte de service abordée ici.

Lorsque la création du premier test de disponibilité échoue, procédez comme suit:

1. Autorisez le compte de service.
2. Attendez quelques minutes que les autorisations soient propagées.
3. Essayez de créer à nouveau le test de disponibilité privé.