Como instalar e configurar o encaminhador no Linux

Este documento descreve como instalar e configurar o encaminhador no Linux. É possível instalar o encaminhador em várias distribuições Linux (Debian, Ubuntu, Red Hat, Suse etc.). O Google Cloud fornece o software usando um contêiner do Docker. É possível executar e gerenciar o contêiner do Docker em uma máquina física ou virtual que executa o Linux.

Personalizar os arquivos de configuração

Com base nas informações enviadas antes da implantação, o Google Cloud fornece o software de encaminhamento e os arquivos de configuração. O Google Cloud orienta os arquivos de configuração para a instância de encaminhamento na sua rede. Se precisar alterar a configuração, entre em contato com o Suporte do Chronicle.

Requisitos do sistema

Veja a seguir recomendações gerais. Para ver recomendações específicas ao seu sistema, entre em contato com o suporte do Chronicle.

  • RAM: 1,5 GB para cada tipo de dado coletado. Por exemplo, detecção e resposta de endpoint (EDR), DNS e DHCP são tipos de dados distintos. Você precisa de 4,5 GB de RAM para coletar todos os três.

  • CPU: duas CPUs são suficientes para processar menos de 10.000 eventos por segundo (EPS,na sigla em inglês) (total para todos os tipos de dados). Se você quer encaminhar mais de 10.000 EPS, provisione de 4 a 6 CPUs.

  • Disco: 100 MB de espaço em disco são suficientes, independentemente da quantidade de dados que o encaminhador do Chronicle processa. Consulte também Buffers de disco se precisar armazenar em buffer mensagens enviadas para o disco, em vez de na memória. O encaminhador do Chronicle armazena em buffer por padrão a memória.

Verifique a configuração do firewall

Se você tiver firewalls ou proxies autenticados entre o contêiner de encaminhamento do Chronicle e a Internet, eles precisarão de regras para abrir o acesso aos seguintes hosts:

Tipo de conexão Destino Porta
TCP malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP oauth2.googleapis.com 443
TCP storage.googleapis.com 443

Coletar dados do Splunk

