Définir le DNS zonal par défaut pour les nouveaux projets

Ce document explique comment mettre à jour votre règle DNS interne pour utiliser le DNS zonal pour les nouveaux projets. Le DNS zonal améliore la fiabilité des applications en isolant les pannes au sein des zones, ce qui évite les perturbations des services critiques tels que la création d'instances et la réparation automatique.

Avant de commencer

  • Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux Google Cloud services et aux API. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine en sélectionnant l'une des options suivantes:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. REST

      Pour utiliser les exemples d'API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à gcloud CLI.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

      Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Google Cloud.

Rôles requis

Pour obtenir les autorisations nécessaires pour afficher l'utilisation du DNS interne à l'échelle de l'organisation et mettre à jour la stratégie par défaut, demandez à votre administrateur de vous accorder les rôles IAM suivants:

  • Vérifier la stratégie DNS globale par défaut : Administrateur des règles de l'organisation (roles/orgpolicy.policyAdmin) sur le dossier ou l'organisation
  • Déterminer si un dossier est prêt à migrer vers un DNS zonal : Explorateur (roles/browser) sur le dossier ou l'organisation

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour afficher l'utilisation du DNS interne à l'échelle de l'organisation et mettre à jour la stratégie par défaut. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour afficher l'utilisation du DNS interne à l'échelle de l'organisation et mettre à jour la stratégie par défaut:

  • Définir une contrainte de règle d'administration : orgpolicy.*
  • Déterminer si un dossier est prêt à migrer vers un DNS zonal :
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • Rechercher les noms DNS globaux et les métadonnées de VM : compute.projects.get

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Présentation de la configuration

Lorsque vous définissez une règle d'administration pour remplacer le type DNS interne par défaut, les projets nouvellement créés utilisent le DNS zonal par défaut. La règle d'administration n'a pas d'incidence sur les projets existants où l'API Compute Engine est déjà activée. Pour migrer des projets existants vers le DNS zonal, consultez la section Migrer des projets existants vers le DNS zonal.

Nous vous recommandons d'appliquer une stratégie DNS zonale au niveau de l'organisation. Cette approche garantit que tous les nouveaux projets créés dans votre organisation utiliseront le DNS zonal, ce qui améliore leur fiabilité et leur résilience. Toutefois, vous devrez peut-être exempter certains dossiers de cette règle appliquée à l'ensemble de l'organisation. Il est nécessaire d'exclure des dossiers lorsque les nouveaux projets de ces dossiers dépendent de projets existants incompatibles avec le DNS zonal.

Le processus d'application d'une stratégie DNS zonale au niveau de l'organisation comprend les étapes suivantes:

  1. Répertoriez les projets et les dossiers: compilez la liste de tous les projets et des dossiers associés de votre organisation.
  2. Identifier les dossiers à exclure: identifiez les dossiers contenant les projets incompatibles identifiés à l'étape 1. Ces dossiers devront être temporairement exemptés de la règle DNS zonale.
  3. Définir la règle d'administration: appliquez la règle DNS zonale au niveau de l'organisation.
  4. Exclure des dossiers spécifiques: appliquez des exceptions aux dossiers identifiés à l'étape 3. Cela leur permet de continuer à utiliser le DNS global pendant que vous corrigez les projets incompatibles qu'ils contiennent.

Cette approche garantit que les nouveaux projets utilisent le DNS zonal pour une fiabilité améliorée, tout en tenant compte des dépendances existantes sur les anciens projets qui ne sont peut-être pas prêts à être migrés immédiatement.

Limites

L'activation des noms DNS zonaux dans l'ensemble de votre organisation applique les paramètres DNS zonaux aux instances d'autres services, tels que:

Vérifiez si vos applications utilisent l'un de ces services et utilisez l'analyse des requêtes pour identifier les problèmes de compatibilité avec le DNS zonal pour les dossiers et les projets associés à ces applications.

Vérifier si votre organisation utilise le DNS global par défaut

Le paramètre DNS par défaut de votre organisation dépend de deux facteurs:

  • Date de création de l'organisation:

    • Créée après le 6 septembre 2018: votre organisation utilise le DNS zonal par défaut. Aucune autre action de votre part n'est requise.
    • Créée avant le 6 septembre 2018: votre organisation utilise le DNS global par défaut. Envisagez de migrer vers un DNS zonal.

  • L'existence et l'application d'une contrainte liée aux règles d'administration:

    Même si votre organisation a été créée avant le 6 septembre 2018, un administrateur peut avoir appliqué une stratégie d'utilisation du DNS zonal pour tous les nouveaux projets créés dans l'organisation. Pour vérifier si une telle règle existe, vous pouvez utiliser la console Google Cloud ou Google Cloud CLI.

