打开 Tomcat 看看里面有什么

在 LabHub 中继续学习

一句话总结

Tomcat只要知道目录七个角色就能说明大部分运行情况，其中实际发生故障的地方是bin/setenv.sh·work/·logs/catalina.out是三。

概念图: 在独立执行的Tomcat上上传WAR · bin/setenv.sh · 一定要放在setenv.sh里。 · work/

为什么还是Tomcat呢

穿弹力靴的话，里面有内置的Tomcat。java -jar以结束。但是如果去国内SI现场的话，仍然有在独立执行的Tomcat上上传WAR的系统。要多得多。原因不是技术上的偏好。

运营组织以WAS单元管理。在一个服务器上上传多个业务WAR，机动/停止/监控程序以WAS为标准化。
标准框架（包括电子政府标准框架）和部署手册以WAR为标准编写。
使用WebLogic/JEUS的组织为了节省成本而转用Tomcat时，运营方式保持不变。

所以新员工在第一周被淘汰的事情就是“请把汤姆猫放上去”。还有那一刻systemctl start tomcat遇到了这个不行的服务器。

目录地图

/opt/tomcat
├── bin/       기동·정지 스크립트. catalina.sh, startup.sh, shutdown.sh, setenv.sh
├── conf/      설정. server.xml, web.xml, context.xml, tomcat-users.xml, logging.properties
├── lib/       톰캣 자신과 모든 웹앱이 공유하는 JAR (JDBC 드라이버를 여기 두는 관행)
├── logs/      catalina.out, localhost_access_log.*.txt, 각종 *.log
├── webapps/   배포 대상. WAR 를 두면 자동으로 같은 이름 디렉터리로 전개된다
├── work/      JSP 를 컴파일한 .java/.class 캐시
└── temp/      java.io.tmpdir

只说一下现场实际出现问题的点。

bin/setenv.sh — 这是Tomcat不提供的基本文件，如果有的话catalina.sh去自动读取。JVM选项(CATALINA_OPTS)放在这里。 catalina.sh直接修改的话，上传Tomcat版本时会消失。一定要放在setenv.sh里。
work/ — 发行后，如果画面和以前一样，大概八成是在这里找到的。在发行手册上这就是为什么要删除“work目录”。
logs/catalina.out — 无法旋转。如果放任不管的话，会变成几十GB。导致磁盘碎片导致的障碍原因排名第一的是这个文件。
lib/vsWEB-INF/lib/ — 如果同一库在两边有不同的版本的话随着班级的增加，地狱也随之打开。NoSuchMethodError去的话从这里开始看。

server.xml的层次

server.xml是俄罗斯娃娃。从外面往里读的话理解得很快。

<Server port="8005" shutdown="SHUTDOWN">      <!-- JVM 하나 -->
  <Service name="Catalina">                   <!-- 커넥터들 + 엔진 하나 -->
    <Connector port="8080" protocol="HTTP/1.1" ... />   <!-- 바깥과 만나는 문 -->
    <Engine name="Catalina" defaultHost="localhost">    <!-- 요청 처리 엔진 -->
      <Host name="localhost" appBase="webapps"          <!-- 가상 호스트 -->
            unpackWARs="true" autoDeploy="true">
        <Valve className="...AccessLogValve" pattern="%h %l %u %t &quot;%r&quot; %s %b" />
      </Host>
    </Engine>
  </Service>
</Server>

Server的port="8005"不是服务端口，而是终止命令接收端口。 shutdown.sh在这里用TCP连接SHUTDOWN发送一个字符串。也就是说，如果这个端口打开，字符串是默认值的话，任何人都可以用TELNET下载WAS。 这是安全检查中经常被指出的项目，措施有两种： shutdown把字符串变长或port="-1"完全停用。 -1做的话shutdown.sh因为不能去kill在手续书中写下了必须下楼的要点。
Connector在后端模块中整体处理。这里只记住一个吧—— 连接器可以放置多个，每个连接器都有不同的端口/协议/多线程。
Host的appBase 去webapps并且autoDeploy="true"所以如果复制WAR的话展开。在运营中autoDeploy="false"放在那里，分发脚本明确地也有很多组织需要展开。是为了防止意外地把文件放进去的事故。
AccessLogValve 的pattern在**%D仍然有很多没有输入（处理时间ms）**的系统。如果访问日志中没有响应时间，那么收到“慢”的报告时就没有任何依据。这个在开放前一定要放进去。

context.xml — 网络应用程序单元设置

conf/context.xml恩全域，conf/Catalina/localhost/<앱이름>.xml是每个应用程序的设置。使用后者的话**webapps可以服务外部的目录**(docBase). 分发成果物/app/deploy/order在这里，不碰Tomcat的运营方式就出来了。

DB连接池(<Resource>）也一般在这里。所以“DB连接信息在哪里”的答案一般是context.xml或应用程序的属性文件中的一者。

移动和静止——没有systemd时

# 기동 (백그라운드, catalina.out 으로 로그)
/opt/tomcat/bin/catalina.sh start

# 포그라운드 (컨테이너에서 쓰는 방식. 로그가 터미널로)
/opt/tomcat/bin/catalina.sh run

# 정지 (8005 포트로 SHUTDOWN 전송, 종료 대기)
/opt/tomcat/bin/catalina.sh stop 30 -force

stop后面的30 -force是“等30秒，如果没死就kill”。在操作脚本中最好放这个。如果有正在处理会话的线程的话汤姆猫有时会乖乖地不死。

确认是否启动的最可靠的方法不是过程，而是日志和端口。

grep 'Server startup in' /opt/tomcat/logs/catalina.out | tail -1
ss -ltn | grep 8080

实际上存在“进程正在运行，但端口未打开”。只有由于端口冲突或初始化失败而导致连接器死亡的情况。只看进程看到“上来了”后，5分钟后又接到电话。

在现场相遇的样子

在SI现场第一次接触Tomcat的第一周，通常会经历这三种情况之一。

“我放了JVM选项，但是没用。”catalina.sh亲自修改了，setenv.sh并没有重新启动。是否反映不是要问文件，而是要问进程——/proc/<pid>/cmdline查看实际执行参数。
“发布了，但画面还是原样。”work/剩下的JSP编译缓存。发布手册中包含“删除work目录”的原因就是这个，实际会因为缺少这一行手册而浪费几个小时。
“磁盘满了。”catalina.out没有轮换。不是Tomcat，而是要从logrotate那里切掉，如果不管的话，就会变成几十GB。

这三个问题都不是一旦不知道Tomcat就会出现的，而是因为不知道某个文件做什么而出现的。所以目录地图是第一位的。