Créer des tests de disponibilité privés

Ce document explique comment configurer un test de disponibilité privé. Les tests de disponibilité privés activent les requêtes HTTP ou TCP dans un client cloud privé virtuel (VPC) tout en appliquant les restrictions liées à Identity and Access Management (IAM) et Périmètres VPC Service Controls. Les tests de disponibilité privés peuvent envoyer des requêtes aux ressources via le réseau privé comme une machine virtuelle (VM) ou un équilibreur de charge interne (ILB) de couche 4.

Les adresses IP internes des ressources sur le réseau privé sont enregistrées les services de l'Annuaire des services avec accès à un réseau privé activé. Pour utiliser un temps d'activité privé vous devez configurer l'accès au réseau privé en utilisant Produit de l'Annuaire des services.

Le projet Google Cloud qui stocke le test de disponibilité privé le projet Google Cloud qui stocke l'annuaire des services peuvent être des projets différents. Cloud Monitoring vous permet de surveiller des ressources dans plusieurs projets Google Cloud d'un seul projet en utilisant un champ d'application des métriques. Le projet dans lequel le test de disponibilité est défini d'un champ d'application des métriques ; le champ d'application des métriques est une liste de tous les projets surveillés par le projet effectuant une surveillance. Le service de l'Annuaire des services peut être défini ou dans un projet dans le champ d'application des métriques. Pour en savoir plus sur les champs d'application des métriques, consultez Présentation des champs d'application des métriques

Le réseau privé et ses ressources, telles que les VM ou les équilibreurs de charge, peuvent ou se trouver dans un autre projet Google Cloud. Ce projet ne comporte pas dans le champ d'application des métriques du projet effectuant une surveillance. Le service de l'Annuaire des services collecte les métriques de temps d'activité, elle doit faire partie du champ d'application des métriques, mais pas les ressources qu'il encapsule.

Ce document explique comment mettre en place un réseau privé et configurer les ressources associées à l'Annuaire des services à l'aide de la console Google Cloud. ou l'API. Les exemples d'API partent du principe que le réseau privé et le service de l'Annuaire des services le projet effectuant une surveillance du test de disponibilité. Toutefois, Créer une configuration test de disponibilité décrit également comment utiliser l'API pour créer un test de disponibilité qui utilise un service de l'Annuaire des services le champ d'application des métriques.

Pour savoir comment configurer des tests de disponibilité qui utilisent des données adresses IP, consultez la page Créer des tests de disponibilité publics. Pour en savoir plus sur la gestion et la surveillance des tests de disponibilité, consultez la Étapes suivantes de ce document.

