ci(#154): 실서버 배포 환경 NCP에서 OCI로 이관#155
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the deployment script deploy-prod.sh to run the Docker container with host networking, pass the server port as an environment variable, and update the host path for the application.yml volume mount. The review feedback highlights two critical issues: first, mounting the configuration file to /application.yml instead of /app/application.yml may prevent Spring Boot from locating it; second, using --network host poses security risks and potential port conflicts, so maintaining bridge networking with port mapping is recommended.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| docker run -d --name "$TARGET_NAME" \ | ||
| --network host \ | ||
| -e SERVER_PORT=${TARGET_PORT} \ | ||
| -v /home/ubuntu/quizly-server/application.yml:/application.yml \ |
There was a problem hiding this comment.
현재 Dockerfile을 보면 WORKDIR /app으로 설정되어 있어, 컨테이너 내부의 작업 디렉토리는 /app입니다.
Spring Boot는 기본적으로 작업 디렉토리(./) 또는 ./config/ 등에서 설정 파일을 찾습니다. 따라서 호스트의 application.yml을 컨테이너의 루트 디렉토리인 /application.yml에 마운트하게 되면, Spring Boot가 이 외부 설정 파일을 인식하지 못하고 jar 내부의 기본 설정만 사용하게 되는 문제가 발생할 수 있습니다.
이로 인해 실서버 환경의 데이터베이스 연결 정보나 API 키 등 외부 설정이 정상적으로 적용되지 않아 애플리케이션 구동 실패나 오동작으로 이어질 수 있습니다.
안정적인 설정을 위해 마운트 경로를 /app/application.yml 또는 /app/config/application.yml로 변경하는 것을 권장합니다.
| -v /home/ubuntu/quizly-server/application.yml:/application.yml \ | |
| -v /home/ubuntu/quizly-server/application.yml:/app/application.yml \ |
References
- 유지보수성·확장성·안정성 관점에서 왜 문제인지 근거를 함께 설명하고 대안을 제시해야 합니다. (link)
There was a problem hiding this comment.
현재 CI/CD 구조에서 docker 이미지 빌드 전에 yml 주입하여 jar를 빌드하고 있어서 Spring Boot가 jar 내부에서 설정 파일 사용 중 (볼륨 마운트 코드는 이전에 배포 시 사용하던 코드가 남아있는 것으로 추측)
볼륨 마운트 라인과 서버로의 설정 파일 전송 스텝을 함께 제거하여 수정
런타임 외부 주입 방식도 고민했으나 기존 방식을 유지하기로 결정
GHCR이 private으로 운영되고 있어 이미지 접근이 팀원으로 제한되고 급하게 클라우드 서비스를 변경해야 할 경우 서버에 별도 파일 없이 이미지 단독으로 바로 구동 가능
| docker run -d --name "$TARGET_NAME" -p "${TARGET_PORT}:8080" \ | ||
| -v /root/quizly-server/application.yml:/application.yml \ | ||
| docker run -d --name "$TARGET_NAME" \ | ||
| --network host \ |
There was a problem hiding this comment.
현재 --network host 옵션을 사용하여 컨테이너가 호스트의 네트워크 네임스페이스를 직접 공유하도록 변경되었습니다.
--network host를 사용하면 포트 포워딩 없이 호스트 포트에 직접 바인딩하므로 네트워크 성능 이점이 있을 수 있으나, 컨테이너 간의 네트워크 격리(Isolation)가 해제되어 보안상 취약해질 수 있습니다. 또한 호스트의 다른 프로세스나 컨테이너와 포트 충돌이 발생할 위험이 커집니다.
만약 특별한 성능상의 이유나 호스트 네트워크 직접 접근이 필요한 상황이 아니라면, 기존처럼 브릿지 네트워크를 사용하고 포트 매핑(-p ${TARGET_PORT}:${TARGET_PORT})을 유지하는 것이 컨테이너 환경의 격리성과 보안성을 유지하는 데 더 안전합니다.
References
- 안정성 및 보안 관점에서 문제가 발생할 수 있는 부분을 지적하고 대안을 제시해야 합니다. (link)
There was a problem hiding this comment.
보안 측면에서 Bridge 네트워크가 더 안전하다고 생각하지만 다만 현재 운영 서버의 Redis가 Docker 컨테이너로 사용 중
Bridge 네트워크로 전환하면 컨테이너 내부의 localhost가 호스트가 아닌 컨테이너 자신을 가리키게 되어 Redis 못 잡아서 현재 방식 유지
2 participants
연관 이슈
작업 사항
deploy-prod.sh) 수정테스트
주의 사항 및 참고사항
main에만 적용되면 되는 사항으로mainmerge 완료 후dev를main기준으로 rebase하여 정렬 예정