글 쓰는 시간

HTTPS 사용하기

로컬에서는 HTTP 요청으로도 테스트 할만하지만 배포 환경에서 HTTP 만으로는 제한되는 부분이 조금 있다.

특히 쿠키를 사용할 때 크롬 정책으로 인해 쿠키 확인이 너무나도 힘들다.

프론트와 백엔드가 같은 도메인인 경우에는 Strict 쿠키 정책으로 어떻게 HTTP로도 가능하겠지만,

다른 도메인이라면 방법이 없다.

그래서 인증서를 발급받고 SSL을 적용해서 HTTPS 요청을 사용하여 Secure 쿠키 정책을 사용해야 한다.

HTTPS는 인증서, 암호화 이런 단어가 들어있어서 어려울것 같지만 생각보다 간단하고 빠르게 할 수 있다.

사용 기술

• EC2
• Nginx
• certbot

1. SSL 적용

SSL을 적용하기 위해서는 인증서가 필요하다.

전에는 Route53에서 매월 0.5달러인가 주고 했지만 이번에는 certbot으로 무료로 해보려고 한다.

certbot의 공식 문서 를 참고하면 아래와 같은 과정을 거친다.

사실상 그대로 가져왔으니 공식 문서만 봐도 충분히 따라할 수 있다.

# 1. certbot을 snap 명령어로 설치 및 실행하므로 snap을 먼저 설치한다
sudo snap install core
sudo snap refresh core

# 2. 기존에 설치된 certbot을 제거한다
# 공식 가이드에선 certbot명령어를 사용할 때 snap이 사용되게 하기 위함이라고 되어있다.
sudo apt-get remove certbot

# 3. certbot을 설치한다
sudo snap install --classic certbot

# 4. certbot 명령어가 실행될 수 있게 세팅한다
sudo ln -s /snap/bin/certbot /usr/bin/certbot

# 5. 아래 명령어를 입력하면 certbot이 nginx 구성을 자동으로 수정한다.
# nginx가 아닌 apache를 웹서버로 사용할 경우, sudo certbot --apache 가 된다
sudo certbot --nginx -d midcon.store -d www.midcon.store

# certbot은 CLI몇 줄로 SSL을 적용해줄 뿐 아니라 자동 리뉴얼까지 해준다
# 처음 설치할 때부터 이러한 cron job 처리를 위한 내용을 site-available/default 에 자동으로 설정해준다
# 아래 명령어로 자동 리뉴얼이 적용되고 있는지 확인할 수 있다
sudo certbot renew --dry-run

5번 커맨드를 입력하면 아래처럼 이메일, 약관 동의 여부 등등을 입력하는 부분이 있다.

당황하지말고 적당히 읽어보고 입력하면 된다.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): hyukkind@naver.com   # 이메일 입력

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf. You must agree in
order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y  # ACME 약관에 동의하는지 N선택시 진행불가

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y   # 이메일을 통해 Let's Encrypt 프로젝트 정보를 받아볼지
Account registered.
Requesting a certificate for midcon.store and www.midcon.store

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/midcon.store/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/midcon.store/privkey.pem
This certificate expires on 2024-08-15.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for midcon.store to /etc/nginx/sites-enabled/default
Successfully deployed certificate for www.midcon.store to /etc/nginx/sites-enabled/default
Congratulations! You have successfully enabled HTTPS on https://midcon.store and https://www.midcon.store

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

2. 결과 확인

2-1. /etc/nginx/sites-available/default 확인

아래 사진은 /etc/nginx/sites-available/default 로 들어가본 결과이다.

localtion /ws 부분은 본인이 웹소켓 설정하느라 추가한 부분이고 아래 부분부터 보면 되는데

아래처럼 certbot이 nginx 설정까지 자동으로 변경한 알 수 있다.

HTTP로 요청하면 HTTPS로 리다이렉트 시키는 설정도 certbot이 자동으로 해두었다.

2-2. HTTP/HTTPS 요청 시

