nginx - What are the applicable scenarios for JAVA project WAR package deployment?

Question

When deploying projects, I always use folders to deploy projects. Recently, I tried to use WAR package project deployment and encountered the following problems:

• Specify the local path for the upload file location, but since it is independent of the project, you need to configure the project separately to access it

• When the company has a large number of projects (about 200 for one server, about 20 servers), each project is configured like this, and the operation and maintenance work is very heavy

• Only one css or JS file was adjusted during maintenance, but it had to be repackaged and released

Compared with the previous folder method, it is really troublesome. I would like to ask experienced students:

1. What application scenarios have you encountered using WAR packages?

2. How to solve the problem I encountered?

Answer 1

The following is my actual operation and maintenance experience:

1. The configuration should be independent of the project, so that the war package can be created only once and applied to different environments;

2. Use automated operation and maintenance tools such as SaltStack, Ansible or Jenkins to help you perform batch operations;

3. If you expect that static resources will change frequently, it is best to separate them from the Java project and deploy them to different sites, or use nginx for diversion;

4. It is recommended to deploy the program to decompress the war file (instead of letting Tomcat decompress it by itself), stop Tomcat, use ln -s to direct the ROOT directory to a new directory, and then start Tomcat, so that Tomcat will run more smoothly;

5. Don’t delete the old directory for now. If the deployment is wrong, use ln -s to switch the ROOT directory to the old one to achieve a quick rollback.

Answer 2

Practical experience:
The projects I have handled are all published in the form of directories on weblogic. Directory structure:

DOMAINS                   --域
└─domainA                 --域A
    └─apps                --应用
        └─app1            --应用1
            ├─deploy      --部署
            │  ├─src      --Java源代码（仅限项目实施开发的源代码，不包含应用库的源代码），服务器统一编译一次防止Java版本问题以及编码问题
            │  └─war      --标准war包结构
            ├─patch       --增量更新目录
            ├─runtime     --运行时目录，日志，用户文件之类的
            └─tmp         --临时目录
       

I wrote several shell scripts according to this standard structure to automate operation and maintenance tasks, such as starting, stopping, monitoring, updating, etc. It actually only took a few days and there was not much code, but now I never do it manually again. Over the operation and maintenance matters.

The basic process is: code development submission-->SVN export incremental update package-->upload to server-->execute on server

If you change an html page, you have to repackage it. What if you enter the wrong file? Static ones can be published separately, so if I just change a JAVA, I have to repackage it and deserve it?

No container actually publishes and serves applications in a war package. They are all decompressed to a temporary location. The war package is in a compressed format. You must let any container read the resources in the compressed file every time it serves a request. There will be performance issues (at least for JSP).

This is my personal solution for some small projects. For large projects, you may need a full-process tool chain, which is continuous integration or something.