006-tomcat 多实例安装、appBase和docBase、Context说明

时间:2024-02-18 15:38:55

一、多实例部署

  主要是为了充分利用服务器资源,并且可以交叉部署应用。主要做法可以有使用docker部署,多实例部署。

  多实例多应用:多个 Tomcat 部署多个不同的项目。这种模式在服务器资源有限,或者对服务器要求并不是很高的情况下,可以实现多个不同项目部署在同一台服务器上的需求,来实现资源使用的最大化

  有一种做法就是简单的复制出一个新的 Tomcat 目录后改一下端口,这种方法应用起来也是可以的,但是会有几个问题:

    1 当你对集群中Tomcat 版本升级 如何做?

    2 当你需要针对每一个不同的 Web 服务分配不用的内存时,你需要怎么做

1.1、知识点

  官方建议配置多实例方法

    

  上图中的 CATALINA_HOME 指Tomcat安装路径,CATALINA_BASE 指实例所在位置。CATALINA_HOME 路径下只需要包含 bin 和 lib 目录,而 CATALINA_BASE 只存放 conf、webapps、logs 等这些文件,这样部署的好处在于升级方便,配置及安装文件间互不影响,在不影响 Tomcat 实例的前提下,替换掉 CATALINA_HOME 中的安装文件。

1.2、脚本说明

  

  env-conf.sh:基础环境,

  initup.sh:构建并启动多实例

  stop.sh:停止多实例

  destroy.sh:停止并销毁

  index_template.html 生成一个静态页,测试使用

  server_template.xml tomcat 实例配置

  tomcat_control_template.sh 单个实例控制器

使用:env-conf.sh配置,使用initup.sh初始化,后续使用 stop.sh 停止所有,destroy.sh停止并销毁所有

控制单个机器,进入catalina_base/bin 使用脚本:control.sh start ; control.sh stop等控制

1.3、思路说明

主要是initup.sh说明

1、按照条件创建目录

mkdir -p /export/Instances/tomcat_instance1
mkdir -p /export/Instances/tomcat_instance2
mkdir -p /export/Instances/tomcat_instance3

2、从原始tomcat目录拷贝实例必须目录

{conf,logs,temp,work}

3、使用server_template.xml针对多实例配置

主要实例线程优化、目录确定

4、tomcat控制脚本编写

参看地址:https://github.com/bjlhx15/shell.git   https://github.com/bjlhx15/shell/tree/master/cmd/centos/multi-tomcat8

1.4、注意点

1.4.1、启动tomcat时,一直卡在Deploying web application directory这块的解决方案

原因:linux或者部分unix系统提供随机数设备是/dev/random 和/dev/urandom ,两个有区别,urandom安全性没有random高,但random需要时间间隔生成随机数。jdk默认调用random。

解决方案:可以有两种方式来解决:

方案一、catalina.sh 中加入这么一行:-Djava.security.egd=file:/dev/./urandom

export JAVA_OPTS="-Xms1024m -Xmx1024m \
 -Djava.security.egd=file:/dev/./urandom -Dfile.encoding=UTF-8 -Des.set.netty.runtime.available.processors=false"

方案二、在JVM 环境中解决

打开 $JAVA_PATH/jre/lib/security/java.security 这个文件(在你安装jdk的目录下)

securerandom.source=file:/dev/random
将其替换为:
securerandom.source=file:/dev/./urandom

