Github Action 사용법 (with ECR)

GitHub Docs에 따르면, GitHub Actions는 코드의 빌드, 테스트 및 배포 과정을 자동화할 수 있는 CI/CD 플랫폼으로, 개발자가 코드 변경 사항을 빠르고 효율적으로 통합하고, 다양한 환경에 배포할 수 있도록 지원한다. 이를 통해 전체 소프트웨어 개발 주기를 간소화하고, 팀 협업과 코드 품질을 향상시킬 수 있다.

 

CI/CD

핵심 키워드인 CI/CD에 대해 자세하게 알아보기 전에 DevOps에 대해 간단하게 알아보자.

DevOps는 시스템 개발자와 운영을 담당하는 정보기술 전문가 사이의 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 개발 방법론이다. 즉, 개발과 운영의 간극을 줄이기 위해 탄생한 Development와 Operations를 합친 개념이다. 이 DevOps 엔지니어의 핵심 업무가 CI/CD인 것이다.

 

[그림 1] CI/CD

CI/CD는 CI(Continuous Integration)와 CD(Continuous Delivery & Continuous Deployment) 를 종합한 개념이다. CI는 어플리케이션의 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합되는 것을 의미한다. CD는 Continuous Delivery와 Continuous Deployment라는 두 개의 뜻을 가지고 있습니다. 지속적인 서비스 제공 혹은 지속적인 배포라는 의미이다.

 

여기서 주의할 것은 앞서 말한 DevOps와 CI/CD는 다른 개념이다. DevOps는 비즈니스 조직과 IT 조직의 협업을 강화하기 위해 나온 개념이다. DevOps 문화의 목표는 고객과 비즈니스를 위한 지속적인 혁신이다. 반면 CI/CD는 DevOps를 하기위한 툴이다. CI/CD 파이프라인을 구축해야 DevOps가 실현될 수 있다.

 

CI가 필요한 환경은 다음과 같다.

1. 다수의 개발자가 형상관리 툴을 공유하여 사용하는 환경 – github을 예시로 들면, 기능 추가 시 commit을 하여 레포지토리에 버전 업데이트를 하는데, 기능별로 빌드/테스트/병합이 번거롭다. 자동화된 빌드와 테스트는 소스코드의 충돌을 방어하는 혜택을 제공할 수 있다.
2. MSA(Micro Service Archietcture) 환경 – MSA는 하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐를 의미한다. MSA 환경에서는 대부분 애자일 방법론이 적용되기 때문에, 기능 추가가 매우 빈번하게 발생된다.

 

CD에서도 마찬가지로 MSA와 같은 환경에서 에자일 방법론이 적용될 경우, 서비스의 사용자는 최대한 빠른 시간 내에 최신 버전의 Production을 제공받을 필요가 있다.

 

[그림 2] CI/CD 툴

 

CI/CD 대표적인 툴로는 Jenkins, Travis CI, Github Actions가 있다.

 

이 중에 접근성이 가장 좋고, 적응도 쉬운 Github Actions에 대해 소개하려 한다. GitHub는 무료로 코드 저장소를 만들 수 있기 때문에 CI/CD 서비스 대비 진입장벽이 낮은 편이다. 소프트웨어 workflow를 자동화하기 위해 사용된다. 이런 workflow와 같이 코어 개념이 6개가 존재한다.

Github Actions 코어 개념

- Workflows: 하나 이상의 작업을 포실행하는 구성 가능한 자동화 프로세스
- Events: workflow를 트리거하는 사용자 지정 이벤트
- Jobs: workflow에서 하나의 처리 단위
- Steps: 작업의 구성 단위로, Job은 하나 이상의 step으로 구성
- Actions: 자주 반복되는 작업을 용이하도록 하기 위한 작업 공유 매커니즘
- Runners: 트리거될 때 workflow를 실행하는 서버

 

