build/Dockerfile 추가 및 애플리케이션 실행 환경 설정 #3
Conversation
There was a problem hiding this comment.
Pull request overview
이 PR은 Spring Boot 애플리케이션을 컨테이너화하기 위한 Dockerfile을 추가합니다. GitHub Actions CD 파이프라인과 Kubernetes 배포 환경을 지원하며, 보안 모범 사례를 따르도록 비루트 사용자로 실행되도록 구성되어 있습니다.
주요 변경사항:
- Eclipse Temurin 21 JRE를 기반으로 한 Docker 이미지 정의
- UID 10001의 비루트 사용자로 애플리케이션 실행
- Gradle 빌드 산출물(bootJar)을 선택적으로 복사 및 실행
|
|
||
| # GitHub Actions에서 ./gradlew clean test build 로 생성된 산출물 사용 | ||
| # (주의) build/libs 에 plain.jar 와 bootJar가 같이 생길 수 있어 bootJar를 선택하도록 처리 | ||
| COPY build/libs/*.jar /app/ |
There was a problem hiding this comment.
문제점: COPY 명령어가 와일드카드(*.jar)를 사용하고 있어, build/libs 디렉터리에 JAR 파일이 없을 경우 빌드가 실패합니다.
영향: GitHub Actions에서 빌드 과정이 실패하거나 JAR 파일이 없는 경우 Docker 빌드가 실패하여 배포 파이프라인이 중단됩니다.
수정 제안: build/libs 디렉터리를 전체 복사한 후 필터링하거나, COPY 실패 시 명확한 에러 메시지를 제공하도록 처리하는 것을 권장합니다. 또는 --chown 옵션을 사용하여 복사와 동시에 소유권을 설정할 수 있습니다.
| RUN set -eux; \ | ||
| JAR="$(ls /app/*.jar | grep -v -- '-plain\.jar$' | head -n 1)"; \ | ||
| mv "$JAR" /app/app.jar; \ |
There was a problem hiding this comment.
문제점: JAR 파일을 선택하는 로직에서 JAR 파일이 하나도 없거나, grep 결과가 비어있을 때 mv 명령이 실패할 수 있습니다. 현재 'set -e'가 포함된 'set -eux'를 사용하고 있어 JAR 변수가 비어있으면 mv 명령이 실패하여 Docker 빌드가 중단됩니다.
영향: 예상치 못한 빌드 환경에서 Docker 이미지 빌드가 실패하며, 디버깅이 어려울 수 있습니다.
수정 제안: JAR 변수가 비어있는지 확인하는 검증 로직을 추가하여 명확한 에러 메시지를 제공하는 것을 권장합니다. 예: [ -z "$JAR" ] && echo "No bootJar found" && exit 1
| # JVM 옵션은 Kubernetes 매니페스트에서 JAVA_TOOL_OPTIONS로 주입 권장 | ||
| ENTRYPOINT ["java","-jar","/app/app.jar"] |
There was a problem hiding this comment.
문제점: ENTRYPOINT에서 JVM 옵션이 하드코딩되어 있지 않아 기본 설정으로 실행됩니다. 메모리 제한이 없는 환경에서는 JVM이 과도한 메모리를 사용할 수 있으며, 컨테이너 OOMKilled 위험이 있습니다.
영향: Kubernetes에서 resources.limits.memory를 512Mi로 설정했으나(k8s/deployment.yaml:77), JVM이 이를 인식하지 못하고 더 많은 메모리를 할당하려 하면 컨테이너가 종료될 수 있습니다.
수정 제안: 기본적인 JVM 메모리 설정을 ENTRYPOINT에 포함하거나, 주석에 명시된 대로 Kubernetes deployment에 JAVA_TOOL_OPTIONS 환경 변수를 추가하여 메모리 설정을 관리하는 것을 권장합니다. 예: -XX:MaxRAMPercentage=75.0
| # 비루트 실행(쿠버네티스 securityContext와도 정합성 좋음) | ||
| RUN useradd -r -u 10001 -g root appuser \ | ||
| && mkdir -p /app \ | ||
| && chown -R 10001:0 /app |
There was a problem hiding this comment.
문제점: Dockerfile에서 UID 10001로 비루트 사용자를 생성하여 보안을 강화했으나, Kubernetes deployment.yaml에 해당하는 securityContext 설정이 없어 정합성이 부족합니다.
영향: Dockerfile에서 설정한 보안 정책이 Kubernetes에서 명시적으로 적용되지 않아, Pod Security Standards를 준수하지 못하거나 예상치 못한 권한으로 실행될 수 있습니다.
수정 제안: k8s/deployment.yaml의 containers 섹션에 securityContext를 추가하여 runAsUser: 10001, runAsNonRoot: true, allowPrivilegeEscalation: false 등을 명시적으로 설정하는 것을 권장합니다.
|
|
||
| # 비루트 실행(쿠버네티스 securityContext와도 정합성 좋음) | ||
| RUN useradd -r -u 10001 -g root appuser \ | ||
| && mkdir -p /app \ |
There was a problem hiding this comment.
문제점: WORKDIR /app을 설정한 후, RUN 명령에서 다시 mkdir -p /app을 실행하고 있습니다. WORKDIR은 디렉터리가 없으면 자동으로 생성하므로 중복된 작업입니다.
영향: 불필요한 명령어로 인해 Docker 이미지 빌드 시간이 증가하고, 코드의 명확성이 떨어집니다.
수정 제안: mkdir -p /app 명령을 제거하거나, WORKDIR 설정 전에 사용자 생성 및 디렉터리 생성을 함께 처리하는 것을 권장합니다.
| && mkdir -p /app \ |
변경된 점