Github Actions로 CD 구축하기

[JJ503]

CI/CD 란?

CI

• 지속적인 통합, Continuos Integration
• 애플리케이션의 버그 수정이나 새로운 코드 변경이 주기적으로 빌드 및 테스트 되며, 공유되는 레파지토리에 통합되는 것

CD

• 지속적 제공 || 배포, Continuous Delivery || Deployment
• CI 이후 배포 단계로, 배포를 수동적으로 진행하는 경우가 Continuous Delivery
• CI 이후 배포 준비가 완료 됐을 때 자동으로 배포를 진행하는 경우가 Continuous Deployment

CI/CD를 어떻게 구축할 수 있을까?

Jenkins

• Jenkins란?

  • 소프트웨어 빌드, 테스트, 배포 등과 관련된 모든 종류의 작업을 자동화하는 데 사용할 수 있는 오픈 소스 자동화 서버
  • 가장 많이 사용되는 CI/CD 도구
  • 웹 기반의 콘솔로 사용 및 설정이 편리함
  • 무료로 사용이 가능하며, 여러 플러그인이 존재해 기능 확장이 쉬움
  • 러닝 커브가 낮으며 범용성이 높음

• 단점

  • 서버의 리소스를 초과해 사용한다면, CI/CD 작업 도중 서버가 다운될 수 있음
  • 장애로 인해 서비스가 내려가면, Git Webhook 이벤트를 받을 수 없음
  • 사용 중이지 않을 때도 메모리를 잡아먹어 불필요한 비용이 발생함
  • 깃허브 접근을 위해 자격증명을 위한 설정이 필요함

Github Actioins

• Github Actions란?

  • Github에서 제공하는 빌드, 테스트, 구축 파이프라인을 자동화할 수 있는 CI/CD 플랫폼
  • Github Hosted Runner 설치를 통해 원하는 환경을 구성할 수 있음
    • Self Hosted Runner를 통해 원하는 서버와 연결도 가능함
  • 추가적인 설치 과정 없이 Github에서 제공하는 환경에서 CI/CD 진행을 할 수 있음
  • Github에 접근 할 때 자격증명이 따로 필요하지 않음
  • Github 마켓플레이스를 통해 다른 사람이 작성한 파이프라인을 사용할 수 있음
  • CI/CD 과정을 모두 Github 페이지에서 확인할 수 있음

• 단점

  • Private Repository의 경우 요금이 발생함 (Public Repository는 무료)
  • Github Hosted Runner를 통해 새로운 환경을 구축하는 경우, 서버 장애 발생 혹은 리소스 초과와 같은 문제를 개발자가 직접 해결해야 함
  • Jenkins보다 오래 걸림

블루밍에서 사용할 CI/CD 툴 및 이유

• Github Actions을 사용할 예정
• Jenkins를 사용하기엔 프리티어 용 EC2의 리소스가 부족함, 계정을 여러 개 만들기에도 부담이 됨 (Github Actions가 너무 불편하면 계정을 만들어서라도 추가할 것)
• CI/CD 툴이 있는 서버가 다운될 위험은 없음
• Github와의 연동이 쉬움 (특히, 서브모듈)
• ec2의 self hosted runner 외에도 Github Hosted Runner를 사용할 수 있기에, 빌드 등에 대해 ec2에서 수행할 필요가 없어 한정된 자원인 상황에서 더 적절할 것으로 판단
• Github Actions의 단점은 오래 걸린다는 문제인데 캐싱을 통해 어느정도 해소할 수 있을 것이라 생각
• 이미 Github Actions를 사용해본 경험이 있기에 러닝 커브가 아주 높지 않을 것으로 예상됨

Github Actions 스크립트 간단 설명

용어 설명

• workflow
  • 자동화된 전체 프로세스를 의미함
  • 하나 이상의 Job으로 구성되며, Event에 의해 예약되거나 트리거될 수 있는 자동화된 절차
• event
  • workflow가 트리거되는 특정 활동이나 규칙
  • on 속성을 통해 설정할 수 있음 (트리거 이벤트 참고 자료)
  • ex) 커밋 푸시, pr 요청 등
• job
  • 워크플로우가 실행되면 수행할 일
  • 여러 Step으로 구성되는 단일 가상 환경에서 실행됨
  • 독립된 환경에서 돌아가는 하나의 처리 단위를 의미함
  • runs-on과 steps 속성을 통해 실행할 내용을 정의함
• runs-on
  • Jobs를 실행할 러너 즉, 환경을 정의함
  • Github Actions에서 제공하는 러너 혹은 Self Hosted Runner 등을 사용할 수 있음
• steps
  • Jobs에서 순차적으로 실행되는 프로세스 단위
  • 명령(shell script)을 내리거나, actions을 실행할 수 있음
• action
  • Github Action에서 미리 정의한 스크립트로, 커스텀 Action이나 서드 파티에서 제공하는 Action을 수행할 수 있음

Github Actions을 통한 CD 구축하기

이번 글에서는 개발 서버의 CD를 수행하는 workflow로 수행해볼 예정입니다.

• .github 디렉터리 하위에 workflows 디렉터리 생성 후 해당 디렉터리에 workflow 파일들을 만들어주기
  