Workflow는 YAML 파일을 통해 설정할 수 있다. .github/workflows 폴더 아래에 YAML 파일이 위치해야 Workflow를 인식한다. Workflow는 on 이라는 키값을 통해서 워크폴로우의 트리거를 설정할 수 있다. 이 명령어는 누군가 코드 저장소에 변경 사항을 Push하거나, Pull Request 하거나 Merge 같은 기능을 수행할 때 트리거로 작용할 수 있고, 어떤 브랜치에서인지까지 세세하게 설정할 수 있다.

 

Github Actions Hands-on

Github Action을 이용하여 AWS ECR에 이미지를 올리는 실습을 진행해보자.

 

먼저 AWS ECR 레포지토리를 생성해보자.

[그림 3] Elastic Container Registry

[그림 4] ECR Repository 생성

다음으로 Github Action을 위한 IAM User를 생성하여 AmazonEC2ContainerRegistryFullAccess 정책 추가해보자.

[그림 5] IAM 생성

[그림 6] IAM 권한 부여

발급된 IAM의 AccessKey와 SecretKey를 발급하여 Github에 넣어보자.

[그림 7] IAM 액세스 키 생성

AccessKey와 SecretKey를 워크플로 파일에 직접 입력하는 것은 절대 해서는 안 된다. 이는 보안상 매우 위험한 행동이다. 보안을 강화하기 위해, 반드시 GitHub Settings에서 해당 키들을 Secrets에 저장하여 사용하는 것을 강력히 권장한다. 이를 통해 민감한 정보가 외부에 노출되는 것을 방지할 수 있다.

[그림 8] Settings에서 키 입력

 

이제, 제일 중요한 Workflow를 작성해보자.

name: Docker image push to ECR

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    name: Build and push Docker image
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Set up Python 3.9
        uses: actions/setup-python@v2
        with:
          python-version: 3.9

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Push Docker image to Amazon ECR
        env:
          REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          REPOSITORY: acc-khu
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $REGISTRY/$REPOSITORY:$IMAGE_TAG .
          docker push $REGISTRY/$REPOSITORY:$IMAGE_TAG

name 옵션은 직관적으로 **"Docker image push to ECR"**로 설정하였다. on 옵션은 main 브랜치에 push 이벤트가 발생할 때 트리거되어 아래의 jobs가 실행되도록 설정했다. 이제 jobs를 자세히 살펴보자.

먼저, build 옵션에서 실행 환경으로 ubuntu-latest를 설정하였다. 이는 Ubuntu가 설치된 환경에서 작업이 이루어지며, 이후 모든 명령어는 Ubuntu의 셸에서 실행된다. 이번 GitHub Actions는 간단한 테스트 목적으로 작성되었으며, FastAPI로 구현된 코드이다. 따라서 Python 3.9 버전을 설치하고, 필요한 dependency들을 설치해준다.

그다음, AWS 자격 증명 설정이 필요하다. AccessKey와 SecretKey는 GitHub Settings에 미리 저장해둔 값을 ${{ secrets.<key> }} 형식으로 불러와 사용하면 자동으로 적용된다.

이제, 내가 생성한 ECR 리포지토리에 Docker 이미지를 푸시해야 하므로, 리포지토리 이름을 동일하게 설정하고, region 값도 정확하게 작성해야 한다. 마지막으로, run 옵션을 사용해 빌드한 Docker 이미지를 ECR에 푸시하면, ECR에 정상적으로 이미지가 업로드된 것을 확인할 수 있다.

[그림 9] GitHub Actions 성공

여기까지 핸즈온을 진행해 보았다. 이 단계에서 더 나아가면, ECR에 업로드된 Docker 이미지를 바탕으로 EC2 인스턴스에서 바로 컨테이너를 실행할 수 있다. 그러나 오늘의 주요 목표는 GitHub Actions를 활용하는 것이었기 때문에, ECR 업로드까지만 진행했다.

이번 과정을 통해 CI/CD의 중요성을 다시 한번 느꼈으며, 더욱 효율적인 개발자가 되기 위해 지속적으로 노력할 것이다. 이러한 CI/CD 파이프라인은 한 번만 익혀두면 다른 프로젝트에서도 계속해서 적용해나갈 수 있다.