自制还是官方？openjdk8镜像构建Tomcat镜像的完整实践指南

说实话，我最早在容器里跑Tomcat的时候，图省事，一条docker pull tomcat用完就完事，直到后来要复现一个老项目的部署环境，要求锁定JDK小版本、加上中文字体、还要改时区，这才发现官方tomcat镜像就像一个黑盒，折腾半天不如自己控制openjdk8的底座来得踏实。这篇内容就是围绕“基于自制openjdk8镜像，还是官方openjdk8镜像，去制作tomcat镜像”，把两条路线完整讲清楚：Dockerfile怎么设计、构建完怎么验证、实际运行时有哪些坑，以及我在多次构建和排障中积累的一点经验。无论你是刚接触Docker的新手，还是已经在用Docker但想把Java环境做得更可控的开发者，这篇都能给你一套可直接落地的做法。

1. 先想清楚一件事：你的Tomcat镜像需要怎样的openjdk8底座

1.1 两种openjdk8来源，对应两种完全不同的落地方式

先说结论：我们做tomcat镜像，本质上是做三层结构——操作系统层、JDK运行时层、Tomcat应用服务器层。openjdk8这一层，决定了你镜像的兼容性、体积和维护方式。

官方openjdk8镜像，指的是Docker官方仓库里的openjdk:8-jdk、openjdk:8-jdk-alpine这类镜像，人家已经帮你把JDK装好了，你只需要在Dockerfile里作为基础镜像，再叠加Tomcat即可。这种方式的好处是快、省事，Dockerfile短，几条指令就能构建出可用的tomcat镜像。

自制openjdk8镜像，则是从一个Linux发行版基础镜像开始，自己下载JDK安装包，自己配置JAVA_HOME和PATH，相当于把JDK的安装过程完整复刻到镜像里。这样做的代价是Dockerfile更长、构建时间更久，但换来了对JDK版本的绝对控制，以及能把公司内部的安全基线、证书体系、字体库统一塞进镜像。

那我为什么说这不是“二选一”的关系，而是“分场景”的关系？如果你只是本地测试、快速验证，直接用官方openjdk8镜像就够，别浪费时间自制。但如果你是内网部署、客户要求提供镜像来源说明、或者需要在一个极简操作系统上定制JDK，那自制就是唯一稳妥的路。

1.2 镜像分层原理：基础镜像决定了最终镜像的体积和稳定性

很多人不理解为什么基础镜像的选择会影响那么大，这要从Docker镜像的分层机制说起。Docker镜像实际上是由一层层只读文件系统叠加而成的，Dockerfile里的每条指令（如FROM、RUN、COPY）都可能生成一个层。基础镜像就是最底下的那一层，你后续每增加一层，都会在它上面累加。

所以两个问题会直接由基础镜像决定：第一，体积。官方openjdk:8-jdk底层是Debian或Oracle Linux，体积相对大；而openjdk:8-jdk-alpine底层是Alpine Linux，一个基础层可能只有几十MB，最终镜像能差出两三百MB。第二，依赖包的可用性。如果你在自制镜像时选的系统底座软件源太老，装tzdata或者fontconfig都可能失败，这会直接影响运行时行为。

还有一点容易被忽略：上层镜像依赖的基础镜像如果太大，那么每次docker pull、每次在不同机器间迁移时都很痛苦。镜像分层的原则是，越稳定的东西越要放在下面，越常变的东西越要放在上面。JDK这种基本不动的，就压在底层；Tomcat版本升级频繁，就应该作为上面的层，这样就算升级Tomcat，基础层缓存还能复用，构建速度会快不少。

2. 自制openjdk8镜像：从零把JDK装进容器

2.1 系统底座选型：CentOS、Ubuntu、还是Alpine

自制openjdk8镜像的第一步，是选一个操作系统底座。这一步不能拍脑袋，因为不同底座的包管理器、C库、体积差异巨大，直接影响到后续的Dockerfile写法。

我常用三种方案，简单对比一下：

如果你追求的是“跟生产服务器保持一致”，那就选CentOS系；如果你追求“最小体积”，就选Alpine；如果你只是要一个稳定的运行环境，Ubuntu/Debian最省心。我个人在实际项目中，对内网交付的镜像更倾向用CentOS或Rocky Linux，因为很多老项目的本地库、动态链接库都是按glibc编译的，Alpine的musl libc会踩坑。CentOS 7虽然已经停止更新，但作为运行JDK8这种同样“高龄”的组合，开发环境里是完全没问题的。

2.2 手写openjdk8镜像的Dockerfile