详细说明

  发生这种情况的根本原因是 SecureRandom 这个 jre 的工具类的问题。那为什么 SecureRandom generateSeed 这么慢呢,这是因为tomcat7、tomcat8都是用org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom 类产生安全随机类 SecureRandom 的实例作为会话 ID。

  Tomcat 使用 SHA1PRNG 算法是基于 SHA-1 算法实现且保密性较强的伪随机数生成器。而在 SHA1PRNG 算法中,有一个种子产生器是根据配置来执行各种操作的。

  linux中的随机数可以从两个特殊的文件中产生,一个是 /dev/urandom,另外一个是 /dev/random。 他们产生的随机数的原理是利用当前系统的熵池来计算出固定一定数量的随机比特,然后再将这些比特作为字节流返回。这里的熵池就是当前系统的环境噪音,熵指的是一个系统的混乱程度,系统跟噪音可以通过很多参数来评估,如内存的使用,文件的使用量,不同类型的进程的数量等等。如果当前的系统的环境噪音变化程度并不是很剧烈、反差不大,或者当前环境的噪音很小,比如刚开机的时候。而刚开机的时候需要大量的随机比特,这个时候产生随机数的随机效果就不是很理想了。

  接下来解释一下 /dev/urandom  和  /dev/random  这两种不同的文件的区别, /dev/random 在不能产生新的随机数的情况下会阻塞程序,程序挂起便没法继续执行,直到熵池产生新的随机字节后才能返回,程序再接着执行,这就是  /dev/random 比 /dev/urandom 产生大量随机数的速度要慢的原因,也是为什么使用这个文件生成随机数时,tomcat启动的速度被拖慢的原因。而 /dev/urandom 这种方式在不能产生新的随机数时不会阻塞程序,当然了,这样的话生成随机数的效果没有  /dev/random 这种方式好,这对于加解密这样的应用来说并不是一个很好的选择。

  SecureRandom generateSeed  使用 /dev/random 生成种子。但是 /dev/random 是一个阻塞数字生成器,如果它没有足够的随机数据提供,它就一直等,这迫使 JVM 等待(程序挂起/tomcat启动拖慢)。键盘和鼠标输入以及磁盘活动可以产生所需的随机性或熵。但在一个服务器缺乏这样的活动,可能会出现问题。

1.4.2、TOMCAT的appBase和docBase

1、appBase

  server.xml文件host配置appBase,appBase这个目录下面的子目录将自动被部署为应用,且war文件将被自动解压缩并部署为应用,默认为tomcat下webapps目录,如果不想访问默认ROOT目录,修改这里,同理如果想访问配置目录下应用为默认应用,在此目录下新增ROOT目录文件夹。

  

2、docBase

  也可以继续在host下配置虚拟目录

<Context path="" docBase="D:\WebContent" sessionCookiePath="/" sessionCookieName="JSESSIONID" />

  docBase只是指向了你某个应用的目录,这个可以和appBase没有任何关系

  如果你把他们弄重复了,也就是2个指向了一个目录,也能运行,但应用下面的每个子目录,其实是被部署为单独的应用的,这就是两者区别与联系

1、appBase="webapps“,这是默认值,相对路径,代表:d:\tomcat\webapps 这样的路径,谓之根目录;根目录下的 ROOT 目录,代表默认的主目录。

  访问: http://localhost:8080 默认找 d:\tomcat\webapps\ROOT 下的文件(前提是没有docBase)

2、appBase=“d:\tomcat\webapps”,绝对目录,

  访问 http://localhost:8080 返回ROOT目录内容,

  访问http://localhost:8080/test返回d:\tomcat\webapps\test目录内容。

3、appBase=“webapps\abc”,相对目录,

  访问 http://localhost:8080 默认返回d:\tomcat\webapps\abc\ROOT的内容;

  访问http://localhost:8080/test返回d:\tomcat\webapps\abc\test的内容。

4、添加路径指向docBase后,appBase 作用变化:

  docBase=“test”, 访问的是 d:\tomcat\webapps\test, appBase为根目录;

  docBase="\test", 访问的是 d:\tomcat\webapps\test,appBase为根目录;

  docBase=“d:\test”, 访问的是 d:\test,appBase无效;

上述test目录必须存在,否则tomcat报错启动失败。

2、Context

a>配置方式

  其一、在server.xml的host中,Tomcat 尽管也允许直接在server.xml文件中配置<Context>元素,但不提倡采用这种方式。

  其二、在项目启动后,会更具配置的server.xml配置中Engine name和Host name 生成;对应二级目录

  Context中的path表示服务器端的项目名称。可以设置为""。 docBase表示访问的项目所在位置或项目所在父目录的位置。

