[Github Action & Docker] CI / CD 배포

Event, Runner, Job, Step, Action

---

CI / CD Tool: GitHub Actions

GitHub Actions vs Jenkins 

CI / CD 툴로 유명한 것은 GitHub Action과 Jenkins가 있다. Jenkins는 별도의 Jenkins 서버를 따로 구축해야되기 때문에 무료 툴인 GitHub Action을 사용할 예정이다.

 

Why Use to GitHub Actions?

• CI / CD 간소화: 별도의 서버(Jenkins 등)를 구축할 필요 없이 GitHub에서 무료로 제공한다.
• 원활한 통합: GitHub 저장소와 자연스럽게 연동되어 자동화 및 반복적인 작업 수행에 유리함.

CI / CD 개념

• CI (Continuous Integration): 코드가 지속적으로 통합되어 빌드 및 테스트되는 프로세스.
• CD (Continuous Deployment/Delivery): 통합된 코드를 자동으로 배포하거나, 특정 시점에 배포할 수 있도록 준비하는 단계.

GitHub Actions 기본 개념

 

• Event: 작업 실행 시점을 정의하는 트리거.
• Runner: 작업을 수행하는 가상머신 또는 컨테이너.
• Job: 여러 스텝(step)으로 구성된 처리 단위
• Step: 작업의 최소 단위. 단순 명령어(Command), 스크립트(Script) 또는 액션(Action)을 포함
• Action: 재사용 가능한 스크립트 라이브러리로서, 다른 사람들이 만든 Script (재사용 및 중복 제거)

Git Actions: Workflow 구성 및 작성

Workflow 정의

• 워크플로우 (Workflow): Github Actions에서 자동화 작업을 정의하는 파일. `./github/workflows` 폴더 내에 YAML 파일로 생성.
  • 여러 개의 워크플로우 파일을 생성할 수 있다.

1. ON 속성 : Event = 작업이 언제 실행되는지 시점 정의

• 브랜치 기준: 어떤 브랜치에 어떤 액션 (Push 혹은 Pull Reqeust 등)이 발생했는지 기준으로 작업 수행

1브랜치 기준 예시: 코드 저장소의 main 브랜치에 push 이벤트가 발생할 때 마다 워크플로우를 실행한다는 조건

• 이슈 기준: 브랜치와 비슷하게 이슈가 발생된 시점, 어떤 타입으로 발생되었는지 등을 기준으로 작업 수행
• 시간 기준: cron 문법을 통해 언제 몇시 몇분 마다 수행할 것인지 스케줄에 따라 작업 수행

시간 기준 예시: 매일 자정에 워크플로우를 실행한다는 조건

 

2. JOB 속성 : Job = 작업 처리 단위

독립된 가상 머신(VM) 또는 컨테이너(Container)에서 돌아가는 하나의 처리 단위로 기본적으로 병렬로 수행한다.

• 1 Workflow : N Job
  • 하나의 워크플로우는 여러개의 Job으로 구성되며 적어도 하나의 Job은 있어야한다.

 

3. RUN-ON 속성 : Runner = Job 수행을 위한 OS(머신) 정의

• 1 Job : 1 Runner
  • Workflow마다 Runner를 정의하는게 아닌, Job 마다 Runner를 정의
    • Workflow 내 다수의 Job 각각 별개의 OS(머신) 설정 가능

 

4. STEP 속성 : 소작업 처리 단위 (Script 혹은 Action)

name: learn-github-actions
run-name: ${{ github;actor }} is learning GitHub Actions
on:  [push]
jobs:
	check-bats-version:
    	runs-on: ubuntu-latetst
        steps:
        	- uses: actions/checkout@v4
            - uses: actions/setup-node@v4
              with:
             	node-version: '20'
            - run: npm install -g bats
            - run: bats -v

• RUN: 작업 단계는 단순한 커맨드(Command)나 스크립트(Script)가 될 수도 있고,
• USES: 액션(Actions)이라고 하는 라이브러리 같은 성격의 스크립트(Script)를 가져다 사용할 수 있다.
  • 위의 예시에서 체크아웃 액션(`actions/checkout`): 코드 저장소로부터 코드를 내려받는 스크립트

방금 설명한 STEP(RUN, USES)이 포함된 Workflow 예시를 아래의 도식과 함께 이해해볼 수 있도록 하자.

수동 절차: Github Action으로 CI + 개발자가 직접 CD

• 4가지 절차만 기억해보자 !
  • Develop → Test Java → Build Java → Build Docker Image → Push → Pull → Run
  • 회색 영역: Java에 관련된 절차
  • 파란색 영역 : Docker에 관련된 절차
• CI 절차: 1. Develop → 2. Test Java → 3. Build Java → 4. Build Docker Image → 5. Push
• CD 절차: 6. Pull → 7. Run

• 3개 타입의 인스턴스: (1) Local + (2) Github Actions/ Jenkins + (3) Server
  • CI / CD 전략 혹은 인프라 구성: 각 인스턴스에 4개의 절차를 어떻게 배치할 것인가 ?
    
    1. Develop: (1) Local 에서 수행 ← 불변(고정) 절차
    2. Test Java: (1) Local 혹은 (2) Github Actions / Jenkins 에서 수행 ← 가변 절차
    3. Build Java: 위와 동일
    4. Build Docker Image: 위와 동일
    5. Push Docker Image from Registry: 위와 동일
    6. Pull Docker Image from Registry: 위와 동일
    7. Run Docker Image: (3) Server에서 수행 ← 불변(고정) 절차

+. Docker Image 업로드 방식: EC2에 Docker Image를 안착시키기 위한 방법 2가지

1. SCP: Docker Image 결과 → Tar 압축 → SCP (Secured Copy) 통해 EC2로 전달 → EC2 내 실행

2. ECR: Docker Image 결과 → ECR 업로드 → EC2 내 ECR로 부터 다운로드 → EC2 내 실행

• ECR에 업로드된 빌드 이미지는
  1. ECS를 통해 EC2와 연결하여 배포 파이프라인 구축 가능
  2. Terraform을 통해 EC2와 연결하여 배포 파이프라인 구축 가능
     • Terraform Provisioner를 통해 원하는 EC2에 접속해서 그 안에 명령어 수행 

CI 사전 준비 : 배포하고자 하는 Java 코드 작성 및 Github에 업로드

위치: Local(내 컴퓨터)

Develop your (Java) Application: Java 개발

• Docker Image는 배포횽 Java 애플리케이션을 위한 이미지로, 개발 후 GitHub Repository에 소스코드 업로드(Git Push)

추가 준비:

• GitHub Action 동작 스크립트: GitHub가 인식하도록 `.github/workflows/scriipt.yml` 위치에 스크립트 등록
• Dockerfile: GitHub Actions에서 Docker 빌드를 수행할 수 있도록 프로젝트에 Dockerfile 정의.

CI: Github 내 Java 코드를 Github Action으로 가져와 Docker 빌드

위치 : Github Action

 

1. GitHub Action 실행 트리거

• 코드가 GitHub Repository에 푸시되면, Action 스크립트가 구동되어 빌드 및 Docker 이미지를 생성.

2. GitHub Actions 스크립트 수행 절차

1. Java 테스트: Java 소스코드를 테스트 → 이번 실습에서는 해당 절차 제외.
2. Java 빌드: Gradle로 애플리케이션 빌드 (JAR 또는 WAR 생성)
3. Docker 이미지 빌드: Dockerfile을 활용해 Docker Image 생성.
4. 빌드된 Docker Image 업로드를 위한 저장소 Registry로 사용하기 위한 Docker Hub에 로그인
5. Docker Hub에 앞서 빌드한 Docker Image 업로드(Push)

Test and Build Java Application

• 앞서 개발한 Java 소스코드를 테스트 한 뒤, Java 빌드
• 앞서 언급하였든 Java 코드에 대한 테스트는 이번 실습에서 제외. Java 빌드는 Gradle을 통해 간편하게 진행

Build Docker Image and Push Docker Image to Registry

1. Build : Docker Image 생성 ← Dockerfile
   • Github에 Java 코드와 함께 올렸던 Dockerfile을 통해 Github Action은 도커 이미지를 생성
2. Push: Docker Image 업로드 → Docker registry (도커 저장소)
   • 빌드된 Docker Image 업로드를 위한 저장소 Registry로 사용하기 위한 Docker Hub에 로그인
     • Github Action 스크립트 내 민감한 정보 직접 넣으면 위험하기에 따로 설정으로 로그인 정보를 주입
     • Docker Hub의 로그인에서 아이디와 Access Token 값이 필요한데, 이건 탈취되면 안된다.

CD: AWS EC2 생성 후 내부접속하여 CI로 만든 Docker 이미지 실행

위치 : AWS EC2 = 애플리케이션(프로그램)이 구동될 서버

1. Pull: Docker Image 다운로드 ← Docker Registry (도커 저장소)
   • 개발자가 직접 AWS EC2에 접속하여, 앞서 Docker Hub에 업로드한 Docker Image 다운로드
     • 가장 먼저 AWS EC2에는 기본적으로 Docker가 설치되어있지 않기 때문에, Docker 설치를 먼저해야한다.
     • Docker Hub에서 Docker Image를 다운할 것이기에 Docker Hub에 로그인
     • 로그인 완료한 Docker Hub에서 Docker Hub에 로그인
     • 로그인 완료한 Docker Hub에서 Docker Image를 다운로드 (Pull)
2. Run: Docker Image 실행 = Container
   • 로그인 완료한 Docker Hub에서 Docker Image 다운로드 (Pull) 완료했다면 Docker Image 구동
   • Docker Container 구동 및 서버 확인

---

이어서 다음포스팅은 오늘 작성한 포스팅을 직접 실습하는 과정을 포스팅해볼 예정이다.

 

 ℹ️ 참고 

[ASAC 6기 강의자료]