确定底座后，我就开始写Dockerfile。下面这个例子基于CentOS 7，通过解压JDK8的tar.gz包来安装JDK，这样能完全控制JDK的版本和安装目录。

dockerfile复制# 自制openjdk8镜像，基于CentOS 7
FROM centos:7.9.2009

# 解决时区和字体问题
RUN yum install -y tzdata fontconfig \
    && yum clean all \
    && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
    && echo "Asia/Shanghai" > /etc/timezone

# JDK8的tar包，提前下载好放在构建目录里
# 解压后目录名为 jdk8u412-b08，这里重命名为 java
WORKDIR /usr/local
ADD jdk8u412-b08.tar.gz /usr/local/
RUN mv /usr/local/jdk8u412-b08 /usr/local/java

# 配置JAVA_HOME和PATH
ENV JAVA_HOME=/usr/local/java
ENV PATH=${JAVA_HOME}/bin:${PATH}

# 验证安装
RUN java -version && javac -version

CMD ["java", "-version"]

这里面有几个关键点，值得单独说明。

第一，为什么用ADD而不是COPY。ADD会自动解压本地tar.gz包到镜像内，省去一条tar -xf的命令，而COPY只是把文件原样拷进去。对于安装JDK这种固定流程，ADD更顺手。

第二，为什么要装fontconfig。很多人做Java镜像时会把这条忽略掉，结果应用里要生成验证码图片或者导出PDF时，直接报java.lang.NullPointerException: FontConfiguration.getVersion，或者中文字全部变成方块。fontconfig就是用来提供字体管理能力的，建议在自制JDK镜像阶段就装好，别等到应用跑起来再补救。

第三，为什么最后用CMD ["java", "-version"]而不是CMD ["/bin/bash"]。因为我构建这种中间镜像时，通常只是验证JDK是否装好了。用java -version作为默认命令，跑起来就能输出版本信息，一眼确认镜像可用。

2.3 构建、验证、导出导入

Dockerfile写好后，在构建目录里执行：

bash复制docker build -t my-openjdk8:8u412 .

这里有个小细节：docker build的上下文默认是当前目录，所以构建时会把当前目录里所有文件都发给Docker守护进程。如果你把JDK tar包和Dockerfile放在一起，要注意构建目录别放无关的大文件，否则构建命令会把它们统统打包进上下文，拖慢构建速度。我一般会加一个.dockerignore文件：

ignore复制*.tar.gz
*.zip
logs/
.git/

等等，我把jdk8包放这里，那.dockerignore不能把它排除掉。这里要明确：如果你用ADD jdk8u412-b08.tar.gz，那么tar包必须在构建上下文内，不能忽略。.dockerignore里应该忽略的是那些不需要进上下文的零碎文件，比如*.log、.git目录、本地的临时输出。

构建成功后会生成一个镜像，运行验证：

bash复制docker run --rm my-openjdk8:8u412

输出类似：

text复制openjdk version "1.8.0_412"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_412-b08)
OpenJDK 64-Bit Server VM (Temurin)(build 25.412-b08, mixed mode)

就说明自制openjdk8镜像OK了。把镜像推送到内部镜像仓库时，我给镜像打全名：docker tag my-openjdk8:8u412 registry.internal.example.com/base/openjdk8:8u412，方便后续tomcat镜像直接引用。自制的好处此时体现出来了——内部仓库里依赖的基础镜像都是自己可控的，后续不管谁做tomcat镜像，都能锁定这个底子。

3. 基于官方openjdk8镜像制作tomcat镜像

3.1 官方镜像的tag怎么挑

自制openjdk8的路线适合需要深度定制的场景，但如果我要快速搭建一套开发环境，直接用官方openjdk8镜像做底座是最高效的。

官方openjdk8镜像的tag有很多，主要区别在于系统底座和是否包含JDK完整开发工具。openjdk:8-jdk表示带完整JDK，适合需要编译的场景；openjdk:8-jre只带运行环境，体积更小；openjdk:8-jdk-alpine则是基于Alpine Linux的JDK版本，体积最小。

我的建议是：如果只是运行Tomcat，不需要在容器里编译Java代码，选openjdk:8-jre-alpine就够了，能省不少空间。但考虑到Tomcat启动时可能需要额外的JSP编译，实际上JSTL或JSP预编译场景还是会用到javac，所以很多人图省事直接选openjdk:8-jdk-alpine。这里没有绝对标准，我个人的经验是：开发环境用openjdk:8-jdk-alpine，生产环境如果追求最小化，用openjdk:8-jre-alpine，但要多做几轮Tomcat应用验证。

