Definir o DNS zonal como padrão para novos projetos

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

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 Trusted Cloud by S3NS . 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 Trusted Cloud console to access Trusted Cloud by S3NS services and APIs, you don't need to set up authentication.

  gcloud

  1. Instale a Google Cloud CLI e faça login nela com sua identidade federada. Depois de fazer login, inicialize a Google Cloud CLI executando o seguinte comando:

     gcloud init

  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 a CLI gcloud.

  Instale a Google Cloud CLI e faça login nela com sua identidade federada. Depois de fazer login, inicialize a Google Cloud CLI executando o seguinte comando:

  gcloud init

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

Funções exigidas

Para ter as permissões necessárias para ver o uso interno de DNS 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:

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

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 visualizar o uso interno de DNS 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:

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 organização usem o DNS zonal, melhorando a confiabilidade e a capacidade de recuperação deles. No entanto, talvez seja necessário isentar algumas pastas dessa política em toda a organização. A isenção de pastas é necessária quando novos projetos dentro delas dependem de projetos atuais 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 pastas associadas na sua organização.
2. Identifique as pastas a serem excluídas: localize as pastas que contêm os projetos incompatíveis identificados na Etapa 1. Essas pastas precisam ser temporariamente isentas da política de DNS zonal.
3. Defina a política da organização: aplique a política de DNS zonal no nível da organização.
4. Exentar 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 os novos projetos usem o DNS zonal para aumentar a confiabilidade, além de acomodar dependências em projetos mais antigos que talvez não estejam prontos para migração imediata.

Limitações

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

• 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 Batch
• Dataproc e Dataflow

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 projetos associados a esses aplicativos.

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

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

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

  • Criada depois de 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 a 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 uma política desse tipo existe, use o console Trusted Cloud ou a Google Cloud CLI.

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

Para determinar quais projetos estão usando 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 a criará.

3. Acesse a página BigQuery no consoleTrusted Cloud .

4. Selecione add_box Criar uma nova consulta.

5. Na área de texto do editor de consultas, insira a seguinte consulta do GoogleSQL e clique em play_arrow 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 play_arrow 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 de uma pasta para migração

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 Trusted 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 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 play_arrow 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 Trusted 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 Trusted Cloud exibe 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 Trusted 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 Trusted Cloud mostra uma lista das 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 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 usar o 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

• Os projetos atuais que usam DNS global precisam ser migrados separadamente. Para mais informações, consulte Atualizar seus projetos para usar o DNS zonal.