이 글의 목표
- HTTPS로 배포할 것
- 백엔드와 프런트엔드 서버를 같은 도메인 같은 포트로 배포할 것
- example.com/api/*-> 백엔드
- example.com/* -> 프런트엔드
CICD는 이 글에서 다루지 않습니다.
도메인 준비(route53)
domain을 구매해서 호스팅 영역을 만들어야 한다
무료 도메인을 제공해주는 사이트도 있지만 편의상 route53에서 구매하기로 하였다.
5달러로 저렴한 .link로 구매해주었다 (환율이 많이 내려와서 다행이다)
이 글에서는 example.link 도메인을 구매했다고 가정하겠다.
인증서 발급 (AWS Certificate Manager)
AWS의 ACM(AWS Certificate Manager)으로 만드는 인증서는 무료로 발급받을 수 있다.
다만 AWS의 서비스에서만 사용할 수 있다는 한계가 있다.
예를 들어 nginx에 인증서파일을 넣는다던가 하는게 안된다는 것이다.
(내보내기활성화를 하면 가능한 거 같긴 한데 돈이 든다)
인증서를 만드는 법은 간단하다. 완전히 정규화된 도메인 이름에 아래와 같이 추가해주면 된다.
example.com // 루트 도메인
*.example.com // 모든 서브 도메인에 대한 인증서 우리는 route53으로 도메인을 구성했으므로 검증방법은 DNS 검증으로 한다.
인증서 요청을 완료했다면 Amazon Route 53에서 DNS 레코드 생성을 수행해주어야한다.
이것을 수행하면 route53 호스팅영역에서 CNAME이라는 레코드 유형의 레코드가 추가된다.
안하면 아무리 기다려도 인증서를 사용하지 못하는 것으로 알고 있다.
CNAME레코드란?
r53에서 DNS 레코드 생성이라는 것을 수행하고 route53으로 가면 CNAME 레코드가 하나 추가된 것을 확인할 수 있다.
CNAME(정식이름) 레코드는 도메인의 별칭을 정식이름으로 매핑하는 역할을 한다. DNS의 A 레코드가 도메인 to IP인데 CNAME 레코드는 도메인 to 도메인이라고 생각하면 된다.
예를 들어 보자
1. blog.example.link으로 요청
2. blog.example.link에 대한 CNAME 레코드를 찾아서 example.link 도메인을 찾음
3. 따라서 example.link의 IP 주소를 찾아서 보내줌
그렇다면 도메인 소유권을 확인할 때에는 왜 생성하는 걸까?
해당 도메인에 대한 CNAME 레코드를 생성할 수 있는 사람 = 도메인 소유자이기 때문이다.
원리는 아래와 같다
1. 서비스 제공자의 지시 : 정말 도메인 소유자라면_123456789.example.link으로 CNAME 레코드 만들어봐. 연결해야하는 곳은unique-token.acm-validations.aws이야
2. 도메인 소유자가 CNAME 레코드 생성
3. 서비스 제공자가 해당 DNS로 조회 : 즉_123456789.example.link가 정말unique-token.acm-validations.aws로 연결되는 지 확인
4. 소유권 인증 완료 : CNAME 레코드를 조작할 수 있으니 진짜 도메인 소유자가 맞구나
ALB
배경
- ec2에서 아래와 같이 배포하고 있다.
services:
server:
image: server-image-name
env_file: .env
ports:
- "80:8080"
client:
image: client-image-name
ports:
- "3000:3000"80 포트는 spring api 서버
3000 포트는 next.js 프론트엔드
요구사항은 아래와 같다
1. 동일한 포트로 배포할 것
2. /api/*인 경우 서버로 연결하고, 그 외의 경우에는 프런트엔드로 연결할 것
대상그룹만들기
서버에 대한 대상그룹과 클라이언트에 대한 대상그룹을 별도로 구성한다.
대상그룹에는 "대상이 트래픽을 수신하는 포트번호"를 설정할 수 있는데 서버 대상그룹에 대한 포트는 80으로, 클라이언트 대상그룹에 대한 포트는 3000으로 하면 로드밸런스가 해당하는 포트로 트래픽을 보내준다.
health-check
로드밸런서는 대상그룹과 연결될 경우, health-check를 통해 해당 인스턴스가 정상적으로 작동하는 지 검증한다. 로드밸런싱 업무를 수행해야하기 때문이다. 정상적으로 작동하지 않는 인스턴스에 요청을 보내면 사용자의 요청을 정상적으로 수행하는 것이 아니므로
이 health-check가 생각보다 다루기 힘든데 보안그룹으로 포트가 열려 있는지, 제대로 된 endpoints 연결되어 있는지 해당 엔드포인트가 200을 반환하는 지 잘 확인하도록 하자
대상그룹>상태검사>편집으로 들어가면 상태검사에 대한 세부조건을 검사할 수 있다.
로드밸런서 생성하기
우리는 https 리스너를 추가해주자.
인증서는 앞서 ACM으로 생성한 인증서를 넣어주면 된다.
리스너에 연결될 대상그룹은 클라이언트에 대한 대상그룹으로 넣어주면 된다.
ALB 리스너 조건 추가
/api/*인 경우 서버로 연결하고, 그 외의 경우에는 프런트엔드로 연결할 것
이 요구사항을 맞추어주기 위해 ALB 리스너에 조건을 추가하기로 하였다
물론 nginx 등의 도구를 사용할 수도 있겠지만 ALB 쓰는 김에 ALB 리스너 조건추가로 하였다.
리스너마다 규칙을 다르게 적용할 수 있다.
규칙을 바꿔줄 리스너를 클릭하면 규칙을 바꿔줄 수 있다
경로 규칙을 추가하자. /api/*라는 규칙을
그리고 작업에서 서버에 대한 대상그룹으로 연결해주자
/api/* 요청을 spring으로 보내준다
spring의 엔드포인트도 이에 맞춰서 /api/*로 연결되어야한다
server:
servlet:
context-path: /api
http로 접근해도 https로 리다이렉트
혹여나 사용자가 http로 접근해도 https로 접근할 수 있도록 리다이렉트하도록 하자
ALB에서 http 리스너를 추가하고 https로 리다이렉트하도록 조치하면 된다
route53으로 연결하기
다시 route 53으로 가서, 레코드 생성을 눌러주자
subdomain의 이름을 프로젝트명인 nearlib으로 한다
레코드 유형은 A로 한다.
별칭>Application Load Balancer에 대한 별칭 > 리전선택>해당하는 ALB 선택으로 ALB와 route53을 연결해준다
이제 조금의 시간이 지난 후 제대로 해당하는 도메인으로 접근하여 제대로 작동하는 지 확인하자
제대로 작동되지 않는다면 대상그룹의 health-check에 문제가 있는지, 보안그룹은 다 열려있는지 등등 확인해야한다.
