Defina o DNS zonal como predefinição para novos projetos

Este documento explica como atualizar a sua política de DNS interno para usar o DNS zonal para novos projetos. O DNS zonal melhora a fiabilidade das aplicações isolando as interrupções nas zonas, o que impede interrupções nos serviços críticos, como a criação de instâncias e a autorrecuperação.

Antes de começar

  • Se ainda não o tiver feito, configure a autenticação. A autenticação valida a sua identidade para aceder a Google Cloud serviços e APIs. Para executar código ou exemplos a partir de um ambiente de desenvolvimento local, pode autenticar-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. Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando: 

      gcloud init

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

    2. Set a default region and zone.

    REST

    Para usar os exemplos da API REST nesta página num ambiente de desenvolvimento local, usa as credenciais que fornece à CLI gcloud.

      Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando: 

      gcloud init

      Se estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.

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

Funções necessárias

Para receber as autorizações de que precisa para ver a utilização de DNS interno ao nível da organização e atualizar a política predefinida, peça ao seu administrador para lhe conceder as seguintes funções de IAM:

  • Verifique a política de DNS global predefinida: Administrador da política da organização (roles/orgpolicy.policyAdmin) na pasta ou na 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 atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Estas funções predefinidas contêm as autorizações necessárias para ver a utilização de DNS interno ao nível da organização e atualizar a política predefinida. Para ver as autorizações exatas que são necessárias, expanda a secção Autorizações necessárias:

Autorizações necessárias

São necessárias as seguintes autorizações para ver a utilização de DNS interno ao nível da organização e atualizar a política predefinida:

  • 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 os nomes de DNS globais e os metadados da VM: compute.projects.get

Também pode conseguir estas autorizações com funções personalizadas ou outras funções predefinidas.

Vista geral da configuração

Quando define uma política da organização para substituir o tipo de DNS interno predefinido, os projetos recém-criados usam o DNS zonal por predefinição. A política organizacional não afeta os projetos existentes nos quais a API Compute Engine já está ativada. Para mudar os projetos existentes para usar o DNS zonal, consulte o artigo Mudar os projetos existentes para o DNS zonal.

Recomendamos que aplique uma política de DNS zonal ao nível da organização. Esta abordagem garante que todos os novos projetos criados na sua organização usam o DNS zonal, o que melhora a respetiva fiabilidade e resiliência. No entanto, pode ter de isentar algumas pastas desta política ao nível 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 ao nível da organização inclui os seguintes passos:

  1. Reúna uma lista de projetos e pastas: compile uma lista de todos os projetos e das respetivas pastas associadas na sua organização.
  2. Identifique as pastas a isentar: identifique as pastas que contêm os projetos incompatíveis identificados no passo 1. Estas pastas têm de ser temporariamente isentas da política de DNS zonal.
  3. Defina a política organizacional: aplique a política de DNS zonal ao nível organizacional.
  4. Isentar pastas específicas: aplique isenções às pastas identificadas no passo 3. Isto permite-lhes continuar a usar o DNS global enquanto resolve os projetos incompatíveis nos mesmos.

Esta abordagem garante que os novos projetos usam o DNS zonal para uma maior fiabilidade, ao mesmo tempo que acomoda as dependências existentes em projetos mais antigos que podem não estar prontos para a migração imediata.

Limitações

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

Reveja se as suas aplicações usam algum destes serviços e use a análise de consultas para identificar problemas de compatibilidade com o DNS zonal para as pastas e os projetos associados a essas aplicações.

Verifique se a sua organização usa o DNS global por predefinição

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

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

    • Criadas após 6 de setembro de 2018: a sua organização usa o DNS zonal por predefinição. Não é necessária nenhuma ação adicional.
    • Criado antes de 6 de setembro de 2018: a sua organização usa o DNS global por predefinição. Deve considerar 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 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 para todos os novos projetos criados na organização. Para verificar se existe uma política deste tipo, pode usar a Google Cloud consola ou a Google Cloud CLI.

Consola

  1. Aceda à página IAM e administrador>Identidade e organização na consola.

    Aceda a Identidade e organização

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

    Uma captura de ecrã da página da consola Identidade e organização que mostra a data de inscrição concluída.

  3. Se a sua 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 predefinido para todos os projetos criados recentemente como DNS zonal.

    1. Aceda à página IAM e administração>Políticas de organização na Google Cloud consola.
    2. No campo Filtro, introduza constraints/compute.setNewProjectDefaultToZonalDNSOnly.
    3. Se a restrição estiver configurada, clique no nome Define a definição de DNS interna para novos projetos como DNS zonal apenas.
    4. Na página Detalhes da política, verifique o Estado.
      • Se o estado for Aplicado, o tipo de DNS interno predefinido é o DNS zonal para todos os novos projetos criados na organização.
      • Caso contrário, o tipo de DNS predefinido para o projeto continua a ser determinado pela hora de criação da organização.
    5. Se a restrição não tiver sido configurada para a organização, o tipo de DNS predefinido para o projeto é determinado pela data de criação da organização.

gcloud

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

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

    gcloud organizations describe ORGANIZATION_ID

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

  2. Se a sua organização foi criada antes de 6 de setembro de 2018, determine se existe uma restrição de política da organização configurada para definir o tipo de DNS predefinido para todos os projetos criados recentemente como DNS zonal.

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

    No resultado, procure constraints/compute.setNewProjectDefaultToZonalDNSOnly.

    1. Se a restrição estiver presente e Status for Enforced, todos os novos projetos criados na organização usam o DNS zonal por predefinição.
    2. Se a restrição não estiver presente ou não for aplicada, o tipo de DNS predefinido é determinado pela data de criação da organização, conforme descrito no primeiro passo.

