Definir o DNS zonal como padrão para novos projetos

Este documento explica como atualizar a política de DNS interno para usar o DNS zonal em novos projetos. O DNS zonal melhora a confiabilidade do aplicativo isolando falhas nas zonas, evitando interrupções em serviços essenciais, como a criação de instâncias e a autocorreção.

Antes de começar

  • Configure a autenticação, caso ainda não tenha feito isso. A autenticação é o processo de verificação da sua identidade para acesso a serviços e APIs do Google Cloud . Para executar códigos ou amostras de um ambiente de desenvolvimento local, autentique-se no Compute Engine selecionando uma das seguintes opções:

    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 as amostras da API REST nesta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para gcloud CLI.

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

        gcloud init

      Para mais informações, consulte Autenticar para usar REST na documentação de autenticação do Google Cloud.

Funções exigidas

Para ter as permissões necessárias para conferir o uso de DNS interno em toda a organização e atualizar a política padrão, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para conferir o uso de DNS interno em toda a organização e atualizar a política padrão. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As permissões a seguir são necessárias para conferir o uso de DNS interno em toda a organização e atualizar a política padrão:

  • Defina uma restrição de política da organização: orgpolicy.*
  • Determine se uma pasta está pronta para migrar para o DNS zonal:
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • Verifique nomes de DNS globais e metadados de VM: compute.projects.get

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Visão geral da configuração

Quando você define uma política da organização para substituir o tipo de DNS interno padrão, os projetos recém-criados usam o DNS zonal por padrão. A política da organização não afeta os projetos atuais em que a API Compute Engine já está ativada. Para alternar projetos atuais para que usem DNS por zona, consulte Como alternar projetos atuais para o DNS zonal.

Recomendamos aplicar uma política de DNS zonal no nível da organização. Essa abordagem garante que todos os novos projetos criados na sua organização usem o DNS zonal, melhorando a confiabilidade e a resiliência. No entanto, talvez seja necessário isentar algumas pastas dessa política da organização. A isenção de pastas é necessária quando novos projetos nessas pastas dependem de projetos existentes que são incompatíveis com o DNS zonal.

O processo de aplicação de uma política de DNS zonal no nível da organização inclui as seguintes etapas:

  1. Coletar uma lista de projetos e pastas: compile uma lista de todos os projetos e pastas associadas na sua organização.
  2. Identificar pastas para isenção: localize as pastas que contêm os projetos incompatíveis identificados na etapa 1. Essas pastas vão precisar ser temporariamente isentas da política de DNS zonal.
  3. Definir a política da organização: aplique a política de DNS zonal no nível da organização.
  4. Isentar pastas específicas: aplique isenções às pastas identificadas na Etapa 3. Isso permite que eles continuem usando o DNS global enquanto você resolve os projetos incompatíveis.

Essa abordagem garante que novos projetos usem o DNS zonal para melhorar a confiabilidade, além de acomodar dependências atuais em projetos mais antigos que talvez não estejam prontos para a migração imediata.

Limitações

Ativar nomes de DNS zonais em toda a organização aplica as configurações de DNS zonais a instâncias em outros serviços, como:

Verifique se os aplicativos usam algum desses serviços e use a análise de consultas para identificar problemas de compatibilidade com o DNS zonal nas pastas e nos projetos associados a esses aplicativos.

Verificar se a organização usa o DNS global por padrão

A configuração de DNS padrão da sua organização depende de dois fatores:

  • A data de criação da organização:

    • Criada após 6 de setembro de 2018: sua organização usa o DNS zonal por padrão. Você não precisa fazer mais nada.
    • Criada antes de 6 de setembro de 2018: sua organização usa o DNS global por padrão. Considere migrar para o DNS zonal.

  • A existência e a aplicação de uma restrição de política da organização:

    Mesmo que sua organização tenha sido criada antes de 6 de setembro de 2018, um administrador pode ter aplicado uma política para usar o DNS zonal em todos os novos projetos criados na organização. Para verificar se essa política existe, use o console do Google Cloud ou a CLI do Google Cloud.

Console

  1. Acesse a página IAM e administrador> Identidade e organização no console.

    Acessar "Identidade e organização"

  2. Verifique a data de inscrição da organização.

    Uma captura de tela da página do console "Identidade e organização" mostrando a data de conclusão da inscrição.

  3. Se a organização foi criada antes de 6 de setembro de 2018, verifique se uma restrição da política da organização define o tipo de DNS padrão em todos os projetos recém-criados como DNS zonal.

    1. Acesse a página IAM e administrador>Políticas da organização no console do Google Cloud.
    2. No campo Filtro, digite constraints/compute.setNewProjectDefaultToZonalDNSOnly.
    3. Se a restrição estiver configurada, clique no nome Define a configuração do DNS interno para novos projetos como "Somente DNS zonal".
    4. Na página Detalhes da política, verifique o Status.
      • Se o status for Aplicado, o tipo de DNS interno padrão será DNS zonal para todos os novos projetos criados na organização.
      • Caso contrário, o tipo de DNS padrão para o projeto ainda será determinado pelo horário de criação da organização.
    5. Se a restrição não tiver sido configurada para a organização, o tipo de DNS padrão do projeto será determinado pela data de criação da organização.

