깃헙 액션도, 도커도, 전부 처음 사용해보는 초보의 CI/CD 적용기이자 고군분투 기록..

요구사항 & 제약조건

• 저희 프로젝트의 간단한 동작 원리 혹은 흐름도입니다. 노란색 상자가 직접 구현해야 하는 서버들인데, 백엔드만 해도 3개의 서버를 구현하고 배포해야 합니다.
• 현재 저희는 하나의 레포지토리만 사용할 수 있는 제약 조건이 있습니다.
• 현대적인 배포 방법들을 적용하고 호환성을 높이며 관리를 용이하게 하기 위해 도커를 적극 활용할 예정입니다.
• 이때, 각 하위 디렉토리에 (ex. frontend, backend/proxy-server, …)위치한 서버 코드를 모두 한번에 빌드하거나 내려받으면 각각의 이미지가 너무 거대해져 불필요한 비용이 발생합니다. 이를 적절히 해결합니다.

ci-cd.yml

name: CI/CD Pipeline

on:
  push:
    branches:
      - main
      - be-feat#46 #테스트용 브랜치

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
    permissions:
      packages: read

  # 콘솔 서버 배포
  deploy-console-server:
    needs: setup
    uses: ./.github/workflows/deploy-service.yml
    with:
      #...

  # 프록시 서버 배포
  deploy-proxy-server:
    needs: setup
    uses: ./.github/workflows/deploy-service.yml
    with:
      #...

  # 네임 서버 배포
  deploy-name-server:
    needs: setup
    uses: ./.github/workflows/deploy-service.yml
    with:
      #...

배포 방법을 다를지라도, 해당하는 하위 디렉토리로 체크아웃하고 도커 이미지를 빌드, 푸시하는 과정은 분명 반복되기에 실제 배포 스크립트를 분리하여 코드 중복을 피하였습니다. 자세한 설정 및 배포 과정은 각 서비스의 docker-compose 등에서 조절할 수 있을 거라 생각하였습니다.

여러 서버를 병렬로 배포해 시간을 줄이고자 하였습니다.

deploy-service.yml

ci-cd.yml에서 input과 secret을 넘겨받고, 실제 배포 작업은 이 파일에서 이루어집니다.

동작 순서는 다음과 같습니다.

1. actions/checkout의 sparse-checkout을 사용해 해당하는 디렉토리로 체크아웃합니다.
2. 도커 buildx를 사용하기 위해 셋업 액션을 실행합니다.
3. docker-compose.yml와 nginx.conf 등 컨테이너를 구동하기 위해 필요한 파일을 SCP로 넘겨줍니다.