Como configurar o log dentro de um contêiner Docker?

Question

Eu estava tentando dockerizar (no Debian 8.2) um servidor OpenVPN (sim, eu sei, já existem esses contêineres), mas algo deu errado dentro do contêiner e o servidor falhou ao iniciar.

Eu decidi inspecionar os logs, mas /var/log/syslog (logs do OpenVPN aqui na minha máquina host) estava faltando dentro do container.

Achei que rsyslog não estava instalado e incluí a instalação antes da instalação do OpenVPN no Dockerfile. Mas isso não teve efeito, o syslog ainda estava faltando.

Meu Dockerfile é:

FROM debian:8.2
USER root
EXPOSE 53/udp
EXPOSE 1194/udp
EXPOSE 443/tcp
RUN apt-get update
RUN apt-get install -y rsyslog
RUN apt-get install -y openvpn
# ...
# Some configuration stuff
# ...
ENTRYPOINT service openvpn start && sh

As perguntas são:

• Por que o OpenVPN registra em syslog após a instalação padrão no meu host Debian 8.2 e não o faz dentro de um container? Eu não configurei nada na minha máquina host para forçar o log do OpenVPN a syslog . Foi um comportamento padrão.

• Como faço para configurar o log do servidor OpenVPN sendo executado dentro de um contêiner docker?

Answer 1

O OpenVPN não iniciaria com o Dockerfile porque não há nada para iniciá-lo :-). Seu entrypoint é sh ; é tudo o que vai rodar.

Se você quiser iniciar dois daemons dentro do Docker, seu entrypoint precisa ser um programa que inicie ambos. Muitas pessoas usam o supervisord para isso. Observe que o Docker é um software relativamente opinativo e a execução de vários daemons em um contêiner não é considerada idiomática.

Se isso é apenas sobre depuração, não há problema. Apenas não execute o openvpn com --daemon ou --log . Ele irá escrever para stdout (alegadamente, embora eu não ficaria surpreso ao ver stderr). Isso é ótimo para depuração se você iniciar manualmente. Você verá todas as mensagens de log imediatamente no terminal.

Se você configurar o ponto de entrada e iniciar manualmente o contêiner no modo interativo - mesmo negócio. Se você iniciá-lo como um recipiente de fundo (perdoe minha indefinição), a saída será capturada por docker logs . É a mesma técnica favorecida pelos sistemas init modernos, como o systemd (e o systemd "journal" logging system).

Uma vez que você tenha o daemon configurado como deseja, você pode estar interessado em sistemas mais personalizados para capturar logs, como as outras respostas.

O Docker possui drivers de registro conectáveis, de acordo com a página de manual para docker logs . Há um driver "syslog" que diz que ele escreve no syslog do host. Ele diz que docker logs não funciona, mas não espero que seja um problema para você.

AVISO : docker logs funciona se você usar o driver de log do journald. No entanto, nos padrões do Debian, minha suposição é que isso causaria a perda de logs durante a reinicialização. Porque o Debian não configura um diário persistente. Não é difícil mudar, se é isso que você quer.

O outro driver de registro que suporta o comando docker logs é chamado de "arquivo json". Espero que seja persistente, mas você pode preferir uma das outras soluções.

A pergunta "por que"

O ponto é que os contêineres do Docker não funcionam necessariamente da mesma forma que o sistema operacional no qual eles são baseados. O Docker não é virtualização de SO como LXC, systemd-nspawn ou uma máquina virtual. Embora o Docker tenha sido derivado do LXC, ele foi projetado especificamente para "contêineres de aplicativos" que executam um único programa.

As distribuições do servidor

(atual) são projetadas como uma combinação de vários programas em execução. Então você não pode pegar um pacote deles e esperar que ele se comporte exatamente da mesma maneira dentro de um desses contêineres de aplicativos.

A comunicação com um daemon de registro é um ótimo exemplo. Não há nada lá que vá mudar, exceto que as pessoas se familiarizarão mais com o conceito de contêineres de aplicativos. E se é isso que eles realmente querem usar :). Eu suspeito que muitos administradores de sistemas estariam mais interessados em um mashup de LXC (containers de sistema operacional), com algo como o NixOS para compartilhar pacotes entre containers; só não foi escrito ainda AFAIK. Ou apenas um melhor LXC .

    

Answer 2

Dê uma olhada no loggly - link ou fluentd - link .