Avant de commencer

  1. Activez les API suivantes :

    • API Cloud Monitoring : monitoring.googleapis.com
    • API de l'Annuaire des services: servicedirectory.googleapis.com
    • API Service Networking: servicenetworking.googleapis.com
    • API Compute Engine: compute.googleapis.com

    Vous pouvez activer les API à l'aide de gcloud CLI ou de la console Google Cloud. Les onglets suivants décrivent la procédure d'installation gcloud CLI et activez l'API Cloud Monitoring:

    console Google Cloud

    1. Dans la console Google Cloud, sélectionnez le projet Google Cloud pour pour lequel vous souhaitez activer l'API, puis accédez à la section API et Services:

      Accédez à la page API et Services

    2. Cliquez sur le bouton Activer des API et des services.

    3. Recherchez "Monitoring".

    4. Dans les résultats de recherche, cliquez sur "API Cloud Monitoring".

    5. Si "API activée" s'affiche, cela signifie que l'API est déjà activée. Si pas, puis cliquez sur Activer.

    CLI gcloud

    1. Si vous n'avez pas encore installé la Google Cloud CLI sur votre station de travail, voir Installer la gcloud CLI

    2. Pour voir si l'API Monitoring est activée, exécutez la commande suivante : sur votre poste de travail, après avoir remplacé PROJECT_ID par le ID du projet pour lequel vous souhaitez activer l'API:

      gcloud services list --project=PROJECT_ID
      

      Si monitoring.googleapis.com apparaît dans le résultat, l'API est activée.

    3. Si l'API n'est pas activée, exécutez la commande suivante pour l'activer:

      gcloud services enable monitoring --project=PROJECT_ID
      

      Pour en savoir plus, consultez les sections sur gcloud services

    Vous pouvez suivre la même procédure pour activer les autres API:

    • Pour utiliser la console Google Cloud, recherchez le nom à afficher. Par exemple : "API de l'Annuaire des services".
    • Pour utiliser la gcloud CLI, spécifiez le premier élément de la Nom de googleapis.com (par exemple, servicedirectory)
  2. Configurez les canaux de notification que vous souhaitez utiliser pour recevoir des notifications. Nous vous recommandons de créer plusieurs types de notifications canaux de distribution. Pour en savoir plus, consultez Créer et gérer des canaux de notification

  3. Configurer un réseau privé et configurer une VM ou un ILB pour qu'il ait l'accès à ce réseau privé. Pour en savoir plus, consultez la section Accès aux services privés.

    Les vérifications privées ciblant les équilibreurs de charge internes sont limitées à des régions avec des vérificateurs de disponibilité. La région USA du test de disponibilité inclut USA_OREGON, USA_IOWA et USA_VIRGINIA. Chacun des USA_* régions dispose d'un vérificateur, et USA inclut les trois. Les autres régions où les tests de disponibilité EUROPE, SOUTH_AMERICA et ASIA_PACIFIC, chacun en possède un vérificateur. Pour supprimer cette limitation, vous devez configurer un accès global à votre équilibreur de charge. Pour en savoir plus sur la configuration de l'accès mondial, consultez l'onglet ILB sur la page Configurer les ressources de l'Annuaire des services de ce document.

    Si vous envisagez de vérifier un ILB qui n'autorise pas l'accès mondial, sélectionnez l'une des régions suivantes pour votre ILB:

    • us-east4
    • us-central1
    • us-west1
    • europe-west1
    • southamerica-east1
    • asia-southeast1
  4. Déterminez quelle interface utiliser:

    • Console Google Cloud: vous permet de créer un test de disponibilité lorsqu'une VM traite des requêtes. Cette interface vous guide via la configuration des ressources de l'annuaire des services, autoriser le compte de service et configurer le pare-feu du réseau des règles de pare-feu.

    • Interfaces de ligne de commande: vous pouvez utiliser la Google Cloud CLI et la L'API Cloud Monitoring permet de créer des tests de disponibilité privés lorsque les équilibreurs de charge internes et les VM et le traitement des demandes.

  5. Si vous prévoyez d'utiliser la ligne de commande pour configurer vos tests de disponibilité privés, puis suivez les étapes préalables.

Créer un test de disponibilité privé

