Registrazione da contenitori docker multiprocess

Question

Sto utilizzando il metodo nginx del collegamento simbolico per il collegamento a/dev/stdout per tutti i file di registro che desidero vengano visualizzati nei "registri di docker", tuttavia questo non funziona.

Ho provato questo con un semplice cronjob in/etc/crontab, se è presente un collegamento simbolico (che punta a/dev/stdout) non scrive nulla (per quanto posso dire), ma se cancello il link simbolico e scrive nel file.

Anche se mi associo in/dev/stdout è echo'd indietro sulla riga di comando ma non si trova in 'registri di finestra mobile' ...

Domanda: Se questo lavoro? (Sembra funzionare con nginx). Altrimenti, come potrei ottenere i registri dai processi 'secondari' a comparire nei log della finestra mobile.

Per ref:

Nginx Dockerfile che mostra il metodo di link simbolici: https://github.com/nginxinc/docker-nginx/blob/a8b6da8425c4a41a5dedb1fb52e429232a55ad41/Dockerfile

Creato un rapporto ufficiale di bug per questo: https://github.com/docker/docker/issues/19616

mio Dockerfile:

FROM ubuntu:trusty 
#FROM quay.io/letsencrypt/letsencrypt:latest # For testing 

ENV v="Fri Jan 22 10:08:39 EST 2016" 

# Setup the cronjob 
ADD crontab /etc/crontab 
RUN chmod 600 /etc/crontab 

# Setup letsencrypt logs 
RUN ln -sf /dev/stdout /var/log/letsencrypt.log 
# Setup cron logs 
RUN ln -sf /dev/stdout /var/log/cron.log 
RUN ln -sf /dev/stdout /var/log/syslog 

# Setup keepalive script 
ADD keepalive.sh /usr/bin/keepalive.sh 
RUN chmod +x /usr/bin/keepalive.sh 

ENTRYPOINT /usr/bin/keepalive.sh 

Il file crontab:

* * * * * root date >> /var/log/letsencrypt.log 

keepalive.sh sceneggiatura

#!/bin/bash 

# Start cron 
rsyslogd 
cron 

echo "Keepalive script running!" 

while true; do 

    echo 'Sleeping for an hour...' 
    sleep 10 

done 

Answer 1

Il risultato finale è che il/dev/stdout per il cron job è stato indirizzato al diverso dispositivo.

/proc/self/fd/1 e avrebbe dovuto essere/proc/1/fd/1 perché poiché la finestra mobile si aspetta solo un processo in esecuzione, questo è l'unico stdout monitorato.

Quindi, una volta modificato i collegamenti simbolici in/proc/1/fd/1, avrebbe dovuto funzionare, tuttavia apparmor (sull'host) stava effettivamente negando le richieste (e ottenendo errori di autorizzazione quando faceva eco a/proc/1/fd/1) a causa del profilo predefinito della finestra mobile (che viene generato automaticamente ma può essere modificato con --security-opts).

Una volta superato l'ostacolo, tutto funziona!

Detto questo, dopo aver esaminato ciò che è necessario modificare in apparmor per consentire la richiesta richiesta, ho deciso di utilizzare il metodo mkfifo come mostrato di seguito.

Dockerfile

FROM ubuntu:latest 

ENV v="RAND-4123" 

# Run the wrapper script (to keep the container alive) 
ADD daemon.sh /usr/bin/daemon.sh 
RUN chmod +x /usr/bin/daemon.sh 

# Create the pseudo log file to point to stdout 
RUN mkfifo /var/log/stdout 
RUN mkfifo /var/log/stderr 

# Create a cronjob to echo into the logfile just created 
RUN echo '* * * * * root date 2>/var/log/stderr 1>/var/log/stdout' > /etc/crontab 

CMD "/usr/bin/daemon.sh" 

daemon.sh

#!/bin/bash 

# Start cron 
cron 

tail -qf --follow=name --retry /var/log/stdout /var/log/stderr 

Answer 2

Beh, è ​​stato menzionato nei commenti, ma per riferimento - ho trovato la soluzione migliore per docker la registrazione è in genere si basano sui meccanismi di registrazione 'standard' multi-sistema - in particolare syslog il più possibile.

Questo perché è possibile utilizzare il syslogd integrato nell'host o utilizzare logstash come syslogd. Ha un filtro integrato, ma in realtà che tende a soffrire un po 'da non essere sufficientemente flessibile, così invece io uso una rete TCP/ascoltatore UDP, e analizzare i log in modo esplicito - come indicato nella "When logstash and syslog goes wrong"

input { 
    tcp { 
    port => 514 
    type => syslog 
    } 
    udp { 
    port => 514 
    type => syslog 
    } 
} 

e poi filtrare il registro:

filter { 
    if [type] == "syslog" { 
    grok { 
     match => { "message" => "<%{POSINT:syslog_pri}>%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" } 
    } 
    syslog_pri { } 
    } 
} 

è quindi possibile alimentare questa logstash a elasticsearch - sia su un host remoto, contenitore locale o quello che sto facendo ora è una docker network con un multi-nodo elasticsearch esempio. (Ho eseguito il rollover da solo utilizzando un download e un file docker, ma sono abbastanza sicuro che esista anche un container autonomo).

output { 
    elasticsearch { 
     hosts => [ "es-tgt" ] 
    } 
} 

Il vantaggio è - finestra mobile consente di usare sia --link o --net per specificare il nome del vostro contenitore elasticsearch, così puoi semplicemente alias il config logstash per puntare al posto giusto. (Per esempio docker run -d --link my_es_container_name:es-tgt -p 514:514 -p 514:514/udp mylogstash o solo docker run --net es_net ....)

Il setup docker network è leggermente più complicata, in quanto è necessario impostare un negozio di valori-chiave (io ho usato etcd, ma sono disponibili altre opzioni). Oppure puoi fare qualcosa come Kubernetes.

E quindi utilizzare kibana per visualizzare, esponendo nuovamente la porta kibana, ma inoltrandosi alla rete elasticsearch per parlare con il cluster.

Ma una volta configurata, è possibile configurare nginx su log to syslog e qualsiasi altra cosa si desidera acquisire regolarmente i risultati della registrazione. Il vero vantaggio IMO è che si sta utilizzando un singolo servizio per la registrazione, uno che può essere ridimensionato (grazie alla rete/containerizzazione) in base alle proprie esigenze.