Console

  1. Accédez à la page IAM et administration>Identité et organisation de la console.

    Accéder à la page Identité et organisation

  2. Vérifiez la date d'inscription de l'organisation.

    Capture d'écran de la page "Identité et organisation" de la console, indiquant la date d'inscription

  3. Si votre organisation a été créée avant le 6 septembre 2018, vérifiez si une contrainte de règle d'administration définit le type DNS par défaut de tous les projets nouvellement créés sur DNS zonal.

    1. Accédez à la page IAM et administration>Règles d'administration dans la console Google Cloud.
    2. Dans le champ Filtre, saisissez constraints/compute.setNewProjectDefaultToZonalDNSOnly.
    3. Si la contrainte est configurée, cliquez sur le nom Définit le paramètre DNS interne des nouveaux projets sur le DNS zonal uniquement.
    4. Sur la page des détails de la règle, vérifiez l'état.
      • Si l'état est Appliqué, le type DNS interne par défaut est le DNS zonal pour tous les nouveaux projets créés dans l'organisation.
      • Sinon, le type DNS par défaut du projet est toujours déterminé par l'heure de création de l'organisation.
    5. Si la contrainte n'a pas été configurée pour l'organisation, le type DNS par défaut du projet est déterminé par la date de création de l'organisation.

gcloud

Exécutez les commandes organizations describe et resource-manager org-policies list pour déterminer le type DNS par défaut d'une organisation.

  1. Vérifiez la valeur de métadonnées creationTime de l'organisation.

    gcloud organizations describe ORGANIZATION_ID

    Remplacez ORGANIZATION_ID par l'ID de l'organisation ou le nom de domaine de l'organisation.

  2. Si votre organisation a été créée avant le 6 septembre 2018, déterminez si une contrainte de règle d'administration est configurée pour définir le type DNS par défaut de tous les projets nouvellement créés sur le DNS zonal.

    gcloud resource-manager org-policies list --organization=ORGANIZATION_ID \
   --filter="constraints/compute"

    Dans le résultat, recherchez constraints/compute.setNewProjectDefaultToZonalDNSOnly.

    1. Si la contrainte est présente et que Status est défini sur Enforced, tous les nouveaux projets créés dans l'organisation utilisent le DNS zonal par défaut.
    2. Si la contrainte n'est pas présente ou n'est pas appliquée, le type DNS par défaut est déterminé par la date de création de l'organisation, comme décrit à la première étape.

Déterminer quels projets d'un dossier ou d'une organisation utilisent le DNS global.

Pour déterminer quels projets utilisent le DNS global, nous vous recommandons d'utiliser BigQuery afin de créer une table qui répertorie les projets relatifs de votre organisation et leurs métadonnées. Vous pouvez ensuite utiliser ce tableau pour exécuter une requête.

  1. Créez un ensemble de données BigQuery.

  2. Exportez des métadonnées d'éléments pour votre organisation vers une table BigQuery.

    1. Assurez-vous que l'API Cloud Asset Inventory est activée.
    2. Configurez les autorisations requises pour utiliser l'API Cloud Asset Inventory.

    3. Exécutez la commande gcloud CLI suivante pour exporter l'élément compute.googleapis.com/Project :

      gcloud asset export \
   --content-type resource \
   --organization 'ORGANIZATION_ID' \
   --bigquery-table 'projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_NAME' \
   --asset-types='compute.googleapis.com/Project' \
   --output-bigquery-force

      Remplacez les éléments suivants :

      • ORGANIZATION_ID : numéro d'ID de l'organisation.
      • PROJECT_ID : ID du projet
      • DATASET_ID : nom de l'ensemble de données BigQuery
      • TABLE_NAME : table vers laquelle vous exportez les métadonnées. Si la table n'existe pas, BigQuery la crée.

  3. Accédez à la page BigQuery de la console Google Cloud.

  4. Sélectionnez Saisir une nouvelle requête.

  5. Dans la zone de texte de l'éditeur de requête, saisissez la requête GoogleSQL suivante, puis cliquez sur  Exécuter.

    SELECT
  JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting,
  count(*) as project_count
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY 1

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet
    • DATASET_ID : nom de l'ensemble de données BigQuery
    • TABLE_NAME : table contenant les métadonnées exportées à l'étape 2.

    Le DNS zonal est configuré pour les projets dont la valeur est ZONAL_ONLY pour vmDnsSetting. Sinon, les projets utilisent le DNS global par défaut.

  6. Facultatif : Pour obtenir une vue détaillée de vmDnsSetting pour chaque projet, saisissez la requête GoogleSQL suivante, puis cliquez sur Exécuter.

    SELECT
  SUBSTR(name,35) as project_id,
  JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting
FROM PROJECT_ID.DATASET_ID.TABLE_NAME

Déterminer si un dossier est prêt à être migré

Cette étape utilise un script bash et la table BigQuery créée dans la section précédente pour déterminer si le dossier est prêt pour la migration.

  • Le dossier est prêt si tous les projets ne comportent aucune requête incompatible avec un DNS zonal effectuée au cours des 30 derniers jours.
  • Si un dossier n'est pas prêt pour la migration, le script répond avec les ID de projet qui se trouvent dans le dossier et qui ne sont pas prêts pour la migration. Les projets figurant dans cette liste de résultats ne sont pas encore compatibles avec les DNS zonaux et nécessitent une action supplémentaire.

Procédez comme suit :

  1. Obtenez l'ID du dossier. Si vous ne connaissez pas l'ID du dossier, procédez comme suit :
    1. Dans la console Google Cloud, accédez à la page Ressources gérées.
    2. Appliquez le filtre Name:FOLDER_NAME pour obtenir l'ID du dossier.

  2. Interrogez la table BigQuery avec les données compute.Project assets exportées.

    Pour savoir comment créer la table BigQuery, consultez la section Déterminer quels projets d'un dossier ou d'une organisation utilisent le DNS global.

    Saisissez la requête GoogleSQL suivante, puis cliquez sur  Exécuter :

    SELECT
  SUBSTR(name,35) AS project_id,
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
WHERE CONTAINS_SUBSTR(ancestors, 'FOLDER_NUMBER')

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet
    • DATASET_ID : nom de l'ensemble de données BigQuery
    • TABLE_NAME : table contenant les métadonnées exportées.
    • FOLDER_NUMBER : ID du dossier

  3. Copiez la liste d'ID de projet et enregistrez-la dans un fichier.

  4. Exécutez le script suivant bash. Le script parcourt les ID de projet dans le fichier enregistré pour déterminer si un dossier est prêt pour la migration.

#!/bin/bash
inaccessible_projects=()
unready_projects=()

for project in $(cat ~/FILENAME | tr '\n' ' '); do
  echo -e "Checking project $project..."
  ERROR=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.error'`
  if ! [[ "$ERROR" -eq "null" ]]; then
    inaccessible_projects+=($project)
    continue
  fi
  QUERY_COUNT=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.timeSeriesData[0].pointData[0].values[0].int64Value'`
  if [[ "$QUERY_COUNT" -ne "null" ]] && [[ "$QUERY_COUNT" -ne "0" ]]; then
    unready_projects+=($project)
  fi
done

