CI/CD
의미
"CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)
"CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)
CI/CD 가 진행되는 단계
지속적 통합(Continuous Integration, CI)
개발자를 위한 자동화 프로세스, Code - Build - Test 단계에서 진행
- Code : 개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push하는 단계
- Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
- Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정
지속적 배포(Continuous Delivery/Deployment, CD)
지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미. 이 부분은 Release - Deploy - Operate 단계에서 진행
- Release : 배포 가능한 소프트웨어 패키지를 작성
- Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출. 실질적인 배포.
- Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지.
CI/CD 파이프라인
배포 과정의 자동화
자동화가 진행되는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지인데
지속적인 통합 및 배포를 위하여 일련의 자동화 단계를 만드는 것을 파이프라인을 구축한다고 표현함
소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조임
파이프라인의 3단계
- Source 단계
원격 저장소에 관리되고 있는 소스코드에 변경 사항이 생기면 감지해서 다음 단계로 전달- Build 단계
전달받은 코드를 컴파일, 빌드, 테스트하여 가공하고 생성된 결과물을 다음 단계로 전달- Deploy 단계: 전달받은 결과물을 실제 서비스에 반영하는 작업
클라이언트 배포
Github Actions를 통한 S3에 클라이언트 배포 Flow 3단계
- Source: 작성한 코드를 github 해당 레포의 브랜치에 커밋하고 푸시하면
- Build: (YAML 파일에 적힌 내용을 토대로) Webpack을 이용해 빌드를 하게되고
- Deploy: (YAML 파일에 적힌 내용을 토대로) S3로 빌드 결과를 업로드해줌
어제 CRA 모드에서 npm run build 를 통해 build 를 완료하고
build 폴더에 생긴 파일들을 S3 버킷에 수동으로 넣어줌으로써 했던 절차들을
YAML 파일에 자동화 작업 내용을 작성해줌으로써
push 한번으로 빌드에서 배포까지 자동으로 하게 해주는 것 같다.
YAML 파일 작성 샘플
# .github/workflows/client.yml
name: client
on:
push:
branches:
- reference
jobs:
build:
runs-on: ubuntu-20.04
steps:
- name: Checkout source code.
uses: actions/checkout@v2
- name: Install dependencies
run: npm install
working-directory: ./my-agora-states-client
- name: Build
run: npm run build
working-directory: ./my-agora-states-client
- 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
- 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-27-julyk9 \
--delete
working-directory: ./my-agora-states-client=> aws --version : aws CLI 의 버전을 확인하는 것
=> AWS_ACCESS_KEY_ID 과 AWS_SECRET_ACCESS_KEY 은 github actions 의 secrets 에서 설정해줘야 하는 것으로 코드에 적은 것과 같은 네이밍으로 작성해줘야 함. 입력해야할 key는 ID는 보안증명에서 확인할 수 있으나 KEY는 IAM 생성시 확인할 수 있는 것으로 보이며 개인적으로는 확인할 수 없어서 엔지니어분이 다시 알려줌. 이것을 모르고 하드코딩으로 작성하여 깃허브상에 노출되면 aws에서 정책상 문제로 인해 인지하고 이용에 제재가 들어올 수 있다고 함(실제로 버킷이 없어지는 등 사례 발생)
=> build s3://fe-27-julyk9 : build는 CRA로 생성시 빌드파일이 생성되는 폴더 이름으로, 수동으로 웹팩으로 번들링 할 경우 dist 라는 파일명이 생겨서 자료 검색하다보면 dist로 작성하는 사람들도 있는 것
=> --delete 옵션 : 원본에 없는 파일이나 객체를 대상에서 제거해줌. 즉 파일이 추가되는 경우 말고, 버킷에 원래 있는 파일중에 이번에 sync 시켜주는 빌드 파일에 없는 파일들을 제거해주는 역할이라고 생각됨
=> sync의 working-directory 를 처음에는 /build 까지 써줘야 되지 않나 생각했는데 그 윗줄에서 build라고 적어주기 때문에 안적어줘도 되는 것 같음
=> (추가)백슬래시 부분 : (백슬래시)는 이스케이프 문자입니다! YAML 파일은 줄바꿈을 하면 줄바꿈한 문자열을 그대로 YAML 문법에 의거해 해석할 가능성이 있기 때문에(앞에 --가 붙어서 리스트라고 읽을 가능성도 있음) \ 를 붙여줘서 --도 \ 이스케이프 문자를 통해 그냥 문자열로 인식하게 만들어서 한 줄로 읽게끔 하는 것이라고 생각하시면 될 것 같다고 알려주심
=> (추가)sync 와 cp에 대한 차이점 : ync 옵션과 cp 옵션은 aws s3 버킷을 올릴 때의 옵션이라고 생각하면 됨 (github과는 연관이 없다고 함) 관련 컬럼 https://www.learnaws.org/2022/03/01/aws-s3-cp-sync/
YAML 은 데이터 직렬화 언어로 JSON 의 상위호환용으로 요즘 많이 쓴다고 함
특히 설정 파일에 사용하기 좋아서 spring boot, github action 등 다양한 CI/CD 툴이나 프레임 워크에서 이용
원활하게 사용하려면 별도의 문법을 숙지해야 함
#를 이용해서 주석처리 가능---문서의 시작...문서의 끝- 들여쓰기 : 기본적으로 2칸 or 4칸 지원 (스페이스로 키로 들여써야 함)
key: value: 키와 밸류 표현,:다음에 무조건 공백 문자가 있어야 함- 추가 참고
https://subicura.com/k8s/prepare/yaml.html#%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%E1%84%86%E1%85%AE%E1%86%AB%E1%84%87%E1%85%A5%E1%86%B8
Github Action으로 클라이언트 CI/CD 구축한 배포 링크
S3 정적 웹페이지 링크
http://fe-27-julyk9.s3-website.ap-northeast-2.amazonaws.com/
레퍼런스
