Proxy transparente para a rede do Docker Significa que o TCP está quebrado

Question

Minha configuração de registro é um único host do Docker com o UDP 514 exposto para o syslog. Um contêiner nginx tem sua porta publicada, portanto, quando você envia logs para 10.1.1.100 (na imagem abaixo), ele acessa primeiro o nginx, cuja configuração para balanceamento de carga transparente para os contêineres do Logstash é:

user root;
events {worker_connections 32768;}
stream {
 upstream logstash_servers {
  server logstash-collector-01:514;
  server logstash-collector-02:514;
  server logstash-collector-03:514;
 }
 listen 514 udp;
 proxy_pass logstash_servers;
 proxy_bind $remote_addr transparent;
 }
}

Isso funciona bem. No entanto, TCP 514 (ou qualquer coisa TCP, para essa matéria) não faz. Mesmo quando eu adiciono o listener e as configurações corretas, acredito que o handshake TCP não seja concluído, porque com o nginx fazendo balanceamento de carga transparente, o proxy_bind é transmitido, por exemplo, 10.1.1.5 como um IP de origem para, e. 172.18.0.4 (uma instância do Logstash). Essa instância, em seguida, tenta concluir o handshake, mas 10.1.1.5 (e quaisquer roteadores ao longo do caminho) não sabe como rotear para a rede Docker de 172.18.0.0/16.

Existe uma solução aqui para poder usar o TCP para registrar?

    

Answer 1

Parece que o nginx pode não ser a melhor ferramenta para o trabalho aqui - haproxy (se você quiser um balanceamento de carga TCP / UDP simples) ou o rsyslog (se você quiser algo um pouco mais sensível a aplicativos) pareceria melhor , e cumpriria a mesma função que o nginx atualmente é.

Examinando sua configuração, você pode até mesmo ter um liststash listener de frontend em 514, que poderia encaminhar para outra instância de logstash para processamento real. Como o logstash não faz o balanceamento de carga do AFAIK, você poderia "rotear" os eventos com base em algumas tags / tipos que você colocou no lugar.

Verificando o link , para que você tenha TCP e UDP, você precisa de algo como:

stream {
    upstream logstash_servers {
        server logstash-collector-01:514;
        server logstash-collector-02:514;
        server logstash-collector-03:514;
    }
    server {
        listen 514;
        ...
    }
    server {
        listen 514 udp;
        ...
    }
}

Não estou completamente claro se a utilização dos logstash_servers no bloco do servidor UDP fará com que o nginx fale UDP ou TCP a eles, portanto, talvez seja necessário disponibilizá-los.

Eu duvido que o problema seja o nó nginx usando o IP "errado" como fonte ao se conectar com os back-ends do logstash - normalmente, o front-end do nginx usará o que o IP "certo" fizer que, no seu caso, significaria um endereço dentro de 172.18 / 16. Isso é semelhante ao modo como o nginx é usado ao fazer proxy reverso para localhost: nessa situação, o nginx se comunicará com o aplicativo localhost usando um IP de origem de 127.0.0.1 (ou :: 1), não o IP em que nginx viu a solicitação. .

E há também o fato de que você parece estar dizendo que tudo isso funciona para o UDP - o que tenderia a dizer que o roteamento não é um problema como esse, mas que algo em sua configuração TCP poderia ser.