GitHub Actions 고급 워크플로우: Docker와 Kubernetes를 활용한 CI/CD 파이프라인 구축

현대적인 소프트웨어 개발에서 CI/CD 파이프라인은 필수 요소가 되었습니다. GitHub Actions는 강력한 자동화 플랫폼으로, Docker 컨테이너화부터 Kubernetes 배포까지 전체 DevOps 워크플로우를 효율적으로 관리할 수 있게 해줍니다. 이 글에서는 실무에서 활용할 수 있는 고급 GitHub Actions 워크플로우 구성 방법을 살펴보겠습니다.

GitHub Actions 워크플로우 기본 구조 이해

GitHub Actions 워크플로우는 .github/workflows 디렉토리에 YAML 파일로 정의됩니다. 고급 워크플로우를 구성하기 전에 기본 구조를 이해하는 것이 중요합니다.

name: Advanced CI/CD Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * 0'  # 매주 일요일 오전 2시

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
  KUBECONFIG_FILE: ${{ secrets.KUBECONFIG }}

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          cache: 'npm'

이 기본 구조에서 on 섹션은 워크플로우 트리거 조건을, env는 전역 환경 변수를 정의합니다. 고급 워크플로우에서는 이러한 기본 요소들을 조합하여 복잡한 파이프라인을 구성합니다.

Docker 이미지 빌드 및 레지스트리 푸시 자동화

컨테이너 기반 애플리케이션 배포를 위해서는 Docker 이미지 빌드와 레지스트리 푸시 과정이 필수입니다. GitHub Container Registry(GHCR)를 활용한 워크플로우를 구성해보겠습니다.

build-and-push:
  needs: test
  runs-on: ubuntu-latest
  permissions:
    contents: read
    packages: write
  outputs:
    image-digest: ${{ steps.build.outputs.digest }}
  steps:
    - name: Checkout repository
      uses: actions/checkout@v4
    
    - name: Log in to Container Registry
      uses: docker/login-action@v3
      with:
        registry: ${{ env.REGISTRY }}
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}
    
    - name: Extract metadata
      id: meta
      uses: docker/metadata-action@v5
      with:
        images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
        tags: |
          type=ref,event=branch
          type=ref,event=pr
          type=sha,prefix={{branch}}-
          type=raw,value=latest,enable={{is_default_branch}}
    
    - name: Build and push Docker image
      id: build
      uses: docker/build-push-action@v5
      with:
        context: .
        push: true
        tags: ${{ steps.meta.outputs.tags }}
        labels: ${{ steps.meta.outputs.labels }}
        cache-from: type=gha
        cache-to: type=gha,mode=max

이 워크플로우는 Docker 이미지 빌드 캐싱을 활용하여 빌드 시간을 단축시키고, 브랜치별로 다른 태그 전략을 적용합니다.

멀티 스테이지 빌드와 보안 스캔 통합

프로덕션 환경에서는 보안이 중요합니다. Docker 이미지 빌드 과정에 보안 스캔을 통합하는 방법을 살펴보겠습니다.

security-scan:
  needs: build-and-push
  runs-on: ubuntu-latest
  steps:
    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}@${{ needs.build-and-push.outputs.image-digest }}
        format: 'sarif'
        output: 'trivy-results.sarif'
    
    - name: Upload Trivy scan results to GitHub Security tab
      uses: github/codeql-action/upload-sarif@v3
      if: always()
      with:
        sarif_file: 'trivy-results.sarif'
    
    - name: Fail on high severity vulnerabilities
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}@${{ needs.build-and-push.outputs.image-digest }}
        format: 'table'
        exit-code: '1'
        severity: 'HIGH,CRITICAL'

Trivy를 사용한 보안 스캔은 컨테이너 이미지의 취약점을 자동으로 검사하고, GitHub Security 탭에 결과를 업로드합니다.

Kubernetes 배포 자동화

Kubernetes 클러스터에 애플리케이션을 자동 배포하는 워크플로우를 구성해보겠습니다. kubectl과 Helm을 활용한 배포 전략을 다룹니다.

