CI/CD 구축과 GitHub Actions를 활용한 자동 배포

원도훈·2024년 11월 29일
aws
1

소프트웨어 개발의 효율성과 품질을 높이기 위해 CI/CD (Continuous Integration/Continuous Deployment)는 필수적인 요소로 자리 잡았습니다. 이 블로그에서는 CI/CD의 개념과 중요성, GitHub Actions를 활용한 CI/CD 환경 구축 방법, 그리고 AWS IAM을 통한 보안 관리까지 포괄적으로 다루어 독자가 스스로 처음부터 끝까지 자동 배포 환경을 구축할 수 있도록 안내합니다.

목차

  1. CI/CD란 무엇인가?
  2. CI/CD 환경을 구축하는 이유
  3. CI/CD의 작동 과정
  4. GitHub Actions 소개
  5. GitHub Actions를 사용한 CI/CD의 아키텍처와 흐름
  6. IAM (Identity and Access Management) 이해하기
  7. GitHub Actions를 활용한 CI/CD 구축 방법
  8. 결론

1. CI/CD란 무엇인가?

CI/CD는 소프트웨어 개발 및 배포 프로세스를 자동화하고 최적화하는 일련의 방법론과 도구를 의미합니다. CI는 Continuous Integration(지속적 통합), CD는 Continuous Delivery(지속적 전달) 또는 Continuous Deployment(지속적 배포)를 의미합니다.

  • Continuous Integration (지속적 통합): 개발자가 작성한 코드를 주기적으로 버전 관리 시스템에 통합하여 빌드 및 테스트 과정을 자동화하는 것입니다. 이를 통해 코드의 통합 과정에서 발생할 수 있는 충돌이나 오류를 조기에 발견하고 수정할 수 있습니다.
  • Continuous Delivery (지속적 전달): CI 과정을 통해 빌드된 코드를 자동으로 스테이징 환경에 배포하여 실제 운영 환경에 배포 가능한 상태를 유지하는 것입니다. 이를 통해 배포 프로세스를 신속하고 안정적으로 수행할 수 있습니다.
  • Continuous Deployment (지속적 배포): 지속적 전달의 연장선으로, 스테이징 환경을 거친 코드를 자동으로 실제 운영 환경에 배포하는 것입니다. 모든 코드 변경 사항이 자동으로 배포되므로 배포 과정이 더욱 신속해집니다.

CI/CD는 개발 주기의 효율성을 높이고, 오류를 조기에 발견하며, 소프트웨어의 품질을 향상시키는 데 기여합니다.

2. CI/CD 환경을 구축하는 이유

CI/CD 환경을 구축하는 주요 이유는 다음과 같습니다:

  • 빠른 피드백: 코드 변경 시 즉각적인 빌드 및 테스트를 통해 오류를 신속하게 발견하고 수정할 수 있습니다.
  • 자동화된 프로세스: 수동 작업을 줄이고 자동화된 빌드, 테스트, 배포 과정을 통해 인적 오류를 최소화합니다.
  • 일관성 있는 배포: 자동화된 배포로 환경 간 일관성을 유지하여 배포 과정에서 발생할 수 있는 문제를 줄입니다.
  • 개발 속도 향상: 자동화된 파이프라인을 통해 개발 주기를 단축시키고, 새로운 기능이나 수정 사항을 빠르게 사용자에게 제공할 수 있습니다.
  • 협업 강화: 여러 개발자가 동시에 작업할 때 코드 통합 과정을 원활하게 만들어 협업 효율을 높입니다.

3. CI/CD의 작동 과정

CI/CD의 일반적인 작동 과정은 다음과 같습니다:

  1. 코드 커밋 (Commit):
    • 개발자가 코드 변경 사항을 버전 관리 시스템(Git 등)에 커밋합니다.
  2. 지속적 통합 (Continuous Integration):
    • 코드가 푸시(push)되면 CI 도구가 자동으로 빌드(build) 과정을 시작합니다.
    • 빌드 과정에서 코드가 컴파일되고, 의존성이 설치되며, 테스트가 실행됩니다.
  3. 테스트 자동화 (Automated Testing):
    • 단위 테스트, 통합 테스트, 기능 테스트 등이 자동으로 수행되어 코드의 안정성을 검증합니다.
  4. 지속적 전달 (Continuous Delivery):
    • 테스트를 통과한 코드는 스테이징(staging) 환경에 자동으로 배포됩니다.
    • 이 단계에서는 실제 운영 환경과 유사한 환경에서 추가적인 검증이 이루어집니다.
  5. 지속적 배포 (Continuous Deployment):
    • 지속적 전달을 통해 검증된 코드는 자동으로 실제 운영 환경에 배포됩니다.
    • 배포 과정에서 모니터링 및 롤백 전략이 함께 적용됩니다.
  6. 모니터링 및 피드백 (Monitoring & Feedback):
    • 운영 환경에서 애플리케이션의 성능과 안정성을 모니터링하고, 사용자 피드백을 수집하여 지속적인 개선에 반영합니다.

