What is DevOps? - Github Action

Tech story/Cloud

What is DevOps? - Github Action

kt cloud 테크블로그 2024. 11. 11. 16:10

[kt cloud DevOps팀 이효원 님]

What is DevOps? - Github Action

1. Github 구성 요소

Github은 소스 코드 관리를 넘어, 개발자와 팀이 협업하고 프로젝트를 관리하는 다양한 도구를 제공하는 플랫폼입니다.
Github은 크게 Organization, Team, Repository로 구성됩니다.

1-1. Organization

Github Organization은 여러 팀과 프로젝트를 효율적으로 관리할 수 있는 Github의 그룹 단위입니다.
기업이나 큰 팀의 경우, Organization을 생성해 프로젝트와 리소스를 통합 관리할 수 있습니다.
Organization은 다음과 같은 기능을 제공합니다.

중앙 관리: 조직 내 모든 사용자와 Repository를 중앙에서 관리할 수 있습니다.
권한 설정: 팀별로 세분화된 권한을 설정하여 특정 팀에만 Repository 접근을 허용하거나 제한할 수 있습니다.
빌링 통합: 유료 플랜에서는 모든 구성원의 사용량을 통합적으로 관리할 수 있습니다.

1-2. Team

Team은 Organization 하위에서 사용자들을 그룹으로 묶어 프로젝트 접근 권한을 관리하는 단위입니다.
Team을 통해 조직 내의 특정 Repository와 파일에 접근할 수 있는 사람을 지정할 수 있습니다.

팀별 역할 분배
: 팀마다 역할과 권한을 설정하여 A팀은 읽기만 가능하게 하고
B팀은 Pull 및 Push 권한을 부여하는 등, 구성원에 따른 Hiearachy를 설정할 수 있습니다.
효율적인 협업: 팀 단위로 Issue 및 Pull Request를 할당할 수 있어 협업과 업무 분배가 용이합니다.

1-3. Repository

Repository는 프로젝트의 소스 코드와 Issue, Pull Request, Wiki 등을 저장하고 관리하는 기본 단위입니다.
Github에서 프로젝트별로 코드를 저장하고 협업을 진행하는 공간으로,
프로젝트 관련 모든 데이터를 보관합니다.

코드 저장소: Git을 통해 프로젝트의 코드와 히스토리를 저장하고 버전 관리를 수행합니다.
Issue 및 Pull Request 관리
: 코드 리뷰, 버그 트래킹 등을 지원하여 개발 프로세스의 흐름을 체계적으로 관리할 수 있습니다.
Wiki 및 문서화: Repository 단위로 Wiki를 제공하여 작업 내용을 문서화 할 수 있습니다.

2. Github Actions

Github Actions는 Github에서 제공하는 CI/CD(지속적인 통합 및 배포) 도구로,
Github Repository에서 코드의 Build, Test, 배포를 자동화 할 수 있도록 돕습니다.

Github Actions는 Commit, Pull Request, Issue 등 이벤트가 발생할 때 트리거 되어 자동화 Workflow를 실행하는 방식으로 동작합니다.
Github Actions는 개발자들이 효율적으로 반복 작업을 줄이고 팀의 코드 품질을 높이며,
보다 빠르고 안정적으로 서비스 릴리즈를 수행할 수 있도록 지원합니다.

3. Github Actions 구성 요소

Github Actions의 Workflow를 구성하는 기본 요소에는 Action, Runner, Runner Group, Package가 있습니다.

3-1. Action

Action은 Github Actions Workflow의 개별 작업 단위를 의미합니다.
Build, Test, 코드 스타일 체크, 배포 등 다양한 작업을 Action으로 정의할 수 있으며,
여러 Action을 결합하여 하나의 Workflow를 구성합니다.

개발자 정의 가능
: Action은 직접 작성하거나, Github Marketplace에서 미리 만들어진 Action을 사용할 수 있습니다.
모듈화와 재사용성
: Action을 재사용할 수 있도록 모듈화하여 팀 내에서 효율적으로 공유하고 활용할 수 있습니다.
자주 사용되는 Action 예시
- Node.js Test 실행
- Docker 이미지 Build
- MS Azure에 애플리케이션 배포

3-2. Runner

Runner는 Github Actions Workflow에서 Action을 실행하는 컴퓨팅 리소스를 의미합니다.
Action이 정의한 작업이 Runner에서 실행되며, Github는 기본적으로 Github에서 제공하는 Runner와 사용자 정의 Runner를 지원합니다.

Github Hosted Runner
: Github에서 제공하는 클라우드 기반 Runner로,
Linux, Windows, macOS 환경을 다양한 스펙으로 제공합니다.
Self Hosted Runner
: 사용자가 직접 서버나 가상 머신을 설정해 Runner로 사용하는 방식으로,
특정 요구 사항에 맞게 커스텀 할 수 있습니다.

3-3. Runner Group

Runner Group은 여러 Runner를 그룹화함으로써 특정 Workflow에서 필요에 따라 사용할 수 있도록 지원합니다.
특히 조직 내 여러 프로젝트에서 사용하는 Runner를 그룹화 해 리소스를 공유할 때 유용합니다.
하나의 Runner Group을 지정하면 하위 다수 Runners를 스케줄링하여 작업을 할당하기 때문에
보다 안정적인 운영이 가능하다는 장점이 있습니다.

리소스 관리
: Runner Group을 사용하면 각 프로젝트나 Repository에서 사용할 수 있는 Runner를 제한할 수 있습니다.
조직 단위 활용
: 조직 내에서 Runner Group을 활용해 특정 Runner를 팀 또는 Repository에 할당함으로써
효율적으로 리소스를 관리합니다.

3-4. Package

Package는 Github Actions에서 프로젝트 Build 결과물을 저장하고 배포하는 데 사용되는 기능입니다.
Github Packages를 통해 라이브러리나 도커 이미지를 저장할 수 있으며,
버전 관리를 지원하여 CI/CD 파이프라인에서 활용할 수 있습니다.

저장소
: Github Packages는 프로젝트의 아티팩트를 저장하는 저장소 역할을 하며
Github Actions Workflow와 통합하여 Build와 배포를 자동화할 수 있습니다.
버전 관리
: 패키지 버전 관리를 통해 라이브러리나 애플리케이션의 특정 버전을 배포할 수 있어
안정적인 배포 프로세스를 지원합니다.
주요 패키지 유형
: npm, Docker, Maven, Gradle 등을 지원하여 다양한 패키지 관리가 가능합니다.

4. Github Actions Workflow 구성 요소

Github Actions의 Workflow는 YAML 파일 형식으로 정의되며, 주로 .Github/workflows/ 폴더에 위치합니다.
Workflow는 이벤트에 반응하여 실행되며 Workflow 파일을 통해 실행할 작업의 순서를 정의할 수 있습니다.

Event Trigger
: Commit, Pull Request 생성, Issue 생성 등 Github 이벤트가 발생할 때 Workflow가 트리거됩니다.
Jobs
: 하나의 Workflow에는 여러 작업(Job)을 포함할 수 있으며,
각 Job은 병렬 또는 순차적으로 실행할 수 있습니다.
Steps
: Job은 여러 개의 Step으로 구성되며, Step은 Action을 실행하는 기본 단위입니다.

5. Github Actions로 CI/CD 파이프라인 구축하기

Github Actions를 활용하여 CI/CD 파이프라인을 구축할 수 있습니다.
예를 들어 Azure에 애플리케이션을 배포하기 위한 CI/CD 파이프라인을 구성하는 경우 다음과 같은 단계로 구성됩니다.

Build 및 Test 단계
: Commit이나 Pull Request가 발생하면 Workflow가 트리거되어
프로젝트의 의존성을 설치하고 Build한 후, 자동 Test를 실행합니다.
패키징 및 아티팩트 저장
: Test가 성공하면 Build된 결과물을 Github Packages에 업로드하거나
Harbor와 같은 외부 Registry에 Push합니다.
프로덕션 배포
: 조건부로 프로덕션 환경에 배포하도록 설정하여 안정적인 배포가 가능하도록 합니다.
이를 통해 변경 사항이 빠르게 반영됩니다.

6. Github Actions 장점

Github Actions는 Github 환경에 통합된 CI/CD 도구로서 다음과 같은 장점이 있습니다:

Github과의 통합성
: Github Repository 내에서 직접 Workflow를 관리하므로,
기존의 버전 관리와 Issue 트래킹과 원활하게 연결됩니다.
자동화와 유연성
: 다양한 이벤트와 조건에 따라 파이프라인을 자유롭게 설계할 수 있으며,
Github Marketplace에서 원하는 Action을 가져와 바로 활용할 수 있습니다.
비용 절감
: 오픈소스 프로젝트와 유료 사용자는 Github Actions의 무료 사용량을 지원받을 수 있어
별도의 CI/CD 인프라 구축 비용을 절감할 수 있습니다.

7. GitHub Actions Workflow

GitHub Actions는 GitHub Repository에서 Build, 테스트, 배포 작업을 자동화하는 도구로,
Action Workflow는 GitHub Actions에서 수행할 일련의 작업을 정의하는 파일입니다.
Workflow 파일을 작성함으로써 코드 Push, Pull Request 등 특정 이벤트 발생 시 원하는 작업을 자동으로 실행할 수 있습니다.
Workflow 파일은 YAML 형식으로 작성되며, GitHub Repository의 .github/workflows/ 폴더에 저장됩니다.
예를 들어 CI/CD 파이프라인을 위한 Workflow 파일을 .github/workflows/ci.yml에 작성할 수 있습니다.

8. Actions Workflow 구성 요소

Workflow 파일은 다음과 같이 구성됩니다.

name: Workflow의 이름을 정의하며, GitHub Actions 탭에서 Workflow를 구분할 때 사용됩니다.
on
: Workflow를 트리거할 이벤트를 지정합니다.
예를 들어 push, pull_request와 같은 GitHub 이벤트를 설정할 수 있습니다.
permissions: Workflow 실행 시 필요한 권한을 설정합니다.
env: Workflow에서 사용하는 전역 환경 변수를 지정합니다.
jobs
: Workflow 내에서 실행할 작업을 정의하는 부분으로 하나 이상의 Job을 포함할 수 있습니다.
Job은 병렬 또는 순차적으로 실행 가능합니다.

