Ce document explique comment configurer un test de disponibilité privé. Les tests de disponibilité privés autorisent les requêtes HTTP ou TCP vers le réseau Virtual Private Cloud (VPC) d'un 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 sur 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 sur le réseau privé sont enregistrées par les services Annuaire des services pour lesquels l'accès au réseau privé est activé. Pour utiliser les tests de disponibilité privés, vous devez configurer l'accès au réseau privé à l'aide du produit Annuaire des services.
Le projet Google Cloud qui stocke le contrôle de disponibilité privé et le projet Google Cloud qui stocke le service Service Directory peuvent être des projets différents. Cloud Monitoring vous permet de surveiller les ressources de plusieurs projetsGoogle Cloud à partir d'un seul projet à l'aide d'un champ d'application de métriques. Le projet dans lequel le test de disponibilité est défini est le projet de champ d'application d'un champ d'application de métriques. Le champ d'application de métriques est une liste de tous les projets que le projet de champ d'application surveille. Le service Service Directory peut être défini dans le projet de champ d'application ou dans un projet du 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, comme les VM ou les équilibreurs de charge, peuvent également se trouver dans un autre projet Google Cloud . Ce projet ne doit pas nécessairement figurer dans le champ d'application des métriques du projet de champ d'application du test de disponibilité. Le service Annuaire des services collecte les métriques de disponibilité. Il doit donc figurer dans le champ d'application des métriques, mais pas les ressources qu'il englobe.
Ce document explique comment configurer un réseau privé et configurer les ressources Service Directory 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 Service Directory se trouvent dans le projet de définition du champ d'application du contrôle du temps d'activité. Toutefois, Créer un test de disponibilité privé explique également comment utiliser l'API pour créer un test de disponibilité qui utilise un service Service Directory dans le champ d'application des métriques.
Pour savoir comment configurer des tests de disponibilité qui utilisent des adresses IP publiques, consultez Créer des tests de disponibilité publics. Pour savoir comment gérer et surveiller vos tests de disponibilité, consultez la section Étapes suivantes de ce document.
Cette fonctionnalité n'est disponible que pour les projets 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.
Avant de commencer
Activez les API suivantes :
- API Cloud Monitoring :
monitoring.googleapis.com
- API Service Directory :
servicedirectory.googleapis.com
- API Service Networking :
servicenetworking.googleapis.com
- API Compute Engine :
compute.googleapis.com
Vous pouvez activer les API à l'aide de la gcloud CLI ou de la consoleGoogle Cloud . Les onglets suivants décrivent comment installer gcloud CLI et activer l'API Cloud Monitoring :
Console Google Cloud
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 :
Cliquez sur le bouton Activer des API et des services.
Recherchez "Monitoring".
Dans les résultats de recherche, cliquez sur "API Cloud Monitoring".
Si "API activée" s'affiche, cela signifie que l'API est déjà activée. Sinon, cliquez sur Activer.
CLI gcloud
Si vous n'avez pas encore installé Google Cloud CLI sur votre poste de travail, consultez Installer gcloud CLI.
Pour vérifier 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.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 les mêmes étapes pour activer les autres API :
- Pour utiliser la console Google Cloud , recherchez le nom à afficher, par exemple "API Service Directory".
- Pour utiliser la CLI gcloud, spécifiez le premier élément du nom
googleapis.com
, par exempleservicedirectory
.
- API Cloud Monitoring :
Configurez les canaux de notification que vous souhaitez utiliser pour recevoir les 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 équilibreur de charge interne pour qu'ils aient accès à ce réseau privé. Pour en savoir plus, consultez Accès aux services privés.
Les vérifications privées ciblant les équilibreurs de charge internes sont limitées aux régions disposant de vérificateurs de disponibilité. La région
USA
du test de disponibilité inclut les régionsUSA_OREGON
,USA_IOWA
etUSA_VIRGINIA
. Chacune des régionsUSA_*
dispose d'un vérificateur, etUSA
inclut les trois. Les autres régions du test de disponibilité,EUROPE
,SOUTH_AMERICA
etASIA_PACIFIC
, possèdent chacune un vérificateur. Pour supprimer cette limitation, vous devez configurer l'accès mondial à votre équilibreur de charge. Pour savoir comment configurer l'accès global, consultez l'onglet "Équilibreur de charge interne" de la section Configurer les ressources de l'Annuaire des services de ce document.Si vous prévoyez de vérifier un équilibreur de charge interne qui n'autorise pas l'accès mondial, sélectionnez l'une des régions suivantes pour votre équilibreur de charge interne :
us-east4
us-central1
us-west1
europe-west1
southamerica-east1
asia-southeast1
Déterminez l'interface à utiliser :
Google Cloud console : vous permet de créer un test de disponibilité lorsqu'une VM traite des requêtes. Cette interface vous guide dans la configuration des ressources Service Directory, l'autorisation du compte de service et la configuration des règles de pare-feu réseau.
Interfaces de ligne de commande : vous pouvez utiliser la Google Cloud CLI et l'API Cloud Monitoring pour créer des tests de disponibilité privés lorsque les équilibreurs de charge internes et les 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 Service Directory :
Pour utiliser la console Google Cloud , sélectionnez l'onglet ConsoleGoogle Cloud .
Pour utiliser l'API Cloud Monitoring et configurer le service Service Directory afin qu'il se trouve dans le même projet Google Cloud que la vérification du temps d'activité, sélectionnez l'onglet API : projet de définition du champ d'application.
Pour utiliser l'API Cloud Monitoring et configurer le service Service Directory afin qu'il se trouve dans un projet surveillé par le champ d'application des métriques du projet du contrôle 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 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.
- 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.
Cliquez sur Create Uptime Check (Créer un test de disponibilité).
Spécifiez un test de disponibilité privé :
Sélectionnez le protocole, qui peut être HTTP, HTTPS ou TCP.
Choisissez le type de ressource Adresse IP interne.
Si vous n'avez pas configuré de service Service Directory pour votre projet ou si vous souhaitez en créer un, cliquez sur Afficher et remplissez le volet Conditions requises pour les vérifications privées du temps d'activité :
Si vous y êtes invité, activez l'API Compute Engine ou l'API Service Directory. L'activation des API peut prendre une minute.
Développez arrow_drop_down Compte de service, le cas échéant, puis cliquez sur Créer un compte de service.
Lorsqu'aucun compte de service Monitoring n'existe, un compte est créé. Monitoring attribue ensuite deux rôles Service Directory au compte de service.
Développez le menu arrow_drop_down Service Directory (Répertoire de services), puis procédez comme suit :
- Développez arrow_drop_down Région, puis sélectionnez la région de la VM qui traite les requêtes.
- Développez arrow_drop_down Espace de noms, puis sélectionnez un espace de noms Service Directory existant ou cliquez sur Créer un espace de noms et créez-en un.
- Cliquez sur Nom du service et saisissez un nom de service. Les services sont les cibles des tests de disponibilité privés.
- Cliquez sur Nom du point de terminaison, puis saisissez un nom pour le point de terminaison. Un point de terminaison est une paire de valeurs d'adresse IP et de port qu'un service peut utiliser pour traiter les requêtes. Lorsque votre service contient plusieurs points de terminaison, l'un d'eux est choisi au hasard.
- Développez arrow_drop_down Réseau, puis sélectionnez votre réseau privé.
- 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.
- Cliquez sur OK.
Développez arrow_drop_down Règles de pare-feu :
Développez arrow_drop_down Réseau, puis sélectionnez le réseau auquel la règle réseau est associée.
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.
Dans le volet Test de disponibilité privé, pour 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 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.
Dans le volet Private Uptime Check (Test de disponibilité privé), complétez la description de la cible du test de disponibilité :
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/
.Facultatif : Pour définir la fréquence d'exécution du test de disponibilité, utilisez le champ Fréquence de consultation.
Facultatif : Pour sélectionner des régions de vérification ou 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
ouPOST
. - Corps : pour les vérifications 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. - En-tête d'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 dans la configuration du point de terminaison de l'annuaire des services. Ne définissez pas de 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, puis chiffrez-les si vous le souhaitez. 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.
Cliquez sur Continuer, puis configurez les exigences portant sur 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 qu'il effectue 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 du contenu soit Contient. Le test de disponibilité n'est réussi que si les données de réponse contiennentabcd
. 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 qui ne dépasse pas 1 024 octets. Dans l'API, ce champ correspond à l'objet
ContentMatcher
.
- 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
Pour empêcher la création d'entrées de journal en raison des tests de disponibilité, décochez Journaliser les échecs de tests.
Pour les tests de disponibilité HTTP, configurez les codes de réponse acceptables. Par défaut, les tests de disponibilité HTTP marquent toute réponse
2xx
comme une réponse réussie.
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 :
- Facultatif : modifiez le nom de la règle d'alerte.
- 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, les notifications sont envoyées lorsqu'au moins deux régions signalent des échecs de test de disponibilité pendant au moins une minute.
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.
Cliquez sur Continuer et effectuez le test de disponibilité :
Saisissez un titre descriptif pour le test de disponibilité.
Facultatif : Pour ajouter des libellés définis par l'utilisateur à votre test de disponibilité, procédez comme suit :
- Cliquez sur expand_more Afficher les étiquettes utilisateur.
- Dans le champ Clé, saisissez un nom pour le libellé.
Les noms de libellés 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
. - 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
. - Pour chaque libellé supplémentaire, cliquez sur Ajouter un libellé utilisateur, puis saisissez la clé et la valeur du libellé.
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 effectuez à nouveau l'étape de vérification.
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
de l'API Cloud Monitoring.
L'objet UptimeCheckConfig
d'un test de disponibilité privé diffère de celui d'un test de disponibilité public de la manière suivante :
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 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 Service Directory.
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 contrôle du temps d'activité. Le contrôle é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 valeurVPC_CHECKERS
. Cette valeur est requise pour les vérifications privées du temps d'activité. Par défaut, les tests de disponibilité sont publics. Vous n'avez donc pas besoin de spécifier ce champ pour les tests de disponibilité publics.
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 Service Directory 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 gcloud CLI :
gcloud config set project PROJECT_ID
Créez une variable d'environnement pour stocker l'ID de votre projet :
export PROJECT_ID=$(gcloud config get-value core/project)
Créez une variable d'environnement pour contenir un jeton d'accès :
export TOKEN=`gcloud auth print-access-token`
Utilisez l'outil
curl
pour appeler la méthodeuptimeCheckConfigs.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
de l'API Cloud Monitoring.
L'objet UptimeCheckConfig
d'un test de disponibilité privé diffère de celui d'un test de disponibilité public de la manière suivante :
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 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 Service Directory.
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 contrôle du temps d'activité. Le contrôle é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 valeurVPC_CHECKERS
. Cette valeur est requise pour les vérifications privées du temps d'activité. Par défaut, les tests de disponibilité sont publics. Vous n'avez donc pas besoin de spécifier ce champ pour les tests de disponibilité publics.
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 Annuaire des services se trouve dans un projet Google Cloud surveillé par le champ d'application des métriques du projetGoogle Cloud du test de disponibilité, procédez comme suit :
Configurez la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud dans lequel le contrôle du temps d'activité doit être créé :
gcloud config set project PROJECT_ID
Créez une variable d'environnement pour 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 de projet duGoogle Cloud 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 de métriques du projet du test de disponibilité.
Créez une variable d'environnement pour contenir un jeton d'accès :
export TOKEN=`gcloud auth print-access-token`
Utilisez l'outil
curl
pour appeler la méthodeuptimeCheckConfigs.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é.
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 à 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 suivre 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 Service Directory. Vous pouvez configurer un Service Directory pour les ressources suivantes :
- VM sur un réseau privé
- Équilibreurs de charge internes (ILB) L4
Pour utiliser les tests de disponibilité privés, vous devez configurer les ressources de l'Annuaire des services suivantes :
- Point de terminaison : un point de terminaison est une paire de valeurs d'adresse IP et de port qu'un service peut utiliser pour traiter les 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 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 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 avec gcloud CLI ou la consoleGoogle 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.
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 Service Directory 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 Service Directory 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 Annuaire des services :
gcloud service-directory namespaces create PRIVATE_NAMESPACE --location=REGION
Créez un service 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 pour stocker 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
CLI gcloud : équilibreur de charge interne de couche 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 Service Directory pour l'ILB de couche 4.
Lorsque vous créez des équilibreurs de charge internes de couche 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 équilibreurs de charge internes de couche 4 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 Service Directory 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 autoriser tous les vérificateurs de disponibilité à transférer des données vers votre équilibreur de charge interne de couche 4, activez l'accès global à l'équilibreur de charge interne :
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'un des éléments suivants :
us-east4
us-central1
us-west1
europe-west1
southamerica-east1
asia-southeast1
Créez un espace de noms Annuaire des services :
gcloud service-directory namespaces create PRIVATE_NAMESPACE_FOR_ILB\ --location=REGION
Créez un service 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 pour stocker 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 vérifications du temps d'activité utilisent un compte de service appartenant à Monitoring pour gérer les interactions avec le service Service Directory. Le nom du compte de service a le format suivant :
service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
Lorsque ce compte de service n'existe pas, Monitoring le crée lorsque vous créez la vérification privée du temps d'activité. Vous ne pouvez pas créer ce compte de service.
Lorsque vous créez un contrôle de disponibilité privé, Monitoring tente d'attribuer deux rôles Service Directory au compte de service. 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 Service Directory à 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 contrôle du temps d'activité 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 attribuent les rôles suivants au compte de service :
roles/servicedirectory.viewer
roles/servicedirectory.pscAuthorizedService
API : projet surveillé
Pour attribuer les rôles Service Directory à 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 contrôle du temps d'activité 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 pour contenir l'ID de 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 de métriques du projet du test de disponibilité.
Créez une variable d'environnement pour contenir 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 contrôle du temps d'activité.
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 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 autorise le trafic TCP entrant à partir des routes 35.199.192.0/19. Une route depuis 35.199.192.0/19 accepte la connectivité aux cibles de transfert qui utilisent le routage privé. Pour en savoir plus, consultez 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.
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 :
Configurez la gcloud CLI pour qu'elle utilise par défaut le projet Google Cloud dans lequel le contrôle du temps d'activité 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 en savoir plus sur cette étape, consultez Configurer le projet réseau.
Limites
Lorsque vous utilisez des vérifications privées du temps d'activité, la validation des certificats SSL est désactivée, quelle que soit la configuration.
Les vérifications privées du temps d'activité ne sont pas compatibles avec les points de terminaison qui comportent des redirections.
Dépannage
Cette section décrit certaines erreurs que vous pouvez rencontrer lorsque vous utilisez des vérifications privées du temps d'activité 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 vérifications du temps d'activité pour gérer les interactions avec le service Service Directory. 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é, la console Google Cloud émet les commandes permettant d'accorder les rôles Annuaire des services au compte de service.
Pour savoir comment attribuer des rôles à un compte de service, consultez 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 Service Directory et des ressources privées dans un même projet Google Cloud , la requête peut aboutir ou échouer. Le résultat dépend de si vous avez désactivé les attributions automatiques de rôles pour les comptes de service dans votre projet :
La première création de vérification du temps d'activité réussit si votre projet autorise l'attribution automatique de rôles pour les comptes de service. Un compte de service est créé pour vous et les rôles nécessaires lui sont attribués.
La première création de vérification du temps d'activité é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.
- Patientez quelques minutes, le temps que les autorisations se propagent.
- Essayez à nouveau de créer le test de disponibilité privé.
API : projet surveillé
La première fois que vous créez un contrôle de disponibilité privé ciblant un service Service Directory 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 façon dont vous autorisez le compte de service dépend du nombre de projetsGoogle Cloud que vous utilisez et de leurs relations. Jusqu'à quatre projets peuvent être concernés :
- Projet dans lequel vous avez défini le test de disponibilité privé.
- Projet surveillé dans lequel vous avez configuré le service Service Directory.
- 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 n'a aucun rôle dans l'autorisation du compte de service dont il est question ici.
Si la création du premier test de disponibilité échoue, procédez comme suit :
- Autorisez le compte de service.
- Patientez quelques minutes, le temps que les autorisations se propagent.
- Essayez à nouveau de créer le test de disponibilité privé.
Accès refusé
Vos tests de disponibilité échouent et renvoient des résultats VPC_ACCESS_DENIED
. Ce résultat signifie qu'un aspect de la configuration de votre réseau ou de l'autorisation du compte de service n'est pas correct.
Vérifiez l'autorisation de votre compte de service pour utiliser un projet de définition du champ d'application ou un projet surveillé, comme décrit dans Échec de la création du test de disponibilité.
Pour en savoir plus sur l'accès aux réseaux privés, consultez Configurer le projet de réseau.
Résultats anormaux des tests de disponibilité privés
Vous disposez d'un service Service Directory avec plusieurs VM, et votre configuration de service contient plusieurs points de terminaison. Lorsque vous arrêtez l'une des VM, votre test de disponibilité indique toujours que l'opération a réussi.
Lorsque la configuration de votre 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 hors service.
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 pour un contrôle de disponibilité privé à un point de terminaison cible, elle 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 de disponibilité |
Si vous essayez de remplacer ces valeurs, les conséquences suivantes peuvent 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
Vous ne voyez aucune donnée dans le tableau de bord des vérifications du temps d'activité lorsque votre vérification du temps d'activité se trouve dans un projet Google Cloud différent de celui du service Service Directory.
Assurez-vous que le projet Google Cloud qui contient la vérification du temps d'activité surveille le projet Google Cloud qui contient le service Service Directory.
Pour savoir comment lister les projets surveillés et en ajouter d'autres, consultez Configurer un champ d'application des métriques pour plusieurs projets.
Étapes suivantes
- Gérer les tests de disponibilité
- Créer des règles d'alerte pour les tests de disponibilité
- Représenter les métriques des tests de disponibilité sous forme de graphique
- Tarifs et limites