4. GitHub Actions 소개

GitHub Actions는 GitHub에서 제공하는 CI/CD 도구로, 개발자가 직접 워크플로우(workflows)를 정의하여 코드의 빌드, 테스트, 배포 과정을 자동화할 수 있게 해줍니다. 주요 특징은 다음과 같습니다:

  • 워크플로우 정의: YAML 파일을 사용하여 다양한 이벤트(푸시, 풀 리퀘스트 등)에 반응하는 자동화 작업을 정의할 수 있습니다.
  • 액션(Action) 재사용: GitHub Marketplace에서 제공하는 수많은 액션을 활용하거나, 직접 커스텀 액션을 만들어 사용할 수 있습니다.
  • 호스팅된 러너: GitHub에서 제공하는 호스팅된 러너(Runner)를 사용하여 다양한 운영체제에서 작업을 실행할 수 있습니다.
  • 매트릭스 빌드: 여러 환경(예: 다양한 OS, Node.js 버전 등)에서 동시에 빌드를 수행할 수 있습니다.
  • 비용 효율성: 공개 저장소는 무료로 사용할 수 있으며, 개인 저장소의 경우에도 사용량에 따라 요금이 부과됩니다.

5. GitHub Actions를 사용한 CI/CD의 아키텍처와 흐름

GitHub Actions를 사용한 CI/CD의 일반적인 아키텍처와 흐름은 다음과 같습니다:

  1. 이벤트 트리거 (Event Trigger):
    • 코드 푸시(push), 풀 리퀘스트(pull request), 태그 생성(tag) 등 특정 이벤트가 발생하면 워크플로우가 시작됩니다.
  2. 워크플로우 정의 (Workflow Definition):
    • .github/workflows/ 디렉토리에 YAML 파일로 워크플로우를 정의합니다.
    • 워크플로우는 여러 개의 잡(Job)으로 구성될 수 있으며, 각 잡은 여러 단계(Step)를 포함합니다.
  3. 잡(Job) 및 단계(Step) 실행:
    • 각 잡은 특정 환경(예: Ubuntu, Windows, macOS)에서 실행됩니다.
    • 단계는 셸 명령어 실행, 액션 사용, 스크립트 실행 등으로 구성됩니다.
  4. 액션(Action) 사용:
    • GitHub Marketplace에서 제공하는 액션을 사용하거나, 직접 작성한 액션을 사용하여 특정 작업을 수행합니다.
    • 예를 들어, 코드 체크아웃, 의존성 설치, 빌드, 테스트, 배포 등이 있습니다.
  5. 결과 보고 및 피드백:
    • 워크플로우 실행 결과가 GitHub UI에 표시되며, 성공 또는 실패 여부를 확인할 수 있습니다.
    • 실패 시, 로그를 통해 원인을 분석하고 수정할 수 있습니다.
  6. 배포 단계:
    • 빌드 및 테스트가 성공하면, 자동으로 스테이징 또는 프로덕션 환경에 배포할 수 있습니다.
    • 예를 들어, AWS S3, AWS EC2, Kubernetes 클러스터, 서버리스 플랫폼 등에 배포할 수 있습니다.
  7. 모니터링 및 알림:
    • 배포 후 애플리케이션의 상태를 모니터링하고, 필요 시 알림을 받을 수 있습니다.
    • GitHub Actions 자체에서 이메일, Slack, 기타 통합 도구와 연동하여 알림을 설정할 수 있습니다.

아키텍처 다이어그램 예시:

[GitHub Repository]
       |
       | (Push Event)
       v
[GitHub Actions Workflow]
       |
       |-- [Checkout Code]
       |-- [Install Dependencies]
       |-- [Run Tests]
       |-- [Build]
       |-- [Deploy to AWS S3]
       |-- [Invalidate CloudFront]
       |
       v
[Deployment Environment (AWS)]

6. IAM (Identity and Access Management) 이해하기

