chore: Dockerfile 세팅 및 CI/CD스크립트 리팩터링 #20
Conversation
📝 Walkthrough""" WalkthroughCI/CD 워크플로우가 리팩토링되어 기존의 단일 Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant GitHub Actions
participant Docker Hub
participant Deployment Server
Developer->>GitHub Actions: 코드 푸시/PR 트리거
GitHub Actions->>GitHub Actions: Docker Buildx 설정 및 로그인
GitHub Actions->>Docker Hub: Docker 이미지 빌드 및 푸시
GitHub Actions->>Deployment Server: SSH로 배포 스크립트 실행 (이미지 태그 참조)
Assessment against linked issues
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (4)
🧰 Additional context used🧠 Learnings (1)📓 Common learnings🪛 Checkov (3.2.334)Dockerfile[LOW] 1-34: Ensure that HEALTHCHECK instructions have been added to container images (CKV_DOCKER_2) [LOW] 1-34: Ensure that a user for the container has been created (CKV_DOCKER_3) 🔇 Additional comments (9)
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🔭 Outside diff range comments (1)
.github/workflows/dev-ci-cd.yml (1)
108-113:IMAGE_TAG변수에 개행 포함 가능성
needs.build-and-push.outputs.tags는 여러 줄 값을 반환합니다. dev 서버 스크립트에서 파싱 오류가 생길 수 있으니 prod와 동일하게 첫 줄만 사용하세요.- export IMAGE_TAG="${{ needs.build-and-push.outputs.tags }}" + export IMAGE_TAG="$(echo "${{ needs.build-and-push.outputs.tags }}" | head -n1)"
♻️ Duplicate comments (1)
Dockerfile-dev (1)
9-12:ARG MODULE재선언 누락으로 동일 문제 반복
위Dockerfile과 동일한 이유로 COPY 단계가 실패할 수 있습니다. 동일한 수정이 필요합니다.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/dev-ci-cd.yml(3 hunks).github/workflows/prod-ci-cd.yml(4 hunks)Dockerfile(1 hunks)Dockerfile-dev(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: hoonyworld
PR: YAPP-Github/26th-App-Team-1-BE#17
File: .github/workflows/ci-pr.yml:8-9
Timestamp: 2025-07-01T09:50:45.498Z
Learning: hoonyworld 사용자는 Naver 코드 포맷터를 사용하며, 이 포맷터는 YAML 배열의 대괄호 내부에 자동으로 여분의 공백을 추가하는 특성이 있음.
🪛 Checkov (3.2.334)
Dockerfile
[LOW] 1-12: Ensure that HEALTHCHECK instructions have been added to container images
(CKV_DOCKER_2)
[LOW] 1-12: Ensure that a user for the container has been created
(CKV_DOCKER_3)
🔇 Additional comments (2)
Dockerfile (1)
11-11:*.jar와일드카드가 여러 아티팩트를 매칭할 가능성
멀티 모듈 프로젝트이거나original-·plain-JAR 등이 함께 존재할 경우 가장 마지막 파일이 덮어씌워질 위험이 있습니다.
경로를 명시적으로 지정하거나*boot.jar등으로 좁혀 주세요..github/workflows/prod-ci-cd.yml (1)
111-115:IMAGE_TAG변수 파싱은 dev/prod 간 일관성 유지
dev에서 수정 제안한 것과 동일하게, prod에서도tags출력이 다중 줄일 수 있지만 이미head -n1을 사용 중입니다. dev 워크플로 수정 후 두 환경이 동일한 패턴을 갖도록 확인 바랍니다.
Dockerfile
Outdated
| # Run stage | ||
| FROM openjdk:21-slim | ||
| WORKDIR /app | ||
| COPY --from=build /app/${MODULE}/build/libs/*.jar app.jar | ||
| ENTRYPOINT ["java", "-jar", "app.jar"] |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
런타임 스테이지 보안 강화를 위해 비-root 사용자 및 HEALTHCHECK 추가 권장
FROM openjdk:21-slim
+RUN useradd --system --uid 10001 appuser \
+ && mkdir /app && chown -R appuser:appuser /app
WORKDIR /app
COPY --from=build /app/${MODULE}/build/libs/*.jar app.jar
+USER appuser
+HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/actuator/health || exit 1
ENTRYPOINT ["java", "-jar", "app.jar"]📝 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.
| # Run stage | |
| FROM openjdk:21-slim | |
| WORKDIR /app | |
| COPY --from=build /app/${MODULE}/build/libs/*.jar app.jar | |
| ENTRYPOINT ["java", "-jar", "app.jar"] | |
| # Run stage | |
| FROM openjdk:21-slim | |
| RUN useradd --system --uid 10001 appuser \ | |
| && mkdir /app && chown -R appuser:appuser /app | |
| WORKDIR /app | |
| COPY --from=build /app/${MODULE}/build/libs/*.jar app.jar | |
| USER appuser | |
| HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/actuator/health || exit 1 | |
| ENTRYPOINT ["java", "-jar", "app.jar"] |
🧰 Tools
🪛 Checkov (3.2.334)
[LOW] 1-12: Ensure that HEALTHCHECK instructions have been added to container images
(CKV_DOCKER_2)
[LOW] 1-12: Ensure that a user for the container has been created
(CKV_DOCKER_3)
🤖 Prompt for AI Agents
In Dockerfile lines 8 to 12, enhance runtime stage security by adding a non-root
user to run the application instead of root, and include a HEALTHCHECK
instruction to monitor container health. Create a user with limited permissions,
switch to that user before running the app, and define a HEALTHCHECK command
that periodically verifies the app is responsive.
Dockerfile-dev
Outdated
| # Build stage | ||
| FROM gradle:8.7-jdk21 AS build | ||
| ARG MODULE=apis | ||
| WORKDIR /app | ||
| COPY . . | ||
| RUN ./gradlew :${MODULE}:bootJar --no-daemon | ||
|
|
||
| # Run stage | ||
| FROM openjdk:21-slim | ||
| WORKDIR /app | ||
| COPY --from=build /app/${MODULE}/build/libs/*.jar app.jar | ||
| ENTRYPOINT ["java", "-jar", "app.jar"] |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
개발용 Dockerfile도 비-root 사용자·HEALTHCHECK 적용 권장
로컬/CI 환경이라도 최소한의 보안 수칙을 동일하게 유지하는 편이 좋습니다.
🤖 Prompt for AI Agents
In Dockerfile-dev lines 1 to 12, the Dockerfile currently runs as root and lacks
a HEALTHCHECK instruction. To improve security and reliability, add a non-root
user and switch to it before running the application. Also, include a
HEALTHCHECK instruction that periodically verifies the app's health, such as by
checking the HTTP endpoint or process status. This ensures better security
practices and container health monitoring even in development environments.
| id: meta | ||
| uses: docker/metadata-action@v5 | ||
| with: | ||
| images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} | ||
| tags: | | ||
| type=raw,value=development-latest | ||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
태그 전략 개선 권장 – development-latest 단일 태그는 충돌 위험
동시 커밋에서 같은 태그가 덮어써지면 롤백·디버깅이 어려워집니다. SHA 짧은값 또는 날짜를 추가해 고유 태그를 병행 저장하는 방식을 고려해 주세요.
예시:
tags: |
type=raw,value=development-${{ github.sha }}
type=raw,value=development-latest
🤖 Prompt for AI Agents
In .github/workflows/dev-ci-cd.yml around lines 73 to 79, the current tagging
strategy uses only the single tag "development-latest," which risks tag
collisions during concurrent commits. To fix this, modify the tags input to
include a unique tag using the short SHA or date along with
"development-latest." For example, add a tag like "development-${{ github.sha
}}" before "development-latest" to ensure each build has a unique tag for better
rollback and debugging.
.github/workflows/dev-ci-cd.yml
Outdated
| - name: Run full Gradle build and test | ||
| run: ./gradlew build --parallel --build-cache |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Gradle 컴파일이 두 번 발생 → 빌드 시간 불필요 증가
build 잡에서 이미 ./gradlew build를 수행했지만, docker build 단계가 다시 소스 전체를 복사해 내부에서 Gradle 빌드를 반복합니다.
아티팩트를 업로드‧다운로드해서 Docker 컨텍스트로 넘기거나, --build-arg BUILT_JAR 방식으로 한 번만 빌드하도록 리팩터링하면 5~7 분 단축됩니다.
🤖 Prompt for AI Agents
In .github/workflows/dev-ci-cd.yml around lines 49 to 50, the Gradle build is
executed twice, causing unnecessary build time increase. Refactor the workflow
to run the Gradle build only once by uploading the built artifacts after the
initial build step and then downloading them in the Docker build step, or pass
the built JAR as a build argument using --build-arg BUILT_JAR. This avoids
copying the entire source and rebuilding inside the Docker context, reducing
build time by 5 to 7 minutes.
| build-args: | | ||
| MODULE=${{ env.MODULE }} | ||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
build-args에 추가 인자 여지 확보
현재 MODULE만 전달하지만, JAR 이름 또는 빌드 프로파일 등 추가 인자가 필요해질 수 있습니다. 다중 줄 블록을 유지하면서 주석으로 향후 확장성을 명시해 두면 유지보수에 도움이 됩니다.
🤖 Prompt for AI Agents
In .github/workflows/prod-ci-cd.yml around lines 93 to 95, the build-args
currently only pass the MODULE variable. To allow future expansion for
additional arguments like JAR name or build profile, keep the multi-line block
format and add a comment above or within the build-args section indicating that
more build arguments can be added here later. This improves maintainability by
explicitly noting the potential for extension.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
Dockerfile (1)
9-13: 비-root 사용자·HEALTHCHECK 추가 권장
보안 및 운영 신뢰성을 위해 런타임 스테이지에서 non-root 사용자로 전환하고 헬스체크를 설정하세요. 과거에도 동일 제안을 드린 바 있습니다.FROM openjdk:21-slim ARG MODULE=apis WORKDIR /app +RUN useradd --system --uid 10001 appuser \ + && chown -R appuser:appuser /app COPY --from=build /app/${MODULE}/build/libs/*SNAPSHOT.jar app.jar +USER appuser +HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/actuator/health || exit 1 ENTRYPOINT ["java", "-jar", "app.jar"]Dockerfile-dev (1)
9-13: 비-root 사용자·HEALTHCHECK 누락
운영-용 Dockerfile과 동일한 보안/가용성 수칙을 개발 이미지에도 적용하는 편이 좋습니다.FROM openjdk:21-slim ARG MODULE=apis WORKDIR /app +RUN useradd --system --uid 10001 appuser \ + && chown -R appuser:appuser /app COPY --from=build /app/${MODULE}/build/libs/*SNAPSHOT.jar app.jar +USER appuser +HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/actuator/health || exit 1 ENTRYPOINT ["java", "-jar", "app.jar"]
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
Dockerfile(1 hunks)Dockerfile-dev(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: hoonyworld
PR: YAPP-Github/26th-App-Team-1-BE#17
File: .github/workflows/ci-pr.yml:8-9
Timestamp: 2025-07-01T09:50:45.498Z
Learning: hoonyworld 사용자는 Naver 코드 포맷터를 사용하며, 이 포맷터는 YAML 배열의 대괄호 내부에 자동으로 여분의 공백을 추가하는 특성이 있음.
🪛 Checkov (3.2.334)
Dockerfile
[LOW] 1-13: Ensure that HEALTHCHECK instructions have been added to container images
(CKV_DOCKER_2)
[LOW] 1-13: Ensure that a user for the container has been created
(CKV_DOCKER_3)
🔇 Additional comments (1)
Dockerfile (1)
10-10: ARG 재선언 문제 해결 👍
ARG MODULE를 런타임 스테이지에서도 다시 선언해 지난 코멘트의 빌드 실패 가능성을 제거했습니다.
|
move-hoon
changed the title
| # 의존성 캐싱 최적화를 위한 단계별 복사 | ||
| # 1. 의존성 관련 파일만 먼저 복사 | ||
| COPY build.gradle settings.gradle ./ | ||
| COPY ${MODULE}/build.gradle ./${MODULE}/ | ||
|
|
||
| # 2. 소스코드 없이 의존성만 다운로드 | ||
| RUN ./gradlew :${MODULE}:dependencies --no-daemon | ||
|
|
||
| # 3. 소스코드 전체 복사 | ||
| COPY . . | ||
|
|
There was a problem hiding this comment.
궁금한게 의존성 캐싱처리했을 때와 캐싱하지 않았을 경우 빌드차이속도가 어느정도 나는지 궁금하네요!
혹시 한번 테스트가능할까요!?
| # JVM 실행 설정 | ||
| # - Xms512m: 초기 힙 메모리 512MB | ||
| # - Xmx1g: 최대 힙 메모리 1GB | ||
| ENTRYPOINT ["java", "-Xms512m", "-Xmx1g", "-jar", "app.jar"] |
There was a problem hiding this comment.
현재 EC2 기본 인스턴스(1GB 메모리)에서 MySQL, Redis, Nginx, 그리고 Java 기반 애플리케이션까지 함께 구동하고자 하는 상황인데, 메모리가 다소 부족할 수 있을 것 같아 별도로 스왑 메모리를 설정해놓았는데 제대로 버틸지 의문이긴하네요 256MB로 조금이나마 작게 가져가는건 어떨까요 너무적을까요!?
🔗 관련 이슈
📘 작업 유형
📙 작업 내역
🧪 테스트 내역
🎨 스크린샷 또는 시연 영상 (선택)
✅ PR 체크리스트
💬 추가 설명 or 리뷰 포인트 (선택)
Summary by CodeRabbit
Chores
New Features