gcloud

Use os comandos organizations describe e resource-manager org-policies list para determinar o tipo de DNS padrão de uma organização.

  1. Verifique o valor dos metadados creationTime da organização.

    gcloud organizations describe ORGANIZATION_ID

    Substitua ORGANIZATION_ID pelo número do ID ou nome de domínio da organização.

  2. Se a organização foi criada antes de 6 de setembro de 2018, determine se uma restrição da política da organização está configurada para definir o tipo de DNS padrão em todos os projetos recém-criados como DNS zonal.

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

    Na saída, procure constraints/compute.setNewProjectDefaultToZonalDNSOnly.

    1. Se a restrição estiver presente e Status for Enforced, todos os novos projetos criados na organização vão usar o DNS zonal por padrão.
    2. Se a restrição não estiver presente ou não for aplicada, o tipo de DNS padrão será determinado pela data de criação da organização, conforme descrito na primeira etapa.

Determinar quais projetos em uma pasta ou organização usam DNS global

Para determinar quais projetos estão usando o DNS global, recomendamos usar o BigQuery para criar uma tabela que liste os projetos relativos à organização e os metadados deles. Em seguida, use essa tabela para executar uma consulta

  1. crie um conjunto de dados do BigQuery;

  2. Exporte os metadados do recurso da sua organização para uma tabela do BigQuery.

    1. Verifique se a API Cloud Asset Inventory está ativada.
    2. Configure as permissões necessárias para usar a API Cloud Asset Inventory.

    3. Use o seguinte comando da CLI gcloud para exportar o recurso 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

      Substitua:

      • ORGANIZATION_ID: o número do ID da organização
      • PROJECT_ID: o ID do projeto;
      • DATASET_ID: o nome do conjunto de dados do BigQuery.
      • TABLE_NAME: a tabela para a qual você está exportando os metadados. Se a tabela não existir, o BigQuery vai criar a tabela.

  3. Vá para a página BigQuery no console do Google Cloud.

  4. Selecione Criar uma nova consulta.

  5. Na área de texto do editor de consultas, insira a seguinte consulta do GoogleSQL e clique em Executar.

    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

    Substitua:

    • PROJECT_ID: o ID do projeto;
    • DATASET_ID: o nome do conjunto de dados do BigQuery.
    • TABLE_NAME: a tabela que contém os metadados exportados, da etapa 2.

    Os projetos com o valor ZONAL_ONLY para vmDnsSetting têm o DNS zonal configurado. Caso contrário, os projetos usam o DNS global por padrão.

  6. Opcional: para ter acesso a uma visualização detalhada de vmDnsSetting para cada projeto, insira a seguinte consulta do GoogleSQL e clique em Executar.

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

Determinar a prontidão para a migração de uma pasta

Esta etapa usa um script bash e a tabela do BigQuery criadas na seção anterior para determinar a prontidão da migração da pasta.

  • A pasta estará pronta se nenhum dos projetos tiver feito consultas incompatíveis com o DNS zonal nos últimos 30 dias.
  • Se uma pasta não estiver pronta para migração, o script vai responder com os IDs do projeto na pasta que estão impedindo que ela esteja pronta para a migração. Os projetos nesta lista de resultados ainda não são compatíveis com DNS zonal e exigem mais ações.

Siga estas etapas:

  1. Consiga o ID da pasta. Se você não souber o ID da pasta, faça o seguinte:
    1. No console do Google Cloud, acesse a página Recursos gerenciados.
    2. Aplique o filtro Name:FOLDER_NAME para conseguir o ID da pasta.

  2. Consultar a tabela do BigQuery com os dados compute.Project assets exportados.

    Para ver instruções sobre como criar a tabela do BigQuery, consulte Determinar quais projetos em uma pasta ou organização usam o DNS global.

    Digite a seguinte consulta do GoogleSQL e clique em Executar:

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

    Substitua:

    • PROJECT_ID: o ID do projeto;
    • DATASET_ID: o nome do conjunto de dados do BigQuery.
    • TABLE_NAME: a tabela que contém os metadados exportados.
    • FOLDER_NUMBER: o número do ID da pasta.

  3. Copie a lista de IDs de projetos e salve-a em um arquivo.

  4. Execute o script bash a seguir. O script faz a iteração dos IDs do projeto no arquivo salvo para determinar se uma pasta está pronta para migração.

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

