Git Actions와 Docker를 이용한 CI/CD pipeline 구축

이 포스팅에서는 Docker와 Git Action을 사용하여 CI/CD를 구축합니다.

CI/CD는 지속적 통합(Continuous Integration) 및 지속적 제공/배포(Continuous Delivery/Deployment)를 의미하며, 소프트웨어 개발 라이프사이클을 간소화하고 가속화하는 것을 목표로 합니다.

• 작성한 코드를 push하고, 리모트 서버에서 pull하고 build하고 run하는 일련의 과정들을 자동화한다면, 개발자는 개발에만 집중할 수 있겠죠??
• 이렇게 push -> pull -> build -> run 하는 과정들을 하나의 파이프라인으로 구축하여 자동화하는 것을 CI/CD라고 생각하시면 되겠습니다!

CI/CD 중 지속적 통합(CI)은 코드 변경 사항을 공유 소스 코드 리포지토리에 통합하는 것을, 지속적 제공(CD)는 코드 변경사항의 통합민 제공, 배포를 나타내는 프로세스로 CI와 CD 두 가지 부분으로 구성됩니다.

조금 더 간단히 말하자면 업데이트 된 코드를 서버에 통합 하는 과정을 CI, 통합된 코드를 배포하는 과정을 CD라고 보시면 되겠습니다.

CI/CD를 구축하는 방법은 Jenkins, Travis CI 등 많은 도구들이 있지만, 이 포스팅에서는 Git Action을 사용하여 CI/CD를 구축해보려합니다.

+ 추가적으로 필자는 Docker를 사용하여 프로젝트의 이미지를 빌드하고, 컨테이너를 띄우는 방식으로 프로젝트를 배포했었는데요. Docker를 사용하여 프로젝트를 빌드하고 배포는 어떻게 했는지는 추후에 작성하도록 하겠습니다.

아키텍처 구조

로컬 코드 변경 및 Git Commit & Push

▶︎ Repository에서 Push 감지

▶︎ Docker-Compose로 프로젝트 빌드 (CI) 및 Docker hub에 빌드한 이미지 PUSH

▶︎ Git Action에서 EC2 서버 접근

▶︎ Docker hub로부터 이미지 PULL

▶︎ 빌드한 이미지로 컨테이너 구축 및 컨테이너 run (CD)

그렇게 복잡하지 않습니다. 이 과정들을 지금부터 구축해보겠습니다.

Workflow 구성요소

프로젝트의 .github/workflows 디렉토리에서 직접적으로 .yml 파일을 작성하는 방법도 있지만, 아래와 같이 Github에서 Actions탭에 들어가서 자동으로 템플릿을 만들어 주는 방법을 제공하기 때문에 이 방법을 사용하겠습니다.

Java with Gradle - Configure를 클릭하여 제공하는 템플릿 코드를 수정하면서 CI, CD를 구축할건데, Git Action의 구성요소들을 먼저 알아보겠습니다.

Workflow(yml)

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle
 
name: Java CI with Gradle
 
on:
  push:
    branches: [ "develop" ]
  pull_request:
    branches: [ "develop" ]
 
jobs:
  build:
 
    runs-on: ubuntu-latest
    permissions:
      contents: read
 
    steps:
    - uses: actions/checkout@v4
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
 
    # Configure Gradle for optimal use in GiHub Actions, including caching of downloaded dependencies.
    # See: https://github.com/gradle/actions/blob/main/setup-gradle/README.md
    - name: Setup Gradle
      uses: gradle/actions/setup-gradle@417ae3ccd767c252f5661f1ace9f835f9654f2b5 # v3.1.0
 
    - name: Build with Gradle Wrapper
      run: ./gradlew build
 
    # NOTE: The Gradle Wrapper is the default and recommended way to run Gradle (https://docs.gradle.org/current/userguide/gradle_wrapper.html).
    # If your project does not have the Gradle Wrapper configured, you can use the following configuration to run Gradle with a specified version.
    #
    # - name: Setup Gradle
    #   uses: gradle/actions/setup-gradle@417ae3ccd767c252f5661f1ace9f835f9654f2b5 # v3.1.0
    #   with:
    #     gradle-version: '8.5'
    #
    # - name: Build with Gradle 8.5
    #   run: gradle build
 
  dependency-submission:
 
    runs-on: ubuntu-latest
    permissions:
      contents: write
 
    steps:
    - uses: actions/checkout@v4
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
 
    # Generates and submits a dependency graph, enabling Dependabot Alerts for all project dependencies.
    # See: https://github.com/gradle/actions/blob/main/dependency-submission/README.md
    - name: Generate and submit dependency graph
      uses: gradle/actions/dependency-submission@417ae3ccd767c252f5661f1ace9f835f9654f2b5 # v3.1.0

• 리포지토리에 추가할 수 있는 일련의 자동화된 커맨드 집합으로 위 yml 파일을 일컬어 workflow라고 볼 수 있겠습니다.

Event

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

• Workflow가 구동시키기 위한 트리거로, 여기에 작성된 동작들이 이루어 질 때 Workflow가 구동됩니다.
• 위와 같이 push, pull_request와 같이 특정한 작업이 이루어질 때 workflow가 실행되도록 작성할 수 있습니다.
• 위 예시에서는 develop 브랜치에 push하거나 develop 브랜치에 PR을 보낼 때 이 workflow가 동작한다고 볼 수 있겠죠.

Runner

• Workflow의 동작들을 구동하기 위한 애플리케이션으로, Github에서 가상 환경을 제공하여 이 가상 환경 위에서 workflow가 구동된다고 보시면 되겠습니다.

Action

• 재사용 가능한 Workflow의 가장 작은 단위블럭으로, 직접만든 Action을 사용하거나 Github 커뮤니티에 의해 생성된 Action을 불러와 사용할 수 있습니다.
• 필자가 작성한 Workflow에서는 사용되지는 않기 때문에 이런 구성요소도 있다 정도로 알고만 넘어가셔도 좋습니다.

Step

• workflow에 작성된 실제 구동되는 커맨드들을 묶어 Step으로 관리합니다. 스탭으로 묶여서 작성된 커맨드들은 스텝 바이 스텝으로 실행되기 때문에 CI/CD에 필요한 작업들을 순차적으로 진행시킬 수 있겠습니다.

Job

• 여러 Step들의 집합을 하나의 Job으로 정의합니다.
• 보통 하나의 Workflow에 여러 Job이 있다면 각각의 Job들은 순서에 상관없이 독립적으로 실행되지만, 필요에 따라 의존관계를 설정하여 순서를 지정할 수도 있다고 합니다.
• 참고로 CI와 CD를 나누어 각각의 Job으로 설정하고, CI가 끝난 후 CD가 실행되도록 의존관계를 설정할 수도 있겠지만, 필자는 굳이 그럴 필요성이 없다고 판단하여, CI/CD과정을 하나의 Job으로 관리했습니다.

CI/CD를 위한 workflow - 0. 빌드 환경 구축

name: Java CI with Gradle
 
on:
  push:
    branches: [ "develop" ]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout
        uses: actions/checkout@v3
 
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'adopt'
 
      - name: Copy Secret
        env:
          OCCUPY_SECRET: ${{ secrets.OCCUPY_SECRET }}
          OCCUPY_SECRET_DIR: src/main/resources
          OCCUPY_SECRET_DIR_FILE_NAME: application-secret.yml
        run: echo $OCCUPY_SECRET | base64 --decode > $OCCUPY_SECRET_DIR/$OCCUPY_SECRET_DIR_FILE_NAME
 
      - name: gradlew mod modify
        run: chmod +x gradlew
 
      # gradle 캐싱 (0)
      - name: Gradle Caching
        uses: actions/cache@v3
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
           key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-
 
      # Spring Boot 어플리케이션 Build (1)
      - name: Spring Boot Build
        run: ./gradlew clean build --exclude-task test
 
      # Docker 이미지 Build (2)
      - name: docker image build
        run: docker build -t rlaehddnd0422/dnd .
 
      # DockerHub Login (3)
      - name: docker login
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
 
      # Docker Hub push (4)
      - name: docker Hub push
        run: docker push rlaehddnd0422/dnd
      
      # GET GitHub IP (5)
      - name: get GitHub IP
        id: ip
        uses: haythem/public-ip@v1.2
 
      # Configure AWS Credentials (6) - AWS 접근 권한 취득(IAM)
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2
      
      # Add github ip to AWS (7)
      - name: Add GitHub IP to AWS
        run: |
          aws ec2 authorize-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32
       
      # AWS EC2 Server Connect & Docker 명령어 실행 (8)
      - name: AWS EC2 Connection
        uses: appleboy/ssh-action@v0.1.6
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ubuntu
          password: ${{ secrets.EC2_PASSWORD }}
          port: ${{ secrets.EC2_SSH_PORT }}
          timeout: 60s
          script: |
            sudo docker stop dnd2
            sudo docker rm dnd2
            sudo docker rmi rlaehddnd0422/dnd
            sudo docker pull rlaehddnd0422/dnd
            sudo docker run -it -d -p 8080:8080 --name dnd2 rlaehddnd0422/dnd
       
      # REMOVE GitHub IP FROM security group (9)
      - name: Remove IP FROM security group
        run: |
          aws ec2 revoke-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

• 프로젝트에 CI/CD를 구축한 워크플로우 파일입니다.
• Step 별로 하나씩 어떻게 동작하는지 코드를 뜯어봅시다.

0.  Event 작성

on:
  push:
    branches: [ "develop" ]

• PR을 감지하여 PR 시에도 수행되도록 작성할 수도 있겠지만, 필자는 동일한 작업에 대해 CI CD를 PR에서 한 번, merge에서 한 번 이렇게 총 두 번 동작할 이유가 없다고 판단하여 저는 develop 브랜치에 push하는 event 발생 시에만 workflow가 동작하도록 작성하였습니다.

1. Runner 환경에 JDK 17 설치

jobs:
  deploy:
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout
        uses: actions/checkout@v3
 
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'adopt'

• Runner 애플리케이션에 우분투의 가장 최근 버전 위에서 프로젝트를 빌드하기 위해 JDK 17을 설치해줍니다.

2. 설정정보 secret 파일 주입

필자는 참고로 application.yml에 작성된 JWT 시크릿 키와 같이 보안성이 높은 코드들을 application-secret.yml로 관리했습니다. 

유출되면 안되는 코드를 사용하지 않는 경우엔 이 과정은 패스하시면 됩니다.

application.yml

jwt:
  secret_key: ${jwt.secret.secret_key}

application-secret.yml

jwt:
  secret:
    secret_key: ~~

- name: Copy Secret
  env:
    OCCUPY_SECRET: ${{ secrets.OCCUPY_SECRET }}
    OCCUPY_SECRET_DIR: src/main/resources
    OCCUPY_SECRET_DIR_FILE_NAME: application-secret.yml
  run: echo $OCCUPY_SECRET | base64 --decode > $OCCUPY_SECRET_DIR/$OCCUPY_SECRET_DIR_FILE_NAME

• 프로젝트를 빌드하기에 앞서, Git에서 관리하지 않는 보안성이 높은 코드들은 secret으로 주입시켜 줍시다.
• 먼저 주입하지 않는 경우 빌드가 제대로 이루어지지 않기 때문에, 반드시 주입을 먼저 수동으로 해줍시다.

