GitHub Actions로 CI/CD 구축 #1

artp·2024년 9월 20일
CI/CDawsgithubgithub actions

CI/CD

목록 보기
4/9
post-thumbnail

GitHub Actions

CI/CD를 구축하기 위한 툴 중 하나로 GitHub Actions가 있습니다. 이 툴은 무료로 사용할 수 있으며, 별도의 빌드 서버를 구축할 필요가 없다는 장점 때문에 현업에서 널리 사용됩니다. 또한, GitHub 레포지토리와의 통합이 원활해 설정과 관리가 간편합니다.
이 외에도 많이 사용되는 CI/CD 툴로는 Jenkins(젠킨스)가 있으며, Jenkins는 오픈소스 툴로서 다양한 플러그인을 통해 유연하게 CI/CD 파이프라인을 구성할 수 있습니다.
CI/CD 흐름에서 GitHub Actions는 빌드, 테스트, 배포에 대한 로직을 실행할 수 있는 일종의 컴퓨터라고 생각하면 됩니다.

CI/CD 흐름

CI/CD의 구성 방식은 다양하지만, 일반적으로 아래와 같은 흐름을 따릅니다.

  • Develop: 새로운 기능이나 수정 사항을 개발합니다.
  • Commit: 코드 변경 사항을 커밋하여 버전 관리 시스템에 반영합니다.
  • Build: 커밋된 코드를 빌드합니다. 이 과정에서 코드를 컴파일하고, 필요한 라이브러리나 의존성을 설정합니다.
  • Test: 빌드가 완료되면, 작성된 테스트 코드가 있는 경우 자동으로 테스트를 실행해 코드의 안정성을 확인합니다.
  • Deploy: 테스트가 성공하면, 해당 코드를 실제 서버에 배포하여 사용자에게 최신 버전이 제공됩니다.

특정 기능을 개발 완료한 후, 코드를 커밋하면 빌드가 자동으로 진행됩니다. 빌드가 완료된 후에는 테스트 코드가 실행되며, 모든 테스트가 통과되면 최신 코드가 실제 서버에 배포됩니다. 이와 같은 CI/CD 파이프라인은 코드 배포를 자동화하여 개발 효율성을 크게 높여줍니다.

CI/CD 실습 #1

EC2 인스턴스 생성

실습을 위한 AWS EC2를 하나 생성합니다. EC2 구성 시 유형을 프리티어인 t2.micro가 아닌 t3a.small을 선택합니다. 이는 프리티어 유형으로 스프링부트 프로젝트 배포 시 메모리 부족으로 인한 멈춤 현상이 발생할 수 있기 때문입니다.

프로젝트 생성 및 워크플로 파일 추가

실습을 위한 스프링 프로젝트를 생성 후 깃허브에 올리고, 프로젝트 내부에서 GitHub Actions 워크플로 작성을 위한 디렉터리를 추가해 줍니다. 그리고 아래와 같이 워크플로 파일 내용을 작성합니다.

워크플로 내용 설명

# 워크플로 이름
name: Deploy To EC2

# main 브랜치에 push 될 때 워크플로 실행
on:
  push:
    branches: 
    - main
  • 워크플로 이름을 설정하고, 언제 이 워크플로가 실행될지 정하는 명령어입니다.
jobs:
  # Job의 고유 ID 값
  Deploy:
    # ubuntu-latest 환경에서 job 실행
    runs-on: ubuntu-latest
    # step: 특정 작업을 수행하는 가장 작은 단위
    steps:
      - name: SSH(원격 접속)로 EC2에 접속
      # EC2에서 자동 배포를 위해 appleboy/ssh-actions@v1.0.3 라이브러리 사용
      uses: appleboy/ssh-action@v1.0.3
with:
  host: ${{ secrets.EC2_HOST }}
  username: ${{ secrets.EC2_USERNAME }}
  key: ${{ secrets.EC2_PRIVATE_KEY }}
  • 깃허브 리포지토리 - Settings - Secrets and variables - Actions에 설정한 시크릿 값을 사용합니다.
  • secrets.EC2_HOST 는 EC2의 주소를 의미합니다.
  • secrets.EC2_USERNAME 은 EC2의 접속 username을 의미합니다.
  • secrets.EC2_PRIVATE_KEY 는 EC2의 Key 파일의 내부 텍스트를 의미합니다. EC2 생성 시 발급한 키 페어 .pem 파일의 내부 내용을 가져와 추가하면 됩니다.
