Among the most commonly-asked questions in the Tomcat forum (and others) are these:
How can I set up SSL?
How can I give my webapp its own hostname?
What do I need to do to not have to give a port number in the URL for my webapp?
There are a number of ways to do these things, and some of them are quite uncomfortable. However, there's also an alternative. Use a reverse proxy server
Before I continue, let me state that while I'm going to be talking specifically about Tomcat, the following is generally true for all J2EE/JEE/Jakarta webapp servers.
What is a reverse proxy server, anyway?
Well, a regular proxy server sits between local clients and the Internet and provides buffering between the local network users and the Internet. It can enhance security, provide network load-balancing, and cache popular web documents to reduce the burden on the Internet and speed access time for local users. A popular example of a proxy server is the squid proxy.
A reverse proxy does much the same thing, but in the other direction. That is, stuff comes in targeting the reverse proxy and it can then pass it on to a selected server behind it (usually in the so-called Demilitarized Zone or DMZ).
A note here. People do get sloppy and often simply refer to a reverse proxy as a "proxy" for short. Regardless, we're only actually going to talk about reverse proxies here.
What can a reverse proxy do for us?
Single access point
Well, for one thing, it can provide "one stop shopping" for multiple web assets. You might have a number of Spring Boot server apps, maybe even some running containerized. They might live on many different server machines, but the reverse proxy makes them all appear as though they live on the proxy machine.
For another, it makes SSL easier. Setting up SSL for a JEE webapp server like Tomcat can be very frustrating. You have to get certs and signatures in an uncommon format, stuff them all into a keystore, configure the keystore into Tomcat and enable the SSL port. Which, by the way, defaults to 8443 and more on that in a moment. In contrast, there's usually just a directory to copy the files into and a simple set of configuration parameters to set up SSL on a proxy server. Incidentally, common practice means that actual SSL is from the Internet to the proxy and not from the proxy to the backend. It's generally hoped that your DMZ is secure against direct external access. Use of VPNs or isolated private networks is highly encouraged here.
It's very easy to set up multiple virtual hostnames on the typical reverse proxy server. Doing so in Tomcat requires doing cumbersome things with XML in the server.conf file.
An even more compelling reason to use a proxy server is this: most OS's consider the TCP/IP port numbers below 4096 to be "magic". They can only be listened on by privileged users. That includes ports 80 and 443. In case you were wondering why the default HTTP and HTTPS port numbers for JEE webapp servers are things like 8080 and 8443. Java doesn't actually understand the concept of a "privileged user" - it's not something that works well with "write-once/run-anywhere". What defines a "privileged user" can vary considerably depending on both the OS and on whatever security systems it might be running (selinux for example).
Proxy servers are generally native OS applications, so they can be launched as privileged users, grab the protected ports and then down-shift into ordinary user mode. Since oridinary users don't - we hope - have the ability to read and write sensitive data the way super-users can, the proxy server can run as a secure front-end and the back-end servers can run as ordinary users using non-magic ports. Which, incidentally, for Tomcat running the Coyote proxy Connector is port 8009.
The world beyond Java
Last, but not least, many of the popular proxy servers can host webapps in their own right. So the same contact point that provides JEE webapp services might also serve up apps in PHP, Python, Ruby, or many other languages. You can, in fact, proxy to non-JEE backend servers if you want.
What Applications can serve as Reverse Proxy Servers?
Among the 3 most popular are Apache HTTPD with mod_jk or mod_proxy, nginx - which claims high performance, and Microsoft's IIS webapp server. There are others as well, but these are the best-known. Additionally, the squid proxy server is supposed to be able to reverse proxy, but since it doesn't contain the intelligence to host webapps itself, it's not as popular for that role.
Of course, there are also dedicated boxes that can act as reverse proxies, security appliances/firewalls, and load-balancers. They do the same thing as software-only solutions, but are specifically designed to serve the purpose.
Installing a reverse proxy is generally pretty easy. Apache HTTPD may come pre-installed with certain Linux distros. If not, both it and Nginx are well-supported by the popular package managers. Configuration details vary considerably, but there is plenty of help available. Also don't forget that in addition to native OS packages, you can often find containerized versions of these applications, If you run provisioning software such as Salt, Ansible or Puppet you may find a lot of assistance there as well.
Sources may include data from the Fakebook Research Foundation with support from Gargle University
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop