TIL

최종 프로젝트 8일차

• 최종프로젝트 8일차, 오늘은 Docker와 Github Action을 이용한 CI/CD 구축에 대해서 공부했다.

CI/CD란 무엇일까

• 흔히, CI/CD는 DevOps 엔지니어의 핵심 업무라고 한다.
• 도대체 CI/CD가 무엇이길래 핵심 업무일까?

CI (Continuous Integration)

• CI는 Continuous Integration 즉, 지속적인 통합이라는 의미이다.
  지속적인 통합이란, 어플리케이션의 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 레포지토리에 통합히는 것을 의미한다. (가능하다면 하루에 여러번까지)
• 현재는 기능 추가 시마다 commit을 통해 repository에 업데이트를 하는데,
  개발자가 다수일 경우, repository에 수많은 commit이 쌓이게 된다.
• 기능별로 빌드/테스트/병합을 하려면 상당히 번거로울 것이다.
  이런 상황에서, 자동화된 빌드&테스트는 원천 소스코드의 충돌 등을 방어하는 장점을 제공한다.

CI의 핵심 목표는,버그를 신속하게 찾아 해결하고, 소프트웨어의 품질을 개선하고,

새로운 업데이트의 검증 및 릴리즈의 시간을 단축시키는 것에 있다.

CD (Continuous Delivery & Continuous Deployment)

• CD는 Continuous Delivery 혹은 Continuous Depolyment 두 용어 모두의 축약어이다.
• 해석하자면, 지속적인 서비스 제공 혹은 지속적인 배포 라는 의미이다.
• Continuous Delivery는 공유 레포지토리로 자동으로 Release 하는 것이고,
• Continuous Deployment는 Production 레벨까지 자동으로 deploy 하는 것을 의미한다.
  CI가 새로운 소스코드의 빌드, 테스트, 병합까지를 의미하였는데,
  CD는 개발자의 변경 사항이 레포지토리를 넘어, 고객의 프로덕션(Production) 환경까지 릴리즈 되는 것을 의미한다.

Github Actions

• CI/CD의 기능을 알아보았다. 구현만 된다면, 개발단계를 굉장히 편리하게 해주는 기능이다.
• 그렇다면 어떻게 CI/CD를 구축할 수 있을까? 이번 글은 Github Action을 통해 구축해보았다.
• GitHub Actions는 GitHub 플랫폼에서 제공하는 자동화 및 지속적 통합/지속적 배포(CI/CD) 서비스이다.
• Github Actions의 구성 요소는 Workflow, Event, Jobs, Actions가 있다.
• Workflow
  • 한개 이상의 job을 실행할 수 있는 자동화된 작업
  • yaml 파일로 저장되며 event에 의해 실행 된다.
• Event
  • workflow 실행을 발동시키는 특정한 활동
  • push event, pull request event, issue event 등이 있다.
• Jobs
  • 한가지 러너안에서 실행되는 여러가지 step들의 모음
  • 각각의 step들은 일종의 shell script 처럼 실행된다.
  • Step들은 순서에 따라 실행되며 Step 끼리 데이터들을 공유할 수 있다.
  • Job은 다른 Job에 의존관계를 가질 수 있으며, 병렬 실행도 가능하다.
• Actions
  • 복잡하고 자주 반복되는 작업을 정의한 커스텀 어플리케이션
  • workflow 파일 안에서 자주 반복되는 코드를 미리 정의해 코드의 양을 줄일 수 있다.

Github Actions 적용하기

• Github Actions를 사용하기 위해서는 프로젝트 폴더의 .github/workflows/디렉토리에
  yaml 파일을 작성해주면 된다.
• yaml 파일의 구조는 다음과 같다.

name: Deploy

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v2
        with:
          java-version: '17'
          distribution: 'adopt'
      - name: Grant execute permission for gradlew
        run: chmod +x ./gradlew
      - name: gradlew bootJar
        run: ./gradlew bootJar
      - name: copy jar to server
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ec2-user
          key: ${{ secrets.SSH_KEY }}
          port: 22
          source: "./build/libs/*.jar"
          target: "~"
          strip_components: 2

      - name: SSH Commands
        uses: appleboy/ssh-action@v0.1.6
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ec2-user
          key: ${{ secrets.SSH_KEY }}
          port: 22
          script_stop: true
          script: |
            kill -9 $(ps -ef | grep java | head -n 1 | awk '{print $2}')
            nohup java -jar *.jar

• name
  • workflow의 name을 정의
  • 선택사항이며 깃허브 저장소의 깃허브 액션 탭에서 workflow의 이름을 보여준다.
• on
  • 해당 workflow를 실행시키는 이벤트를 정의
  • 위 코드에서는 main브랜치에 push 이벤트가 발생했을 때 workflow가 실행되도록 정의
• jobs
  • job의 이름을 정의(위 코드에서는 deploy)
  • runs-on : 어떤 호스트에서 실행될지 정의 - ubuntu 가상 머신에서 실행 되도록 정의
• Steps
  • uses: actions/checkout@v3 - 해당 레포지토리를 pull 받고 이동하는 action 대부분의 workflow에서 사용
  • uses: actions/setup-java@v2 - java를 설치하는 action으로 가상머신안에는 대부분의 프로그래밍 언어가 설치되어 있지 않기 때문에 프로젝트 실행에 필요한 언어들을 action을 통해 다운
  • run: ./gradlew bootJar - run 키워드를 통해 러너가 실행되는 서버에서 명령어를 실행
    (위 코드에서는 gradlew 권한 변경과 jar 파일 생성)

Github Actions를 통한 CI/CD 적용

• CI를 적용한 모습이다.
• Pull Request시 Github Actions를 통해 자동으로 테스트를 수행한다!
  
  
• CD가 적용된 모습이다.
• 상세정보를 확인해보면 AWS의 콘솔에서 빌드되는것도 확인할 수 있다!
• 적용을 하면, 이벤트가 발생할때마다 Actions 탭에서 자동으로 yml에 적힌 내용을 수행하는데,
  이것으로 상당히 많은 부분을 자동화 할 수 있었다! (테스트, 배포 등등)

오늘의 회고

오늘은 Github Actions를 사용하여 CI/CD를 구현해 보았다.
AWS에 서버를 배포해본 경험이 없었어서 모든게 새로웠는데, 게다가 이것을 자동으로 해주는게 너무 신기했다. CI/CD를 구축하기 위해 yml파일을 작성하는 수고가 들지만,
나중을 생각하면 무조건 구축하는것이 이득인 CI/CD였다.
최종 프로젝트에도 CI/CD를 적용하여 PR시 자동으로 테스트와 배포를 해주는것을 추가해봐야겠다.