GitHub Actions으로 배포 자동화해 보기(a.k.a CI/CD) – 2화

CI/CD가 뭐냐고요? 쉽게 말해 개발자가 개발을 마치고, 애플리케이션을 빌드하고, 테스트를 하고, 원격 저장소에 코드를 업데이트하고, 이를 배포하는 등의 전 과정을 자동화하는 과정을 말합니다. 대부분의 실무 환경에서는 CI/CD를 진행하죠. 여기서는 깃허브 액션을 활용하여 CI/CD를 진행해봅니다.

본 글은 ‘GitHub Actions으로 배포 자동화해 보기’의 2편으로 깃허브 액션 스크립트를 작성하여 CI/CD를 구현하고, 정상적으로 작동하는지 확인해보겠습니다. CI/CD가 무엇인지, 깃허브 리포지터리 생성 및 코드를 푸시하는 방법이 궁금하시다면 ‘GitHub Actions으로 배포 자동화해 보기-1편‘을 참고해주세요.

 

1. 깃허브 액션 스크립트 작성하기, CI

이제 깃허브에 리포지토리가 준비되었으니 깃허브 액션 스크립트를 작성해 CI를 구현하겠습니다.

 

1단계

프로젝트 최상단에 .github 디렉터리를 만들어줍니다. 그 안에 workflows 디렉터리를 다시 만들고 ci.yml 파일을 생성해 다음 스크립트를 작성합니다.

workflow가 아니라 workflows입니다.

 

 

# 1 워크플로의 이름 지정
name: CI

# 2 워크플로가 시작될 조건 지정
on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest # 3 실행 환경 지정
    #4 실행스텝지정
    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-java@v3
        with:
          distribution: 'zulu'
          java-version: '17'

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Build with Gradle
        run: ./gradlew clean build

 

❶ 워크플로의 이름을 지정합니다. 이 워크플로는 CI를 실행하기 위한 스크립트의 모음이므로 CI 라고 지정했습니다. ❷ 워크플로를 시작할 트리거 조건을 지정합니다. main 브랜치에 푸시를 할 때마다 워크플로를 시작하도록 작성했습니다. ❸ 리눅스나 윈도우와 같은 실행 환경을 지정합니다. ❹ 실행 스텝을 그룹화 합니다. 각 항목은 별도의 작업(uses) 또는 명령어(run)로 이루어졌습니다.

 

▼ 실행 스텝 그룹화 정리

 

 

2단계

추가된 파일을 원격 저장소에 올리기 위해 커밋, 푸시를 진행하고 깃허브 리포지터리의 [Action] 메뉴에 들어가 CI가 실행되는 것을 확인합니다.

$ git add .
$ git commit -m "CI 추가"
$ git push origin main

이 화면이 보이고 워크플로가 성공적으로 동작하면 초록색 체크 모양으로 표시됩니다. 여기까지 확인한 뒤에 CD 스크립트를 추가하겠습니다.

 

 

2. 깃허브 액션 스크립트 작성하기, CD

1단계

현재 프로젝트에서는 빌드를 진행하면 총 두 개의 jar 파일이 생깁니다. 하나는 일반 jar 파일이고 다른 하나는 plain이라는 접미사가 붙은 jar 파일입니다.

이 jar 파일은 플레인 아카이브(plain archive)라고 하며 애플리케이션 실행에 필요한 의존성을 포함하 지 않고 소스 코드의 클래스 파일과 리소스 파일만 포함합니다. 따라서 플레인 아카이브만으로는 서비스를 실행할 수 없으므로 빌드 시에 일반 jar 파일만 생성하도록 그레이들 파일을 변경하겠습니다.

▼ build.gradle

... 생략 ...
 jar {
   enabled = false
}

 

 

2단계

깃허브 액션 스크립트에서 만든 ci.yml 파일 이름을 cicd.yml로 변경하고 다음 코드를 추가합니다.

name: CI/CD # 1 깃허브 액션 이름 변경

on:
 push:
    branches: [ main ]

jobs:
 build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-java@v3
        with:
          distribution: 'corretto'
          java-version: '17'

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew


      - name: Build with Gradle
        run: ./gradlew clean build

      #2 현재시간가져오기
      - name: Get current time
        uses: josStorer/get-current-time@v2.0.2
        id: current-time
        with:
           format: YYYY-MM-DDTHH-mm-ss
           utcOffset: "+09:00"

      # 3 배포용 패키지 경로 저장
      - name: Set artifact
        run: echo "artifact=$(ls ./build/libs)" >> $GITHUB_ENV

      # 4 빈스토크 배포
      - name: Beanstalk Deploy
      uses: einaregilsson/beanstalk-deploy@v20
      with:
        aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        application_name: springboot-developer
        environment_name: springboot-developer-env
        version_label: github-action-${{steps.current-time.outputs.formattedTime}} region: ap-northeast-2
        deployment_package: ./build/libs/${{env.artifact}}

 

