Use Docker to quickly install tomcat on the cloud server and deploy the SSM project

Preface

SpringBoot is embedded with tomcat, and the service can be started quickly with one command. Recently, I learned SSM honestly in class. The SSM project is deployed and online, and it needs to be packaged as a war package and placed on the tomcat of the server. Of course the best way to install and configure tomcat is to use docker. It is very convenient to download, install and uninstall. One day tomcat is broken, delete it if you say it is deleted, and the configuration can still be retained.

Quick start Docker: https://blog.csdn.net/qq_43290318/article/details/107743188

Install and run tomcat

1. Pull the latest image

docker pull tomcat

2. Run a tomcat container for testing

# 随便运行一个tomcat容器
docker run --name tomcat01 -p 8080:8080 -d tomcat

# 进入容器内部
docker exec -it tomcat01 /bin/bash

Why run a tomcat container (which can be deleted later)? Because we need to know what the directory structure in the tomcat container is, so that the next time the container is officially run, the key directory in the container will be mounted to the host. Then modify the configuration and copy the project war package in the future, enter the container out of order, and operate directly in the directory of the host machine, and it will take effect without restarting the container! ! !

 Enter the container tomcat01 and see the directory structure as above. Here we only need to focus on 4 directories:

1. conf: configuration related, we need to modify the configuration file server.xml in this directory when deploying the project

2. logs: Store the log files generated by the project

3. webapps.dist: default interface, etc.

4. webapps: Note that after starting the container, you will report 404 when you visit ip:8080 , and you will not see the Tomcat logo and mascot, the yellow little male cat. The reason is that in tomcat9, although the default port 8080 points to the webapps directory, webapps is empty. Its actual resources are placed in the webapps.dist directory. So we only need to copy all the content of webapps.dist to webapps, and visit ip:8080 to see the default page. This is explained in detail below. 

3. Copy all the contents of /usr/local/tomcat in the container to the host

We have also seen in the above that our deployment project needs to pay attention to visit the 4 directories in 2. For convenience, we plan to directly mount  /usr/local/tomcat to the host's /data/tomcat (optional). The mount is based on the host machine! ! ! In other words, if the host's /data/tomcat is empty, then mount /usr/local/tomcat to the host's /data/tomcat, then /usr/local/tomcat inside the container will be all empty, because it Taking the host as a benchmark, how the corresponding directory of the host is obtained, it is how it is obtained.

So before officially running the tomcat container for mounting, we need to copy all the contents under /usr/local/tomcat in the test container to /data/tomcat.

docker cp tomcat01:/usr/local/tomcat /data/tomcat

4. Officially run the tomcat container

# 停止测试容器
docker stop tomcat01
# 删除测试容器
docker rm tomcat01

# 正式运行我们的tomcat容器
docker run --privileged=true -v /data/tomcat:/usr/local/tomcat -p 8080:8080 -p 8688:8688 -p 80:80 --name tomcat01 -d tomcat

I will not introduce the command parameters of docker run much. Look at the blog in the preface. Why do we need to perform multiple port mapping? Because when deploying multiple projects under one tomcat, there are two options:

1. Use different ports to distinguish multiple projects

2. Multiple projects share port 80, but are distinguished by domain name

So in order to prevent us from deploying multiple projects later, I have mapped port 80 in addition to the default port 8080. Of course, you can map some other ports in case you need to use them later. If you want to use it later, but the corresponding port mapping is not performed when the container is running, what should you do? Delete this container directly, and run a new container through docker run again. Since we mounted the directory before, the project resources and configuration of the deleted container will not be lost! ! !

Configure tomcat

1. Configure tomcat default page

The default port of tomcat is 8080, and you can access the default page by visiting port 8080. After starting the container, visit ip:8080 and it will report 404. I did not see the Tomcat logo and mascot, the yellow little male cat. The reason is that in tomcat9, although the default port 8080 points to the webapps directory, webapps is empty. Its actual resources are placed in the webapps.dist directory. So we only need to copy all the content of webapps.dist to webapps, and visit ip:8080 to see the default page.

Since we mounted the directory when we started the container earlier, we only need to operate under /data/tomcat on the host, and it will take effect without restarting the container after the operation is completed. Refresh ip:8080, you can see the default page.

