Configurar um nome de domínio para uma aplicação

Introdução

A aplicação já responde a solicitações HTTP, mas seus usuários precisam de um nome. Crie uma zona hospedada no Route 53 e um registro A, observe a resposta DNS real e use o endereço retornado para acessar a aplicação fornecida.

Conclua primeiro AWS Foundations. Esta VM independente fornece acesso configurado à AWS CLI, um endpoint de consultas DNS e uma zona de referência não relacionada ao seu trabalho. Você não precisa de uma conta pessoal da AWS nem comprar um domínio. Observe os registros no AWS View, acima, e execute comandos no Terminal, abaixo. O nome de prática termina em .test; este laboratório não registra nem delega um domínio público.

Relação com a certificação

Visão geral do laboratório

Criar o nome da aplicação

Nesta etapa, crie uma zona hospedada e um registro A para a aplicação preparada.

DNS traduz nomes em informações, como endereços IP. Uma zona hospedada contém os registros de um domínio. Um registro A associa um nome a um endereço IPv4; ele não inicia a aplicação nem abre uma conexão de rede.

O domínio é labex-n01.test e o nome da aplicação será app.labex-n01.test. A aplicação escuta em 127.0.0.1, na porta HTTP 8081. Esse endereço de loopback se refere à VM, portanto todas as solicitações permanecem no ambiente de prática.

Crie a zona:

cd /home/labex/project
ZONE_ID=$(aws route53 create-hosted-zone \
  --name labex-n01.test \
  --caller-reference labex-n01-application \
  --query HostedZone.Id \
  --output text)

$(...) captura a saída do comando na variável de shell ZONE_ID. --query seleciona o ID da nova zona e --output text permite usá-lo como argumento. CallerReference distingue esta solicitação de criação. Mantenha este Terminal aberto para preservar a variável.

A alteração do registro é fornecida em JSON. O here-document entre aspas escreve texto literal em record.json. TTL, em segundos, informa por quanto tempo os caches DNS podem reutilizar a resposta. Este servidor responde diretamente à consulta autoritativa; o laboratório não mede um cache recursivo.

cat > record.json <<'JSON'
{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "app.labex-n01.test",
      "Type": "A",
      "TTL": 60,
      "ResourceRecords": [{"Value": "127.0.0.1"}]
    }
  }]
}
JSON

Aplique a alteração à sua zona. file:// lê o arquivo JSON local:

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --change-batch file://record.json

A resposta identifica a alteração e comprova a configuração; a próxima etapa testará uma resposta DNS real. Inspecione o registro salvo:

aws route53 list-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --query "ResourceRecordSets[?Type=='A']"

Encontre o nome da aplicação, A, TTL 60 e 127.0.0.1. O AWS View mostra o registro na sua zona ao lado da zona de referência independente. Não altere a referência. Execute a verificação antes de continuar.

Consultar DNS e acessar a aplicação

Nesta etapa, diferencie uma resposta DNS válida, um nome ausente e uma solicitação HTTP bem-sucedida.

dig é uma ferramenta de consulta DNS. @127.0.0.1 seleciona o servidor preparado e -p 1053 sua porta de prática. +norecurse solicita uma resposta autoritativa sem busca recursiva. Assim você testa explicitamente o servidor sem alterar o resolvedor do sistema da VM.

dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A

A resposta deve mostrar status: NOERROR e uma entrada ANSWER com o nome, TTL 60, tipo A e endereço 127.0.0.1. Ela vem do seu registro real no Route 53. Compare com um nome que você não criou:

dig +norecurse @127.0.0.1 -p 1053 missing.labex-n01.test A

Espere status: NXDOMAIN e nenhuma resposta. A troca DNS foi concluída e informou um nome ausente; a conexão com o servidor não falhou. O AWS View mostra a última consulta real e o número de respostas.

Capture agora o endereço. +short imprime somente a resposta:

APP_IP=$(dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A +short)
printf '%s\n' "$APP_IP"

curl faz a solicitação HTTP. --resolve usa o endereço recém-obtido para o nome e a porta exatos desta solicitação. Ele não registra um domínio nem altera o DNS do sistema.

curl --fail --noproxy '*' \
  --resolve "app.labex-n01.test:8081:${APP_IP}" \
  http://app.labex-n01.test:8081/

Saída esperada:

Delivery application ready

DNS retornou um endereço e HTTP alcançou uma aplicação nesse endereço. São resultados diferentes: uma resposta DNS válida, por si só, não comprova que a aplicação está funcionando. Execute a verificação da consulta e do acesso.

Remover somente a zona da aplicação

Nesta etapa, remova seu registro e sua zona hospedada e observe que o nome deixa de ser resolvido.

Normalmente não é possível excluir uma zona que ainda contém registros de aplicação. Uma alteração DELETE deve corresponder ao nome, tipo, TTL e valor do registro. Escreva o mesmo registro com a ação de exclusão:

cat > delete-record.json <<'JSON'
{
  "Changes": [{
    "Action": "DELETE",
    "ResourceRecordSet": {
      "Name": "app.labex-n01.test",
      "Type": "A",
      "TTL": 60,
      "ResourceRecords": [{"Value": "127.0.0.1"}]
    }
  }]
}
JSON

Aplique a exclusão e remova a zona da aplicação, agora vazia:

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --change-batch file://delete-record.json
aws route53 delete-hosted-zone \
  --id "$ZONE_ID"

Consulte novamente o nome removido:

dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A

Espere NXDOMAIN. A aplicação fornecida é uma preparação independente e pode continuar funcionando: excluir um registro DNS remove a associação do nome, não a aplicação. O AWS View deve manter somente a zona de referência. Execute a verificação de limpeza.

Resumo

Você criou uma zona hospedada e um registro A, leu respostas DNS reais, acessou a aplicação com o endereço obtido e removeu somente seus recursos DNS. Você diferenciou configuração de registros, resolução de nomes e disponibilidade da aplicação. Em seguida, aprenda como o CloudFront fornece conteúdo de uma origem S3 restrita.