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.

Decidi inspecionar os logs, mas /var/log/syslog(os logs do OpenVPN aqui na minha máquina host) estavam faltando dentro do contêiner.

Achei que rsyslognão estava instalado e adicionei sua instalação antes da instalação do OpenVPN ao Dockerfile. Mas isso não surtiu efeito, syslogainda faltava.

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 faz login syslogapós a instalação padrão no meu host Debian 8.2 e não faz isso dentro de um contêiner? Não configurei nada na minha máquina host para forçar o log do OpenVPN para syslog. Foi um comportamento padrão.

• Como configuro o log do servidor OpenVPN em execução dentro de um contêiner docker?

Answer 1

O OpenVPN não iniciaria com esse Dockerfile porque não há nada para iniciá-lo :-). Seu ponto de entrada é sh; isso é tudo que vai funcionar.

Se você deseja iniciar dois daemons dentro do Docker, seu ponto de entrada precisa ser um programa que inicie ambos. Muita gente usa supervisordpara isso. Observe que o Docker é um software relativamente opinativo e executar vários daemons em um contêiner não é considerado idiomático.

Se se trata apenas de depuração, não há problema. Apenas não corra openvpncom --daemonou --log. Ele escreverá no stdout (supostamente, embora eu não ficaria surpreso em ver o stderr). Isso é ótimo para depuração se você iniciá-lo 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 - o mesmo negócio. Se você iniciá-lo como um contêiner de segundo plano (desculpe minha imprecisão), a saída será capturada para docker logs. É a mesma técnica preferida pelos sistemas init modernos como o systemd (e o sistema de registro de "diário" do systemd).

Depois de configurar o daemon como deseja, você pode estar interessado em sistemas mais customizados para captura de logs, como as outras respostas.

O Docker possui drivers de log conectáveis, de acordo com a página de manual do docker logs. Há um driver "syslog" que diz que grava no syslog do host. Diz que docker logsnão vai funcionar, mas não espero que isso seja um problema para você.

AVISO: docker logsfunciona se você usar o driver de log journald. No entanto, nos padrões do Debian, suponho que isso causaria a perda de logs na reinicialização. Porque o Debian não configura um diário persistente. Porém, não é difícil mudar, se é isso que você deseja.

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

A pergunta "por que"

A questão é que os contêineres Docker não funcionam necessariamente da mesma forma que o sistema operacional em que se baseiam. Docker não é uma virtualização de sistema operacional como LXC, systemd-nspawnou 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 de servidores (atuais) são projetadas como uma combinação de vários programas em execução. Portanto, 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 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 :). Suspeito que muitos administradores de sistemas estariam mais interessados ​​em um mashup de LXC (contêineres de sistema operacional), com algo como NixOS para compartilhar pacotes entre contêineres; simplesmente ainda não foi escrito AFAIK. Ou apenas ummelhor LXC.