9. Jobs 구성 요소

Job은 Workflow에서 독립적으로 실행되는 단위입니다.
각 Job은 다음과 같은 구성 요소로 이루어집니다.

runs-on
: Job이 실행될 환경을 지정합니다.
예를 들어, ubuntu-latest는 최신 Ubuntu 환경에서 실행되도록 설정합니다.
steps
: Job 내에서 실행할 단계별 작업을 정의합니다.
각 Step은 name, uses, env, run 등을 포함할 수 있습니다.

10. Step 구성 요소

Step은 Job 내에서 실행되는 개별 작업으로, 다음과 같은 요소를 포함할 수 있습니다:

name
: Step의 이름을 지정하여, GitHub Actions 실행 로그에서 해당 작업을 쉽게 구분할 수 있습니다.
uses
: GitHub Actions에서 제공하는 프리셋 Action을 사용하거나, 커스텀 Action을 사용할 수 있습니다.
env: Step에 필요한 환경 변수를 설정합니다.
run: 명령어를 실행하는 부분으로, 스크립트나 쉘 명령어를 작성할 수 있습니다.

11. 예제: Gradle Build 및 Docker Image Push Workflow 작성하기

다음은 Gradle을 사용하여 Application을 Build하고,
Build 결과를 Docker Image로 만들어 Docker Hub에 Push하는 Workflow 예제입니다.
이 예제에서는 GitHub Actions에서 자주 사용하는 Checkout Action, Gradle Build Action, Artifact Upload/Download Action, Docker Login Action, Docker Push Action을 포함합니다.

Workflow 파일 예제 (.github/workflows/ci.yml)위 Workflow 예제는 크게 두 가지 Job으로 구성되어 있습니다.

name: CI/CD Pipeline

on:
  push:
    branches:
      - main

permissions:
  contents: read

env:
  DOCKER_REGISTRY: docker.io
  DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
  DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }}
  IMAGE_NAME: my-app

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repository
        uses: actions/checkout@v2

      - name: Set up JDK 11
        uses: actions/setup-java@v2
        with:
          java-version: '11'

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

      - name: Upload build artifact
        uses: actions/upload-artifact@v2
        with:
          name: build-output
          path: build/libs/

  docker:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Download build artifact
        uses: actions/download-artifact@v2
        with:
          name: build-output

      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ env.DOCKER_USERNAME }}
          password: ${{ env.DOCKER_PASSWORD }}

      - name: Build Docker image
        run: docker build -t ${{ env.DOCKER_REGISTRY }}/${{ env.DOCKER_USERNAME }}/${{ env.IMAGE_NAME }}:latest .

      - name: Push Docker image
        run: docker push ${{ env.DOCKER_REGISTRY }}/${{ env.DOCKER_USERNAME }}/${{ env.IMAGE_NAME }}:latest

1) “build” Job

runs-on: ubuntu-latest: 이 Job은 최신 Ubuntu 환경에서 실행됩니다.
Step 1: Repository Checkout
- Action 사용
  : Actions/checkout@v2을 사용하여 Repository를 Checkout하고, 코드를 Download합니다.
Step 2: JDK 설치
- Gradle Build를 위해 JDK를 설치합니다.
- Actions/setup-java@v2을 사용해 Java 11 버전을 설정합니다.
Step 3: Gradle Build
- ./gradlew build 명령어를 통해 Gradle을 사용하여 프로젝트를 Build합니다.
Step 4: Artifact 업로드
- Build 결과물인 JAR 파일을 업로드하여 다음 Job에서도 사용할 수 있도록 합니다.
- Actions/upload-artifact@v2를 사용하여 build/libs/ 폴더의 내용을 업로드합니다.

2) “docker” Job

runs-on: ubuntu-latest: 이 Job 역시 최신 Ubuntu 환경에서 실행됩니다.
needs: build
: Job간 의존성을 설정하는 기능으로, Job은 병렬 실행이 Default이기 때문에 Job간 실행 순서를 설정하고 싶을 때 사용합니다.
build Job이 성공적으로 완료된 후에만 이 Job이 실행됩니다.
Step 1: Artifact Download
- Actions/download-artifact@v2를 사용하여 이전 build Job에서 업로드한 Build 결과물을 Download합니다.
Step 2: Docker Hub Login
- docker/login-Action@v2를 사용해 Docker Hub에 Login합니다.
- GitHub Secrets에 저장된 DOCKER_USERNAME과 DOCKER_PASSWORD를 사용하여 보안을 유지합니다.
Step 3: Docker Image Build
- Build된 Artifact를 기반으로 Docker Image를 Build합니다.
- ${{ env.DOCKER_REGISTRY }}/${{ env.DOCKER_USERNAME }}/${{ env.IMAGE_NAME }}:latest 형식의 Image 태그를 사용합니다.
Step 4: Docker Image Push
- 마지막으로, Build된 Docker Image를 Docker Hub에 Push합니다.