도메인 이름을 애플리케이션에 연결하기

소개

애플리케이션은 이미 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으로 제공합니다. 따옴표로 감싼 here-document는 텍스트를 그대로 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 오리진에서 콘텐츠를 제공하는 방법을 배웁니다.