이제 HTTP 로 요청하면 자동으로 HTTPS 로 리다이렉트 되고, HTTPS 요청도 잘 되는걸 확인할 수 있다.

3. 추가

만약 인증서를 삭제하고 싶다면 아래 명령어를 입력하면 된다.

sudo certbot delete

그럼 아래와 같은 창을 확인할 수 있고, 여기서 삭제하고 싶은 인증서의 번호를 입력하면 된다.

아쉽지만 nginx 설정까지는 자동으로 삭제해주지는 않는것 같다.

인증서 삭제 후 nginx 변경 부분은 수동으로 삭제하자.

참고자료

도메인 적용

EC2에 애플리케이션 서비스를 배포까지는 했다.

하지만 아직 도메인을 적용하지 않아서 불편하게 퍼블릭 IP를 입력해서 접속해야한다.

이번 글에서는 이름을 가진 도메인을 붙여볼것이다.

Nginx를 리버스 프록시로 사용하여 도메인으로 들어온 요청을 EC2 8080 포트로 포워딩 해보자.

사용 기술

• EC2
• Nginx

1. 도메인 확보

우선 도메인을 붙이려면 도메인을 어떻게든 마련해야 한다.

인터넷에 검색해보면 무료로 구할 수 있는 사이트도 있고, 가비아 같은 호스팅 사이트도 많다.

본인은 가비아에서 1년에 500원짜리 도메인을 샀다.

마이 페이지에서 아래의 도메인 란을 누르면 내 도메인을 확인할 수 있다.

2. DNS 레코드 수정

이제 도메인의 DNS 레코드를 설정해서 구매한 도메인으로 접속 시 EC2 서버로 포워딩 해줄것이다.

2-1. 내 도메인의 관리 창으로 이동

2-2. DNS 정보 란의 도메인 연결 설정 창으로 이동

내 도메인 관리 창에서 아래로 내려보면 DNS 정보 란이 보일것이다.

여기서 설정을 누르면 DNS 관리페이지로 넘어간다.

2-3. DNS 관리 페이지에서 DNS 설정

DNS 설정 버튼을 눌러서 DNS 레코드 설정을 해준다.

아래처럼 추가해준다.

호스트는 www, @ 를 넣어준다.

www로 넣으면 www.midcon.store 를 등록하는것이고 @로 넣으면 midcon.store 를 등록함을 의미한다.

값/위치에 해당하는것은 본인의 EC2 인스턴스의 퍼블릭 IP이다.

3. EC2 인스턴스의 인바운드 규칙 설정

우리는 HTTP 혹은 HTTPS 요청으로도메인명/경로 와 같은 형태로 요청을 받을 것이다.

따라서 HTTP 와 HTTPS에 해당하는 포트 번호를 인바운드 규칙 설정 해줘야한다.

보안그룹으로 이동해서 아래처럼 HTTP, HTTPS에 해당하는 80, 443 포트를 열어준다.

4. Nginx 설정

4-1. Nginx 설치

우선은 EC2에서 Nginx를 설치한다.

Ubuntu 환경의 경우 아래의 명령어를 입력하여 설치한다.

sudo apt-get install nginx -y   // Nginx 설치

Nginx가 제대로 설치 되었다면 EC2의 퍼블릭 IP 주소로 접속하면 아래와 같은 화면이 뜰것이다.

4-2. Nginx 설정

HTTP 요청의 기본 포트값은 80이므로 도메인 명:8080 이 아닌 도메인 명 만 입력했을 때 80번 포트로 요청이 들어온다.

따라서 이러한 80번 포트의 요청을 원래 EC2 인스턴스의 8080 포트로 연결시켜야 한다.

이것을 Nginx를 이용해서 해볼 것이다.

Nginx의 기본 설정 값은 /etc/nginx/sites-available/default 파일에 설정돼 있다.

이 파일을 수정하여 원하는 설정으로 바꿀것이다.