Determine que projetos numa pasta ou numa organização usam o DNS global

Para determinar que projetos estão a usar o DNS global, recomendamos que use o BigQuery para criar uma tabela que liste os projetos relativos da sua organização e os respetivos metadados. Em seguida, pode usar esta tabela para executar uma consulta

  1. Crie um conjunto de dados do BigQuery.

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

    1. Certifique-se de que a API Cloud Asset Inventory está ativada.
    2. Configure as autorizaçõ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 está a exportar os metadados. Se a tabela não existir, o BigQuery cria-a.

  3. Aceda à BigQuery na Google Cloud consola.

  4. Selecione Compor uma nova consulta.

  5. Na área de texto do editor de consultas, introduza a seguinte consulta GoogleSQL e, de seguida, 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 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, do passo 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 predefinição.

  6. Opcional: para uma vista detalhada do vmDnsSetting para cada projeto, introduza a seguinte consulta GoogleSQL e, de seguida, 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

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

Este passo usa um script bash e a tabela do BigQuery criada na secção anterior para determinar a prontidão para a migração da pasta.

  • A pasta está pronta se todos os projetos não tiverem feito consultas que sejam incompatíveis com o DNS zonal nos últimos 30 dias.
  • Se uma pasta não estiver pronta para a migração, o script responde com os IDs dos projetos na pasta que estão a impedir que a pasta fique pronta para a migração. Os projetos nesta lista de resultados ainda não são compatíveis com o DNS zonal e requerem uma ação adicional.

Conclua os seguintes passos:

  1. Obtenha o ID da pasta. Se não souber o ID da pasta, faça o seguinte:
    1. Na Google Cloud consola, aceda à página Recursos geridos.
    2. Aplique o filtro Name:FOLDER_NAME para obter o ID da pasta.

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

    Para ver as instruções sobre como criar a tabela do BigQuery, consulte o artigo Determine que projetos numa pasta ou numa organização usam o DNS global.

    Introduza a seguinte consulta GoogleSQL e, de seguida, clique em  Executar:

    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 dos projetos e guarde-a num ficheiro.

  4. Execute o seguinte guião do bash. O script itera os IDs dos projetos no ficheiro guardado para determinar se uma pasta está pronta para a 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 ficheiro no qual guardou a lista de IDs dos projetos.

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

  • Para pastas e projetos seguros para migrar, notifique os proprietários dos projetos de que podem começar a migrar projetos prontos.
  • Para pastas que contêm projetos que não são seguros para migrar, dê instruções aos proprietários dos projetos para corrigirem consultas incompatíveis.

Exclua pastas que não estejam preparadas para migrar para o DNS zonal

Para isentar uma pasta da política da organização, conclua os seguintes passos para definir a opção de aplicação da política ao nível da pasta como Off.

  1. Inicie sessão na Google Cloud consola como superadministrador do Google Workspace ou Cloud ID.

  2. Na consola, aceda à página Políticas de organização.

    Aceda às políticas da organização

  3. Clique em Selecionar e, de seguida, selecione as pastas que quer isentar da política da organização.

    A Google Cloud consola apresenta uma lista de restrições da política da organização para essa pasta numa 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. Selecione Nome.
    3. Defina o nome do filtro como Define a definição de DNS interna para novos projetos como DNS zonal apenas.

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

  7. Na página Editar, selecione Personalizar.

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

  9. Clique em Guardar.

Para mais informações sobre a personalização das restrições da política da organização, consulte o artigo Personalizar políticas para restrições booleanas na documentação do Resource Manager.

Aplique o DNS zonal por predefinição para novos projetos

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

  1. Inicie sessão na Google Cloud consola como superadministrador do Google Workspace ou Cloud ID.

  2. Na consola, aceda à página Políticas de organização.

    Aceda às políticas da organização

  3. Selecione a pasta ou a organização para a qual quer ver as políticas de organização. A Google Cloud consola apresenta uma lista de restrições da política da organização disponíveis. A lista pode abranger várias páginas.

  4. Para encontrar a política que aplica o DNS zonal, clique em Filtrar e selecione Nome. Em seguida, defina o nome do filtro como Define a definição de DNS interna para novos projetos como DNS zonal apenas.

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

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

    Por predefinição, a aplicação é indefinida para uma pasta ou uma organização. No entanto, se uma pasta principal tiver uma aplicação definida, a aplicação é herdada da pasta principal mais próxima que tenha uma aplicação definida. Para mais informações, consulte o artigo Compreender a avaliação da hierarquia.

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

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

  8. Em Aplicação, selecione Ativar.

    Esta ação define o tipo de DNS interno predefinido para todos os novos projetos na organização como DNS zonal.

  9. Clique em Guardar.

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

Se for necessário o DNS global para resolver uma consulta de nome DNS incorporada na sua carga de trabalho, pode reverter esta alteração ao nível da organização ou da pasta desativando a aplicação.

Reverta para a utilização do DNS global para uma organização ou uma pasta

Para reverter uma organização ou uma pasta para a utilização do DNS global, pare a aplicação da política organizacional para o DNS zonal. Conclua os seguintes passos.

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

    Defina a aplicação de Sets the internal DNS setting for new projects to Zonal DNS Only como Desativado.

  2. Se quiser reverter para a utilização do DNS global para toda a organização, verifique se nenhuma das pastas na organização está a aplicar a política da organização constraints/compute.setNewProjectDefaultToZonalDNSOnly.

  3. Para verificar se o DNS global está configurado para os seus projetos e instâncias, consulte o artigo Determine que projetos numa pasta ou organização usam o DNS global.

O que se segue?