AWS EC2 에 GitHub Action으로 CI/CD 해보기

https://pabeba.tistory.com/294

 

이전 시간에 AWS EC2를 구성하고 파일 업로드와 설정을 손수 진행해보았는데요.

 

이번 시간에는 GitHub Action으로 딸깍 push만 해서 AWS EC2 인스턴스에 파일을 올리고 재시작 하는 것을 해볼겁니다.

 

이전전 시간에 deploy.yml 파일에서 업그레이드하고 Github 프로젝트에 설정 조금하면 금방 CI/CD 가능합니다!

 

1. CI/CD와 GitHub Actions 개요

본격적인 코드 설명에 앞서 간단한 개념을 잡고 가겠습니다.

• CI (Continuous Integration - 지속적 통합): 개발자들이 작성한 코드를 주기적으로 중앙 저장소에 통합하고, 자동화된 빌드 및 테스트를 통해 코드의 품질을 검증하는 과정입니다.
• CD (Continuous Deployment - 지속적 배포): CI 과정을 통과한 코드를 실제 운영 환경(Production)에 자동으로 배포하는 과정입니다.
• GitHub Actions: GitHub에서 제공하는 강력한 CI/CD 도구입니다. GitHub 저장소 내에서 발생하는 이벤트(Push, Pull Request 등)를 트리거(Trigger)로 삼아 사용자가 정의한 작업(Workflow)을 실행할 수 있습니다.

💡 지식 더하기: 왜 CI/CD를 사용할까요? CI/CD를 구축하면 개발자는 코드 작성에만 집중할 수 있고, 반복적인 빌드, 테스트, 배포 작업을 자동화하여 휴먼 에러를 방지하고 배포 속도를 획기적으로 향상시킬 수 있습니다. 또한, 언제든 안정적으로 배포 가능한 상태를 유지할 수 있다는 큰 장점이 있습니다.

---

2. GitHub Actions 워크플로(Workflow) 분석

이제 실제 배포에 사용되는 .github/workflows/deploy.yml (파일명은 자유) 파일을 한 부분씩 살펴보며 기능을 설명해 드리겠습니다.

전체 소스는 여기 있어요.

https://github.com/hosose/my_project/blob/main/.github/workflows/deploy.yml

my_project/.github/workflows/deploy.yml at main · hosose/my_project

 

name: Push 기반 CI/CD 테스트

# [트리거 지정] CI/CD가 작동하게 되는 원인, 이벤트를 정의합니다.
# main 브랜치에서 push 이벤트가 발생(Listen -> on)하면 아래 설정한 내용이 작동합니다.
on:
  push:
    branches:
      - main

• name: 워크플로의 이름을 지정합니다. GitHub Actions 탭에서 이 이름으로 표시됩니다.
• on.push.branches: 파이프라인을 실행할 트리거를 정의합니다. 여기서는 main 브랜치에 코드가 push될 때만 이 워크플로가 실행되도록 설정했습니다. 실무에서는 보통 main(운영) 또는 develop(개발) 브랜치를 지정합니다.

# 개별 작업(jobs)을 순서대로 나열합니다 (파이프라인).
jobs:
  # 'ci'라는 이름의 job을 하나 설정합니다.
  ci:
    # 어떤 OS에서 job을 진행할 것인가? -> GitHub에서 클라우드 방식으로 제공합니다 (Runner).
    runs-on: ubuntu-latest

• jobs: 워크플로에서 실행될 실제 작업들을 정의합니다. 여러 작업을 병렬로 실행할 수도 있지만, 여기서는 ci라는 하나의 작업을 정의했습니다.
• runs-on: 작업이 실행될 가상 환경(Runner)의 OS를 지정합니다. ubuntu-latest는 가장 최신의 우분투 환경을 사용하겠다는 의미이며, GitHub에서 제공하는 클라우드 리소스를 사용하게 됩니다.

    # 작업 단계(steps)를 지정합니다.
    steps:
      # 1. GitHub에 저장되어 있는 최신 내용을 체크아웃합니다 (소스를 모두 내려받음).
      - name: 코드 checkout
        uses: actions/checkout@v4

• steps: 하나의 job 내에서 실행될 일련의 단계들을 순서대로 정의합니다.
• actions/checkout@v4: GitHub에서 공식적으로 제공하는 액션(Action)입니다. 현재 구동 중인 Runner OS 환경으로 GitHub 저장소의 소스 코드를 복사(Checkout)해옵니다. 이 단계가 있어야 이후 단계에서 소스 파일을 기반으로 작업을 진행할 수 있습니다.

      # 확인 or 단위테스트 (편의상 생략하고 환경 확인만 진행)
      - name: 확인 검증
        # 여러 개의 명령어를 작동시킬 때는 '|' 기호를 통해 배치로 작성합니다.
        run: |
          pwd
          ls -al
          cat main.py
        shell: bash

