간단한 CI/CD 파이프라인 구축으로 심플하게 일하기 (feat. GitHub Actions)

들어가며

CI/CD 란?

• 지속적 통합 (CI)

• 지속적 배포 (CD)

CI/CD Tool 비교 분석

GitHub Actions 🥇

• 장점
• 통합성 : GitHub 리포지토리와 높은 통합성 제공
• 사용 용이성 : YAML 파일로 Config 설정

• 단점인 듯 단점 아닌 장점 같은 단점
• 비용 및 제한된 리소스 : 무료 플랜은 월 2,000분까지 무료. 그 이상은 추가 비용 지불 필요

• 총평
• 코드 변경 시 자동으로 워크플로우 트리거가 가능한 점이 가장 메리트. 또한 YAML 파일로 설정을 관리 할 수 있어 직관적이고 간단한 운영 가능. 무료 플랜에서는 리소스 제한이 존재하지만 월 2,000분까지 사용할 정도의 작업량이 아니라고 판단하여 문제 없을 것으로 확인

AWS CodeBuild, CodeDeploy, CodePipeline 🥈

• 장점
• 통합성 : AWS 서비스와 높은 통합성, 다양한 AWS 리소스와 쉽게 연동 가능
• 확장성 : AWS 의 다른 서비스와 연동하여 확장성 뛰어남
• 관리형 서비스 : 인프라 관리 필요 없음. AWS에서 자동으로 스케일링 관리

• 단점
• 비용 : 사용량에 따른 비용 발생
• 러닝 커브 : AWS 서비스들 간의 연동 및 설정이 처음에 다소 복잡

• 총평
• GitHub Actions를 사용하기 위해 회사 계정 secret key를 GitHub에 저장해두는 것이 너무나 무서워서 찾아본 AWS 코드 삼형제. 보안적인 측면에서는 1등이었으나 자동화하고자 하는 작업(수정한 코드를 GitHub에 반영하는 시점에 맞추어 S3에 해당 파일을 업로드하는 명령어 실행)에 비해 무거운 점+ 굳이 비용 지불이라는 점이 아쉬워 탈락

AWS Lambda

• 장점
• 서버리스 : 서버 관리 필요 없으며 이벤트 기반 동작
• 비용 효율성 : 사용한 만큼만 지불
• 확장성 : AWS Lambda는 자동 스케일링

• 단점
• 제한된 실행 시간 : 최대 15분의 실행 시간 제한 존재
• 상태 관리 어려움 : 상태를 유지하는 작업에 부적합

• 총평
• 위와 동일한 이유로 탈락

Jenkins

• 장점
• 유연성 : 다양한 플러그인을 통해 높은 유연성과 확장성 제공
• 커뮤니티 : 오픈 소스 프로젝트로서 큰 커뮤니티와 많은 리소스 제공
• 자체 호스팅 : 자체 호스팅이 가능하여 모든 설정과 데이터를 직접 관리 가능

• 단점
• 복잡성 : 설치 및 유지 관리 복잡
• 인프라 관리 : 자체 호스팅이므로 인프라 직접 관리

• 총평
• 위와 동일한 이유로 탈락
 

Cron job + Custom Script 🥉

• 장점
• 단순성 : 간단한 작업 스케줄링과 실행에 적합
• 비용 : 비용들지 않으며 기본적인 시스템 자원 활용

• 단점
• 유연성 부족 : 복잡한 파이프라인 구현하기에 제한적
• 관리 : 에러 처리 및 로깅, 모니터링 어려움
• 확장성 : 대규모 프로젝트에 적합하지 않음

• 총평
• 단순성과 비용이 들지 않는 부분에서 높은 점수를 부여하였지만 수정한 파일을 GitHub에 업로드한 시점에 맞추어 S3파일 업로드 명령어를 실행시켜야 하는 타이밍을 구현하고 운영하는 리소스 보다 GitHub Actions를 도입하는 것이 더 효율적이라 판단. 즉, 관리의 어려움으로 탈락

GitHub Actions 적용기

1️⃣ S3 접근 가능한 AWS IAM 생성

• AmazonS3FullAccess, AWSCodeDeployFullAccess, deny-delete-s3-bucket

2️⃣ GitHub Secrets에 Secret Key를 환경변수로 저장

3️⃣ 워크플로 디렉토리 생성 및 YAML 파일 작성

• .github/workflow/deploy.yml

# 워크플로 이름 지정 
name: Deploy to AWS S3 
on: # 워크 플로 트리거 이벤트 지정
  push:
    branches:
      - master # master 브랜치에 push될 때 트리거되도록 설정

# 하나 이상의 작업 정의 
jobs: 
  deploy:
    runs-on: ubuntu-latest # 작업이 실행될 환경

		# 작업 내에서 실행될 단계 지정
    steps: 
      - name: Checkout source code
        uses: actions/checkout@v3
        with:
          fetch-depth: 2

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-1

      - name: Get list of changed files
        id: changes
        run: |
        
	        git diff --name-only HEAD~1 HEAD > changed_files.txt
	        cat changed_files.txt

      - name: Upload to S3
        run: |
        
	        while IFS= read -r file; do
	            if [ -f "$file" ] && [[ "$file" != .github/* ]] && [[ "$file" != config/* ]]; then
	            aws s3 cp "$file" "${{ secrets.S3_BUCKET }}/$file"
	            fi
	        done < changed_files.txt 

• 작업 내에서 실행될 단계 Steps 설명
1. Checkout source code
• 빌드, 테스트, 배포 등 작업을 수행하기 위해 GitHub 리포지토리에 있는 소스 코드를 워크플로가 실행되는 가상 머신이나 컨테이너 환경으로 가져와 사용할 수 있도록 준비
• 소스코드를 체크아웃 할 때 커밋 내역을 최소 2개 이상 가져오기
• 이후 단계에서 이전 커밋과 현재 커밋을 비교할 때 필요한 커밋 개수가 최소 2개이기 때문에
2. Configure AWS credentials
• AWS 사용자 인증 단계
3. Get list of changed files
• 이전 커밋과 현재 커밋을 비교하여 변경된 스크립트 파일만 S3에 업로드 해야하기 때문에 변경된 파일 목록은 changed_files.txt 에 담기
• 위의 1. Checkout source code 단계에서 fetch-depth를 지정해주지 않으면 에러 발생
4. Upload to S3
• changed_files 에서 빈칸을 기준으로(IFS=) 한 줄씩 읽어와 file 변수에 저장
• read : 입력을 받아 변수에 저장
• -r 옵션 : 백슬래시를 escape 문자로 처리하지 않기 위함
• 아래 3가지 조건을 모두 만족하는 경우에만 S3 버킷에 복사
• 변경된 파일이 존재할 때
• 해당 파일이 .github/* 경로에 위치하지 않을 때
• 해당 파일이 config/* 경로에 위치하지 않을 때
• 대괄호 안에 조건문 명시시 꼭 앞 뒤로 한 칸씩 띄워주기 ⭐
• aws sync 를 사용할 경우 변경되지 않은 모든 파일들까지 일괄적으로 매번 재업로드하기 때문에 aws cp 선택

4️⃣ Push 후 Actions 성공 여부 확인

마치며