Сведения о сети для кластера GitHub Enterprise Server
Каждый узел в кластере GitHub Enterprise Server должен иметь возможность взаимодействовать со всеми другими узлами в кластере по сети. Вы можете просмотреть необходимые порты и протоколы для конечных пользователей, администрирования и обмена данными между узлами. Чтобы распределить трафик между интерфейсными узлами, GitHub рекомендует настроить внешнюю подсистему балансировки нагрузки.
Рекомендации по сети
Реализация самого простого проекта сети для кластеризации заключается в размещении узлов в одной локальной сети. Если кластер должен охватывать подсети, не рекомендуется настраивать правила брандмауэра между сетями. Задержка между узлами должна быть меньше 1 миллисекунд.
Задержка между основными и реплика узлами должна быть меньше 70 миллисекунд. Не рекомендуется настраивать брандмауэр между сетями узлов.
Порты приложений для конечных пользователей
Порты приложений предоставляют конечным пользователям доступ к веб-приложениям и Git.
| Порт | Description | Encrypted |
|---|---|---|
| 22/TCP | Git по протоколу SSH | |
| 25/TCP | SMTP | Требуется STARTTLS |
| 80/TCP | HTTP | Если протокол SSL включен, этот порт перенаправляется на HTTPS |
| 443/TCP | HTTPS | |
| 9418/TCP | Простой порт протокола Git (Отключено в частном режиме) |
Административные порты
Административные порты не требуются для использования основного приложения конечными пользователями.
| Порт | Description | Encrypted |
|---|---|---|
| ICMP | ICMP Ping | |
| 122/TCP | Административный SSH | |
| 161/UDP | SNMP | |
| 8080/TCP | HTTP консоли управления | Если протокол SSL включен, этот порт перенаправляется на HTTPS |
| 8443/TCP | HTTPS консоли управления |
Порты взаимодействия кластера
Если брандмауэр уровня сети установлен между узлами, эти порты должны быть доступны. Обмен данными между узлами не шифруется. Эти порты не должны быть доступны извне.
| Порт | Description |
|---|---|
| 1336/TCP | Внутренний API |
| 3033/TCP | Внутренний доступ к SVN |
| 3037/TCP | Внутренний доступ к SVN |
| 3306/TCP | MySQL |
| 4486/TCP | Доступ к регулятору |
| 5115/TCP | Серверная часть служба хранилища |
| 5208/TCP | Внутренний доступ к SVN |
| 6379/TCP | Redis |
| 8001/TCP | Grafana |
| 8090/TCP | Внутренний доступ к GPG |
| 8149/TCP | Доступ к файловому серверу GitRPC |
| 8300/TCP | Consul |
| 8301/TCP | Consul |
| 8302/TCP | Consul |
| 9000/TCP | Управляющая программа Git |
| 9102/TCP | Файловый сервер Pages |
| 9105/TCP | Сервер LFS |
| 9200/TCP | Elasticsearch |
| 9203/TCP | Служба семантического кода |
| 9300/TCP | Elasticsearch |
| 11211/TCP | Memcache |
| 161/UDP | SNMP |
| 8125/UDP | Statsd |
| 8301/UDP | Consul |
| 8302/UDP | Consul |
| 25827/UDP | Collectd |
Настройка подсистемы балансировки нагрузки
Рекомендуется использовать внешнюю подсистему балансировки нагрузки на основе TCP, которая поддерживает протокол PROXY для распределения трафика между узлами. Рассмотрите возможность использования следующих конфигураций подсистемы балансировки нагрузки:
- TCP-порты (как показано ниже) следует перенаправить на узлы, на которых запущена служба
web-server. Это единственные узлы, обслуживающие внешние клиентские запросы. - Прикрепленные сеансы не должны быть включены.
Предупреждение. При прекращении подключений HTTPS в подсистеме балансировки нагрузки запросы от подсистемы балансировки нагрузки к GitHub Enterprise Server также должны использовать протокол HTTPS. Понижение уровня подключения к HTTP не поддерживается.
Обработка сведений о подключениях клиентов
Так как подключения клиентов к кластеру выполняются из подсистемы балансировки нагрузки, IP-адрес клиента может быть потерян. Для корректной записи сведений о подключении клиента требуется учесть некоторые особенности.
Мы настоятельно рекомендуем реализовать протокол PROXY, если подсистема балансировки нагрузки поддерживает его. Если поддержка PROXY недоступна, нагрузку на порты HTTP и HTTPS можно также распределять с помощью заголовка X-Forwarded-For.
Предупреждение системы безопасности. Если включена поддержка прокси-сервера или перенаправление HTTP, крайне важно, чтобы внешний трафик не мог напрямую поступать на устройства GitHub Enterprise Server. Если внешний трафик не будет блокироваться должным образом, существует риск подделки исходных IP-адресов.
Включение поддержки PROXY на GitHub Enterprise Server
Настоятельно рекомендуется включить поддержку PROXY для экземпляра и подсистемы балансировки нагрузки.
Примечание. GitHub Enterprise Server поддерживает протокол PROXY версии 1, несовместимый с подсистемами балансировки сетевой нагрузки AWS. Если вы используете подсистемы балансировки сетевой нагрузки AWS с GitHub Enterprise Server, не включайте поддержку PROXY.
-
Для имеющегося экземпляра используйте следующую команду:
ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply -
Для подсистемы балансировки нагрузки следуйте инструкциям, предоставленным поставщиком.
Сопоставления TCP-портов протокола ПРОКСИ
| Исходный порт | Порт назначения | Описание службы |
|---|---|---|
| 22 | 23 | Git по протоколу SSH |
| 80 | 81 | HTTP |
| 443 | 444 | HTTPS |
| 8080 | 8081 | HTTP консоли управления |
| 8443 | 8444 | HTTPS консоли управления |
| 9418 | 9419 | Git |
Включение поддержки X-Forwarded-For на GitHub Enterprise Server
X-Forwarded-For Используйте протокол , только если протокол PROXY недоступен. Заголовок X-Forwarded-For совместим только с HTTP и HTTPS. Для подключений Git по протоколу SSH IP-адрес будет иметь значение подсистемы балансировки нагрузки. В некоторых средах IP-адреса клиента в журнале аудита экземпляра могут отображаться 127.0.0.1неправильно.
Чтобы включить заголовок X-Forwarded-For, используйте следующую команду:
ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply
Сопоставления портов протокола TCP для использования без поддержки PROXY
| Исходный порт | Порт назначения | Описание службы |
|---|---|---|
| 22 | 22 | Git по протоколу SSH |
| 25 | 25 | SMTP |
| 80 | 80 | HTTP |
| 443 | 443 | HTTPS |
| 8080 | 8080 | HTTP консоли управления |
| 8443 | 8443 | HTTPS консоли управления |
Настройка проверок работоспособности
Проверки работоспособности позволяют подсистеме балансировки нагрузки прекратить направлять трафик узлу, который не отвечает, в случае неудачной попытки выполнения предварительно настроенной проверки этого узла. Если узел кластера завершается сбоем, проверки работоспособности, связанные с избыточными узлами, обеспечивают высокий уровень доступности.
Настройте подсистему балансировки нагрузки, чтобы проверка следующий URL-адрес.
http(s)://HOSTNAME/status
Конечная точка вернет код 200 состояния (ОК), если узел работоспособен и доступен для запросов конечных пользователей. Дополнительные сведения см. в разделе Мониторинг конфигурации высокого уровня доступности.
Примечание. Если устройство находится в режиме обслуживания, в URL-адресе https://HOSTNAME/status вернется код состояния 503 ("Служба недоступна"). Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.
Требования к DNS
Поиски DNS для имени узла GitHub Enterprise Server должны разрешаться в подсистему балансировки нагрузки. Рекомендуется включить изоляцию поддомена. Если изоляция поддомена включена, дополнительная запись с подстановочными знаками (*.HOSTNAME) также должна разрешаться в подсистему балансировки нагрузки. Дополнительные сведения см. в разделе Включение изоляции поддомена.