앞선 포스팅에서 S3의 배포를 스크립트 실행 하나로 배포하는 방법에 대해 알아보았다. 하지만 해당 스크립트를 입력하는 것은 수동이므로 이 마저도 자동으로 하기위해 CI/CD라는 것이 존재한다.
CI/CD는 Continuous Integration(CI)와 Continuous Delivery/Deployment(CD)를 통합해서 부르는 용어다. CI/CD는 개발 과정에서 필요한 빌드, 테스트, 배포등의 과정을 자동화한다. CI/CD 자동화를 통해서 개발자들은 코드를 자동으로 테스트하고 배포할 수 있고 이를 통해 효율적인 작업과, 더 빠르고 더 자주 배포를 진행할 수 있게 된다.
CI/CD는 일련의 과정을 처리하는 CI/CD 파이프라인을 구축함으로서 자동화한다. 개발자들은 이러한 파이프라인을 구축하고 모니터링 하기 위해서 이를 위한 CI/CD 플랫폼을 사용하는데 CI/CD 플랫폼의 종류를 구분하자면 크게 설치형
과 클라우드형
으로 나눌 수 있다.
CI/CD 파이프라인 또한 하나의 프로그램이므로 프로그램을 설계해두면 이를 실행할 컴퓨터가 필요하다. 설치형
은 파이프라인을 구축하는 개발자가 직접 특정 컴퓨터에 CI/CD 플랫폼을 설치해서 활용하는 방법
이다. 대표적인 설치형 CI/CD 플랫폼으로는 Jenkins
가 있다.
반대로 클라우드형
같은 경우에는 CI/CD 플랫폼을 운영할 컴퓨터를 개발자가 직접 관리할 필요 없이 서비스 제공자가 클라우드에서 모두 운영해주는 형태
다. 즉 클라우드형 CI/CD 플랫폼을 이용하면 별도의 컴퓨팅 자원에 대한 관리 없이 CI/CD 파이프라인의 구축에만 신경 쓸 수 있다. 다만, 컴퓨터에 직접 접근할 수 없고 플랫폼에서 제공해주는 수준까지만 할 수 있기에 세부적인 조정이 불가능하다는 단점이 있다. 대표적인 클라우드형 CI/CD 플랫폼의 예시로는 Travis CI
, GitHub Actions
등이 있다.
GitHub Actions는 GitHub에서 제공하는 클라우드형 CI/CD 툴이다. GitHub에서 자체적으로 제공하기에 GitHub 레파지토리와의 연동이 쉽고, 레파지토리 안에서 CI/CD까지 함께 구축하고 관리할 수 있다는 이점으로 인해 현재 많은 인기를 얻고 있다.
출처: GitHub Actions 공식문서(https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions)
use
키워드와 함께 사용할 수 있으며 브랜치로 체크아웃하고, 환경을 설정하는 등 복잡하지만 자주 사용되는 과정들을 미리 정의해두고 편리하게 활용할 수 있다.배포하고자 하는 프로젝트의 루트 디렉토리에 폴더를 만든다.
.github > workflows > CICD.yaml
해당 파일에 다음과 같은 코드를 작성한다.
name: CI/CD-improved-todo-list
on: # 언제 동작 할 것인가?
push: # push (&PR) 시 동작할 것이다.
branch: # main 브랜치에 push할 때 동작할 것이다.
- main
jobs: #어떤 작업을 진행할 것인가.
cicd: #CI/CD를 진행할 것이다.(사용자 지정 이름)
runs-on: ubuntu-latest # 우분투 환경에서 실행할 것이다.
steps: # 진행 순서는 다음과 같다. run은 스크립트, use는 액션
- uses: actions/checkout@v3 # checkout 버전3 액션을 사용할 것이다 마켓 플레이스 액션.
with: # checkout 공식문서에 따라 추가
ref: 'main' # main 브랜치로 갈 것이다.
- run: npm ci # 디펜던시 설치해주기 clean install(==npm install)
- run: npm run test # 기본 파일로 있는 App.test.tsx가 실행되는 것.
- run: npm run build # 빌드 돌리기
- name: deploy to s3 # 아래 step의 이름을 부여
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 액세스 키 아이디
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} # aws 액세스 키
AWS_REGION: 'ap-northeast-2'
SOURCE_DIR: 'build'
위와 같이 작성을 하게되면 main 브랜치에 push를 하거나, merge를 하게되면, 코드가 테스트 과정을 거쳐 자동으로 배포되게 된다.
steps
은 크게 run
과 use
두 가지 형태가 있는 것을 볼 수 있다. (name은 그저 이름 지정일 뿐이다.) run
은 스크립트 실행
, uses
는 액션 실행
을 뜻하며, 액션은 github의 marketplace
에서 키워드로 검색하면 찾을 수 있으며, 사람들이 많이 사용하는 것을 사용하길 추천 한다고 하셨다.
위 yaml 파일에 절대로 secrets.AWS_S3_BUCKE
AWS_ACCESS_KEY_ID
secrets.AWS_SECRET_ACCESS_KEY
를 하드 코딩해서 올려서는 안 된다. 이것이 깃허브에 공개적으로 업로드 될 경우 해커들에 의해 아주 잠깐 동안의 노출에서 키를 탈취당할 수 있으며 5000만원 과금의 중인공이 될 수 있으니, 절대로 하드 코딩하는 일은 없어록 하자. 그렇다면 키는 어떻게 해야 안전하게 올리는 것일까?
위와 같이 해당 프로젝트의 레포지토리
> setting
> Secret and variables
> Actions
> New repository secret
에서 추가해줄 수 있다. 여기에 한번 입력된 값은 본인조차 다시 열어볼 수 없으므로, 보안이 철저하다고 볼 수 있다.
참고로 AWS access key는 AWS의 보안자격증명
에서 발급 받을 수 있으며, 생성 당시에만 값을 확인할 수 있으므로, cvs파일로 다운받아 안전한 곳에 보관해놓도록 하자.