『互联网架构』软件架构-tomcat之环境部署(下)(22)

栏目: Java · 发布时间: 5年前

内容简介:tomcat生产环境得应用配置,这次的对各位老铁还是非常有用的。其实就是咱们生产环境实际要做的一些事情,有老铁联系我说,从之前说的docker还有现在很多部署基本都是跟运维关系很大,跟开发关系很少啊?其实老铁你误解我了,我的思路就是不管是在应用的环境,最后的部署希望的是各位老铁都能完全的熟悉。源码:https://github.com/limingios/netFuture/tree/master/tomcat-pro

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

源码:https://github.com/limingios/netFuture/tree/master/tomcat-pro

『互联网架构』软件架构-tomcat之环境部署(下)(22)

Tomcat启动和部署方式(一)

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

#####现状

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

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

    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。

『互联网架构』软件架构-tomcat之环境部署(下)(22)

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

vagrant up
su -
#密码 vagrant
vi /etc/resolv.conf
#nameserver 8.8.8.8

『互联网架构』软件架构-tomcat之环境部署(下)(22)

  • 安装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

『互联网架构』软件架构-tomcat之环境部署(下)(22)

『互联网架构』软件架构-tomcat之环境部署(下)(22)

  • 安装tomcat7

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

『互联网架构』软件架构-tomcat之环境部署(下)(22)

下载安装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

『互联网架构』软件架构-tomcat之环境部署(下)(22)

『互联网架构』软件架构-tomcat之环境部署(下)(22)

『互联网架构』软件架构-tomcat之环境部署(下)(22)

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

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

『互联网架构』软件架构-tomcat之环境部署(下)(22)

『互联网架构』软件架构-tomcat之环境部署(下)(22)

  1. 启动配置shell脚本

    >创建shll脚本

cd ~
cd services/tomcat-1/
vi tomcat.sh
chmod 777 tomcat.sh

『互联网架构』软件架构-tomcat之环境部署(下)(22)

脚本内容

#!/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之环境部署(下)(22)

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

./tomcat start
./tomcat stop

『互联网架构』软件架构-tomcat之环境部署(下)(22)

  • 上边的方式就实现了,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之环境部署(下)(22)

进入单个的tomcat-1中

cd services
cd tomcat-1
ll

『互联网架构』软件架构-tomcat之环境部署(下)(22)

创建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

『互联网架构』软件架构-tomcat之环境部署(下)(22)

运行测试

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之环境部署(下)(22)

『互联网架构』软件架构-tomcat之环境部署(下)(22)

最终tomcat-1目录。

1.app-conf 是配置文件

2.appwar 是项目连接的发布目录

3.current_deploy_dir 目前发布的目录

4.current_deploy.sh 指的是deploy.sh中 pom_a 发布的项目名称

5.war是上传的项目路径

6.webapps 里面是空的

『互联网架构』软件架构-tomcat之环境部署(下)(22)

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

1. Tomcat 执行文件与程序目录分离。(便于后续升级Tomcat或统一配置Tomcat)

2. 一键部署发布应用

3. 可快速回滚应用和配置

4. 自定义配置应用

Tomcat server.xml配置详解(二)

实际上其实老铁们配置最多的可能就是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 体系结构图

『互联网架构』软件架构-tomcat之环境部署(下)(22)

一个 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方式记录的值更多 ||

Tomcat 集群

Tomcat 会话管理器

* StandardManager

Tomcat6的默认会话管理器,用于非集群环境中对单个处于运行状态的Tomcat实例会话进行管理。当Tomcat关闭时,这些会话相关的数据会被写入磁盘上的一个名叫SESSION.ser的文件,并在Tomcat下次启动时读取此文件。

* PersistentManager

当一个会话长时间处于空闲状态时会被写入到swap会话对象,这对于内存资源比较吃紧的应用环境来说比较有用。

* DeltaManager

用于Tomcat集群的会话管理器,它通过将改变了会话数据同步给集群中的其它节点实现会话复制。这种实现会将所有会话的改变同步给集群中的每一个节点,也是在集群环境中用得最多的一种实现方式。

* BackupManager

用于Tomcat集群的会话管理器,与DeltaManager不同的是,某节点会话的改变只会同步给集群中的另一个而非所有节点。

PS:看了本次是不是tomcat的配置这么多门道,其实很多时候很多人都是安于目前的项目,意味的去抱怨,而不想通过技术的手段改变现有沉闷的技术。其实很尴尬啊。

『互联网架构』软件架构-tomcat之环境部署(下)(22)

百度未收录

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!

>>原文链接地址:上一篇:

已是最新文章


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Handbook of Data Structures and Applications

Handbook of Data Structures and Applications

Dinesh P. Mehta / Chapman and Hall/CRC / 2004-10-28 / USD 135.95

In the late sixties, Donald Knuth, winner of the 1974Turing Award, published his landmark book The Art of Computer Programming: Fundamental Algorithms. This book brought to- gether a body of kno......一起来看看 《Handbook of Data Structures and Applications》 这本书的介绍吧!

html转js在线工具
html转js在线工具

html转js在线工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具