refactor: 스프링 부트 앱 외의 사이드 인프라 배포 과정을 분리

[Hexeong]

관련 이슈

• resolves: refactor: 사이드 인프라(Redis, Redis-Exporter, Alloy) 분리를 위한 Code Deploy & Docker Compose 수정 #591

작업 내용

• dev/prod 환경에 대해서 기존 사이드 인프라를 배포하던 docker-compose.yml을 스프링 부트 앱만 배포하도록 수정
• dev/prod 환경에 대해서 배포 시 github action 작업 중 사이드 인프라 관련 step을 제거/수정

특이 사항

1. docker-compose로 배포하는 컨테이너가 1개여서 쉘 스크립트 명령어로 바꿔 scp 스텝을 지울 수도 있지만, 현재 IaC를 지향하고 있기에 인프라 스펙을 Code로써 정의해두는 게 더 좋다고 느껴 일단 docker-compose를 사용하는 현재 체제를 유지했습니다!
2. 또한 cd.yml은 배포에 대한 책임을, docker-compose는 인프라 스펙 정의에 대한 책임으로 서로 역할 분리를 통해 협업간 이점이 있지 않을까 합니다 ㅎㅎ
3. 이 부분에 대해서 의견 있으시다면 가감없이 편하게 말씀해주시면 감사드리겠습니다~!

리뷰 요구사항 (선택)

• 스프링 부트 앱 배포(깃헙 액션)와 사이드 인프라 배포(테라폼)이 서로 다르게 실행되기 때문에 같은 network 상에서 묶여야 통신이 가능할 것 같습니다!
• 하지만 제가 생각했을 때, 굳이 network를 생성하지 않고 host의 네트워크를 그대로 쓰게 해도 문제가 없을 것 같고, 더욱이 중간에서 default 네트워크를 이용하지 않기에 미묘한 성능향상(?)이 있을 거라 생각해서 host 네트워크로 설정했습니다!
• 해당 부분에 대해서 괜찮은지에 대해서도 의견 주시면 감사드리겠습니다~

[coderabbitai]

Walkthrough

1. 서비스 제거: 개발 및 프로덕션 docker-compose에서 redis, redis-exporter, alloy 서비스를 완전히 제거했습니다.
2. 네트워크 및 포트 변경: solid-connection 서비스에 network_mode: "host"를 적용하고, 호스트 포트 매핑을 제거했습니다.
3. Redis 호스트 설정 변경: SPRING_DATA_REDIS_HOST 값을 "redis"에서 "127.0.0.1"로 변경했습니다.
4. 재시작 정책 추가: 남아있는 서비스들에 restart: always 정책을 추가했습니다.
5. CI/CD 단순화: 배포 시 로컬 설정 파일(config.alloy, nginx.*.conf) 전송 및 원격 적용 단계를 제거하고, 원격에서 GHCR 로그인 → 이미지 풀 → docker-compose down || true 및 docker-compose up --detach로 앱 재시작하도록 흐름을 정리했습니다.
6. 레지스트리/이미지 정리: dangling 이미지 프루닝과 오래된 태그 이미지 제거 절차를 CI/CD에 추가했습니다.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested reviewers

• wibaek
• whqtker
• JAEHEE25
• lsy1307
• sukangpunch
• Gyuhyeok99

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	PR 제목은 변경의 핵심을 명확하게 요약하고 있으며, 사이드 인프라 배포 과정의 분리라는 주요 변경사항을 잘 나타냅니다.
Description check	✅ Passed	PR 설명은 템플릿을 따르고 있으며, 관련 이슈, 작업 내용, 특이사항, 리뷰 요구사항을 충분히 포함하고 있습니다.
Linked Issues check	✅ Passed	PR의 모든 변경사항이 이슈 #591의 목표인 사이드 인프라 분리를 충족하고 있습니다. dev/prod 환경의 docker-compose.yml 수정, GitHub Actions 워크플로우 개선, 역할 분리가 완벽하게 구현되었습니다.
Out of Scope Changes check	✅ Passed	모든 변경사항이 이슈 #591의 범위 내에 있으며, 사이드 인프라(Redis, Redis-Exporter, Alloy) 분리와 배포 프로세스 개선으로 제한되어 있습니다.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

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

📥 Commits

Reviewing files that changed from the base of the PR and between 1f12fea and d2cc19e.

📒 Files selected for processing (4)

