chore/38 - ci 설정 - #39
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 Walkthrough개요프로덕션 환경 배포를 위한 통합 인프라를 구축합니다. GitHub Actions CI/CD 워크플로우를 추가하여 테스트 자동화와 ECR 이미지 배포를 구현하고, Dockerfile을 멀티스테이지 빌드로 전환하며, Spring Boot 프로덕션 설정과 Prometheus 모니터링을 설정합니다. 변경사항프로덕션 배포 인프라
예상 코드 검토 시간🎯 3 (중간 복잡도) | ⏱️ ~20분 관련 이슈
관련된 PR
제안 검토자
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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: 3
🧹 Nitpick comments (1)
.github/workflows/ci-prod.yml (1)
50-53: ⚡ Quick winPR 이벤트에서도 Docker 이미지 빌드를 수행하고 있습니다.
현재는
pull_request에서도 이미지를 빌드해 CI 시간이 늘어납니다. 배포 파이프라인 목적이 push 경로라면 build 단계도 push로 제한하는 게 더 일관적입니다.수정 예시
- name: Build Docker image # 이미지 빌드해서 + if: github.event_name == 'push' run: | docker build --build-arg SERVER_PORT=${{ vars.SERVER_PORT }} -t ${{ vars.ECR_REGISTRY }}/${{ vars.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }} .🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci-prod.yml around lines 50 - 53, The Docker image build is running for pull_request events causing unnecessary CI time; restrict the build to push events by guarding the build step or job (the step named "Build Docker image" that runs the docker build command) with an event check (e.g., only run when github.event_name == 'push' or move the step into a job that has a push-only trigger) so the image build executes only on push/deploy paths; update the workflow triggers/step condition accordingly and keep the existing docker build arguments and tags unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Dockerfile`:
- Around line 12-20: The Dockerfile runs the runtime container as root because
there is no USER instruction; update the Dockerfile to create and switch to a
non-root user before the ENTRYPOINT so the JVM process runs with least
privileges (e.g., add steps to create a group/user, chown /app to that user, and
add a USER <username> line placed before ENTRYPOINT); reference the existing
WORKDIR /app, the copied app.jar, and the ENTRYPOINT
["java","-jar","/app/app.jar"] so the new user owns /app and runs the jar.
In `@src/main/resources/application-prod.yml`:
- Around line 29-31: 현재 application-prod.yml의 jpa.hibernate.ddl-auto가 update로
설정되어 있어 프로덕션에서 스키마가 런타임에 변경될 수 있으니 값을 validate로 변경하세요; application-prod.yml 파일에서
jpa.hibernate.ddl-auto: update를 jpa.hibernate.ddl-auto: validate로 바꾸고, 데이터베이스
스키마 변경은 Flyway/ Liquibase 같은 명시적 마이그레이션 도구로 관리하도록 관련 배포 문서나 CI/CD 파이프라인을 업데이트하여
프로덕션과 Docker 환경이 동일한 검증 방식을 사용하도록 보장하세요.
- Line 36: Change the production YAML to stop logging SQL and exposing health
details: set show-sql to false (replace the current show-sql: true) and add or
update the management.endpoint.health.show-details property to a restrictive
value like never (or when-authorized) so health endpoint details are not exposed
publicly; target the settings shown as show-sql and
management.endpoint.health.show-details in application-prod.yml.
---
Nitpick comments:
In @.github/workflows/ci-prod.yml:
- Around line 50-53: The Docker image build is running for pull_request events
causing unnecessary CI time; restrict the build to push events by guarding the
build step or job (the step named "Build Docker image" that runs the docker
build command) with an event check (e.g., only run when github.event_name ==
'push' or move the step into a job that has a push-only trigger) so the image
build executes only on push/deploy paths; update the workflow triggers/step
condition accordingly and keep the existing docker build arguments and tags
unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 3a5710b2-ec5d-4791-b249-a8a418fec3c6
⛔ Files ignored due to path filters (1)
gradle/wrapper/gradle-wrapper.jaris excluded by!**/*.jar
📒 Files selected for processing (5)
.github/workflows/ci-prod.yml.gitignoreDockerfilebuild.gradlesrc/main/resources/application-prod.yml
| jpa: | ||
| hibernate: | ||
| ddl-auto: update |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# application-prod.yml 파일이 존재하는지 확인하고 내용 읽기
if [ -f "src/main/resources/application-prod.yml" ]; then
echo "=== application-prod.yml 파일 내용 ==="
cat -n "src/main/resources/application-prod.yml"
else
echo "파일을 찾을 수 없습니다."
# 유사한 파일들 찾아보기
echo "=== 유사한 설정 파일 찾기 ==="
find . -name "application*.yml" -o -name "application*.yaml" 2>/dev/null | head -20
fiRepository: Miche-Let/inventory-service
Length of output: 2188
🏁 Script executed:
# 프로젝트 구조 확인
echo "=== 프로젝트 구조 확인 ==="
ls -la src/main/resources/ 2>/dev/null || echo "resources 디렉토리 없음"Repository: Miche-Let/inventory-service
Length of output: 550
🏁 Script executed:
# 다른 환경 파일들의 ddl-auto 설정 확인
echo "=== application-docker.yml 중 ddl-auto 설정 ==="
grep -A 2 "ddl-auto" src/main/resources/application-docker.yml 2>/dev/null || echo "설정 없음"
echo -e "\n=== application-local.yml 중 ddl-auto 설정 ==="
grep -A 2 "ddl-auto" src/main/resources/application-local.yml 2>/dev/null || echo "설정 없음"
echo -e "\n=== application-perf.yml 중 ddl-auto 설정 ==="
grep -A 2 "ddl-auto" src/main/resources/application-perf.yml 2>/dev/null || echo "설정 없음"
echo -e "\n=== application.yml 중 ddl-auto 설정 ==="
grep -A 2 "ddl-auto" src/main/resources/application.yml 2>/dev/null || echo "설정 없음"Repository: Miche-Let/inventory-service
Length of output: 366
🏁 Script executed:
# Hibernate 프로젝트 설정에서 JPA/Hibernate 버전 확인
echo "=== Maven/Gradle 설정에서 Hibernate 버전 확인 ==="
if [ -f "pom.xml" ]; then
grep -i "hibernate\|spring-data-jpa\|spring-boot" pom.xml | head -20
elif [ -f "build.gradle" ] || [ -f "build.gradle.kts" ]; then
grep -i "hibernate\|spring-data-jpa\|spring-boot" build.gradle* | head -20
fiRepository: Miche-Let/inventory-service
Length of output: 795
프로덕션 환경에서 ddl-auto: update 설정을 validate로 변경해야 합니다.
런타임에 자동으로 스키마를 변경하면 예기치 않은 드리프트와 장애가 발생할 수 있습니다. Docker 환경에서는 이미 validate를 사용 중이므로, 프로덕션도 동일하게 설정하고 명시적 마이그레이션으로 관리하는 것이 안전합니다.
수정 예시
jpa:
hibernate:
- ddl-auto: update
+ ddl-auto: validate📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| jpa: | |
| hibernate: | |
| ddl-auto: update | |
| jpa: | |
| hibernate: | |
| ddl-auto: validate |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/main/resources/application-prod.yml` around lines 29 - 31, 현재
application-prod.yml의 jpa.hibernate.ddl-auto가 update로 설정되어 있어 프로덕션에서 스키마가 런타임에
변경될 수 있으니 값을 validate로 변경하세요; application-prod.yml 파일에서 jpa.hibernate.ddl-auto:
update를 jpa.hibernate.ddl-auto: validate로 바꾸고, 데이터베이스 스키마 변경은 Flyway/ Liquibase
같은 명시적 마이그레이션 도구로 관리하도록 관련 배포 문서나 CI/CD 파이프라인을 업데이트하여 프로덕션과 Docker 환경이 동일한 검증
방식을 사용하도록 보장하세요.
| hibernate: | ||
| default_schema: inventory_service | ||
| format_sql: true | ||
| show-sql: true |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "application-prod.yml" -type fRepository: Miche-Let/inventory-service
Length of output: 113
🏁 Script executed:
cat -n ./src/main/resources/application-prod.ymlRepository: Miche-Let/inventory-service
Length of output: 2153
🌐 Web query:
Spring Boot show-sql production security best practice
💡 Result:
In production environments, you should always set spring.jpa.show-sql=false [1][2]. Enabling this property is considered a security and operational anti-pattern for several reasons [3][2][4]. Why spring.jpa.show-sql is not suitable for production: 1. Security Risk: It can inadvertently expose sensitive data, database schema details, or internal logic in your application logs [2]. 2. Performance Impact: It writes directly to standard output (System.out) without the optimizations, filtering, or asynchronous handling provided by professional logging frameworks [3][5][4]. This can cause significant performance degradation under heavy load [2]. 3. Log Noise: It generates excessive, unformatted output that fills up log files rapidly, making it difficult to identify actual application errors or security incidents [2][4]. 4. Limited Utility: It only displays the prepared statement structure (with question marks for parameters), which is often insufficient for debugging complex issues [2]. Recommended Best Practices: If you need to inspect SQL queries for troubleshooting, use the following approaches instead of show-sql: 1. Use Logging Frameworks: Configure your logging framework (e.g., Logback) to capture SQL at the appropriate level. This allows you to route logs to files, filter them, and manage them according to your organization's retention policies [5][4]. - To log SQL statements: Set logging.level.org.hibernate.SQL=DEBUG [5][6][4]. - To log parameter values: Set logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE [5][2][6][4]. 2. Use Spring Profiles: Always restrict these logging configurations to non-production profiles (e.g., dev or test) using Spring Profiles [2]. Ensure your production configuration explicitly disables them [1]. 3. Use Interceptors (Advanced): For more robust or customized logging, consider using a library like DataSource-Proxy [3][5]. This allows you to intercept JDBC calls, format them, and log them consistently without relying on Hibernate-specific properties [3][5]. Security Note: While logging SQL is a debugging tool, it is not a substitute for proper security measures. Always protect against SQL injection by using parameterized queries (which Spring Data JPA does automatically when using standard repository methods or @Query with named/indexed parameters) and avoiding manual string concatenation in queries [7][8][9].
Citations:
- 1: https://medium.com/@shahharsh172/spring-boot-security-best-practices-a-developers-complete-guide-e91c49dfd5d3
- 2: https://runebook.dev/en/articles/spring_boot/application-properties/application-properties.data.spring.jpa.show-sql
- 3: https://vladmihalcea.com/log-sql-spring-boot
- 4: https://medium.com/@patelsajal2/learn-how-to-enable-logging-of-sql-statements-in-spring-boot-with-this-comprehensive-tutorial-48c06bc080ab
- 5: https://www.baeldung.com/sql-logging-spring-boot
- 6: https://stackoverflow.com/questions/30118683/how-can-i-log-sql-statements-in-spring-boot
- 7: https://blog.stackademic.com/spring-boot-sql-injection-protection-guide-86b131de185c
- 8: https://stackoverflow.com/questions/73617743/is-springboot-data-jpa-repository-safe-against-sql-injection
- 9: https://medium.com/@AlexanderObregon/sql-injection-guards-in-spring-boot-with-prepared-queries-f1f12c3b52c2
🌐 Web query:
Spring Boot management.endpoint.health.show-details production security best practice
💡 Result:
In production environments, setting management.endpoint.health.show-details to always is generally considered a security risk and is not recommended [1][2][3]. The health endpoint is often exposed to monitoring systems (like Kubernetes liveness/readiness probes) that may not be authenticated [1][4][5]. If show-details is set to always, the endpoint may reveal sensitive internal information—such as database connection details, disk space paths, or other infrastructure-specific data—to anyone who can access the endpoint [1][3][4]. Best Practices for Production: 1. Use when-authorized: Instead of always, set management.endpoint.health.show-details to when-authorized [1][2]. This ensures that detailed health information is only visible to authenticated users with appropriate roles, while unauthenticated users (or monitoring tools) receive only the basic status [1][2]. 2. Configure Roles: When using when-authorized, you can define which roles are permitted to see the details using the management.endpoint.health.roles property [1][2]. 3. Secure Actuator Endpoints: Always protect your Actuator endpoints using Spring Security [6][7]. If you must expose the health endpoint for monitoring, ensure your security configuration explicitly permits access to the basic health status for those monitoring tools while restricting access to the detailed information [1][2][6]. 4. Limit Exposure: Only expose the endpoints you absolutely need [6][7]. Use management.endpoints.web.exposure.include to explicitly list required endpoints (e.g., health, info, prometheus) rather than using a wildcard (*) [6][4][7]. 5. Use a Separate Management Port: For enhanced security, consider running Actuator on a separate management port (management.server.port) that is not publicly accessible and can be protected by a firewall [6]. If you have secured your application and specifically require the always setting, ensure your security configuration explicitly permits access to the health endpoint for both authenticated and unauthenticated users, acknowledging the potential information disclosure [1][2].
Citations:
- 1: https://docs.spring.io/spring-boot/docs/3.0.13/reference/html/actuator.html
- 2: https://docs.spring.io/spring-boot/reference/actuator/endpoints.html
- 3: https://dev.to/jtorchia/spring-security-with-spring-boot-actuator-the-authorization-model-that-survived-the-incident-391i
- 4: https://medium.com/@akashpadir10/spring-boot-actuator-health-checks-make-your-java-app-production-ready-ae5aaafa0aaa
- 5: https://stackoverflow.com/questions/62669831/should-spring-boot-cloud-actuator-be-disabled-in-production
- 6: https://medium.com/@sarveshkhamkar321/spring-boot-actuator-your-applications-built-in-health-monitor-7b9692890ef4
- 7: https://dev.to/codereacher_20b8a/securing-spring-boot-actuator-endpoints-a-must-for-production-13pi
운영 환경의 SQL 및 헬스 엔드포인트에서 민감 정보 노출
show-sql: true는 SQL 쿼리와 데이터베이스 스키마를 로그에 노출시키며, 성능 저하를 유발합니다. show-details: always는 인증되지 않은 사용자도 데이터베이스 연결 정보와 내부 인프라 정보에 접근할 수 있게 합니다. 두 설정 모두 프로덕션 환경에서 비활성화해야 합니다.
수정 예시
- show-sql: true
+ show-sql: false
@@
health:
- show-details: always
+ show-details: when-authorized🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/main/resources/application-prod.yml` at line 36, Change the production
YAML to stop logging SQL and exposing health details: set show-sql to false
(replace the current show-sql: true) and add or update the
management.endpoint.health.show-details property to a restrictive value like
never (or when-authorized) so health endpoint details are not exposed publicly;
target the settings shown as show-sql and
management.endpoint.health.show-details in application-prod.yml.
2 participants
📝 작업 내용
🚀 주요 변경 사항
✅ 자체 체크리스트 (필수)
./gradlew build실행 결과 정상 (인증샷 첨부)📸 테스트 인증샷
💬 리뷰어 전달사항 (선택)
📎 참고 자료
Summary by CodeRabbit
릴리스 노트
New Features
Chores