Visão geral
Configurando protocolos componíveis
protocols no arquivo de configuração XML:
Configurando camadas de protocolo
protocols:
plain_http- nome ao qual outra camada pode fazer referênciatype- indica o handler de protocolo que será instanciado para processar dados. Ele tem o seguinte conjunto de handlers de protocolo predefinidos:tcp- handler do protocolo nativo do ClickHousehttp- handler do protocolo HTTP do ClickHousetls- camada de criptografia TLSproxy1- camada PROXYv1mysql- handler do protocolo de compatibilidade com MySQLpostgres- handler do protocolo de compatibilidade com PostgreSQLprometheus- handler do protocolo Prometheusinterserver- handler de interservidor do ClickHouse
O handler de protocolo
gRPC não está implementado para Composable protocols<port> e <host> opcionais.
Por exemplo, para configurar um endpoint na camada HTTP adicionada anteriormente,
poderíamos modificar nossa configuração da seguinte forma:
<host> for omitida, será usada a <listen_host> da configuração raiz.
Configurando sequências de camadas
<impl>, fazendo referência a outro
módulo. Por exemplo, para configurar uma camada TLS sobre o nosso módulo plain_http,
podemos ajustar ainda mais a configuração da seguinte forma:
Associando endpoints às camadas
Definição de endpoints adicionais
<type>. Por exemplo, podemos definir o endpoint another_http para o
módulo plain_http da seguinte forma:
Handlers HTTP personalizados por endpoint
type=http compartilham a mesma
configuração <http_handlers>. Você pode sobrescrever isso adicionando uma tag <handlers> que aponta
para outra seção de configuração. Isso permite que cada porta HTTP use um
conjunto diferente de regras de roteamento HTTP.
Por exemplo, para executar uma API HTTP alternativa na porta 8124 com seus próprios handlers:
<http_handlers>,
enquanto as requisições para a porta 8124 usam as regras de <http_handlers_alt>. Se <handlers>
for omitido, o endpoint volta para o <http_handlers> padrão.
A seção de handlers personalizados segue o mesmo formato de
<http_handlers>.
As alterações na seção de handlers personalizados são detectadas durante a recarga da configuração, e o
endpoint correspondente é reiniciado automaticamente.
Usuário de sessão padrão por endpoint
user ou um pacote Hello do protocolo nativo com um nome de usuário
vazio), o servidor o autentica como o usuário de sessão padrão —
a configuração do servidor default_session_user, cujo valor padrão é default.
A tag <default_session_user> substitui essa configuração para um único endpoint. Isso
permite que diferentes portas de escuta atendam a diferentes usuários anônimos:
readonly_user. Um cliente que informa explicitamente um nome de usuário não é afetado.
A tag é pesquisada a partir do módulo do endpoint em direção aos módulos (impl)
referenciados, e o valor mais próximo do endpoint prevalece. Ela se aplica aos handlers de protocolo
tcp, http, mysql e postgres, bem como aos handlers prometheus que
autenticam solicitações (remote_write, remote_read, query e api_v1); os
endpoints de exposição de métricas (incluindo endpoints do Keeper exclusivos para métricas) são disponibilizados
sem autenticação e ignoram a configuração. Handlers com um usuário fixo (a chave user
dentro de handler de uma regra http_handlers, ou a chave user dentro de handler
de uma regra prometheus.handlers) autenticam as solicitações como o usuário configurado e também ignoram a configuração — em
particular, um default_session_user vazio não os rejeita. Ela não pode ser usada com o
protocolo interservidor: as conexões interservidor são autenticadas pelo Secret do cluster
e pelo usuário inicial e nunca usam o usuário de sessão padrão.
Especificando parâmetros adicionais da camada
privateKeyFile) e arquivos de certificado (certificateFile)
da seguinte forma: