💡 이 포스트에는 S4 Unit 10. [deploy] CI/CD 와 관련된 과제를 하고 몰랐던 점이나 부족했던 점을 정리했다!
이번 과제는 CI/CD 를 실습하기 위해 Github Action, AWS S3를 사용해 클라이언트를 배포했다.
다음과 같은 순서로 진행했다.
AWS에서 IAM을 검색하고, 처음에 사용자를 생성하면 생성직후 '엑세스 키 ID'와 '비밀 엑세스 키' 이렇게 두가지가 뜬다.
이 두 키는 처음부터 잘 복사해서 가지고 있어야 한다.
나의 경우 AWS 계정을 제공받아 이미 키를 알고있었기 때문에 새로 생성할 수는 없었다.
대신 아래의 링크를 참고하면 엑세스 키를 생성하는 데 도움이 된다.
🔗 AWS 사용자 엑세스 키 가이드
🔗 AWS 엑세스 키 발급받고 사용하기 - 공부하는 개발자
배포할 코드가 올라가 있는 깃 리포지토리를 준비하고, 어느 브랜치에 올릴 것인지 확인해둔다. 참고로 이 리포지토리는 public이여야 한다.
깃허브 리포지토리 화면 상답의 탭 중에서 setting을 선택한다.
왼쪽 사이드바의 security 메뉴 중에서 secrets의 아래 화살표를 클릭한다.
그곳에 actions를 클릭한다.
여기서 우측 상단의 new repository secret 버튼을 클릭하여 키를 생성한다. 키는 총 2개 등록한다.
Name에는 키의이름, Secret에 각 키의 이름과 값을 넣고 Add secret 버튼을 클릭한다. 이번 실습에서 각 키의 이름과 secrets 값은 아래와 같다.
이후 yml 파일을 작성할 때 보면 알겠지만
1번에 AWS의 엑세스 키 ID를 값으로 AWS_ACCESS_KEY_ID
로,
1번에 AWS의 비밀 엑세스 키를 값으로 AWS_SECRET_ACCESS_KEY
라는 이름으로 생성한다.
생성하면 위 첫번째 이미지의 하단처럼 Repository secrets 목록에 2개의 키가 생성된 것을 확인할 수 있다.
지금까지의 AWS 키를 등록하는 방법은 아래의 공식문서에 잘 나와있다.
🔗 Github actions에 AWS 키 등록하기
이제 위의 등록했던 키를 가지고 배포할 작업물에 yml파일을 작성하고,
리포지토리에 push 하면 자동으로 빌드 후 S3의 버킷으로 업로드가 된다.
이렇게 자동화하기위해 yml 파일을 작성해주어야한다.
이번 실습에서는 client.yml로 작성했으며,
아래서부터 중요한 부분 위주로 yml코드를 부분부분 설명하려고 한다.
작성할 yml파일은 크게 name, on, jobs로 나뉜다.
name은 자동으로 처리할 액션의 임의의 이름이다.
on은 언제 이 액션이 실행될지 명시되어 있다.
jobs는 구체적으로 실행할 내용이다.
on
작성이번 실습의 액션 이름은 client라고 정했다.
on
에는 git push시 실행되도록 하기 위해 작성했으며, 실행될 브랜치를 적는다.
나의 경우 main 브랜치에서 실행할 예정이므로 main이라고 작성하였다.
name: client
on:
push:
branches:
- main
각 스텝을 작성하기 위해 jobs 항목을 작성한다.
여기서 steps 안에 각 실행내용을 작성할 예정이다.
각 실행 내용의 이름은 - name: <내용>
이런식으로 작성한다.
jobs:
build:
runs-on: ubuntu-20.04 #배포 실행될 환경
steps: #각 단계의 이름과 실행내용을 나열해서 작성한다.
- name: Checkout source code.
uses: actions/checkout@v2
다음의 설명 내용들은 모두 steps 안에 이어서 작성한다.
빌드를 하기 위한 모듈을 설치해야하므로 steps 아래에 다음과 같이 작성한다.
나의 경우 npm install로 설치해야 하므로 run:
부분에 npm install이라고 작성했다.
working-directory
에는 배포할 클라이언트의 디렉토리명을 넣는다.
#...
- name: Install dependencies
run: npm install
working-directory: ./my-client #디렉토리명
#...
작업물을 빌드해야 하므로 npm run build가 필요하다.
나머지는 위와 같다.
- name: Build
run: npm run build
working-directory: ./my-agora-states-client
생략하고 바로 버킷으로 연결해도 된다.
AWS의 버전을 확인하는 단계로 엑세스 키, 시크릿 키가 필요하다.
env
부분에 해당 키를 입력한다.
키 이름은 각각 secrets.<2번에서 생성한 키명>
으로 아래와 같이 작성한다.
- name: SHOW AWS CLI VERSION
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_EC2_METADATA_DISABLED: true
run: |
aws --version
빌드한 클라이언트를 버킷에 배포하기 위한 구문이다.
AWS 버전을 확인했던 것처럼 env 항목에 키를 입력하고,
run 부분에는 명령어를 입력한다.
- name: Sync Bucket
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_EC2_METADATA_DISABLED: true
run: |
aws s3 sync \
--region ap-northeast-2 \
build s3://fe-63-shinnh2-s3 \
--delete
working-directory: ./my-agora-states-client
버킷과 연결하는 run
명령어 부분을 자세히 살펴보면 다음과 같다.
aws s3 sync \ #sync냐 cp에 따라 차이가 있다.
--region ap-northeast-2 \ #리전에 대한 부분이다. 여기선 서울이다.
build s3://fe-63-shinnh2-s3 \ # build s3://[버킷 이름]
--delete #sync, cp와 결합하여 다른 명령어를 사용한다.
여기서 aws s3 sync
와 aws s3 cp
에는 차이가 있다.
cp는 기존에 똑같은 파일이 있더라도 모든 파일을 복사하여 업로드한다.
sync는 업데이트된 파일만 복사하여 업로드 한다.
여기서 --delete 를 사용하면 업로드시 삭제된 파일이 있다면, 버킷에서도 이를 적용하여 해당 파일을 삭제한다.
참고: 🔗 AWS 관련 가이드
참고: 🔗 https://stackoverflow.com/questions/64728076/aws-s3-cp-vs-aws-s3-sync-behavior-and-cost
yml파일을 작성하고 push하면 자동으로 빌드 후 버킷에 업로드된다.
yml파일이 잘 작성되어 통과되면 깃허브의 actions 탭에 체크표시로 뜬다.
체크표시로 제대로 github actions 가 잘 작동한 것을 확인했다면
AWS 버킷에서 파일이 잘 업로드되었는지 확인할 수 있다.
업로드한 파일의 마지막 수정 시간이 git push한 시간과 비슷하고,
스크롤을 아래로 내려 '정적 웹 호스팅'의 주소부분을 클릭했을 때 클라이언트 화면이 뜬다면 클라이언트 배포가 완료된 것이다.
이번에 깃을 배포하는 과정에서 깃 명령어가 잘 안 될뻔 했지만, 그래도 다행히 잘 해결했다. 이런식으로라도 깃을 계속 연습해서 경험치를 쌓아놓아야 나중에 능숙하게 깃을 다루지 않을까? 그리고 직접 만든 결과물을 배포하는 경험을 직접해보니 재미있었다. 무엇보다 이렇게 빌드+배포를 git push 만으로도 자동으로 할 수 있다는 점이 좋다고 생각한다. 오늘도 이렇게 하나 배워갑니다!