Estaba intentando acoplar (en Debian 8.2) un servidor OpenVPN (sí, lo sé, ya existen tales contenedores) pero algo salió mal dentro del contenedor y el servidor no pudo iniciarse.
Decidí inspeccionar los registros pero /var/log/syslog(los registros de OpenVPN aquí en mi máquina host) faltaban dentro del contenedor.
Pensé que rsyslogno estaba instalado y agregué su instalación antes de la instalación de OpenVPN al Dockerfile. Pero esto no tuvo ningún efecto, syslogtodavía faltaba.
Mi Dockerfile es:
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
Las preguntas son:
¿Por qué OpenVPN inicia sesión
syslogdespués de la instalación predeterminada en mi host Debian 8.2 y no lo hace dentro de un contenedor? No configuré nada en mi máquina host para forzar el registro de OpenVPNsyslog. Era un comportamiento predeterminado.¿Cómo configuro el registro del servidor OpenVPN que se ejecuta dentro de un contenedor acoplable?
Respuesta1
OpenVPN no comenzaría con ese Dockerfile porque no hay nada para iniciarlo :-). Su punto de entrada es sh; eso es todo lo que ejecutará.
Si desea iniciar dos demonios dentro de Docker, su punto de entrada debe ser un programa que inicie ambos. Mucha gente lo usa supervisordpara esto. Tenga en cuenta que Docker es un software relativamente obstinado y que ejecutar varios demonios en un contenedor no se considera idiomático.
Si se trata sólo de depurar, no hay problema. Simplemente no corras openvpncon --daemono --log. Escribirá en stdout (supuestamente, aunque no me sorprendería ver stderr). Esto es excelente para depurar si lo inicia manualmente. Verás todos los mensajes de registro inmediatamente en la terminal.
Si configura el punto de entrada e inicia manualmente el contenedor en modo interactivo, lo mismo. Si lo inicia como un contenedor en segundo plano (perdón por mi vaguedad), la salida se capturará para docker logs. Es la misma técnica favorecida por los sistemas de inicio modernos como systemd (y el sistema de registro de "diario" systemd).
Una vez que haya configurado el demonio como desea, es posible que le interesen sistemas más personalizados para capturar registros, como las otras respuestas.
Docker tiene controladores de registro conectables, según la página de manual de docker logs. Hay un controlador "syslog" que dice que escribe en el syslog del host. Dice que docker logsno funcionará, pero no espero que eso sea un problema para ti.
ADVERTENCIA: docker logsfunciona si utiliza el controlador de registro diario. Sin embargo, según los valores predeterminados de Debian, supongo que esto provocaría la pérdida de registros al reiniciar. Porque Debian no configura un diario persistente. Sin embargo, no es difícil cambiar, si eso es lo que quieres.
El otro controlador de registro que admite el docker logscomando se llama "archivo json". Supongo que será persistente, pero es posible que prefieras una de las otras soluciones.
La pregunta del "por qué"
El punto es que los contenedores Docker no necesariamente funcionan igual que el sistema operativo en el que se basan. Docker no es una virtualización del sistema operativo como LXC, systemd-nspawno una máquina virtual. Aunque Docker se derivó de LXC, fue diseñado específicamente para "contenedores de aplicaciones" que ejecutan un solo programa.
Las distribuciones de servidores (actuales) están diseñadas como una combinación de varios programas en ejecución. Por lo tanto, no puede tomarles un paquete y esperar que se comporte exactamente de la misma manera dentro de uno de estos contenedores de aplicaciones.
La comunicación con un demonio de registro es un gran ejemplo. No hay nada que vaya a cambiar, excepto que la gente se familiarizará más con el concepto de contenedores de aplicaciones. Y si eso es lo que realmente quieren usar :). Sospecho que muchos administradores de sistemas estarían más interesados en una combinación de LXC (contenedores de sistema operativo), con algo como NixOS para compartir paquetes entre contenedores; Simplemente aún no se ha escrito, AFAIK. O simplemente unmejor LXC.