还有一个现实问题：官方openjdk仓库对8系列的新tag推送已经停滞，历史tag仍然能拉取，但如果你发现某个tag拉不下来，也不用慌，可以改用社区维护良好的eclipse-temurin:8-jdk或eclipse-temurin:8-jre作为替代底座，两者的使用方式几乎一样。

3.2 制作tomcat镜像的Dockerfile与参数解析

基于官方openjdk8镜像制作tomcat镜像，逻辑上就是把Tomcat的tar包解压到镜像里，把CATALINA_HOME配好，再让Tomcat以前台方式启动。下面是一个我常用的Dockerfile：

dockerfile复制# 基于官方openjdk8镜像
FROM openjdk:8-jdk-alpine

# 环境变量
ENV TZ=Asia/Shanghai \
    LANG=C.UTF-8 \
    CATALINA_HOME=/usr/local/tomcat \
    PATH=${CATALINA_HOME}/bin:${PATH}

# 修改时区
RUN apk add --no-cache tzdata \
    && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
    && echo "Asia/Shanghai" > /etc/timezone

# 把Tomcat解压到/usr/local/tomcat
WORKDIR /usr/local
ADD apache-tomcat-9.0.98.tar.gz /usr/local/
RUN mv /usr/local/apache-tomcat-9.0.98 /usr/local/tomcat

# 监听端口
EXPOSE 8080

# 启动Tomcat（前台运行，不能后台）
CMD ["catalina.sh", "run"]

这个Dockerfile里有几个参数值得展开讲。

CATALINA_HOME是Tomcat的核心环境变量，Tomcat启动时要根据它找到conf、webapps这些目录。PATH里加上Tomcat的bin目录，是为了在容器内直接执行catalina.sh、startup.sh这些命令。

TZ=Asia/Shanghai和tzdata是一对。Alpine精简到连时区数据库都没有，不装tzdata，就算设置了TZ也不生效。如果直接用debian底座的官方openjdk镜像，它内置了时区数据，但在Debian类系统上有时需要额外设置/etc/timezone，所以我在两个路线里都统一装了tzdata并做了软链。

catalina.sh run必须用run参数，不能用start。这个我在后面“容器秒退”的常见问题里还会详细说，这里先记住一个结论：在容器里启动Tomcat，一定要前台运行，否则PID 1进程会立刻退出，容器也跟着退出。

3.3 构建并启动你的tomcat容器

构建命令和之前类似：

bash复制docker build -t my-tomcat:9.0.98 .

注意，Tomcat版本和解压目录名一定要对得上。比如你下载的是apache-tomcat-9.0.98.tar.gz，解压出来就是apache-tomcat-9.0.98，Dockerfile里的mv命令才能正确重命名。

构建完成以后，启动一个容器：

bash复制docker run -d -p 8080:8080 --name tomcat-demo my-tomcat:9.0.98

然后访问http://localhost:8080，能看到Tomcat默认页面说明镜像正常。不过我要提醒一点：Tomcat 9之后默认页面上是有/manager入口的，但Tomcat容器内部默认没有用户在tomcat-users.xml里配置权限，你是点不进去的，这属于正常现象。后面要部署应用，直接挂载webapps即可：

bash复制docker run -d -p 8080:8080 \
  -v /data/webapps:/usr/local/tomcat/webapps \
  --name tomcat-demo \
  my-tomcat:9.0.98

这样宿主机/data/webapps里的WAR包或者目录会直接映射到Tomcat的webapps目录，免去进入容器拷贝的麻烦。

4. 核心细节：时区、JVM、日志、部署方式，一个都不能少

4.1 容器时区与中文字体

很多Java应用跑到容器里，第一反应就是“日志时间不对”，查半天发现容器默认是UTC时区，比北京时间慢了8小时。这个问题在制作tomcat镜像时最好就处理掉，别等出了日志再补救。

我分别在两条路线里都加了时区处理：

• 自制openjdk8镜像时，在基础镜像阶段就安装了tzdata，并把Asia/Shanghai软链到/etc/localtime。
• 基于官方openjdk8-alpine镜像时，用apk add tzdata安装，再做同样的软链。

这里有个细节：如果你不用软链，只是设置ENV TZ=Asia/Shanghai，在某些Java环境中不一定生效。因为Java读取时区时会走系统接口，/etc/localtime才是系统真正依赖的时区文件。所以稳妥的做法是软链复制二选一，而不是只设环境变量。

中文字体问题也类似。很多Java报表、验证码图片需要加载系统字体，如果镜像里没有字体文件，中文会显示成方框。自制JDK镜像时我装了fontconfig，如果还缺具体的TTF字体，还可以额外COPY一份字体文件到/usr/share/fonts/目录，然后fc-cache -f刷新缓存。

4.2 JVM参数在Dockerfile中的正确传法

Tomcat本身是Java应用，它的启动参数是通过catalina.sh读取JAVA_OPTS和CATALINA_OPTS两个环境变量来生效的。很多人在Dockerfile里写了ENV JAVA_OPTS="-Xms256m -Xmx1g"，但其实并没有真正传给Tomcat，原因就是变量名没配对。

Tomcat 8.5之后的catalina.sh脚本里，CATALINA_OPTS是专门给Tomcat运行时的参数（比如JVM调优参数），JAVA_OPTS则会传给所有Java进程。如果你只是要调Tomcat的内存，用CATALINA_OPTS就够了。正确的做法是在Dockerfile里写：

dockerfile复制ENV CATALINA_OPTS="-Xms512m -Xmx1g -Dfile.encoding=UTF-8"

也可以在运行容器时通过-e传：

bash复制docker run -d -p 8080:8080 \
  -e CATALINA_OPTS="-Xms512m -Xmx1g" \
  --name tomcat-demo \
  my-tomcat:9.0.98

关于内存设置有个不得不提的问题：很多老一点的JDK8版本在容器里默认不感知cgroup内存限制，你给容器限制-m 512m，结果JVM还是按宿主机的内存大小分配堆内存，很容易导致容器被OOM Killer杀掉。JDK 8u191以后默认开启了UseContainerSupport，如果你用的是更新的8u版本问题不大；但如果锁定了老版本，建议在CATALINA_OPTS里显式加上：

text复制-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0

MaxRAMPercentage的意思是让JVM最多使用容器限定内存的75%，留一部分给堆外内存、线程栈和元空间。这个比例可以根据实际业务调，我一般从75%起步。

4.3 日志收集与应用部署

Tomcat在容器里启动后，日志一般会输出到两个地方：标准输出/标准错误（stdout/stderr）和容器内的logs目录。因为我们用catalina.sh run前台启动，主进程的日志会打到stdout，可以通过docker logs tomcat-demo查看，这是最简单的方式。但应用本身的log4j日志如果写到了容器内的某个文件，那docker logs是看不到的，需要把日志目录挂载到宿主机：

bash复制docker run -d -p 8080:8080 \
  -v /data/logs/tomcat:/usr/local/tomcat/logs \
  -v /data/webapps:/usr/local/tomcat/webapps \
  --name tomcat-demo \
  my-tomcat:9.0.98

这样既方便本地排查，也能让日志收集组件直接读取宿主机目录，避免进入容器拷贝。

应用部署的方式主要有三种：第一种，把WAR包直接COPY进Dockerfile，适合发布固定版本；第二种，挂载webapps目录，适合频繁迭代、想要热更新的场景；第三种，使用docker cp临时拷贝，适合快速验证。我个人的做法是：测试阶段用挂载，发布阶段用构建进镜像，这样镜像可以回滚，不会因为挂载目录内容变了导致版本漂移。

5. 常见问题与排查技巧实录

5.1 容器秒退、端口不通、镜像平台不匹配

这三个问题是我做tomcat镜像时遇到最多的，挨个说。

容器启动后秒退，docker logs里如果有类似Neither the JAVA_HOME nor the JRE_HOME environment variable is defined的报错，说明Tomcat找不到JDK。但更常见的是没有任何报错，容器就是立刻退出，此时多半是Dockerfile里把启动命令写成了startup.sh。Tomcat的startup.sh会启动一个新进程并把Tomcat放入后台，容器里的PID 1进程跑完命令后认为任务结束，直接退出，整个容器随之销毁。正确写法前面强调过：catalina.sh run，保证Tomcat在前台运行，PID 1进程一直活着。

端口不通的原因比较多，我踩过的坑有三类。一类是宿主机端口被占用，docker run -p 8080:8080报端口冲突，换一个宿主机端口映射即可，比如-p 18080:8080。一类是Tomcat的server.xml里Connector监听了127.0.0.1，那容器外部就访问不到，需要改成0.0.0.0。还有一类是云环境的安全组策略挡了端口，这个和镜像本身无关，但排障时容易走弯路。

平台不匹配的问题在Apple Silicon的Mac上尤其常见。官方openjdk8镜像很多都是linux/amd64的，你在ARM机器上拉取时，Docker会提示平台不匹配，甚至启动失败。临时解决办法是在运行或构建时加--platform linux/amd64强制指定平台：

bash复制docker run --platform linux/amd64 -p 8080:8080 my-tomcat:9.0.98

