DevOps 가이드·약 5분 내외
CI/CD — GitHub Actions로 Docker 이미지 빌드하고 배포하기
로컬에서 매번 docker build를 치고 계신가요? 코드를 푸시하기만 하면 GitHub 서버가 대신 이미지를 굽고 서버에 배포까지 해주는 자동화(CI/CD) 파이프라인을 구축하는 방법을 알아봅니다.
아키텍처 구조도
다이어그램 렌더링 중...
수동 배포의 고통
CI/CD가 없다면 배포할 때마다 다음과 같은 지루한 과정을 반복해야 합니다.
귀찮음의 연속
수동 배포의 단점
매번 5~10분을 낭비하게 됩니다.
매번 5~10분을 낭비하게 됩니다.
로컬 PC 리소스 소모
빌드 중 컴퓨터 느려짐
→
실수 확률 증가
휴먼 에러
GitHub Actions를 쓰면 이 모든 과정이 "git push" 한 번으로 끝납니다.
CI/CD 파이프라인 흐름도
1
Git Push
개발자가 코드를 staging이나 main 브랜치에 푸시합니다.
2
GitHub Actions (CI)
GitHub 서버가 코드를 받아 docker build를 실행합니다.
3
Registry 푸시
완성된 이미지를 GitHub Container Registry(GHCR)에 업로드합니다.
4
서버 배포 (CD)
우리 서버(VPS)에 접속해 새 이미지를 pull 받고 실행합니다.
GitHub Actions 워크플로 작성
저장소 최상단에 .github/workflows/docker-build.yml 파일을 만들면 GitHub이 이를 읽고 자동으로 실행합니다.
docker-build.yml 예시
name: Build and Push Docker Image
on:
push:
branches:
- main
- staging
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Log in to the Container registry
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: ghcr.io/my-org/my-app:latest안전한 배포를 위한 태깅 전략 (SHA)
latest 태그만 쓰면 안 되는 이유
모든 이미지를 latest 또는 staging으로만 덮어쓰면, 배포 후 심각한 버그가 발견되었을 때 "이전 버전"으로 롤백(되돌리기)할 수가 없습니다. 이전 이미지가 덮어씌워져 사라졌기 때문입니다.
Git Commit SHA를 태그로 사용하기
# Git 커밋 해시(앞 7자리) 추출
- name: Get short SHA
id: vars
run: echo "sha=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT
- name: Build and push
uses: docker/build-push-action@v5
with:
tags: |
ghcr.io/my-org/my-app:staging
ghcr.io/my-org/my-app:staging-${{ steps.vars.outputs.sha }}이렇게 두 개의 태그를 동시에 푸시하면, 서버에서는 항상 :staging을 당겨서(pull) 최신 버전을 배포하되, 필요하면 :staging-abc1234 처럼 특정 커밋 버전으로 즉시 롤백할 수 있습니다.