Configurer un nom de domaine pour une application

Introduction

L’application répond déjà aux requêtes HTTP, mais les utilisateurs ont besoin d’un nom. Créez une zone hébergée Route 53 et un enregistrement A, observez la réponse DNS réelle, puis utilisez l’adresse retournée pour accéder à l’application fournie.

Terminez d’abord AWS Foundations. Cette VM indépendante fournit un accès AWS CLI configuré, un point de requête DNS et une zone de référence sans rapport avec votre travail. Aucun compte AWS personnel ni achat de domaine n’est nécessaire. Observez les enregistrements dans AWS View, en haut, et exécutez les commandes dans Terminal, en bas. Le nom d’exercice se termine par .test ; ce laboratoire n’enregistre ni ne délègue de domaine public.

Lien avec la certification

Aperçu du laboratoire

Créer le nom de l’application

Dans cette étape, créez une zone hébergée et un enregistrement A pour l’application préparée.

DNS traduit les noms en informations telles que des adresses IP. Une zone hébergée contient les enregistrements d’un domaine. Un enregistrement A associe un nom à une adresse IPv4 ; il ne démarre pas l’application et n’ouvre pas de connexion.

Le domaine est labex-n01.test et le nom de l’application sera app.labex-n01.test. L’application écoute sur 127.0.0.1, port HTTP 8081. Cette adresse de bouclage désigne la VM ; les requêtes restent donc dans l’environnement d’exercice.

Créez la zone :

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)

$(...) capture la sortie dans la variable shell ZONE_ID. --query sélectionne l’ID de la zone et --output text permet de l’utiliser comme argument. CallerReference distingue cette demande de création. Gardez ce Terminal ouvert pour conserver la variable.

Le changement d’enregistrement est fourni en JSON. Le here-document entre guillemets écrit du texte littéral dans record.json. TTL, exprimé en secondes, indique pendant combien de temps les caches DNS peuvent réutiliser la réponse. Ce serveur répond directement à une requête faisant autorité ; l’exercice ne mesure pas un cache récursif.

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

Appliquez le changement à votre zone. file:// lit le fichier JSON local :

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

La réponse identifie le changement et prouve la configuration ; l’étape suivante testera une réponse DNS réelle. Examinez l’enregistrement sauvegardé :

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

Repérez le nom, A, TTL 60 et 127.0.0.1. AWS View affiche cet enregistrement dans votre zone, à côté de la zone de référence indépendante. Ne modifiez pas la référence. Lancez la vérification avant de continuer.

Interroger DNS et contacter l’application

Dans cette étape, distinguez une réponse DNS valide, un nom absent et une requête HTTP réussie.

dig interroge DNS. @127.0.0.1 sélectionne le serveur fourni et -p 1053 son port d’exercice. +norecurse demande une réponse faisant autorité, sans recherche récursive. Le serveur est testé explicitement, sans modifier le résolveur système de la VM.

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

La réponse doit afficher status: NOERROR et une entrée ANSWER avec le nom, TTL 60, type A et adresse 127.0.0.1. Elle provient de votre véritable enregistrement Route 53. Comparez avec un nom non créé :

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

Attendez status: NXDOMAIN, sans réponse. L’échange DNS a réussi et signale un nom absent ; il ne s’agit pas d’un échec de connexion au serveur. AWS View affiche la dernière requête réelle et son nombre de réponses.

Capturez maintenant l’adresse. +short affiche uniquement la réponse :

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

curl effectue la requête HTTP. --resolve utilise l’adresse obtenue pour le nom et le port exacts de cette requête ; il n’enregistre pas de domaine et ne modifie pas le DNS système.

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

Résultat attendu :

Delivery application ready

DNS a retourné une adresse, puis HTTP a atteint l’application à cette adresse. Ces résultats sont distincts : une réponse DNS valide ne prouve pas à elle seule que l’application fonctionne. Lancez la vérification de la requête et de l’accès.

Supprimer uniquement la zone de l’application

Dans cette étape, supprimez votre enregistrement et votre zone, puis observez que le nom ne se résout plus.

Une zone contenant encore des enregistrements applicatifs ne peut normalement pas être supprimée. Un changement DELETE doit correspondre au nom, au type, au TTL et à la valeur de l’enregistrement. Écrivez le même enregistrement avec l’action de suppression :

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

Appliquez la suppression, puis retirez la zone applicative désormais vide :

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"

Interrogez de nouveau le nom supprimé :

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

Attendez NXDOMAIN. L’application fournie est un élément de préparation indépendant et peut continuer à fonctionner : supprimer le DNS retire l’association du nom, pas l’application. AWS View ne doit conserver que la zone de référence. Lancez la vérification du nettoyage.

Résumé

Vous avez créé une zone hébergée et un enregistrement A, lu des réponses DNS réelles, accédé à l’application avec l’adresse obtenue et supprimé uniquement vos ressources DNS. Vous avez distingué configuration des enregistrements, résolution des noms et disponibilité de l’application. Découvrez ensuite comment CloudFront fournit du contenu depuis une origine S3 restreinte.