Cette section explique comment créer et configurer des tests de disponibilité privés des services de l'Annuaire des services:

  • Pour utiliser la console Google Cloud, sélectionnez l'onglet Console Google Cloud.

  • Pour utiliser l'API Cloud Monitoring et configurer service de l'Annuaire des services pour qu'il se trouve dans le même projet Google Cloud que sélectionnez l'onglet API: Scoping project (API : Projet de surveillance).

  • Pour utiliser l'API Cloud Monitoring et configurer Service de l'Annuaire des services doit se trouver dans un projet surveillé selon le champ d'application des métriques test de disponibilité, sélectionnez l'onglet API: Projet surveillé.

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. Cliquez sur Create Uptime Check (Créer un test de disponibilité).

    Boîte de dialogue "Créer un test de disponibilité".

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

    1. Sélectionnez le protocole (HTTP, HTTPS ou TCP).

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

  4. Si aucun service de l'Annuaire des services n'est configuré pour votre projet ou si vous voulez créer service Annuaire des services, puis cliquez sur Afficher et effectuez la Volet Private Uptime Check Prerequisites (Prérequis pour les tests de disponibilité privés) :

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

    2. Développez Compte de service . Si cette option est affichée, puis cliquez sur Créer un compte de service.

      Si aucun compte de service Monitoring n'existe, est créé. Monitoring accorde ensuite au compte de service deux rôles de l'Annuaire des services.

    3. Développez le menu Annuaire des services et puis procédez comme suit:

      1. Développer la région et puis la région de la VM qui traite les requêtes.
      2. Développez l'espace de noms , puis sélectionnez un un espace de noms existant dans l'Annuaire des services Cliquez sur Créer un espace de noms, puis créez un espace de noms.
      3. Cliquez sur Nom du service, puis saisissez un service. son nom. Les services sont les cibles des tests de disponibilité privés.
      4. Cliquez sur Nom du point de terminaison et saisissez un nom pour le nom du point de terminaison. Un point de terminaison est une paire d'adresses IP et de valeurs de port qu'un service peut utiliser pour gérer les requêtes. Lorsque votre service contient plusieurs un seul point de terminaison est choisi au hasard.
      5. Développez le réseau , puis sélectionnez votre réseau privé.
      6. Développez l'instance , puis sélectionnez la VM. sur le réseau privé qui diffuse les requêtes. Après avoir sélectionné de l'instance, son adresse IP interne s'affiche.
      7. Cliquez sur OK.
    4. Développez Règles de pare-feu :

      1. Développez Réseau , puis sélectionnez le réseau auquel la règle de 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 provenant des routes 35.199.192.0/19. Une route provenant de 35.199.192.0/19 prend en charge la connectivité au transfert qui utilisent un routage privé. Pour en savoir plus, consultez la section Routes VPC.

  5. Dans le volet Test de disponibilité privé, vous pouvez spécifier le service Annuaire des services à utiliser, effectuez l'une des opérations suivantes:

    • Sélectionnez Utiliser le nom complet du service, puis saisissez le nom complet 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 . Si vous avez créé un service, ces champs sont sélectionnés automatiquement.

  6. Dans le volet Test de disponibilité privé, saisissez la description du cible du test de disponibilité:

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

      Tests de disponibilité privés utilisant le protocole HTTP ou HTTPS envoyez une demande à http://target/path. Dans ce 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 alors envoyée à http://target/.

    2. Facultatif: Pour définir la fréquence d'exécution du test de disponibilité, utilisez la méthode Fréquence du test.

    3. Facultatif: Pour sélectionner des régions du vérificateur 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 ciblage:

      • 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, sauf aux É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.
      • Corps: pour les tests HTTP POST, saisissez le corps encodé au format URL. vous vous devez le faire vous-même. Pour toutes les autres vérifications, laissez cette champ vide.
      • En-tête d'hôte: ne définissez pas ce champ lors de la configuration des tests de disponibilité privés.
      • Port: toute valeur définie ici remplace le port de votre Configuration du point de terminaison de l'Annuaire des services Ne pas définir saisissez une valeur ici si vous souhaitez que la configuration du point de terminaison soit utilisée.
      • En-têtes personnalisés: spécifiez des en-têtes personnalisés et, éventuellement, les chiffrer. Le chiffrement masque les valeurs de l'en-tête du 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.
  7. Cliquez sur Continuer et configurez les exigences de réponse. Tous les paramètres de cette section ont des valeurs par défaut:

    • Pour définir un délai d'expiration pour le test de disponibilité, utilisez Champ Délai avant expiration de la réponse. Un test de disponibilité échoue est reçue de plusieurs zones géographiques au cours de cette période.

    • 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:

      • Dans le menu des options, sélectionnez Type de correspondance de contenu de la réponse. 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 le type de correspondance du contenu est Contient. Le test de disponibilité fonctionne uniquement lorsque les données de réponse contiennent abcd. Pour en savoir plus, consultez Validez les données de réponse.
      • Saisissez le contenu de la réponse. Le contenu de la réponse doit être une chaîne ne dépasse pas 1 024 octets. Dans l'API, ce champ est objet ContentMatcher.
    • Pour éviter la création d'entrées de journal en raison de tests de disponibilité, Supprimez Échecs de la vérification du journal.

    • Pour les tests de disponibilité HTTP, configurez les codes de réponse acceptables. Par défaut, les tests de disponibilité HTTP 2xx en tant que réponse positive.

  8. Cliquez sur Continuer, puis configurez des règles d'alerte et des notifications.

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

    1. Facultatif: Mettez à jour le nom de la règle d'alerte.
    2. (Facultatif) Dans le champ Durée, sélectionnez la durée des tests de disponibilité doivent échouer avant l'envoi des notifications. Par défaut, les notifications sont envoyé lorsqu'au moins deux régions signalent des échecs de tests de disponibilité pour une dure au moins une minute.
    3. Dans le champ Canaux de notification, développez le menu , sélectionnez les chaînes à ajouter, puis cliquez sur OK.

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

    Si vous ne voulez pas créer de règle d'alerte, que le texte du bouton d'activation est Do not create an alert (Ne pas créer d'alerte).

  9. Cliquez sur Continue (Continuer) et terminez le test de disponibilité:

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

    2. Facultatif: Pour ajouter des étiquettes définies par l'utilisateur à votre test de disponibilité, effectuer les opérations suivantes:

      1. Cliquez sur Afficher les libellés utilisateur.
      2. Dans le champ Clé, saisissez le nom du libellé. Les noms des étiquettes doivent commencer par une lettre minuscule et peuvent contenir lettres minuscules, chiffres, traits de soulignement et tirets. Par exemple, saisissez severity.
      3. Dans le champ Valeur, saisissez la valeur de votre libellé. Valeurs des étiquettes peut contenir lettres minuscules, chiffres, traits de soulignement et tirets. Par exemple, saisissez critical.
      4. Pour chaque libellé supplémentaire, cliquez sur Ajouter une étiquette utilisateur, puis saisissez la clé et la valeur de l'étiquette.
    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 surveillance

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

L'objet UptimeCheckConfig d'un test de disponibilité privé diffère à partir de l'objet pour un test de disponibilité public, comme suit:

  • La ressource surveillée spécifiée dans la configuration du test de disponibilité doit être de type servicedirectory_service. Ce type de ressource comporte les étiquettes suivantes:

    • project_id: ID du projet associé au Service de l'Annuaire des services.
    • location: région cloud associée au service.
    • namespace_name: espace de noms de l'Annuaire des services
    • service_name: nom du service de l'Annuaire des services.
  • Il n'est pas nécessaire de spécifier une valeur port dans la configuration du test de disponibilité. La valeur du port issue des remplacements de point de terminaison de l'Annuaire des services n'importe quelle valeur définie dans la configuration du test de disponibilité, et celui-ci é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 obligatoire pour le temps d'activité privé vérifications. Par défaut, les tests de disponibilité sont publics. vous n'avez pas besoin de le spécifier.

Le code JSON suivant illustre un objet UptimeCheckConfig pour une test de disponibilité privé à l'aide des ressources de l'Annuaire des services configuré 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 Service de l'Annuaire des services se trouve dans le même projet Google Cloud 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 pour 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 Méthode uptimeCheckConfigs.create et envoyez-y 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 dispose des rôles nécessaires. Pour plus d'informations, Consultez la page Échec de la création du test de disponibilité.

API: projet surveillé

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

L'objet UptimeCheckConfig d'un test de disponibilité privé diffère à partir de l'objet pour un test de disponibilité public, comme suit:

  • La ressource surveillée spécifiée dans la configuration du test de disponibilité doit être de type servicedirectory_service. Ce type de ressource comporte les étiquettes suivantes:

    • project_id: ID du projet associé au Service de l'Annuaire des services.
    • location: région cloud associée au service.
    • namespace_name: espace de noms de l'Annuaire des services
    • service_name: nom du service de l'Annuaire des services.
  • Il n'est pas nécessaire de spécifier une valeur port dans la configuration du test de disponibilité. La valeur du port issue des remplacements de point de terminaison de l'Annuaire des services n'importe quelle valeur définie dans la configuration du test de disponibilité, et celui-ci é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 obligatoire pour le temps d'activité privé vérifications. Par défaut, les tests de disponibilité sont publics. vous n'avez pas besoin de le spécifier.

Le code JSON suivant illustre un objet UptimeCheckConfig pour une test de disponibilité privé à l'aide des ressources de l'Annuaire des services configuré 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 de l'Annuaire des services se trouve dans un projet Google Cloud surveillée par le champ d'application des métriques Google Cloud, procédez comme suit:

  1. Configurer la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud où le test de disponibilité doit être créé:

    gcloud config set project PROJECT_ID
    
  2. Créez une variable d'environnement pour 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 Projet Google Cloud dans lequel le service de l'Annuaire des services est défini:

    export MONITORED_PROJECT_ID=MONITORED_PROJECT_ID
    

    Ce projet doit faire partie du champ d'application des métriques du projet.

  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 Méthode uptimeCheckConfigs.create et envoyez-y 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 dispose des rôles nécessaires. Pour plus d'informations, Consultez la page Échec de la création du test de disponibilité.

Il peut s'écouler jusqu'à 5 minutes avant que les résultats du test de disponibilité ne commencent à parvenir à Monitoring. Pendant ce temps, le tableau de bord du test de disponibilité indique l'état "aucune donnée disponible".

Étapes préalables

Si vous prévoyez d'utiliser l'interface de la console Google Cloud, Accédez ensuite à Créer un test de disponibilité privé. La La console Google Cloud vous guide à travers toutes les étapes préalables.

Si vous prévoyez d'utiliser pour configurer des tests de disponibilité privés, vous devez Effectuez les étapes suivantes avant de pouvoir créer le test de disponibilité:

  1. Configurer les ressources de l'Annuaire des services
  2. Autoriser le compte de service
  3. Configurer des règles de pare-feu

Configurer les ressources de l'Annuaire des services

Les tests de disponibilité privés déterminent la disponibilité d'une ressource à l'aide d'un une adresse IP interne enregistrée service de l'Annuaire des services. Vous pouvez configurer un Annuaire des services pour les ressources suivantes:

  • VM sur un réseau privé
  • Équilibreurs de charge internes L4

Pour utiliser des tests de disponibilité privés, vous devez configurer les éléments suivants : Ressources de l'Annuaire des services:

  • Point de terminaison: un point de terminaison est une paire d'adresses IP et de valeurs de port qu'un service peut utiliser pour gérer les requêtes. Lorsque votre service contient plusieurs un seul point de terminaison est choisi au hasard.
  • Service: un service est un ensemble de points de terminaison qui fournissent un ensemble de comportements. Les services sont les cibles des tests de disponibilité privés.
  • Espace de noms: un espace de noms contient un ensemble de noms de services et les noms les points de terminaison. Les espaces de noms vous permettent de regrouper des services gestion de la sécurité.

Vous pouvez configurer ces ressources à l'aide de gcloud CLI ou de la console Google Cloud. Lorsque vous utilisez la console, la procédure de configuration sont incluses dans la boîte de dialogue Créer 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 d'un test de disponibilité, vous êtes invité à créer l'Annuaire des services et un service.

gcloud CLI – VM

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

Pour créer des ressources de l'Annuaire des services pour une VM, effectuer les opérations suivantes:

  1. Configurez la Google Cloud CLI pour qu'elle utilise par défaut le projet Google Cloud dans lequel les ressources de l'Annuaire des 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 dans l'Annuaire des services:

    gcloud service-directory namespaces create PRIVATE_NAMESPACE --location=REGION
    
  4. Créez un service d'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 destinée à 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 le une 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
    

gcloud CLI – ILB L4

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

Vous pouvez utiliser des tests de disponibilité privés pour surveiller la disponibilité d'une instance (ILB) en créant des ressources de l'Annuaire des services pour l'ILB L4.

Lorsque vous créez un ILB L4, vous pouvez utiliser l'intégration automatique fournie par Annuaire des services pour en savoir plus, consultez la section Configurer Équilibreurs de charge internes dans l'Annuaire des services pour en savoir plus.

Si vous disposez d'équilibreurs de charge internes L4 qui ont été créés sans utiliser l'intégration automatique fournies 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 de l'Annuaire des 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 permettre à tous les vérificateurs de disponibilité de transférer des données vers votre ILB L4, activez l'accès global à l'ILB:

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

    Si votre ILB L4 n'autorise pas l'accès mondial, les métriques de temps d'activité sont disponible uniquement si ILB_REGION correspond à l'un des éléments suivants:

    • us-east4
    • us-central1
    • us-west1
    • europe-west1
    • southamerica-east1
    • asia-southeast1
  4. Créez un espace de noms dans l'Annuaire des services:

    gcloud service-directory namespaces create PRIVATE_NAMESPACE_FOR_ILB\
    --location=REGION
    
  5. Créez un service d'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éer une variable d'environnement destinée à 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 le une 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
    

Autoriser le compte de service

Les tests de disponibilité utilisent un compte de service appartenant à Monitoring pour : gérer les interactions avec le service de l'Annuaire des services. Le nom du compte de service a le format suivant :

service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com

Si ce compte de service n'existe pas, Monitoring crée le compte de service lorsque vous créez le test de disponibilité privé. Toi ne peut pas créer ce compte de service.

Lorsque vous créez un test de disponibilité privé, Monitoring tente pour attribuer au compte de service deux rôles d'Annuaire des services. Toutefois, lorsque vous utilisez l'API, les paramètres de votre projet Google Cloud peuvent Monitoring n'accorde pas de rôles au compte de service. Dans ce cas, la création du test de disponibilité échoue.

Cette section explique comment attribuer les rôles requis à un compte de service existant:

console Google Cloud

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

API: projet de surveillance

Pour attribuer les rôles Annuaire des services à un compte de service existant, procédez comme suit:

  1. Configurer la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud où le test de disponibilité doit être créé:

    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 Annuaire des services à un compte de service existant, procédez comme suit:

  1. Configurer la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud où le test de disponibilité doit être créé:

    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 qui contient l'ID du projet. dans lequel le service de l'Annuaire des services est défini:

    export MONITORED_PROJECT_ID=MONITORED_PROJECT_ID
    

    Ce projet doit faire partie du champ d'application des métriques du projet.

  4. Créez une variable d'environnement qui contient l'ID du projet. où le réseau est défini:

    export NETWORK_PROJECT_ID=NETWORK_PROJECT_ID
    

    Ce projet n'a pas besoin d'être inclus dans le champ d'application des métriques test de disponibilité.

  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 de l'Annuaire des services est configuré, $SERVICE_MONITORED_PROJECT_ID
    • roles/servicedirectory.pscAuthorizedService pour le projet dans lequel le réseau privé $NETWORK_PROJECT_ID est configuré.

Configurer des règles de pare-feu

Vous devez créer une règle de pare-feu qui autorise le trafic TCP entrant à partir des routes 35.199.192.0/19. Une route provenant de 35.199.192.0/19 prend en charge la connectivité vers qui utilisent le routage privé. Pour plus d'informations, consultez la section Routes VPC.

console Google Cloud

Lorsque vous utilisez la console Google Cloud, après avoir sélectionné Adresse IP interne comme type de ressource d'un test de disponibilité, vous êtes invité à configurer 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 accéder au réseau privé, exécutez la commande suivante:

  1. Configurer la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud où le test de disponibilité doit être créé:

    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 de 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 associé, 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 Configurez le projet réseau.

Limites

Lorsque vous utilisez des tests de disponibilité privés, la validation des certificats SSL est désactivée, quelle que soit la configuration.

Les tests de disponibilité privés ne sont pas compatibles avec les points de terminaison comportant des redirections.

Dépannage

Cette section décrit certaines erreurs que vous pouvez rencontrer lors de l'utilisation des tests de disponibilité privés et fournit des informations pour les résoudre.

Échec de la création du test de disponibilité

Les paramètres de votre projet Google Cloud peuvent empêcher la modification des rôles attribués au compte de service utilisé par les tests de disponibilité gérer les interactions avec le service de l'Annuaire des services. Dans ce cas, la création du test de disponibilité échoue.

Cette section explique comment attribuer les rôles attribués au compte de service requiert:

console Google Cloud

Lorsque vous utilisez la console Google Cloud pour créer un test de disponibilité privé, la console Google Cloud exécute les commandes pour accorder des 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 surveillance

La première fois que vous créez un test de disponibilité privé pour Service de l'Annuaire des services et ressources privées dans un même projet Google Cloud, la requête peut réussir ou échouer. Le résultat varie selon que vous Vous avez désactivé l'attribution automatique de rôles pour les comptes de service dans votre projet:

  • Le premier test de disponibilité est créé avec succès si votre projet le permet l'attribution automatique de rôles pour les comptes de service. Un compte de service créé pour vous et obtient les rôles nécessaires.

  • La création du premier test de disponibilité échoue si votre projet n'autorise pas l'attribution automatique de rôles pour les comptes de service. Un compte de service 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 se propagent.
  3. Réessayez de créer le test de disponibilité privé.

API: projet surveillé

La première fois que vous créez un test de disponibilité privé qui cible service de l'Annuaire des services dans un projet surveillé des ressources privées dans différents projets Google Cloud, la requête échoue et entraîne la création Compte de service Monitoring.

La méthode d'autorisation du compte de service dépend du nombre Les projets Google Cloud que vous utilisez et leurs relations. Vous pouvez avoir jusqu'à quatre projets impliqués:

  • Projet dans lequel vous avez défini le test de disponibilité privé.
  • Le projet surveillé dans lequel vous avez configuré Service de l'Annuaire des services.
  • Projet dans lequel vous avez configuré le réseau VPC.
  • Projet dans lequel les ressources réseau, telles que les VM ou les équilibreurs de charge, sont configuré. Ce projet ne dispose d'aucun rôle dans l'autorisation du compte de service abordées 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 se propagent.
  3. Réessayez de créer le test de disponibilité privé.

Accès refusé

Vos tests de disponibilité échouent avec VPC_ACCESS_DENIED résultats. Ce résultat qu'un aspect de votre configuration réseau ou de votre compte de service l'autorisation n'est pas correcte.

Vérifier l'autorisation de votre compte de service pour utiliser un champ d'application ou un projet surveillé, comme décrit dans Échec de la création du test de disponibilité

Pour plus d'informations sur l'accès aux réseaux privés, consultez Configurez le projet réseau.

Résultats anormaux des tests de disponibilité privés

Vous disposez d'un service de l'Annuaire des services plusieurs VM et que votre configuration de service contient plusieurs points de terminaison. Lorsque vous arrêtez l'une des VM, le test de disponibilité indique toujours la réussite de l'opération.

Lorsque la configuration de votre service contient plusieurs points de terminaison, l'un est choisi au hasard. Si la VM associée au point de terminaison choisi est en cours d'exécution, le test de disponibilité réussit, même si l'une des VM est arrêtée.

En-têtes par défaut

Vos tests de disponibilité renvoient des erreurs ou des résultats inattendus. Cela pourrait se produire si vous avez remplacé les valeurs d'en-tête par défaut.

Lorsqu'une requête est envoyée pour un test de disponibilité privé à un point de terminaison cible, la requête inclut les en-têtes et valeurs suivants:

En-tête Valeur
HTTP_USER_AGENT GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)
HTTP_CONNECTION keep-alive
HTTP_HOST Adresse IP du point de terminaison de l'Annuaire des services
HTTP_ACCEPT_ENCODING gzip, deflate, br
CONTENT_LENGTH Calculé à partir des données sur le temps d'activité après

Si vous tentez de remplacer ces valeurs, voici ce qui peut se produire:

  • Le test de disponibilité signale des erreurs
  • Les valeurs de remplacement sont supprimées et remplacées par les valeurs de la table

Aucune donnée visible

Le tableau de bord du test de disponibilité ne contient aucune donnée le test de disponibilité se trouve dans un projet Google Cloud différent de Service de l'Annuaire des services.

Assurez-vous que le projet Google Cloud contenant le test de disponibilité surveille le projet Google Cloud contenant Service de l'Annuaire des services.

Pour savoir comment répertorier les projets surveillés et ajouter des uns, consultez Configurez un champ d'application des métriques pour plusieurs projets.

Étape suivante