글 쓰는 시간

AWS S3

자동화 된 배포를 위해서는 배포 파일을 저장할 수 있는 저장소가 필요한데, 이 저장소를 S3로 선택했다.

이전 글에서 이미지 저장소를 만들 때도 썼던 그 S3인데, CI/CD 용 버킷을 새로 만들어서 사용한다.

S3를 선택한 이유는 자동 배포를 위해 AWS CodeDeploy를 사용할 예정이라 같은 AWS 서비스라서 연동하기 편하기 때문이다.

1. EC2에 적용할 IAM 역할 설정

CI/CD 과정에서 EC2 인스턴스에서 실행 중인 CodeDeploy를 통해 S3 버킷의 배포용 파일들에 접근한다.

따라서 EC2의 IAM 역할을 설정해줘야 문제 없이 동작한다.

1-1. IAM 역할 생성 페이지로 이동

1-2. 신뢰할 수 있는 엔티티 선택

1-3. 권한 추가

1-4. 역할 이름 지정

역할 이름 지정 후 생성을 완료한다.

1-5. EC2 인스턴스에 IAM 역할 연결

EC2 인스턴스로 이동해서 IAM을 연결한다.

2. S3 버킷 생성

CI/CD 용으로 버킷을 새로 만들것이다.

깃헙 액션에서 IAM 사용자 정보로 이 S3 버킷에 저장한다.

따라서 퍼블릭 엑세스가 필요 없으므로 최대한 private 하게 생성한다.

2-1. S3 버킷 생성 페이지로 이동

2-2. 버킷 만들기

아래처럼 리전과 이름만 설정하면 나머지는 기본값으로 생성하면 된다.

2-3. 버킷 생성 확인

CodeDeploy

CodeDeploy는 EC2, ECS 등의 서비스로의 애플리케이션 배포를 자동화하 해주는 배포 서비스이다.

S3에 저장된 배포 파일들을 이 CodeDeploy가 자동으로 배포하도록 설정할 수 있다.

1. CodeDeploy에 적용할 IAM 역할 설정

CodeDeploy 애플리케이션을 생성하고 이를 이용해 EC2에 배포할 것이다.

이 때, CodeDeploy가 EC2에 접근하여 배포 과정을 실행하기 위해 IAM 역할을 설정해줘야 한다.

1-1. IAM 역할 생성 페이지로 이동

1-2. 신뢰할 수 있는 엔티티 선택

CodeDeploy로 선택해주면 권한은 자동으로 추가되므로 이후는 기본값으로 설정한다.

1-3. 역할 이름 지정

역할 이름 지정 후 생성을 완료한다.

2. CodeDeploy 애플리케이션 생성

2-1. 애플리케이션 생성 페이지로 이동

2-2. 애플리케이션 생성

아래 사진처럼 앱 이름과 컴퓨팅 플랫폼을 설정해준다.

컴퓨팅 플랫폼은 EC2/온프레미스로 선택하고 애플리케이션을 생성한다.

3. CodeDeploy 배포 그룹 설정

3-1. 배포 그룹 생성 페이지로 이동

3-2. 배포 그룹 설정

배포 그룹 설정을 해준다.

역할은 위 1 에서 생성한 역할을 선택해준다.

3-3. 환경 구성

3-2에서 아래로 내려오면 환경 구성이 나온다.

EC2 인스턴스를 선택하고, 태그 그룹을 선택해준다.

이 글에서 생성한대로 EC2를 생성했다면 아래처럼 선택할 수 있다.

EC2 설정에서 태그를 따로 생성할 수도 있다.

태그를 선택하면 맨 아래 박스처럼 일치하는 인스턴스를 확인할 수 있다.

3-3. 설정 완료

AWS Systems Manager 설정은 적당히 넘기고

배포 설정을 확인하면 아래처럼 돼 있으면 넘어간다.

로드 밸런서는 사용하지 않으니 설정을 완료하고 배포 그룹을 생성한다.