run: echo $OCCUPY_SECRET | base64 --decode > $OCCUPY_SECRET_DIR/$OCCUPY_SECRET_DIR_FILE_NAME

▶︎ run 커맨드를 통해 인코딩된 secret 파일을 base64로 디코딩하여 SECRET_DIR 에 작성한 디렉토리에 FILE_NAME으로 세팅합니다. 

3. secret 파일 환경 변수에 세팅하기

Github에서 CI/CD를 구축할 프로젝트의 Setting 탭에서 Secrets and variables의 Actions 탭에서 Git Action에서 사용되는 환경변수를 설정할 수 있습니다.

• New Repository secret을 눌러 원하는 이름과 시크릿 값들을 설정하시면 됩니다.

• 참고로 secret 파일은 base64로 인코딩하여 설정하도록 합시다.
• 링크 참고 :  https://www.base64decode.org/

CI/CD를 위한 workflow - 1. CI 구축

- name: gradlew mod modify
  run: chmod +x gradlew
 
# gradle 캐싱 (0)
- name: Gradle Caching
  uses: actions/cache@v3
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
     key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
    restore-keys: |
      ${{ runner.os }}-gradle-

• Gradlew mod modify: Gradle 래퍼 스크립트의 권한을 수정합니다.
• Gradle Caching: Gradle 종속성을 캐싱하여 워크플로우 실행 시간을 단축합니다.

# Spring Boot 어플리케이션 Build (1)
- name: Spring Boot Build
  run: ./gradlew clean build --exclude-task test
 
# Docker 이미지 Build (2)
- name: docker image build
  run: docker build -t rlaehddnd0422/dnd .
 
# DockerHub Login (3)
- name: docker login
  uses: docker/login-action@v2
  with:
    username: ${{ secrets.DOCKERHUB_USERNAME }}
    password: ${{ secrets.DOCKERHUB_TOKEN }}
 
# Docker Hub push (4)
- name: docker Hub push
  run: docker push rlaehddnd0422/dnd

• Spring Boot Build: Spring Boot 애플리케이션을 빌드하며 테스트는 제외합니다.
• Docker 이미지 build: rlaehddnd0422/dnd 태그로 Docker 이미지를 빌드합니다.
• Docker login: 제공된 자격 증명을 사용하여 Docker Hub에 로그인합니다.
  • 여기서 제공한 자격 증명 값 또한 secret 파일처럼 환경변수로 주입해주었습니다. 과정은 동일하므로 설명 생략
• Docker Hub push: Docker 이미지를 Docker Hub에 푸시합니다.

이렇게 develop 브랜치에 push가 감지되는 경우 프로젝트를 빌드하고, 도커 이미지를 빌드하여 도커 허브에 푸쉬하는 과정인 CI과정이 완료되었습니다. 

CI/CD를 위한 workflow - 2. CD 구축

이제 리모트 서버에서 도커 허브에 있는 이미지를 pull하여 run하는 CD과정까지 구축해볼건데, 과정이 비교적 복잡하지만 잘 따라온다면 그렇게 어렵지 않습니다.

사전작업으로 먼저 Runner에서 리모트 EC2 서버에 접근할 수 있도록 하기 위해 보안그룹을 열어주어야 합니다.

EC2의 IAM Role을 통해 외부 접근 권한을 열어주기 위해 IAM Role을 생성하도록 합시다.

EC2 -> IAM 서비스 접속

사용자 생성 클릭

아래와 같이 선택 후 다음 클릭

권한 설정 - 그룹 생성

AmazonEc2FullAccess 선택 및 사용자 그룹 생성

사용자 그룹을 생성하면 아래와 같이 암호가 제공되는데, 암호는 이 때 한번만 확인할 수 있기 때문에 csv파일로 다운받아 관리하거나, 은밀한 곳에 저장해두자.

