refactor: 스프링 부트 앱 외의 사이드 인프라 배포 과정을 분리 #592
Conversation
Hexeong
requested review from
Gyuhyeok99,
JAEHEE25,
lsy1307,
sukangpunch,
whqtker and
wibaek
as code owners
Walkthrough
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/prod-cd.yml (1)
149-153: 2. 재시작 로직의 에러 처리 및 헬스체크
docker compose down || true패턴을 사용하여 컨테이너가 실행 중이지 않을 때의 실패를 방지한 것은 좋지만, 다음 사항들을 고려해 주세요:
- 에러 마스킹:
|| true로 인해 실제 문제가 발생해도 감춰질 수 있습니다.- 배포 검증 부재: 재시작 후 애플리케이션이 정상적으로 시작되었는지 확인하는 헬스체크가 없습니다. 배포 실패 시 롤백 메커니즘도 고려가 필요합니다.
🔎 헬스체크를 추가하는 개선안
재시작 후 다음과 같은 헬스체크를 추가할 수 있습니다:
OWNER_LOWERCASE=$OWNER_LOWERCASE IMAGE_TAG=$IMAGE_TAG_ONLY docker compose -f docker-compose.prod.yml up -d + # 4. 헬스체크 + echo "Waiting for application to be healthy..." + for i in {1..30}; do + if curl -f http://localhost:8080/actuator/health > /dev/null 2>&1; then + echo "Application is healthy!" + break + fi + if [ $i -eq 30 ]; then + echo "Health check failed after 30 attempts" + exit 1 + fi + echo "Attempt $i/30: Application not ready yet..." + sleep 2 + done + - # 6. 정리 + # 5. 정리 docker image prune -f
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/dev-cd.yml.github/workflows/prod-cd.ymldocker-compose.dev.ymldocker-compose.prod.yml
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-25T10:59:42.734Z
Learnt from: whqtker
Repo: solid-connection/solid-connect-server PR: 481
File: docs/infra-config/nginx.conf:36-36
Timestamp: 2025-08-25T10:59:42.734Z
Learning: When using network_mode: host in Docker Compose, containers share the host's network namespace, so nginx proxy_pass should target localhost:PORT instead of container service names like solid-connection-server:PORT.
Applied to files:
docker-compose.prod.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (11)
docker-compose.prod.yml (3)
14-14: 2. 재시작 정책 추가
restart: always정책을 추가한 것은 프로덕션 환경의 안정성을 높이는 좋은 개선입니다!
7-11: 호스트 네트워킹 전환 및 Redis 외부 배포 설정 검증 필요프로덕션 환경 docker-compose 파일의 주요 구조 변경에 대해 다음 항목들을 확인해 주세요:
Redis 가용성 검증
- Redis가 실제로 호스트의
127.0.0.1:6379에서 실행 중인지 확인 필요- 로컬 개발 환경(docker-compose.local.yml)과 달리, 프로덕션에서는 Redis가 Docker 컨테이너 외부에서 독립 실행되어야 함
포트 노출 및 방화벽 규칙 확인
network_mode: "host"사용으로 컨테이너의 모든 포트(8080, 8081 등)가 호스트에 직접 노출됨- 방화벽 규칙이 필요한 포트만 허용하도록 적절히 구성되었는지 검증
네트워크 격리 손실에 따른 보안 검토
- Docker 네트워크 격리가 완전히 우회되므로 보안 영향도 평가 필요
- 호스트 머신의 다른 서비스와의 포트 충돌 가능성 검토
1-14: 3. 제거된 사이드 인프라 서비스 검증 필요Docker Compose에서 Redis, Redis-Exporter, Alloy 서비스가 제거되었습니다. 이 서비스들이 호스트에 별도로 배포되어 정상 동작하는지 확인이 필요합니다:
- Redis: 데이터 영속성 및 백업 설정
- Redis-Exporter: 모니터링 메트릭 수집
- Alloy: 로그 및 메트릭 집계
Spring Boot 앱이 시작될 때 이러한 의존성 서비스들이 준비되지 않으면 연결 실패가 발생할 수 있습니다.
다음 스크립트로 사이드 인프라가 호스트에서 실행 중인지 확인할 수 있습니다:
#!/bin/bash # Description: Verify side infrastructure services are running on host echo "=== Checking Redis service ===" systemctl status redis 2>/dev/null || systemctl status redis-server 2>/dev/null || echo "Redis service not found via systemctl" echo -e "\n=== Checking Redis-Exporter ===" ps aux | grep -i redis.*exporter | grep -v grep echo -e "\n=== Checking Alloy ===" ps aux | grep -i alloy | grep -v grep echo -e "\n=== Checking listening ports ===" ss -tlnp | grep -E ':(6379|9121|12345)\s'docker-compose.dev.yml (3)
14-14: 2. 재시작 정책 추가개발 환경에도
restart: always정책을 추가하여 안정성을 높인 점이 좋습니다!
1-14: 3. 사이드 인프라 분리 확인프로덕션과 마찬가지로 Redis, Redis-Exporter, Alloy가 제거되었습니다. 개발 서버에 이들이 별도로 배포되어 있는지 확인이 필요합니다.
7-11: 호스트 네트워킹 및 Redis 연결 설정 확인 (개발 환경)변경사항 확인:
network_mode: "host"적용SPRING_DATA_REDIS_HOST→127.0.0.1변경SPRING_DATA_REDIS_PORT→6379설정restart: always정책 적용개발 환경 구성 시 다음 사항을 확인해 주세요:
- Redis가 로컬 시스템의
127.0.0.1:6379에서 정상 실행 중인지 확인- 호스트 네트워킹 모드 사용으로 인한 포트 충돌 가능성 검토
.github/workflows/prod-cd.yml (2)
143-148: 1. 이미지 풀 단계GHCR 로그인 및 이미지 풀 로직이 올바르게 구현되었습니다. 워크플로우 토큰을 사용하여 인증하는 방식이 적절합니다.
119-128: 설정 파일 전송 로직 누락 확인
docs/infra-config디렉토리에nginx.prod.conf와config.alloy파일이 존재하고, 워크플로우에서 이들이 체크아웃되고 있으나(라인 110-116), 실제 배포 단계에서는docker-compose.prod.yml만 서버로 전송되고 있습니다(라인 124-127). SSH 단계의 "apply nginx config" 스텝도 실제로는 Docker Compose 재시작만 수행할 뿐 해당 설정 파일들을 적용하지 않습니다.배포 전에 다음을 확인하세요:
- 프로덕션 서버의 Nginx 설정 파일(
/etc/nginx/sites-available/등)이 최신 상태인지- Alloy 설정 파일이 서버에 존재하고 최신 버전인지
- 설정 변경 시 별도의 수동 배포 프로세스나 관리 절차가 마련되어 있는지
.github/workflows/dev-cd.yml (3)
127-130: 1. 이미지 풀 단계GHCR 로그인 및 이미지 풀 로직이 올바르게 구현되었습니다.
138-147: 3. 이미지 정리 로직개발 환경에 대한 이미지 정리 로직이 잘 구현되었습니다:
- Dangling 이미지 제거
- 최근 5개 태그를 제외한 이전 이미지 제거
|| true로 정리 실패 시에도 배포가 계속 진행되도록 한 점이 적절합니다.
103-111: 4. 설정 파일 전송 제거 확인프로덕션과 마찬가지로 Alloy 및 Nginx 설정 파일 전송이 제거되었습니다. 개발 서버에 해당 설정들이 사전 배포되어 있는지 확인이 필요합니다.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.github/workflows/dev-cd.yml (2)
132-136: 배포 후 헬스체크 추가를 권장합니다.현재 구현은 컨테이너를 재시작하지만 정상 구동 여부를 확인하지 않습니다.
다음과 같은 검증 단계를 추가하면 배포 신뢰성을 높일 수 있습니다:
docker compose ps로 컨테이너 상태 확인- 로그를 통해 애플리케이션 시작 메시지 확인
- 헬스 엔드포인트에 대한 간단한 HTTP 요청 (예:
curl -f http://localhost:8080/actuator/health)배포가 실패했을 때 즉시 감지할 수 있어 롤백이나 디버깅이 용이해집니다.
🔎 헬스체크 추가 예시
OWNER_LOWERCASE=$OWNER_LOWERCASE IMAGE_TAG=$IMAGE_TAG_ONLY docker compose -f docker-compose.dev.yml up -d + +# 5. 배포 검증 +echo "Verifying deployment..." +sleep 10 +if docker compose -f docker-compose.dev.yml ps | grep -q "Up"; then + echo "Deployment verification passed." +else + echo "Deployment verification failed. Containers not running properly." + docker compose -f docker-compose.dev.yml logs --tail=50 + exit 1 +fi
142-147: 이미지 정리 로직에 안전장치를 추가할 수 있습니다.현재 로직은 잘 작동하지만, 정리할 이미지가 5개 이하인 경우를 더 명확하게 처리할 수 있습니다.
🔎 개선된 정리 로직 예시
-echo "Cleaning up old tagged images (keeping last 5)..." -IMAGE_NAME_BASE="ghcr.io/${OWNER_LOWERCASE}/solid-connection-dev" -docker images "${IMAGE_NAME_BASE}" --format "{{.Tag}}" | \ -sort -r | \ -tail -n +6 | \ -xargs -I {} docker rmi "${IMAGE_NAME_BASE}:{}" || true +echo "Cleaning up old tagged images (keeping last 5)..." +IMAGE_NAME_BASE="ghcr.io/${OWNER_LOWERCASE}/solid-connection-dev" +OLD_IMAGES=$(docker images "${IMAGE_NAME_BASE}" --format "{{.Tag}}" | sort -r | tail -n +6) +if [ -n "$OLD_IMAGES" ]; then + echo "Removing old images: $OLD_IMAGES" + echo "$OLD_IMAGES" | xargs -I {} docker rmi "${IMAGE_NAME_BASE}:{}" || true +else + echo "No old images to clean up (less than 6 images found)." +fi현재 구현도 충분히 안전하게 동작하므로 선택적으로 적용하시면 됩니다.
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/dev-cd.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (3)
.github/workflows/dev-cd.yml (3)
114-114: 스텝 이름이 더 명확해졌습니다.배포 작업의 의도가 잘 드러나는 네이밍입니다.
123-124: 환경 변수 전달 문제가 해결되었습니다.이전 리뷰에서 지적되었던
OWNER_LOWERCASE누락 이슈가 수정되었습니다.
- Line 123-124에서 필요한 환경 변수들을 export하고
- Line 136에서 docker compose 명령 실행 시 명시적으로 전달하고 있어
docker-compose.dev.yml이 요구하는 변수들을 정상적으로 사용할 수 있습니다.
Also applies to: 136-136
135-135: 에러 처리 전략을 확인해 주세요.
|| true를 사용하여docker compose down실패를 무시하고 있습니다.첫 배포 시 중단할 컨테이너가 없는 경우를 대비한 것으로 보이지만, 이로 인해 다음과 같은 실제 문제들도 감춰질 수 있습니다:
- docker-compose.dev.yml 파일 문법 오류
- Docker 데몬 권한 문제
- 네트워크나 볼륨 관련 충돌
더 명확한 에러 처리를 원하신다면 다음과 같은 접근을 고려해 보세요:
# 컨테이너가 존재하는 경우에만 down 실행 if docker compose -f docker-compose.dev.yml ps -q | grep -q .; then docker compose -f docker-compose.dev.yml down fi현재 방식을 의도적으로 선택하신 것이라면 괜찮습니다.
1 participant
관련 이슈
작업 내용
특이 사항
리뷰 요구사항 (선택)