b>Context查找顺序

  Tomcat 提供了多种配置<Context>元素的途径。当Tomcat 6.x加载一个 Web 应用时,会依次按照以下五种方式尝试查找 Web 应用的<Context>元素,直到找到为止: 

    1)到<CATALINA_HOME>/conf/context.xm文件中查找<Context>元素。这个文件中的<Context>元素的信息适用于所有Web应用。 

    2)到<CATALINA_HOME>/conf/[enginename]/[hostname]/context.xml.default 文件中查找<Context>元素。[enginename]表示<Engine>的 name 属性,[hostname]表示<Host>的name属性。在context.xml.default文件中的<Context>元素的信息适用于当前虚拟主机中的所有Web应用

      例如以下文件中的<Context>元素适用于名为Catalina的Engine下的localhost主机中的所有Web应用:

<CATALINA_HOME>/conf/Catalina/localhost/context.xml.default   

    3)到<CATALINA_HOME>/conf/[enginename]/[hostname]/[contextpath].xml文件中查找<Context>元素。[contextpath]表示单个Web应用的URL入口。在[contextpath].xml文件中的<Context>元素的信息只适用于单个 Web 应用,

      例如以下文件中的<Context>元素适用于名为“Catalina”的Engine下的localhost主机中的helloapp应用: 

<CATALINA_HOME>/conf/Catalina/localhost/helloapp.xml  

    4)到Web应用的META-INF/context.xml文件中查找<Context>元素。这个文件中的<Context>元素的信息适用于当前Web应用。

    5)到<CATALINA_HOME>/conf/server.xm文件中的<Host>元素中查找<Context>子元素。该<Context>元素的信息只适用于单个Web应用。 

  如果仅仅为单个 Web 应用配置<Context>元素,可以优先选择第三种或第四种方式。第三种方式要求在Tomcat的相关目录下增加一个包含<Context>元素的配置文件,而第四种方式则要求在 Web 应用的相关目录下增加一个包含<Context>元素的配置文件。

  对于这两种方式,Tomcat在运行时都会监测包含<Context>元素的配置文件是否被更新,如果被更新,Tomcat 会自动重新加载并启动 Web 应用,使对<Context>元素所做的修改生效。 

c>采用第四种方式配置<Context>元素。

  在 helloapp 目录下新建一个META-INF子目录,然后在其中创建一个context.xml文件,它的内容如下: 

<Context path="/helloapp" docBase="helloapp" reloadable="true"/>    

  以上<Context>元素的 docBase 属性表明,helloapp 应用的文件路径为<CATALINA_HOME>/webapps/helloapp;path属性表明访问helloapp应用的URL入口为“/helloapp”。 

d>采用第三种方式配置<Context>元素。

  假定 helloapp 应用的文件路径为C:\chapter03\helloapp,并且在<CATALINA_HOME>/webapps 目录下没有发布helloapp应用。

  在<CATALINA_HOME>/conf目录下先创建Catalina目录,接着在Catalina目录下再创建localhost目录,然后在<CATALINA_HOME>/conf/Catalina/localhost目录下创建helloapp.xml文件,它的内容如下:

<Context path="/helloapp" docBase="C:\ chapter03\helloapp" reloadable="true"/>    

  以上<Context>元素的 docBase 属性指定了 helloapp 应用的绝对路径,为C:\chapter03\helloapp;path属性表明访问helloapp应用的URL入口为“/helloapp”。

  由于helloapp.xml文件位于Catalina/localhost/子目录下,因此helloapp应用将运行在名为Catalina 的 Engine 组件的 localhost 虚拟主机中。访问 helloapp应用中的 login.htm和hello.jsp的URL分别为: 

http://localhost:8080/helloapp/login.htm    
http://localhost:8080/helloapp/hello.jsp    

  注意:如果没有为Web应用配置Tomcat的Context元素,那么Tomcat会为Web应用提供一个默认的Context组件。conf/Catalina/localhost 空目录

文件名:

  ROOT.xml ,表示访问时,无需加前缀;

  当为 项目名.xml,访问时,需要加前缀; 当为xxx.xml,访问时需要添加xxx前缀。

e>采用第五种方式配置<Context>元素

  在 server.xm文件中已经有一个名为 localhost 的<Host>元素,最常见的做法是在该<Host>元素中插入<Context>子元素,例如: 

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">    
  <Context path="/helloapp" docBase="helloapp" reloadable="true"/>    
</Host>