❶ 깃허브 액션 이름을 CI에서 CI/CD로 변경합니다. ❷ josStorer/get-current-time 플러그인을 사용해 현재 시간을 가져옵니다. 가져온 시간은 배포 버전을 지정할 때 사용됩니다. ❸ 빌드 이후에 생성된 jar 파일을 찾아 “artifact”라는 환경 변수에 값을 넣어줍니다. $GITHUB_ ENV를 사용해 깃허브 워크플로 전체적으로 사용할 수 있는 환경 변수를 설정할 수 있습니다. ❹ einaregilsson/beanstalk-deploy 플러그인을 사용해 빈스토크 배포를 진행합니다. 여기에서 지정한 secrets.AWS_ACCESS_KEY_ID와 secrets.AWS_SECRET_ACCESS_KEY는 깃허브 액션에서 가져오는 비밀값입니다. 이 값은 AWS에서 만든 뒤 깃허브에서 설정해야 합니다. 또한 애플리케이션 이름(application_name)과 환경 이름(environment_name)은 일래스틱 빈스토크에서 확인할 수 있습니다.

 

 

 

3단계

IAM은 AWS 리소스를 사용하도록 권한을 부여하는 서비스입니다. AWS에 접속한 뒤 IAM 서비스를 검색해 접속한 다음 [사용자]를 클릭합니다. 그런 다음 [사용자 추가] 버튼을 눌러 사용자를 추가합니다. 사용자 이름은 github-action으로 지정합니다.

 

 

4단계

[다음]을 눌러 나온 권한 설정에서는 [직접 정책 연결]을 선택한 뒤 AdministratorAccess- AWSElasticBeanstalk를 검색해 선택합니다. 이 권한은 빈스토크를 사용하기 위해 필요한 모든 관리 권한을 사용자에게 제공하는 권한입니다. AdministratorAccess 권한은 너무 광범위하기 때문에 정말 필요한 권한만 주는 것이 좋지만 진행의 편의를 위해 해당 권한을 사용하겠습니다.

 

 

 

5단계

사용자 생성을 마치고 github-action 사용자를 눌러 액세스 키를 만듭니다. 조금만 스크롤바를 내리면 액세스 키 항목의 [액세스 키 만들기] 버튼을 찾을 수 있습니다. [서드 파티 서비스]를 선택하 고 [다음]을 누르고 ‘설명 태그 값’을 github-action으 로 해 액세스 키를 만드세요.

 

이 값들은 절대로 노출되면 안 되는 값이 므로 깃허브 리포지토리와 같은 공간에 올리지 않도록 주의해야 합니다.

 

 

6단계

그러면 액세스 키가 만들어집니다. 이 화면을 넘기지 마세요. 액세스 키는 이 화면에서 딱 한 번 확인할 수 있습니다. 값을 미리 복사하거나 [.csv 파일 다운로드]를 눌러 보관해주세요.

 

 

7단계

복사한 값을 등록하기 위해 깃허브 리포지토리에 접속한 뒤 [Settings → Secrets and variables → Actions] 순서로 메뉴에 들어갑니다. 그 이후에 [New repository secrets] 버튼 을 눌러 새로운 비밀 키를 각각 등록합니다.

 

 

8단계

깃허브에 커밋, 푸시를 하기 전에 민감한 값을 삭제하겠습니다. application.yml 파일 을 열어 비밀값으로 정의한 client-id와 client-secret, 그리고 jwt 항목을 삭제하세요.

 

 

9단계

cd가 정상적으로 작동하는 것을 확인하기 위해 커밋과 푸시를 차례대로 수행하고 확인합니다. 깃허브 액션이 성공하는 것을 확인할 수 있습 니다. 실제로 배포가 되었는지 확인하기 위해 빈스 토크의 최근 배포 날짜와 시간을 확인해보세요. 앞 으로 작업을 한 뒤 리포지터리에 업로드하면 깃허브 액션이 빌드를 자동으로 실행하고, 빌드에 성공하면 새 버전을 빈스토크에 배포할 겁니다.

$ git add .
$ git commit -m "ci.yml > cicd.yml"
$ git push origin main

깃허브 액션에서 ‘Error: Deployment failed: Error: Environment still has health Yellow 30 seconds after update finished!’라는 메시지가 나올수도있지만실습에는크게영향을주지않으므 로 이대로 마무리해도 좋습니다.

 

 

3. 결론

깃허브 액션을 사용해 코드가 변경될 때마다 자동으로 빌드되고 배포하는 방법을 실습했습니다. 이번 장에서 배운 깃허브 액션 플러그인 이외에도 사용할 수 있는 플러그인이 매우 많으니 적절하 게 사용하면 개발 생산성을 크게 올릴 수 있습니다. CI/CD는 실무에서 많이 사용하는 개념이니 꼭 이해해두는 게 좋습니다.