Créer des tests de disponibilité privés

Ce document explique comment configurer un test de disponibilité privé. Les tests de disponibilité privés permettent d'envoyer des requêtes HTTP dans un réseau cloud privé virtuel (VPC) client tout en appliquant les restrictions Identity and Access Management (IAM) et les périmètres VPC Service Controls. Les tests de disponibilité privés peuvent envoyer des requêtes via le réseau privé à des ressources telles qu'une machine virtuelle (VM) ou un équilibreur de charge interne (ILB) L4.

Les adresses IP internes des ressources du réseau privé sont enregistrées par les services de l'Annuaire des services avec l'accès au réseau privé activé. Pour utiliser des tests de disponibilité privés, vous devez configurer l'accès à un réseau privé à l'aide du produit de l'Annuaire des services.

Le projet Google Cloud qui stocke le test de disponibilité privé et le projet Google Cloud qui stocke le service de l'Annuaire des services peuvent être différents. Cloud Monitoring vous permet de surveiller les ressources de plusieurs projets Google Cloud à partir d'un seul projet en utilisant un champ d'application des métriques. Le projet dans lequel le test de disponibilité est défini est le projet effectuant une surveillance 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 dans le projet effectuant une surveillance ou dans un projet du champ d'application des métriques. Pour en savoir plus sur les champs d'application des métriques, consultez la page 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 également se trouver dans un autre projet Google Cloud. Ce projet ne doit pas nécessairement se trouver dans le champ d'application des métriques du projet effectuant une surveillance du test de disponibilité. Le service de l'Annuaire des services collecte les métriques de temps d'activité. Il doit donc figurer dans le champ d'application des métriques, mais pas les ressources qu'il encapsule.

Ce document explique comment configurer un réseau privé et les ressources de l'Annuaire des services pour celui-ci à l'aide de la console Google Cloud ou de l'API. Les exemples d'API supposent que le réseau privé et le service de l'Annuaire des services se trouvent dans le projet effectuant une surveillance du test de disponibilité. Cependant, la section Créer un test de disponibilité privé explique également comment utiliser l'API pour créer un test de disponibilité qui utilise un service de l'Annuaire des services dans le champ d'application des métriques.

Pour en savoir plus sur la configuration des tests de disponibilité qui utilisent des adresses IP publiques, consultez la section Créer des tests de disponibilité publics. Pour plus d'informations sur la gestion et la surveillance des tests de disponibilité, consultez la section Étapes suivantes de ce document.

Avant de commencer

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 comment installer la gcloud CLI et activer l'API Cloud Monitoring:
console Google Cloud
1. Dans la console Google Cloud, sélectionnez le projet Google Cloud pour lequel vous souhaitez activer l'API, puis accédez à la page API et services:
  
  Accéder à 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. Sinon, cliquez sur Activer.
gcloud CLI
1. Si vous n'avez pas encore installé la Google Cloud CLI sur votre poste de travail, consultez 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 l'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 Service Directory").
- Pour utiliser la gcloud CLI, spécifiez le premier élément du nom googleapis.com (par exemple, servicedirectory).
Configurez les canaux de notification que vous souhaitez utiliser pour recevoir des notifications. Nous vous recommandons de créer plusieurs types de canaux de notification. Pour en savoir plus, consultez Créer et gérer des canaux de notification.
Configurez un réseau privé et configurez une VM ou un ILB pour accéder à ce réseau privé. Pour en savoir plus, consultez la section Accès aux services privés.

