[SECTION2] <AWS 배포 자동화> DAY 3 LOG

# 학습 목표

• 프론트엔드의 배포를 자동화
• CDN을 통해 프론트엔드를 캐싱하고, HTTPS를 적용
• 프론트엔드와 WAS를 연결
• 프론트엔드가 잘 작동하기 위해 WAS를 구현

 

# 해결 과제

💡 마일스톤7 - 프론트엔드 배포 자동화

• 프론트엔드 프로젝트의 배포 자동화를 구현
  • GitHub Action 또는 CodePipeline + CodeBuild 조합 중 하나를 선택해서 구현
• 프론트엔드의 변경사항이 S3에 배포가 되는지 확인
• 정적 웹사이트 설정을 통해 S3 웹사이트 URL로 접근 시 웹 페이지가 제대로 보여야 함 

💡 마일스톤8 - 프론트엔드 HTTPS 적용

• CloudFront를 이용하여, S3 정적 웹사이트를 캐싱
• Route 53을 이용해 https://www.yourdomain.click의 트래픽이, CDN(CloudFront)에 연결되도록 만들어야 함

💡 마일스톤9 - 프론트엔드-서버 연결 확인

• 프론트엔드가 잘 작동하도록, WAS 측 코드를 변경
• WAS가 CORS를 허용
• 프론트엔드가 올바른 서버를 바라볼 수 있도록 환경변수를 설정할 수 있어야 함

 

#과제 항목별 진행 상황

✏️  마일스톤7 - 프론트엔드 배포 자동화

Step 1 : 로컬에서 DB, WAS, WEB 서버(프론트엔드, 정적 웹사이트 이후 WEB 서버 통일) 기동 시 동작 확인

$ npm install
$ npm run build
$ npm run start &

Step 2 : S3 버킷을 생성한 후 빌드한 WEB 서버를 호스팅하고 환경 변수 설정

1 : S3 버킷 생성

2. S3를 정적 웹 호스팅용으로 구성

1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔 > 버킷 목록에서 정적 웹 사이트 호스팅을 사용 설정하려는 버킷의 이름을 선택
2. [속성(Properties)]을 선택
   •   

     

3. 정적 웹 사이트 호스팅(Static website hosting)에서 편집(Edit)을 선택
4. 이 버킷을 사용하여 웹 사이트를 호스팅를 선택
5. 정적 웹 사이트 호스팅에서 사용을 선택
6. 인덱스 문서(Index document)에 인덱스 문서 이름을 입력(일반적으로 index.html)

   • 

   • 인덱스 문서 이름은 대소문자를 구분하며 S3 버킷에 업로드하려는 HTML 인덱스 문서의 파일 이름과 정확히 일치해야하며, 웹 사이트 호스팅용 버킷을 구성하는 경우 인덱스 문서를 지정해야 루트 도메인이나 임의의 하위 폴더로 요청이 전송되면 Amazon S3가 이 인덱스 문서를 반환함 (인덱스 문서 구성 섹션을 참고)
   • 4XX 클래스 오류에 대한 사용자 지정 오류 문서를 제공하려면 [오류 문서(Error document)]에 사용자 지정 오류 문서 파일 이름을 입력
   • 오류 문서 이름은 대소문자를 구분하며 S3 버킷에 업로드하려는 HTML 오류 문서의 파일 이름과 정확히 일치해야 함, 사용자 지정 오류 문서를 지정하지 않았는데 오류가 발생하면 Amazon S3에서 기본 HTML 오류 문서를 반환함 (사용자 지정 오류 문서 구성을 참고)
   • (선택 사항) 고급 리디렉션 규칙을 지정하려면 리디렉션 규칙(Redirection rules)에 JSON을 입력하여 규칙을 설명 (ex.  요청의 특정 객체 키 이름 또는 접두사에 따라 조건부로 요청을 라우팅 가능. 자세한 내용은 고급 조건부 리디렉션을 사용하도록 리디렉션 규칙 구성 섹션을 참고)
7. [변경 사항 저장(Save changes)] 선택
8. Amazon S3는 버킷에 대한 정적 웹 사이트 호스팅을 지원하며, 페이지 하단의 정적 웹 사이트 호스팅(Static website hosting)에 버킷의 웹 사이트 엔드포인트가 표시

   • 

9. 정적 웹 사이트 호스팅에서 엔드포인트를 기록
10. 엔드포인트는 버킷의 Amazon S3 웹 사이트 엔드포인트 버킷을 정적 웹 사이트로 구성한 후 이 엔드포인트를 사용하여 웹 사이트를 테스트 가능
11. S3 버킷에서 권한 > 버킷 정책 > 편집 > 정책생성기 클릭해 정책을 만들고 적용

    • 

      

      

