Я использую цифровую морскую каплю (Ubuntu 14.04.2 LTS (GNU / Linux 3.13.0-52-generic x86_64)) для размещения как jira, так и confluence. Они запускаются на одном ip, но на разных портах. Я хотел получить к ним доступ с помощью jira.team.domain.com и confluence.team.domain.com, поэтому я выбрал решение обратного прокси, используя apache 2.4.7.
Дела пошли очень хорошо, и они работали довольно быстро. Проблема в том, что через пару дней, в течение определенного времени, обратный прокси-сервер не работает, и я получаю сообщение «имя хоста не разрешено» в браузере. Я проверил, доступны ли приложения jira и confluence по адресам ip: port (порты 8081 и 8091). Через некоторое время, точно не знаю сколько, снова начинает работать.
Настройка следующая:
Jira server.xml содержит два коннектора:
<Connector port="8080"
maxThreads="150"
minSpareThreads="25"
connectionTimeout="20000"
enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"
proxyName="jira.team.domain.com"
proxyPort="80"/>
<Connector port="8081"
maxThreads="150"
minSpareThreads="25"
connectionTimeout="20000"
enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"/>
Confluence server.xml также имеет 2 соединителя:
<Connector port="8091" connectionTimeout="20000" redirectPort="8443"
maxThreads="200" minSpareThreads="10"
enableLookups="false" acceptCount="10" debug="0" URIEncoding="UTF-8"
protocol="org.apache.coyote.http11.Http11NioProtocol" />
<Connector port="8090" connectionTimeout="20000" redirectPort="8443"
maxThreads="200" minSpareThreads="10"
enableLookups="false" acceptCount="10" debug="0" URIEncoding="UTF-8"
protocol="org.apache.coyote.http11.Http11NioProtocol"
proxyName="confluence.team.domain.com" proxyPort="80" />
а файл /etc/apache2/sites-enabled/000-default.conf выглядит так:
<VirtualHost *:*>
ServerName localhost
# DocumentRoot /var/www/html
<Proxy *>
Require all granted
</Proxy>
# ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://jira.team.domain.com:8080/
ProxyPassReverse / http://jira.team.domain.com:8080/
</VirtualHost>
<VirtualHost *:*>
ServerName confluence.team.domain.com
DocumentRoot /var/www/html
<Proxy *>
Require all granted
</Proxy>
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://confluence.team.domain.com:8090/
ProxyPassReverse / http://confluence.team.domain.com:8090/
</VirtualHost>
Может ли кто-нибудь помочь мне решить эту проблему?
Вам даже не нужно работать с именем хоста в Apache conf в части для бэкэндов / прокси. Насколько вы правильно настроили прокси-часть "backends":
proxyName="jira.team.domain.com"
proxyPort="80"
... или в случае https ...
proxyName="jira.team.domain.com"
scheme="https"
proxyPort="443"
и аналогичная настройка для слияния (вариант для http, который вы уже сделали, как вы упомянули в вопросе). Таким образом, ProxyPass может легко использовать только IP:
<VirtualHost *:*>
ServerName jira.team.domain.com
...
ProxyPass / http://127.0.0.1:8080/
...
</VirtualHost>
<VirtualHost *:*>
ServerName confluence.team.domain.com
...
ProxyPass / http://127.0.0.1:8090/
...
</VirtualHost>
С этой настройкой вам нужна только запись DNS, указывающая на хост, чтобы предотвратить необходимость / etc / hosts записи на стороне клиента и правильные Название сервера в конфигурации Apache, чтобы правильно соответствовать виртуальному хосту (у вас есть только localhost для определения jira) и правильно proxyName в продуктах Atlassian для правильного ответа, который отправляется обратно пользователю ...
В случае этого параметра нет даже места для разрешения DNS на Apache в качестве уровня проксирования, поэтому я бы сказал, что вы обойдете проблему, о которой вы упомянули ;-).
Это звучит несколько похоже на проблемы, которые у меня были с обратным проксированием приложений Atlassian, для которых характерны периодические проблемы с Apache, в то время как экземпляры Tomcat кажутся вполне нормальными. «Имя хоста не разрешено» в браузере не согласуется с этим, так что, возможно, нет, но вы можете попробовать. Попробовать ничего не повредит.
Если у самого сервера Apache иногда возникают проблемы с выполнением DNS-запроса, это было бы довольно просто решить с помощью файла hosts. Убедитесь, что fqdn находится в /etc/hosts
назначен либо петле (127.0.0.1), либо любому интерфейсу, на котором вы слушаете JIRA / Confluence:
127.0.0.1 localhost jira.team.domain.com confluence.team.domain.com
Если вы назначите его для обратной петли, вам необходимо убедиться, что JIRA и Confluence прослушивают интерфейс обратной петли (или все интерфейсы).
Проблема, которую я видел несколько раз (обычно возвращающая пользователю ошибку 503), заключается в том, что Apache обнаруживает какую-то проблему с серверной частью. Когда это происходит, по умолчанию он отключается на 60 секунд. Это может быть полезным признаком того, что существует проблема конфликта ресурсов с JIRA и / или Confluence, поэтому ее не следует игнорировать, но 60 секунд простоя каждый раз, когда бэкэнд становится нестабильным, - это немного. Вы можете отключить это, настроив параметр повтора в директивах ProxyPass:
<VirtualHost *:*>
ServerName localhost
# DocumentRoot /var/www/html
<Proxy *>
Require all granted
</Proxy>
# ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://jira.team.domain.com:8080/ retry=0
ProxyPassReverse / http://jira.team.domain.com:8080/
</VirtualHost>
<VirtualHost *:*>
ServerName confluence.team.domain.com
DocumentRoot /var/www/html
<Proxy *>
Require all granted
</Proxy>
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://confluence.team.domain.com:8090/ retry=0
ProxyPassReverse / http://confluence.team.domain.com:8090/
</VirtualHost>
Из документации mod_proxy:
Тайм-аут повторной попытки работника пула подключений в секундах. Если рабочий пула подключений к внутреннему серверу находится в состоянии ошибки, Apache httpd не будет пересылать запросы на этот сервер до истечения времени ожидания. Это позволяет выключить внутренний сервер для обслуживания и вернуть его в работу позже. Значение 0 означает, что рабочие процессы всегда будут повторяться в состоянии ошибки без тайм-аута.
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
Если это не сработает, попробуйте использовать Инструменты разработчика вашего браузера, чтобы точно узнать, что возвращается или не возвращается Apache и какие заголовки устанавливаются. Взглянув на журналы Apache, используя tail -f /path/to/logs/goes/here
пока вы нажимаете кнопку обновления, тоже не повредит.