How to deploy .war files in Plesk Onyx 17.8 despite no longer supported TomCat?

Question

Up to and including version 17.5 Plesk Onyx came with a Tomcat installation, which is no longer supported from version 17.8. Thus no .war files can be deployed and executed anym

Answer 1

1. Idea

Use a Tomcat Docker container instead and deploy your .war file in a mapped Docker volume.

2. Solution

• Install the Plesk extension "Docker" from the extension catalog (Home -> Server Management -> Extensions -> search textbox).
• Open the Docker extension (Home -> Server Management -> Docker).
• Install the Tomcat container (search textbox -> 'run' drop down box)
• Adapt the Tomcat container configuration
  • activate "Automatic start after system reboot"
  • deactivate "Automatic port mapping"
  • for the "Manual mapping" choose a 8080 to external 8080 port configuration
• Add two "Volume mapping"s
  • /usr/local/tomcat/webapps/ to /usr/local/tomcat/webapps/
  • /usr/local/tomcat/logs/ to /usr/local/tomcat/logs/

3. Explanation

The first volume mapping provides a directory on the host system (your server) which is synchronized with the webapps directory within the Tomcat container. Copying your .war file into it will deploy it at the Tomcat container. The second volume mapping provides the Tomcat container internal log files to your host system.

Answer 2

The downside of using Plesk's "Docker proxy rules" is multiple domains can't share one docker.

In Plesk 17.8 here's what worked best for me...

Using ssh, install Tomcat on port 8080.

Delete all demo apps from Tomcat webapp folder

Copy my app war files to Tomcat webapp folder

Log in to Plesk

For each domain with a Tomcat webapp, click "Apache & nginx Settings" for that domain, scroll down, under "Additional nginx directives" Add

location /app1 {
    proxy_pass http://127.0.0.1:8080;
}

Every webapp name has be unique. Works with Let's Encrypt so

• https://example1.com/app1 shows http://127.0.0.1:8080/app1

• https://example2.com/app2 shows http://127.0.0.1:8080/app2

Answer 3

We had the same issue: After a successful deploy on Plesk Onyx 17.5 our hoster announced a forced update to 17.8 justified by GDPR requirements by Plesk. Knowing that this would break our production environment, we set up a new machine to test our possibilities. I was very happy to find your idea here @ThirstForKnowledge - which sounds great to my ears - but Docker was not an option for us as our virtualized hosting environment was not possible to run an Docker host. So we came up with another idea, which may be helpful for others with the same difficulties to face with.

1. Idea

Install Tomcat as standalone application and deploy .war with Tomcat Manager shipped by default. Create a cron script checking for updates of the Tomcat .zip archive and install JRE by using package manager, which auto-updates by Plesks initiation regularly.

2. Solution

• Install JRE by using package manager
• Install Tomcat by using the .zip from their mirrors
• Harden it against attacks by following one of various online tutorials
• Make it a service and enable it for start at bootup
• Configure Tomcat manager application (localhost only, look three steps ahead)
• Block Tomcats default port by Plesk firewall
• Set up Plesks subscription with encryption and automatic redirection to HTTPS
• Use Plesks ability to change Apache configuration and set up reverse proxy to Tomcats port
• Check domain for a running Tomcat server and valid encryption
• Log in to Tomcat manager
• Undeploy all demo applications and deploy your .war
• Deactivate manager access to prevent attacks (or configure Fail2Ban appropriately) (may not be needed if you follow all next steps but safe is safe)
• Change reverse proxy configuration to point / to your application
• Create a script to update Tomcat and cron it by Plesk

3. Explanation

Users connections will be guided to your Tomcat/Java application but encryption and all the other hosting stuff can be done by Plesk interface. Updates will be driven by Plesks package updater for Java and by the cron script for Tomcat. Deploying and undeploying is be made really easy by Tomcat manager which is only shortly exposed to the WWW when needed and credentials are securely transmitted. Tomcat needed to be manually installed because our package manager only had Tomcat 7 in his repositories, this maybe defers to your installation so check it before!

4. Open questions

Does anyone have more experience or finds security weaknesses or leaks with this approach? Does anyone have a nicer idea to fulfill this taks? Do we miss something? I'm happy about all considerations :)