Definir DNS zonal como padrão para novos projetos

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Este documento explica como atualizar sua política interna de DNS para usar DNS zonal em novos projetos. O DNS zonal melhora a confiabilidade dos aplicativos isolando interrupções dentro das zonas, evitando interrupções em serviços críticos, como criação de instâncias e recuperação automática.

Antes de começar

• Se ainda não o fez, configure a autenticação. Autenticação é o processo pelo qual sua identidade é verificada para acesso a Google Cloud serviços e APIs. Para executar códigos ou amostras em um ambiente de desenvolvimento local, você pode se autenticar 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. After installing the Google Cloud CLI, initialize it by running the following command:

     gcloud init

     If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  2. Set a default region and zone.

  REST

  Para usar as amostras da API REST nesta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para gcloud CLI.

  After installing the Google Cloud CLI, initialize it by running the following command:

  gcloud init

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

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

Funções obrigatórias

Para obter as permissões necessárias para visualizar 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ê as seguintes funções do IAM:

• Verifique a política DNS global padrão: Administrador de políticas da organização ( roles/orgpolicy.policyAdmin ) na pasta ou organização
• Determine se uma pasta está pronta para migrar para DNS zonal: Navegador ( roles/browser ) na pasta ou organização

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

Essas funções predefinidas contêm as permissões necessárias para visualizar o uso de DNS interno em toda a organização e atualizar a política padrão. Para ver as permissões exatas necessárias, expanda a seção Permissões necessárias :

Você também poderá obter essas permissões com funções personalizadas ou outras funções predefinidas .

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 existentes em que a API Compute Engine já está ativada. Para mudar projetos existentes para usar DNS zonal, consulte mudar projetos existentes para DNS zonal .

Recomendamos a aplicação de 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 usarão DNS zonal, melhorando sua confiabilidade e resiliência. No entanto, talvez seja necessário isentar algumas pastas desta política para toda a organização. A isenção de pastas é necessária quando novos projetos dentro dessas 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. Reúna uma lista de projetos e pastas : Compile uma lista de todos os projetos e suas pastas associadas em sua organização.
2. Identifique as pastas a serem isentas : identifique as pastas que contêm os projetos incompatíveis identificados na Etapa 1. Essas pastas precisarão ser temporariamente isentas da política DNS zonal.
3. Definir a política organizacional : aplique a política de DNS zonal no nível organizacional.
4. Isentar pastas específicas : aplique isenções às pastas identificadas na Etapa 3. Isso permite que elas continuem usando o DNS global enquanto você aborda os projetos incompatíveis dentro delas.

Essa abordagem garante que novos projetos utilizem DNS zonal para maior confiabilidade, ao mesmo tempo que acomoda dependências existentes em projetos mais antigos que podem não estar prontos para migração imediata.

Limitações

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

• Ambiente flexível do App Engine , Google Kubernetes Engine e contêineres em execução no Compute Engine
• Cloud SQL , funções do Cloud Run e lote
• Dataproc e Dataflow

Revise se seus aplicativos usam algum desses serviços e use a análise de consulta para identificar problemas de compatibilidade com DNS zonal para as pastas e projetos associados a esses aplicativos.

Verifique se sua organização usa DNS Global por padrão

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

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

  • Criado após 6 de setembro de 2018: sua organização usa DNS zonal por padrão. Nenhuma ação adicional é necessária.
  • Criado antes de 6 de setembro de 2018: sua organização usa DNS global por padrão. Você deve considerar migrar para DNS zonal.

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

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

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

Para determinar quais projetos usam DNS global, recomendamos usar o BigQuery para criar uma tabela que liste os projetos relativos da sua organização e os metadados deles. Você pode então usar esta tabela para executar uma consulta

1. Crie um conjunto de dados do BigQuery .

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

   1. Certifique-se de que a API Cloud Asset Inventory esteja 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 o seguinte:

      • ORGANIZATION_ID : o número de 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 seus metadados. Se a tabela não existir, o BigQuery a criará.

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

4. Selecione add_box Componha uma nova consulta .

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

   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 o seguinte:

   • 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.

   Projetos com o valor ZONAL_ONLY para vmDnsSetting possuem DNS zonal configurado. Caso contrário, os projetos usarão DNS global por padrão.

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

   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 preparação para migração de uma pasta

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

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

Conclua as seguintes etapas:

1. Obtenha 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 obter o ID da pasta.

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

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

   Insira a seguinte consulta GoogleSQL e clique em play_arrow Run :

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

   Substitua o seguinte:

   • 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 de ID da pasta

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

4. Execute o seguinte script bash . O script percorre os 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 no qual você salvou a lista de IDs do projeto.

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

• Para pastas e projetos cuja migração é segura, notifique os proprietários do projeto de que eles podem começar a migrar projetos prontos .
• Para pastas que contêm projetos cuja migração não é segura, instrua os proprietários do projeto a corrigir consultas incompatíveis .

Pastas isentas que não estão prontas para migrar para DNS zonal

Para isentar uma pasta da política da organização, conclua as etapas a seguir para definir a opção de imposiçã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 .

   Acesse as políticas da organização

3. Clique em Selecionar e selecione as pastas que deseja isentar da política da organização.

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

4. Para encontrar a restrição de política da organização que impõe o DNS zonal:

   1. Clique em Filtrar .
   2. Selecione Nome .
   3. Defina o nome do filtro como Define a configuração de 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 Desativado 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 obter mais informações sobre como personalizar restrições de política da organização, consulte Personalização de políticas para restrições booleanas na documentação do Resource Manager.

Aplicar DNS zonal por padrão para novos projetos

Use as etapas a seguir 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 .

   Acesse as políticas da organização

3. Selecione a pasta ou organização para a qual deseja visualizar as políticas da organização. O console do Google Cloud exibe uma lista de restrições de políticas da organização disponíveis. A lista pode abranger várias páginas.

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

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

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

   Por padrão, a imposição é indefinida para uma pasta ou organização. No entanto, se uma pasta pai tiver uma imposição definida, a imposição será herdada da pasta pai mais próxima que tenha uma imposição definida. Para obter mais informações, consulte Noções básicas sobre avaliação de 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 Ativado .

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

9. Clique em Salvar .

Para validar a alteração da política da organização, você pode criar um novo projeto na pasta ou organização, criar e iniciar uma instância de VM e verificar se sua VM está habilitada para DNS zonal .

Se o DNS global for necessário para resolver uma consulta de nome DNS incorporada à sua carga de trabalho, você poderá reverter essa alteração no nível da organização ou da pasta desabilitando a imposição.

Voltar a usar DNS global para uma organização ou pasta

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

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

   Defina a aplicação de Define a configuração de DNS interno para novos projetos como Zonal DNS Only como Off .

2. Se você quiser voltar a usar o DNS global para toda a organização, verifique se nenhuma das pastas da organização está aplicando as 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 DNS global .

O que vem a seguir

• Quaisquer projetos existentes que utilizem DNS global deverão ser migrados separadamente. Para obter mais informações, consulte Atualizar seus projetos para usar DNS zonal .