다시 사용자 탭으로 들어와 액세스 키 만들기를 클릭하여 액세스 키를 발급받도록 합시다.
용도에 맞게 발급받으면 되는데, 아무거나 해도 상관없는 듯 합니다. 필자는 첫번째 CLI로 발급받았습니다.

발급받은 ACCESS_KEY와 SECRET을 아까와 마찬가지로 프로젝트 환경변수에 세팅해주시면 됩니다.

# GET GitHub IP (5)
- name: get GitHub IP
  id: ip
  uses: haythem/public-ip@v1.2
 
# Configure AWS Credentials (6) - AWS 접근 권한 취득(IAM)
- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: ap-northeast-2

EC2에 접근하기 위한 IP를 가져오고, 위에서 등록한 id와 시크릿 값을 주입하여, AWS EC2에 접근하기 위한 IAM 권한을 얻습니다.

# Add github ip to AWS (7)
- name: Add GitHub IP to AWS
  run: |
    aws ec2 authorize-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

이제 가져온 아이피를 AWS에 접근하여 접근할 수 있도록 AWS에 해당 깃허브 아이피를 등록해주고, EC2에 접근하여 Docker 명령어 쉘을 실행하여 CD 구축할 예정입니다.

# AWS EC2 Server Connect & Docker 명령어 실행 (8)
- name: AWS EC2 Connection
  uses: appleboy/ssh-action@v0.1.6
  with:
    host: ${{ secrets.EC2_HOST }}
    username: ubuntu
    password: ${{ secrets.EC2_PASSWORD }}
    port: ${{ secrets.EC2_SSH_PORT }}
    timeout: 60s
    script: |
      sudo docker stop dnd2
      sudo docker rm dnd2
      sudo docker rmi rlaehddnd0422/dnd
      sudo docker pull rlaehddnd0422/dnd
      sudo docker run -it -d -p 8080:8080 --name dnd2 rlaehddnd0422/dnd

환경변수에 등록한 EC2 아이디와 비밀번호, 그리고 포트번호를 통해 EC2에 접근하여 docker 명령어를 통해 리모트 서버에 존재하는 기존의 이미지를 제거하고, 도커 허브에서 이미지를 pull하고 새롭게 run 합니다.

# REMOVE GitHub IP FROM security group (9)
- name: Remove IP FROM security group
  run: |
    aws ec2 revoke-security-group-ingress --group-id ${{ secrets.AWS_SG_ID }} --protocol tcp --port 22 --cidr ${{ steps.ip.outputs.ipv4 }}/32

• CD 구축이 끝났으니 Github 아이피를 보안 그룹에서 제거해줌으로써 추후 외부 접속을 막아주도록 합시다.

CI/CD 파이프라인 구축에 사용된 환경변수 정리 

• AWS_ACCESS_KEY_ID : IAM Role에서 생성한 액세스 키의 ID
• AWS_ACCESS_KEY_PASSWORD : IAM Role로 생성한 액세스 키의 PASSWORD

• AWS_SG_ID : EC2 보안그룹 ID
• DOCKERHUB_PW : 도커 허브 비밀번호
• DOCKERHUB_TOKEN : 도커 허브에서 발급받은 액세스 토큰
• DOCKERHUB_USERNAME : 도커 허브의 아이디
• EC2_HOST : AWS EC2 인스턴스의 퍼블릭 IPv4 DNS
• EC2_PASSWORD : EC2에 접근/연결 설정해두었던 패스워드 
• EC2_SSH_PORT : SSH로 접근할 port. (22)
• EC2_USERNAME : AWS EC2 인스턴스의 username
• OCCUPY_SECRET : application-secret.yml (encoded with base 64)

이렇게 이번 포스팅에서 Git Action을 사용하여 CI/CD 파이프라인을 구현하여 배포를 자동화해보았습니다.

다음 포스팅에서는 이어 Docker를 사용해 어떻게 프로젝트를 관리(빌드/배포)했는지 알아보도록 하겠습니다.

<참고자료>