CI/CD

지금까지 EC2 인스턴스를 만들고 서버를 띄워서 배포도 했고, RDS 인스턴스를 만들어서 DB도 연동했다.

버전 업데이트 시 일일이 테스트 및 빌드 하던 것도 Github Actions로 자동화했으니 CI 까지는 진행하였다.

이제 배포의 틀은 어느정도 갖춰지긴 했지만, 아직까지 수작업으로 매번 scp 커맨드를 써서 최신 버전으로 배포하고 있다.

결국 이런 단순 반복 작업은 사람이 하다보면 언젠가 꼭 실수가 나오기 마련이고, 이는 곧 장애로 이어질 수 있다.

따라서 이번엔 GitHub에 PR을 올리고 머지 시 배포되는것 까지 자동화(CD) 해보려 한다.

보통 이 두가지를 합쳐서 CI/CD라고 한다.

자동 빌드 및 테스트(CI, Continuous Integration)

업데이트 한 버전을 자동으로 빌드 및 테스트 하는 것

배포 자동화(CD, Continuous Deploy)

빌드 및 테스트를 마치고 성공적으로 업데이트 한 버전의 애플리케이션을 자동으로 배포 하는 것

CI/CD & 무중단 배포

애플리케이션의 버전을 업데이트하면 자동으로 빌드 및 테스트하고, 자동으로 배포까지 해보려 한다.

하지만 현재 배포 중인 서비스를 종료하고, 새로운 버전의 서비스를 띄우면 서버가 죽어있는 시간이 존재하지 않을까?

만약 별 다른 공지 없이 이렇게 서버가 내려가 있으면 사용자에게 나쁜 경험을 줄 수 있다.

따라서 새로운 버전을 배포해도 서버가 죽어있는 시간이 거의 없는 자동화 과정을 만들어보려 한다.

그림으로 나타내자면 아래와 같다.

참고자료

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

참고자료

Presign URL

S3 버킷에 이미지를 저장할 때 이전 글에서 했던 방식대로 백엔드 서버에서 SDK로 저장할 수 있었다.

하지만 이번 글에서는 조금 다른 방식으로 프론트엔드 서버에서 이미지를 저장해보려 한다.

프론트 엔드 서버에서도 AWS SDK를 이용하면 이미지를 저장할 수 있다.

하지만 프론트 쪽은 브라우저의 개발자 도구로 민감한 정보를 보기 편하기 때문에 꺼려진다.

그래서 이번에 써볼건 Presign URL 방식인데, 간단히 설명하자면 S3 버킷에 이미지를 저장할 수 있는 권한을 가진 URL이다.

이 URL로 몇번이고 S3 버킷에 요청을 할 수 있기 때문에 유효시간을 지정하여 발급한다.

프리사인 URL의 흐름은 아래와 같다.

1. 프론트에서 백엔드로 이미지 파일명을 보내서 프리사인 URL을 요청한다.
2. 백엔드는 요청 받은 이미지 파일명으로 S3 버킷에 저장할 수 있는 프리사인 URL을 발급한다.
3. 프론트에서 프리사인 URL에 PUT 요청으로 이미지를 저장한다.

사용 기술

• Spring Boot 3.2.4 / gradle-kotlin
• Java 17
• Aws SDK

1. AwsConfig 설정

AwsConfig

S3 프리사이너를 빈 등록 한다.

Aws 관련 yml 설정은 이 글의 내용과 동일하다.

@RequiredArgsConstructor
@ConfigurationProperties(prefix = "aws")
public class AwsConfig {

    private final String accessKey;
    private final String secretKey;
    private final String s3AccessPoint;

    public String getS3AccessPoint() {
        return s3AccessPoint;
    }

    @Bean
    public S3Presigner s3Presigner() {
        return S3Presigner.builder()
            .credentialsProvider(getAwsBasicCredentials())
            .region(Region.AP_NORTHEAST_2)
            .build();
    }

