2024. 10. 4. 16:55ㆍ카테고리 없음
Https
Https는 SSL이라는 보안 프로토콜을 위해서 HTTP통신을 하는 프로토콜을 말합니다.
( 요즘은 발전된 버전인 TSL를 사용한다고 합니다. https는 우선 구글 검색엔진에 가산점이 있습니다. http는 브라우저에서 보안 위험 표시가 나옵니다. )
진행 과정
도메인 구매 --> 도메인 인증 --> ACM 인증서 발급 --> Target Group 생성 --> Load Balancer 생성 --> 규칙 수정 --> Health check 성공 위와 같은 방식으로 진행하겠습니다.
가비아에서 도메인 구매
우선 저는 현재 EC2를 배포해놓은 상황이니 가비아에 가서 도메인을 구매해주겠습니다.
도메인을 구매해주는 이유는 퍼블릭 ip주소를 외우기 매우 어려울뿐더러 프론트에서 ip연결시에 더 편리하기 때문입니다.
우선 가비아에 접속해서 도메인은 구매해줍니다.
저는 기존에 있던 도메인의 유효기간이 남아있어서 해당 도메인으로 진행하였습니다.
Route53
그럼 이제 AWS Route53에 접속해줍니다.
DNS 관리 하단에 호스팅 영역 생성에 들어가줍니다.
그 후 가비아에서 구매한 도메인을 넣어줍니다.
설명은 자신만 보는 것이니 적어주셔도되고 안적어주셔도됩니다.
호스팅 영역을 생성해주면 레코드들이 생성된 걸 확인할 수 있습니다.
여기서 NS 유형의 레코드에 우측 값들을 가비아의 네임서버에 기재해주어야합니다.
여기 네임서버에 1234차 순으로 해당 NS 유형에 있는 우측 값들을 기재해줍니다.
( 이때 마지막에 있는 .은 반드시 빼고 기재해줍니다. )
다음으로 소유자 인증 후 적용을 해주면 1~2일정도 소요됩니다.
ACM 인증서 발급
다음으로는 ACM인증서 ( SSL 인증서 )를 발급받아주어야합니다.
구매한 도메인의 대한 보안 인증서를 발급받는 과정이라고 생각하시면 됩니다.
ACM에 접속하여 인증서 발급 요청을 눌러 도메인 값을 기재해줍니다.
발급 요청을 보내면 이렇게 검증 대기중이 나오는데 이중 검증 대기중, 아니오, 부적격이 나온다면 정상적으로 잘 된것입니다.
다음으로는 CNAME 레코드를 만들어보겠습니다.
발급 받은 인증서를 클릭하고 Route53에서 레코드 생성을 눌러줍니다.
그 후 일정 시간이 지나면 인증서의 상태가 발급됨으로 변경되는 걸 확인할 수 있습니다.
Load balancer
다음으로는 로드 벨런서를 통해 Ec2로 접근하는 요청을 리다이렉팅하여 https로 연결하는 과정을 진행해주겠습니다.
현재까지 가비아에서 도메인을 구매하고 AWS(Route53)에서 도메인 소유를 인증하고, ACM을 통하여 SSL인증서를 발급받았습니다.
이제 ec2 인스턴스의 로드 벨런싱을 위한 타겟그룹을 생성하고, 로드 벨런서로 리다이렉트 규칙 설정 및 로드 벨런서의 health check를 통해 로드 벨런싱을 안전하게 유지 해보겠습니다.
우선 로드 벨런서란 원래, 요청을 여러 서버로 분산 시키기 위해 사용하는 기술입니다.
타겟 그룹을 여러개 생성하고, 들어오는 요청들을 특정 알고리즘에 따라 각 타겟 그룹에 분산시켜주는 것입니다.
하지만 저희가 지금 구현하려는 방식을 보면,
- 타겟 그룹이 1개이며,
- https 요청 (리스너에서 캐치) -> https를 거친 후, 로드벨런싱을 통해 원래 사용하던 http포트로 요청
- http 요청 (리스너에서 캐치) -> 위의 https로 리다이렉션(리스너 규칙에 의해서)
이와 같이 되어있습니다.
우선 준비해야 할 사항입니다.
1. 네트워크는 연결할 ec2의 설정을 따라야합니다.
2. 보안그룹은 연결할 ec2의 설정을 따라야합니다.
3. 나의 웹 서버에서 사용하는 포트번호를 사용해야합니다. ( 저는 8080으로 사용하였습니다. )
또한 ec2에서의 보안그룹을 설정해주어야합니다.
우선 지금 사용하고있는 ec2의 적용된 보안그룹에 들어가 인바운드 규칙을 편집해줍니다.
이와같이 8080( 제가 사용하는 웹 서버 포트번호 입니다. ), 433 포트번호에 대해서 IPv4, IPv6를 모두 등록하고, 저장해줍니다.
( http, https 모든 요청을 열어주겠다는 의미입니다. )
다음으로는 로드 벨런싱 설정을 해보겠습니다.
우선 타겟 그룹을 설정해줍니다. ( ec2 하단에 대상그룹을 선택해줍니다. )
다켓 그룹을 생성해줍니다.
타겟 유형은 인스턴스로 설정해주고, 적당한 타겟 그룹 이름과, 포트번호를 8080으로 변경해주고, vpc를 ec2와 동일하게 설정해줍니다.
(default vpc면 그대로 default로 해주시면 됩니다. )
다음으로 상태검사 즉 health check는 인스턴스가 건강한지 확인하는 방법입니다.
( unhealthy하다면 로드 벨런서가 해당 타겟 그룹으로 요청을 보내지 않습니다. )
( 이 사항은 추후에 변경하도록 할 예정이니 default값으로 놓습니다. )
다음으로 사용할 인스턴스를 체크하고, 포트 번호 확인 후 아래에 포함시켜줍니다.
위처럼 타겟이 추가되었다면 대상그룹을 생성하여줍니다.
다음으로 로드벨런서를 생성하여줍니다.
이중 ALB를 생성하여줍니다.
그 후 적당한 이름을 설정해줍니다.
다음으로 네트워크 매핑시에 최소 2개의 가용 영역을 설정해주어야하며, ec2가 사용하는 VPC, 서브넷과 매핑되어야합니다.
( 만약 헷갈린다면 , ec2인스턴스 정보를 확인하셔서, 인스턴스의 vpc, 서브넷(가용영역)을 포함하도록 네트워크 매핑을 진행해주셔야합니다. )
저는 동일한것을 확인 하였습니다.
참고로 위해서 스키마 설정을 internet-facing으로 설정했기에, privateSubnet은 매핑할 수 없으므로, publicSubnet으로 매핑해주셔야합니다.
보안그룹은 ec2와 동일하게 지정해줍니다.
다음으로 http:8080, https:433에 대한 리스너를 생성해줍니다. ( Forward to를 위해서 생성한 타겟그룹으로 설정해줍니다. )
다음으로 저번에 생성해뒀던 인증서를 적용해줍니다.
인증서의 식별번호를 잘 보고 맞는 인증서를 적용해줘야합니다.
그 후 로드벨런서를 생성하기를 눌러줍니다.
다음으로는 A 레코드를 생성해주겠습니다.
우선 Route53으로 들어가줍니다.
다음과같이 레코드 이름은 비워두고, Loadbalancer를 설정해주고 아까 생성한 로드벨런서를 넣어주어 레코드를 생성해줍니다.
그럼 Route53에서 호스팅 영역을보면 레코드 4개가 다 생성된걸 확인할 수 있습니다.
다음으로는 로드벨런서의 리스너 규칙을 추가해주겠습니다.
위에서 생성한 로드벨런서의 정보로 들어가서 리스너 탭을 열어줍니다.
443, 8080 리스너가 존재하고, 443에는 SSL인증서도 적용이 되어있다는걸 확인할 수 있습니다.
그렇다면 각각 클릭하여 규칙들을 편집하여 주겠습니다.
443같은 경우 요청시에 위에 대상그룹으로 100퍼센트 보내겠다는 뜻으로 지정하여줍니다.
다음으로 8080은 규칙을 추가하여줍니다.
그럼 다음과같이 규칙이 추가된걸 확인할 수 있습니다.
다음으로 ec2에서 로드벨런싱에 들어가서 대상그룹에서 생성한 대상그룹을 선택합니다.
그럼 이렇게 대상 그룹의 대상이 건강한지 안건강한지 나오게됩니다.
우선 상태검사창에서 편집으로 들어가줍니다.
여기서 상태경로 검사가 / 이므로 따로 제 프로젝트에서 /경로로 get요청을 보내면 헬스 체커가 되도록 따로 healtchecker 컨트롤러를 만들어주겠습니다.
위와같이 get 요청으로 간단하게 구현하여 주었습니다.
여기 상태검사 설정 편집에 성공코드가 200이라고 설정되어있으면, 서버로부터 200이라는 요청을 받았을때 healthy하다는 것을 나타냅니다.
추가적으로 저는 지금 jwt 토큰으로 인증을 받아야하는 상황이기에
security config파일에 허용되는 url에 헬스체커 url도 같이 넣어주었습니다.
그렇게되면 허용된 url에 대해서 도메인에 잘 연결이되는것을 확인할 수 있습니다.
문제 상황
추가적으로 저는 docker cicd를 구현해놓았기에 인바운드 규칙 편집시에 ssh 22번 포트를 안열어놔줘서 터미널에서 ssh로의 접속이 끊기는 현상이 발생하였고, cicd에서 작성해둔 스크립트에서 문제가 발생하여 배포 업데이트가 되지않는 문제상황이 발생하였습니다.
따라서 ec2의 보안그룹에서 ssh에 접근할수있도록 보안그룹에 인바운드 규칙을 추가해주었습니다.
그 후 다시 터미널에서 ssh로 정상접근이 되었고, cicd액션이 제대로 돌아가는것을 확인할 수 있었습니다.
헬스체커 api도 제대로 배포된 서버에 업데이트 되어서되어서 헬시가 뜨는것을 확인할 수 있습니다.
( healthChaecker에 설정해둔 루트경로로 healthChecker가 요청을 보낼시 받는 응답코드가 해당 healthChecker의 응답코드와 일치 )
