Establece el DNS zonal como la opción predeterminada para los proyectos nuevos

En este documento, se explica cómo actualizar tu política de DNS interna para usar DNS zonal en proyectos nuevos. El DNS zonal mejora la confiabilidad de las aplicaciones, ya que aísla las interrupciones dentro de las zonas y evita las interrupciones de los servicios esenciales, como la creación de instancias y la curación automática.

Antes de comenzar

  • Si aún no lo hiciste, configura la autenticación. La autenticación es el proceso mediante el cual se verifica tu identidad para acceder a los servicios y las APIs de Google Cloud . Para ejecutar código o muestras desde un entorno de desarrollo local, puedes autenticarte en Compute Engine seleccionando una de las siguientes opciones:

    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

      Para usar las muestras de la API de REST en esta página en un entorno de desarrollo local, debes usar las credenciales que proporcionas a la CLI de gcloud.

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

        gcloud init

      Para obtener más información, consulta Autentica para usar REST en la documentación de autenticación de Google Cloud .

Roles obligatorios

Para obtener los permisos que necesitas para ver el uso de DNS interno en toda la organización y actualizar la política predeterminada, pídele a tu administrador que te otorgue los siguientes roles de IAM:

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

Estos roles predefinidos contienen los permisos necesarios para ver el uso de DNS interno en toda la organización y actualizar la política predeterminada. Para ver los permisos exactos que son necesarios, expande la sección Permisos requeridos:

Permisos necesarios

Se requieren los siguientes permisos para ver el uso de DNS interno en toda la organización y actualizar la política predeterminada:

  • Establece una restricción de política de la organización: orgpolicy.*
  • Determina si una carpeta está lista para migrar a DNS zonal:
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • Verifica los nombres de DNS globales y los metadatos de la VM: compute.projects.get

También puedes obtener estos permisos con roles personalizados o con otros roles predefinidos.

Descripción general de la configuración

Cuando configuras una política de la organización para anular el tipo de DNS interno predeterminado, los proyectos recién creados usan DNS zonal de forma predeterminada. La política de la organización no afecta los proyectos existentes en los que la API de Compute Engine ya está habilitada. Para cambiar los proyectos existentes a fin de usar DNS zonal, consulta Cambia proyectos existentes a DNS zonal.

Recomendamos aplicar una política de DNS zonal a nivel de la organización. Este enfoque garantiza que todos los proyectos nuevos creados en tu organización usen DNS zonal, lo que mejora su confiabilidad y resiliencia. Sin embargo, es posible que necesites exentar algunas carpetas de esta política de toda la organización. Es necesario eximir carpetas cuando los proyectos nuevos dentro de ellas dependen de proyectos existentes que no son compatibles con el DNS zonal.

El proceso de aplicación de una política de DNS zonal a nivel de la organización incluye los siguientes pasos:

  1. Obtén una lista de proyectos y carpetas: Compila una lista de todos los proyectos y sus carpetas asociadas dentro de tu organización.
  2. Identifica las carpetas que se eximen: Identifica las carpetas que contienen los proyectos incompatibles identificados en el paso 1. Estas carpetas deberán estar exentas temporalmente de la política de DNS de zona.
  3. Establece la política de la organización: Aplica la política de DNS de zona a nivel de la organización.
  4. Exenta carpetas específicas: Aplica exenciones a las carpetas identificadas en el paso 3. Esto les permite seguir usando el DNS global mientras abordas los proyectos incompatibles dentro de ellos.

Este enfoque garantiza que los proyectos nuevos usen DNS zonal para mejorar la confiabilidad, a la vez que se adaptan las dependencias existentes en proyectos más antiguos que podrían no estar listos para una migración inmediata.

Limitaciones

Habilitar nombres de DNS zonales en toda tu organización aplica la configuración de DNS zonal a las instancias de otros servicios, como los siguientes:

Revisa si tus aplicaciones usan alguno de estos servicios y usa el análisis de consultas para identificar problemas de compatibilidad con el DNS zonal para las carpetas y los proyectos asociados con esas aplicaciones.

Verifica si tu organización usa DNS global de forma predeterminada

La configuración predeterminada de DNS de tu organización depende de dos factores:

  • La fecha de creación de la organización:

    • Creación después del 6 de septiembre de 2018: Tu organización usa DNS zonal de forma predeterminada. No necesitas realizar ninguna otra acción.
    • Creado antes del 6 de septiembre de 2018: Tu organización usa el DNS global de forma predeterminada. Considera migrar a DNS zonal.

  • La existencia y aplicación de una restricción de la política de la organización:

    Incluso si tu organización se creó antes del 6 de septiembre de 2018, es posible que un administrador haya aplicado una política para usar el DNS zonal para todos los proyectos nuevos creados dentro de la organización. Para verificar si existe una política de este tipo, puedes usar la consola de Google Cloud o Google Cloud CLI.

Console

  1. Ve a la página IAM y administración>Identidad y organización en la consola.

    Ve a Identidad y organización.

  2. Verifica la fecha de registro de la organización.

    Captura de pantalla de la página Identidad y organización de la consola en la que se muestra la fecha de registro completada.

  3. Si tu organización se creó antes del 6 de septiembre de 2018, verifica si una restricción de la política de la organización establece el tipo de DNS predeterminado para todos los proyectos recién creados en DNS zonal.

    1. Ve a la página IAM y administración>Políticas de la organización en la consola de Google Cloud.
    2. En el campo Filtro, ingresa constraints/compute.setNewProjectDefaultToZonalDNSOnly.
    3. Si la restricción está configurada, haz clic en el nombre Establece la configuración de DNS interno para proyectos nuevos solo en DNS zonal.
    4. En la página Detalles de la política, verifica el Estado.
      • Si el estado es Forzado, el tipo de DNS interno predeterminado es DNS zonal para todos los proyectos nuevos que se crean en la organización.
      • De lo contrario, el tipo de DNS predeterminado del proyecto aún se determina con la hora de creación de la organización.
    5. Si la restricción no se configuró para la organización, el tipo de DNS predeterminado del proyecto se determina según la fecha de creación de la organización.

gcloud

Usa el comando organizations describe y el comando resource-manager org-policies list para determinar el tipo de DNS predeterminado para una organización.

  1. Verifica el valor de metadatos creationTime de la organización.

    gcloud organizations describe ORGANIZATION_ID

    Reemplaza ORGANIZATION_ID por el número de ID de la organización o el nombre de dominio de la organización.

  2. Si tu organización se creó antes del 6 de septiembre de 2018, determina si se configuró una restricción de política de la organización para establecer el tipo de DNS predeterminado de todos los proyectos creados recientemente en DNS zonal.

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

    En el resultado, busca constraints/compute.setNewProjectDefaultToZonalDNSOnly.

    1. Si la restricción está presente y Status es Enforced, todos los proyectos nuevos creados en la organización usarán DNS zonal de forma predeterminada.
    2. Si la restricción no está presente o no se aplica, el tipo de DNS predeterminado se determina con la fecha de creación de la organización, como se describe en el primer paso.

Determina qué proyectos en una organización o carpeta usan el DNS global

