글 쓰는 시간

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포트로 접속하는것처럼 잘 접속 된다.

참고자료

타임존

EC2 인스턴스의 기본 타임존 설정은 UTC로 되어있다.

따라서 비즈니스 로직에서 생성 시간이나 수정 시간 등을 기록하는게 중요하다면 타임존 설정을 해야한다.

리눅스를 공부했다면 간단할 수도 있겠지만 아직 리눅스가 미숙해서 그런지 매번 헷갈리니까 기록해둬야겠다.

이번 글에서는 EC2 인스턴스의 타임존을 Asia/Seoul로 변경하는 방법과 타임존 확인 방법을 정리해두려 한다.

본인의 EC2 OS인 Ubuntu 기준으로 정리한다.

타임존 설정

sudo timedatectl set-timezone Asia/Seoul

타임존 확인

timedatectl

위 명령어로 Asia/Seoul 로 타임존을 설정하고 확인해보았다.

Swap Memory

스왑 메모리는 쉽게 말해서 RAM이 아닌 Disk 공간을 RAM 처럼 활용하는 것이다.

실제 메모리(RAM) 즉, 물리 메모리가 가득 차면 프로세스는 더 이상 이어가지 못하고 종료된다.

이 때, 스왑 메모리를 할당하면 Disk 공간으로 부족한 RAM을 충당할 수 있다.

스왑 메모리는 디스크 I/O 성능에 의존하므로 물리적 메모리보다 느리다는 단점이 있지만 프리티어에서는 굉장히 유용하다.

스왑 메모리 설정

토이 프로젝트용으로는 주로 AWS EC2 혹은 Azure, GCP 등의 프리티어 인스턴스를 사용한다.

그런데 이런 프리티어 인스턴스는 성능이 몹시 딸린다.

예시로 EC2 프리티어 인스턴스는 RAM이 1GB 밖에 안되기 때문에 스프링부트 애플리케이션을 두개만 띄워도 힘들어한다.

이를 조금이라도 보완하기 위한 스왑 메모리 를 설정해보자.

1. 스왑 파일 생성

주로 기존 메모리의 2~4배 정도를 스왑 메모리로 설정한다고 한다.

그러므로 2GB 정도를 스왑 메모리로 설정하겠다.

sudo fallocate -l 2G /swapfile

2. 스왑 파일 권한 설정

sudo chmod 600 /swapfile

3. 스왑 파일 권한 설정

sudo mkswap /swapfile

4. 스왑 파일 활성화

sudo swapon /swapfile

5. 스왑 파일이 시스템 재부팅 후에도 유지되도록 설정

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

6. 스왑 메모리 설정 확인

sudo swapon --show

위 명령어를 입력하면 어래처럼 스왑 메모리 설정을 확인할 수 있다.

보안그룹

보안 그룹은 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에서 로컬로 파일 전송을 할 수 있다.

SSH(Secure Shell Protocol)

SSH란 네트워크 프로토콜 중 하나이다.

컴퓨터와 컴퓨터가 인터넷과 같은 Public Network를 통해 서로 통신을 할 때  보안적으로 안전하게 통신을 하기 위해 사용한다.

대표적인 사용의 예는 다음과 같다.

• 원격 제어
• 데이터 전송

SSH를 통해 내 컴퓨터(로컬)에서 EC2 인스턴스로 접속해볼것이다.

그러면 로컬에서 EC2로 접속해서 인스턴스를 이리저리 건드려볼 수 있다.

이후 데이터 전송까지 진행해서 EC2 인스턴스에 스프링 부트 애플리케이션을 띄워볼것이다.

1. SSH로 EC2 인스턴스에 접속

1-1. 인스턴스로 이동해서 연결 버튼 클릭

1-2. 인스턴스 연결 방법 확인

AWS에서 EC2 인스턴스에 연결하는 방법을 너무 친절히 잘 알려줘서 적혀있는걸 따라만 해도 된다.

아래부터는 순전히 여기 적혀있는걸 따라하는 과정이다.

1-3. CLI(Git Bash)로 키 페어 위치로 이동

위 사진은 이전 EC2 인스턴스를 생성할 때 생성했던 키 페어 사진이다.

이제부터 EC2 인스턴스에 접근할 때 이때 만들었던 키 페어가 필요하다.

기본적으로 download 폴더에 있을 것이다.

본인은 이걸 바탕화면으로 옮겼기 때문에 desktop 경로로 이동했다.

1-4. 키 페어 권한 변경

chomd 커맨드로 키 페어의 권한을 변경해준다.

1-5. EC2 인스턴스 접속

이제 키 페어로 EC2 인스턴스로 이동하려면 아래와 같은 양식으로 입력하면 된다.

유저 이름은 OS마다 조금씩 다른데, 본인은 OS를 ubuntu로 했기 때문에 유저 이름은 ubuntu이다.

ssh -i {키 페어 파일 이름} {유저이름}@{EC2 인스턴스 주소}

혹은 아래 처럼 연결해둔 탄력적 IP나 public IP 주소로 접근도 가능하다.

(my-key.pem를 감싸는 " "는 생략 가능)

2. EC2 인스턴스 접속 확인

첫 접속때는 위와 같은 라인이 뜰 수도 있는데, yes를 입력하면 된다.

입력 커서가 가리키는 부분이 빨간 표시 영역처럼 바뀌면 접속에 성공한것.

참고로 EC2 인스턴스 접속을 끝내고 싶다면 ctrl + D 를 누르면 된다.

참고자료