지속적 통합 및 지속적 배포(CI/CD): Docker Compose를 사용하는 이유

현대 소프트웨어 개발 환경에서 지속적 통합 및 지속적 배포(CI/CD)는 신뢰할 수 있고 효율적인 소프트웨어를 제공하기 위한 필수적인 관행입니다. CI/CD는 코드 변경 사항이 자동으로 테스트되고 배포되도록 보장하여 빠르고 일관된 제공을 촉진합니다. 그러나 특히 GitHub Actions를 사용하는 현재 접근 방식은 개발을 방해할 수 있는 몇 가지 문제를 야기합니다.

GitHub Actions와 YAML의 문제점
#

GitHub Actions의 주요 문제 중 하나는 YAML 구성 파일에 대한 과도한 의존입니다. YAML은 워크플로우를 정의하는 강력하고 유연한 방법이지만 몇 가지 단점이 있습니다:

이식성 부족: GitHub Actions의 YAML 구성은 GitHub에 특화되어 있습니다. 이는 GitLab, Bitbucket 또는 Jenkins와 같은 다른 CI/CD 플랫폼으로 쉽게 전환할 수 없는 종속성을 만듭니다.
복잡성 및 유지보수성: 프로젝트가 성장함에 따라 YAML 파일은 더 복잡해지고 유지 관리가 어려워집니다. 이러한 복잡성은 하나의 스크립트가 빌드 프로세스의 한 측면을 처리해야 한다는 단일 책임 원칙(SRP)을 모호하게 만들 수 있습니다.
개발자 부담: 개발자는 Git뿐만 아니라 YAML의 복잡성과 선택한 플랫폼의 특정 CI/CD 도구도 이해해야 합니다. 이러한 추가 학습 곡선은 개발 속도를 늦추고 오류를 발생시킬 수 있습니다.

CI/CD를 위한 Docker Compose 제안
#

이러한 문제를 해결하기 위해 코드 빌드 및 테스트에 Docker Compose를 활용하고 GitHub Actions와 같은 CI/CD 도구를 단순히 오케스트레이터로 사용할 것을 제안합니다. 이 접근 방식이 도움이 되는 방법은 다음과 같습니다:

이식성: Docker Compose 파일은 표준이며 로컬 또는 모든 CI/CD 플랫폼에서 실행할 수 있습니다. 이를 통해 빌드 구성이 이식 가능하며 특정 공급자에 종속되지 않습니다.
단순화: 빌드 및 테스트 프로세스를 Docker 컨테이너 내에 격리함으로써 CI/CD 구성이 더 간단해집니다. 개발자는 Docker Compose 파일만 유지 관리하면 되므로 YAML 구성의 복잡성이 줄어듭니다.
로컬 일관성: Docker Compose를 사용하면 개발자가 CI/CD 파이프라인과 정확히 동일한 빌드 및 테스트 프로세스를 로컬에서 실행할 수 있습니다. 이를 통해 “내 컴퓨터에서는 작동함” 문제가 줄어들고 환경 간 일관성이 보장됩니다.

CI/CD에 Docker Compose 구현
#

CI/CD 파이프라인에 Docker Compose를 통합하는 단계별 가이드는 다음과 같습니다:

Dockerfile 정의: 애플리케이션을 설치하고 실행하는 단계를 정의하는 Dockerfile 파일을 생성합니다. 이는 나중에 docker compose 파일에서 사용됩니다. Dockerfile을 사용하면 Docker 이미지 빌드의 책임을 분리할 수 있다는 이점이 있습니다.

# 공식 Node.js 런타임을 베이스 이미지로 사용
FROM node:14

# 컨테이너 내 작업 디렉토리 설정
WORKDIR /app

# package.json 및 package-lock.json 파일을 컨테이너로 복사
COPY package*.json ./

# 종속성 설치
RUN npm install

# 나머지 애플리케이션 코드를 컨테이너로 복사
COPY . .

# 앱이 실행되는 포트 노출
EXPOSE 3000

# 애플리케이션을 실행하는 명령 정의
CMD ["npm", "start"]

Docker Compose 파일 정의: 애플리케이션이 빌드하고 실행하는 데 필요한 모든 서비스를 정의하는 docker-compose.build.yaml 파일을 생성합니다.

services:
  app:
    image: myprivaterepo.com/image:latest
    build: .
    volumes:
      - .:/app
    command: sh -c "npm install && npm test"

로컬 테스트: Docker Compose를 로컬에서 실행하여 빌드가 예상대로 작동하는지 확인합니다.
```
docker compose -f docker-compose.build.yaml build
```

CI/CD 구성: GitHub Actions(또는 다른 CI/CD 플랫폼) 워크플로우 파일에서 Docker 명령을 사용하여 Docker Compose 파일을 실행합니다.

name: CI/CD Pipeline
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
      - name: Build and Test with Docker Compose
        run: docker compose -f docker-compose.build.yaml build
      - name: Push the image referenced in the docker compose file
        run: docker compose -f docker-compose.build.yaml push

이 설정은 CI/CD 도구가 Docker Compose 프로세스의 오케스트레이션만 담당하고 Docker Compose가 애플리케이션의 실제 빌드 및 테스트를 처리하도록 보장합니다. 이러한 관심사의 분리는 단일 책임 원칙을 준수하고 CI/CD 구성의 복잡성을 줄입니다.

Docker 이미지 리포지토리로 푸시: Compose 파일을 사용하는 이점 중 하나는 이미지가 호스팅되는 리포지토리에 이미지를 쉽게 푸시할 수 있다는 것입니다. Docker는 이미지 이름을 사용하여 이미지가 저장되는 위치를 결정합니다. 예를 들어 image: myprivaterepo.com/image:latest는 이미지가 공개 도메인 myprivaterepo.com에서 찾을 수 있음을 나타냅니다. 프라이빗 리포지토리로 푸시하려면 액세스 토큰을 얻기 위해 리포지토리 서비스에서 제공하는 지침을 참조하십시오.

결론
#

CI/CD 파이프라인에서 Docker Compose를 사용하면 더 높은 이식성, 단순성 및 일관성을 달성할 수 있습니다. 이 접근 방식을 통해 개발자는 공급자별 구성에 얽매이지 않고 코드 작성 및 표준 형식의 빌드 프로세스 정의에 집중할 수 있습니다. 궁극적으로 이는 더 빠른 개발 주기와 더 안정적인 소프트웨어 제공으로 이어질 수 있습니다.

GitHub Actions와 YAML의 문제점#

CI/CD를 위한 Docker Compose 제안#

CI/CD에 Docker Compose 구현#

결론#

GitHub Actions와 YAML의 문제점
#

CI/CD를 위한 Docker Compose 제안
#

CI/CD에 Docker Compose 구현
#

결론
#