tomcat生产环境得应用配置,这次的对各位老铁还是非常有用的。其实就是咱们生产环境实际要做的一些事情,有老铁联系我说,从之前说的docker还有现在很多部署基本都是跟运维关系很大,跟开发关系很少啊?其实老铁你误解我了,我的思路就是不管是在应用的环境,最后的部署希望的是各位老铁都能完全的熟悉。
源码:https://github.com/limingios/netFuture/tree/master/tomcat-pro
以真实的项目为例,告诉大家如何去设置项目的部署。
#####现状
目前慢慢的jeakins 和 devops的普及越多越多的公司开始自动的部署。但是还有很多公司停留在:增量升级和打个war包来进行升级。来一起回顾下他们的流程
整包升级
1.打好war包
2.停止Tomcat
3.上传并替换 原程序Context目录
4.删除原来的WAR包
5.删除原来的Context 目录
6.进行 WEB-INF/classes/app.propertites config.propertites 目录 找到应的配置文件并修改
7.启动Tomcat
这么做的弊端是什么?
1.本身比较繁琐
2.发布失败回滚
3.tomcat需要升级,多个tomcat是不是需要一个一个来
4.jeankins也是这么做的,最后也是落到tomcat里面
5.tomcat做配置的时候也比较麻烦
6.tomcat重启的时候还需要进入bin目录下的catalina.shell
生产环境下,单机多应用的配置
tomcat 是公共的,jdk是公共的。也就是service里面的APP1,APP2,APP3引用这个tomcat和jdk。
通过vagrant创建虚拟机,设置虚拟机的nds。192.168.67.103
vagrant up su - #密码 vagrant vi /etc/resolv.conf #nameserver 8.8.8.8
安装jdk
>其实我很讨厌这种安装方式,但是为了给老铁们演示,因为这还是最主流的。我比较崇拜docker的容器镜像,还是回归话题正常操作,安装jdk。
yum install -y wget wget wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/8u141-b15/336fa29ff2bb4ef291e347e091f7f4a7/jdk-8u141-linux-x64.tar.gz" #上边的下载比较慢,建议不通过wget的方式,本地下载后上传上去,我下载了3个多小时,当时正好想看电视剧看了几集 tar -zxvf jdk* cd jdk* #获取jdk目录填写到下面JAVA_HOME中 pwd #追加环境变量 echo "export JAVA_HOME=/root/jdk1.8.0_141" >> /etc/profile echo "export PATH=$""JAVA_HOME/bin:$""PATH" >> /etc/profile #执行下面这个才能生效 source /etc/profile java -version javac -version
安装tomcat7
>在这里选择你需要的tomcat https://mirrors.cnnic.cn/apache/tomcat/
下载安装tomcat
cd ~ #wget tomcat下载的时候很快 wget https://mirrors.cnnic.cn/apache/tomcat/tomcat-7/v7.0.92/bin/apache-tomcat-7.0.92.tar.gz tar -zxvf apache-tomcat* #运行下tomcat看能否启用 cd apache-tomcat* cd bin ./catalina.sh start
1.编写原来的apche-tomcat制作软连接
cd ~ ln -s ln -s jdk1.8.0_141/ jdk ln -s apache-tomcat-7.0.92/ tomcat #创建service群,里面可以放很多个tomcat mkdir services cd services #讲tomcat拷贝到service里面一份更改名称叫tomcat-1 cp -r ~/apache-tomcat-7.0.92 tomcat-1 cd tomcat-1 #删除项目中无用的 rm -rf apache-tomcat-7.0.92/ bin BUILDING.txt CONTRIBUTING.md LICENSE NOTICE README.md RELEASE-NOTES RUNNING.txt
启动配置shell脚本
>创建shll脚本
cd ~ cd services/tomcat-1/ vi tomcat.sh chmod 777 tomcat.sh
脚本内容
#!/bin/bash export JAVA_OPTS="-Xms100m -Xmx200m" export JAVA_HOME=/root/jdk/ export CATALINA_HOME=/root/tomcat export CATALINA_BASE="`pwd`" case $1 in start) $CATALINA_HOME/bin/catalina.sh start echo start success!! ;; stop) $CATALINA_HOME/bin/catalina.sh stop echo stop success!! ;; restart) $CATALINA_HOME/bin/catalina.sh stop echo stop success!! sleep 2 $CATALINA_HOME/bin/catalina.sh start echo start success!! ;; esac exit 0
查看目录结构发现tomcat的常用配置conf,lib,logs,temp,webapps都在,然后我们启动下这个tomcat,看看日志是否在logs目录上打印
./tomcat start ./tomcat stop
部署的流程
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中
cd services cd tomcat-1 ll
创建deploy.sh
vi deploy.sh cat delop.sh mkdir war mkdir app-conf
deploy.sh
#!/bin/bash -e pom_a=$1 pom_v=$2 export work_time=$(date +%Y-%m-%d_%H-%M-%S) #1. download war, ready env echo "deploy time: $work_time" mkdir -p war/ war=war/${pom_a}_${pom_v}.war deploy_war() { target_d=war/${pom_a}-${pom_v}-$work_time target_dir=`pwd`/$target_d if [ ! -f "$war" ]; then echo "war not exist: $war" exit 1 fi unzip -q $war -d $target_dir #cp -r `pwd`/app-conf/* $target_dir/WEB-INF/classes/ rm -f appwar ln -sf $target_d appwar if [ -f current_deploy.sh ] then ./tomcat.sh stop cat current_deploy_dir > last_deploy fi target_ln=`pwd`/appwar echo '<?xml version="1.0" encoding="UTF-8" ?> <Context docBase="'$target_ln'" allowLinking="true"> </Context>' > `pwd`/conf/Catalina/localhost/ROOT.xml echo -ne "#!/bin/bash -e/npom_a=${pom_a}/npom_v=${pom_v}" > current_deploy.sh echo -ne "${target_d}" > current_deploy_dir chmod +x current_deploy.sh ./tomcat.sh start } deploy_war
运行测试
yum install -y unzip zip yum install -y lrzsz cd ~/services/tomcat-1/ chmod 777 deploy.sh cd war #上传文件例如:com_V1.0.0 rz cd .. mkdir -p /root/services/tomcat-1/conf/Catalina/localhost/ # com 是项目名,V1.0.0上传的版本号 ./deploy.sh com V1.0.0
最终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. 自定义配置应用
实际上其实老铁们配置最多的可能就是context.xml
server.xml
<Server> <Listener /><!-- 监听器 --> <GlobaNamingResources> <!-- 全局资源 --> </GlobaNamingResources <Service> <!-- 服务 用于 绑定 连接器与 Engine --> <Connector 8080/> <!-- 连接器--> <Connector 8010 /> <!-- 连接器--> <Connector 8030/> <!-- 连接器--> <Engine> <!-- 执行引擎--> <Logger /> <Realm /> <host "www.tl.com" appBase=""> <!-- 虚拟主机--> <Logger /> <!-- 日志配置--> <Context "/luban" path=""/> <!-- 上下文配置--> </host> </Engine> </Service> </Server>
一个 server 可对应多个 service
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方式记录的值更多 ||
Tomcat 会话管理器
* StandardManager
Tomcat6的默认会话管理器,用于非集群环境中对单个处于运行状态的Tomcat实例会话进行管理。当Tomcat关闭时,这些会话相关的数据会被写入磁盘上的一个名叫SESSION.ser的文件,并在Tomcat下次启动时读取此文件。
* PersistentManager
当一个会话长时间处于空闲状态时会被写入到swap会话对象,这对于内存资源比较吃紧的应用环境来说比较有用。
* DeltaManager
用于Tomcat集群的会话管理器,它通过将改变了会话数据同步给集群中的其它节点实现会话复制。这种实现会将所有会话的改变同步给集群中的每一个节点,也是在集群环境中用得最多的一种实现方式。
* BackupManager
用于Tomcat集群的会话管理器,与DeltaManager不同的是,某节点会话的改变只会同步给集群中的另一个而非所有节点。
PS:看了本次是不是tomcat的配置这么多门道,其实很多时候很多人都是安于目前的项目,意味的去抱怨,而不想通过技术的手段改变现有沉闷的技术。其实很尴尬啊。
百度未收录
>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:上一篇:已是最新文章