    private StaticCredentialsProvider getAwsBasicCredentials() {
        return StaticCredentialsProvider.create(
            AwsBasicCredentials.create(accessKey, secretKey)
        );
    }
}

2. ImageService 구현

ImageService

사실 프리사인 URL이라고 별게 있는건 아니고 컨트롤러에서 받아온 filename 하나만 있으면 된다.

이 파일 이름을 UUID로 변환하든, 파일 이름 그대로 저장하든 편한대로 로직을 구성하면 된다.

나머지는 백엔드 환경 변수에 설정한 Aws 설정 값들로 프리사인 URL을 만든다.

아래처럼 프리사인 리퀘스트를 만들고 프리사인을 해서 프리사인 URL 을 만들고 응답 값으로 주면 된다.

여기서는 프리사인 URL을 PUT 메서드로 요청하게끔 설정하였다.

유효기간은 5분으로 주었다.

@Service
@RequiredArgsConstructor
public class ImageService {

    private final AwsConfig awsConfig;
    private final S3Presigner s3Presigner;

    public String getPresignedUrl(String filename) {
        if (filename == null || filename.isBlank()) {
            throw new IllegalArgumentException("파일명을 확인해주세요.");
        }
        return generatePresignedUrl(filename);
    }

    private String generatePresignedUrl(String filename) {
        PutObjectRequest putObjectRequest = PutObjectRequest.builder()
            .bucket(awsConfig.getS3AccessPoint())
            .key(filename)
            .build();

        PutObjectPresignRequest presignRequest = PutObjectPresignRequest.builder()
            .signatureDuration(Duration.ofMinutes(5))
            .putObjectRequest(putObjectRequest)
            .build();

        try (S3Presigner presigner = s3Presigner) {
            return presigner.presignPutObject(presignRequest)
                .url()
                .toString();
        }
    }
}

3. 결과 확인

3-1. 프리사인 URL 발급 요청

프리사인 URL을 생성하는 컨트롤러를 만들었다.

아래처럼 파일 이름을 요청 값으로 보내고 프리사인 URL을 발급 받았다.

요청 값에 입력한 파일명이 string 이므로 S3에 string이라는 이름으로 저장될 것이다.

3-2. 프리사인 URL로 PUT 요청

아래 사진 처럼 form-data 형식으로 PUT 메서드로 저장하고자 하는 이미지를 넣어 요청한다.

여기서 요청하는 이미지 파일의 이름이나 key 값은 의미가 없고 프리사인 URL 발급 시 지정한 이름으로 S3 버킷에 저장된다.

아래 사진 처럼 200번 응답이 오면 성공한것이다.

실패할 경우 에러 페이지가 출력된다.

3-3. S3 버킷 확인

아래처럼 string 이라는 이름으로 파일이 저장됨을 알 수 있다.

4. PostMan이 아닌 프론트에서 요청할 때

CORS는 웹 브라우저의 보안 기능이다.

웹 브라우저는 스크립트가 현재 페이지와 다른 도메인으로 요청을 보낼 때 이를 제한하기 위해 CORS 정책을 적용한다.

포스트맨과 같은 API 테스트 도구는 브라우저가 아니므로, CORS 정책을 적용하지 않는다.

따라서 위처럼 해도 CORS 에러가 발생하지 않는다.

하지만 프론트엔드와 연동하면 브라우저에서 요청하기 때문에 CORS 에러가 뜬다.

CORS 에러를 막기 위해서는 S3 버킷에서 권한 처리를 해줘야한다.

아래처럼 S3 버킷에 들어가서 권한 탭에서 CORS 설정을 해주도록 한다.

본인은 PUT 요청으로 프리사인 URL을 만들었으므로 아래처럼 설정해주었다.

타임존

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

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

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

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

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

타임존 설정

sudo timedatectl set-timezone Asia/Seoul

타임존 확인

timedatectl

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

보안 그룹 설정

이전 글에서 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에 성공하면 아래와 같은 창을 확인할 수 있다.