error_len=${#inaccessible_projects[@]}
unready_len=${#unready_projects[@]}

echo -e "$error_len projects were inaccessible"
echo -e "$unready_len projects were not ready for migration"

if [ $error_len -ne 0 ]; then
  echo "Unable to access the following projects:"
  for project in "${inaccessible_projects[@]}"; do
    echo "$project"
  done
fi
if [ $unready_len -ne 0 ]; then
  echo "The following projects are not ready for migration:"
  for project in "${unready_projects[@]}"; do
    echo "$project"
  done
fi

if (( $error_len + $unready_len > 0 )); then
  echo "This folder is NOT ready for gDNS -> zDNS migration."
else
  echo "This folder is ready for gDNS -> zDNS migration."
fi

Remplacez FILENAME par le nom du fichier dans lequel vous avez enregistré la liste des ID de projet.

Transmettez les résultats de l'analyse d'aptitude à la migration aux propriétaires du projet :

Exempter les dossiers non prêts à migrer vers le DNS zonal

Pour exempter un dossier de la règle d'administration, procédez comme suit pour définir l'option d'application de la règle au niveau du dossier sur Off.

  1. Connectez-vous à Google Cloud Console en tant que super-administrateur Google Workspace ou Cloud Identity.

  2. Dans la console, accédez à la page Règles d'administration.

    Accéder à la page Règles d'administration

  3. Cliquez sur Sélectionner, puis sélectionnez les dossiers à exempter de la règle d'administration.

    La console Google Cloud affiche la liste des contraintes de règles d'administration pour ce dossier sur une ou plusieurs pages.

  4. Pour trouver la contrainte de règle d'administration qui applique un DNS zonal, procédez comme suit :

    1. Cliquez sur Filtrer.
    2. Sélectionnez Nom.
    3. Définissez le nom du filtre sur Définit le paramètre DNS interne des nouveaux projets sur le DNS zonal uniquement.

  5. Cliquez sur le nom de la contrainte de règle d'administration pour ouvrir la page Détails de la règle.

  6. Cliquez sur Modifier.

  7. Sur la page Modifier, sélectionnez Personnaliser.

  8. Sous Application, sélectionnez Désactiver pour désactiver l'application de la contrainte. Cela signifie que le type DNS interne par défaut pour tous les projets du dossier est déterminé par la date de création de l'organisation.

  9. Cliquez sur Enregistrer.

Pour en savoir plus sur la personnalisation des contraintes de règles d'administration, consultez la section Personnaliser les règles pour les contraintes booléennes dans la documentation de Resource Manager.

Appliquer le DNS zonal par défaut pour les nouveaux projets

Pour définir la règle d'administration pour un dossier ou une organisation, procédez comme suit :

  1. Connectez-vous à Google Cloud Console en tant que super-administrateur Google Workspace ou Cloud Identity.

  2. Dans la console, accédez à la page Règles d'administration.

    Accéder à la page Règles d'administration

  3. Sélectionnez le dossier ou l'organisation dont vous souhaitez afficher les règles d'administration. La console Google Cloud affiche la liste des contraintes de règles d'administration disponibles. Cette liste peut s'étendre sur plusieurs pages.

  4. Pour trouver la règle permettant d'appliquer le DNS zonal, cliquez sur Filtre et sélectionnez Nom, puis définissez le nom du filtre sur Définit le paramètre DNS interne des nouveaux projets sur le DNS zonal uniquement.

  5. Cliquez sur le nom de la règle pour en afficher les détails.

    La page des détails de la règle fournit des informations sur la contrainte et son application actuelle.

    Par défaut, la mesure d'application n'est pas définie pour un dossier ou une organisation. Toutefois, si un dossier parent a une mesure d'application définie, l'application est héritée du dossier parent le plus proche ayant une mesure d'application définie. Pour en savoir plus, consultez la page Comprendre le processus d'évaluation hiérarchique.

  6. Pour personnaliser la règle d'administration, cliquez sur Modifier.

  7. Sur la page de modification, sélectionnez Personnaliser.

  8. Sous Application, sélectionnez Activé.

    Cela définit le type DNS interne par défaut pour tous les nouveaux projets de l'organisation sur le DNS zonal.

  9. Cliquez sur Enregistrer.

Pour valider la modification des règles d'administration, vous pouvez créer un projet sous le dossier ou l'organisation, puis créer et démarrer une instance de VM et vérifier si votre VM est configurée pour utiliser le DNS zonal.

Si un DNS global interne est nécessaire pour résoudre une requête de nom DNS intégrée à votre charge de travail, vous pouvez annuler cette modification au niveau de l'organisation ou du dossier en désactivant la mesure d'application.

Rétablir l'utilisation du DNS global pour une organisation ou un dossier

Pour rétablir l'utilisation du DNS global pour une organisation ou un dossier, arrêtez l'application de la règle d'administration pour le DNS zonal. Procédez comme suit :

  1. Désactivez la règle d'administration constraints/compute.setNewProjectDefaultToZonalDNSOnly au niveau de l'organisation ou du dossier. Pour savoir comment modifier cette règle, consultez la page Appliquer le DNS zonal par défaut pour les nouveaux projets.

    Définissez l'application de Définit le paramètre DNS interne des nouveaux projets sur le DNS zonal uniquement sur Désactivé.

  2. Si vous souhaitez revenir à l'utilisation du DNS global pour l'ensemble de l'organisation, vérifiez qu'aucun des dossiers de l'organisation n'applique la règle d'administration constraints/compute.setNewProjectDefaultToZonalDNSOnly.

  3. Pour vérifier que le DNS global est configuré pour vos projets et instances, consultez la section Déterminer quels projets d'un dossier ou d'une organisation utilisent le DNS global.

Étape suivante