Fix Dockerfile: update OpenJDK base image to a valid tag #6
Conversation
WalkthroughUpdated the Dockerfile: switched the builder base image to Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ 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: 2
🧹 Nitpick comments (1)
Dockerfile (1)
23-26: Consider usingeclipse-temurin:17-jre-alpinefor a more optimized runtime image.The switch to Eclipse Temurin for the deployer stage aligns well with the builder stage (line 8) and modernizes from the deprecated
openjdk:17-alpine. However, for runtime containers, using the JRE-only variant (17-jre-alpine) would be more appropriate than JDK, reducing image size by excluding unnecessary build tools.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Dockerfile(2 hunks)
🧰 Additional context used
🪛 Hadolint (2.14.0)
Dockerfile
[error] 13-13: COPY with more than 2 arguments requires the last argument to end with /
(DL3021)
Dockerfile
Outdated
|
|
||
| # Copy source code from local to container | ||
| COPY . /app | ||
| COPY . /appFROM openjdk:17-jdk-alpine as deployer |
There was a problem hiding this comment.
Critical syntax error: Two Docker commands concatenated into one line.
Line 13 contains a malformed command that concatenates COPY and FROM instructions. This will cause the Docker build to fail immediately with a syntax error.
Apply this diff to fix the syntax error:
-COPY . /appFROM openjdk:17-jdk-alpine as deployer
+COPY . /app📝 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.
| COPY . /appFROM openjdk:17-jdk-alpine as deployer | |
| COPY . /app |
🧰 Tools
🪛 Hadolint (2.14.0)
[error] 13-13: COPY with more than 2 arguments requires the last argument to end with /
(DL3021)
🤖 Prompt for AI Agents
In Dockerfile around line 13, the line currently concatenates two Docker
instructions ("COPY . /appFROM openjdk:17-jdk-alpine as deployer"); split this
into two separate lines so each Dockerfile directive stands alone: place "COPY .
/app" on its own line and "FROM openjdk:17-jdk-alpine as deployer" on its own
line; if this is intended to start a new build stage, ensure the FROM line
begins the stage (move it before any stage-specific COPY if necessary).
| # FROM maven:3.8.3-openjdk-17 as builder | ||
| # Import docker image with Maven and JDK 17 (from Eclipse Temurin) | ||
| FROM maven:3.8.3-eclipse-temurin-17 as builder |
There was a problem hiding this comment.
Consider upgrading to a newer Maven version instead of 3.8.3.
The maven:3.8.3-eclipse-temurin-17 tag appears to exist on Docker Hub, but it is not part of the actively maintained tags. Current supported Maven images use 3.9.11 or later versions with Eclipse Temurin. Since the PR objective is to fix unavailable base images, upgrading to maven:3.9.11-eclipse-temurin-17 or maven:3.8.9-eclipse-temurin-17 would be preferable for receiving security updates and ongoing support.
The eclipse-temurin:17-jdk-alpine image tag is actively available and appropriate for the deployer stage.
🤖 Prompt for AI Agents
In Dockerfile around lines 6 to 8, the base image uses an older, unmaintained
tag `maven:3.8.3-eclipse-temurin-17`; update the builder stage to a supported
Maven tag such as `maven:3.9.11-eclipse-temurin-17` (or at minimum
`maven:3.8.9-eclipse-temurin-17`) to ensure security updates and ongoing
support, and for the deployer stage prefer switching to an actively maintained
JDK runtime like `eclipse-temurin:17-jdk-alpine` as suggested by replacing the
FROM lines accordingly.
| # FROM openjdk:17-alpine as deployer | ||
| # Use eclipse-temurin:17-jdk-alpine for runtime | ||
| FROM eclipse-temurin:17-jdk-alpine as deployer |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
eclipse-temurin 17-jdk-alpine Docker image
💡 Result:
Summary — eclipse-temurin:17-jdk-alpine
- What it is: the Eclipse Temurin OpenJDK 17 JDK packaged on an Alpine Linux base (musl libc). [1][2]
- Official source: image published on Docker Hub as eclipse-temurin:17-jdk-alpine. [1][2]
- Typical notes: smaller image size (Alpine) but uses musl instead of glibc — some Java native libraries or JVM features may be incompatible or require workarounds. Test your app on the image before production. [2][3]
- Pull command:
docker pull eclipse-temurin:17-jdk-alpine. [1]
References
[1] Docker Hub — eclipse-temurin (image / tags).
[2] Docker Hub — image layer / eclipse-temurin:17-jdk-alpine.
[3] EchoHQ / ecosystem notes on Temurin Alpine variants (compatibility discussion).
🌐 Web query:
eclipse-temurin 17-jdk-alpine security vulnerabilities
💡 Result:
Short answer: eclipse-temurin:17-(jdk|jre)-alpine images have shown multiple security alerts tied to vulnerable Alpine packages and a few Java CVEs; fixes usually require rebuilding the Alpine-based image (to pick up updated Alpine/OpenJDK packages) or switching to a non‑Alpine Temurin image. Sources and examples below.
Evidence / notes
- Users reported a high‑severity libexpat/Alpine package vulnerability affecting Alpine-based Temurin images (issue discussion in docker-library). [1]
- Adoptium maintainers/issues show specific CVE reports against eclipse-temurin:17-jre-alpine (example: CVE-2024-8176) and requests to rebuild the image to remediate. [2]
- Several CVEs affecting Java/Graal/OpenJDK packaged in Alpine appear in vulnerability databases; Rapid7 lists multiple Alpine/Java CVEs (CVE-2024-20955, CVE-2024-21211, CVE-2023-22025, etc.) that have been surfaced for Alpine Java builds. [3][4][5]
Recommendations
- If you rely on alpine images, rebuild or pull the latest eclipse-temurin:17-jdk-alpine image once the upstream image is rebuilt (or rebuild your own from a current alpine base) to get patched Alpine packages. [1][2]
- Alternatively, use the non‑Alpine Temurin 17 images (e.g., debian/buster‑slim or slim variants) until the Alpine images are rebuilt, since many reports recommend that as a mitigation. [1][2]
Sources
- docker-library issue re: libexpat / Alpine affecting temurin images.
- adoptium/adoptium-support issue: eclipse-temurin:17-jre-alpine vulnerability (CVE-2024-8176).
- Rapid7 — Alpine Linux CVE‑2024‑20955.
- Rapid7 — Alpine Linux CVE‑2024‑21211.
- Rapid7 — Alpine Linux CVE‑2023‑22025.
(If you want, I can check the current Temurin 17 Alpine image build date and list exact CVE IDs affecting the exact image digest you use.)
🌐 Web query:
openjdk alpine image deprecated
💡 Result:
Short answer: The official openjdk Docker image (including many alpine tags) is deprecated/removed. The Docker Official Image maintainers deprecated the openjdk repo and many Alpine-based OpenJDK tags were discontinued because upstream OpenJDK builds are glibc‑based (Alpine uses musl), causing compatibility and build/support issues. Migrate to a maintained distribution (examples: eclipse‑temurin, amazoncorretto, ibm‑semeru, liberica/zulu where available) or use glibc‑based slim Debian images. [1][2][3]
Actionable links:
- Docker Hub deprecation notice for openjdk. [1]
- docker-library/openjdk (DEPRECATED) repo. [2]
- Explanation of why Alpine OpenJDK tags were removed (musl vs glibc / upstream builds). [3]
References:
[1] Docker Hub — openjdk (deprecation notice).
[2] docker-library/openjdk (GitHub) — DEPRECATED.
[3] Discussion / explanation (StackOverflow / docker-library PRs) about Alpine (musl) incompatibility with upstream OpenJDK builds.
Reconsider the Eclipse Temurin Alpine variant due to known vulnerabilities.
While moving from the deprecated openjdk:17-alpine to a maintained distribution is the correct direction, eclipse-temurin:17-jdk-alpine images have shown multiple security alerts tied to vulnerable Alpine packages and a few Java CVEs. Recent vulnerabilities include CVE-2024-8176 and other CVEs affecting Alpine/Java packages (CVE-2024-20955, CVE-2024-21211, CVE-2023-22025).
Additionally, Alpine uses musl instead of glibc — some Java native libraries or JVM features may be incompatible or require workarounds.
Recommended mitigations:
- Use a non-Alpine Temurin 17 variant (e.g.,
eclipse-temurin:17-jdk-slimor debian-based) instead, or - Ensure strict vulnerability scanning (e.g., Trivy/Snyk) in CI/CD and commit to rebuilding the Alpine image regularly to pick up patched Alpine packages.
🤖 Prompt for AI Agents
In Dockerfile around lines 23 to 25, the base image was changed to
eclipse-temurin:17-jdk-alpine which has known Alpine- and Java-related CVEs and
musl incompatibilities; replace that image with a non-Alpine Temurin 17 variant
(for example use eclipse-temurin:17-jdk-slim or another debian-based Temurin 17
image) by updating the FROM line, ensure the image tag or digest is pinned for
reproducibility, and add/enable vulnerability scanning (Trivy/Snyk) in CI and a
policy to regularly rebuild base images to pick up security fixes.
|
@Amitabh-DevOps Changes made: Stage 1: Updated builder image from maven:3.8.3-openjdk-17 to maven:3.8.3-eclipse-temurin-17. Stage 2: Updated runtime image from openjdk:17-alpine to eclipse-temurin:17-jdk-alpine to reduce final image size while maintaining compatibility. |
1 participant
@Amitabh-DevOps
I noticed that the Dockerfile was using the
openjdk:17-alpinetag, which seems to be unavailable, causing build issues. I've replaced it with theeclipse-temurin:17-jdk-alpineimage, which is a stable and well-supported JDK 17 base image from the Eclipse Temurin project. This change should resolve the issue and improve build consistency.Changes:
FROM openjdk:17-alpinetoFROM eclipse-temurin:17-jdk-alpineSummary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.