- TIL. drf팀프로젝트(8) AWS 배포 목차
[오늘 한일]
- 프로젝트 마무리. 제출
- 발표회
[오늘 배운점]
<AWS 배포>
제출 하루 전날, 오후부터 밤까지.
팀원분들과 노력끝에 프로젝트 배포에 성공했다.
팀원분 계정으로 배포를 완성했다.
나도 함께 내 AWS계정으로 배포를 시도하며 문제와 시행착오를 함께 해결했었다.
프로젝트가 끝나고 혼자서 내 계정도 배포에 성공시켰다.
배포는 모두 AWS를 이용했다.
백엔드 배포는 EC2로
프론트 배포는 S3을 사용했다.
ROUTE53으로 도메인을 구매해서 동작시켰고,
ACL로 SSL인증서도 받고,
ELB와 CloudFront로 요청과 서버를 연결했다.
배포에 꼭 필요했던 단계들을 쭉 나열해보겠다.
- EC2 인스턴스 생성. 프로젝트 폴더 클론.
※ 여기까지 하면 런서버 후 IP로 접속이 가능하다.
- gunicorn, nginx설치 및 기본 세팅.
- 장고에 allowed host, nginx설정에 server에 인스턴스 IP추가.
※ 여기까지 하면 인스턴스 IP(HTTP)로 접속 가능하다.
nginx화면과 장고화면이 나오는지 체크한다.
브라우저로 http를 체크하면 개발자도구 콘솔에 cors에러가 나온다. (에러는 나지만 값은 불러온다)
404에러가 나온다면 nginx설정을 한번 체크해본다.
nginx화면은 잘 나오나 장고화면이 나오지 않는다면(Bad request) 장고 setting을 체크한다.
설정을 바꾸다보면 예기치않게 400에러를 만날수 있다.
이경우 gunicorn과 nginx를 차례로 restart해준다.
- 프론트 배포.
S3을 이용한다. 우선 프론트 주소로 프론트 화면을 확인한다.
이번 프로젝트를 하면서 프론트를 http로 동작시킬수 없었다.
정적 웹 호스팅을 지원하는 사이트들이 보안상 http를 열어주지 않게 강화되고 있는 것같다.
https로 완성된 프론트에서는 백엔드(http)로 제대로 통신할수 없다.
mixed content 에러가 나오는데, 웹은 https고 백엔드에 요청은 http로 해서 그렇다.
백엔드 서버를 필시 https로 완성해야한다.
- ROUTE53에서 도메인 사기
- ACL에서 SSL인증서 받기
- ELB 로드밸런서 연결.
로드 밸런서를 연결하면 https로 요청받게 할수 있다.
요청을 로드밸런서가 https로 받고 로드밸런서↔서버 간 통신은 http로 하게된다.
로드밸런서를 http로 우선 생성하고 연결을 확인한다.
로드밸런서에 https 리스너를 추가하려면 ssl 인증서가 필요하다.
ssl 인증서를 받기 위해선 도메인이 필요하다. (도메인에 부여되는 거니 당연하다)
로드밸런서 연결까지하면 https(로드밸런서 접근주소)로 장고 동작을 볼수있다.
- ROUTE53에서 도메인->접속 주소 설정하기
Route53에 설정한 호스팅 주소로 백엔드 접속이 가능해진다.
- Cloudfront 생성하여 S3 버킷과 연결하기
Cloudfront에 CNname을 설정하면 그 주소를 통해 프론트 접속이 가능하다.
프론트 준비가 다됬다면,
- 장고 setting에 allowed host와 nginx에 server에 프론트 주소를 추가해준다.
- 프론트 api에서 동작하는 백엔드, 프론트 주소를 변경해준다. (전역변수로 되어있으면 바꾸기 편하다)
여기까지 하면 배포 완료다.
결론, 모든 파트를 AWS로 사용하면 편리하다.
위에서 한 과정들은 다 강의에서 배운 부분들이다.
다만 예기치 않은 상황들을 만나면서 시행착오를 많이 겪게 되었다.
처음 http로 서버 올리고 cors오류 > 로드밸런서를 사용하면서 해결되었다.
mixed content 오류 > http, https혼합으로 완성할 방법은 없다. 프론트를 http로 맞출수도 없다. https로 가야한다.
다 연결한 후에 404에러 > nginx와 장고에 프론트 도메인을 추가해줘야한다.
이렇게가 이번 배포의 핵심이였던것 같다.
프로젝트를 통해, 배포까지 마스터해서 좋다.
DB분리라던지 인스턴스 다중화도 다음번에 도전해보면 좋을것 같다.