# 此时处于宿主机的 /data/tomcat 
cp -r webapps.dist/* webapps/

2. Configure Tomcat Web Management Interface

(1) The access url of the management page is: ip:8080/manager/html , but the management interface cannot be accessed remotely by default, and you need to turn off the relevant restrictions. Open webapps/manager/META-INF/context.xml and comment the following:

<Context antiResourceLocking="false" privileged="true" >
<!--
  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
         allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
-->
</Context>

(2) Configure the administrator user name and password. Open conf/tomcat-users.xml and modify the following configuration:

<tomcat-users>
<!--
    Comments
-->
   <role rolename="admin-gui"/>
   <role rolename="manager-gui"/>
   <user username="自定义的用户名" password="自定义的密码" roles="admin-gui,manager-gui"/>

</tomcat-users>

(3) Visit the management page

Deploy SSM project

1. Project configuration

The simplest way to deploy a project is to use the default port 8080 of tomcat, name the war package ROOT.war , and then put it directly under webapps, and replace the project code with the current default management interface. Then you can access your project by visiting port 8080. This method is simple, but it is too intrusive and is not recommended, because you may need to use the management page again in the future.

When deploying multiple projects under one tomcat, there are two options:

1. Use different ports to distinguish multiple projects

2. Multiple projects share port 80, but are distinguished by domain name

The same principle applies to Apache's virtual host. In the case of not purchasing a domain name, use different port numbers to distinguish. If you have already bought a domain name, if you still use different projects with different port numbers, when accessing different projects through "domain name: port number", the domain name is followed by a port number, which seems to be a violation.

So this time we use the second method, which is why I added a port 80 mapping when running the container earlier. Why use port 80 instead of other ports? I will not explain.

Open conf/server.xml  and add the following configuration between the <Server> tags:

<Service name="Catalina-项目名">
    <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
    <Connector port="8689" protocol="AJP/1.3" redirectPort="8443" />
    <Engine name="Catalina" defaultHost="域名">
        <Realm className="org.apache.catalina.realm.LockOutRealm">
            <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" />
        </Realm>
        <Host name="域名" appBase="webapps-项目名" unpackWARs="true" autoDeploy="true">
            <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs/项目名" prefix="access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b" />
        </Host>
    </Engine>
</Service>
  • The Catalina-project name in the root node   is one of our names. It seems to need to start with Catalina, as long as it is not repeated, you can add multiple configurations as above in the configuration file.
  • Connector HTTP/1.1: HTTP link configuration, our port is configured here, we configure it as: 80
  • Connector AJP/1.3: Used for forwarding configuration to other servers, the port configuration is: 8689 ; generally used for communication between apache and tomcat.
  • Service The port configuration in, if there are multiple different  Service  nodes, our ports can be configured as the same, as long as the domain names are different.
  • Engine-defaultHost: This is the place to configure the domain name. For the Service configured with the same port,   different domain names can be used to solve the redirection problem; but when both are configured with the  localhost same domain name, please use different ports.
  • Engine-Realm: This node does not need to be managed.
  • Engine-Host-name: Here we also configure the domain name that they have purchased the above configuration of the domain name and domain name is the same as can be.
  • Engine-Host-appBase: Here is the key point, we configure a folder for our project configuration; the default management interface folder is  webapps , here we configure it  webapps-项目名 to distinguish different projects.
  • Engine-Host-Valve: In this node, we mainly configure the directory where logs are generated, and other related configurations

2. The project is marked as a war package and pushed to the server

Different IDEs have different packaging methods, and Baidu is fine. Push the war package to the server, you can use xftp or winscp.

It is worth noting that before the war package is launched, because the server environment is different from the local environment, the corresponding configuration needs to be modified, such as: database related configuration, database driver package version, etc. I have stepped on these pits. . . .

3. Rename the war package to ROOT.war and put it under "webapps-project name"

When accessing the project through the domain name, ROOT.war will be automatically decompressed into the folder ROOT. If you access it and report a 500 error, or find that the war package cannot be automatically decompressed, you can try to decompress it yourself through the linux command. I have encountered this problem before.

https://blog.csdn.net/qq_43290318/article/details/104769757

 

Guess you like

Origin blog.csdn.net/qq_43290318/article/details/109792232