deploy-to-k8s:
  needs: [build-and-push, security-scan]
  runs-on: ubuntu-latest
  environment: production
  steps:
    - name: Checkout repository
      uses: actions/checkout@v4
    
    - name: Setup kubectl
      uses: azure/setup-kubectl@v3
      with:
        version: 'v1.28.0'
    
    - name: Setup Helm
      uses: azure/setup-helm@v3
      with:
        version: '3.12.0'
    
    - name: Configure kubectl
      run: |
        echo "${{ secrets.KUBECONFIG }}" | base64 -d > kubeconfig
        export KUBECONFIG=kubeconfig
        kubectl config current-context
    
    - name: Deploy with Helm
      run: |
        export KUBECONFIG=kubeconfig
        helm upgrade --install myapp ./helm-chart \
          --namespace production \
          --create-namespace \
          --set image.repository=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} \
          --set image.tag=${{ github.sha }} \
          --set ingress.enabled=true \
          --wait --timeout=10m
    
    - name: Verify deployment
      run: |
        export KUBECONFIG=kubeconfig
        kubectl rollout status deployment/myapp -n production
        kubectl get pods -n production -l app=myapp

이 배포 워크플로우는 Helm을 사용하여 Kubernetes 리소스를 관리하고, 배포 후 상태를 검증합니다.

환경별 배포 전략과 승인 워크플로우

프로덕션 배포에는 승인 과정이 필요합니다. GitHub Environments를 활용한 단계별 배포 전략을 구현해보겠습니다.

deploy-staging:
  needs: [build-and-push, security-scan]
  runs-on: ubuntu-latest
  environment: staging
  steps:
    - name: Deploy to staging
      run: |
        echo "Deploying to staging environment"
        # 스테이징 배포 로직

deploy-production:
  needs: deploy-staging
  runs-on: ubuntu-latest
  environment: production
  if: github.ref == 'refs/heads/main'
  steps:
    - name: Deploy to production
      run: |
        echo "Deploying to production environment"
        # 프로덕션 배포 로직
    
    - name: Notify deployment
      uses: 8398a7/action-slack@v3
      with:
        status: ${{ job.status }}
        channel: '#deployments'
        webhook_url: ${{ secrets.SLACK_WEBHOOK }}
      if: always()

GitHub Environments 설정에서 protection rules를 구성하면 프로덕션 배포 전 승인을 요구할 수 있습니다.

모니터링과 롤백 자동화

배포 후 애플리케이션 상태를 모니터링하고 문제 발생 시 자동 롤백하는 기능을 추가할 수 있습니다.

post-deployment-check:
  needs: deploy-production
  runs-on: ubuntu-latest
  steps:
    - name: Health check
      run: |
        for i in {1..30}; do
          if curl -f https://myapp.example.com/health; then
            echo "Health check passed"
            exit 0
          fi
          echo "Attempt $i failed, retrying in 10 seconds..."
          sleep 10
        done
        echo "Health check failed after 30 attempts"
        exit 1
    
    - name: Rollback on failure
      if: failure()
      run: |
        export KUBECONFIG=kubeconfig
        kubectl rollout undo deployment/myapp -n production
        echo "Rollback completed due to health check failure"

워크플로우 최적화와 성능 향상

대규모 프로젝트에서는 워크플로우 실행 시간과 비용 최적화가 중요합니다. 캐싱, 병렬 실행, 조건부 실행을 활용한 최적화 방법을 살펴보겠습니다.

optimize-workflow:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
      with:
        fetch-depth: 0
    
    - name: Check for changes
      id: changes
      run: |
        if git diff --quiet HEAD~1 HEAD -- src/; then
          echo "source-changed=false" >> $GITHUB_OUTPUT
        else
          echo "source-changed=true" >> $GITHUB_OUTPUT
        fi
    
    - name: Skip if no source changes
      if: steps.changes.outputs.source-changed == 'false'
      run: echo "No source code changes detected, skipping build"
    
    - name: Cache dependencies
      if: steps.changes.outputs.source-changed == 'true'
      uses: actions/cache@v3
      with:
        path: ~/.npm
        key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
        restore-keys: |
          ${{ runner.os }}-node-

마무리

GitHub Actions를 활용한 고급 워크플로우 구성은 현대적인 DevOps 환경에서 필수적인 기술입니다. Docker 컨테이너화부터 Kubernetes 배포까지의 전체 파이프라인을 자동화함으로써 개발 생산성을 크게 향상시킬 수 있습니다. 보안 스캔, 환경별 배포 전략, 모니터링 등을 통합한 완전한 CI/CD 파이프라인을 구축하여 안정적이고 효율적인 소프트웨어 배포 환경을 만들어보시기 바랍니다.