ドメイン名をアプリケーションに接続する

はじめに

アプリケーションは HTTP リクエストに応答しますが、利用者には名前が必要です。Route 53 のホストゾーンと A レコードを作成し、実際の DNS 応答を確認して、そのアドレスで用意されたアプリケーションにアクセスします。

先に AWS Foundations を完了してください。この独立した VM には、設定済みの AWS CLI アクセス、DNS 問い合わせサーバー、作業対象とは別の参照ゾーンが用意されています。個人の AWS アカウントやドメイン購入は不要です。上の AWS View でレコードを確認し、下の Terminal でコマンドを実行します。練習用の名前は .test で終わり、公開ドメインの登録や委任は行いません。

認定試験との関連

ラボの概要

アプリケーションの名前を作成する

このステップでは、用意されたアプリケーション用のホストゾーンと A レコードを作成します。

DNS は名前を IP アドレスなどの情報に変換します。ホストゾーンはドメインのレコードを保持します。A レコードは名前を IPv4 アドレスに対応付けます。アプリケーションの起動や接続は行いません。

ドメインは labex-n01.test、アプリケーション名は app.labex-n01.test です。アプリケーションは 127.0.0.1 の HTTP ポート 8081 で待ち受けます。このループバックアドレスは VM 自身を指し、リクエストは練習環境内に留まります。

ゾーンを作成します：

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)

$(...) は出力をシェル変数 ZONE_ID に保存します。--query はゾーン ID を選択し、--output text は引数として使える形式で出力します。CallerReference はこの作成リクエストを識別します。変数を保持するため、この Terminal を開いたままにしてください。

レコードの変更は JSON で指定します。引用符付きのヒアドキュメントは、その内容をそのまま record.json に書き込みます。秒単位の TTL は DNS キャッシュが応答を再利用できる期間を示します。このサーバーは権威ある応答を直接返します。ここでは再帰キャッシュを測定しません。

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

自分のゾーンに変更を適用します。file:// はローカル JSON ファイルを読み込みます：

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

応答は変更を識別し、設定結果を示します。次のステップで実際の DNS 応答を試します。保存されたレコードを確認します：

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

アプリケーション名、A、TTL 60、127.0.0.1 を確認してください。AWS View は、自分のゾーンのレコードと独立した参照ゾーンを表示します。参照ゾーンを変更しないでください。次に進む前にチェックを実行します。

DNS を問い合わせてアプリケーションにアクセスする

このステップでは、有効な DNS 応答、存在しない名前、成功した HTTP リクエストを区別します。

dig は DNS を問い合わせます。@127.0.0.1 は用意されたサーバー、-p 1053 は練習用ポートを選択します。+norecurse は再帰検索を行わない権威ある応答を要求します。VM のシステムリゾルバーを変更せず、サーバーを明示して試せます。

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

status: NOERROR と、名前、TTL 60、タイプ A、アドレス 127.0.0.1 を含む ANSWER が表示されるはずです。応答は実際の Route 53 レコードに基づきます。作成していない名前と比較します：

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

status: NXDOMAIN と、回答なしの結果を期待してください。DNS のやり取りは成功し、名前が存在しないことを伝えています。サーバーへの接続失敗ではありません。AWS View は直近の実際の問い合わせと回答数を表示します。

アドレスを保存します。+short は回答だけを出力します：

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

curl は HTTP リクエストを実行します。--resolve は取得したアドレスを、このリクエストの正確な名前とポートに使用します。ドメインを登録したり、システム DNS を変更したりしません。

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

期待される結果：

Delivery application ready

DNS がアドレスを返し、そのアドレスのアプリケーションに HTTP でアクセスできました。この二つは別の結果です。有効な DNS 応答だけでは、アプリケーションが動作しているとは証明できません。問い合わせとアクセスのチェックを実行します。

アプリケーション用ゾーンだけを削除する

このステップでは、自分のレコードとホストゾーンを削除し、名前が解決されなくなることを確認します。

通常、アプリケーションのレコードが残っているゾーンは削除できません。DELETE の変更は、レコードの名前、タイプ、TTL、値と一致する必要があります。同じレコードに削除アクションを指定します：

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

削除を適用し、空になったアプリケーション用ゾーンを削除します：

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"

削除した名前を再度問い合わせます：

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

NXDOMAIN を期待してください。用意されたアプリケーションは独立した準備用リソースなので、動作し続けることがあります。DNS レコードの削除は名前の対応付けをなくすだけで、アプリケーションを削除しません。AWS View には参照ゾーンだけが残るはずです。クリーンアップのチェックを実行します。

まとめ

ホストゾーンと A レコードを作成し、実際の DNS 応答を読み、返されたアドレスでアプリケーションにアクセスして、自分の DNS リソースだけを削除しました。レコード設定、名前解決、アプリケーションの可用性を区別しました。次は、CloudFront が制限された S3 オリジンからコンテンツを配信する仕組みを学びます。