• run: Runner의 터미널에서 실행할 명령어를 기술합니다. 여기서는 소스 코드가 정상적으로 체크아웃되었는지 확인하기 위해 현재 경로(pwd), 파일 목록(ls -al), 그리고 메인 파일 내용(cat main.py)을 출력해봅니다.
• 실무에서는 이 단계에서 파이썬 패키지 설치(pip install) 및 단위 테스트(pytest 등)를 실행하여 코드의 이상 유무를 검증하는 CI 과정을 수행합니다.

🚀 여기서부터는 CD (Continuous Deployment) 작업입니다.

이제 검증된 소스 코드를 실제 운영 중인 AWS EC2 서버로 복사하고 서비스를 재시작하는 배포 과정을 진행합니다.

      # [CD 작업 1: 파일 복사]
      # CI 쪽 서버(Runner)에서 EC2 서버(배포용 서버)로 배포 진행 -> SSH 활용
      - name: source code copy to EC2
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.EC2_KEY }}
          port: 22
          # 복사할 대상 (편의상 . (현재 디렉토리 전체))
          source: .
          # 우분투 OS가 세팅된 EC2 서버의 대상 경로로 복사
          target: "/home/ubuntu/projects"

• appleboy/scp-action: SCP(Secure Copy) 프로토콜을 이용해 Runner에서 원격 서버로 파일을 복사해주는 서드파이 액션입니다.
• with (중요 - 보안): 접속 정보를 입력합니다. 이때 IP 주소(HOST), 사용자명(USERNAME), SSH 키(.pem 파일 내용 - EC2_KEY)와 같은 민감한 정보는 소스 코드에 직접 노출하지 않고, GitHub 저장소의 Settings -> Secrets and variables -> Actions에 저장된 Secrets 변수를 활용해 보안을 유지합니다. 도커 등에서 사용하는 환경변수(.env) 파일 내용도 시크릿 변수에 담아 배포 시 동적으로 생성할 수 있습니다.
• 보안 이슈: EC2 서버의 SSH 포트(22번)는 GitHub Action Runner가 접속할 수 있도록 보안 그룹(Security Group)에서 접근 허용이 되어 있어야 합니다. 편의상 0.0.0.0/0 (모든 IP 허용)으로 설정하기도 하지만, 보안 강화를 위해 GitHub의 서브넷 IP만 허용하는 방식이 더 권장됩니다.

      # [CD 작업 2: 서비스 재가동]
      # 파일 복사 후 서버에서 실제 서비스를 갱신하고 재시작하는 명령을 전달합니다.
      - name: Run Script And Service Restart
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.EC2_KEY }}
          port: 22
          script: |
            # 1. 프로젝트 폴더 위치로 이동합니다.
            #cd /home/ubuntu/projects
            
            # 2. 가상환경에 추가된 패키지가 있다면 설치를 진행합니다.
            #./web/bin/pip install -r requirements.txt
            
            # 3. systemd로 관리 중인 애플리케이션 서비스를 재시작합니다.
            sudo systemctl restart hello.service

• appleboy/ssh-action: SSH를 통해 원격 서버에 접속하여 명령어를 실행해주는 액션입니다.
• script: EC2 서버에 접속해서 실행할 쉘 명령어를 기술합니다.
  1. 배포된 폴더로 이동합니다.
  2. 새로 추가된 파이썬 패키지가 있다면 가상환경의 pip를 이용해 설치합니다.
  3. 리눅스 시스템 데몬(systemd)으로 관리 중인 웹 애플리케이션 서비스(hello.service)를 재시작하여 변경된 코드가 반영되도록 합니다.

💡 지식 더하기: 보안 이슈에 대한 첨언 원문의 주석에 "EC2 -> GitHub로 다시 요청 보내서 명령 실행(이 부분은 보안 이슈로 하지 않고 터미널에서 수동으로 함)"이라는 내용이 있는데, 이는 GitHub Actions의 동작 방식과 다소 차이가 있습니다. GitHub Actions는 **GitHub 측(Runner)에서 EC2로 접속하는 형태(Outbound)**이지, EC2가 GitHub에 요청을 보내는 구조가 아닙니다. 위 워크플로처럼 SSH 액션을 사용하면 GitHub 측에서 EC2에 접속해 명령어를 실행할 수 있어 완전한 자동화 배포가 가능합니다. 다만, 민감한 키(secrets.EC2_KEY)가 GitHub 측에 저장된다는 점에 대한 보안 관리(예: 주기적인 키 로테이션, 권한 최소화)가 필요합니다.

---

3. 마치며

이제 모든 설정이 완료되었습니다. main 브랜치에 코드를 push하면 GitHub Actions가 자동으로 동작하여 코드 체크아웃 -> 검증(테스트 생략) -> EC2 파일 복사 -> 서비스 재시작까지 한 번에 완료해 줍니다.

 

이렇게 구축된 CI/CD 파이프라인은 초기 세팅에 노력이 들지만, 이후 개발 생산성을 비약적으로 높여주는 강력한 도구가 됩니다. 여러분의 프로젝트에도 꼭 적용해 보시길 권장합니다!