企业官网建设流程全解析

• 文档

本指南以 Docker Official Images 中eclipse-temurin镜像的官方文档（eclipse-temurin/content.md）为核心，系统讲解如何基于 Eclipse Temurin 构建的 OpenJDK 镜像运行 Java 应用、如何用jlink定制精简 JRE、如何将内部 CA 证书注入 JVM 信任库，并覆盖镜像变体与标签体系的选择策略。读完本文，你将掌握一套可直接复制、可投入生产使用的容器化 Java 部署方案。

什么是 Eclipse Temurin

Eclipse Temurin 是一个开源项目，它提供代码与构建流程，用于支撑运行时二进制文件及相关技术的构建。其产出的二进制具备高性能、企业级、跨平台、开源许可，并通过 Java SE TCK 测试，面向整个 Java 生态系统提供通用能力。

本仓库中的eclipse-temurin镜像所包含的，正是由 Eclipse Temurin 项目构建的 OpenJDK 二进制（见 content.md 的 Overview 描述）。官方对这类镜像的定位是：既可作为一次性容器（挂载源码后直接启动应用），也可作为构建其他镜像的基础层（见 README.md 对eclipse-temurin:<version>变体的说明）。

快速开始：运行一个预构建的 Jar

使用最新的 OpenJDK 25 镜像运行预构建的 jar 文件，Dockerfile 如下：

FROM eclipse-temurin:25 RUN mkdir /opt/app COPY japp.jar /opt/app CMD ["java", "-jar", "/opt/app/japp.jar"]

构建并运行：

docker build -t japp . docker run -it --rm japp

两点实操说明：

• CMD使用 JSON 数组形式（exec form），直接以java进程作为容器主进程，信号传递与进程管理更符合容器惯例。
• -it --rm便于交互式调试且退出后自动清理容器；若面向生产或后台运行，可去掉-it并配合-d。

从宿主挂载 Jar 文件

如果希望 jar 文件保留在宿主机上、不打进镜像，可以直接挂载宿主目录：

FROM eclipse-temurin:25 CMD ["java", "-jar", "/opt/app/japp.jar"]

docker build -t japp . docker run -it -v /path/on/host/system/jars:/opt/app japp

此时宿主目录/path/on/host/system/jars被挂载到容器内的/opt/app，无需重建镜像即可切换应用版本，适合本地开发调试场景。

迁移 JDK：使用其他基础镜像

官方镜像基于特定发行版构建；如果你需要部署到官方未提供的发行版之上，可以用多阶段COPY --from把 JDK 整体搬移过去：

# Example FROM <base image> ENV JAVA_HOME=/opt/java/openjdk COPY --from=eclipse-temurin:25 $JAVA_HOME $JAVA_HOME ENV PATH="${JAVA_HOME}/bin:${PATH}"

这里有两个关键约定：

• JAVA_HOME固定为/opt/java/openjdk：这是 Eclipse Temurin 镜像内 JDK 的统一安装路径，COPY --from引用同一路径即可无痛迁移。
• PATH必须显式追加${JAVA_HOME}/bin：迁入新基础镜像后，java、javac等命令默认不在PATH中，需要手动导出。

用 jlink 创建精简 JRE（OpenJDK 21+）

官方文档明确建议：虽然所有 Eclipse Temurin 版本都提供 JRE 镜像，但更推荐使用jlink生成自定义的精简 JRE，只保留应用真正需要的模块，从而显著缩小镜像体积。

OpenJDK 21 及以上版本支持以下多阶段构建方式：

# Example of custom Java runtime using jlink in a multi-stage container build FROM eclipse-temurin:25 as jre-build # Create a custom Java runtime RUN $JAVA_HOME/bin/jlink \ --add-modules java.base \ --strip-debug \ --no-man-pages \ --no-header-files \ --compress=2 \ --output /javaruntime # Define your base image FROM debian:buster-slim ENV JAVA_HOME=/opt/java/openjdk ENV PATH "${JAVA_HOME}/bin:${PATH}" COPY --from=jre-build /javaruntime $JAVA_HOME # Continue with your application deployment RUN mkdir /opt/app COPY japp.jar /opt/app CMD ["java", "-jar", "/opt/app/japp.jar"]

对上述jlink参数的逐项说明：

整个流水线分为两段：第一段（jre-build阶段）基于完整的eclipse-temurin:25裁剪出最小运行时；第二段以debian:buster-slim这种更小的基础镜像承载该运行时，并在其上继续部署应用。最终交付的镜像只包含精简运行时 + 应用 jar，体积与攻击面都远小于完整 JDK 镜像。

注意：jlink 生成的运行时是一个"定制 JDK"，模块集合由--add-modules决定；如果应用在运行时动态加载模块（如反射使用未包含的 API、使用 ServiceLoader 扩展），需要把这些模块显式加进列表，否则会抛ModuleNotFoundException。

将内部 CA 证书注入 JVM 信任库

企业内网环境通常存在自建 CA。官方文档提供了把内部 CA 证书注入镜像的受支持方案，适用于除 Windows 系镜像外的所有镜像变体。

证书格式与挂载位置

• 证书格式取决于基础镜像的操作系统预期，PEM 格式、扩展名为.crt是最稳妥的选择。
• 证书需要放入容器内的/certificates目录（例如通过 volume 挂载）。
• 必须通过环境变量USE_SYSTEM_CA_CERTS显式开启证书处理（变量值为任意非空值即可）。