IAM (Identity and Access Management)은 클라우드 서비스(AWS, Azure, GCP 등)에서 사용자, 그룹, 역할, 권한을 관리하는 서비스입니다. 주요 기능은 다음과 같습니다:

  • 사용자(User): 클라우드 리소스에 접근할 수 있는 개별 계정입니다. 각 사용자는 고유한 자격 증명(예: 비밀번호, 액세스 키)을 가집니다.
  • 그룹(Group): 여러 사용자를 하나의 그룹으로 묶어 일괄적으로 권한을 부여할 수 있습니다.
  • 역할(Role): 특정 작업을 수행할 수 있는 권한을 정의한 집합으로, 사용자나 서비스가 필요할 때 임시로 역할을 맡아 사용할 수 있습니다.
  • 정책(Policy): JSON 형식으로 작성되며, 사용자, 그룹, 역할에 부여할 수 있는 권한을 명시합니다. 예를 들어, 특정 S3 버킷에 대한 읽기/쓰기 권한 등을 정의할 수 있습니다.
  • 멀티팩터 인증(MFA): 보안을 강화하기 위해 사용자가 로그인할 때 추가적인 인증 단계를 요구할 수 있습니다.

IAM의 중요성:

  • 보안 강화: 최소 권한 원칙(Principle of Least Privilege)을 적용하여 사용자가 필요한 리소스에만 접근할 수 있도록 제한합니다.
  • 액세스 관리: 사용자 및 서비스의 접근 권한을 중앙에서 관리하고, 변경 사항을 추적할 수 있습니다.
  • 컴플라이언스 준수: 규제 요구사항을 충족하기 위해 접근 제어 정책을 엄격하게 적용할 수 있습니다.
  • 운영 효율성: 역할 기반 접근 제어(Role-Based Access Control, RBAC)를 통해 권한 부여를 자동화하고 관리할 수 있습니다.

7. GitHub Actions를 활용한 CI/CD 구축 방법

이제 GitHub Actions를 활용하여 CI/CD 환경을 구축하는 구체적인 단계를 살펴보겠습니다. 이 가이드를 따라하면 독자는 자신만의 자동 배포 파이프라인을 설정할 수 있습니다.

7.1. 사전 준비

  • GitHub 계정 및 저장소: GitHub에 계정이 있고, 자동 배포를 설정할 프로젝트 저장소가 필요합니다.
  • AWS 계정: AWS S3와 CloudFront를 사용할 계획이라면 AWS 계정이 필요합니다.
  • AWS IAM 사용자 생성: 배포에 사용할 IAM 사용자와 필요한 권한을 설정해야 합니다.

7.2. GitHub 저장소 설정

  1. 저장소 생성 또는 기존 저장소 사용:
    • GitHub에 로그인하고, 새 저장소를 생성하거나 기존 저장소를 엽니다.
  2. 프로젝트 코드 준비:
    • 배포할 프로젝트 코드를 로컬에서 준비하고, GitHub 저장소에 푸시(push)합니다.
    • 예시로, React 애플리케이션을 사용할 수 있습니다.

7.3. AWS IAM 사용자 생성 및 권한 부여

  1. IAM 사용자 생성:

    • AWS Management Console에 로그인하고, IAM 서비스로 이동합니다.
    • "사용자 추가"를 클릭하고, 사용자 이름을 입력한 후, "프로그래밍 방식 액세스"를 선택합니다.

  2. 권한 설정:

    • "기존 정책 직접 연결"을 선택하고, 필요한 권한을 포함한 정책을 선택합니다. 예를 들어, S3 및 CloudFront에 대한 접근 권한을 가진 커스텀 정책을 생성하여 연결할 수 있습니다.
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:DeleteObject",
        "s3:ListBucket",
        "s3:PutObject",
        "s3:Sync"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "cloudfront:CreateInvalidation",
      "Resource": "arn:aws:cloudfront::your-account-id:distribution/your-distribution-id"
    }
  ]
}

  3. 자격 증명 확인:

    • 생성된 Access Key ID와 Secret Access Key를 안전하게 보관합니다. 이후 GitHub Secrets에 추가해야 합니다.

7.4. GitHub Secrets 설정

  1. GitHub 저장소로 이동:

    • 자동 배포를 설정할 GitHub 저장소로 이동합니다.

  2. Settings > Secrets and variables > Actions로 이동:

    • "New repository secret"을 클릭합니다.

  3. Secrets 추가:

    • AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY라는 이름으로 앞서 생성한 IAM 사용자의 Access Key와 Secret Key를 각각 추가합니다.

7.5. GitHub Actions 워크플로우 파일 작성