• .github/workflows/dev-cd.yml
• .github/workflows/prod-cd.yml
• docker-compose.dev.yml
• docker-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 파일의 주요 구조 변경에 대해 다음 항목들을 확인해 주세요:

1. Redis 가용성 검증

   • Redis가 실제로 호스트의 127.0.0.1:6379에서 실행 중인지 확인 필요
   • 로컬 개발 환경(docker-compose.local.yml)과 달리, 프로덕션에서는 Redis가 Docker 컨테이너 외부에서 독립 실행되어야 함

2. 포트 노출 및 방화벽 규칙 확인

   • network_mode: "host" 사용으로 컨테이너의 모든 포트(8080, 8081 등)가 호스트에 직접 노출됨
   • 방화벽 규칙이 필요한 포트만 허용하도록 적절히 구성되었는지 검증

3. 네트워크 격리 손실에 따른 보안 검토

   • 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 연결 설정 확인 (개발 환경)

변경사항 확인:

1. network_mode: "host" 적용
2. SPRING_DATA_REDIS_HOST → 127.0.0.1 변경
3. SPRING_DATA_REDIS_PORT → 6379 설정
4. 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 재시작만 수행할 뿐 해당 설정 파일들을 적용하지 않습니다.

배포 전에 다음을 확인하세요:

1. 프로덕션 서버의 Nginx 설정 파일(/etc/nginx/sites-available/ 등)이 최신 상태인지
2. Alloy 설정 파일이 서버에 존재하고 최신 버전인지
3. 설정 변경 시 별도의 수동 배포 프로세스나 관리 절차가 마련되어 있는지

.github/workflows/dev-cd.yml (3)

127-130: 1. 이미지 풀 단계

GHCR 로그인 및 이미지 풀 로직이 올바르게 구현되었습니다.

---

138-147: 3. 이미지 정리 로직

개발 환경에 대한 이미지 정리 로직이 잘 구현되었습니다:

• Dangling 이미지 제거
• 최근 5개 태그를 제외한 이전 이미지 제거

|| true로 정리 실패 시에도 배포가 계속 진행되도록 한 점이 적절합니다.

---

103-111: 4. 설정 파일 전송 제거 확인

프로덕션과 마찬가지로 Alloy 및 Nginx 설정 파일 전송이 제거되었습니다. 개발 서버에 해당 설정들이 사전 배포되어 있는지 확인이 필요합니다.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

.github/workflows/dev-cd.yml (2)

132-136: 배포 후 헬스체크 추가를 권장합니다.

현재 구현은 컨테이너를 재시작하지만 정상 구동 여부를 확인하지 않습니다.

다음과 같은 검증 단계를 추가하면 배포 신뢰성을 높일 수 있습니다:

1. docker compose ps로 컨테이너 상태 확인
2. 로그를 통해 애플리케이션 시작 메시지 확인
3. 헬스 엔드포인트에 대한 간단한 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

📥 Commits

Reviewing files that changed from the base of the PR and between d2cc19e and e2b1ec4.

📒 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 누락 이슈가 수정되었습니다.

1. Line 123-124에서 필요한 환경 변수들을 export하고
2. Line 136에서 docker compose 명령 실행 시 명시적으로 전달하고 있어

docker-compose.dev.yml이 요구하는 변수들을 정상적으로 사용할 수 있습니다.

Also applies to: 136-136

---

135-135: 에러 처리 전략을 확인해 주세요.

|| true를 사용하여 docker compose down 실패를 무시하고 있습니다.

첫 배포 시 중단할 컨테이너가 없는 경우를 대비한 것으로 보이지만, 이로 인해 다음과 같은 실제 문제들도 감춰질 수 있습니다:

1. docker-compose.dev.yml 파일 문법 오류
2. Docker 데몬 권한 문제
3. 네트워크나 볼륨 관련 충돌

더 명확한 에러 처리를 원하신다면 다음과 같은 접근을 고려해 보세요:

# 컨테이너가 존재하는 경우에만 down 실행
if docker compose -f docker-compose.dev.yml ps -q | grep -q .; then
  docker compose -f docker-compose.dev.yml down
fi

현재 방식을 의도적으로 선택하신 것이라면 괜찮습니다.

[Gyuhyeok99]

고생하셨습니다~
궁금한 점들은 회의 때 다 말씀주셔서 문제 없을 거 같습니다!