使用 Docker CLI 的完整示例：

$ docker run -v $(pwd)/certs:/certificates/ -e USE_SYSTEM_CA_CERTS=1 eclipse-temurin:25

底层处理机制

证书处理由镜像内置的入口脚本/__cacert_entrypoint.sh完成：

• 开启后，证书会被同时写入JVM 信任库（供 Java 程序使用）和系统 CA 存储（供curl等 CLI 工具使用）。
• 如果你覆盖了镜像默认的 entrypoint 脚本，必须手动调用/__cacert_entrypoint.sh才能启用证书处理。

受限环境下的差异（如 Red Hat OpenShift）

默认拒绝特权的环境（典型如 Red Hat OpenShift）会带来两类差异，需要在方案设计时留意：

1. 容器以非rootUID 运行

由于默认 JVM 信任库与系统 CA 存储都不可被非root用户写入：

• 系统 CA 存储不会被更新；
• JVM 会获得一个独立的信任库，你的证书会被加入其中；
• 镜像会自动扩展JAVA_TOOL_OPTIONS环境变量，把 JVM 切换到该新信任库；
• 新信任库的路径会通过JRE_CACERTS_PATH环境变量导出。若你覆盖了默认 entrypoint，需要手动让 JVM 感知这个新信任库（例如在启动命令中通过-Djavax.net.ssl.trustStore=$JRE_CACERTS_PATH指定）。

2. 容器以只读文件系统运行

限制与非rootUID 场景相同，额外要求是：必须在/tmp挂载一个可写卷，因为创建新信任库的过程需要可写临时目录。

官方说明指出该特性已在多种场景下测试，但依然存在偶发边界情况的可能；如遇异常，可到adoptium/containers仓库的 issues 中反馈。

镜像变体与标签体系

eclipse-temurin镜像提供多种风味（variant），每种面向特定使用场景（详见 README.md）。

eclipse-temurin:<version>（默认变体）

这是事实上的默认镜像。若不明确自己的需求，优先选用它。它基于 Ubuntu 构建，标签中可能出现的jammy、noble、resolute是 Ubuntu 发行版代号：

• 如果镜像中需要安装额外软件包，建议显式指定具体的 Ubuntu 代号标签（如25-noble），以避免新 Ubuntu 发布时基础层变化带来的意外破坏；
• 而像25、25-jdk、latest这类**共享标签（Shared Tags）**会跟随最新基础版本滚动，适合对可复现性要求不高的场景。

eclipse-temurin:<version>-alpine

基于 Alpine Linux 官方镜像，Alpine 基础层仅约 5MB，整体镜像显著更小巧，适合镜像体积优先的场景。两个注意事项：

• Alpine 使用musl libc而非 glibc，部分对 libc 依赖较深的软件可能遇到兼容问题；
• 为最小化体积，Alpine 变体通常不预装git、bash等额外工具，需要在自有 Dockerfile 中按需添加。

eclipse-temurin:<version>-windowsservercore

基于 Windows Server Core，仅适用于 Windows 10 Professional/Enterprise（Anniversary Edition）及 Windows Server 2016 以上的 Windows 容器环境，且不支持前文所述的自定义 CA 证书注入方案。

标签命名解读

从 README.md 的标签列表可以归纳出命名规则：

• Simple Tags（简单标签）：形如8u504-b01-jdk-alpine-3.24、17-jdk-noble、25-jre，依次包含「JDK 精确版本 / 大版本 + jdk|jre + 基础系统（alpine、ubuntu 代号、ubi、windowsservercore、nanoserver）+ 系统版本」；
• Shared Tags（共享标签）：形如8-jdk、17、25、latest，聚合多个平台架构（多架构 manifest 列表），latest当前指向 OpenJDK 25（见 README.md）；
• 每个大版本同时维护jdk与jre两类镜像，例如25-jdk与25-jre。

支持的架构

官方镜像覆盖amd64、arm32v7、arm64v8、ppc64le、riscv64、s390x及windows-amd64（见 README.md），可依托 Docker 的多架构拉取能力在对应平台上直接使用。

许可证与维护信息

• 镜像的 Dockerfile 及相关脚本采用Apache License 2.0；
• 镜像内安装的 OpenJDK 采用GNU GPL v2 with Classpath Exception；
• 与所有 Docker 镜像一样，镜像内还可能包含基础发行版的其他软件（如 Bash 等）及其直接/间接依赖，使用者有责任确认全部软件的使用符合相应许可证（详见 license.md）。

镜像由 Adoptium 维护，获取帮助可通过 Adoptium Slack 与 Adoptium Support；与 Eclipse Temurin 本体无关的漏洞（例如 Ubuntu 自身漏洞）应提交给对应项目本身（参见 get-help.md 与 issues.md）。

小结

围绕eclipse-temurin官方镜像，本文覆盖了四条主线：直接用 JDK 镜像运行 jar、用COPY --from把 JDK 迁移到任意基础镜像、用jlink在多阶段构建中裁剪出最小 JRE、以及通过USE_SYSTEM_CA_CERTS//__cacert_entrypoint.sh向 JVM 与系统信任库注入内部 CA 证书，并兼顾了非rootUID、只读文件系统等受限运行环境的差异。生产落地时，只需结合自身 Java 版本与依赖模块，即可将上述 Dockerfile 直接改造复用。

• 文档