Docker装Tomcat，看起来不过是一条docker run tomcat就能搞定的事，但真把它用顺了，你会发现里面藏着一堆跟镜像版本、目录结构、端口映射、数据卷挂载有关的细节。尤其是官方镜像里那个webapps目录为空的“大坑”，不提前搞明白，装完十有八九要对着 404 页面发愣。这篇文章我结合自己多次排障和部署的经验，把 Docker 安装 Tomcat 从选镜像到跑起来、再往生产级方向调整的完整过程，一步步捋清楚。
实际干活的时候，我们经常要同时维护好几个环境：开发环境、测试环境、预发环境，每个环境对 Tomcat 版本、JDK 要求可能还不一样。要是都靠在一台机器上装不同的 Tomcat 实例，光是环境变量、端口配置就能把人折腾疯。用 Docker 之后，每个容器是独立的环境，版本随意切，换机器也方便。理解了这个大前提，后面所有操作就都顺理成章了。
1. 思路先行：容器跑 Tomcat 到底解决了什么问题
1.1 为什么非要用容器装 Tomcat
很多人最开始接触 Docker，都是从 Nginx、MySQL、Tomcat 这类中间件开始的。拿 Tomcat 举例，传统安装方式在那个年代没问题：下载二进制包、配置环境变量、改 server.xml、启动。但问题恰恰出在“每台机器都要重复一遍”上。换了服务器，你得重新下载、重新解压、重新改配置，整套流程里任何一个环节稍有疏漏，比如 JDK 版本不对、字符集没设好，服务就起不来，排查起来费时费力。
容器化之后，镜像本身就是“打包好的运行环境”。Tomcat 的二进制、JDK、基础系统、目录结构全都在镜像里固化下来了。同一份镜像，在开发机器上能跑，在测试服务器上一样能跑，不会再出现“我本地好的呀”这种经典甩锅现场。另外，Docker 把端口隔离做得比较干净，一个宿主机上开 5 个 Tomcat 容器，分别映射 8081 到 8085，互不干扰，这在传统装多实例时需要小心修改端口配置的场景下，便利性提升非常明显。
还有一点，容器本身的分层镜像设计对回滚也很友好。我升级出问题后，直接把容器换成上一个镜像标签重新启动就行，整个过程是秒级的。要是传统方式，要么靠自己备份目录，要么重新部署一遍，麻烦得多。
1.2 Tomcat 官方镜像的结构与特点
Docker Hub 上的tomcat官方镜像，它的基础路径是固定的/usr/local/tomcat，进去之后你会发现它跟 Linux 下直接解压的 Tomcat 目录结构基本一致，bin、conf、lib、logs、webapps、webapps.dist这些目录都在。但这里要注意的是，从 Tomcat 9 开始，官方镜像为了保持容器启动后目录干净，默认把初始的 Web 应用放到了webapps.dist目录里，而webapps目录是空的。
这个设计初衷是好的：你挂载自定义目录时不会跟镜像自带的默认应用冲突。但它也带来一个非常典型的副作用：直接用官方镜像起容器，访问http://localhost:8080会看到 404 页面，很多人第一反应是“Tomcat 没装成功”，其实容器已经完全起来了，只是没有可访问的应用。
另外还有一个版本上的大坑：Tomcat 10 之后，包名从javax.servlet全部改成了jakarta.servlet。如果你们项目里还是传统的 SSM 框架或者老 Spring 版本，直接选 Tomcat 10 镜像跑上去，启动时很容易报类找不到或各种 Servlet 相关异常。所以选镜像的时候，不能只看“最新版”，必须看项目实际兼容性。大多数传统 Web 项目，老老实实选tomcat:9.0系列最稳妥。
2. 动手前准备：镜像版本选型与拉取细节
2.1 先看懂镜像标签再动手
镜像标签这个事，平时不起眼，关键时刻能折腾人。tomcat:latest现在指向的是 Tomcat 10 或更高的大版本，而tomcat:9.0则是 9.x 系列里的最新小版本。这里建议是：能明确指定标签就明确指定，尽量少用latest。latest是会变的，今天拉下来能跑，过几个月再拉可能就是一个大版本升级，应用可能直接不兼容。
那标签怎么选？我的经验是三步走：
- 确认项目里用的 JDK 版本。如果是 JDK 8，选
tomcat:9.0-jdk8-temurin或类似带jdk8字样的标签；如果项目已经升级到 JDK 11 或 17，可以在tomcat:9.0-jdk11、tomcat:9.0-jdk17这类标签里挑。 - 确认 Servlet 规范版本。老项目优先 9.0，新项目如果确定不需要兼容旧的
javax包，再考虑 10.x。 - 看看基础系统类型。
-jre8、-jdk8这些指的是基础镜像里预装的运行时，还有带alpine字样的精简版，体积小很多，但某些依赖 glibc 的第三方库可能不兼容，生产环境我会偏向选择标准的temurin或openjdk版本，更省心。
比如我们之前有个老项目，跑的是 Spring 4 + JDK 8 + WAR 包部署，我最后定的是tomcat:9.0.85-jdk8-temurin这类固定小版本的镜像。为什么不只写9.0？因为固定到小版本后，镜像的不可变性更强，团队中任何人拉下来的东西都一样，避免“我用的 9.0.63，你用的 9.0.85，为什么行为不一样”这类问题。
2.2 拉取镜像时的网络与加速配置
镜像拉取这一步，最直接的命令就是docker pull tomcat:9.0-jdk8-temurin。但实际操作中，网络问题经常让人头疼，尤其是直接连 Docker Hub，速度可能很慢或者直接超时。我这边常用的是给 Docker 配置镜像加速器，配置文件是/etc/docker/daemon.json，在registry-mirrors字段里填上加速地址，然后systemctl restart docker重启 Docker 服务。配置好之后再拉取，速度会明显改善。
拉取完成后，用docker images看一眼镜像列表，确认镜像已经在本机。这里有个小习惯，我会顺手记录镜像的IMAGE ID前几位，后面启动容器时即使标签写错了，也能用 ID 顶上。拉取这个动作本身没啥高深的，重点是提前确认网络环境通不通，别等容器起不来了才怀疑镜像没拉全。
这里顺带提醒一句：如果拉取时看到的是manifest unknown或者not found，大概率是标签写错了。先去 Docker Hub 页面搜一下tomcat/tags，确认你想要的标签确实存在，不要凭感觉拼标签。
3. 核心步骤：跑起第一个 Tomcat 容器
3.1 启动命令逐段拆解
先把最简单的启动命令写在前面：
docker run -d --name tomcat-demo -p 8080:8080 tomcat:9.0-jdk8-temurin这条命令刚接触时容易看不懂，拆开来看其实很清晰：
-d：后台运行，终端不会卡住。--name tomcat-demo：给容器起个名字。起了名之后，后续用docker exec -it tomcat-demo bash进去操作就方便了，不用记容器 ID。-p 8080:8080：端口映射，宿主机 8080 端口转发到容器的 8080 端口。Tomcat 镜像内部默认监听的就是 8080，这是catalina.sh run启动后默认的端口。- 最后是镜像名加标签。
跑起来之后，先用docker ps看容器状态。如果STATUS列显示Up，说明容器起来了。这时候访问http://宿主机IP:8080，你会发现大概率是 404。不用慌，这不是装坏了，而是前面说的webapps目录为空导致的。
3.2 处理官方镜像的 webapps 默认目录问题
要让 Tomcat 的默认欢迎页出现，有两种常规处理思路。
第一种，直接改容器内的目录结构。这种方法适合临时测试、快速看一眼效果：
docker exec -it tomcat-demo bash cd /usr/local/tomcat rm -rf webapps mv webapps.dist webapps exit docker restart tomcat-demo注意顺序：先删掉空的webapps，再把webapps.dist改名成webapps。为什么不直接cp -r？因为官方镜像启动时如果发现webapps目录存在且里面内容完整，默认应用就能加载；但如果你直接复制，原目录还在，文件重复，后面维护时容易乱。当然cp也行，只是我习惯用mv，目录更干净。改完重启容器，再访问 8080，就能看到经典的 Tomcat 欢迎页了。
第二种，自定义应用直接挂载进去，这是实际部署时我更推荐的方式。比如你本地有一个test.war，想丢进容器让它自动解压部署：
docker run -d --name tomcat-demo -p 8080:8080 \ -v /opt/webapps:/usr/local/tomcat/webapps \ tomcat:9.0-jdk8-temurin这里把宿主机的/opt/webapps目录挂载到了容器里的/usr/local/tomcat/webapps。本地目录里放上test.war，Tomcat 启动后会自动完成部署，访问路径就是http://localhost:8080/test/。这种方式的优势在于，真实项目部署不需要频繁进容器改东西，宿主机上更新了 WAR 包，重启或者直接靠热部署就能生效，符合日常运维习惯。
3.3 验证容器日志与资源占用
容器启动后，看日志也是基本功。docker logs这个命令我们在排查问题时几乎天天用：
docker logs tomcat-demo docker logs -f tomcat-demodocker logs显示的是容器当前所有标准输出日志，-f参数是持续跟踪输出。Tomcat 启动时如果端口被占用、配置出错，日志里会有明确报错。比如看到SEVERE级别的Failed to initialize end point之类，通常就是 8080 端口被占用了。日志这块不建议等到出问题才查，启动完顺手看一眼，能提前发现很多隐患。
资源占用方面，可以用docker stats实时看容器 CPU、内存情况。Tomcat 默认堆内存可能会比较保守，后面要调 JVM 参数时，docker stats就是最直接的验证工具。
4. 生产级调整：数据卷、时区、字符集与资源限制
4.1 挂载配置文件与日志目录
实际用下来，光跑起来还不够。容器的文件系统是临时的，容器被删掉，里面的日志和配置就全没了。要想让数据活下去，就得把关键目录挂载出来。
常见的挂载需求有这几个：
webapps目录：放部署的应用，前面已经演示过。logs目录：Tomcat 的日志目录，里面是catalina.out、localhost.log这些。挂出来之后可以直接在宿主机上看日志，不用每次docker exec进去。conf目录：如果经常要改server.xml或context.xml，可以把整个conf目录挂载出来。
配置挂载用一条命令就能实现：
docker run -d --name tomcat-prod \ -p 8080:8080 \ -v /data/tomcat/conf:/usr/local/tomcat/conf \ -v /data/tomcat/logs:/usr/local/tomcat/logs \ -v /data/tomcat/webapps:/usr/local/tomcat/webapps \ -e TZ=Asia/Shanghai \ tomcat:9.0-jdk8-temurin这里有一个细节：挂载conf目录时要保证宿主机的这个目录里有完整的配置文件，至少要有server.xml、web.xml、context.xml。空目录挂载进去，Tomcat 会因为找不到配置直接起不来。稳妥的做法是先把容器跑起来，用docker cp把容器里的conf目录复制到宿主机：
docker cp tomcat-prod:/usr/local/tomcat/conf /data/tomcat/conf然后删掉容器，再用挂载方式重新创建。配置文件先落地，再挂载，就不会踩空了。
4.2 时区与字符集的坑
时区这个坑，我印象很深。刚用 Docker 跑 Tomcat 时，容器里默认时区是 UTC，日志时间比北京时间慢了 8 小时。排查线上问题时，看到一条日志记录时间跟数据库时间对不上，查了半天才发现是容器时区问题。现在我的习惯是启动容器时直接加上环境变量：
-e TZ=Asia/Shanghai如果基础镜像里没有预设这个时区，可能还需要挂载/etc/localtime。但大多数官方 Tomcat 镜像配合TZ变量就够了，加了之后日志时间和系统时间能对上。
字符集也容易出问题。尤其当项目里还在用 GBK 编码的老接口，启动后看到中文乱码，第一反应是代码问题，实际上往往是容器环境变量没设对。可以在启动时加：
-e JAVA_OPTS="-Dfile.encoding=UTF-8 -Duser.timezone=GMT+08"已经运行的容器，可以通过设置环境变量后再重启一次来解决。这里要提醒的是，JAVA_OPTS这个环境变量对 Tomcat 镜像来说是生效的，因为启动脚本catalina.sh会读取它。我们把它用在自定义镜像的ENV里也是一样的原理。
4.3 容器资源限制与 JVM 参数联动
生产环境大家还要关注一个点：容器内存限制。一个 Tomcat 容器，如果不加限制，默认可以用完宿主机的全部内存，这在多容器场景下非常危险。
我会在跑容器时加上：
-m 2g --cpus=1.5-m 2g限制容器最大使用 2GB 内存，--cpus=1.5限制 CPU 使用率。但是这里有个配套问题：如果只限制容器内存，而不调整 JVM 的堆内存参数，JVM 可能还是会尝试申请超过容器限制的内存，导致容器被强制杀掉。所以需要把 JVM 参数跟容器限制联动起来。
比较直接的方法是设置环境变量：
-e JAVA_OPTS="-Xms512m -Xmx1024m -Dfile.encoding=UTF-8"-Xmx1024m把堆最大内存控制在 1GB，给容器留出足够余量，这样整个容器在-m 2g的限制下不会有内存超限的风险。之前在某个项目里遇到过容器反复OOMKilled的问题，docker inspect能看到OOMKilled字段是true，当时就是靠把 JVM 堆内存调小同时调整容器内存限制解决的。这个经验值得记一下：看到容器起来又立刻退出，先看docker inspect xxx | grep -i oom，真的有 OOM 就调整内存配置。
5. 排查实录：那些年我踩过的 Tomcat 容器坑
5.1 访问 404 的排查路径
对于刚用 Docker 跑 Tomcat 的人来说，404 问题排第一。现象很一致：容器状态Up，端口映射正常，但访问http://localhost:8080就是 404。
排查思路是这样的：先确认应用有没有在容器里。用docker exec -it进去看webapps目录里有没有内容。如果webapps是空的，就回到第 3 节说的，把webapps.dist改名或挂载自定义应用。如果webapps里有应用但访问还是 404，那就要看访问路径对不对，Tomcat 默认访问路径是应用名，比如http://localhost:8080/test/，不带应用名直接访问根路径只有在 ROOT 应用存在时才有效。
5.2 端口映射失败的几种情况
端口映射出问题时，常见现象是容器起不来，或者起来了但宿主机访问不到。最常见的是端口冲突，宿主机的 8080 已经被别的进程占了。解决办法有两个：换宿主机端口，比如-p 8081:8080；或者先停掉占用端口的进程。快速确认端口占用，可以用ss -lntp | grep 8080。
还有一种是防火墙问题。容器明明在跑，端口映射也在，但外部机器访问不了。这时候先检查宿主机防火墙是否放行了对应端口。公司内部服务器很多还套着安全组，这种情况需要在安全组规则里把端口放行，不然容器怎么折腾都没用。
5.3 容器频繁重启与日志定位法
容器起不来或一直重启，我一般用三步定位法：
先看状态：
docker ps -a如果容器状态显示Exited，用docker logs看最后一段日志。如果是配置文件有问题，日志里会明确提示。比如server.xml里改了端口号，但没放行对应端口映射，就会报Error listening on port。
如果容器一直在重启，可以看docker inspect里的RestartCount字段。配合docker events能实时看到容器生命周期事件。之前遇到过一次容器秒退，最后发现是挂载目录权限不对，宿主机目录所有者和容器内用户不一致，Tomcat 没有权限写日志目录。解决办法是把宿主机目录权限调成 777 或者设置成容器内所用用户能读写的权限，然后用ls -ld检查一下目录权限就清楚了。
5.4 常见问题速查表
| 现象 | 大概率原因 | 解决办法 |
|---|---|---|
| 访问 8080 返回 404 | webapps 目录为空 | 改名 webapps.dist 或挂载应用目录 |
| 容器启动后立即退出 | 端口冲突或配置错误 | docker logs 查看具体报错 |
| 外部访问不到 | 防火墙/安全组未放行 | 放行宿主机端口 |
| 中文日志乱码 | 字符集环境变量没设 | 加 JAVA_OPTS 指定 UTF-8 |
| 时间差 8 小时 | 容器时区为 UTC | 加 -e TZ=Asia/Shanghai |
| 容器被杀 OOM | JVM 堆超限 | 调整 -Xmx 与容器内存限制 |
| 老项目启动报 Servlet 异常 | Tomcat 10 包名不兼容 | 改用 9.0 系列镜像 |
这张表其实是我整理给项目组内部用的，每次新同事接手容器环境时，先看表再动手，能少走不少弯路。
6. 下一步：从容器到镜像的封装思路
6.1 直接 commit 容器镜像的坑
有时候我们临时改了容器里的一些配置，发现挺好用，就想把这些改动固化下来，做成镜像。最简单的做法是：
docker commit tomcat-demo my-tomcat:1.0这条命令会把容器当前的文件系统状态保存成新镜像。我刚接触时觉得特别方便，但实际在工程里不太推荐。原因有两个：一是commit出来的镜像没有构建过程，别人拿到这个镜像完全不知道里面改了什么，配置来源不明；二是如果容器里落了临时文件、缓存垃圾，也会一起打进镜像，镜像越来越臃肿。
6.2 用 Dockerfile 做可追溯的自定义镜像
我更推荐用 Dockerfile 的方式，把改动记录下来，变成可以重复构建的代码：
FROM tomcat:9.0-jdk8-temurin LABEL maintainer="ops-team" ENV TZ=Asia/Shanghai ENV JAVA_OPTS="-Xms512m -Xmx1024m -Dfile.encoding=UTF-8" # 拷贝项目 WAR 包 COPY test.war /usr/local/tomcat/webapps/test.war # 修改默认欢迎页目录设置，这一步根据项目需要 RUN rm -rf /usr/local/tomcat/webapps EXPOSE 8080 CMD ["catalina.sh", "run"]构建命令是：
docker build -t my-tomcat-app:1.0 .这种方式的优势，一是改动都在 Dockerfile 里，有迹可查；二是以后版本升级，只需要改一行基础镜像的版本号，重新构建就行。实际运维时还能跟 CI/CD 流水线结合，代码提交、触发构建、推送镜像、自动部署一气呵成。
6.3 镜像瘦身的两个实用手段
Tomcat 镜像本身不算小，但能优化。第一，选带slim或alpine标签的版本，体积能小不少。但要注意，alpine 的 libc 跟标准镜像不同，部分需要调用本地库的 Java 库可能出问题，我一般是先测试再决定。第二，清理临时文件。在 Dockerfile 里尽量一条RUN命令做完所有操作，然后顺手把临时下载的包删掉，尽量减小中间层体积。
镜像瘦身这事不用太激进，程序包从几百兆降到一百多兆，对单机部署的影响有限，但在批量发布或者传镜像到多个服务器时，节省的时间就很可观了。另外提醒一句，分析镜像层可以用：
docker history 镜像名能看到每一层的构建操作，排查“镜像怎么突然变大了”很有用。
7. 一点个人经验总结
跟 Docker 里的 Tomcat 打了这几年交道，最大的体会是：不要等到出了问题再想原理，容器使用中的大部分“怪现象”，根子都在基础概念上。比如端口映射、数据卷、镜像分层，理解了这三个，上面一大半坑都能避开。
选镜像不要盲目追新，老项目老老实实用 9.0 带 JDK 8 的标签，新项目也先确认依赖再看要不要上 10.x。启动容器时顺手把时区、字符集、JVM 参数、数据卷挂载全部配齐，省得后面来回改。
最后再分享一个小技巧：每次启动 Tomcat 容器前，先检查宿主机端口是不是被占了，用ss -lntp | grep 8080扫一眼；然后启动后立刻docker logs看前几行，能确认容器是真正进入运行状态了，而不是只看到了Up状态就以为万事大吉。这些习惯看起来不起眼，真正排障的时候，能帮你省下好几个小时的折腾时间。
