https nginx spring s3 docker 로 배포하기

문제점

기존의 배포는 프론트의 경우 s3에 배포를 해두었고, 백의 경우 ec2 에서 도커로 컨테이너를 통해 배포중이었다. 이때 쿠키를 써야하는 상황이 나와서 프론트와 백 서버간 도메인을 통합해야하는 필요성이 생겼다. 또한 http를 쓰다보니 보안 경고창이 떠서 사용자 입장에서 신뢰하기 힘든 서비스라는 피드백이 있었다.

• 쿠키를 써야하는데 도메인이 달라서 사용 불가
• http는 보안적으로 문제가 많음

---

해결 방안

• 앞단에 nginx를 두어 도메인을 통합하기
• certbot을 사용하여 https로 변경하기

시스템 구성도

0. 도메인 빌리기

본 프로젝트 에서는 가비아에서 도메인을 빌렸다.

1. 도메인을 aws의 Route53에서 호스팅하기

aws 콘솔창에서 Route53 시작하기

도메인 이름을 그대로 적어준후 호스팅 영역생성을 클릭하면 된다.

그후 레코드가 생성되면 값/트래픽 라우팅 대상이 생성된다.
이때 가비아에서 네임서버 설정으로 들어간후 1,2,3,4차에 값을 복사하여 넣어야 한다.

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/migrate-dns-domain-in-use.html
https://velog.io/@ssssujini99/Web-AWS-Route53%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0%ED%95%98%EA%B8%B0

aws공식문서와 블로그의 도움을 받았다.

2. ec2에 nginx 설치

$ sudo apt update
$ sudo apt install nginx

nginx 설치

3. Nginx 파일 수정

# nginx.conf
http {
	server {
    	listen 80;
        
        server_name [server domain];
        
        location / {
        	proxy_pass http://127.0.0.1:8080;
        }
    }
}

nginx.conf 파일을 수정해서 domain을 연결해야 한다.

4. HTTPS 적용

Certbot 설치
Certbot 공식문서에서는 "You'll need to install snapd and make sure you follow any instructions to enable classic snap support."
즉 snap을 사용하여 설치해야 한다

sudo snap install core
sudo snap refresh core

혹시 certbot이 설치되어있으므로 제거를 한 후 진행

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

cert bot 실행

sudo certbot --nginx -d whokie.com

무료 ssl/tls 인증서 발급
certbot으로 진행하게 되면, 무료 SSL/TLS 인증서 발급과 관련된 Let's Encrypt를 사용하게 된다. 이 무료의 단점은 90일마다 재발급을 진행해야 한다는 것인데, certbot은 이를 지원하고 있다. 이를 확인하기 위해서는 아래의 두 명령어를 통해서 확인해볼 수 있다.

sudo certbot renew --dry-run
systemctl list-timers

conf파일 변경 확인

certbot이 알아서 conf파일을 변경해 준다

5.프론트와 연결하기

처음에는 nginx에 프론트의 정적파일을 직접 서버에서 내려줄 생각이었다. 그렇게 하려면 프론트 측에 ec2 키와 ec2에 직접 배포 자동화를 진행해야하는데 번거로운 점이 많았다. 이미 s3에 배포를 해둔 상황이었기 때문에 최대한 변경 가능성을 낮추기 위해 고민한결과 nginx가 직접 s3에서 프론트 파일을 가져와 내려주는 방식을 사용하였다.

location / {
	proxy_pass {프론트 주소}
    }

6.도메인 통합

이제 https://whokie.com을 연결하면 nginx를 통해 s3에서 데이터를 불러온다. 클라이언트 입장에서는 앞단의 proxy 서버에게서 받아온다고 생각하고 그 후는 알수 가 없어진다. 서버의 경우

location /api/ {
	proxy_pass {백 주소}
    }

whokie.com/api/~ 는 백 서버에게 포워딩을 하게 구현하므로서 백과 프론트의 도메인을 통합해 주었다. 이를 통해 cors를 따로 열어둘 필요가 없게 되었다.

7.기대 효과

1. 쿠키 사용 - 도메인를 통합 함으로서 쿠키를 사용할 수 있게 되었다.
2. s3에게서 리소스 받아오기 - 프론트의 배포와 백의 배포를 독립시킴으로서 프론트에게 ec2 키나 다른 작업을 따로 하게 하지 않아도 도메인을 통합 시킬 수 있었다.
3. 리버스 프록시 - 클라이언트가 api를 사용할 때 서버의 직접 요청하는 것이 아닌 앞단의 nginx에게 요청하게 하므로서 클라이언트에게 서버의 위치를 숨길 수 있게 되었다.
4. cors - 도메인을 통합하였기 때문에 cors를 열어두지 않아도 요청을 받을 수 있게 되었다.

8. 후회

1. nginx 서버와 실제 백엔드 배포 서버를 다르게 구현하고 보안그룹으로 설정했어야 했는데, 생각을 못했다.
2. nginx 또한 docker 컨테이너로 배포하고 관리하면 더 편했을 것 같다.