1. 为什么这套“老掉牙”组合反而最需要自己动手做镜像最近在帮一个跑了好多年的老项目做容器化迁移场景就是经典的 Docker openjdk8 Tomcat 8.5 三件套。业务代码里一堆javax.*的老 API第三方 jar 也停留在 2018 年的版本升级 JDK 基本等于重写。所以摆在桌面上的问题很现实要么把整套旧环境原样装进容器要么就别迁。一开始我也偷懒想着直接用官方现成的镜像一把梭。官方 openjdk 仓库里openjdk:8-jdk、openjdk:8-jdk-slim、openjdk:8-jdk-alpine这些 tag 都很现成Docker Hub 上还有维护得很好的tomcat:8.5-jdk8-openjdk。但真把需求摆出来之后发现没那么简单安全扫描要求基础镜像里的系统包版本可控审计要能说清楚每一层是哪儿来的生产环境还需要预置内网 CA 证书、时区统一成 Asia/Shanghai、加密策略文件也要调整。这些诉求用官方镜像当然也能通过二次 Dockerfile 实现但很多时候你会发现官方镜像的底层系统——尤其是 alpine——要装点东西特别别扭。于是“基于自制 openjdk8 镜像做 Tomcat 镜像”和“基于官方 openjdk8 镜像做 Tomcat 镜像”这两条路就成了每次评审会上都会被翻出来的核心议题。这篇文章把我实际跑通的两条路线完整记下来自制基础镜像怎么做、Tomcat Dockerfile 怎么写、两条路的差异在哪里、踩过哪些坑。适合正在给 Java 老项目做容器化的朋友也适合想搞清楚镜像层、JDK 底座、Tomcat 启动方式这些底层逻辑的人。2. 自制 OpenJDK8 基础镜像包管理器路线与压缩包路线先说自制。所谓自制 openjdk8 镜像本质就是“从一张干净的系统镜像出发自己把 JDK8 装进去”。装 JDK8 有两条经典路线用系统包管理器装比如 CentOS 的yum或者把下载好的 JDK 压缩包直接打进基础镜像。两条路线我都试过取舍点很清晰。2.1 路线一用 CentOS 的 yum 装 OpenJDK8这是最省事、最贴近服务器上手工安装习惯的做法。Dockerfile 长这样FROM centos:7 RUN yum install -y java-1.8.0-openjdk-devel \ yum clean all \ rm -rf /var/cache/yum ENV JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk ENV PATH$JAVA_HOME/bin:$PATH这里有两个细节值得展开。第一装的是java-1.8.0-openjdk-devel而不是java-1.8.0-openjdk。前者带完整的 JDK 工具链包括javac、jmap、jstack、jstat这些排查和调优工具后者只带 JRE。如果你只在镜像里跑 Tomcat理论上 JRE 够用但出了内存溢出、CPU 飙高的时候jmap和jstack几乎是救命工具没有它们只能干瞪眼。第二yum clean all和删缓存必须写在同一个 RUN 里。Dockerfile 每一层 RUN 结束后的文件系统快照都会被保存不清理的话/var/cache/yum里那一堆 rpm 就全沉淀在镜像层里体积直接从三百多 MB 飙到四五百 MB。另外JAVA_HOME指向的/usr/lib/jvm/java-1.8.0-openjdk通常是个软链接实际目录带完整版本后缀。构建完用一条命令验证路径真实有效docker run --rm my-openjdk8:latest readlink -f $(which java) # 输出类似 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.382.b05-1.el7_9.x86_64/bin/java只要打印出的是软链接后的真实路径说明 JAVA_HOME 没跑偏。2.2 路线二用 JDK 压缩包打进基础镜像yum 路线的短板是 JDK 小版本不可控装到的版本完全取决于源当前的更新情况。如果你需要锁死某个小版本比如 8u202、8u402就得走压缩包路线。FROM ubuntu:20.04 RUN apt-get update apt-get install -y --no-install-recommends \ ca-certificates \ rm -rf /var/lib/apt/lists/* ADD OpenJDK8U-jdk_x64_linux_hotspot_8u402b06.tar.gz /opt/ ENV JAVA_HOME/opt/jdk8u402-b06 ENV PATH$JAVA_HOME/bin:$PATH我建议从 AdoptiumEclipse Temurin 项目下载 OpenJDK8 的tar.gz压缩包而不是 Oracle 官方 JDK8。原因有两个一是 Oracle JDK 8 的许可条款对企业使用限制很多打包进镜像再分发容易踩授权红线二是 Temurin 的构建版本在 Docker 社区里验证得很充分跟官方镜像里的 JDK 同源。下载时注意选x64_linux_hotspot标签对应的包文件名里的8u402b06表示 8u402 build 06小版本一目了然。ADD有个特性要特别记牢如果参数是本地 tar.gz 且目标是目录Docker 会自动解压。这是和COPY最大的行为差异很多人用COPY后发现压缩包没解开就是这个原因。如果你不想依赖ADD的自动解压行为也可以在 RUN 里手动tar -xzf并清理原始压缩包第 5 节会给一个更彻底的写法。2.3 构建、验证与推送到私有仓库两条路线写好后构建命令一样docker build -t my-openjdk8:8u402 ./openjdk8-dockerfile/构建完别急着做 Tomcat先做两层验证。第一层验证 JVM 版本docker run --rm my-openjdk8:8u402 java -version # openjdk version 1.8.0_402第二层验证运行参数和系统状态docker run --rm my-openjdk8:8u402 bash -lc echo $JAVA_HOME cat /etc/os-release顺便说一句自制镜像不是为了折腾而折腾。我见过不少团队把自制镜像的整个生命周期搞反了花大量精力写完 Dockerfile却从来不往私有仓库推送。自制基础镜像的价值在于“可复现、可审计、可统一维护”推送到私有仓库让整个团队统一使用这套基础层才算真正成为团队资产。推的时候记得同时打一个带时间戳的版本和一个stable别名别裸用latest。3. 两种基础镜像上的 Tomcat Dockerfile 实操基础镜像准备好之后Tomcat 镜像就变成了一个“往 JDK 环境里塞 Tomcat 运行包”的问题。这一步无论底座是自制还是官方套路基本一致差别主要在细节。3.1 准备 Tomcat 压缩包并校验完整性先下载 Tomcat 8.5.98。这个版本是 8.5 系列的最终版本对要稳定运行两三年的遗留系统来说是最稳妥的选择。wget https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.98/bin/apache-tomcat-8.5.98.tar.gz sha512sum apache-tomcat-8.5.98.tar.gz下载 Tomcat 有个细节Apache 官网的下载链接分dlcdn和archive两类dlcdn只保留还在活跃发布的版本像 8.5.98 这种已经退役的版本要去archive.apache.org拉。校验和也不要从官网页面复制了事更稳的做法是从 Apache 的KEYS文件和对应的.sha512文件核对。构建镜像是一个自动执行很多步骤的过程源头包不干净后面全白搭。3.2 基于自制 openjdk8 镜像的 DockerfileFROM my-openjdk8:8u402 ENV CATALINA_HOME/opt/tomcat ENV PATH$PATH:$CATALINA_HOME/bin RUN mkdir -p /opt/tomcat ADD apache-tomcat-8.5.98.tar.gz /opt/ RUN mv /opt/apache-tomcat-8.5.98/* /opt/tomcat/ \ chmod x /opt/tomcat/bin/*.sh WORKDIR $CATALINA_HOME EXPOSE 8080 CMD [catalina.sh, run]几个关键点解释一下。为什么用catalina.sh run而不是常见的startup.sh这是整个 Dockerfile 里最重要的一行。startup.sh的逻辑是启动一个后台进程然后立即退出这在物理机上是合理的但在容器里会导致灾难Docker 的 CMD 进程一退出容器就进入退出状态Tomcat 来不及完成任何启动过程。catalina.sh run让 JVM 在前台运行Tomcat 成为容器的 PID 1 持续存活docker stop发来的 SIGTERM 也能被 JVM 正确处理做到优雅停机。为什么用ADD而不是在 Dockerfile 里先curl下载这里我特意走了“本地下载好压缩包 ADD 自动解压”的路子因为很多内网构建环境里Dockerfile 里的RUN curl拿不到外网而构建机的 shell 反而能通过代理下载。在宿主机把 tar 包拉到 Dockerfile 所在目录利用 ADD 的构建上下文拿进去是最不容易卡住的姿势。代价是多占一层镜像想极致优化的话可以换成第 5 节里的 curl 写法。3.3 基于官方 openjdk8 镜像的 Dockerfile官方镜像的思路完全一样只是 FROM 变一下FROM openjdk:8-jdk-slim ENV CATALINA_HOME/opt/tomcat RUN mkdir -p /opt/tomcat ADD apache-tomcat-8.5.98.tar.gz /opt/ RUN mv /opt/apache-tomcat-8.5.98/* /opt/tomcat/ \ chmod x /opt/tomcat/bin/*.sh WORKDIR $CATALINA_HOME EXPOSE 8080 CMD [catalina.sh, run]这里我推荐openjdk:8-jdk-slim而不是openjdk:8-jdk-alpine后面会详细解释。-slim是基于 Debian 的精简版本去掉了文档和大部分用不到的包但保留了 glibc 和完整的系统工具链对跑 Tomcat 这种需要加载本地库的 Java 应用来说宽容得多。如果你确实想用 alpine至少要把时区包和本地化相关的东西补上否则跑起来大概率遇到日志时间不对、某些字符集乱码的问题。3.4 同一份 Tomcat在两个底座下的实际差异构建完成后把两个镜像都跑起来对比差异挺直观。整理成一张表对比项自制CentOS/Ubuntu 底座官方 openjdk:8-jdk-slim官方 openjdk:8-jdk-alpine镜像体积400-600 MB约 300 MB约 150 MBlibc 实现glibcglibcmusl时区处理已带 tzdata改起来方便容易补默认无 tzdata需 apk 安装Tomcat NativeAPR方便编译安装可行很麻烦JDK 小版本自己锁定随官方镜像维护随官方镜像维护安全审计基础层由自己负责依赖上游依赖上游注意 alpine 那列。镜像小是它最大的卖点但 Java 生态对 musl libc 的支持一直不算完美尤其到了 JDK 8 这个老版本某些加密算法、DNS 缓存、系统调用行为在 musl 下和 glibc 下表现不一致排查代价很高。Tomcat 的 APR 连接器要编译本地库依赖一堆 dev 工具包在 alpine 上装起来纯粹是受罪。所以我的结论很明确追求体积就去用官方-slim追求可控就去自制alpine 留给那些纯 Java、无本地依赖、且团队能接受偶尔玄学问题的新项目。4. 启动验证、JVM 参数注入与数据卷挂载镜像做出来只是第一步。跑起来的验证链路以及怎么注入 JVM 参数、怎么把日志和 webapps 挂出来才是日常运维天天要面对的部分。4.1 第一次启动的完整检查链路构建完先用最朴素的方式启动docker run -d --name tomcat8 -p 8080:8080 my-tomcat8:8.5.98然后按顺序做四件事。第一件看日志docker logs -f tomcat8正常情况会看到INFO: Server startup in [xxx] milliseconds。第二件验证 HTTP 服务curl -I http://localhost:8080关注返回头里的HTTP/1.1 200。第三件进容器看进程docker exec tomcat8 ps -ef | grep java这一步是为了确认 JVM 是前台运行的 PID 1而不是孤儿进程。第四件看一眼 Tomcat 版本和日志目录权限docker exec tomcat8 /opt/tomcat/bin/version.sh docker exec tomcat8 ls -l /opt/tomcat/logs这四步全部通过镜像才算真正可用。很多人习惯docker run后只 curl 一下 8080 就完事等到第二天发现日志没输出、时间不对才开始回头查浪费的时间全是在启动验证这一步省懒省掉的。4.2 JAVA_OPTS 与 CATALINA_OPTS 到底该改哪个跑 Tomcat 镜像绕不开 JVM 参数。常见需求是调整堆大小-Xms512m -Xmx2048m。但你会在网上看到两种写法一种塞JAVA_OPTS一种塞CATALINA_OPTS到底哪个对Tomcat 的catalina.sh脚本把环境变量分成了两类JAVA_OPTS在启动 JVM 和停止 JVM 时都会被读取CATALINA_OPTS只在启动 Tomcat 运行环境时读取。所以堆参数这类“只有 Tomcat 运行时才需要”的设置应该放进CATALINA_OPTS。你要是把-Xmx2048m写进JAVA_OPTS执行shutdown.sh时 JVM 也会尝试申请 2 GB 堆白白增加无谓开销。在 Docker 里注入CATALINA_OPTS最干净的方式是环境变量docker run -d --name tomcat8 -p 8080:8080 \ -e CATALINA_OPTS-Xms512m -Xmx2048m -Djava.security.egdfile:/dev/./urandom \ -e TZAsia/Shanghai \ my-tomcat8:8.5.98java.security.egdfile:/dev/./urandom是个老梗。JDK 8 在某些环境下默认使用/dev/random熵不足时 JVM 启动过程会肉眼可见地卡几十秒。Tomcat 官方脚本的setenv.sh示例里都推荐了这个参数别省略。如果不想在docker run命令里塞太长的环境变量可以把参数写进镜像内的/opt/tomcat/bin/setenv.sh。Tomcat 启动时会自动读取这个文件这也是把 JVM 参数固化进镜像的常用姿势。4.3 挂载 webapps 和日志目录时的注意事项部署应用有两个目录需要从宿主机挂进容器webapps和logs。docker run -d --name tomcat8 -p 8080:8080 \ -v /data/tomcat/webapps:/opt/tomcat/webapps \ -v /data/tomcat/logs:/opt/tomcat/logs \ -e CATALINA_OPTS-Xms512m -Xmx2048m \ my-tomcat8:8.5.98第一个坑是宿主机目录的属主和权限。演示镜像里 Tomcat 是用 root 跑的所以没有权限问题但如果你在 Dockerfile 里创建了tomcat用户并切换到该用户运行宿主机目录必须设置对应的 uid/gid否则 Tomcat 连日志都写不进去。常见解决办法是先查一下容器内 tomcat 用户的 uid然后把宿主机目录属主改成同一个 uiddocker exec tomcat8 id tomcat # 假设输出 uid1001(tomcat) sudo chown -R 1001:1001 /data/tomcat第二个坑是logs目录挂载会导致catalina.out不再通过docker logs输出。Tomcat 的日志默认输出目录是${CATALINA_HOME}/logs被数据卷覆盖之后容器 stdout 里只剩 JVM 的原始输出和 stderr。挂载 logs 之后日志采集策略要改成读宿主机文件别再依赖 docker logs否则你会疑惑“日志怎么突然没了”。第三个坑是默认的 webapps 内容。官方 Tomcat 压缩包自带 ROOT、docs、examples 等一批默认应用生产环境最好在镜像构建阶段就清掉RUN rm -rf /opt/tomcat/webapps/docs \ /opt/tomcat/webapps/examples \ /opt/tomcat/webapps/host-manager \ /opt/tomcat/webapps/manager这一步没做的话安全扫描器照着端口一探就能看到 Tomcat 的默认管理页面和管理接口风险非常大。5. 构建和运行阶段的高频翻车点实录这一段是实际跑完几轮之后最想写的内容。构建 Dockerfile 看起来无非几行真正编译、启动、排障的时候坑一个接一个。5.1 压缩包下载失败与校验不一致很多人在本机一把就过的 Dockerfile换到公司构建机上却卡在拉包这一步。原因通常是构建机网络受限Dockerfile 里的RUN curl或RUN wget访问不了外网。解决方案我在前面说过在宿主机下载好放到 Dockerfile 同目录用ADD的构建上下文带进去。这个做法能应付绝大多数场景。如果你对镜像层体积敏感不想让压缩包存进中间层就换成下载、解压、清理在一个 RUN 里完成的写法RUN curl -fsSL -o /tmp/apache-tomcat-8.5.98.tar.gz \ https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.98/bin/apache-tomcat-8.5.98.tar.gz \ tar -xzf /tmp/apache-tomcat-8.5.98.tar.gz -C /opt \ mv /opt/apache-tomcat-8.5.98 /opt/tomcat \ rm -rf /tmp/apache-tomcat-8.5.98.tar.gzcurl -fsSL里的-f表示 HTTP 错误时直接失败-S显示错误信息-L跟随重定向。这三个参数缺一不可。Apache 的下载链接几乎都会跳转到镜像站不用-L会得到一个 30x 的空文件然后 tar 解压报错定位半天还以为是镜像源的问题。5.2 默认时区不对导致日志时间差 8 小时启动镜像后你一定会遇到的一个问题容器里的默认时区是 UTC日志里打印的时间比北京时间差 8 个小时。如果你在镜像里加了-Duser.timezoneAsia/ShanghaiJava 应用的日志是东八区但操作系统层的date、cron、Tomcat 本地脚本里的时间还是 UTC混乱得很。Debian/Ubuntu/CentOS 底座在 Dockerfile 里加一行RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ echo Asia/Shanghai /etc/timezoneAlpine 底座要先装 tzdata 才能找到时区文件RUN apk add --no-cache tzdata \ cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ echo Asia/Shanghai /etc/timezone然后docker run时再补一个-e TZAsia/Shanghai双保险。这样 JVM 读到的/etc/localtime、环境变量和系统date指令就是一致的。构建完记得重新验证别在 Dockerfile 里写了就以为生效。5.3 用 startup.sh 启动导致容器秒退这个坑我见过不止一次。有人拿到 Tomcat 压缩包后第一反应是CMD [/opt/tomcat/bin/startup.sh]然后启动容器发现docker ps里状态一直是Exited日志还什么都没留下。原因我在 3.2 节提过startup.sh会把 JVM 放到后台然后退出主进程一退出容器直接结束。解决方式就是换catalina.sh run。如果你非要在命令里加各种环境变量也依然保持前台运行。记住一个判断标准容器里必须有个前台进程顶着Tomcat 的前台进程就是 JVM 本身。另一个相关问题是优雅停机。catalina.sh run直接在 shell 里跑 JVM 的 main 方法Docker 发 SIGTERM 后 JVM 会走标准关闭流程把正在处理的请求收尾再释放端口。你要是用了startup.sh或者额外包了一层后台启动脚本SIGTERM 传不到 JVM十有八九会变成强制关闭或者僵尸进程。5.4 Alpine 底座的“玄学”问题如果你非要选 alpine我劝你先搞清楚代价。Java 8 在 alpine 的 musl libc 环境下有几个历史遗留问题经常把人折腾得够呛。一是某些 JCE 加密算法在 musl 下加载行为不同代码里偶尔报NoSuchAlgorithmException换个 glibc 环境又正常。二是 DNS 解析的本地缓存行为差异在容器网络环境抖动时会表现出诡异的间歇性连接失败。三是 Tomcat NativeAPR 连接器在 alpine 上要么不装要装就要连编译工具链一起装镜像体积优势荡然无存还多出一堆不稳定因素。我的建议是除了纯内存型、无本地库依赖、对体积极度敏感的工具类 Java 应用其他场景一律用 glibc 底座也就是官方-slim或自制 Ubuntu/CentOS。镜像大个一两百 MB换来的是少熬夜排查那些“换个环境就好了”的玄学问题这笔账怎么算都划算。5.5 官方 openjdk 镜像归档后怎么锁版本还有个绕不开的现实Docker Hub 上的官方openjdk仓库已经标记为 deprecated官方维护团队建议切换到eclipse-temurin等新仓库。也就是说openjdk:8-jdk-slim这种 tag 虽然现在还能拉取但不会再有新的安全更新了。对生产环境来说这等于拿一个停更的基础镜像在跑业务安全扫描器大概率会亮红灯。两种应对方式。第一种是换 base把FROM openjdk:8-jdk-slim换成FROM eclipse-temurin:8-jdk或FROM eclipse-temurin:8-jdk-jammy功能上完全兼容又有人持续维护。第二种是如果项目规定必须用openjdk仓库至少把镜像 tag 锁定成具体版本甚至 digest不要用浮动的latest这样镜像内容哪天变了也能定位出来。锁定 digest 的操作很简单docker pull openjdk:8-jdk-slim docker inspect --format{{index .RepoDigests 0}} openjdk:8-jdk-slim # openjdksha256:xxx...把输出的openjdksha256:xxx填进 Dockerfile 的FROM镜像内容就永远固定在这一份快照上。安全审计要追溯的是具体到字节的镜像内容不是一个 tag 名。6. 最后说点选型的大实话两条路我都完整跑过最后给老项目落地的是自制路线ubuntu:20.04底座 Temurin 8u402 Tomcat 8.5.98。原因不复杂项目要过安全审计基础层必须由自己维护还要预置内网 CA 证书和统一时区这些用官方镜像也能做但要额外处理的东西太多不如一开始就掌握所有层。如果只是自己开发调试、或者新项目没有严格审计要求我建议直接用eclipse-temurin:8-jdk配官方tomcat:8.5-jdk8-temurin-jammy省心得多。官方 Tomcat 镜像连启动方式都是正确的前台运行不用自己写 Dockerfile。最后分享一个小技巧不管选哪条路构建完镜像后都留一份构建信息文件把基础镜像版本、JDK 版本、Tomcat 精确版本、Dockerfile 的 commit hash 记下来塞进镜像里的/opt/tomcat/BUILD_INFO或者做成 label。以后任何环境复现、审计追溯、出问题回滚都能直接按图索骥不用对着镜像 tag 猜来猜去。这套折腾下来我最大的体会是自制镜像不是炫技而是把不可控的上游变化变成可控的团队资产。