但这种方式依赖模拟层，性能会有损耗。更彻底的办法是寻找该版本的linux/arm64镜像，或者自制openjdk8镜像时选择支持arm64的OS底座。

5.2 乱码、时区不对、JVM识别不了内存限制

乱码问题的根因通常是字符集。镜像里没有设置LANG环境变量，Java默认按系统区域设置读取文件，一旦应用处理中文就容易乱码。我一般在Dockerfile里加ENV LANG=C.UTF-8。但要注意，C.UTF-8这个locale在Alpine里存在，在CentOS的yum安装环境里不一定完整，所以自制JDK镜像时可以改成ENV LANG=en_US.UTF-8，具体看你选择的底座支持哪些locale。

时区不对虽然启动时能看出来，但很多人是在凌晨收到告警后才发现日志时间早了8小时，难受得很。排查方法很简单：docker exec <container> date，如果输出是UTC时间，说明时区没有生效。修复时不要只在Dockerfile里设ENV TZ，执行ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime是更稳的一步。如果你已经用-e TZ=Asia/Shanghai运行容器但没生效，多半是镜像里缺tzdata，需要在基础镜像里补装。

JVM不识别内存限制的问题，表现是容器限制-m 512m，但JVM启动时按宿主机内存计算堆大小，导致容器被OOM Kill，docker inspect里能看到OOMKilled: true。遇到这种问题，先确认JDK版本，再在CATALINA_OPTS里显式设置-XX:MaxRAMPercentage=75.0或直接给-Xmx。我建议生产环境显式指定-Xms和-Xmx，既防止JVM启动时做太多动态内存探测，也便于运维提前评估容量。

5.3 镜像体积膨胀与构建缓存

自制openjdk8镜像如果基于CentOS，装完JDK和依赖后体积很容易突破500MB，加上Tomcat后可能到600MB甚至更多。这对网络传输和存储都是一种浪费。我做镜像瘦身时主要用三个手段：

第一，安装依赖后立刻执行包管理器清理。yum用yum clean all，apt用apt-get clean，apk用rm -rf /var/cache/apk/*。这些命令要在同一个RUN指令里和安装命令连着写，避免中间层缓存把安装包残留下来。

第二，选择更小的基础镜像。Dockerfile同样的一套逻辑，从CentOS换成Alpine，最终镜像体积可能缩小一半以上。前提是应用本身不依赖glibc特性，否则就要回到CentOS/Debian路线。

第三，谨慎使用多阶段构建。很多人想把编译Tomcat应用的事也塞进Dockerfile里，多阶段构建可以把编译工具链留在临时镜像，最终镜像只保留编译产物。这个思路很值得推广，但要注意别把构建依赖误删了，比如JSP例程如果依赖javac，那你的最终镜像还是需要JDK而不是JRE。

构建缓存也是一个容易被忽略的坑。Docker构建时，如果当前指令和之前的指令没有变化，会直接用缓存层，这确实快，但有时会害了你。比如你修改了本地jdk8u412-b08.tar.gz，但文件名没变，Docker会认为这个ADD指令没有变化，直接复用缓存。解决办法是构建时加--no-cache强制重建，或者更改文件名让缓存失效。

5.4 常见问题速查表

我把这几年做tomcat镜像遇到的问题整理成一张表，方便大家直接对照排查。

最后一条“Tomcat启动很慢”值得多说一句。Java应用在启动过程中要生成安全随机数，默认读/dev/random，如果宿主机熵源不足会导致阻塞，表现就是Tomcat迟迟起不来。显式指定file:/dev/./urandom是常见解法，这个参数在容器环境里几乎成了标配，我希望更多人能提前加进镜像，而不是等启动卡住了再查。

最后再分享一点实践体会

在自制和官方两条路线之间来回切换过之后，我的个人感受是：官方openjdk8镜像适合作为“默认选项”，它能帮你快速得到一个能跑的tomcat镜像，省时省力；自制openjdk8镜像是“可控选项”，当你需要锁定JDK版本、添加系统依赖、统一内网基线时，它才是正解。两者不是非要分个高下，而是看你的项目处于什么阶段、对交付物有什么要求。

另外，我做tomcat镜像时养成了一个习惯：每次构建完，必定执行docker history <image>看一眼镜像分层，确认关键指令都生效了，没有多余的大文件被带进去。有一次我发现自己多COPY了一个几百MB的日志目录，就是靠这个命令发现的。镜像层面的问题，越早看越容易发现，等到应用运行起来再排查，成本就高多了。希望这篇内容能让你在制作自己的tomcat镜像时少绕几个弯路。