Understand Tomcat service and build

1, Tomcat overview

Since November 2017, Java accounted for 13% of the programming language ranking, ranking first in the list, Tomcat has also become the first choice for Java developers. Its open source, less system resources, cross platform and other characteristics are deeply loved. This chapter mainly studies how to deploy Tomcat service and realize the configuration of multiple virtual hosts according to the production environment. The final focus is on the pressure test, how to optimize Tomcat service according to the pressure test results and how to deal with common memory overflow.
Tomcat server is a free open source Web application server. It is a lightweight application server. It is widely used in small and medium-sized systems and when there are not many concurrent access users. It is the first choice for developing and debugging JSP programs. Generally speaking, Tomcat, like Apache or Nginx Web servers, has the function of processing HTML pages. However, because its ability to process static html is far less than Apache or Nginx, Tomcat usually runs on the back end as a Servlet and JSP container.

Official website address: https://tomcat.apache.org/

2, Introduction to Tomcat configuration file and its core components

2.1. Configuration file

Introduction to files in the installation directory

Directory namefunction
binSave the script files for starting and closing Tomcat. catalina.sh, startup.sh and shutdown.sh are commonly used
confVarious configuration files of Tomcat server are stored, including server.xml, context.xml, Tomcat users.xml and web.xml.
libThe jar package for storing the Tomcat server is generally unchanged. Unless a third-party service, such as redis, is connected, the corresponding jar package needs to be added
logsStore Tomcat logs
tempStore the files generated by Tomcat runtime
webappsDirectory where project resources are stored
workTomcat working directory is generally used when clearing Tomcat cache

conf subdirectory

file nameexplain
server.xmlMaster profile
web.xmlEach webapp can only be accessed after "deployment". Its deployment mode is usually defined by web.xml and stored in the WEB-INF / directory. This file provides default deployment related configuration for all webapps. Each web application can also use a special configuration file to overwrite the global file
context.xmlIt is used to define the Context configuration that all web applications need to load. This file provides the default configuration for all webapps. Each web application can also use its own special configuration. It is usually defined by the special configuration file context.xml, which is stored in the WEB-INF / directory, overwriting the global file
tomcat-users.xmlUser authentication account and password file
catalina.policyUsed to set the security policy for tomcat when using the security option to start omcat
catalina.propertiesThe configuration of Tomcat environment variables is used to set classloader paths and some parameters related to JVM tuning
logging.propertiesTomcat log system related configuration, you can modify the log level and log path
Note that configuration files are case sensitive

2.2 core components

Tomcat consists of a series of components, including three core components:

  • Web container: complete the functions of the web server.
  • Servlet container: named catalina, used to process servlet code.
  • JSP container: used to translate JSP dynamic web pages into Servlet code

Multi instance: multi instance is to open multiple different service ports on one server and run multiple service processes at the same time. These service processes listen to different service ports through different socket s to provide services.

Engine: Generally speaking, engine is the supporting part of a program or a set of system. Common program engines include game engine, search engine, anti-virus engine, etc

serverServer, the process instance running Tomcat. There can be multiple service s in a server, but usually only one
serviceService is used to organize the correspondence between Engine and Connector. There is only one Engine in a service
connectorConnector, which is responsible for the HTTP, HTTPS, AJP and other protocol connections of the client. A connector belongs to only one Engine
EngineThe Engine is used to respond to and process user requests. Multiple connectors can be bound to an Engine
HostThat is, virtual hosts can realize multiple virtual hosts, for example, using different host headers to distinguish
ContextConfigure the mapping relationship between specific URL path mapping and directory according to the application context: url = > directory
<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">
   <Service name="Catalina">
     <Connector port="8080" protocol="HTTP/1.1"connectionTimeout="20000"
               redirectPort="8443" />
       <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
          <Engine name="Catalina" defaultHost="localhost">
             <Host name="localhost"  appBase="webapps"unpackWARs="true" autoDeploy="true">
           <Context >
                <Context />