리눅스 커맨드를 좀 알면 알아서 하겠지만 모른다면 아래 명령어를 입력하면 된다.

sudo vim /etc/nginx/sites-available/default    // 관리자 권한으로 vim으로 뒤 경로 파일 실행

위 파일에 들어가면 대략 아래와 같은 창이 뜬다.

그럼 i를 눌러서 수정모드로 위 기본 서버 설정 아래에 아래처럼 입력해준다.

아래 설정이 위에서 설명한 80번 포트를 8080번 포트로 연결시켜주는 설정이다.

저장은 Ctrl + c 이후 :wq 입력 후 엔터를 누르면 된다.

# server_name 에 적힌 도메인으로 "/" 이하 경로로 접근 시(사실상 모든 경로) 8080포트로 위임 
server {
    listen 80;
    server_name midcon.store www.midcon.store;

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

설정을 변경할 때마다 아래 명령어로 Nginx를 재시작 해줘야 한다.

sudo service nginx restart

5. 결과 확인

아래처럼 도메인으로 접속해도 8080포트로 접속하는것처럼 잘 접속 된다.

참고자료

IAM

IAM은  AWS 리소스에 대한 액세스를 안전하게 제어하게 해주는 웹 서비스이다. 

이 서비스를 이용하여 AWS 서비스에 접근할 수 있는 권한을 설정할 수 있다.

1. IAM 사용자 생성

Github Actions나 우리의 스프링부트 애플리케이션 같이 외부에서 AWS 서비스에 접근하기 위해서는 

해당 서비스에 대한 권한을 가진 사용자의 accessKey와 secretKey가 필요하다.

Github Actions에서 필요한 서비스는 S3, CodeDeploy이므로 이 두 서비스에 대한 권한을 가진 사용자를 만든다.

1-1. 사용자 생성 페이지로 이동

1-2. 사용자 이름 설정

1-3. 사용자 권한 설정

위에서도 설명했듯 Github Actions에서 AWS 서비스를 이용하기 위해서는 S3, Code Deploy에 대한 권한이 필요하다.

따라서 권한 정책에서 아래 두개를 선택하고 사용자 생성을 완료한다.

• AmazonS3FullAccess
• AWSCodeDeployFullAccess

1-4. 사용자 생성 확인

2. IAM 사용자 액세스 키 생성

2-1. 액세스 키 생성

2-2. 액세스 키 사용 사례 선택

2-3. 액세스 키 생성 및 확인

액세스 키를 생성 완료하면 아래와 같은 창을 확인할 수 있다.

시크릿 키 는 생성 시에만 확인할 수 있으므로 따로 저장해두고 분실 시 재발급해야 한다.

보안 그룹 설정

이전 글에서 RDS 인스턴스를 생성했다.

RDS 인스턴스를 생성할 때 default와 EC2의 보안 그룹을 추가해주었다.

그래서 현재  EC2에서 접근은 가능하지만 외부에서 접근하려면 추가로 설정해줘야한다.

이 글에서는 생성할 때 추가해둔 default 보안 그룹을 수정해서 로컬에서 접근할 수 있도록 할 것이다.

1. default 보안 그룹 수정

1-1. RDS 인스턴스로 이동

생성된 RDS 인스턴스를 눌러서 인스턴스 정보를 확인하면 아래와 같이 정보를 확인할 수 있다.

1-2. default 보안 그룹 수정 페이지으로 이동

인스턴스 정보 창에서 아래로 쭉 내려오면 보안 그룹 규칙을 확인할 수 있다.

여기서 default 보안 그룹을 눌러서 이동한다.

default 보안 그룹을 클릭해서 이동하면 아래처럼 확인할 수 있다.

보안 그룹 ID를 눌러서 수정 페이지로 이동하자.

1-3. 보안 그룹 수정

로컬에서 RDS에 접근할 수 있게 인바운드 규칙에 아래처럼 내 IP를 추가한다.

1-4. 보안 그룹 수정 확인

아래처럼 새로 추가한 규칙을 확인할 수 있다.

2. 로컬에서 RDS 접근

로컬에서 인텔리제이나 DBeaver 등으로 RDS에 접근한다.

본인은 DBeaver를 이용할 것이다.

2-1. DBeaver로 새 데이터베이스 연결

2-2. RDS 접근을 위한 DB 정보 입력

DBeaver를 사용하면 아래와 같은 창을 확인할 수 있다.

다른 어떤 DB 접근 GUI를 쓰더라도 아래와 구조는 같을것이다.

이제 엔드포인트, 포트번호, DB 이름, 사용자 이름, 비밀번호를 입력하면 된다.

이후 Test Connection으로 연결이 잘 되는지 확인하면 끝.

엔드포인트와 포트번호는 RDS 연결 및 보안 탭에서 확인할 수 있다.

DB 이름과 마스터 사용자 이름은 RDS 구성 탭에서 확인할 수 있다.

3. 로컬에서 RDS 접근 확인

Test Connection에 성공하면 아래와 같은 창을 확인할 수 있다.

RDS

지금까지 EC2 인스턴스를 생성하고 이 인스턴스에서 서비스를 배포까지 하였다.

DB는 어떤 서비스든 필요할테니 이제 애플리케이션과 DB를 연동해야 한다.

스프링 서버와 동일한 EC2 인스턴스에서 인메모리로 데이터를 저장할 수도 있지만

이 경우 하나의 EC2 인스턴스가 죽을 경우 DB 데이터 또한 사라진다.

결국 여러 경우를 생각하면 DB는 따로 서버를 둬야한다는 결론이 나온다.

여기서 간단하게 생각하면 두 가지 선택지가 생긴다.

• DB를 띄운 EC2 인스턴스를 DB 서버로 이용한다.
• AWS RDS를 이용한다.

두 가지를 비교하자면 비용적인 측면에서는 EC2 인스턴스가 더 저렴하다.

반면 AWS RDS에서는 기본적인 설정은 AWS에서 마친 상태의 DB 서버를 제공해주므로 직접 설정해야하는 DB 설정이 많이 줄어든다.

매니지드(RDS) vs 언매니지드(EC2) 라고 할 수 있다.

프리티어로 RDS도 제공하므로 우선 RDS를 사용하고 추후 DB 설정 공부를 하고 EC2로 직접 DB 서버를 띄워보기로 했다.

1. RDS 인스턴스 생성

1-1. RDS 인스턴스 생성 페이지로 이동

1-2. DB 종류 선택

원하는 종류의 DB를 선택하면 된다.

본인은 써본게 이것 뿐이라 MySQL 8 버전을 선택하겠다.

1-3. 템플릿 선택

프리 티어를 선택하면 가용성 및 내구성은 설정할 수 없다.

1-4. DB 정보 설정

DB 이름, 마스터 이름, 비밀번호를 설정한다.

추후 애플리케이션이나 DBeaver에서 DB에 접근할 때 여기서 입력한 정보로 접속한다.

1-5. 인스턴스 구성 및 스토리지 설정

프리티어를 사용하므로 선택지는 거의 없다.

과금 가능성이 있는 설정만 주의하자.

1-6. 보안 그룹 설정 

EC2 컴퓨팅 리소스에 연결 안 함, 퍼블릭 액세스

로컬에서 DBeaver나 인텔리제이 등에서 MySQL로 DB를 직접 확인해보기 위해 퍼블릭 액세스를 열어두려 한다.

따라서 EC2 컴퓨팅 리소스에 연결 안 함, 퍼블릭 액세스를 허용하겠다.

VPC 보안 그룹

해당 보안 그룹을 통해 들어온 요청만 3306 포트로 받아주겠다는 의미다.

기존 항목을 선택해 내가 만든 EC2 인스턴스의 보안 그룹(여기서는 launch-wizard-1)을 선택하면 EC2 인스턴스의 요청을 받는다.

로컬에서도 DB에 접근하기 위해서는 default 보안 그룹을 추가하고 이 보안 그룹을 조금 수정할 것이다.

1-7. 추가 구성

그림에서 생략된 부분은 기본 설정을 따라가면 된다고 생각해서 굳이 추가하지 않았다.

2. RDS 인스턴스 생성 확인

위와 같이 설정하고 데이터베이스 생성을 하면 아래처럼 생성된 RDS 인스턴스를 확인할 수 있다.

인스턴스 생성까지 시간이 좀 걸린다.

RDS 인스턴스를 다시 만들어서 위 설정과는 DB 식별자가 조금 다를테지만 신경쓰지 않아도 된다.

참고 자료

보안그룹

보안 그룹은 AWS 에서 제공하는 방화벽 모음이다.
서비스를 제공하는 애플리케이션이라면 상관 없지도 모르지만,

RDS나 S3처럼 외부에서 함부로 접근하면 안되는 인스턴스는 허용된 IP 에서만 접근하도록 설정해야한다.

• 인바운드 (Inbound): 외부 -> EC2 인스턴스 내부 허용
• 아웃바운드 (Outbound): EC2 인스턴스 내부 -> 외부 허용

1. EC2 인스턴스의 보안 그룹 설정

1-1. 인스턴스에 적용된 보안 그룹 확인

인스턴스의 보안 탭으로 이동하면 현재 인스턴스에 적용된 보안 그룹을 확인할 수 있다.

인스턴스를 생성할 때 설정했던 SSH 트래픽 허용 설정도 보인다.

이제 이 보안 그룹의 인바운드/아웃바운드 설정을 편집할것이다.

1-2. 사이드 바에서 보안 그룹으로 이동 후 편집 창으로 이동

1-3. 원하는 인바운드 규칙으로 편집

인바운드 규칙은 위에서 설명했듯 외부에서 EC2 인스턴스로의 접근을 관리한다.

우선 로컬에서 SSH로 접근하는것과 8080 포트로 오는 요청만 허용한다.

필요 시 다른 포트도 추가하면 된다.

아웃바운드 규칙은 딱히 건들 필요 없으니 모든 IP에 대해 열어두는 기본 설정을 유지한다.

1-4. 인스턴스로 이동해서 인바운드 규칙 변경 확인

EC2 인스턴스 정보에서 보안 규칙이 잘 변경 됐는지 확인한다.

2. 보안 그룹 설정 변경 후 EC2의 스프링 부트 서버 접속

변경된 보안 규칙이 적용되는데 시간이 조금 걸릴 수 있으니 조금 기다렸다가 접속한다.

다시 요청을 하면 아래처럼 서버가 제대로 떠있고, 접속할 수 있음을 확인할 수 있다.

(본인은 스프링 부트 서버를 8082 포트로 열어서 인바운드 규칙을 8082로 바꿨다.)

EC2 인스턴스에 Spring Boot 서버 띄우기

저번 글에서 EC2로 jar 파일을 이동시켰다.

이제 이 jar 파일로 서버를 띄우기만 하면 된다.

하지만 EC2는 아직 생성한 상태 그대로이기 때문에 자바가 설치되어있지 않기 때문에 설치해야한다.

1. EC2 인스턴스에 JDK 설치

1-1. OS에 맞는 패키지 관리자로 JDK 설치

OS마다 패키지 관리자가 다르기 때문에 OS에 맞는 패키지 관리자로 JDK를 설치하면 된다.

본인은 ubuntu로 OS를 설정했기 때문에 apt를 사용한다.

설치는 되게 간단하게 아래 두 줄이면 JDK를 바로 설치할 수 있다.

// EC2 인스턴스에서
sudo apt-get update
sudo apt-get install openjdk-17-jdk

// apt나 apt-get이나 큰 차이는 없어서 뭘 쓰든 상관없다.

1-2. 자바 버전 확인

아래처럼 java -version 명령어로 자바 버전을 확인해서 확인 가능하면 설치가 잘 된것이다.

2. EC2에서 스프링 부트 서버 띄우기

jar 파일이 있는 경로에서

아래처럼 명령어를 입력하면 jar 파일로 스프링부트 서버를 띄울 수 있다.

또한 종료는 ctrl + C로 스프링 부트 서버를 종료시킬 수 있다.(종료까지 시간이 좀 걸릴 수 있음)

java -jar {jar파일 이름} &   

// 위에서 &는 안붙여도 되지만 &를 붙이면 백그라운드에서 실행 시켜서 다른 작업 가능

3. EC2에서 띄운 스프링 부트 서버에 접속

이제 http://{탄력적 IP}:8080 으로 접속하면 아래와 같은 창을 확인할 수 있다.

(실패하는게 당연함)

4. 실패한 이유

다른 설정을 하지 않고 이대로 접속하면 접속이 차단되는것은 정상적인 응답이다.

인스턴스의 보안 그룹 설정을 하지 않았기 때문에 기본 설정이 외부에서 오는 차단을 막기 때문이다.

따라서 다음 글에서 처럼 인바운드/아웃바운드 보안 그룹 설정을 하도록 한다.

scp(secure copy)

scp는 로컬 호스트와 원격 호스트 또는 두 개의 호스트 간에 파일을 전송하는 수단이다. 

SSH(Secure Shell)을 통한 파일 전송 방식이며 별도의 FTP 클라이언트를 설치하지 않아도 파일 송수신이 가능하다.

파일 전송을 하기 위해 비슷한걸로 rsync라는 것도 있다고 한다.

여기서는 scp를 통해 로컬에서 빌드한 jar 파일을 EC2 인스턴스로 전송해보도록 한다.

1. 스프링 빌드 파일 생성

1-1. 스프링 프로젝트 경로로 이동해서 빌드 파일 생성

본인은 빌드하다가 자바 버전 문제 때문에 이런 오류를 만나서 고생했다.

사용하는 CLI에 따라 명령어가 다를테지만 윈도우/Git Bash 기준으로는 아래처럼 한다.

1-2. 빌드 된 jar 파일 확인

사용 환경에 따라 맞는 방식으로 빌드를 하고 build/libs 폴더로 가면 

아래처럼 두가지의 jar 파일을 확인할 수 있다.

여기서 두 jar 파일을 간단히 설명하자면 아래와 같다.

• 위의 용량이 적은 plain이 붙은 jar 파일은 라이브러리 없이 순수한 jar 파일
• 아래의 용량이 큰 jar 파일은 라이브러리를 포함한 jar 파일

이 중 우리가 사용할건 아래의 jar 파일이다.

2. scp로 로컬 -> EC2로 파일 전송

2-1. 파일 전송 확인을 위해 EC2 접속

로컬과 EC2 두가지 상태를 동시에 비교하기 위해 CLI 창을 아래처럼 두개 이용한다.

2-2. scp를 이용해 파일 전송

scp는 ssh와 입력 파라미터가 비슷한데, 아래와 같은 양식으로 작성한다.

작성 코드 길이를 줄이기 위해 EC2 접속 방법 중 EC2 경로를 연결한 탄력적 IP 주소를 입력하는 방식을 선택했다.

scp -i {키 페어 파일 경로} {전송할 파일 경로} {전송받을 위치 경로}

전송받을 경로는 EC2에서 아래처럼 리눅스 명령어 pwd로 확인할 수 있다.

3. EC2에서 전송받은 파일 확인

로컬에서 EC2로 scp를 통해 파일을 전송하고 EC2에서 확인해보면 아래처럼 파일이 전송된걸 확인할 수 있다.

참고로 로컬 -> EC2로 파일 전송도 가능하지만, EC2 -> 로컬로도 파일 전송이 가능하다.

아래처럼 작성하면 EC2에서 로컬로 파일 전송을 할 수 있다.