Para determinar qué proyectos usan el DNS global, recomendamos usar BigQuery para crear una tabla que enumere los proyectos relativos para tu organización y sus metadatos. Luego, puedes usar esta tabla para ejecutar una consulta.

  1. Crea un conjunto de datos de BigQuery.

  2. Exporta los metadatos de los recursos de tu organización a una tabla de BigQuery.

    1. Asegúrate de que la API de Cloud Asset Inventory esté habilitada.
    2. Configura los permisos necesarios para usar la API de Cloud Asset Inventory.

    3. Usa el siguiente comando de gcloud CLI para exportar el elemento 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

      Reemplaza lo siguiente:

      • ORGANIZATION_ID: El número de ID de la organización
      • PROJECT_ID: el ID del proyecto
      • DATASET_ID: El nombre del conjunto de datos de BigQuery
      • TABLE_NAME: Es la tabla a la que exportarás tus metadatos. Si la tabla no existe, BigQuery la crea.

  3. Ve a la página deBigQuery en la consola de Google Cloud.

  4. Selecciona Redactar una nueva consulta.

  5. En el área de texto del editor de consultas, ingresa la siguiente consulta de GoogleSQL y, luego, haz clic en Ejecutar.

    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

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID del proyecto
    • DATASET_ID: El nombre del conjunto de datos de BigQuery
    • TABLE_NAME: La tabla que contiene los metadatos exportados del paso 2.

    Los proyectos con el valor ZONAL_ONLY para vmDnsSetting tienen configurado el DNS zonal. De lo contrario, los proyectos usan DNS global de forma predeterminada.

  6. Opcional: para obtener una vista detallada de vmDnsSetting en cada proyecto, ingresa la siguiente consulta de GoogleSQL y, luego, haz clic en Ejecutar.

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

Determina si una carpeta está lista para la migración

En este paso, se usa una secuencia de comandos bash y la tabla de BigQuery creada en la sección anterior para determinar el nivel de preparación para la migración de la carpeta.

  • La carpeta está lista si todos los proyectos no realizaron ninguna consulta incompatible con el DNS zonal en los últimos 30 días.
  • Si una carpeta no está lista para la migración, la secuencia de comandos responde con los IDs del proyecto en la carpeta que impiden que la carpeta esté lista para la migración. Los proyectos de esta lista de resultados aún no son compatibles con el DNS zonal y requieren acciones adicionales.

Completa los siguientes pasos:

  1. Obtén el ID de la carpeta. Si no conoces el ID de la carpeta, haz lo siguiente:
    1. En la consola de Google Cloud, ve a la página Recursos administrados.
    2. Aplica el filtro Name:FOLDER_NAME para obtener el ID de la carpeta.

  2. Consulta la tabla de BigQuery con los datos de compute.Project assets exportados.

    Para obtener instrucciones sobre cómo crear la tabla de BigQuery, consulta Determina qué proyectos en una organización o carpeta usan el DNS global.

    Ingresa la siguiente consulta de GoogleSQL y, luego, haz clic en  Ejecutar:

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

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID del proyecto
    • DATASET_ID: El nombre del conjunto de datos de BigQuery
    • TABLE_NAME: Es la tabla que contiene los metadatos exportados.
    • FOLDER_NUMBER: El número de ID de la carpeta

  3. Copia la lista de IDs de proyecto y guárdala en un archivo.

  4. Ejecuta la siguiente secuencia de comandos bash: La secuencia de comandos itera en los IDs del proyecto en el archivo guardado para determinar si una carpeta está lista para la migración.

#!/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

Reemplaza FILENAME por el nombre del archivo en el que guardaste la lista de IDs de proyecto.

Comunica los resultados del análisis de preparación para la migración a los propietarios del proyecto:

  • En el caso de las carpetas y los proyectos que se pueden migrar de forma segura, notifica a los propietarios de los proyectos que pueden comenzar a migrar los proyectos listos.
  • En el caso de las carpetas que contienen proyectos que no son seguros para migrar, indícales a los propietarios de los proyectos que corrijan las consultas incompatibles.

Carpetas exentas que no están listas para migrar a DNS zonal