• dev-cd.yml 스크립트 작성

  • 구상하는 플로우
    1. develop 브랜치에 push될 때 트리거됨
    2. Job의 환경 설정
    3. Github Submodule 사용 옵션 설정
    4. Github Hosted Runner를 통한 빌드 수행
    5. Github Hosted Runner에서 빌드된 jar 파일을 개발 서버로 전달
    6. 개발 서버에서 자동 배포 스크립트 수행
    7. 배포 실행 결과에 대해 Slack에 알림

develop 브랜치에 push될 때 트리거됨

• pr이 develop 브랜치에 머지될 때 트리거되고 싶음

  즉, devleop 브랜치에 커밋이 push될 때 트리거 되면 됨

• 아래와 같이 설정

  • workflow_dispatch : 수동 트리거

  on:
      workflow_dispatch:
    push:
      branches:
        - develop

2. Job의 환경 설정

• 환경은 ubuntu-22.04로 실제 개발 서버와 동일한 환경으로 만들어 줌
  

jobs:
  build:
    runs-on: ubuntu-22.04

3. Github Submodule 사용 옵션 설정

• develop 브랜치를 체크아웃할 때 서브 모듈 사용 옵션을 설정해줘야 함 (checkout action 참고 자료)

• 깃허브 설정의 secrets 탭에서 GITHUB_TOKEN을 설정할 수 있음

  GITHUB_TOKEN은 서브모듈에 접근이 가능한 계정에 대한 토큰을 사용해야 한다

- name: checkout branch
  uses: actions/checkout@v3
  with:
    token: ${{ secrets.GITHUB_TOKEN }}
    submodules: true

4. Github Hosted Runner를 통한 빌드 수행

• 빌드를 위해 JDK 17 버전 설치

• 애플리케이션 빌드

  • 이때, 빌드는 bootJar로 수행함

    → CI를 통해 테스트 등에 대한 검증은 모두 완료했다 가정하기에 jar 빌드에만 집중하기 위해 해당 방식으로 진행, 이를 통해 더 빠른 속도로 빌드할 수 있다

• 캐싱 처리를 통해 매번 새롭게 환경을 구축하지 않아도 되도록 한다

- name: Set up JDK 17
  uses: actions/setup-java@v3
  with:
    java-version: '17'
    distribution: 'corretto'

- name: cache gradle
  uses: actions/cache@v3
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
    restore-keys: |
      ${{ runner.os }}-gradle-

- name: chmod gradle
  run: chmod +x ./

- name: build application
  run: ./gradlew bootJar

5. Github Hosted Runner에서 빌드된 jar 파일을 개발 서버로 전달

• strip_components: source path 중 복사되는 기준 경로

  → 원래 scp 명령어 수행 시 source의 경로를 그대로 복사하는데, 경로를 어디서 부터 사용할지에 대해 설정하는 옵션

- name: scp to dev server
  uses: appleboy/scp-action@master
  with:
    username: ubuntu
    host: ${{ secrets.DEV_PUBLIC_IP }}
    key: ${{ secrets.DEV_PRIVATE_KEY }}
    source: "./build/libs/*.jar"
    target: "/home/ubuntu"
    strip_components: 2

6. 개발 서버에서 자동 배포 스크립트 수행

- name: deploy application
  uses: appleboy/ssh-action@master
  with:
    username: ubuntu
    host: ${{ secrets.DEV_PUBLIC_IP }}
    key: ${{ secrets.DEV_PRIVATE_KEY }}
    script: |
      sudo /home/ubuntu/deploy.sh

7. 배포 실행 결과에 대해 Slack에 알림

- name: send result to slack
  uses: 8398a7/action-slack@v3
  with:
    status: ${{ job.status }}
    author_name: Github Action CD
    fields: repo,message,commit,author,action,eventName,ref,workflow,job,took
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
  if: always()

전체 코드

name: Dev Server CD

on:
  workflow_dispatch:
  push:
    branches:
      - develop

jobs:
  build:
    runs-on: ubuntu-22.04
    steps:
      - name: checkout branch
        uses: actions/checkout@v3
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          submodules: true

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'corretto'

      - name: cache gradle
        uses: actions/cache@v3
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-

      - name: chmod gradle
        run: chmod +x ./

      - name: build application
        run: ./gradlew bootJar

      - name: scp to dev server
        uses: appleboy/scp-action@master
        with:
          username: ubuntu
          host: ${{ secrets.DEV_PUBLIC_IP }}
          key: ${{ secrets.DEV_PRIVATE_KEY }}
          source: "./build/libs/*.jar"
          target: "/home/ubuntu"
          strip_components: 2

      - name: deploy application
        uses: appleboy/ssh-action@master
        with:
          username: ubuntu
          host: ${{ secrets.DEV_PUBLIC_IP }}
          key: ${{ secrets.DEV_PRIVATE_KEY }}
          script: |
            sudo /home/ubuntu/deploy.sh

      - name: send result to slack
        if: always()
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
          author_name: Github Action CD
          fields: repo,message,commit,author,action,eventName,ref,workflow,job,took
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

---

참고 자료

Jenkins vs GitHub Action vs Tekton

워크서버개발팀의 GitHub Actions 적용기

GitHub Actions으로 배포 자동화해 보기(a.k.a CI/CD) - 2화 - 골든래빗

Github Action 에서 Submodule 설정 방법