Descripción general
Configuración de protocolos componibles
protocols en el archivo de configuración XML:
Configuración de las capas de protocolo
protocols:
plain_http- nombre al que puede hacer referencia otra capatype- indica el manejador de protocolo que se instanciará para procesar datos. Tiene el siguiente conjunto de manejadores de protocolo predefinidos:tcp- manejador del protocolo nativo de ClickHousehttp- manejador del protocolo HTTP de ClickHousetls- capa de cifrado TLSproxy1- capa PROXYv1mysql- manejador del protocolo de compatibilidad con MySQLpostgres- manejador del protocolo de compatibilidad con Postgresprometheus- manejador del protocolo Prometheusinterserver- manejador interserver de ClickHouse
El manejador del protocolo
gRPC no está implementado para protocolos componibles<port> y, opcionalmente, <host>.
Por ejemplo, para configurar un endpoint en la capa HTTP añadida anteriormente,
podríamos modificar la configuración de la siguiente manera:
<host>, se usa <listen_host> de la configuración
principal.
Configuración de secuencias de capas
<impl> y haciendo referencia a otro
módulo. Por ejemplo, para configurar una capa TLS sobre nuestro módulo plain_http,
podríamos seguir modificando nuestra configuración de la siguiente manera:
Asociar endpoints a las capas
Definición de endpoints adicionales
<type>. Por ejemplo, podemos definir el endpoint another_http para el
módulo plain_http de la siguiente manera:
Manejadores HTTP personalizados por endpoint
type=http comparten la misma configuración
<http_handlers>. Puede cambiar esto añadiendo una etiqueta <handlers> que apunte
a una sección de configuración distinta. Esto permite que cada puerto HTTP sirva un
conjunto diferente de reglas de enrutamiento HTTP.
Por ejemplo, para ejecutar una API HTTP alternativa en el puerto 8124 con sus propios handler:
<http_handlers>,
mientras que las solicitudes al puerto 8124 usan las reglas de <http_handlers_alt>. Si se omite <handlers>,
el endpoint vuelve al valor predeterminado <http_handlers>.
La sección de handler personalizados sigue el mismo formato que
<http_handlers>.
Los cambios en la sección de handler personalizados se detectan durante la recarga de la configuración, y el
endpoint correspondiente se reinicia automáticamente.
Usuario de sesión predeterminado por endpoint
user o un paquete Hello del protocolo nativo con un nombre de usuario
vacío), el servidor lo autentica como el usuario de sesión predeterminado: el
ajuste del servidor default_session_user,
cuyo valor predeterminado es default.
La etiqueta <default_session_user> sobrescribe este ajuste para un único endpoint. Esto
permite que distintos puertos de escucha atiendan a diferentes usuarios anónimos:
readonly_user. Un client que proporciona explícitamente un nombre de usuario no se ve afectado.
La etiqueta se busca desde el módulo del endpoint hacia los módulos (impl)
a los que hace referencia, y prevalece el valor más cercano al endpoint. Se aplica a los handlers de protocolo
tcp, http, mysql y postgres, así como a los handlers de prometheus que
autentican solicitudes (remote_write, remote_read, query y api_v1); los
endpoints de exposición de métricas (incluidos los endpoints de Keeper exclusivos para métricas) se sirven
sin autenticación e ignoran esta configuración. Los handlers con un usuario fijo (la clave user
dentro de handler de una regla http_handlers, o la clave user dentro de handler
de una regla prometheus.handlers) se autentican como el usuario configurado y también ignoran esta configuración; en
particular, un default_session_user vacío no los rechaza. No se puede utilizar con el protocolo
interserver: las conexiones entre servidores se autentican mediante el secreto del cluster
y el usuario inicial, y nunca usan el usuario de sesión predeterminado.
Especificar parámetros adicionales de la capa
privateKeyFile) y archivos de certificado (certificateFile)
de la siguiente manera: