Linux环境Tomcat安装配置与部署实战：从JDK到systemd全指南

1. 装前必读Tomcat和JDK的版本匹配是第一道坎1.1 先弄明白Tomcat在Linux里扮演什么角色很多人第一次接触Tomcat是在Windows的课堂上装了之后双击startup.bat浏览器里看到一个猫就以为完事了。但换到Linux服务器上情况完全不一样没有图形界面没有一键安装包甚至没有JAVA_HOME你连启动脚本都会直接报错。这也是为什么“Linux环境下Tomcat安装与配置”看起来只是click点来实则每一步都踩版本、权限和环境变量的坑。先弄清楚Tomcat到底是干嘛用的。Tomcat是一个Servlet容器也叫Web应用服务器它负责把你写好的Java Web应用跑起来。你写的Servlet、JSP、Filter单靠JDK是无法直接跑成Web服务的必须有一个类似Tomcat这样的容器来接收HTTP请求加载类执行逻辑再返回响应。生产环境里Tomcat经常和Nginx搭配使用Nginx在前面接收80端口流量Tomcat在8080被Nginx反向代理这就是最常见的Java后端部署架构之一。准备把Tomcat部署到Linux得先把目标搞清楚是给本地开发用还是给测试服务器用还是直接面向生产这三类场景的配置差距比想象中大。本地开发重快捷测试服务器重可重复生产环境重安全和服务化托管。我下面所有操作步骤都兼顾三种场景但会在关键位置指出生产环境建议你照着做基本不会跑偏。1.2 JDK选择与JAVA_HOME配置很多人挂在第一步Tomcat本身是用Java写的所以没有JDK一切免谈。这里最容易犯的错误是先装了Tomcat再装JDK或者JDK版本和Tomcat严重不匹配。官方文档里每个Tomcat主版本都标定了最低JDK版本这里给你一张对照表建议直接按表选型。Tomcat版本最低JDKServlet规范Jakarta命名空间Tomcat 9.0JDK 8以上Servlet 4.0javax.*Tomcat 10.0JDK 8以上Servlet 4.0jakarta.*Tomcat 10.1JDK 11以上Servlet 6.0jakarta.*Tomcat 11JDK 17以上Servlet 6.1jakarta.*选择逻辑很简单如果项目还在用Spring Boot 2.3之前的版本或者老项目跑在javax.*包名上就选Tomcat 9如果你用的是Spring Boot 3、Spring Framework 6这类新生态直接上Tomcat 10.1或Tomcat 11。别听网上“越新越好”的瞎指挥Tomcat 10彻底换成了jakarta.*命名空间老项目拷进去编译不过、启动报ClassNotFoundException的案例我见过不下十次。JDK安装我推荐用系统包管理器装OpenJDK这是Linux上最省心的方式。Debian/Ubuntu系sudo apt update sudo apt install -y openjdk-11-jdkCentOS/RHEL系sudo yum install -y java-11-openjdk-devel装完先确认路径不要靠脑子记。不同发行版、不同版本JDK路径差异很大我见过有人硬写/usr/lib/jvm/java-8-openjdk结果目录不存在后面所有启动都失败。which java readlink -f $(which java)Ubuntu上典型输出是/usr/lib/jvm/java-11-openjdk-amd64/bin/java去掉最后的/bin/java就是你需要的JAVA_HOME。配置环境变量建议写到/etc/profile.d/tomcat.sh不要直接改/etc/profile独立文件更便于维护。sudo tee /etc/profile.d/jdk.sh EOF export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 export PATH$PATH:$JAVA_HOME/bin EOF source /etc/profile.d/jdk.sh java -version看到类似openjdk version 11.0.22的输出JDK这部分就算过了。注意我在这里把环境变量独立成一个文件而不是塞进/etc/profile因为将来更新JDK版本你只需要改这一个文件不会污染系统全局配置。2. 下载与安装比想象中更需要注意的几个细节2.1 从哪里下载、选哪个安装包Tomcat官方提供三种发布形式源码包、tar.gz二进制包、以及Windows专用zip包。在Linux上我们只需要tar.gz二进制包它已经把编译好的类库全部打好了解压即用。源码包是用来自己编译的普通部署根本不用碰。还有一位“二进制包”官方发行版都会在目录里提供一个apache-tomcat-9.0.xx.tar.gz和一个apache-tomcat-9.0.xx-src.tar.gz认准不带-src的那个。去Apache官网找到对应版本的二进制发行档案或者直接用wget下载。注意最好通过官方推荐的站点下载确保包完整性下载完一定要做SHA512校验。Apache提供了.sha512文件在校验时可以拿它做对比。wget https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.89/bin/apache-tomcat-9.0.89.tar.gz wget https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.89/bin/apache-tomcat-9.0.89.tar.gz.sha512 sha512sum -c apache-tomcat-9.0.89.tar.gz.sha512如果输出OK说明下载文件完整可以继续。这一步看似多余但生产环境部署包被篡改的事情不是没发生过养成校验习惯只有好处。另外版本号尽量用当前稳定版不要用测试版除非你明确知道自己需要某个新特性。2.2 创建独立用户和服务目录别把tomcat跑在root下这是我和很多初学者反复强调的点Tomcat不要用root启动。原因很简单Web服务直接面对外部流量一旦应用被攻破攻击者拿到的是root权限整个服务器都跟着投降。正确的做法是创建用途单一的系统用户再把Tomcat目录交给这个用户。sudo mkdir -p /opt/tomcat sudo useradd -r -s /sbin/nologin -d /opt/tomcat tomcat-r表示创建系统用户-s /sbin/nologin表示不允许该用户登录系统。这个用户唯一的工作就是运行Tomcat进程。然后再把下载好的tar.gz解压到/opt/tomcat并且要把解压结果整理成标准目录结构。2.3 解压、目录归属与基础验证跑通第一个启动命令sudo tar -zxvf apache-tomcat-9.0.89.tar.gz -C /opt/tomcat --strip-components1 sudo chown -R tomcat:tomcat /opt/tomcat sudo find /opt/tomcat -type d -exec chmod 755 {} \; sudo find /opt/tomcat -type f -exec chmod 644 {} \; sudo chmod x /opt/tomcat/bin/*.sh--strip-components1的意思是解压时把最外层目录名apache-tomcat-9.0.89剥掉这样内容直接落在/opt/tomcat下。如果你不用这个参数就会多套一层目录启动脚本路径就会变成/opt/tomcat/apache-tomcat-9.0.89/bin/startup.sh后续配置容易乱。这里我为什么要单独执行bin目录的加执行权限因为上面已经把目录设为755、文件设为644sh文件默认不是可执行状态。虽然启动时可以调用sh startup.sh绕过执行权限但service方式会直接用ExecStart/opt/tomcat/bin/startup.sh不加上执行权限你会看到一整晚都排查不出来的Permission denied。先在命令行跑一次版本验证。切换到tomcat用户看设计得正不正规sudo -u tomcat /opt/tomcat/bin/version.sh输出里能看到Server version: Apache Tomcat/9.0.89、JVM Version这些信息就说明JDK环境和Tomcat本身没问题。3. 配置文件逐个讲server.xml、context.xml、tomcat-users.xml3.1 server.xml里的端口、Host和ExecutorTomcat的核心配置都集中在conf/server.xml。新手最常见的操作就是改端口号但经常只改了一个端口。要知道Tomcat默认监听三个端口端口默认值用途Shutdown8005接收关闭命令的本地端口HTTP/1.18080对外HTTP访问端口AJP/1.38009连接Apache/Nginx等前端服务器的二进制协议如果80端口被Nginx占用你需要把HTTP端口改成8080以外的空闲端口如果8005端口冲突启动时会立刻报java.net.BindException: Address already in use。下面是修改HTTP连接器的基础示例同时便宜设置了两个重要参数Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 maxThreads300 minSpareThreads50 URIEncodingUTF-8 /URIEncodingUTF-8这个参数对中文URL参数特别重要。Linux系统默认locale如果没设置好不指定这个参数请求参数里的中文很容易变成乱码。maxThreads控制最大并发处理线程生产环境建议结合机器内存调整默认200有时候遇到活动高峰明显不够但盲目调到1000会造成线程频繁切换性能反而更差。生产环境我会再考虑几点autoDeploy参数在Host元素上开发环境可以打开生产环境建议设置为false避免Hots插件hot热部署意外把半成品WAR包发布出去unpackWARs同样在开发机上有用生产环境大多直接部署展开后的目录可以保持默认true。3.2 context.xml里的默认容器配置影响全局的Session和监听器conf/context.xml控制着所有应用共享的默认Context容器。这个文件里最常见的问题是JVM参数和Session配置长篇大论。新手一般不需要改它但有几个点需要你认识一下。Manager pathname /这个配置是用来禁用Session持久化的。默认情况下Tomcat在关闭时会把Session状态序列化到work目录下的SESSIONS.ser文件里下次启动再加载。这样做的本意是平滑重启但实际开发中经常出现“改完代码重启TomcatSession还残留着旧状态”的诡异问题。如果你不需要这个特性可以把pathname设为空字符串Context Manager pathname / WatchedResourceWEB-INF/web.xml/WatchedResource /Context另外conf/context.xml里也可以统一配置JarScanner但一般保持默认即可。频繁改这个文件的风险大于收益。3.3 开启Manager权限的tomcat-users配置等五分钟才能操作Tomcat自带的Manager应用在刚安装完时默认是禁止访问的你必须先在conf/tomcat-users.xml里添加角色和用户。tomcat-users role rolenamemanager-gui/ role rolenamemanager-script/ role rolenameadmin-gui/ user usernameadmin passwordYourStrongPass rolesmanager-gui,manager-script,admin-gui/ /tomcat-usersmanager-gui允许登录网页端管理界面manager-script允许通过HTTP命令远程部署WAR包。生产环境不要开启manager-gui只保留manager-script配合自动化发布工具使用就够了。这个文件如果配置错误Tomcat启动时不会报错但你访问/manager会看到403页面排查思路先看这里。顺带说一句很多人修改tomcat-users.xml之后重启发现还是不生效原因多半是没看conf/Catalina/localhost/manager.xml这个文件。新版Tomcat默认对该应用做了基于IP地址的访问限制修改conf/server.xml里Valve中的allow配置或者放行指定IP否则本机访问可以、远程访问就是403。4. 让Tomcat跟随系统自启动systemd方案全记录4.1 为什么不用服务器里写启动命令直接挂后台的方式网上很多老文章教你用nohup /opt/tomcat/bin/startup.sh 让Tomcat后台运行。这在开发机上也许凑合但生产环境会遇到三个问题一是Tomcat进程和终端脱钩没人帮你看护进程意外退出不会自动拉起二是服务器重启后需要人工登录再启动三是root退出后孤儿进程的资源回收容易产生僵尸态。正确做法是写一个systemd服务单元让系统来管理Tomcat的生命周期。如果你用CentOS 7以下的旧系统才需要考虑init.d方式现在主流Linux发行版都用systemd所以下文统一按systemd写。4.2 写一个可长期运行的systemd unit注意Type要选对在/etc/systemd/system/tomcat.service里写入下面的配置[Unit] DescriptionApache Tomcat 9 Web Application Server Afternetwork.target syslog.target [Service] Typeforking Usertomcat Grouptomcat EnvironmentJAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 EnvironmentCATALINA_HOME/opt/tomcat EnvironmentCATALINA_BASE/opt/tomcat EnvironmentCATALINA_PID/opt/tomcat/temp/tomcat.pid ExecStart/opt/tomcat/bin/startup.sh ExecStop/opt/tomcat/bin/shutdown.sh Restarton-failure RestartSec10 [Install] WantedBymulti-user.targetTypeforking很关键。startup.sh本身会以nohup方式把Tomcat进程丢到后台然后脚本立即退出如果设置成Typesimplesystemd会认为主进程已经退出把整个服务标记为失败。指定forking后systemd会等待CATALINA_PID指向的进程出现再判定服务启动成功。另外Restarton-failure也不是随手写上去的。生产环境里进程OOM或被外部kill掉systemd会等10秒自动重启能把服务可用性拉高一大截。但注意不要把Restartalways和RestartSec1一起用否则如果应用启动必失败每隔几秒你的日志里全是错误磁盘会被刷爆。4.3 启动、停止、状态与开机自启验证写完之后重新加载systemd配置然后设置开机自启sudo systemctl daemon-reload sudo systemctl enable tomcat sudo systemctl start tomcat sudo systemctl status tomcat -l状态输出里必须看到Active: active (running)。接着用curl验证80行端口curl -I http://127.0.0.1:8080返回HTTP/1.1 200就说明服务已经正常起来了。另外我通常还会检查一下Tomcat日志中是否出现异常因为这个阶段systemctl status未必展示所有细节sudo tail -f /opt/tomcat/logs/catalina.out启动成功后主动重启一次服务器再确认Tomcat是否真的自动起来了。如果没起来大概率是JAVA_HOME环境变量没在unit里正确声明或者/opt/tomcat/logs目录的所有者不是tomcat用户。这两个坑占了自启动失败的八成原因。5. 部署Web应用与排查启动异常实践环节最长的体现5.1 WAR包部署的四种常见方式按场景选就行要把应用部署到Tomcat最直观的方式是把WAR包复制到webapps目录。Tomcat的Host容器默认设置了autoDeploytrue会定时扫描该目录发现新的WAR包或目录后自动加载。复制进去之前建议先停止Tomcat服务再拷贝否则可能出现文件没拷完就开始解压的问题。sudo systemctl stop tomcat sudo cp /data/myapp.war /opt/tomcat/webapps/ sudo chown tomcat:tomcat /opt/tomcat/webapps/myapp.war sudo systemctl start tomcat启动后观察logs/catalina.out看到Deploying web application archive ... has finished in xxx ms就说明部署成功。此时访问http://ip:8080/myapp就能看到应用。第二种方式是通过Manager的图形界面部署适合零散的手动操作。前提是前面已经配置好了manager-gui角色打开http://ip:8080/manager/html输入用户名密码浏览上传WAR包即可。第三种方式是用Manager的脚本API做远程部署这个适合写进Jenkins或CI脚本。manager-script角色是必需的curl -u admin:YourStrongPass \ --upload-file /data/myapp.war \ http://127.0.0.1:8080/manager/text/deploy?path/myappupdatetrue脚本API返回OK - Deployed application at context path /myapp就算部署成功。这个方式可以做到全自动化发布推荐生产环境配合使用。第四种方式是在conf/Catalina/localhost/下一个myapp.xml这个XML直接对外定义Context的docBase好处是应用可以放在webapps之外的其他目录方便脚本和老区文件独立管理。5.2 启动报错别瞎猜先把日志层级理清楚Tomcat的日志放在logs目录下但初学者经常分不清看哪个。简单说catalina.out是控制台输出包含主进程运行日志启动报错第一时间看这里catalina.YYYY-MM-DD.log是每天生成的详细日志localhost.YYYY-MM-DD.log里面判断应用加载过程中容器内部的日志manager.*等模块日志一般不常看。常见的启动报错基本有这几类症状常见原因快速验证方法Address already in use端口冲突ss -lntpNeither JAVA_HOME nor JRE_HOME defined环境变量没生效echo $JAVA_HOME或 systemd unit查看Permission denied目录属主不对ls -ld /opt/tomcat/logsClassNotFoundException javax.servlet...Tomcat版本与应用servlet规范不匹配检查应用web.xml及依赖The web application... has failed to startweb.xml或Spring初始化出错看localhost.*.log看到catalina.out里的堆栈异常时别只截前两行完整日志中最后一行的Caused by才是根因。尤其是Spring Boot应用Shade这个依赖时真正的错误经常沉在多级Caused by底下。5.3 常见问题速查端口、权限、乱码和IDEA 404都遇到过吧端口被占Address already in use: JVM_Bind。先确认端口被谁占用然后决定是杀掉占用进程还是改Tomcat端口。别上来就kill先看是nginx还是其他Java进程改了端口之后所有调用方都要跟着改成本不小。ss -lntp | grep 8080权限问题Tomcat启动后报无法写logs/catalina.out几乎都是因为用root解压后目录所有者为root而systemd service里Usertomcat写不出日志。解决方法是sudo chown -R tomcat:tomcat /opt/tomcat/logs /opt/tomcat/work /opt/tomcat/temp启动卡住不报错生产服务器经常遇到Tomcat启动到一半卡住半天不打印Server startup in。时间多是因为JVM在Linux上获取随机数时/dev/random阻塞导致SecureRandom初始化很慢。解决方法是给JVM加参数-Djava.security.egdfile:/dev/urandom中文乱码看到访问URL里的中文参数乱码检查server.xml连接器有没有配置URIEncodingUTF-8应用响应乱码检查应用的web.xml中是否设置了request.setCharacterEncoding(UTF-8)或者过滤器。Linux服务器语言包是LANGC.UTF-8时通常问题出在应用自身编码而不是系统。IDEA配置Tomcat后报404如果看到“Tomcat 描述 源服务器未能找到目标资源的表示或者是不愿公开一个已经存在的”这种提示基本是IDEA部署Web应用时的Deployment配置没有把artifact加到Server中。在IDEA里打开Run/Debug Configurations找到Deployment页签点击加号添加你要部署的war exploded并把Application context设置成对应路径问题就消失了。6. 上线前的基础加固走完这几步才能谈生产环境6.1 禁用默认应用与降权运行别把一个危险的默认状态丢到公网Tomcat解压后默认带着docs、examples、manager、host-manager这些自带应用。开发阶段用它们很方便但上线前必须处理掉尤其不能让manager暴露到公网。否则攻击者可以尝试弱口令登录管理后台一旦成功就能上传恶意WAR包等于把服务器管理权限拱手送出。我的习惯是把webapps目录清空只建立ROOT目录或者干脆把默认目录全部删掉只保留自己部署的应用。同时把conf/server.xml里的Shutdown端口设为随机的强密码或直接关闭外部访问。Tomcat的8005端口本来只监听本机但要防止防火墙意外放行了这个端口建议改成Server port-1 shutdownSHUTDOWN禁用远程关闭命令。AJP端口如果不用Nginx和Apache做协议对接建议直接注释掉既减少攻击面也避免AJP/1.3端口被被绕过利用的风险。给Tomcat分配独立用户和独立目录前面已经做了。额外检查一下/opt/tomcat/conf目录权限Tomcat用户只有只允许读配置的权限不放开写权限。Web上传功能如果把文件写到webapps目录应用存在被写木马的风险所以生产环境的webapps目录不要给写权限sudo chmod -R 555 /opt/tomcat/webapps sudo chmod -R 750 /opt/tomcat/conf6.2 用Nginx把Tomcat从公网“藏”到内网整套部署也算完整了单独把Tomcat的8080端口对公网算是下策。原因有三一个8080端口天然不适合HTTPS证书绑定和HTTP/2优化第二个Nginx能挡掉一部分恶意请求第三Tomcat本身对静态资源的处理速度远不如Nginx。所以生产部署最常见的布局是Nginx监听80/443反向代理到内网128.0.0.1:8080的Tomcat。Nginx的核心配置片段如下写在/etc/nginx/conf.d/tomcat.conf中server { listen 80; server_name example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ~* \.(css|js|png|jpg|gif|ico|woff2)$ { expires 30d; add_header Cache-Control public; proxy_pass http://127.0.0.1:8080; } }proxy_set_header X-Forwarded-For这一点对Java应用很重要。Tomcat很多业务代码需要通过request.getRemoteAddr()获取真实IP如果没有Nginx把这些转发头带过去应用拿到的都是127.0.0.1后面做日志分析、异地登录检查都会出错。如果只是静态资源走Nginx缓存必须在资源后缀路径中同样业务请求分开不要让Nginx把带鉴权的动态页面也缓存掉。配上HTTPS的话把443端口监听加上SSL证书proxy_pass还是指向http://127.0.0.1:8080由Nginx终止TLSTomcat依然走明文内网协议。Tomcat server.xml连接器可以不用动应用感知的协议信息通过X-Forwarded-Proto传递即可。这套部署完成后Tomcat不直接面对公网安全等级上了一个台阶同时分担了静态资源压力。整个Linux环境下从安装、配置、托管服务到部署、镜像到最后Nginx接入才算一条完整的链路。最后再分享一个我长期用的经验操作完之后把/opt/tomcat/conf/server.xml改动的段落单独存一个diff记录尤其是端口、连接器线程数、URIEncoding这几项。Tomcat版本升级时直接用diff比对旧配置比重新逐行读文档快得多。Linux部署这类事情最怕的不是不会配置而是配完忘了改过什么。留好变更记录后面遇到诡异问题能省好几个小时。