tomcat部署多个项目
1
配置说明
一个tomcat进程运行两个项目,启动多个端口提供服务,即修改server.xml 增加多个service配置选项
<Service name="Catalina1">
<Connector port="9001" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<Engine name="Catalina1" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps1"
unpackWARs="true" autoDeploy="true">
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
</Engine>
</Service>
配置文件
整体结构
<Server>
<Service>
<Connector />
<Connector />
<Engine>
<Host>
<Context /><!-- 现在常常使用自动部署,不推荐配置Context元素,Context小节有详细说明 -->
</Host>
</Engine>
</Service>
</Server>
元素分类
server.xml文件中的元素可以分为以下4类:
(1)顶层元素:
(2)连接器:
(3)容器:
容器的功能是处理Connector接收进来的请求,并产生相应的响应。Engine、Host和Context都是容器,但它们不是平行的关系,而是父子关系:Engine包含Host,Host包含Context。一个Engine组件可以处理Service中的所有请求,一个Host组件可以处理发向一个特定虚拟主机的所有请求,一个Context组件可以处理一个特定Web应用的所有请求。
(4)内嵌组件:可以内嵌到容器中的组件。实际上,Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat组件,其他组件都可以归为内嵌组件。
HOST
(1)Engine与Host
Host是Engine的子容器。Engine组件中可以内嵌1个或多个Host组件,每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个,且其中一个的name必须与Engine组件的defaultHost属性相匹配。
(2)Host的作用
Host虚拟主机的作用,是运行多个Web应用(一个Context代表一个Web应用),并负责安装、展开、启动和结束每个Web应用。
Host组件代表的虚拟主机,对应了服务器中一个网络名实体(如”www.test.com”,或IP地址”116.25.25.25”);为了使用户可以通过网络名连接Tomcat服务器,这个名字应该在DNS服务器上注册。
客户端通常使用主机名来标识它们希望连接的服务器;该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取出主机名,寻找名称匹配的主机。如果没有匹配,请求将发送至默认主机。因此默认主机不需要是在DNS服务器中注册的网络名,因为任何与所有Host名称不匹配的请求,都会路由至默认主机。
(3)Host的配置
在第一部分的例子中,Host的配置如下:
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
下面对其中配置的属性进行说明:
name属性指定虚拟主机的主机名,一个Engine中有且仅有一个Host组件的name属性与Engine组件的defaultHost属性相匹配;一般情况下,主机名需要是在DNS服务器中注册的网络名,但是Engine指定的defaultHost不需要,原因在前面已经说明。
unpackWARs指定了是否将代表Web应用的WAR文件解压;如果为true,通过解压后的文件结构运行该Web应用,如果为false,直接使用WAR文件运行Web应用。
Host的autoDeploy和appBase属性,与Host内Web应用的自动部署有关;此外,本例中没有出现的xmlBase和deployOnStartup属性,也与Web应用的自动部署有关
Context
(1)Context的作用
Context元素代表在特定虚拟主机上运行的一个Web应用。在后文中,提到Context、应用或Web应用,它们指代的都是Web应用。每个Web应用基于WAR文件,或WAR文件解压后对应的目录(这里称为应用目录)。
Context是Host的子容器,每个Host中可以定义任意多的Context元素。
在第一部分的例子中,可以看到server.xml配置文件中并没有出现Context元素的配置。这是因为,Tomcat开启了自动部署,Web应用没有在server.xml中配置静态部署,而是由Tomcat通过特定的规则自动部署。下面介绍一下Tomcat自动部署Web应用的机制。
(2)Web应用自动部署
Host的配置
要开启Web应用的自动部署,需要配置所在的虚拟主机;配置的方式就是前面提到的Host元素的deployOnStartup和autoDeploy属性。如果deployOnStartup和autoDeploy设置为true,则tomcat启动自动部署:当检测到新的Web应用或Web应用的更新时,会触发应用的部署(或重新部署)。二者的主要区别在于,deployOnStartup为true时,Tomcat在启动时检查Web应用,且检测到的所有Web应用视作新应用;autoDeploy为true时,Tomcat在运行时定期检查新的Web应用或Web应用的更新。除此之外,二者的处理相似。
通过配置deployOnStartup和autoDeploy可以开启虚拟主机自动部署Web应用;实际上,自动部署依赖于检查是否有新的或更改过的Web应用,而Host元素的appBase和xmlBase设置了检查Web应用更新的目录。
其中,appBase属性指定Web应用所在的目录,默认值是webapps,这是一个相对路径,代表Tomcat根目录下webapps文件夹。
xmlBase属性指定Web应用的XML配置文件所在的目录,默认值为conf/<engine_name>/<host_name>,例如第一部分的例子中,主机localhost的xmlBase的默认值是$TOMCAT_HOME/conf/Catalina/localhost。
检查Web应用更新
一个Web应用可能包括以下文件:XML配置文件,WAR包,以及一个应用目录(该目录包含Web应用的文件结构);其中XML配置文件位于xmlBase指定的目录,WAR包和应用目录位于appBase指定的目录。
Tomcat按照如下的顺序进行扫描,来检查应用更新:
A、扫描虚拟主机指定的xmlBase下的XML配置文件
B、扫描虚拟主机指定的appBase下的WAR文件
C、扫描虚拟主机指定的appBase下的应用目录
Context元素最重要的属性是docBase和path,此外reloadable属性也比较常用。
docBase指定了该Web应用使用的WAR包路径,或应用目录。需要注意的是,在自动部署场景下,docBase不在appBase目录中,才需要指定;如果docBase指定的WAR包或应用目录就在appBase中,则不需要指定,因为Tomcat会自动扫描appBase中的WAR包和应用目录,指定了反而会造成问题。
path指定了访问该Web应用的上下文路径,当请求到来时,Tomcat根据Web应用的 path属性与URI的匹配程度来选择Web应用处理相应请求。例如,Web应用app1的path属性是”/app1”,Web应用app2的path属性是”/app2”,那么请求/app1/index.html会交由app1来处理;而请求/app2/index.html会交由app2来处理。如果一个Context元素的path属性为””,那么这个Context是虚拟主机的默认Web应用;当请求的uri与所有的path都不匹配时,使用该默认Web应用来处理。
但是,需要注意的是,在自动部署场景下,不能指定path属性,path属性由配置文件的文件名、WAR文件的文件名或应用目录的名称自动推导出来。如扫描Web应用时,发现了xmlBase目录下的app1.xml,或appBase目录下的app1.WAR或app1应用目录,则该Web应用的path属性是”app1”。如果名称不是app1而是ROOT,则该Web应用是虚拟主机默认的Web应用,此时path属性推导为””。
reloadable属性指示tomcat是否在运行时监控在WEB-INF/classes和WEB-INF/lib目录下class文件的改动。如果值为true,那么当class文件改动时,会触发Web应用的重新加载。在开发环境下,reloadable设置为true便于调试;但是在生产环境中设置为true会给服务器带来性能压力,因此reloadable参数的默认值为false
<Context docBase="D:\Program Files\app1.war" reloadable="true"/>
(3)server.xml中静态部署Web应用
除了自动部署,我们也可以在server.xml中通过
server.xml中使用Context元素配置Web应用,Context元素应该位于Host元素中。举例如下:
<Context path="/" docBase="D:\Program Files \app1.war" reloadable="true"/>
docBase:静态部署时,docBase可以在appBase目录下,也可以不在;本例中,docBase不在appBase目录下。
path:静态部署时,可以显式指定path属性,但是仍然受到了严格的限制:只有当自动部署完全关闭(deployOnStartup和autoDeploy都为false)或docBase不在appBase中时,才可以设置path属性。在本例中,docBase不在appBase中,因此path属性可以设置。
reloadable属性的用法与自动部署时相同
如何确定请求由谁处理?
当请求被发送到Tomcat所在的主机时,如何确定最终哪个Web应用来处理该请求呢?
(1)根据协议和端口号选定Service和Engine
Service中的Connector组件可以接收特定端口的请求,因此,当Tomcat启动时,Service组件就会监听特定的端口。在第一部分的例子中,Catalina这个Service监听了8080端口(基于HTTP协议)和8009端口(基于AJP协议)。当请求进来时,Tomcat便可以根据协议和端口号选定处理请求的Service;Service一旦选定,Engine也就确定。
通过在Server中配置多个Service,可以实现通过不同的端口号来访问同一台机器上部署的不同应用。
(2)根据域名或IP地址选定Host
Service确定后,Tomcat在Service中寻找名称与域名/IP地址匹配的Host处理该请求。如果没有找到,则使用Engine中指定的defaultHost来处理该请求。在第一部分的例子中,由于只有一个Host(name属性为localhost),因此该Service/Engine的所有请求都交给该Host处理。
(3)根据URI选定Context/Web应用
这一点在Context一节有详细的说明:Tomcat根据应用的 path属性与URI的匹配程度来选择Web应用处理相应请求,这里不再赘述。
(4)举例
以请求http://localhost:8080/app1/index.html为例,首先通过协议和端口号(http和8080)选定Service;然后通过主机名(localhost)选定Host;然后通过uri(/app1/index.html)选定Web应用
如何配置多个服务
通过在Server中配置多个Service服务,可以实现通过不同的端口号来访问同一台机器上部署的不同Web应用。
在server.xml中配置多服务的方法非常简单,分为以下几步:
(1)复制
(2)修改端口号:根据需要监听的端口号修改
(3)修改Service和Engine的name属性
(4)修改Host的appBase属性(如webapps2)
(5)Web应用仍然使用自动部署
(6)将要部署的Web应用(WAR包或应用目录)拷贝到新的appBase下。