Github Actions - softeerbootcamp-3rd/Team2-iFive GitHub Wiki

Github Actions

Github Action은 github에서 공식적으로 제공하는 CI/CD 툴이다.
다시 말해 개발의 work flow를 자동화할 수 있게 도와주는 툴이다.

Jenkins의 단점

  • 젠킨스는 플러그인을 최신상태로 유지해야한다.
  • 동일한 빌드환경에서 일관성을 제공하지 않음.
  • 여러 플러글인에 의존해야함

Github Actions 장점

  • 간편한 설정
  • 서버 설치가 불필요

Docker Run으로 구성되기때문에 build와 run만을 필요로해서 실행과 디버깅이 쉽다.

GitHub Actions는 많은 언어와 프레임워크를 지원하고 있고, YAML로 작성할 수 있다. 따라서 일반적인 코드를 작성하듯 편집, 재사용, 공유, 포킹할 수 있다.
레포지토리를 포킹하면 작업이 자동으로 포킹되기 때문에 GitHub과 함께 사용하는 것이 매우 쉽게 느껴진다.

깃허브 Action를 클릭하게되면 최상위 폴더에 .yml파일이 생기게 된다.

.gitub / workflow 폴더는 항상 최상위에 위치하여야 한다.

깃허브 액션즈는 해당 yml파일을 보고 CD작업을 수행한다.


문법

on

  • 트리거
  • 해당 워크플로우가 실행되는 트리거를 지정합니다.
  • push 는 push가 발생했을때, pull_request 는 pull_request 가 발생했을 때 트리깅합니다.
  • wokflow_dispatch 는 버튼을 클릭해서 수동으로 이벤트를 시작시킬 수 있습니다.

jobs

  • 워크플로우에서 실행되는 모든 작업을 그룹화

build

  • build라는 이름의 작업을 정의합니다.

steps

  • 작업에서 실행되는 모든 단계를 함께 그룹화합니다.

uses

  • 해당 step에서 사용할 액션. Github 마켓플레이스에 올라온 action들을 사용할 수 있다.
  • checkout 은 git 관련된 명령등을 수행할 수 있게 해준다

CD 구성하기

현재 작성된 gradle.yml파일은 다음과 같다.

on:
  push:
    branches: [ "be" ]
  pull_request:
    branches: [ "be" ]

...

jobs:
  build:

    runs-on: ubuntu-latest
    permissions:
      contents: read

    steps:
    - uses: actions/checkout@v4
    - name: JDK 17세팅
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'

    - name: properties 설정
      run: |
        cd BE/iDrop
        mkdir -p ./src/main/resources/env
        echo touch ./src/main/resources/env/mysql.yml
        echo "${{ secrets.MYSQL_INFO }}" > ./src/main/resources/env/mysql.yml

    - name: gradlew 실행 권한 설정
      run: |
        ...

    - name: AWS credential 설정
      uses: aws-actions/configure-aws-credentials@v1
      with:
        ...

    - name: S3 업로드
      run: ...

...

workflow는 다음과 같다.

  1. 사용할 JDK를 세팅 후, 사용할 스프링 properties파일을 삽입하도록 한다.
  2. Gradle실행 권한을 설정 후 build를 시작한다.
  3. AWS IAM Key를 이용하여 S3에 ZIP파일을 업로드 후 code Deploy를 통해 EC2로 파일 다운 후 deploy.sh를 실행한다.

유의해야 할 점은 현재 모노리포지토리 전략 사용으로 인해 FE와 BE폴더를 나누어 작업을 하고 있다.
배포해야 할 백엔드 서버는 BE폴더에 위치하고, 이에따라 배포 브랜치는 be branch이다.

해당 명령어들은 .yml파일이 최상위에 위치하기 때문에 cd를 이용하여 현재 작업중인 위치를 이동시켜주거나, 파일의 fullPath를 기술하여 실행하도록 해야한다.

이와 관련한 발생한 오류들은 트러블 슈팅에 기술한다.

appspec.yml

appspec.yml은 Code Deploy가 볼 수 있는 파일이다.
appspec.yml은 인스턴스에 S3파일을 복사 이후에 CodeDeploy가 실행시킬 파일이다.

CodeDeploy의 Event LifeCycle은 다음과 같다.

image

위와 같은 순서대로 Event들이 실행된다. 이 순서는 CodeDeploy에서 이미 정해 놓은 순서이고, 각각을 Event Hook 이라고 한다.

appspec.yml 작성

files

files:
  - source: /
    destination: /home/ubuntu/
    overwrite: yes

source: 인스턴스에 복사할 수정된 파일 또는 디렉터리를 설정합니다.

  • 해당 경로는 appspec.yml 파일 기준 상대경로입니다.

destination: 인스턴스에서 파일이 복사되어야 하는 위치를 식별합니다.

overwrite: 선택 값으로, 동일한 파일이 있을 경우 덮어쓰기 여부를 작성합니다.

permissions permissions 섹션은 files 섹션에서 정의한 파일이 인스턴스에 복사된 후 해당 파일에 권한이 어떻게 적용되어야 하는 지를 지정합니다.

permissions는 EC2/온프레미스에만 사용되므로 AWS Lamda/ECS 배포는 resources 섹션 을 참조할 수 있습니다.

permissions:
  - object: /home/ubuntu/
    owner: bvoat
    group: ubuntu
    ...

hooks

hooks:
   deployment-lifecycle-event-name:
     - location: script-location
       timeout: timeout-in-seconds
       runas: user-name

각 실행 주기별 실행할 이벤트, 경로를 작성합니다.


실행이 완료된 이후 S3에 파일이 위치함을 볼 수 있다.

image

Code Deploy로 설정한 EC2로 배포와 실행이 완료됨을 확인할 수 있다.

image


함께 보면 좋은 자료

- AppSpec 'hooks' section