Les tests privés qui ciblent des équilibreurs de charge internes sont limités aux régions disposant de vérificateurs de disponibilité. La région USA pour les tests de disponibilité inclut les régions USA_OREGON, USA_IOWA et USA_VIRGINIA. Chacune des régions USA_* comporte un vérificateur, et USA inclut les trois. Les autres régions pour les tests de disponibilité, EUROPE, SOUTH_AMERICA et ASIA_PACIFIC, disposent chacune d'un vérificateur. Pour supprimer cette limitation, vous devez configurer l'accès mondial à votre équilibreur de charge. Pour en savoir plus sur la configuration de l'accès mondial, consultez l'onglet ILB dans la section 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
Déterminez l'interface à utiliser:
- Console Google Cloud: permet de créer un test de disponibilité lorsqu'une VM traite des requêtes. Cette interface vous guide dans la configuration des ressources de l'Annuaire des services, l'autorisation du compte de service et la configuration des règles de pare-feu du réseau.
- Interfaces de ligne de commande: vous pouvez utiliser Google Cloud CLI et l'API Cloud Monitoring pour créer des tests de disponibilité privés lorsque des équilibreurs de charge internes et des VM traitent des requêtes.
Si vous prévoyez d'utiliser la ligne de commande pour configurer vos tests de disponibilité privés, 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 pour les 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 le service de l'Annuaire des services afin qu'il se trouve dans le même projet Google Cloud que le test de disponibilité, sélectionnez l'onglet API: projet de surveillance.
Pour utiliser l'API Cloud Monitoring et configurer le service de l'Annuaire des services dans un projet surveillé par le champ d'application des métriques du projet du 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:

Dans le panneau de navigation de la console Google Cloud, sélectionnez Monitoring, puis Tests de disponibilité:
Accéder aux tests de disponibilité
Cliquez sur Create Uptime Check (Créer un test de disponibilité).
Spécifiez un test de disponibilité privé:
1. Sélectionnez le protocole : HTTP ou HTTPS. Ne sélectionnez pas TCP pour un test de disponibilité privé.
2. Sélectionnez le type de ressource Adresse IP interne.
Si aucun service de l'Annuaire des services n'est configuré pour votre projet ou si vous souhaitez en créer un, cliquez sur Afficher et remplissez le volet Prérequis pour le test de disponibilité privé:
1. Si vous y êtes invité, activez l'API Compute Engine ou l'API de l'Annuaire des services. L'activation des API peut prendre une minute.
2. Développez Service Account (Compte de service) si celui-ci s'affiche, puis cliquez sur Create Service Account (Créer un compte de service).
  
  Si aucun compte de service Monitoring n'existe, il est créé. Ensuite, Monitoring attribue au compte de service deux rôles "Annuaire des services".
3. Développez le menu Service Directory (Annuaire des services), puis procédez comme suit:
  1. Développez Région , puis sélectionnez la région de la VM qui diffuse les requêtes.
  2. Développez Espace de noms , puis sélectionnez un espace de noms existant dans l'Annuaire des services ou cliquez sur Créer un espace de noms et créez un espace de noms.
  3. Cliquez sur Nom du service, puis saisissez un nom de service. Les services sont la cible des tests de disponibilité privés.
  4. Cliquez sur Nom du point de terminaison, puis saisissez un nom. Un point de terminaison est une paire de valeurs d'adresse IP et de port qu'un service peut utiliser pour gérer des requêtes. Lorsque votre service contient plusieurs points de terminaison, l'un d'eux est choisi au hasard.
  5. Développez Réseau , puis sélectionnez votre réseau privé.
  6. Développez Instance , puis sélectionnez la VM du réseau privé qui diffuse les requêtes. Une fois l'instance sélectionnée, 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 l'adresse 35.199.192.0/19 accepte la connectivité à des cibles de transfert qui utilisent un routage privé. Pour en savoir plus, consultez la section Routes VPC.