3. S3에 Pipeline 사용하기 설정

1. [Properties] 탭에서 [Versioning]을 선택 [Enable versioning]을 선택한 다음 [Save]를 선택
2. 버전 관리가 활성화되면 Amazon S3는 버킷에 있는 모든 객체의 모든 버전을 저장
3. [Permissions] 탭에서 기본값을 그대로 두기(S3의 버킷 및 객체 권한에 대한 자세한 내용은 정책에서 권한 지정 단원을 참조)
4. Amazon S3 콘솔에서 버킷에 파일을 업로드
   • 업로드를 선택
   • 파일을 끌어서 놓거나 파일 추가를 선택하고 파일 찾기
   • 업로드를 선택

4. 빌드한 WEB 서버 파일 업로드 후 S3 엔드포인트로 접근 시 정상 동작 확인

 

Step 3 : CodePipeline + CodeBuild으로 WEB 서버 배포 자동화  구현

1. 프로젝트 최상위 디렉토리에서 buildspec.yml 파일 생성

version: 0.2

phases:
  pre_build:
    commands:
      - cd helloworld-web
      - npm install
  build:
    commands:
      - npm run build

artifacts:
  files:
    - '**/*'
  base-directory: 'helloworld-web/build' # 특수문자가 있을 시 ''로 감싸주어야 함
  #discard-paths: yes # 디렉토리는 포함하지 않는 경우 사용

2. CodePipeline에서 파이프라인 생성

2-1. 파이프라인 설정 선택 : 파이프라인명, 서비스 역할 선택 후 다음

- 고급 설정에서 아티팩트 스토어나 암호화 키를 선택할 수 있으며 "아티팩트 스토어"의 리포지토리 버킷은 원본 버킷/위치를 뜻하는 게 아닌 별도의 Amazon S3 버킷을 별도의 파이프라인 아티팩트 리포지토리로 사용하는 것

2-2. 소스 스테이지 추가 : 빌드할 소스의 공급자를 선택하고 해당 소스 공급자와 AWS 연결 구성 후 리포지토리 이름 및 브랜치를 선택

2-3. 빌드 스테이지 추가 : 빌드 공급자를 선택(이 경우 Codebuild)하고 리전을 선택

- 이미 생성한 CodeBuild가 존재하는 경우 선택하거나 새롭게 생성할 경우 프로젝트 생성을 선택해 새로운 CodeBuild 프로젝트를 생성

2-4. 배포 스테이지 추가 : 배포 관련 설정 내용 지정

2-5. 검토 : 파이프라인 내용 검토 후 파이프라인 생성 

3. 파이프라인 생성 후 정상적으로 WEB 서버가 S3 버킷에 빌드, 배포 자동화되는 과정 확인

3-1. CodePipeline에서 소스 빌드, 배포 자동화 내역 확인

3-2. S3 버킷 엔드포인트로 접속해 WEB 서버 페이지가 정상적으로 배포되었는지 확인

 

Step 4 : WEB 서버 내용을 변경한 후 변경사항이 제대로 S3에 배포 되는지 확인

1. WEB 서버 파일 내용을 수정한 뒤 리파지토리에 add, commit, push 수행

// *.js의 경고 메시지 수정
// ... 상략 ...
  if (error) return <FilledMessage>요청을 받아올 수 없습니다. 서버 문제같은데요? 웹 배포 자동화는 성공적으로 이루어졌습니다.</FilledMessage>
// ... 하략 ...

2. CodePipeline에서 정상적으로 빌드, 배포가 수행되는지 확인

2-1. CodePipeline에서 소스 빌드, 배포 자동화 내역 확인

2-2. S3 버킷 엔드포인트로 접속해 수정된 WEB 서버 페이지가 정상적으로 배포되었는지 확인

 

✏️ 마일스톤8 - 프론트엔드 HTTPS 적용

Step 1 : CloudFront에서 배포를 생성해 WEB 서버가 배포된 S3 버킷과 연결

1. 원본 섹션의 [원본 도메인]에서 사용할 AWS 서비스나 원본 도메인 이름 입력
2. 기본 캐시 동작 섹션의 [뷰어 프로토콜 정책]을 Redirect HTTP to HTTPS로 설정
   • CloudFront에 SSL 인증서를 적용해 S3 버킷의 WEB 서버에 HTTPS 암호화를 적용할 것이므로 HTTP 요청을 HTTPS로 리다이렉트
3. 설정 섹션의 [대체 도메인 이름]에 사용할 도메인명 입력
4. 설정 섹션의 [사용자 정의 SSL 인증서]에 3번 항목의 도메인에 발급 받은 인증서를 적용
   • CloudFront의 경우 us-east-1 리전의 인증서를 적용해야 하므로 해당 리전의 인증서가 없는 경우 하단의 인증서 요청을 통해 발급받아 적용
