Configurar un nombre de dominio para una aplicación

Introducción

La aplicación ya responde a solicitudes HTTP, pero sus usuarios necesitan un nombre. Crea una zona alojada de Route 53 y un registro A, observa la respuesta DNS real y utiliza la dirección devuelta para acceder a la aplicación preparada.

Completa primero AWS Foundations. Esta VM independiente proporciona acceso configurado a AWS CLI, un servidor de consultas DNS y una zona de referencia ajena a tu trabajo. No necesitas una cuenta personal de AWS ni comprar un dominio. Observa los registros en AWS View, arriba, y ejecuta comandos en Terminal, abajo. El nombre de práctica termina en .test; no se registra ni delega un dominio público.

Relevancia para la certificación

Vista general del laboratorio

Crear el nombre de la aplicación

En este paso, crea una zona alojada y un registro A para la aplicación preparada.

DNS convierte nombres en información, como direcciones IP. Una zona alojada guarda los registros de un dominio. Un registro A asocia un nombre con una dirección IPv4; no inicia la aplicación ni abre una conexión.

El dominio es labex-n01.test y el nombre de la aplicación será app.labex-n01.test. La aplicación escucha en 127.0.0.1, puerto HTTP 8081. Esta dirección de bucle local corresponde a la VM, por lo que las solicitudes permanecen en el entorno de práctica.

Crea la 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 la salida en la variable de shell ZONE_ID. --query selecciona el ID de la zona y --output text permite utilizarlo como argumento. CallerReference distingue esta solicitud de creación. Mantén abierto este Terminal para conservar la variable.

El cambio del registro se proporciona en JSON. El here-document entre comillas escribe texto literal en record.json. TTL, en segundos, indica cuánto puede reutilizarse la respuesta en cachés DNS. El servidor responde directamente a una consulta autoritativa; aquí no se mide una caché recursiva.

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

Aplica el cambio a tu zona. file:// lee el archivo JSON local:

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

La respuesta identifica el cambio y demuestra la configuración; el siguiente paso probará una respuesta DNS real. Inspecciona el registro guardado:

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

Busca el nombre de la aplicación, A, TTL 60 y 127.0.0.1. AWS View muestra el registro en tu zona junto a la zona de referencia independiente. No modifiques la referencia. Ejecuta la comprobación antes de continuar.

Consultar DNS y solicitar la aplicación

En este paso, distingue una respuesta DNS válida, un nombre ausente y una solicitud HTTP correcta.

dig consulta DNS. @127.0.0.1 selecciona el servidor preparado y -p 1053 su puerto de práctica. +norecurse solicita una respuesta autoritativa sin búsqueda recursiva. Así se prueba el servidor explícitamente, sin cambiar el resolvedor del sistema de la VM.

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

Debe aparecer status: NOERROR y una entrada ANSWER con el nombre, TTL 60, tipo A y dirección 127.0.0.1. La respuesta procede de tu registro real de Route 53. Compárala con un nombre que no has creado:

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

Espera status: NXDOMAIN y ninguna respuesta. El intercambio DNS se completó y comunicó que falta el nombre; no falló la conexión con el servidor. AWS View muestra la última consulta real y el número de respuestas.

Captura ahora la dirección. +short imprime únicamente la respuesta:

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

curl realiza la solicitud HTTP. --resolve utiliza la dirección recién obtenida para el nombre y puerto exactos de esta solicitud. No registra un dominio ni cambia el DNS del sistema.

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

Resultado esperado:

Delivery application ready

DNS devolvió una dirección y HTTP alcanzó una aplicación en ella. Son resultados distintos: una respuesta DNS válida no demuestra por sí sola que la aplicación esté funcionando. Ejecuta la comprobación de consulta y acceso.

Eliminar únicamente la zona de la aplicación

En este paso, elimina tu registro y zona alojada, y observa que el nombre deja de resolverse.

Normalmente no puede eliminarse una zona que todavía contiene registros de aplicación. Un cambio DELETE debe coincidir con el nombre, tipo, TTL y valor del registro. Escribe el mismo registro con la acción de eliminación:

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

Aplica la eliminación y borra la zona de aplicación ya vacía:

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"

Consulta otra vez el nombre eliminado:

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

Espera NXDOMAIN. La aplicación preparada es un recurso independiente y puede seguir funcionando: eliminar un registro DNS quita la asociación del nombre, no la aplicación. AWS View debe conservar únicamente la zona de referencia. Ejecuta la comprobación de limpieza.

Resumen

Creaste una zona alojada y un registro A, leíste respuestas DNS reales, accediste a la aplicación con la dirección obtenida y eliminaste únicamente tus recursos DNS. Diferenciaste configuración de registros, resolución de nombres y disponibilidad de la aplicación. A continuación, aprende cómo CloudFront sirve contenido desde un origen S3 restringido.