O aplicativo Python não imprime nada ao executar desanexado na janela de encaixe

Eu tenho um aplicativo Python (2.7) iniciado no meu dockerfile:

CMD ["python","main.py"]

main.py imprime algumas strings quando é iniciado e entra em um loop depois:

print "App started"
while True:
    time.sleep(1)

Desde que inicie o contêiner com o sinalizador -it, tudo funcionará conforme o esperado:

$ docker run --name=myapp -it myappimage
> App started

E eu posso ver a mesma saída via logs depois:

$ docker logs myapp
> App started

Se eu tentar executar o mesmo contêiner com o sinalizador -d, o contêiner parece iniciar normalmente, mas não consigo ver nenhuma saída:

$ docker run --name=myapp -d myappimage
> b82db1120fee5f92c80000f30f6bdc84e068bafa32738ab7adb47e641b19b4d1
$ docker logs myapp
$ (empty)

Mas o contêiner ainda parece estar funcionando;

$ docker ps
Container Status ...
myapp     up 4 minutes ... 

Anexar também não exibe nada:

$ docker attach --sig-proxy=false myapp
(working, no output)

Alguma idéia que está dando errado? "Imprimir" se comporta de maneira diferente quando executado em segundo plano?

Versão do Docker:

Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.4.2
Git commit (client): a8a31ef
OS/Arch (client): linux/arm
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.4.2
Git commit (server): a8a31ef

Finalmente, encontrei uma solução para ver a saída do Python ao executar daemon no Docker, graças a @ahmetalpbalkan no GitHub . Respondendo aqui pessoalmente para mais referências:

Usando saída sem buffer com

CMD ["python","-u","main.py"]

ao invés de

CMD ["python","main.py"]

resolve o problema; você pode ver a saída (stderr e stdout) via

docker logs myapp

agora!

No meu caso, rodar Python com -unão mudou nada. O que fez o truque, no entanto, foi definir PYTHONUNBUFFERED=0como variável de ambiente:

docker run --name=myapp -e PYTHONUNBUFFERED=0 -d myappimage

Para mim, é um recurso, não um bug. Sem um pseudo-TTY, não há nada a se desviar. Portanto, uma solução simples é alocar um pseudo-TTY para seu contêiner em execução com:

$ docker run -t ...

Consulte este artigo que explica os motivos detalhados do comportamento:

Normalmente, existem três modos de buffer:

• Se um descritor de arquivo não for armazenado em buffer, não ocorre armazenamento em buffer, e as chamadas de função que lêem ou gravam dados ocorrem imediatamente (e serão bloqueadas).
• Se um descritor de arquivo for totalmente armazenado em buffer, é usado um buffer de tamanho fixo e as chamadas de leitura ou gravação simplesmente leem ou gravam no buffer. O buffer não é liberado até ficar cheio.
• Se um descritor de arquivo estiver em buffer de linha, o buffer aguardará até que ele veja um caractere de nova linha. Portanto, os dados serão armazenados em buffer e armazenados em buffer até que a \ n seja visto e, em seguida, todos os dados armazenados em buffer serão liberados nesse momento. Na realidade, normalmente há um tamanho máximo no buffer (assim como no caso com buffer total), então a regra é mais como "buffer até que um caractere de nova linha seja visto ou 4096 bytes de dados sejam encontrados, o que ocorrer primeiro".

E o GNU libc (glibc) usa as seguintes regras para armazenar em buffer:

Stream               Type          Behavior
stdin                input         line-buffered
stdout (TTY)         output        line-buffered
stdout (not a TTY)   output        fully-buffered
stderr               output        unbuffered

Portanto, se usado -t, a partir do documento docker , ele alocará uma pseudo-tty e stdoutse tornará line-buffered, assim,docker run --name=myapp -it myappimage poderia ver a saída de uma linha.

E, se o uso apenas -d, não tty foi alocado, então, stdouté fully-buffered, uma linha App startedcertamente não é capaz de liberar o buffer.

Em seguida, use -dta make stdout line bufferedou add -uem python para flush the bufferé a maneira de corrigi-lo.

Se você deseja adicionar sua saída de impressão à saída do Flask durante a execução docker-compose up, adicione o seguinte ao seu arquivo de composição do docker.

web:
  environment:
    - PYTHONUNBUFFERED=1

https://docs.docker.com/compose/environment-variables/

Você pode ver os logs na imagem desanexada se mudar printpara logging.

main.py:

import time
import logging
print "App started"
logging.warning("Log app started")
while True:
    time.sleep(1)

Dockerfile:

FROM python:2.7-stretch
ADD . /app
WORKDIR /app
CMD ["python","main.py"]

Como ainda não vi essa resposta:

Você também pode liberar o stdout após imprimir nele:

import time

if __name__ == '__main__':
    while True:
        print('cleaner is up', flush=True)
        time.sleep(5)

Tente adicionar essas duas variáveis ​​de ambiente à sua solução PYTHONUNBUFFERED=1ePYTHONIOENCODING=UTF-8

Como uma solução rápida, tente o seguinte:

from __future__ import print_function
# some code
print("App started", file=sys.stderr)

Isso funciona para mim quando encontro os mesmos problemas. Mas, para ser sincero, não sei por que esse erro ocorre.

Eu tive que usar PYTHONUNBUFFERED=1no meu arquivo docker-compose.yml para ver a saída do django runserver.

Geralmente, nós o redirecionamos para um arquivo específico (montando um volume do host e gravando-o nesse arquivo).

Adicionar um tty usando -t também é bom. Você precisa buscá-lo nos logs da janela de encaixe.

Usando grandes saídas de log, não tive nenhum problema com o armazenamento de buffer sem colocá-lo no log de janelas de encaixe.

Se você não estiver usando docker-composee apenas normal docker, adicione-o ao seu Dockerfileque está hospedando um aplicativo de balão

ARG FLASK_ENV="production"
ENV FLASK_ENV="${FLASK_ENV}" \
    PYTHONUNBUFFERED="true"

CMD [ "flask", "run" ]