5. 설정 섹션의 [IPv6]는 끄기로 설정

 

Step 2 : Route53을 이용해 CloudFront과 도메인 연결

1. Route53 콘솔의 호스팅 영역에서 CloudFront와 연결할 호스팅 영역에서 레코드 생성

1-1. 1단계 라우팅 정책에서 단순 라우팅 선택

1-2. 2단계 레코드 구성에서 단순 레코드 정의 선택

1. CloudFront 배포를 생성할 때 입력한 대체 도메인 이름과 동일하게 [레코드 이름] 입력
2. [값/트래픽 라우팅 대상]에서 사용할 대상, 이 경우 CloudFront 배포에 대한 별칭을 선택
3. 실제 사용할 CloudFront 배포 선택
4. [단순 레코드 정의] 버튼 선택하여 레코드 등록

 

Step 3 : CloudFront의 배포 도메인 이름과 대체 도메인 이름(Route53에 등록한 도메인)으로 접근 시  HTTPS가 적용된 WEB 서버로 접속되는지 확인

1. 배포 도메인 이름으로 접속 시

2. 대체 도메인 이름으로 접속 시

3. WAS ALB와 WEB CloudFront의 Route 53 도메인 적용 확인

 

✏️ 마일스톤9 - 프론트엔드-서버 연결 확인

Step 1 : WEB 서버가 잘 작동하도록, WAS 측 코드를 변경

1. GET /api/restaurants/ API 작성

// .../routes/api/restaurants/index.js

'use strict'

module.exports = async function (fastify, opts) {
  fastify.get('/', async function (req, reply) {
    reply.send([
      {
        "name": "용다방",
        "menu": [
          {
            "name": "애플 시나몬 에이드",
            "price": 6500,
            "duration": 5
          },
          {
            "name": "카페모카",
            "price": 6000,
            "duration": 5
          }
        ],
        "address": "서울시 마포구 양화로 1111",
        "rating": 4.5
      }
    ])
  })
}

2. HTTP 요청을 통한 API 테스트 

$ curl http://localhost:3000/api/restaurants
[{"name":"용다방","menu":[{"name":"애플 시나몬 에이드","price":6500,"duration":5},{"name":"카페모카","price":6000,"duration":5}],"address":"서울시 마포구 양화로 1111","rating":4.5}]%

 

Step 2 : WAS에 CORS 허용

1. @fastify/cors 모듈 설치

$ npm i @fastify/cors

2. WAS 서버의 plugins 디렉토리 하위에 cors.js 모듈(플러그인) 등록

'use strict'

const fp = require('fastify-plugin')

module.exports = fp(async function (fastify, opts) {
  fastify.register(require('@fastify/cors'), {
    origin: "도메인주소"
  })
})

 

Step 3 : 프론트엔드가 올바른 서버를 바라볼 수 있도록 환경변수를 설정 후 WEB 서버와 WAS가 정상적으로 작동하는지 확인

1. CodeBuild 콘솔에서 프로젝트 빌드 > 빌드 프로젝트 이름 선택 후 편집 > 환경 선택

2.  WEB 서버에 지정된 WAS API 환경 변수를 HTTPS 접근이 가능한 도메인으로 수정

3. 환경 변수 수정 후 WEB서버로 접근 시 WAS와 정상적으로 동작하는지 확인

 

#TROUBLE SHOOTING LOG

📝 문제 1 : 웹 서버 자동화 파이프라인 구성 시 Source에서 권한 부족 문제 발생

The provided role cannot be assumed: 'Access denied when attempting to assume the role 'arn:aws:iam::123456789012:role/service-role/AWSCodePipelineServiceRole-ap-northeast-2-helloworld-web''

• 원인 : S3 버킷에 대한 파이프라인 서비스 롤(IAM)을 사용해 AWS 리소스에 대해 액세스할 수 있는 권한 정책이 존재하지 않음
• 해결 방안 : 해당 IAM 정책에서 사용자가 위임하려는 역할에 대해 sts:AssumeRole을 호출할 수 있는 권한을 부여(https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/troubleshoot_roles.html)

# References

https://rainbound.tistory.com/entry/AWS-Parameter-Store-%EC%99%80-AWS-Secrets-Manager-%EA%B3%B5%ED%86%B5%EC%A0%90%EA%B3%BC-%EC%B0%A8%EC%9D%B4%EC%A0%90

AWS Parameter Store 와 AWS Secrets Manager 공통점과 차이점

https://www.npmjs.com/package/@fastify/cors

@fastify/cors

https://velog.io/@jisun-rea/AWS-IAM-Role-AssumeRole

[AWS] IAM Role, AssumeRole