Para eximir una carpeta de la política de la organización, completa los siguientes pasos para establecer la opción de aplicación de la política en el nivel de la carpeta en Off.

  1. Accede a la consola de Google Cloud como un administrador avanzado de Google Workspace o Cloud Identity.

  2. En la consola, ve a la página Políticas de la organización.

    Ir a Políticas de la organización

  3. Haz clic en Seleccionar y, luego, selecciona las carpetas que deseas exentar de la política de la organización.

    La consola de Google Cloud muestra una lista de las restricciones de la política de la organización para esa carpeta en una o más páginas.

  4. Para encontrar la restricción de la política de la organización que aplica el DNS zonal, haz lo siguiente:

    1. Haz clic en Filtrar.
    2. Selecciona Nombre.
    3. Establece el nombre del filtro en Establece la configuración de DNS interno para proyectos nuevos solo en DNS zonal.

  5. Haz clic en el nombre de la restricción de la política de la organización para abrir la página Detalles de la política.

  6. Haz clic en Editar.

  7. En la página Editar, selecciona Personalizar.

  8. En Aplicación forzosa, selecciona Desactivada para inhabilitar la aplicación forzosa de la restricción. Esto significa que el tipo de DNS interno predeterminado para todos los proyectos de la carpeta se determina según la fecha de creación de la organización.

  9. Haz clic en Guardar.

Para obtener más información sobre cómo personalizar las restricciones de las políticas de la organización, consulta Personaliza políticas para restricciones booleanas en la documentación de Resource Manager.

Aplica el DNS zonal de forma predeterminada para proyectos nuevos

Realiza los siguientes pasos para establecer la política de la organización de una organización o carpeta:

  1. Accede a la consola de Google Cloud como un administrador avanzado de Google Workspace o Cloud Identity.

  2. En la consola, ve a la página Políticas de la organización.

    Ir a Políticas de la organización

  3. Selecciona la organización o carpeta cuyas políticas de la organización deseas ver. En la consola de Google Cloud, se muestra una lista de las restricciones de la política de la organización que están disponibles. La lista puede abarcar varias páginas.

  4. Para buscar la política que aplica el DNS zonal, haz clic en Filtro y selecciona Nombre y, luego, configura el nombre del filtro como Establece la configuración de DNS interno para proyectos nuevos solo en DNS zonal.

  5. Haz clic en el nombre de la política para ver sus detalles.

    En la página de detalles de la política, se proporciona información de la limitación y cómo esta se aplica en este momento.

    De forma predeterminada, la aplicación no está definida para una organización o carpeta. Sin embargo, si una carpeta superior tiene una aplicación definida, la aplicación se hereda de la carpeta superior más cercana que tiene una aplicación definida. Para obtener más información, consulta Comprende la evaluación de jerarquías.

  6. Para personalizar la política de la organización, haz clic en Editar.

  7. En la página de edición, selecciona Personalizar.

  8. En Aplicación, selecciona Activado.

    Esto establece el tipo de DNS interno predeterminado para todos los proyectos nuevos de la organización en DNS zonal.

  9. Haz clic en Guardar.

Para validar el cambio de la política de la organización, puedes crear un nuevo proyecto en la organización o carpeta y, luego, crea y luego inicia una instancia de VM y verificar si tu VM está habilitada para el DNS zonal.

Si se necesita un DNS global interno para resolver una consulta de nombre de DNS integrada en tu carga de trabajo, puedes revertir este cambio a nivel de la organización o de la carpeta a través de la inhabilitación de la aplicación.

Vuelve a usar del DNS global para una organización o carpeta

Para revertir una organización o carpeta para usar DNS global, detén la aplicación forzosa de la política de la organización para el DNS zonal. Completa los siguientes pasos.

  1. Inhabilita la política de la organización constraints/compute.setNewProjectDefaultToZonalDNSOnly a nivel de la organización o la carpeta. Si deseas obtener instrucciones para modificar esta política, consulta Aplica el DNS zonal de forma predeterminada para proyectos nuevos.

    Establece la aplicación forzosa de Establece la configuración de DNS interno para proyectos nuevos solo en DNS zonal en Desactivado.

  2. Si deseas volver a usar el DNS global para toda la organización, verifica que ninguna de las carpetas de la organización aplique la política de la organización constraints/compute.setNewProjectDefaultToZonalDNSOnly.

  3. Para verificar que el DNS global esté configurado para tus proyectos e instancias, consulta Determina qué proyectos en una organización o carpeta usan el DNS global.

¿Qué sigue?