Dear Mr. Schultz:
Delighted to hear from you, and delighted that you weighed in on this.
You've already earned my undying respect and gratitude. This also allows
us to drop one more cert that we have to pay for, and I think it could
lead to an easy way to drop yet another.
On 4/9/20 3:31 PM, Christopher Schultz wrote:
. . .
First of all, definitely use mod_proxy and definitely use
mod_proxy_http (and not mod_proxy_ajp).
It seemed the more straightforward of the two options. And it was
already there.
0. DO NOT TRY TO USE YOUR PROXY TO RE-WRITE URL-SPACES
And you still don't talk about Fight Club . . . ;P
If you have an application hosted on Tomcat in /foo then map it to
/foo on the proxy.
Done. That was also the advice I got from Mr. Eggers, and with multiple
contexts, I saw no reason to copy that particular mistake that somewhat
untrustworthy tutorial page.
1. Configure your Tomcat connector
I left it "stock"; given that I'm going to be removing the extra
security group that temporarily gave me direct access to the Tomcat
port, I saw no reason to go with a nonstandard port number.
2. Configure mod_proxy to act as a proxy
ProxyRequests Off # this is to disable forward-proxying (!!)
Done, but that's the default anyway.
ProxyPass /context1/ http://localhost:1234/context1/
ProxyPassReverse /context1/ http://localhost:1234/context1/
3. Celebrate
Not much time for that: I'm still in the process of reconstructing a WAR
file for one of the contexts. I had to reconstruct an Eclipse project in
order to do so. And I'm not much more knowledgable about Eclipse than I
am about httpd.
4. If localhost, use http; otherwise, use https. This requires a TLS
cert, which may be irritating to accomplish with an "internal" host.
Note that httpd isn't terribly picky about the signature on the TLS
certificate of the origin server (Tomcat), so you can self-sign if
you'd like.
It's localhost.
5. Without additional configuration on the Tomcat side, you'll find
that your access logs tell you that all visitors have the same IP
address (surprise! it's your reverse-proxy!). Have a look at the
RemoteIPValve[1] to get that all fixed up.
Not something we pay a lot of attention to.
6. If you have your static content files on the web server, you may be
able to improve performance a bit by NOT proxying requests to the
static content.
Not enough static content to bother with.
7. Adding more origin servers requires a slightly different
configuration.
Not even remotely enough traffic to warrant a load balancer. We have
another product that's running behind a load balancer, in an Elastic
Beanstalk stack; outside of torture-testing and some occasional early
bugs, we haven't actually seen it spawn off a second node. Then again,
that product is very new.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