tomcat processing request process

  • Tomcat starts a Server process. You can start multiple servers, that is, multiple instances of tomcat, but generally only one Server is started
  • Create a Service to provide services. You can create multiple services, but generally only one
  • In each Service, is the associated configuration of the Engine and its Connector
  • You can provide multiple connectors for this Service. These connectors use different protocols and bind different ports. Their role is to process different connection requests or responses from clients
  • The Engine is also defined inside the Service. The Engine is the real entry to process requests. Multiple virtual hosts are defined inside
  • The Engine analyzes the request header and sends the request to the corresponding virtual host
  • If there is no match, the data is sent to the defaultHost default virtual host on the Engine
  • The default virtual host on the Engine can be modified
  • Host defines the virtual host. The virtual host has a name, which is matched by the name
  • Context defines the application's individual path mapping and configuration

3, Tomcat service deployment

3.1. Close the firewall

[root@localhost ~]# systemctl stop firewalld.service
[root@localhost ~]# setenforce 0

3.2. Install JDK package

[root@localhost ~]#rpm -ivh jdk-8u201-linux-x64.rpm

Will install Tomcat Required software package to/opt Directory
Switch to/opt Remove and install JDK
cd /opt
rpm -ivh jdk-8u201-linux-x64.rpm

3.3. Setting JDK environment variables

1. Modify profile
vim /etc/profile
export JAVA_HOME=/usr/java/jdk1.8.0_201-amd64
export CLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/dt.jar
export PATH=$JAVA_HOME/bin:$PATH
2. Refresh profile
[root@localhost jdk1.8.0_201-amd64]#source /etc/profile

3.4. Installing tomcat

1. #Switch to / opt and unzip the tomcat package
cd /opt
tar -zxf apache-tomcat-9.0.16.tar.gz 
2. #Copy the extracted package to / usr/local / and rename it
cp -r apache-tomcat-9.0.16 /usr/local/tomcat

3. #Switch to the copied directory and start tomcat
cd /usr/local/tomcat/
4. #See if it starts successfully
ss -natp |grep 8080
5. #Test whether you can log in successfully on the web page

3.5. Add tomcat to the service

1. #Shut down the service first
2. #Add user set primary group
useradd -s /sbin/nologin tomcat
chown tomcat:tomcat tomcat/ -R
3. #New service file
vim /etc/systemd/system/tomcat.service
#After=syslog.target network.target remote-fs.target nss-lookup.target
After=syslog.target network.target
4. #Reload the service and start it to see if it starts successfully
systemctl daemon-reload
systemctl start tomcat
ss -ntap |grep 8080

4, Virtual host configuration

Sometimes the company may have multiple projects to run, so it is certainly impossible to run multiple Tomcat services on one server, which will consume too many system resources. At this time, the Tomcat virtual host needs to be used. For example, two new domain names www.why.com and www.accp.com hope to access different project contents through these two domain names.

[root@localhost webapps]#mkdir why  accp
[root@localhost webapps]#echo "this is kgc web !" > why/index.jsp
[root@localhost webapps]#echo "this is accp web !" > accp/index.jsp
[root@localhost webapps]#cat accp/index.jsp kgc/index.jsp 
this is accp web ls
this is why web ls

#Detailed explanation of configuration file
[root@localhost ~]# vim /usr/local/tomcat/conf/server.xml 
<Host name="www.why.com" appBase="/usr/local/tomcat/webapps"
            unpackWARs="true" autoDeploy="true" xmlValidation="false"
                <Context docBase="/usr/local/tomcat/webapps/kgc"
                path="" reloadable="true" />

      <Host name="www.accp.com" appBase="/usr/local/tomcat/webapps"
            unpackWARs="true" autoDeploy="true" xmlValidation="false"
                <Context docBase="/usr/local/tomcat/webapps/accp"
                path="" reloadable="true" />
[root@localhost ~]#systemctl restart tomcat

##change hosts file##  C:\Windows\System32\drivers\etc change the hosts file	www.why.com	www.accp.com


Tags: Linux bash

Posted on Mon, 22 Nov 2021 04:37:44 -0500 by moboter