É possível configurar o encaminhador do Chronicle para encaminhar seus dados do Splunk para o Chronicle. O Google Cloud configura o encaminhador do Chronicle com as seguintes informações para encaminhar os dados do Splunk:

  • URL da API REST do Splunk (por exemplo, https://10.0.113.15:8889).

  • Consultas do Splunk para gerar dados para cada um dos tipos de dados necessários (por exemplo, index=dns).

É necessário disponibilizar as credenciais da sua conta do Splunk para o encaminhamento do Chronicle.

Crie um arquivo local para as credenciais do Splunk e nomeie-o como creds.txt. Coloque seu nome de usuário na primeira linha e a senha na segunda linha:

  cat creds-file

  myusername
  mypassword

Para clientes que usam o encaminhador do Chronicle para acessar uma instância do Splunk, copie o arquivo creds.txt para o diretório de configuração (o mesmo diretório dos arquivos de configuração). Exemplo:

cp creds-file ~/config/creds.txt

Verifique se o arquivo creds.txtem> está no local adequado:

ls ~/config 

- splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10
      maximum_window_size: 30
      user: admin
      password: letmeinaA1!
      query_string: search index=* sourcetype=dns
      query_mode: realtime

minimum_window_size: o período mínimo passado para a consulta do Splunk. O valor padrão é de 10 segundos. Esse parâmetro é usado para ajustar se o requisito é mudar a frequência com que o servidor do Splunk é consultado quando o encaminhador está em estado estável. Além disso, quando há atraso, a chamada de API do Splunk pode ser feita várias vezes.

maximum_window_size: o período máximo passado para a consulta do Splunk. O valor padrão é de 30 segundos. Esse parâmetro é usado para ajustar os casos em que há atraso e se mais dados por consulta são necessários.

Altere esse parâmetro (igual ou maior que) quando você alterar o parâmetro mínimo. Os casos de atraso podem ocorrer quando uma chamada de consulta do Splunk está demorando mais do que o valor de max_window_size.

Instalar o Docker

Você pode instalar o Docker em vários sistemas operacionais host. A instalação real do Docker depende do ambiente do host. O Google Cloud tem uma documentação limitada que ajuda a instalar o Docker em várias das distribuições Linux mais conhecidas. No entanto, o Docker é de código aberto e a documentação substancial já está disponível.

Depois de instalar o Docker no sistema, o restante do processo de instalação do encaminhador do Chronicle é idêntico, independentemente da distribuição do Linux usada.

Verifique se o Docker está instalado no sistema executando o seguinte comando (privilégios elevados):

# docker ps

A resposta a seguir indica que o Docker foi instalado corretamente:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Use o comando a seguir para coletar outras informações sobre a instalação do Docker:

# docker info

Se você tiver problemas com o Docker, o Chronicle Support poderá solicitar a saída desse comando para ajudar na depuração.

Instalar o encaminhador

Nesta seção, descrevemos como instalar o Chronicle Forwarder usando um contêiner do Docker em um sistema Linux.

Etapa 1. Fazer o download, transferir e instalar os arquivos de configuração do encaminhador

O Google Cloud fornece arquivos de configuração de encaminhamento específicos para seu sistema operacional (Linux ou Windows). Faça download dos arquivos do link fornecido pelo seu representante do Chronicle para um diretório local no seu laptop (por exemplo, crronicle). Depois de concluir as etapas a seguir, transfira os arquivos de configuração do laptop para o diretório ~/config do encaminhamento no diretório inicial do usuário.

  1. Conecte-se ao encaminhador do Linux por meio do terminal.

  2. Crie um novo usuário no encaminhador do Linux.

    # adduser <username>

    # passwd <username>

    # usermod -aG wheel <username>

  3. Altere o diretório para o diretório principal do novo usuário que executará o contêiner do Docker.

  4. Crie um diretório para armazenar os arquivos de configuração do encaminhador do Chronicle: # mkdir ~/config

  5. Alterar o diretório

  6. Depois de transferir os arquivos, confirme se os arquivos de configuração estão no diretório ~/config:

    # ls -l

Etapa 2. Executar o encaminhador no contêiner do Docker

Você pode usar os procedimentos a seguir para iniciar o encaminhador do Chronicle pela primeira vez e também para fazer upgrade para a versão mais recente do contêiner do Chronicle:

As opções --log-opt estão disponíveis desde o Docker 1.13. Essas opções limitam o tamanho dos arquivos de registros de contêiner e precisam ser usadas desde que sua versão do Docker seja compatível com elas.

  1. Se você estiver fazendo upgrade, comece limpando todas as execuções anteriores do Docker. No exemplo a seguir, o nome do contêiner do Docker é cfps. Em seguida, acesse a imagem do Docker mais recente do Google Cloud com o comando # docker pull abaixo.

    # docker stop cfps
# docker rm cfps

  2. Consiga a imagem mais recente do Docker do Google Cloud:

    # docker pull gcr.io/chronicle-container/cf_production_stable

  3. Inicie o encaminhador do Chronicle no contêiner do Docker:

    docker run \

  --detach \

  --name cfps \

  --restart=always \

  --log-opt max-size=100m \

  --log-opt max-file=10 \

  --net=host \

  -v ~/config:/opt/chronicle/external \

  gcr.io/chronicle-container/cf_production_stable

Esses comandos também são fornecidos como um script de shell chamado run_docker_production_stable.sh.

O contêiner do Docker (e o encaminhador do Chronicle) persiste após a reinicialização do sistema.

Etapa 3. Monitorar e gerenciar o encaminhador

Os comandos do Docker a seguir ajudam a monitorar e gerenciar o encaminhador do Chronicle:

  • Verifique se o contêiner do Docker está em execução:

    docker ps

  • Exiba os registros do contêiner. Isso pode gerar um volume substancial de saída, mas é útil para depuração:

    docker logs cfps

  • Para ver o que está sendo executado no contêiner, faça o seguinte:

    docker top cfps

  • Para interromper o contêiner:

    docker stop cfps

Coletar dados de syslog

O encaminhamento do Chronicle pode operar como um servidor Syslog, o que significa que você pode configurar qualquer dispositivo ou servidor compatível com o envio de dados de syslog por uma conexão TCP ou UDP para encaminhar os dados para o encaminhamento do Chronicle. Você pode controlar quais dados o dispositivo ou servidor envia ao encaminhador do Chronicle. O encaminhador do Chronicle pode então encaminhar os dados para o Chronicle.

O arquivo de configuração (fornecido pelo Google Cloud) especifica quais portas você quer monitorar para cada tipo de dado encaminhado (por exemplo, porta 10514). Por padrão, o encaminhador do Chronicle aceita conexões TCP e UDP.

Configurar rsyslog

Para configurar o rsyslog, é necessário especificar um destino para cada porta (por exemplo, cada tipo de dados). Consulte a sintaxe do seu sistema na documentação. Os exemplos a seguir ilustram uma configuração de destino rsyslog:

  • Tráfego de registro TCP: dns.* @192.168.0.12:10514

  • Tráfego de registro UDP: dns.* @192.168.0.12:10514

Ativar o TLS para configurações do syslog

Você pode ativar o TLS para a conexão do Syslog com o encaminhador do Chronicle. No arquivo de configuração do encaminhador do Chronicle, especifique o local do próprio certificado gerado e da chave de certificado, conforme mostrado no exemplo a seguir:

certificado "/opt/chronicle/external/certs/client_generated_cert.pem"
Chave_de_certificado "/opt/chronicle/external/certs/client_generated_cert.key"

Com base no exemplo mostrado, a configuração do encaminhador do Chronicle seria modificada da seguinte maneira:

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
  tcp_address: 0.0.0.0:10515
  tcp_buffer_size: 65536
  connection_timeout_sec: 60
  certificate: "/opt/chronicle/external/certs/client_generated_cert.pem"
  certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
  minimum_tls_version: "TLSv1_3"

O valor de batch_n_bytes não deve exceder 5 MB.

É possível criar um diretório de certificados no diretório de configuração e armazenar os arquivos de certificado nele.

Coletar dados de arquivos

Inicie o encaminhador do Chronicle no contêiner do Docker:

  docker run \

    --name cfps \

    --log-opt max-size=100m \

    --log-opt max-file=10 \

    --net=host \

    -v ~/config:/opt/chronicle/external \

    -v /var/log/crowdstrike/falconhoseclient:/opt/chronicle/edr \

     gcr.io/chronicle-container/cf_production_stable

Esse comando docker run é essencial para mapear o volume de carregamento para o contêiner.

Com base neste exemplo, você modificaria a configuração do encaminhador do Chronicle da seguinte maneira:

 collectors:
  - file:
       common:
         enabled: true
         data_type: CS_EDR
         data_hint:
         batch_n_seconds: 10
         batch_n_bytes: 1048576
       file_path: /opt/chronicle/edr/output/sample.txt
       filter:

Coletar dados de pacote

O encaminhador do Chronicle pode capturar pacotes diretamente de uma interface de rede usando o libpcap no Linux. Os pacotes são capturados e enviados ao Chronicle em vez de entradas de registro. A captura de pacotes é processada apenas a partir de uma interface local. Para ativar a captura de pacotes no seu sistema, entre em contato com o suporte do Chronicle.

O Google Cloud configura o encaminhador do Chronicle com a expressão Berkeley Packet Filter (BPF) usada ao capturar pacotes (por exemplo, porta 53 e não localhost).

Alternar a compactação de dados

A compactação de registros reduz o consumo de largura de banda da rede ao transferir registros para o Chronicle. No entanto, a compactação pode causar um aumento no uso da CPU. A compensação entre o uso de CPU e a largura de banda depende de muitos fatores, incluindo o tipo de dados de registro, a compactação desses dados, a disponibilidade de ciclos de CPU no host que executa o encaminhador e a necessidade de reduzir o consumo de largura de banda da rede.

Por exemplo, os registros baseados em texto são compactados com eficiência e podem economizar muito largura de banda com baixo uso da CPU. No entanto, os payloads criptografados de pacotes brutos não compactam bem e geram maior uso da CPU.

A compactação de registros fica desativada por padrão. Ativar a compactação de registros pode reduzir o consumo da largura de banda. No entanto, ativar a compactação de registros também pode aumentar o uso da CPU. Esteja ciente das vantagens e desvantagens.

Para ativar a compactação de registros, defina o campo compactação como true no arquivo de configuração do encaminhador do Chronicle, conforme mostrado no exemplo a seguir:

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
      secret_key: |
        {
          "type": "service_account",
...

Armazenando em buffer do disco

O armazenamento em buffer do disco permite que você armazene em buffer mensagens de backlog no disco, em vez de memória. As mensagens de backlog podem ser armazenadas caso o encaminhador ou o host subjacente falhem. Esteja ciente de que a ativação do armazenamento em buffer do disco pode afetar o desempenho.

Se você estiver executando o encaminhador usando o Docker, o Google recomenda montar um volume separado do volume de configuração para fins de isolamento. Além disso, cada entrada deve ser isolada com seu próprio diretório ou volume para evitar conflitos.

Exemplo de configuração: armazenamento em buffer do disco

A configuração a seguir inclui sintaxe para ativar o armazenamento em buffer do disco:

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the forwarder
      write_to_disk_dir_path: /buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Filtros de expressão regular

Os filtros de expressão regular permitem filtrar registros com base em correspondências de expressões regulares com base em registros brutos.

Os filtros empregam a sintaxe RE2 descrita aqui: https://github.com/google/re2/wiki/Sintaxe

Os filtros precisam incluir uma expressão regular e, como opção, definir um comportamento quando houver uma correspondência. O comportamento padrão em uma correspondência é bloquear. Também é possível configurá-lo explicitamente como bloqueio.

Como alternativa, os filtros podem ser especificados com o comportamento allow. Se você especificar qualquer filtro de permissão, o encaminhamento bloqueará todos os registros que não corresponderem a pelo menos um filtro de permissão.

É possível definir um número arbitrário de filtros. Os filtros de bloco têm prioridade sobre os filtros de permissão.

Quando os filtros são definidos, é necessário atribuir um nome a eles. Os nomes dos filtros ativos serão informados ao Chronicle por meio das métricas de integridade do encaminhador. Os filtros definidos na raiz da configuração são mesclados com os filtros definidos no nível do coletor. Os filtros no nível do coletor têm precedência em casos de nomes conflitantes. Se nenhum filtro for definido no nível raiz ou do coletor, o comportamento será permitir todos.

Exemplo de configuração: filtros de expressão regular

Na configuração do encaminhador, os registros WINEVTLOG que não correspondem ao filtro raiz (allow_filter) são bloqueados. Dada a expressão regular, o filtro permite apenas registros com prioridades entre 0 e 99. No entanto, todos os registros NIX_SYSTEM que contêm 'foo' ou 'bar' são bloqueados, apesar de allow_filter. Isso ocorre porque os filtros usam um operador lógico "OR". Todos os registros são processados até que um filtro seja acionado.

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Etiquetas arbitrárias

Os rótulos são usados para anexar metadados arbitrários aos registros usando pares de chave e valor. Os rótulos podem ser configurados para um encaminhador inteiro ou dentro de um coletor específico de um encaminhador. Se ambos forem fornecidos, os rótulos serão mesclados com as chaves do coletor, que terão precedência sobre as chaves do encaminhador, se as chaves se sobrepuserem.

Exemplo de configuração: rótulos arbitrários

Na configuração do encaminhador a seguir, os pares de chave-valor e 'foo=bar' e #39;meow=mix' são anexados aos registros WINEVTLOG, e os pares de chave e valor 'foo=baz' e ##99;meow=mix' são anexados aos registros NIX_SYSTEM.

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Namespaces

Use rótulos de namespace para identificar registros de diferentes segmentos de rede e conflitar os endereços IP sobrepostos. É possível configurar um rótulo de namespace para todo um encaminhador ou dentro de um coletor específico do encaminhador. Se ambos forem incluídos, o namespace do coletor específico terá precedência.

Qualquer namespace configurado para o encaminhador aparece com os recursos associados na interface do usuário do Chronicle. Também é possível pesquisar namespaces usando o recurso Chronicle Search.

Para mais informações sobre como visualizar namespaces na interface do usuário do Chronicle, consulte este link.

Exemplo de configuração: namespaces

Na configuração do encaminhador, os registros WINEVTLOG são anexados ao namespace FORWARDER e os registros NIX_SYSTEM são anexados ao namespace CORPORATE.

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Entrada do Kafka

É possível ingerir dados de tópicos do Kafka da mesma forma que para o syslog. Os grupos de consumidores são utilizados para permitir a implantação de até três encaminhadores e a extração de dados do mesmo tópico do Kafka.

Para mais informações sobre grupos de consumidores de Kafka, consulte: https://docs.confluent.io/platform/current/clients/consumer.html.

Exemplo de configuração: entrada do Kafka

A configuração do encaminhador a seguir mostra como configurá-lo para ingerir dados de tópicos do Kafka:

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      username: user
      password: password
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "/path/to/cert.pem"
        certificate_key: "/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Balanceamento de carga e alta disponibilidade

O encaminhador do Chronicle Linux pode ser implantado em um ambiente em que um balanceador de carga da camada 4 está instalado entre a origem de dados e as instâncias do encaminhador. Isso permite que um cliente distribua a coleta de registros em vários encaminhadores ou envie registros para outro encaminhamento se houver falha. Esse recurso é compatível apenas com o tipo de coleção syslog.

O encaminhador do Linux inclui um servidor HTTP integrado que responde a verificações de integridade HTTP do balanceador de carga. O servidor HTTP também ajuda a garantir que os registros não sejam perdidos durante a inicialização ou o encerramento de um encaminhador.

Configure o servidor HTTP, o balanceamento de carga e as opções de alta disponibilidade na seção servidor do arquivo de configuração do encaminhador. Essas opções oferecem suporte à definição de durações de tempo limite e códigos de status retornados em resposta a verificações de integridade recebidas em implantações baseadas em orquestração e programador de contêineres, bem como em balanceadores de carga tradicionais.

Use os seguintes caminhos de URL para verificações de integridade, prontidão e atividade. Os valores <host:port> são definidos na configuração do encaminhador.

  • http://<host:port>/meta/available: verificações de atividade para programadores/orquestradores de contêineres, como o Kubernetes.
  • http://<host:port>/meta/ready: verificações de prontidão e verificações de integridade do balanceador de carga tradicional.

A configuração de encaminhamento a seguir é um exemplo de balanceamento de carga e alta disponibilidade:

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503
Caminho da configuração Descrição
servidor : Graceful_timeout Tempo que o encaminhamento retorna uma verificação de prontidão/saúde ruim e ainda aceita novas conexões. Esse também é o tempo de espera entre o recebimento de um sinal e o início do encerramento do próprio servidor. Isso permite que o tempo do balanceador de carga remova o encaminhador do pool.
servidor : dred_timeout Quantidade de tempo que o encaminhamento aguarda até que as conexões ativas sejam fechadas por conta própria antes de serem fechadas pelo servidor.
servidor : http : porta Número da porta que o servidor HTTP detecta para verificações de integridade do balanceador de carga. Precisa estar entre 1024-65535.
servidor : http : host Endereços IP ou nome do host que podem ser resolvidos para endereços IP que o servidor precisa detectar. Se estiver vazio, o valor padrão será o sistema local (0.0.0.0).
servidor : http : read_timeout Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. Tempo máximo permitido para ler toda a solicitação, o cabeçalho e o corpo. É possível definir read_timeout e read_header_timeout.
servidor : http : read_header_timeout Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. Tempo máximo permitido para ler cabeçalhos de solicitação. O prazo de leitura da conexão é redefinido depois da leitura do cabeçalho.
servidor : http : write_timeout Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. Tempo máximo permitido para enviar uma resposta. Ele é redefinido quando um novo cabeçalho de solicitação é lido.
servidor : http : inatividade_tempo limite Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. Tempo máximo de espera para a próxima solicitação quando as conexões inativas estiverem ativadas. Se o inatividade de nenhum valor for zero, o valor de read_timout será usado. Se ambos forem zero, read_header_timeout será usado.
routes : meta : pronto_status O código de status que o encaminhador retorna quando está pronto para aceitar tráfego em uma destas situações:
  • A verificação de prontidão é recebida de um programador ou orquestrador de contêiner, como o Kubernetes.
  • A verificação de integridade é recebida de um balanceador de carga tradicional.
routes : meta : não lida com status Código de status que o encaminhador retorna quando não está pronto para aceitar o tráfego.
routes : meta : available_status Código de status que o encaminhador retorna quando uma verificação de atividade é recebida e o encaminhador está disponível. As verificações de atividade geralmente são enviadas por programadores/orquestradores de contêineres, como o Kubernetes.

Perguntas frequentes

O que é um contêiner do Docker?

  • Os contêineres do Docker, como as máquinas virtuais, fornecem mais segurança, isolamento e gerenciamento de recursos.

  • Máquinas virtuais: têm um espaço privilegiado (kernel do Linux) e um espaço de usuário (tudo com que você interage: libc, python, ls, tcpdump etc.).

  • Os contêineres têm apenas um espaço de usuário (tudo o que você interage com: libc, python, ls, tcpdump etc.) e dependem do espaço de privilégios do host.

Por que distribuir um encaminhamento do Chronicle usando um contêiner?

  • Mais segurança com o isolamento:
    • O ambiente e os requisitos do cliente não afetam o encaminhamento do Chronicle.
    • O ambiente e os requisitos do encaminhador do Chronicle não afetam o cliente.
    • O mecanismo de distribuição de contêiner já existe e pode ser privado e separado para o Google Cloud e os clientes. https://cloud.google.com/container-registry/

Por que apenas o Linux para contêineres? E o Windows?

  • Os contêineres foram desenvolvidos primeiro para Linux e estão prontos para produção.

  • A compatibilidade do Windows com contêineres está melhorando. Os contêineres estão disponíveis para o Windows Server 2016 e o Windows 10.

Você precisa aprender comandos avançados do Docker?

  • O encaminhamento do Chronicle usa um único contêiner, então você não precisa saber sobre o Swarm, orquestração, Kubernetes ou outros conceitos ou comandos avançados do Docker.