5.2 CI/CD 와 GitHub Action.
서론
지속적 통합(CI)과 지속적 배포(CD)는 현대 소프트웨어 개발의 핵심적인 부분으로 자리 잡았습니다. CI/CD는 코드 변경 사항을 자동으로 통합, 테스트, 배포하여 개발 팀의 효율성을 향상시키고, 배포 과정에서의 오류를 줄여줍니다.
Jenkins 와 같은 도구는 오랫동안 CI/CD 파이프라인을 구축하는 데 사용되었지만, GitHub Actions 의 등장으로 더욱 간편하고 효율적인 방법에 대한 관심이 높아지고 있습니다.
GitHub Action 소개
GitHub Actions 는 GitHub 리포지토리 내에서 직접 CI/CD 파이프라인을 구축할 수 있는 강력한 도구입니다. 워크플로를 통해 소프트웨어 개발 워크플로우를 자동화할 수 있으며, 이는 .github/workflows 디렉토리 내의 YAML 파일로 정의됩니다. GitHub Actions 는 코드 푸시나 풀 리퀘스트와 같은 이벤트에 반응하여 워크플로를 실행할 수 있으며, 웹 훅을 트리거 하는 등 다양한 방법으로 소프트웨어 개발을 지원합니다.
GitHub Actions 파이프라인 구축
사전준비
- GitHub 계정 및 리포지토리
- Docker 계정 및 Docker 대한 기본이해
리포지토리 설정
GitHub Actions 를 사용하기 위해서는 리포지토리에 .github/workflows 디렉토리를 생성해야합니다. 이 디렉토리 안에 워크플로 파일(.yml 또는 .yaml 확장자)을 생성합니다. 그 외에는 머신을 준비하거나 설치가 필요하지 않습니다.
Docker 이미지 빌드 및 푸시 워크플로
아래는 Docker 이미지를 빌드하고 Docker Hub 에 푸시하는 간단한 GitHub Actions 워크플로의 예시입니다.
name: Build and Push Docker image
on:
push:
branches: [ main ]
jobs:
build-and-push:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Login to DockerHub
uses: docker/login-action@v3
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Build and push
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: user/app:latest
이 GitHub Actions 워크플로우는 리포지토리의 main
브랜치에 변경사항이 푸시될 때마다 Docker 이미지를 자동으로 빌드하고 Docker Hub 에 푸시하도록 설계되었습니다.
워크플로우는 ubuntu-latest
러너에서 실행되는 여러 단계로 구성됩니다.
Steps 에 대한 설명
- Checkout repository: 워크플로우는 리포지토리의 코드를 작업 디렉토리로 체크아웃 하여 Docker 이미지 빌드 프로세스에서 사용할 수 있도록 시작합니다.
- Set up Docker Buildx: 이 단계는 Docker Buildx 를 설정합니다. Docker Buildx 는 Docker 의 기능을 확장하는 Docker CLI 플러그인으로, buildkit 빌더 엔진의 기능에 대한 전체 지원을 제공합니다. 이를 통해 멀티 아키텍처 이미지를 생성하는 것과 같은 보다 고급 빌드 기능을 사용할 수 있습니다.
- Login to DockerHub: DockerHub 에 Docker 이미지를 푸시하기 전에, 워크플로우는 GitHub Secrets 에 저장된 자격 증명을 사용하여 DockerHub 에 로그인합니다. Secret 인
DOCKER_USERNAME
과DOCKER_PASSWORD
는 DockerHub 사용자 이름과 비밀번호를 안전하게 저장하기 위해 리포지토리 설정에서 설정해야 합니다. - Build and push: 이 단계는 리포지토리의 컨텍스트(즉, 리포지토리의 루트 디렉토리)를 사용하여 Docker 이미지를 빌드하고
user/app:latest
로 태그를 지정합니다. 이미지를 빌드한 후, DockerHub 에 푸시합니다.push: true
플래그는 DockerHub 로 이미지를 푸시하는 기능을 활성화합니다.
GitHub Actions 고급 기능
Secrets 관리
GitHub 리포지토리 안에서 Secret 관리 기능을 통해 비밀번호, 토큰, SSH 키와 같은 민감한 정보를 안전하게 저장하고 관리할 수 있습니다.
매트릭스 빌드
매트릭스 빌드는 언어, 운영체제 및 기타 변수의 여러 버전을 걸쳐 워크플로를 실행할 수 있게 해주는 강력한 기능입니다. 다양한 환경에서 병렬 테스트를 가능하게 하여 코드가 예상대로 작동하는지 확인합니다. 이는 테스트에 필요한 시간을 크게 줄이고 소프트웨어의 신뢰성을 향상시킵니다.
Workflow 최적화
GitHub Actions Workflow 는 실행시 정보가 없는 깨끗한 상태에서 시작하기 때문에 이를 최적화하기 위한 방법들을 제공합니다.
캐시
캐시는 workflow 에서 자주 사용되는 정보를 저장하여 다음 workflow 실행 시에 재사용할 수 있도록 합니다. 이를 통해 빌드 시간을 줄이고 CI/CD 과정을 더욱 효율적으로 만들 수 있습니다. 특히 Gradle, NPM 과 같이 의존성 패키지를 다운로드하는 데 시간이 많이 소요되는 경우에 유용합니다. 캐시는 고유한 식별키로 저장, 사용이 가능하며 브랜치별로 관리할 수도 있습니다.
아티팩트
아티팩트는 workflow 실행중 생성된 데이터를 저장할 수 있도록 합니다. 예를 들면 빌드나 테스트의 output, log 이 될 수 있으며 job 간에 데이터를 공유하고 workflow 가 완료된 후에도 데이터를 저장할 수 있습니다. 캐시와 차이점은 워크플로우의 실행 결과 중에 생성된 파일을 대상으로 설계된 요소입니다.
캐쉬와 아티팩트 비교
- 패키지 관리 시스템의 빌드 종속성 등 작업 또는 워크플로 실행 간에 자주 변경되지 않는 파일을 다시 사용하려는 경우 캐싱을 사용합니다.
- 빌드된 이진 파일 또는 빌드 로그와 같이 워크플로 실행이 종료된 후 볼 작업에서 생성된 파일을 저장하려는 경우 아티팩트를 사용합니다.
결론
Jenkins 와 GitHub Actions 의 차이점
- 통합: GitHub Actions 는 GitHub 과 깊게 통합되어 있어 GitHub 에서 호스팅되는 프로젝트에 대해 원활한 경험을 제공합니다. Jenkins 는 강력하지만 별도의 관리와 통합이 필요합니다.
- 구성: GitHub Actions 구성은
.github/workflows
디렉토리에 코드로 저장되어 GitOps 접근 방식을 촉진합니다. Jenkins 구성은 종종 UI를 통해 관리됩니다. - 확장성: GitHub Actions 는 병렬 실행에 대해 최소한의 설정으로 더 확장 가능한 솔루션을 제공합니다. Jenkins 의 확장성은 달성할 수 있지만 추가 플러그인과 구성이 필요합니다.
GitHub Actions 의 이점
- 사용의 용이성: GitHub 과의 통합은 코드가 존재하는 동일한 플랫폼 내에서 워크플로를 설정하고 관리하기 매우 간단하게 만듭니다.
- 비용 효율적: 공개 저장소의 경우 GitHub Actions 는 무료이며, 비공개 저장소는 넉넉한 양의 무료 분을 받아 소규모에서 중규모 프로젝트에 비용 효율적입니다.
- 유연성: 매트릭스 빌드, 캐싱, 아티팩트 관리와 같은 복잡한 워크플로를 생성할 수 있는 능력은 다양한 CI/CD 요구에 대한 GitHub Actions 를 다목적 도구로 만듭니다.
GitHub Actions 는 GitHub 와 관련된 워크플로 프로세스를 단순화하고 자동화하여 개발자들이 더욱 효율적으로 작업할 수 있도록 도와줍니다. 상황에 따라 적절한 도구를 사용하여 CI/CD 파이프라인을 구축하고 관리하는 것이 중요합니다.