AWS S3로 실습해보는 CI/CD (사실 CD만 함)

Notice

Recent Posts

Recent Comments

Link

« 2025/03 »
일	월	화	수	목	금	토
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Tags more

Archives

Today

Total

관리 메뉴

방명록 남기기

깊고 넓은 삽질

AWS S3로 실습해보는 CI/CD (사실 CD만 함) 본문

Programming

AWS S3로 실습해보는 CI/CD (사실 CD만 함)

ggsno 2022. 9. 2. 21:05

풀스택과 풀사이클의 차이점을 알게 되었다. 약간의 뉘앙스 차이라는데, 전자는 모든 과정을 할 줄 아는 것이고 후자는 모든 과정을 경험해 봤다는 의미라고 한다. 풀스택까진 아니더라도 풀사이클 개발자가 되면 개발의 이해도가 높아지지 않을까. 배포에 대해 공부하는 것도 그 일환이라고 생각한다.

본 포스팅은 CI/CD 실습을 위해 간단한 배포 서버인 AWS S3를 이용해 정적 페이지를 배포하고 CI/CD 툴인 Github Action으로 배포 자동화를 하는 과정을 담고있다.

CI/CD

CI/CD의 목적은 빌드, 테스트, 배포 과정을 자동화하는 것이다.

CI (Continuous Integration) : Continuous Integration를 직역해보자면 지속적 통합이다. 여기서 통합은 코드의 변경을 merge하는 것을 넘어 변경이 유효한지 테스트하는 것까지 포함한다. 본 포스팅에서는 테스팅을 다루지 않기 때문에 CI/CD에서 사실상 CD만을 실습 해보도록 하겠다.
CD (Continuous Delivery/Deployment) : CD는 두 가지 의미로 사용되는데, Delivery와 Deployment로 나뉜다. 전자는 개발환경까지의 배포 자동화를 말하고 후자는 실제 사용자가 사용하고 있는 Production 환경에 배포 자동화를 말한다.
CI/CD 플랫폼 종류 : CI/CD의 파이프라인을 구축하고 모니터링하기위한 플랫폼으로 크게 두 종류가 있다. 하나는 설치형이고 나머지 하나는 클라우드 형이다. 전자는 특정 컴퓨터에 플랫폼을 직접 설치해 활용하는 방식 (ex. Jenkins)이고 후자는 별도의 운영 관리 없이 클라우드에서 제공하는 서비스를 활용하는 방식(ex. Travis CI, GitHub Actions) 이다. 클라우드 형은 파이프라인 구축에만 신경 쓸 수 있는 대신 주어진 서비스 이외의 세부적인 조정이 불가하다.

Github Actions

Github Actions은 Github에서 제공하는 클라우드형 CI/CD 툴이다. 아래는 Github Actions 구성 요소이다.

Workflow : 하나 이상의 작업을 실행하는 자동화 프로세스. 레포지토리 내의 yaml 파일에 의해 정의된다. 후술할 Event에 의해 트리거되거나 정의된 일정으로 실행될 수 있고 수동으로도 실행 가능하다.
Event : Workflow 실행을 트리거하는 레포지토리의 특정 활동
Runner : Workflow를 실행할 서버. GitHub Actions의 Runner는 기본적으로 Node 16 version을 탑재한다.
Jobs : 하나의 Runner에서 실행되는 Workflow의 일련의 step 모음. step은 하나의 shell script 혹은 후술할 Action을 의미한다.
Actions : 자주 반복 되는 작업을 수행하는 GitHub Actions 플랫폼용 사용자 지정 응용 프로그램. 설정파일에서 use 키워드와 함께 사용할 수 있다.

AWS S3를 이용한 정적 사이트 배포

AWS S3 : S3는 Simple Storage Service의 약자로, 파일을 클라우드 스토리지에 저장하고 인터넷상으로 접근할 수 있게 해주는 서비스다. build한 정적인 파일들을 S3를 통해 배포 가능하다.

배포용 S3 Bucket 생성 및 호스팅 설정

AWS 사이트의 S3 서비스에 접속해 새로운 bucket을 생성한다

Bucket name : 아이디처럼 다른 사람들과 중복되지 않게 만들어야 함
AWS Region : 클라우드 서비스를 제공하는 물리적 서버의 위치. 가까운 곳으로 설정.

public access block을 체크 해제시 하단에 경고창이 뜬다. 알았다고 체크해주자.

배포용이기 때문에 public access block을 체크 해제

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<bucket-name>/*"
        }
    ]
}

Resource속성의 <bucket-name>을 현재 생성한 bucket의 이름으로 바꿔야 한다.

Properties 탭에서 최하단에 있는 Static website hosting 옵션 진입

정적 웹사이트 호스팅 Enable체크 후 가장 먼저 보여줄 index 파일의 이름 기입

Properties 탭의 최하단에 있는 Static website hosting에 추가된 배포 사이트 URL

여기까지가 S3를 이용한 정적사이트 배포이다.

여기에 깃허브 액션에서 사용할 access key를 미리 받아두자.

사이트 우측 상단에 있는 아이디를 클릭하면 Security credentials가 있다

Create New Access Key를 클릭해 Access key를 생성하자

액세스 키를 만들 때 access id와 secret key를 주는데, 최초 한 번만 보여주고 그 이후로는 절대 볼 수 없으니 따로 파일로 저장하는것을 추천한다.

Github action을 이용한 배포 자동화

깃허브 레포지토리를 생성하고 build할 파일들을 넣은 후 Actions에 들어가보자

workflow를 만들어주는 많은 템플릿들이 있다. 우리는 실습을 위해 직접 작성해보자.

line 1 | name : workflow의 이름

line 3 | on : job이 트리거 되는 조건들 ( main 브랜치에 push가 되면 job을 실행해라)

line 8 ~ 23 | jobs의 steps들이 차례대로 실행된다. env에서 사용하는 변수들은 아래에 나올 스크린샷을 참고하자

line 24 | SOURCE_DIR에는 build될 파일들이 들어가는 디렉토리 이름을 기입한다. vite로 프로젝트를 만들었다면 dist이고 CRA로 만들었다면 build일 것이다.

name: deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@main
      - run: npm ci
      - run: npm run build
      - name: deploy to s3 bucket
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: "ap-northeast-2"
          SOURCE_DIR: "dist"