[TIL, 일일 회고] 2024.10.30 - MSA 배포 자동화를 위한 Docker 이미지 태깅 전략

개요

어제 프로젝트의 배포 프로세스를 정리하면서 dockerTagAndPush.sh 파일에 대해서 정리하겠다 했습니다.

 

본 글에서는 각 서비스의 Docker 이미지를 빌드하고 태깅하는 역할을 하는 dockerTagAndPush.sh 파일에 대해서 정리하고, 장점에 대해서 정리하고자 합니다.

[TIL, 일일 회고] 2024.10.29 - GlowGrow 프로젝트 GitHub Actions와 Docker를 활용한 MSA 배포 자동화

 

Docker 이미지 태깅이란❓

Docker 이미지 태그는 같은 이미지를 구분하는 식별자입니다.

docker tag myapp:latest myapp:v1.0.0

 

같은 이미지에 다른 태그를 부여하여 버전을 관리할 수 있습니다.

태깅의 중요성

 

버전 관리

• 각 배포 버전을 명확히 구분
• 문제 발생 시 롤백 용이
• 배포 이력 추적 가능

운영 안정성

• 특정 버전 고정 가능
• 실수로 인한 잘못된 배포 방지
• 테스트된 버전 관리 용이

협업 효율성

• 팀원 간 특정 버전 공유 용이
• 환경별 버전 관리 가능
• 배포 프로세스 표준화

 

효과적인 태깅 전략

1. latest 태그

docker tag myapp:latest

 

• 항상 최신 버전을 가리킴
• 개발 환경에서 유용
• latest 태그는 실제로 가장 최근에 빌드된 이미지를 나타내지만, 항상 안정성을 보장하지 않습니다. 따라서, 개발 환경에서는 유용할 수 있지만, 프로덕션 환경에서는 신뢰성 문제가 발생할 수 있습니다.

 

2. 버전 태그

docker tag myapp:v1.0.0

 

• 명시적 버전 관리
• 프로덕션 환경에 적합

 

3. Git Commit Hash

docker tag myapp:abc123

 

• 소스코드와 직접 연결
• 정확한 버전 추적 가능
• 이 방법은 특정 커밋 버전과 이미지를 연결하여, 정확한 버전 추적이 가능합니다. 이 태그는 CI/CD 파이프라인에서 빌드된 특정 코드의 이미지를 참조할 수 있어 디버깅과 배포를 보다 용이하게 합니다.

 

태깅 전략 선택

다양한 태깅 전략이 있지만 저희 프로젝트에서는  latest 와Git Commit Hash 전략을 사용했습니다.

# 모든 서비스 도커 이미지를 빌드합니다.
services=(
  "glowgrow-eureka" "glowgrow-gateway" "glowgrow-auth" "glowgrow-user"
  "glowgrow-payment" "glowgrow-notification" "glowgrow-post" "glowgrow-promotion" "glowgrow-reservation" "glowgrow-multimedia"
)

# 도커 이미지에 commit hash를 기반으로한 이미지 태그를 설정합니다.
commit_hash=$(git rev-parse --short HEAD)

for service in "${services[@]}"
do
  imageName="$DOCKER_HUB_NAMESPACE/$service"

  # 도커 이미지 빌드 (해당 service 디렉토리에 Dockerfile이 있어야 합니다.)
  docker build -t "$imageName:latest" "./$service"

  # 이미지를 구분하기 위해서 latest 이외의 태그를 추가합니다.
  docker tag "$imageName:latest" "$imageName:$commit_hash"

  # Docker Hub에 push
  docker push "$imageName:latest"
  docker push "$imageName:$commit_hash"

  echo "$service 이미지가 빌드되어 Docker hub에 푸쉬되었습니다."
done

echo "모든 서비스의 이미지 빌드 및 푸쉬가 완료되었습니다."

 

• 자동화된 태깅
  • latest 태그와 commit hash 태그 자동 생성
  • 모든 서비스에 일관된 태깅 적용
• 배포 자동화
  • 빌드부터 푸시까지 자동화
  • 수동 작업 최소화
  • 인적 오류 방지
• 확장성
  • 새로운 서비스 추가가 용이
  • 태깅 전략 변경이 쉬움

commit_hash=$(git rev-parse --short HEAD)

 

• short hash 사용 이유: 전체 해시보다 읽기 쉽고 관리하기 용이
• git과의 연동으로 코드와 이미지 버전 추적 가능

 

latest 태그는 사용의 편리함을 제공하는 반면, Git commit hash 태그는 코드 변경 사항에 대한 명확한 추적과 신뢰성을 제공합니다. 두 태그를 함께 사용함으로써 배포의 유연성과 안정성을 확보할 수 있습니다.

 

한마디로 정리하자면 dockerTagAndPush.sh 파일은 이미지들을 빌드하고 태그를 붙여서 저장소에 올리는 역할을 담당합니다.

 

쉘 스크립트로 작성한 이유

저희는 도커 이미지 태깅을 쉘 스크립트로 작성했습니다. 수동으로 할 수 도있지만 자동으로 하면 다음과 같은 장점이 있습니다.

수동

# 서비스마다 반복 작업 필요
docker build -t myapp/eureka:latest ./eureka
docker tag myapp/eureka:latest myapp/eureka:abc123
docker push myapp/eureka:latest
docker push myapp/eureka:abc123

# 다음 서비스...

 

 

반복 작업의 비효율성 

• 각 마이크로서비스마다 동일한 명령어 반복
• 시간 소요가 큼
• 지루하고 단순 반복적인 작업

 

인적 오류 발생 가능성 

• 명령어 오타 위험
• 태그 이름 실수 가능
• 일부 서비스 누락 가능성

일관성 유지의 어려움 

• 각 서비스마다 다른 방식의 태깅 가능성
• 표준화된 프로세스 유지 어려움

 

스크립트 사용 시

./dockerTagAndPush.sh

 

 

자동화된 프로세스 

• 한 번의 명령으로 모든 서비스 처리
• 사람의 개입 최소화
• 빠른 배포 가능

표준화된 배포 프로세스 

• 모든 서비스에 동일한 빌드/태그/푸시 프로세스 적용
• 일관된 버전 관리
• 체계적인 이미지 관리

유지보수성 향상 

• 배포 프로세스 변경 시 스크립트만 수정
• 새로운 서비스 추가가 용이
• 배포 로직 중앙 관리

오류 추적 용이성

• 로그 메시지를 통한 진행 상황 모니터링
• 문제 발생 시 빠른 원인 파악

CI/CD 파이프라인 통합 용이

# GitHub Actions 예시
jobs:
  docker:
    steps:
      - name: Build and Push
        run: ./dockerTagAndPush.sh

 

 

• 자동화된 배포 파이프라인 구축 가능
• 지속적 통합/배포 실현

---

예를 들어, 10개의 마이크로서비스가 있는 경우:

수동 작업 시

• 40개의 명령어 실행 필요 (빌드,태그,푸시,푸시)
• 약 10-15분 소요
• 실수 가능성 높음

스크립트 사용 시

• 1개의 명령어로 처리
• 3-5분 소요
• 실수 가능성 최소화

이러한 이유로 마이크로서비스 아키텍처에서는 쉘 스크립트를 통한 자동화를 선택했습니다.