이제 GitHub Actions 워크플로우 파일을 작성하여 CI/CD 파이프라인을 정의합니다.

  1. 워크플로우 파일 생성:

    • GitHub 저장소의 루트 디렉토리에 .github/workflows/ 폴더를 생성합니다.
    • 예를 들어, deploy.yml 파일을 생성합니다.

  2. 워크플로우 파일 내용 작성:

    name: Deploy To S3 And Invalidate CloudFront

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: GitHub Repository 가져오기
        uses: actions/checkout@v3

      - name: 의존성 설치
        run: npm install

      - name: 빌드하기
        run: npm run build

      - name: AWS 인증 설정
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: ap-northeast-2
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - name: S3 기존 파일들 전체 삭제
        run: |
          aws s3 rm --recursive s3://wdohoon

      - name: 빌드된 파일 S3에 업로드
        run: |
          aws s3 sync ./build s3://wdohoon

      - name: CloudFront 무효화
        run: |
          aws cloudfront create-invalidation --distribution-id YOUR_DISTRIBUTION_ID --paths "/*"

    설명:

    • 이벤트 트리거: main 브랜치에 푸시(push) 이벤트가 발생하면 워크플로우가 실행됩니다.
    • 잡(Job) 정의: deploy 잡은 ubuntu-latest 환경에서 실행됩니다.
    • 단계(Steps):
      • 코드 체크아웃: actions/checkout@v3 액션을 사용하여 저장소의 코드를 가져옵니다.
      • 의존성 설치: npm install 명령어로 프로젝트의 의존성을 설치합니다.
      • 빌드: npm run build 명령어로 프로젝트를 빌드합니다.
      • AWS 인증 설정: aws-actions/configure-aws-credentials@v1 액션을 사용하여 AWS 자격 증명을 설정합니다.
      • S3 기존 파일 삭제: aws s3 rm --recursive s3://wdohoon 명령어로 S3 버킷의 기존 파일을 모두 삭제합니다.
      • 빌드된 파일 S3에 업로드: aws s3 sync ./build s3://wdohoon 명령어로 빌드된 파일을 S3 버킷에 동기화합니다.
      • CloudFront 무효화: aws cloudfront create-invalidation 명령어로 CloudFront 배포를 무효화하여 변경 사항을 반영합니다.

    주의사항:

    • YOUR_DISTRIBUTION_ID를 실제 CloudFront 배포 ID로 교체해야 합니다.
    • S3 버킷 이름 wdohoon을 실제 사용 중인 버킷 이름으로 변경해야 합니다.

  3. 워크플로우 파일 커밋 및 푸시:

    • 작성한 deploy.yml 파일을 커밋하고, main 브랜치에 푸시합니다.
    git add .github/workflows/deploy.yml
git commit -m "Add CI/CD workflow for deploying to S3 and CloudFront"
git push origin main

7.6. 배포 확인

  1. GitHub Actions 실행 확인:

    • GitHub 저장소의 "Actions" 탭으로 이동하여 방금 푸시한 커밋에 대한 워크플로우 실행 상태를 확인합니다.
    • 모든 단계가 성공적으로 완료되었는지 확인합니다.

  2. AWS S3 및 CloudFront 확인:

    • AWS Management Console에 로그인하고, S3 버킷에 빌드된 파일이 업로드되었는지 확인합니다.
    • CloudFront 배포의 무효화 상태를 확인하여 최신 파일이 배포되었는지 확인합니다.

  3. 웹사이트 접근:

    • CloudFront 배포 도메인을 통해 웹사이트에 접근하여 최신 버전이 정상적으로 배포되었는지 확인합니다.

8. 결론

CI/CD는 소프트웨어 개발과 배포의 효율성을 크게 향상시킬 수 있는 중요한 방법론입니다. GitHub Actions는 이러한 CI/CD 프로세스를 손쉽게 구현할 수 있는 강력한 도구를 제공하며, IAM은 이러한 자동화된 프로세스가 안전하게 동작할 수 있도록 필수적인 보안 관리 기능을 제공합니다. 이 가이드를 따라 GitHub Actions를 활용한 CI/CD 환경을 구축하면, 고품질의 소프트웨어를 빠르고 안전하게 배포할 수 있습니다.

자동화된 배포 파이프라인을 통해 개발자는 코드 작성에 집중할 수 있으며, 배포 과정에서 발생할 수 있는 오류를 최소화할 수 있습니다. 또한, CI/CD를 통해 팀 간 협업이 원활해지고, 제품의 품질과 사용자 경험을 향상시킬 수 있습니다.

지금 바로 CI/CD 환경을 구축하여 효율적인 개발과 안정적인 배포를 경험해 보세요!

참고 자료:

profile
원도훈
개발
이전 포스트

DNS

다음 포스트

Git Branch 전략

0개의 댓글