Я настроил очень простую конфигурацию кластера Apache + Glassfish.
Он отлично работает, если я создаю и использую прослушиватель, который использует http-listener-1 по умолчанию.
Однако, если я переключаюсь на безопасный прослушиватель, который использует http-listener-2, то соединение устанавливается, но затем оно сбрасывается, и пользователь получает ошибку 502 Bad Gateway, и у меня есть это сообщение в mod_jk.log
[Wed Dec 04 16:17:55.905 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (674): socket TCP_NODELAY set to On
[Wed Dec 04 16:17:55.905 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (711): socket SO_KEEPALIVE set to On
[Wed Dec 04 16:17:55.905 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (763): timeout 300 set for socket=16
[Wed Dec 04 16:17:55.905 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (798): trying to connect socket 16 to 10.0.10.4:28010
[Wed Dec 04 16:17:55.906 2019] [6957:139970911750336] [debug] jk_open_socket::jk_connect.c (824): socket 16 [10.0.30.4:39278 -> 10.0.10.4:28010] connected
other log entries in between....
[Wed Dec 04 16:17:55.907 2019] [6957:139970911750336] [debug] ajp_send_request::jk_ajp_common.c (1779): (worker1) request body to send 0 - request body to resend 0
[Wed Dec 04 16:17:55.909 2019] [6957:139970911750336] [debug] jk_shutdown_socket::jk_connect.c (931): About to shutdown socket 16 [10.0.30.4:39278 -> 10.0.10.4:28010]
[Wed Dec 04 16:17:55.909 2019] [6957:139970911750336] [debug] jk_is_input_event::jk_connect.c (1410): error event during poll on socket 16 [10.0.30.4:39278 -> 10.0.10.4:28010] (event=16)
[Wed Dec 04 16:17:55.909 2019] [6957:139970911750336] [debug] jk_shutdown_socket::jk_connect.c (1015): Shutdown socket 16 [10.0.30.4:39278 -> 10.0.10.4:28010] and read 0 lingering bytes in 0 sec.
[Wed Dec 04 16:17:55.909 2019] [6957:139970911750336] [info] ajp_connection_tcp_get_message::jk_ajp_common.c (1339): (worker1) can't receive the response header message from tomcat, tomcat (10.0.10.4:28010) has forced a connection close for socket 16
Конфигурация вполне стандартная, с той лишь разницей, что я использую личный сертификат, созданный моим внутренним центром сертификации. Сертификат был успешно добавлен в хранилище ключей, и если я обращаюсь к веб-приложению напрямую через порт 8181, оно работает (с некоторым предупреждением), и я могу проверить свой сертификат.
Вот часть https.conf
# Sample app
JkMount /sample loadbalancer
JkMount /sample/* loadbalancer
the worker.properties
worker.list=worker1,loadbalancer
# default properties for workers
worker.template.type=ajp13
worker.template.port=28010
worker.template.lbfactor=50
worker.template.connection_pool_timeout=600
worker.template.socket_keepalive=1
worker.template.socket_timeout=300
# properties for worker1
worker.worker1.reference=worker.template
worker.worker1.host=myhost.com
# properties for loadbalancer
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=worker1
Здесь разъем jk на Glassfish, как вы видите, он подключен к порту 28010, который я убедился, что он открыт.
Потратив некоторое время на изучение этой проблемы и чтение документов, я пришел к выводу, что JK не работает с TLS. Флаг безопасности применяется только к прослушивателю http.
Один из возможных вариантов работы, который я экспериментировал, - открыть туннель между HTTPD и экземплярами Glassfish. Это легко, но может иметь и обратную сторону. Самое главное, что SSH-соединение может оборваться. В этом случае можно также создать службу, перезапускающую туннель, но это было вне моих знаний (и времени).
Поскольку сеть, в которой находятся экземпляры, уже хорошо защищена, я закончил тем, что общался с JK через небезопасное соединение.