꿀팁 저장소

클라이언트 코드를

EC2에서 관리 및 배포하곤 했었는데

사실 용량도 많이 차지하고 좋은 방법은 아니라고 생각했다.

더 빠른 전달속도와 더 쉬운 프로젝트 관리를 위한 방법을 찾던중

CloudFront + Route53+ S3 + ACM(for SSL)
조합을 발견했다.

처음해보는 사람이라도 쉽게 할수있고,

효과는 눈이 번쩍일정도로 뛰어난것같다.

이에 대해 고민하던 나와 다른 분들을위해

위 조합을 이용하는 방법을 상세하게 공유하고자 한다.

1. S3

1-1) 먼저, 시작은 S3에서부터다

1-2) React 프로젝트가 있다면 빌드후 생성된 파일들을 S3에 올릴것이다.

1-3) S3 -> 버킷 만들기

1-4) 주의사항은 모든 퍼블릭 액세스 차단을 해제시킬것 (사이트는 누구나 접근가능해야하니까요)
1-4-1) 버킷 만들기
1-5) 버킷을 만들고나면 객체 탭에다가 빌드후 생성된 파일들을 드래그다운하여 업로드한다.
1-6) 다음, 권한 탭에서 버킷 정책을 생성해준다
1-6-1) 편집 -> 정책 생성기 
1-6-2) Select Type of Policy: S3
1-6-3) Effect: Allow

1-6-4) Principal: *

1-6-5) Aws Service: S3

1-6-6) Actions: GetObject
1-6-7) ARN: 정책 편집 페이지에 있는 버킷ARN을 복사해 붙여넣는다. 그리고 뒤에 /*을 덧붙인다
1-6-8) ARN 예시: arn:aws:s3:::coke.cola/*
1-7) 속성탭으로 이동한다.
1-7-1) 맨 하단에 정적 웹 사이트 호스팅을 편집
1-7-2) 정적 웹사이트 호스팅 -> 활성화, 유형 -> 정적 웹사이트 호스팅, 인덱스 문서 -> index.html
1-7-3) 변경 사항 저장

여기까지 했으면 S3설정은 끝났다.

심심하다면 index.html의 객체 URL로 접근해보면 접속됨을 확인할 수 있다.

이제 누구나 쉽게 접속할수있게 도메인을 설정해주는 것과 좀더 빠른 페이지를 위한 CloundFront 적용이 남았다.

아, 안전한 서비스 제공을 위한 SSL도 필수니까 당연히 진행하는거로

이전 포스팅에서 했던것처럼 ACM(Certificate Manager)을 통해 SSL 인증서를 생성해보자

2.  SSL 인증

2-1) ACM (Certificate Manager)에 접속
2-2) 인증서 요청 -> 공인 인증서 요청
2-3) 도메인 이름 사용하고자 하는거로 입력  (S3에 저장한 사이트를 운영하고자하는 사이트 도메인), (구매해둔 도메인은 있다는 가정)

2-4) DNS 검증 -> 태그 설정 (내가 식별을 위한거니까 영문으로 알아볼수 있게 쓰면됨)

2-5) 검토를 하고나서 생성된 정보를 기반으로 Route 53에 해당 CNAME을 등록해주면 됩니다.

SSL은 간단히 이정도만 해주면 끝입니다.

그러면 잠시 뒤 발급완료 처리가 됩니다.

다음 순서는 CloudFront입니다.

S3에서 파일을 제공하는것보다 빠를 뿐아니라, SSL을 연결해주는것도 쉽게 가능합니다.

3. CloudFront 설정하기 - 조금 번거로움

3-1) CloudFront 접속 

3-2) Create distribution

3-2-1) Origin Domain 검색 (로딩이 좀 걸립니다) ->  S3 버킷이 나타나면 클릭

3-2-2) Viewer protocol policy: Redirect HTTP to HTTPS

3-2-3) Custom SSL certificate - optional: 이전에 생성해둔거로 지정

3-2-4) Default root object: index.html

3-2-5) Create distribution
3-3) 생성됐다면, 도메인을 설정해줄건데요. 다시 Roue53에 해당 호스팅 영역으로 갑니다.

3-3-1) 레코드 생성 - "A 유형"

3-3-2) 도메인 이름 설정 (2-3과 일치하게)

3-3-3) 트래픽 라우트 대상 -> 별칭 active -> Cloud Front 배포에 대한 별칭 선택 -> 검색란에 CloudFront의 Distribution domain name 이름 검색 및 선택

3-3-4) 3-3-1 ~ 3-3-3의 작업을 한번 더 반복하여 "AAA 유형"도 생성

3-4) 거의 끝났습니다. 다시 Clound Front로 돌아갑니다.

3-4-1) 해당 객체를 Edit

3-4-2) Alternative domain name에 "Add Item" 하여 2-3에서 만든 도메인과 동일하게 입력해줍니다.
3-4-3) 그리고 저장하면 끝

자 이제 두근두근 하면서

해당 도메인에 https://로 접속해 봅니다.

잘되나요? 잘됐길바라며 여기서 마치겠습니다.

서브도메인은 정말로 유용하다

하나의 도메인을 여러 방면으로 사용할 수 있게해준다.

예를들어,

블로그용: blog.self-made.cloud

상품판매: shop.self-made.cloud
포트폴리오: portfolio.self-made.cloud

이런식으로 도메인별로 역할을 구분한다던지

혹은 서브도메인에 cname을 붙여서 다른 서비스와 연동한다던지
(지금 글쓴이의 도메인이 tistory와 연동된것처럼)

하는것처럼 말이다.

이렇게 사랑스러운 서브도메인을 적극 활용하기 위해서는

SSL 인증은 필수라고 볼 수 있다.

AWS에서는 ACM 서비스를 통해 쉽게 SSL인증서를 발급 및 적용할 수 있는데, 

한번 알아보도록 하자. (도메인을 하나 이미 구매했다는 전제)

1. AWS -> Route53

1-1) 호스팅 영역을 먼저 생성해보겠습니다.

1-2) Route53에 해당 도메인명과 내가 이해할수 있는 간략한 설명을 기록한뒤 생성합니다.

1-3) 생성하고나면 기본적으로 MX, SOA에 해당하는레코드들이 생성되어있습니다.

1-4) 도메인을 다른 업체에서 구매했다면 도메인 구매 업체 네임서버를 aws에 맞게 변경해주어야합니다.

(NS 타입으로 도메인 구매 업체의 네임서버값 레코드를 추가해주면 됩니다.

(*팁:  EC2 등의 서비스를 도메인과 연결하려면 여기서 설정 가능합니다. A레코드 - 서비스의 IP 쌍으로 레코드 생성)

2. AWS -> ACM (Certificate Manager)

2-1) 인증서 요청 -> 공인 인증서 요청
2-2) SSL인증을 받고자하는 도메인의 이름을 입력 (예를들어, 블로그 도메인을 생성하고자 한다면 blog.domain.com)
2-3) DNS 검증
2-4) Tag생성 -> 영문으로 해주세요. 내가 해당 인증서를 식별하기 위함이니 헷갈리지 않게 적어주세요

3. 인증서 추가인증 받기

3-1) SSL 인증서 요청으로 끝나는게 아니라 Route53에서 일을 마무리 해주어야합니다.

3-2) 다시 Route53으로 돌아와 인증서 생성후 표기된 CNAME의 이름과 값을 등록해줍니다.

3-3) 레코드 생성 -> CNAME

4. 마무리
4-1) 해당 서브도메인에 SSL설정은 완료되었습니다.
4-2) 잠시 기다린뒤 ACM에서 새로고침을 몇번 해보면 인증서 "발급 완료"를 확인해 볼 수 있습니다.

여기까지 하고 이제 해당 도메인과

연결하고자 하는 서비스를 연결해주기만 하면됩니다.

위에서 팁으로 안내했던 방법 등을 이용하면됩니다.

EC2와 NGINX만 쓸때는 너무나도 자연스러웠던것이

LoadBalancer를 쓰면서 추가적인 조치가 필요해졌다

EC2 + NGINX 구성에서는 늘 사용자 요청의 대문역할은 NGINX였고,

NGINX에 HTTP -> HTTPS Redirect 설정을 해두면 자연스럽게 처리되었다.

다만, 이번에 사용자의 증가로 Load Balancer를 적용한 이후로는 해당 코드는 무효했었다.

대문이 NGINX가 아니라 Load Balancer가 되어버린것이다.

따라서,  HTTP -> HTTPS Redirect설정을 Load Balancer에서 해주었다.

너무나도 간단하고 친절하게 되어있으므로 겁먹을 필요없다.

1. EC2 -> 로드밸런서 -> 대상 클릭 -> 하단에 탭중 리스너 -> HTTP 내용중 "규칙 보기/편집"을 클릭하여 해당화면으로 진입.

2. 연필탭 클릭 -> 왼쪽에 뜬 연필 한번 더 클릭 -> 기본 설정 지우고 "리다이렉션 설정" -> HTTPS / 443


참고자료
stackoverflow.com/questions/24603620/redirecting-ec2-elastic-load-balancer-from-http-to-https

S3에 업로드된 파일의 이름변경, 언제 필요할까요?

특정한 이름 구조나 패턴을 갖춘 파일들이 필요할 때가 분명히 있습니다.

제가 이번에 해당 경험을 하게되어 간단히 정보를 공유해보고자 합니다.

S3에서 제공하는 API를 활용하면 제법 다양한 일들을 할 수 있습니다.

그중에서 이번엔 버킷에서 항목들의 목록을 가져오고, 항목들의 이름을 변경하는 방법에 대해서 알아보고자 합니다.

먼저, S3 API 중에 항목의 이름을 변경하는 API는 존재하지 않습니다.

따라서, 항목을 카피하는 copyObject를 이용해  변경된 이름의 Object를 생성하고 원본을 지우는 방식을 채택해야합니다.

항목들을 가져올때는 listObjectsV2를 사용하는데요 간단한 예시를 들어보겠습니다.

const config = {
  accessKeyId: process.env.AWS_KEY,
  secretAccessKey: process.env.AWS_SECRET_KEY,
  region: 'ap-northeast-2',
  signatureVersion: 'v4',
};

AWS.config.update(config);
const s3 = new AWS.S3();

s3.listObjectsV2({ Bucket: `pdf.pitchit`, MaxKeys: 1000 }, async (err, data) => {
  const { Contents } = data;
  const keys = Contents.map(info => info.Key);
  
  // 키를 활용해 다양한 액션을 취할 수 있습니다.
  // 그중에서 객체 복사는 다음과 같이 간단히 할 수 있습니다.
  
  const info = {
    Bucket: 'origin_bucket',
    CopySource: `/target_bucket/${key}`,
    Key: new_name, // 변경할 이름입니다.
  };
  
  s3.copyObject(info, async (err, data) => {
    ...
  });
});