Java 8应用容器化：自制Tomcat+JDK8 Docker镜像实战指南

镜像封装这件事，只要有几年Java后端容器化经验的都不会陌生。我自己在把一个遗留的Java 8项目往Docker上迁移时，第一反应是直接docker pull tomcat拿官方包用，结果折腾一圈后发现官方镜像虽然开箱即用，但和我们的生产环境差了点意思：时区不对、日志量大、加密套件和字符集配置得重新改，连基础镜像到底用的什么发行版都得去查文档。于是干脆按项目自己封装了一版，把openjdk8和tomcat揉进同一个镜像里，一套构建脚本走完，推到私有仓库后各环境直接复用。

这个主题适合两类人：一类是刚把Java Web应用容器化、被官方镜像配置整得焦头烂额的新手，另一类是想把基础镜像纳入配置管理、实现环境统一交付的团队。我会把两种构建路径都讲清楚——基于官方openjdk8镜像直接叠tomcat，以及从底层自制openjdk8镜像再封装tomcat，包括各自的Dockerfile写法、启动脚本、踩坑记录和参数取舍，照着做就能在本地复现。

1. 内容整体设计与思路拆解

1.1 官方tomcat镜像为什么不够用

很多人会问：官方不是有tomcat:8.5-jdk8这种现成镜像吗，何必费劲自己做？这话对了一半。官方镜像适合快速验证、跑demo，但拿到生产环境就会暴露一堆实际问题。

首先是时区。官方镜像默认时区是UTC，容器起来后date命令输出的时间和北京时间差8小时，而老项目很多地方直接用new Date()拼文件名、写日志，时间一错位整个链路都不对。其次字符集也有隐患，官方镜像通常精简过系统组件，某些中文字体或locale缺失，如果应用里要生成验证码图片、导出带中文的Excel，字体渲染就会变成豆腐块。更大的隐患是官方tomcat镜像默认以root用户启动进程，这在等保和容器安全扫描时属于明显风险项，很多公司过不了这关。

之后还得面对依赖管理的问题。官方镜像的构建过程不透明，更新了哪个补丁、哪个组件版本我们是不可控的，出安全漏洞之后没法快速溯源。与其在别人封装好的黑盒上做修补，不如把openjdk和tomcat的版本、参数、配置都写进自家的Dockerfile，纳入Git管理，每次构建都有迹可循，这才是镜像自制的核心价值。

1.2 两条技术路线的核心差异

所谓“自制openjdk8镜像”和“官方openjdk8镜像”，本质区别在基础层。官方openjdk:8uXXX-jdk镜像自带一个精简操作系统加JDK，我们只需要在这个基础上叠加tomcat层，构建速度快、体积也比较小。而自制openjdk8镜像是指我们自己选一个基础Linux发行版，比如centos:7或者ubuntu:20.04，自己把JDK的tar包解压进去，再叠加tomcat层。

两条路线的选择标准，我是这么看的：

• 追求快速交付、镜像体积敏感、且能接受官方包管理方式，直接基于官方openjdk镜像改，省时省力。
• 需要严格锁定JDK小版本、需要集成特定系统库、或有等保和供应链合规要求，走自制路线，把所有层都握在自己手里。

有人可能觉得自制路线更专业，但实际上自制意味着要自己处理glibc版本、openssl兼容、时区数据等一堆底层问题，维护成本明显更高。我更建议的做法是：把官方openjdk镜像作为基础层，再用多阶段构建和配置覆盖的方式注入我们的定制内容，兼顾可维护性和可控性。本文两种方案都会给出，你可以根据项目阶段选择。

2. 核心细节解析与实操要点

2.1 JDK与Tomcat版本匹配关系

在动手写Dockerfile之前，先确认版本组合，这是最容易翻车的地方。JDK8和Tomcat的Servlet规范关系看似宽松，但要注意大版本边界。

如果你的项目用了javax.servlet包，Tomcat 10默认不兼容，必须改命名空间，这对老系统是伤筋动骨的事。我一般给Java 8项目配Tomcat 8.5.100或者Tomcat 9.0.x，前者稳妥，后者功能新一点。本次示例选择Tomcat 8.5.100 + JDK8u202，这是目前兼容性最稳、踩坑最少的组合。

另外JDK小版本也有讲究。Oracle JDK 8u202是最后一个免费商用版本，后面的大版本更新要商业授权。用OpenJDK的话，Adoptium（Eclipse Temurin）发行版是社区常用的选择，Linux上直接下载tar.gz解压即可，不涉及复杂安装流程。

2.2 官方openjdk8镜像的版本与系统差异

官方openjdk镜像在Docker Hub上的tag排列很迷惑，openjdk:8-jdk-alpine这种老tag对应的是基于Alpine Linux的精简版，而openjdk:8uXXX-jdk在不同时期对应的基础系统也不一样，常见的是Oracle Linux或Ubuntu。这点很关键，因为Alpine用的是musl libc，而大部分Java本地化依赖库编译时基于glibc，如果应用里有JNI调用或依赖特定系统库，在Alpine上跑容易出诡异的报错。

实践下来我的建议是：能用Debian/Ubuntu底座的openjdk镜像，就别碰Alpine底座，除非对体积有极致要求且确认应用纯Java无本地库。openjdk:8-jdk这个tag在较长时间内指向Ubuntu底座，是相对稳妥的选择。不过也有一个坑：官方openjdk镜像里没有bash，严格来说是有的但很精简，我们写启动脚本时如果用到了bash特性，比如数组、高级通配符，就可能报错。所以脚本要么收敛到sh语法，要么在Dockerfile里先apt-get install -y bash。

还有一点，官方openjdk镜像默认不带curl和wget，做健康检查时HEALTHCHECK指令里如果用curl去探测端口，得提前把工具装进去。要么就用Java层面的检查脚本，要么就在构建阶段安装这些基础工具，后面我会在Dockerfile里体现。

2.3 自制JDK镜像时基础系统的选择

如果决定从底层自制，基础镜像选择开门见山就是CentOS与Ubuntu之争。CentOS 7的glibc版本较老，但和很多传统企业应用的编译环境一致，兼容性验证成本低；CentOS 7在2024年中已经EOL，意味着基础镜像的安全补丁不再更新，这是必须评估的隐患。Ubuntu 20.04 LTS支持周期长、官方源更新及时、glibc版本较新，适合长期作为基础镜像。

我做自制镜像时选的是ubuntu:20.04，理由有三：安全更新可持续到2030年；apt源在国内或者内网都可以配置镜像，下载依赖稳定；它对OpenJDK的运行时兼容问题最少。如果公司安全团队强制要求不可使用已EOL的系统，CentOS 7这条路基本走不通，Ubuntu LTS是更稳妥的选择。

自制镜像还需要考虑中文字体、时区数据、cacerts证书库的问题。Ubuntu基础镜像默认没有安装fontconfig和中文字体，如果你的应用要生成图片或PDF，需要提前apt-get install -y fontconfig fonts-dejavu-core。时区数据打包在tzdata包里，默认也是没有完整安装的，Dockerfile里需要配置DEBIAN_FRONTEND=noninteractive再安装，以免交互提示卡住构建。

3. 实操过程与核心环节实现

3.1 方案A：基于官方openjdk8镜像制作Tomcat镜像

这套方案适合大多数团队，构建速度快，Dockerfile简洁。我以openjdk:8u342-jdk为例，这个tag基于Ubuntu，glibc环境干净。先把目录结构准备好，后面所有文件都放到一个目录下统一构建：

bash复制tomcat8-jdk8-image/
├── Dockerfile
├── startup.sh
├── setenv.sh
└── server.xml

Dockerfile内容如下：

dockerfile复制FROM openjdk:8u342-jdk

LABEL maintainer="your-team@example.com" \
      description="Tomcat 8.5 with JDK8 for legacy service"

# 环境变量统一在这里声明
ENV CATALINA_HOME=/usr/local/tomcat \
    CATALINA_BASE=/usr/local/tomcat \
    PATH=$PATH:/usr/local/tomcat/bin \
    JAVA_HOME=/usr/local/openjdk-8 \
    TZ=Asia/Shanghai \
    LANG=C.UTF-8 \
    JAVA_OPTS="-Xms512m -Xmx1024m -Djava.awt.headless=true"

# 安装必要工具，配置时区
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        tzdata \
        curl \
        fontconfig \
        fonts-dejavu-core \
    && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
    && echo "Asia/Shanghai" > /etc/timezone \
    && rm -rf /var/lib/apt/lists/*

# 下载并解压Tomcat
RUN curl -fsSL https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.100/bin/apache-tomcat-8.5.100.tar.gz -o /tmp/tomcat.tar.gz \
    && tar -xzf /tmp/tomcat.tar.gz -C /usr/local/ \
    && mv /usr/local/apache-tomcat-8.5.100 /usr/local/tomcat \
    && rm -rf /usr/local/tomcat/webapps/* \
    && rm -f /tmp/tomcat.tar.gz

# 覆盖配置
COPY server.xml $CATALINA_HOME/conf/server.xml
COPY setenv.sh $CATALINA_HOME/bin/setenv.sh
COPY startup.sh /usr/local/bin/startup.sh

RUN chmod +x /usr/local/bin/startup.sh $CATALINA_HOME/bin/setenv.sh \
    && useradd -r -s /sbin/nologin tomcat \
    && chown -R tomcat:tomcat $CATALINA_HOME

USER tomcat

EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=5s --start-period=40s --retries=3 \
    CMD curl -f http://localhost:8080/ || exit 1

ENTRYPOINT ["/usr/local/bin/startup.sh"]

这里有几个细节值得单独说明。

第一，JAVA_HOME路径我写的是/usr/local/openjdk-8，这是官方openjdk:8u342-jdk镜像里JDK的实际解压目录。不同版本的tag路径可能不同，稳妥的办法是构建前先docker run --rm openjdk:8u342-jdk sh -c "which java"看一眼，再写死到环境变量里。

第二，删除webapps下自带项目不是可选项而是安全必选项。官方Tomcat压缩包自带ROOT、docs、examples、manager、host-manager这五个应用，其中manager和host-manager如果暴露到公网，配合弱口令就是远程命令执行的入口，2020年前后爆过好几轮CVE攻击脚本，都是扫描这些默认路径的。所以rm -rf那一步必须在解压后执行。

第三，USER指令切到普通用户运行进程，进程权限从root降到tomcat用户。这一步很多镜像做得不到位，但恰恰是安全扫描的硬性要求。需要注意war包部署目录必须让tomcat用户可写，否则热部署或上传war时会报权限不足。

再看启动脚本startup.sh：

bash复制#!/bin/sh
# 解决容器停止时Tomcat进程无法接收SIGTERM的问题
exec catalina.sh run

有人可能习惯用catalina.sh start启动，这在容器里是致命错误。start命令会把Tomcat放到后台执行，容器主进程随之退出，Docker判定容器已停止，于是整个容器直接死掉。catalina.sh run让Tomcat在前台运行并接收信号，容器生命周期才能正确管理。加上exec关键字则让启动脚本进程本身被java进程替换，信号传递更直接，这是容器化启动脚本的标准写法。

setenv.sh是这样：

bash复制#!/bin/sh
# 在catalina.sh执行时自动加载，专门放JVM参数
JAVA_OPTS="-Xms512m -Xmx1024m -Xss512k -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Duser.timezone=Asia/Shanghai"

setenv.sh是Tomcat自带的扩展机制，只要文件存在于bin目录，catalina.sh启动时就会自动加载它。我把JVM参数放在这里而不是写进Dockerfile的ENV，是因为运维在容器外部用docker run -e JAVA_OPTS=...时，Dockerfile的ENV会被覆盖，而setenv.sh属于镜像内文件，修改需要重新构建，这个优先级关系值得留意。

构建命令和验证命令如下：

bash复制docker build -t app-tomcat:8.5.100-jdk8 .

docker run -d --name test-tomcat \
  -p 8080:8080 \
  -e JAVA_OPTS="-Xms256m -Xmx512m" \
  app-tomcat:8.5.100-jdk8

docker exec -it test-tomcat bash

进入容器后依次验证日期、Java版本、进程状态：

bash复制date
java -version
ps -ef | grep java

正常输出应该是Fri Jan 10 10:11:22 CST 2025这样的北京时间，java版本为1.8.0_342，进程以tomcat用户运行。如果date还是UTC时间，检查/etc/timezone文件是否覆盖成功。

3.2 方案B：基于自制openjdk8镜像封装Tomcat镜像

自制JDK镜像看起来复杂，其实核心就是三步：选底座、解压JDK、处理系统依赖。这里以Ubuntu 20.04为基础演示。先说说JDK包从哪来，最规范的渠道是Adoptium官方的GA发布包，建议事先下载好JDK的tar.gz并放到构建目录，不要在Dockerfile里现场下载——国外CDN在构建机上经常超时，而且依赖网络状态。我习惯把安装包放到和Dockerfile同级的packages/目录，构建时用COPY指令打进临时层。

目录结构：

bash复制custom-tomcat8-jdk8-image/
├── Dockerfile
├── packages/
│   ├── OpenJDK8U-jdk_x64_linux_hotspot_8u392b08.tar.gz
│   └── apache-tomcat-8.5.100.tar.gz
├── startup.sh
├── setenv.sh
└── server.xml

Dockerfile基本框架：

dockerfile复制FROM ubuntu:20.04

ENV DEBIAN_FRONTEND=noninteractive \
    JAVA_HOME=/opt/java/openjdk \
    CATALINA_HOME=/opt/tomcat \
    TZ=Asia/Shanghai \
    LANG=C.UTF-8

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        ca-certificates \
        tzdata \
        curl \
        fontconfig \
        fonts-dejavu-core \
    && rm -rf /var/lib/apt/lists/*

# 安装JDK并精简无用内容
COPY packages/OpenJDK8U-jdk_x64_linux_hotspot_8u392b08.tar.gz /tmp/jdk.tar.gz
RUN mkdir -p /opt/java \
    && tar -xzf /tmp/jdk.tar.gz -C /opt/java --strip-components=1 \
    && mv /opt/java /opt/java/openjdk \
    && rm -rf /opt/java/openjdk/src.zip \
    && rm -rf /opt/java/openjdk/jre/bin/policytool \
    && find /opt/java/openjdk -name "*.html" -type f -delete \
    && rm -f /tmp/jdk.tar.gz

这里最需要解释的是--strip-components=1参数。Adoptium的tar包解压后第一层目录名是jdk8u392-b08之类的版本目录，如果不加这个参数，JDK会被解压到/opt/java/jdk8u392-b08，环境变量得跟着版本名走，日后升级JDK小版本就要改Dockerfile。加--strip-components=1可以把版本目录这一层剥掉，让JDK文件直接落在/opt/java下，保持路径稳定。

我还在JDK安装后删了src.zip和一堆html文档，这些在运行环境里毫无用处，每个文件都占几MB到几十MB，删掉能让镜像瘦身100MB以上。JDK8不像JDK9以后能jlink定制裁剪模块，所以手工清理文档是自制JDK镜像里性价比最高的瘦身手段。

接下来安装Tomcat，步骤和方案A差不多，只是目录统一放在/opt下：

dockerfile复制COPY packages/apache-tomcat-8.5.100.tar.gz /tmp/tomcat.tar.gz
RUN tar -xzf /tmp/tomcat.tar.gz -C /opt/ \
    && mv /opt/apache-tomcat-8.5.100 /opt/tomcat \
    && rm -rf /opt/tomcat/webapps/* \
    && rm -f /tmp/tomcat.tar.gz \
    && useradd -r -s /sbin/nologin tomcat \
    && chown -R tomcat:tomcat /opt/tomcat

COPY server.xml /opt/tomcat/conf/server.xml
COPY setenv.sh /opt/tomcat/bin/setenv.sh
COPY startup.sh /usr/local/bin/startup.sh

RUN chmod +x /usr/local/bin/startup.sh /opt/tomcat/bin/setenv.sh

USER tomcat
EXPOSE 8080
ENTRYPOINT ["/usr/local/bin/startup.sh"]

构建方法与方案A一致：

bash复制docker build -t app-tomcat:custom-jdk8 .

docker run -d --name test-tomcat-custom -p 8080:8080 app-tomcat:custom-jdk8

自制路线的优点在这一步体现出来了：JDK和Tomcat的版本完全可控，任何一层出了问题都能从Dockerfile溯源；镜像内不含多余的工具链，攻击面更小。缺点是构建过程中要自己维护基础镜像的安全补丁更新，Ubuntu的apt-get upgrade需要定期执行并重新出包。

3.3 server.xml、日志权限与持久化配置

不管走哪条方案，server.xml都要针对容器场景微调。一个常见的需求是统一URI编码，老项目经常因为URL中的中文参数乱码被坑，在Connector上显式声明UTF-8可以彻底规避：

xml复制<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           URIEncoding="UTF-8"
           maxThreads="200"
           minSpareThreads="20"
           acceptCount="100" />

线程池参数maxThreads、acceptCount要根据容器的CPU和内存规格预估，默认值在容器里往往偏大。一般来说容器分配2核4G的情况下，maxThreads设置200到300比较合理，配合minSpareThreads减少突发流量下线程创建的开销。

日志方面要提前规划好数据卷。Tomcat的日志在logs目录下，包括catalina.out、localhost_access_log等，容器重建后这些日志会消失，所以docker run时一定要挂载：

bash复制docker run -d --name app \
  -p 8080:8080 \
  -v /data/logs/tomcat:/opt/tomcat/logs \
  -v /data/webapps:/opt/tomcat/webapps \
  app-tomcat:8.5.100-jdk8

挂载后有个隐患：宿主机目录的属主和容器内tomcat用户UID可能不一致，导致启动时无法写日志。解决办法有两种，要么在启动脚本里先chown再启动，要么在宿主机上把目录属主调成和容器内tomcat用户一样的UID。我在Dockerfile里创建用户时已经指定了UID为1002，宿主机侧可以用chown -R 1002:1002 /data/logs/tomcat对齐。

4. 镜像瘦身、启动脚本与JVM参数详解

4.1 各方案镜像体积实测与分析

构建完两个镜像可以对比一下体积。

bash复制docker images | grep tomcat

根据我的实际构建记录，基于官方openjdk的tomcat镜像体积大约在480MB到550MB之间，自制Ubuntu底座的镜像大致在600MB上下，差距主要来自JDK安装方式和基础系统库的完整度。如果追求体积压缩，可以考虑换成slim或alpine基础镜像，但Alpine底座的musl兼容性问题前面提过，不是所有应用都能接受。

还有一个很有效的瘦身思路，是删除/opt/tomcat/webapps下不需要的静态资源和示例，并对JRE做进一步裁剪。JDK8虽然不能jlink，但可以删掉jre/lib/ext下用不到的扩展包，以及jre/lib/rt.jar中的无用类，不过这个操作风险高、收益也有限，我不建议普通团队在镜像构建中做这么激进的优化，性价比太低。

4.2 启动脚本的信号处理与优雅停机

前面已经提到，容器内启动必须用catalina.sh run。这里再补充一个生产环境常见的坑：想实现优雅停机，让Tomcat在接到SIGTERM后能等待正在处理的请求结束，只靠默认配置是不够的。Tomcat的server.xml里可以配置优雅停机参数：

xml复制<Server port="8005" shutdown="SHUTDOWN">
  <!-- 关键参数 -->
</Server>

但更实用的是把catalina.sh里的JVM_OPTS配好，并借助startup.sh的trap机制：

bash复制#!/bin/sh
trap 'echo "Stopping Tomcat..."; catalina.sh stop 30' SIGTERM
catalina.sh run

实际生产里，我们通常依赖容器编排的terminationGracePeriodSeconds和Tomcat的maxWait参数配合，如果项目对优雅停机要求很高，建议在setenv.sh中加入-Dcatalina.stopTime=20这类参数，并确认server.xml中配置了unpackWARs="true"。这块不同Tomcat版本的行为差异较大，升级版本后要重新验证一次。

4.3 JVM参数在容器环境中的合理配置

容器里的JVM参数比裸机更敏感，因为容器有cgroup限制。JDK8的某些小版本默认不识别容器内存限制，-Xmx必须显式指定，否则JVM可能按照宿主机内存去申请堆空间，在内存紧张时直接被OOM Killer干掉。我在setenv.sh中给出的参数组合是经过验证的：

bash复制JAVA_OPTS="-Xms512m -Xmx1024m -Xss512k -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m"

-Xss512k对多数Web应用足够，Tomcat自身的线程栈会更深一些，如果遇到StackOverflowError再适当调大。MetaspaceSize和MaxMetaspaceSize是JDK8特有的，默认的元数据空间是动态增长的，不显式限制的话，热部署加载类过多可能耗尽容器内存。

另外，-Djava.awt.headless=true是无界面服务器的标配，少了这个参数，生成图片、转换PDF时会直接在运行时抛HeadlessException。-Dfile.encoding=UTF-8和-Duser.timezone=Asia/Shanghai是给Java进程内代码用的，和系统环境变量LANG、TZ是两个层面，最好都配置到位，否则JVM内部和系统调用之间仍可能出现编码错位。

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

5.1 容器启动即退出的问题原因

这是所有人第一次做Tomcat镜像时都会碰到的问题。docker run成功后容器立刻退出，docker logs看不到明确报错，这种情况90%是因为启动命令写成catalina.sh start了。前面说过，start命令把Java进程放后台，容器主进程没事可做就退出了。解决方法就是把启动命令改成catalina.sh run并加exec。

如果改完还是退出，就进入容器检查日志：

bash复制docker run -it --rm app-tomcat:8.5.100-jdk8 /bin/bash
tail -f /opt/tomcat/logs/catalina.out

常见原因包括：8080端口被占用、setenv.sh里的JAVA_OPTS格式错误导致JVM启动失败、用户权限不足无法创建work或temp目录。逐个排查基本三五分钟能定位。

5.2 时区不对与中文乱码的排查思路

先看时间：

bash复制docker exec -it test-tomcat date

如果显示UTC，说明/etc/localtime没被正确覆盖。Dockerfile里ln -sf和echo两条命令都要有，只改TZ环境变量对某些基础镜像不起作用，因为进程不读这个变量。改成-v /etc/localtime:/etc/localtime:ro挂载宿主机时区文件是最快解决方式，但可移植性差，还是建议在镜像构建时就处理好。

中文乱码就有多个层面了。系统locale、JVM的file.encoding、Tomcat的URIEncoding、数据库连接串的字符集参数，任何一个设置不一致都会乱码。镜像里先把LANG=C.UTF-8和JAVA_OPTS中-Dfile.encoding=UTF-8同时配好，再在server.xml中声明URIEncoding="UTF-8"，大部分乱码问题能提前消灭。

5.3 官方镜像里缺bash和相关依赖的处理方法

官方openjdk镜像为了控制体积，会把很多“实用但不必要”的工具裁掉。比如openjdk:8-jdk-alpine里连bash都没有，我们的启动脚本如果写了#!/bin/bash，运行时会报No such file or directory。判断脚本执行失败的原因时，这个报错很有迷惑性，因为脚本文件确实存在，但解释器不存在。

解决方法是：要么在Dockerfile里apk add --no-cache bash，要么把脚本改成#!/bin/sh。我建议后者，因为容器的核心原则是精简到够用为止，sh语法同样能完成Tomcat启动工作，没必要为这种需求增加一层依赖。

5.4 部署war包后访问404

war包放进webapps目录后，浏览器访问项目路径404，大概率是解压和类加载的问题。先确认war包属主是否tomcat用户、是否有可读权限。再看server.xml的appBase是不是指向了webapps。如果是热部署场景，Tomcat检测war包变化后会自动解压，老项目首次解压较慢，可以等几秒再刷新。

还有一类常见情况是war包是zip格式但不合规，Tomcat能部署但类加载不到，控制台会打印大量ClassNotFoundException，这种情况重新打包部署即可。

6. 优化方向与个人经验总结

6.1 把镜像纳入版本管理与CI流水线

镜像构建本身不复杂，真正复杂的是把镜像纳入交付体系。我现在的做法是：Dockerfile和启动脚本放在Git仓库的docker/目录，Jenkins或GitLab CI在代码合并触发后自动构建，并推送带版本号的镜像到私有仓库。镜像的tag规则是tomcat-8.5.100-jdk8-${BUILD_ID}，这样每个环境部署的镜像都有唯一的构建标识，出了问题能快速定位到对应的代码提交和构建日志。

这种做法比手动docker build再docker tag要可靠得多，也避免了“本地能跑，服务器跑不了”的环境差异问题。

6.2 两步法排查镜像安全风险

镜像做完后一定要过一遍安全扫描。Trivy是当前最常用的开源扫描工具，一条命令就能检查出系统包漏洞、JDK和Tomcat的已知CVE：

bash复制trivy image --severity HIGH,CRITICAL app-tomcat:8.5.100-jdk8

扫描结果出来后，重点关注涉及Tomcat AJP协议和反序列化的高危漏洞。Tomcat 8.5.50以下版本存在严重的AJP文件读取漏洞，如果排查发现版本过低，优先升级Tomcat版本而不是打补丁，因为Tomcat官方对老版本的安全维护周期有限。

6.3 一点实际经验

镜像自制这件事，我踩过最大的坑就是盲目追新。刚上手时总想用最新的Tomcat和JDK，结果老项目在Tomcat 10上直接因为javax改成jakarta命名空间而无法启动，白折腾一整天。后来养成习惯：先确认项目的Servlet版本和依赖库，再选定Tomcat大版本，最后固定JDK版本，形成组合后不再随意升级。

在团队协作中，我还会把镜像的基础信息写进README，包括JDK和Tomcat的精确版本、构建命令、JVM参数含义、挂载点清单。这个文档比任何脚本都重要，因为半年后重新维护镜像时，自己看Dockerfile都能看懂，但当初为什么选这个参数、对应哪个线上故障，只有文档能留住前因后果。

如果你手头正有一个Java 8老应用在容器化，先别急着从官方仓库拉现成镜像，花半小时把基础层选型和启动脚本搞清楚，后面省下的不止是排查问题的时间，更是一整套交付流程的稳定。