Dans le volet Test de disponibilité privé, effectuez l'une des opérations suivantes pour spécifier le service de l'Annuaire des services à utiliser:
- 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 automatiquement.
Dans le volet Test de disponibilité privé, saisissez 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 Path 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 Fréquence de vérification.
3. Facultatif: Pour sélectionner des régions du vérificateur ou pour configurer l'authentification, les en-têtes pour les tests HTTP et HTTPS ainsi que d'autres valeurs, cliquez sur More target options (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 en comptent trois. Le paramètre par défaut, Mondial, inclut toutes les régions.
  - Request Method (Méthode de requête) : sélectionnez GET ou POST.
  - Corps: pour les tests HTTP POST, saisissez le corps encodé au format URL. Vous devez effectuer l'encodage vous-même. Pour toutes les autres vérifications, laissez ce champ vide.
  - Host header (En-tête de l'hôte) : ne définissez pas ce champ lorsque vous configurez des tests de disponibilité privés.
  - Port: toute valeur que vous définissez ici remplace le port défini dans votre configuration de point de terminaison dans 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: fournissez des en-têtes personnalisés et chiffrez-les éventuellement. Le chiffrement masque les valeurs dans 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.
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 avant expiration pour le test de disponibilité, utilisez le champ Délai avant expiration de la réponse. Un test de disponibilité échoue lorsqu'aucune réponse n'est reçue de la part de plusieurs emplacements 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 Le contenu est activé:
  - Dans le menu des options, sélectionnez le type de correspondance du 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 que le type de correspondance du contenu soit Contient. Le test de disponibilité ne réussit que si les données de la réponse contiennent abcd. Pour en savoir plus, consultez la section 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 au maximum. Dans l'API, ce champ correspond à l'objet ContentMatcher.
- Pour empêcher la création d'entrées de journal en raison des tests de disponibilité, désélectionnez Échecs de la vérification des journaux.
- Pour les tests de disponibilité HTTP, configurez les codes de réponse acceptables. Par défaut, les tests de disponibilité HTTP marquent n'importe quelle réponse 2xx comme une réponse réussie.
Cliquez sur Continuer, puis configurez des règles d'alerte et des notifications.

Pour être averti lorsqu'un test de disponibilité échoue, créez une règle d'alerte et configurez des canaux de notification pour cette règle:
1. (Facultatif) Mettez à jour le nom de la règle d'alerte.
2. Facultatif: Dans le champ Duration (Durée), sélectionnez la durée pendant laquelle les tests de disponibilité doivent échouer avant l'envoi de notifications. Par défaut, les notifications sont envoyées lorsqu'au moins deux régions signalent des échecs de tests de disponibilité pendant une durée minimale d'une minute.
3. Dans la zone intitulée Canaux de notification, développez 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 bien Do not create an alert (Ne pas créer d'alerte).
Cliquez sur Continuer et effectuez 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é, procédez comme suit:
  1. Cliquez sur Afficher les libellés utilisateur.
  2. Dans le champ Clé, saisissez le nom du libellé. Les noms d'étiquettes 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 la valeur du libellé. Les valeurs d'étiquette peuvent contenir des lettres minuscules, des chiffres, des traits de soulignement et des tirets. Par exemple, saisissez critical.
  4. Pour chaque étiquette supplémentaire, cliquez sur Ajouter une étiquette 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 surveillance

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.

Voici les différences entre l'objet UptimeCheckConfig d'un test de disponibilité privé et celui d'un test de disponibilité public:

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 libellés suivants:
- 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.
Remarque :Les valeurs de ces libellés sont déterminées lors de la configuration des ressources de l'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 du test de disponibilité, et le test é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 tests de disponibilité privés. Par défaut, les tests de disponibilité sont publics. Il n'est donc pas nécessaire de spécifier ce champ.

Le code JSON suivant illustre un objet UptimeCheckConfig pour un test de disponibilité privé utilisant les 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 de l'Annuaire des services se trouve dans le même projet Google Cloud que le test de disponibilité, procédez comme suit:

Définissez le projet Google Cloud par défaut pour la gcloud CLI:
```
gcloud config set project PROJECT_ID
```
Créez une variable d'environnement destinée à stocker l'ID de votre projet:
```
export PROJECT_ID=$(gcloud config get-value core/project)
```
Créez une variable d'environnement contenant un jeton d'accès:
```
export TOKEN=`gcloud auth print-access-token`
```

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 la section Échec de la création d'un test de disponibilité.

API: projet surveillé

Voici les différences entre l'objet UptimeCheckConfig d'un test de disponibilité privé et celui d'un test de disponibilité public:

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 libellés suivants:
- 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.
Remarque :Les valeurs de ces libellés sont déterminées lors de la configuration des ressources de l'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 du test de disponibilité, et le test é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 tests de disponibilité privés. Par défaut, les tests de disponibilité sont publics. Il n'est donc pas nécessaire de spécifier ce champ.

{
  "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é par le champ d'application des métriques du projet Google Cloud correspondant, procédez comme suit:

Configurez la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud dans lequel le test de disponibilité doit être créé:
```
gcloud config set project PROJECT_ID
```
Créez une variable d'environnement destinée à stocker l'ID de votre projet:
```
export PROJECT_ID=$(gcloud config get-value core/project)
```
Créez une variable d'environnement pour stocker l'ID du 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 se trouver dans le champ d'application des métriques du projet du test de disponibilité.
Créez une variable d'environnement contenant un jeton d'accès:
```
export TOKEN=`gcloud auth print-access-token`
```

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"
}'

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 à la section Créer un test de disponibilité privé. La console Google Cloud vous guide tout au long des étapes préalables.

Si vous prévoyez d'utiliser la ligne de commande pour configurer vos tests de disponibilité privés, vous devez effectuer les étapes suivantes avant de pouvoir créer le test de disponibilité:

Configurer les ressources de l'Annuaire des services
Autoriser le compte de service
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'une adresse IP interne enregistrée par un 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 (ILB) L4

Pour utiliser des tests de disponibilité privés, vous devez configurer les ressources suivantes de l'Annuaire des services:

Point de terminaison: un point de terminaison est une paire de valeurs d'adresse IP et de port qu'un service peut utiliser pour gérer des requêtes. Lorsque votre service contient plusieurs points de terminaison, l'un d'eux est choisi au hasard.
Service: un service est un ensemble de points de terminaison fournissant un ensemble de comportements. Les services sont la cible des tests de disponibilité privés.
Espace de noms: un espace de noms contient un ensemble de noms de service et leurs points de terminaison associés. Les espaces de noms vous permettent de regrouper des services pour une gestion cohérente.

Vous pouvez configurer ces ressources à l'aide de la gcloud CLI ou de la console Google Cloud. Lorsque vous utilisez la console, les étapes 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 pour un test de disponibilité, vous êtes invité à créer un Annuaire des services et un service.

gcloud CLI – 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 des services pour une VM, procédez comme suit:

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
```

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)')

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

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

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

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)')

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

gcloud CLI – ILB L4

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) L4 en créant des ressources de l'Annuaire des services pour l'ILB L4.

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

Si des équilibreurs de charge internes L4 ont été créés 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:

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
```

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)')

Pour permettre à tous les vérificateurs de disponibilité de transférer des données vers votre ILB L4, activez l'accès mondial à 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é ne sont disponibles que si ILB_REGION correspond à l'un des éléments suivants:
- us-east4
- us-central1
- us-west1
- europe-west1
- southamerica-east1
- asia-southeast1

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

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

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

Créez 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)')

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

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

Le compte de service existe déjà si votre projet Google Cloud contient un canal de notification. S'il n'existe pas, Monitoring crée le compte de service lorsque vous créez le test de disponibilité privé. Vous ne pouvez pas créer ce compte de service.

Lorsque vous créez un test de disponibilité privé, Monitoring tente d'attribuer au compte de service deux rôles dans l'Annuaire des services. Toutefois, lorsque vous utilisez l'API, les paramètres de votre projet Google Cloud peuvent empêcher Monitoring d'attribuer des 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 pour un test de disponibilité, vous êtes invité à autoriser le compte de service.

API: projet de surveillance

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

Configurez la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud dans lequel le test de disponibilité doit être créé:
```
gcloud config set project PROJECT_ID
```

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)')

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 accordent les rôles suivants au compte de service:

roles/servicedirectory.viewer
roles/servicedirectory.pscAuthorizedService

API: projet surveillé

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

Configurez la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud dans lequel le test de disponibilité doit être créé:
```
gcloud config set project PROJECT_ID
```

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)')

Créez une variable d'environnement contenant 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 se trouver dans le champ d'application des métriques du projet du test de disponibilité.
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 n'a pas besoin de figurer dans le champ d'application des métriques du projet du test de disponibilité.

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 accordent 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é est configuré : $NETWORK_PROJECT_ID.

Configurer des règles de pare-feu

Vous devez créer une règle de pare-feu qui active le trafic TCP entrant provenant des routes 35.199.192.0/19. Une route provenant de l'adresse 35.199.192.0/19 accepte la connectivité à des cibles de transfert qui utilisent le routage privé. Pour en savoir plus, 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 pour un test de disponibilité, vous êtes invité à configurer les règles de pare-feu.

gcloud CLI

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:

Configurez la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud dans lequel le test de disponibilité doit être créé:
```
gcloud config set project PROJECT_ID
```
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)
```

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 est associée, tandis que PRIVATE_CHECK_NETWORK_HOPE_RULE correspond au nom de la règle de pare-feu.

Pour plus d'informations sur cette étape, consultez la section Configurer 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 de 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 que les tests de disponibilité utilisent pour 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 requis par le compte de service:

console Google Cloud

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

Pour en savoir plus sur l'attribution de 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 un service d'Annuaire des services et des 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 avez ou non désactivé les attributions automatiques de rôles pour les comptes de service dans votre projet:

La première création d'un test de disponibilité réussit si votre projet autorise l'attribution automatique de rôles pour les comptes de service. Un compte de service est créé automatiquement et dispose des 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 est créé, mais aucun rôle n'est attribué.

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

Autorisez le compte de service.
Attendez quelques minutes que les autorisations se propagent.
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 un service de l'Annuaire des services dans un projet surveillé ou des ressources privées dans un autre projet Google Cloud, la requête échoue et entraîne la création d'un compte de service Monitoring.

La manière dont vous autorisez le compte de service dépend du nombre de projets Google Cloud que vous utilisez et de leurs relations. Jusqu'à quatre projets peuvent être impliqués:

Projet dans lequel vous avez défini le test de disponibilité privé.
Projet surveillé dans lequel vous avez configuré le 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ées. Ce projet ne dispose d'aucun rôle dans l'autorisation du compte de service décrite ici.

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

Autorisez le compte de service.
Attendez quelques minutes que les autorisations se propagent.
Réessayez de créer le test de disponibilité privé.

Accès refusé

Échec de vos tests de disponibilité avec des résultats VPC_ACCESS_DENIED. Ce résultat signifie qu'un aspect de votre configuration réseau ou de votre autorisation de compte de service n'est pas correct.

Vérifiez l'autorisation de votre compte de service pour l'utilisation d'un projet effectuant une surveillance ou d'un projet surveillé, comme décrit dans la section Échec de la création du test de disponibilité.

Pour en savoir plus sur l'accès aux réseaux privés, consultez la section Configurer le projet réseau.

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

Vous disposez d'un service de l'Annuaire des services avec plusieurs VM et 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 votre configuration de service contient plusieurs points de terminaison, l'un d'eux 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 peut se produire si vous avez remplacé les valeurs d'en-tête par défaut.

Lorsqu'une requête est envoyée à un point de terminaison cible pour un test de disponibilité privé, elle inclut les en-têtes et les 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` et `br`
`CONTENT_LENGTH`	Calculé à partir des données post-temps d'activité

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 du tableau.

Aucune donnée visible

Aucune donnée ne s'affiche dans le tableau de bord des tests de disponibilité lorsque votre test de disponibilité se trouve dans un projet Google Cloud différent de celui du service de l'Annuaire des services.

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

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