Обзор
Настройка составных протоколов
protocols:
Настройка уровней протокола
protocols:
plain_http- имя, на которое может ссылаться другой слойtype- указывает обработчик протокола, который будет создан для обработки данных. Доступен следующий набор предопределённых обработчиков протоколов:tcp- нативный обработчик протокола ClickHousehttp- HTTP-обработчик протокола ClickHousetls- слой шифрования TLSproxy1- слой PROXYv1mysql- обработчик протокола совместимости с MySQLpostgres- обработчик протокола совместимости с PostgreSQLprometheus- обработчик протокола Prometheusinterserver- межсерверный обработчик ClickHouse
Обработчик протокола
gRPC не реализован для Composable protocols<port> и необязательным тегом <host>.
Например, чтобы настроить конечную точку на ранее добавленном HTTP-слое, мы
можем изменить конфигурацию следующим образом:
<host> не указан, используется <listen_host> из корневой конфигурации.
Настройка последовательностей слоёв
<impl> и ссылки на другой
модуль. Например, чтобы настроить слой TLS поверх нашего модуля plain_http,
мы можем дополнительно изменить конфигурацию следующим образом:
Подключение конечных точек к слоям
Определение дополнительных конечных точек
<type>. Например, можно определить конечную точку another_http для
модуля plain_http следующим образом:
Пользовательские HTTP-обработчики для отдельных конечных точек
type=http используют одну и ту же конфигурацию
<http_handlers>. Это можно переопределить, добавив тег <handlers>, который ссылается
на другой раздел конфигурации. Благодаря этому каждый HTTP-порт может обслуживать
свой набор правил HTTP-маршрутизации.
Например, чтобы запустить альтернативный HTTP API на порту 8124 с собственными обработчиками:
<http_handlers>,
а запросы к порту 8124 — правила <http_handlers_alt>. Если <handlers>
не указан, конечная точка использует значение по умолчанию — <http_handlers>.
Раздел пользовательских обработчиков имеет тот же формат, что и
<http_handlers>.
Изменения в разделе пользовательских обработчиков отслеживаются при перезагрузке конфигурации, и
соответствующая конечная точка автоматически перезапускается.
Пользователь сеанса по умолчанию для каждой конечной точки
user или в пакете Hello собственного протокола с пустым именем
пользователя), сервер аутентифицирует его как пользователя сеанса по умолчанию —
default_session_user, настройку сервера
со значением по умолчанию default.
Тег <default_session_user> переопределяет эту настройку для отдельной конечной точки. Это
позволяет разным прослушиваемым портам обслуживать разных анонимных пользователей:
readonly_user. Клиент, явно указывающий имя пользователя, не затрагивается.
Тег ищется от модуля конечной точки в направлении модулей, на которые ссылается impl,
и приоритет имеет значение, расположенное ближе всего к конечной точке. Эта настройка применяется к обработчикам протоколов tcp, http,
mysql и postgres, а также к обработчикам prometheus, которые
аутентифицируют запросы (remote_write, remote_read, query и api_v1); конечные точки
экспорта метрик (включая конечные точки Keeper, предоставляющие только метрики) обслуживаются
без аутентификации и игнорируют эту настройку. Обработчики с фиксированным пользователем (ключ user
внутри handler правила http_handlers или ключ user внутри handler
правила prometheus.handlers) аутентифицируют запросы от имени настроенного пользователя и также игнорируют эту настройку —
в частности, пустое значение default_session_user не приводит к их отклонению. Эту настройку нельзя использовать с протоколом
interserver: межсерверные подключения аутентифицируются с помощью секрета
кластера и начального пользователя и никогда не используют пользователя сеанса по умолчанию.
Указание дополнительных параметров слоя
privateKeyFile) и файлы сертификатов (certificateFile)
следующим образом: