软件架构-tomcat之环境部署（下）

IT架构圈

发布于 2021-08-24 10:49:19

1.9K0

软件架构-tomcat之环境部署（上） tomcat生产环境的应用配置，这次的对各位老铁还是非常有用的。其实就是咱们生产环境实际要做的一些事情，有老铁联系我说，从之前说的docker还有现在很多部署基本都是跟运维关系很大，跟开发关系很少啊？其实老铁你误解我了，我的思路就是不管是在应用的环境，最后的部署希望的是各位老铁都能完全的熟悉。

Tomcat启动和部署方式（一）

以真实的项目为例，告诉大家如何去设置项目的部署。

现状

目前慢慢的jeakins 和 devops的普及越多越多的公司开始自动的部署。但是还有很多公司停留在：增量升级和打个war包来进行升级。来一起回顾下他们的流程

•增量升级

前提服务器的jdk和tomcat，和开发的要保持一致。
建立一个文件夹目录，放入文件class和jsp等文件。并且有个txt文件负责记录文件的名称和对应的要升级的目录
停止服务，服务器打包备份，然后一个一个进行替换。如果升级内容比较多，可能就哭了。
替换完毕，启动服务。

•整包升级

打好war包
停止Tomcat
上传并替换原程序Context目录
删除原来的WAR包
删除原来的Context 目录
进行 WEB-INF/classes/app.propertites config.propertites 目录找到应的配置文件并修改
启动Tomcat

•这么做的弊端是什么？

本身比较繁琐
发布失败回滚
tomcat需要升级，多个tomcat是不是需要一个一个来
jeankins也是这么做的，最后也是落到tomcat里面
tomcat做配置的时候也比较麻烦
tomcat重启的时候还需要进入bin目录下的catalina.shell

•生产环境下，单机多应用的配置

tomcat 是公共的，jdk是公共的。也就是service里面的APP1，APP2，APP3引用这个tomcat和jdk。

通过vagrant创建虚拟机，设置虚拟机的nds。192.168.67.103

•安装jdk

其实我很讨厌这种安装方式，但是为了给老铁们演示，因为这还是最主流的。我比较崇拜docker的容器镜像，还是回归话题正常操作，安装jdk。

•安装tomcat7

在这里选择你需要的tomcat https://mirrors.cnnic.cn/apache/tomcat/

下载安装tomcat

•开始部署service项目目录和shell脚本

1.编写原来的apche-tomcat制作软连接

1.启动配置shell脚本

创建shll脚本

脚本内容

查看目录结构发现tomcat的常用配置conf，lib，logs，temp，webapps都在，然后我们启动下这个tomcat，看看日志是否在logs目录上打印

•上边的方式就实现了，tomcat和jdk都是公共的，每个应用可以有自己的一套配置，只需要复制tomcat-1就可以了。完成里面的配置、tomcat-1其实就是我们下载的tomcat只是删除了一些公共的东西。

• 部署的流程

1.webapp目录下不放入任何的war包 2.创建war目录。上传的war都放入这个目录下，注意：上传的war包必须要有版本号 3.war解压后，是根据项目名称-版本号-日期合并产生的 4.appwar 软连接连接到对应的war解压的目录 5.在conf/Catalina/ 下建立ROOT.xml。配置解压war包产生的目录 6.如果回滚appwar软连接直接修改成war目录下指定的项目解压目录 7.在开发的时候可能存在svn和git上提交的代码都是测试环境，需要替换app.properties,可以创建一个app-conf目录。每次部署了自动替换项目中的配置文件。连接正式的数据库等等。

进入单个的tomcat-1中

创建deploy.sh

deploy.sh

运行测试

最终tomcat-1目录。1.app-conf 是配置文件 2.appwar 是项目连接的发布目录 3.current_deploy_dir 目前发布的目录 4.current_deploy.sh 指的是deploy.sh中 pom_a 发布的项目名称 5.war是上传的项目路径 6.webapps 里面是空的

基于shell 编写自定义启动脚本实现一键发布。如要完成以下功能。

1. Tomcat 执行文件与程序目录分离。（便于后续升级Tomcat或统一配置Tomcat）2. 一键部署发布应用3. 可快速回滚应用和配置4. 自定义配置应用

Tomcat server.xml配置详解（二）

实际上其实老铁们配置最多的可能就是context.xml
server.xml

•server 体系结构图

一个 server 可对应多个 service 元素的主要作用是将一到多个Connector 与一个 Engine 关联。当Connector 接收到请求后分发给 Engine 进行处理。
Host host 表示一个虚拟主机,默认使用localhost ，一个Engine 中可配置多个host 演示配置建立多个虚拟站点即Host (10分钟)
Context 表示应用加载目录通过 path 属性指定。其相对路径为 catalina_base 目录。可配置多个 Context。另外也可以在 catalina_base/conf/host_name/XXX.xml 中添加 Context 元素。

元素名	属性	解释
server	port	指定一个端口，这个端口负责监听关闭tomcat的请求
shutdown	指定向端口发送的命令字符串
service	name	指定service的名字
Connector(表示客户端和service之间的连接)	port	指定服务器端要创建的端口号，并在这个端口监听来自客户端的请求
minThread	服务器启动时创建的处理请求的线程数
maxThread	最大可以创建的处理请求的线程数
enableLookups	如果为true，则可以通过调用request.getRemoteHost()进行DNS查询来得到远程客户端的实际主机名，若为false则不进行DNS查询，而是返回其ip地址
redirectPort	指定服务器正在处理http请求时收到了一个SSL传输请求后重定向的端口号
acceptCount	指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理
connectionTimeout	指定超时的时间数(以毫秒为单位)
Engine(表示指定service中的请求处理机，接收和处理来自Connector的请求)	defaultHost	指定缺省的处理请求的主机名，它至少与其中的一个host元素的name属性值是一样的
Context(表示一个web应用程序，通常为WAR文件，关于WAR的具体信息见servlet规范)	docBase	应用程序的路径或者是WAR文件存放的路径
path 表示此web应用程序的url的前缀，这样请求的url为http://localhost:8080/path/****
reloadable	这个属性非常重要，如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化，自动装载新的应用程序，我们可以在不重起tomcat的情况下改变应用程序
host(表示一个虚拟主机)	name	指定主机名
appBase	应用程序基本目录，即存放应用程序的目录
unpackWARs	如果为true，则tomcat会自动将WAR文件解压，否则不解压，直接从WAR文件中运行应用程序
Logger(表示日志，调试和错误信息)	className	指定logger使用的类名，此类必须实现org.apache.catalina.Logger 接口
prefix	指定log文件的前缀
suffix	指定log文件的后缀
timestamp	如果为true，则log文件名中要加入时间，如下例:localhost_log.001-10-04.txt
Realm(表示存放用户名，密码及role的数据库 )	className	指定Realm使用的类名，此类必须实现org.apache.catalina.Realm接口
Valve(功能与Logger差不多，其prefix和suffix属性解释和Logger 中的一样)	className	指定Valve使用的类名，如用org.apache.catalina.valves.AccessLogValve类可以记录应用程序的访问信息
directory	指定log文件存放的位置
pattern	有两个值，common方式记录远程主机名或ip地址，用户名，日期，第一行请求的字符串，HTTP响应代码，发送的字节数。combined方式比common方式记录的值更多