script_stop: true
script: |
  cd /home/ubuntu/test-server
  git pull origin main
  ./gradlew clean build
  sudo fuser -k -n tcp 8080 || true
  nohup java -jar build/libs/*SNAPSHOT.jar > ./output.log 2>&1 &
  • script_stop: true 는 아래 스크립트 중 실패하는 명령이 하나라도 있으면 실패로 처리한다는 의미입니다.
  • cd /home/ubuntu/test-server 는 본인이 생성한 EC2의 경로입니다.
  • git pull origin main 명령어로 최신 수정 사항을 가져와 병합합니다.
  • ./gradlew clean build 명령어로 프로젝트를 다시 빌드합니다.
  • sudo fuser -k -n tcp 8080 || true 에서 || true 를 붙인 이유는 8080 포트에서 종료할 프로세스가 없더라고 실패로 처리하지 않기 위함입니다.
  • nohup java -jar build/libs/*SNAPSHOT.jar > ./output.log 2>&1 & 명령어는 jar 파일을 실행하고, 발생하는 로그들을 ./output.log 파일에 기록하는 명령어입니다.

GitHub Actions에서 Secrets 추가

아래와 같이 깃허브에서 워크플로에 사용할 secrets를 설정합니다.

자동 배포 확인

이후 코드를 수정하여 깃허브에 push 후 워크플로가 잘 작동하는지 서버에 접속하여 확인해보면, 자동 배포가 잘 되고 있음을 확인할 수 있습니다.

CI/CD 실습 #2

.gitignore에 application.yml 추가

  • 프로젝트 .gitignore에서 application.yml 파일을 추가합니다.
    application.yml 파일에는 데이터베이스 자격 증명, API 키, 비밀 토큰 등 노출해서는 안 되는 민감한 정보들이 포함되므로, 이를 Git에 포함하지 않도록 주의해야 합니다.
    따라서 .gitignore 파일에 해당 파일을 추가하여 Git에 커밋되지 않도록 설정합니다.

워크플로 파일 내용 수정

아래와 같이 워크플로 내용을 수정합니다.

  • env: APPLICATION_PROPERTIES: ${{ secrets.APPLICATION_PROPERTIES }} 는 GitHub Secrets에 저장된 application.yml 내용을 환경 변수로 설정한다는 의미입니다.
  • envs: APPLICATION_PROPERTIES 는 위에서 정의한 환경 변수를 전달한다는 의미입니다.
  • rm -rf src/main/resources/application.yml 는 기존의 application.yml 파일을 삭제한다는 의미입니다.
  • echo "$APPLICATION_PROPERTIES" > src/main/resources/application.yml 는 echo로 출력된 APPLICATION_PROPERTIES의 값을 src/main/resources/application.yml 파일에 저장한다는 의미입니다. 즉, 새로운 application.yml 파일을 생성하여 그 안에 APPLICATION_PROPERTIES 값을 삽입하게 됩니다.

GitHub Secrets에서 APPLICATION PROPERTIES 추가

APPLICATION PROPERTIES에 프로젝트의 appliction.yml 파일 내용을 가져와 추가합니다. 이 과정은 노출하면 안 되는 값인 application.yml 파일의 내용을 GitHub Secrets로 추가하는 것입니다.

EC2에서 확인

프로젝트를 새로 push한 후에 깃허브 리포지토리에서 확인해보면 설정에 따라 application.yml 파일이 없는 것을 확인할 수 있습니다.

하지만 EC2 내부에서 확인해보면 워크플로 파일 설정에 따라 application.yml 파일이 생성되어 존재하는 것과 그 내용까지 확인할 수 있습니다.

application.yml 파일을 수정했을 경우 배포

application.yml 파일 내용을 수정했거나 추가한 경우에는 깃허브 Secrets에서 직접 수정한 내용으로 재작성해 주어야 합니다. 이 과정은 자동으로 처리되지 않으므로 수동으로 처리합니다.

테스트가 실패했을 경우 배포 결과

프로젝트에서 일부러 테스트를 실패하도록 코드를 작성 후 이를 깃허브에 올리게 되면 배포가 정상적으로 진행되는지 확인합니다.

  • 아래처럼 코드를 작성하여 테스트를 실패하도록 합니다.
  • 변경한 코드를 깃허브 리포지토리에 push합니다.
  • 깃허브 액션에서 결과를 확인합니다.
  • 테스트가 실패했을 경우 배포가 되지 않는 것을 확인할 수 있습니다.

해당 방식의 배포 장단점

장점

  • 빠른 업데이트: git pull을 사용하여 변경된 부분의 코드만 업데이트되므로, 전체 프로젝트를 다시 배포하는 다른 CI/CD 방식에 비해 속도가 빠릅니다. 이는 배포 시간을 줄여주어 효율적인 운영이 가능합니다.
  • 간단한 인프라: CI/CD 툴로 GitHub Actions 하나만 사용하므로, 추가적인 인프라 설정 없이 간편하게 배포 파이프라인을 구성할 수 있습니다. 이를 통해 관리 복잡도가 줄어들고 유지보수가 쉬워집니다.

단점

  • 서버 성능 저하: 빌드 작업을 EC2에서 직접 수행하기 때문에, 빌드 과정에서 서버 자원을 많이 사용하면 실제 운영 서비스 성능에 영향을 줄 수 있습니다. 특히 트래픽이 많은 상황에서는 이 부분이 큰 단점이 될 수 있습니다.
  • 보안 이슈 및 제한적인 프로젝트 적용: GitHub 계정 정보가 EC2에 저장되므로 보안 위험이 있을 수 있으며, EC2에 접근 가능한 프로젝트의 범위가 제한됩니다. 이는 다수의 협업자나 민감한 프로젝트에서 제약이 될 수 있습니다.
  • 적용 범위 한정: 이 방식은 주로 개인 프로젝트나 토이 프로젝트에서 CI/CD를 가볍고 빠르게 적용하고자 할 때 적합합니다.
profile
artp
donggyun_ee
이전 포스트

GitHub Actions + Issues, Slack 연동

다음 포스트

GitHub Actions로 CI/CD 구축 #2

0개의 댓글