Substitua FILENAME pelo nome do arquivo em que você salvou a lista de IDs do projeto.

Transmita os resultados da análise de prontidão para migração aos proprietários do projeto:

  • Para pastas e projetos com segurança para migração, notifique os proprietários do projeto que eles podem começar a migrar projetos prontos.
  • No caso de pastas que contenham projetos que não podem ser migrados, instrua os proprietários de projetos a corrigir consultas incompatíveis.

As pastas isentas não estão prontas para migrar para o DNS zonal

Para isentar uma pasta da política da organização, conclua as etapas a seguir para definir a opção de aplicação da política no nível da pasta como Off.

  1. Faça login no console do Google Cloud como superadministrador do Google Workspace ou do Cloud Identity.

  2. No console, acesse a página Políticas da organização.

    Acessar as políticas da organização

  3. Clique em Selecionar e escolha as pastas que você quer isentar da política da organização.

    O console do Google Cloud mostra uma lista de restrições de políticas da organização para essa pasta em uma ou mais páginas.

  4. Para encontrar a restrição da política da organização que aplica o DNS zonal:

    1. Clique em Filtrar.
    2. Selecionar {NOME}
    3. Defina o nome do filtro como Define a configuração do DNS interno para novos projetos como Somente DNS zonal.

  5. Clique no nome da restrição da política da organização para abrir a página Detalhes da política.

  6. Clique em Editar.

  7. Na página Editar, selecione Personalizar.

  8. Em Aplicação, selecione Desativada para desativar a aplicação da restrição. Isso significa que o tipo de DNS interno padrão para todos os projetos na pasta é determinado pela data de criação da organização.

  9. Clique em Salvar.

Para mais informações sobre como personalizar as restrições da política da organização, consulte Como personalizar políticas para restrições booleanas na documentação do Resource Manager.

Aplicar DNS zonal por padrão para novos projetos

Siga os seguintes passos para definir a política da organização para uma pasta ou organização:

  1. Faça login no console do Google Cloud como superadministrador do Google Workspace ou do Cloud Identity.

  2. No console, acesse a página Políticas da organização.

    Acessar as políticas da organização

  3. Selecione a pasta ou a organização que contém as políticas da organização que você quer visualizar. O console do Google Cloud exibe uma lista das restrições da política da organização disponíveis. A lista pode abranger várias páginas.

  4. Para encontrar a política para aplicar DNS por zona, clique em Filtrar e selecione Nome. Em seguida, defina o nome do filtro como Define a configuração de DNS interno para novos projetos somente para DNS por zona.

  5. Clique no nome da política para ver os detalhes dela.

    A página de detalhes da política fornece informações sobre a restrição e como a restrição é aplicada no momento.

    Por padrão, a aplicação é indefinida para uma pasta ou organização. No entanto, se uma pasta pai tiver uma aplicação definida, ela será herdada da pasta mãe mais próxima que tem uma aplicação definida. Para mais informações, consulte Noções básicas sobre a avaliação da hierarquia.

  6. Para personalizar a política da organização, clique em Editar.

  7. Na página de edição, selecione Personalizar.

  8. Em Aplicação, selecione Ativada.

    Isso define o tipo de DNS interno padrão para todos os novos projetos na organização como DNS zonal.

  9. Clique em Salvar.

Para validar a alteração da política da organização, crie um novo projeto na pasta ou organização, depois crie e inicie uma instância de VM e verifique se a VM está ativada para DNS por zona.

Se o DNS global interno for necessário para resolver uma consulta de nome DNS integrada à carga de trabalho, é possível reverter essa alteração no nível da organização ou da pasta desativando a aplicação.

Reverter para o uso de DNS global em uma organização ou pasta

Para reverter uma organização ou pasta para o uso do DNS global, interrompa a aplicação da política organizacional para o DNS zonal. Siga as etapas a seguir.

  1. Desative a política da organização constraints/compute.setNewProjectDefaultToZonalDNSOnly no nível da organização ou da pasta. Para instruções sobre como modificar essa política, consulte Aplicar DNS zonal por padrão para novos projetos.

    Defina a aplicação de Define a configuração do DNS interno para novos projetos como Somente DNS zonal como Desativada.

  2. Se você quiser voltar a usar o DNS global para toda a organização, verifique se nenhuma das pastas na organização está aplicando a política da organização constraints/compute.setNewProjectDefaultToZonalDNSOnly.

  3. Para verificar se o DNS global está configurado para seus projetos e instâncias, consulte Determinar quais projetos em uma pasta ou organização usam o DNS global.

A seguir