La aplicación Python no imprime nada cuando se ejecuta separada en la ventana acoplable

Tengo una aplicación Python (2.7) que se inicia en mi dockerfile:

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

main.py imprime algunas cadenas cuando se inicia y luego entra en un bucle:

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

Mientras inicio el contenedor con el indicador -it, todo funciona como se esperaba:

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

Y puedo ver la misma salida a través de registros más tarde:

$ docker logs myapp
> App started

Si intento ejecutar el mismo contenedor con el indicador -d, el contenedor parece comenzar normalmente, pero no puedo ver ningún resultado:

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

Pero el contenedor todavía parece funcionar;

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

Adjuntar tampoco muestra nada:

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

¿Alguna idea de qué va mal? ¿"Print" se comporta de manera diferente cuando se ejecuta en segundo plano?

Versión de 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 encontré una solución para ver la salida de Python cuando se ejecuta daemonized en Docker, gracias a @ahmetalpbalkan en GitHub . Respondiendo aquí yo mismo para mayor referencia:

Usar salida sin búfer con

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

en vez de

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

resuelve el problema; Puede ver la salida (stderr y stdout) a través de

docker logs myapp

¡ahora!

En mi caso, ejecutar Python con -uno cambió nada. Sin embargo, el truco fue establecer PYTHONUNBUFFERED=0como variable de entorno:

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

Para mí es una característica, no un error. Sin un pseudo-TTY no hay nada a lo que stdout. Entonces, una solución simple es asignar un pseudo-TTY para su contenedor en ejecución con:

$ docker run -t ...

Vea este artículo que explica la razón detallada del comportamiento:

Normalmente hay tres modos de almacenamiento en búfer:

• Si un descriptor de archivo no tiene búfer, no se produce ningún búfer, y las llamadas a funciones que leen o escriben datos ocurren inmediatamente (y se bloquearán).
• Si un descriptor de archivo está completamente protegido, entonces se usa un buffer de tamaño fijo, y las llamadas de lectura o escritura simplemente leen o escriben desde el buffer. El búfer no se vacía hasta que se llena.
• Si un descriptor de archivo tiene un buffer de línea, entonces el buffer espera hasta que vea un carácter de nueva línea. Por lo tanto, los datos se almacenarán en el búfer y en el búfer hasta que se vea un \ n, y luego todos los datos que se almacenan en el búfer se vacían en ese momento. En realidad, generalmente hay un tamaño máximo en el búfer (al igual que en el caso de búfer completo), por lo que la regla es en realidad más como "búfer hasta que se ve un carácter de nueva línea o se encuentran 4096 bytes de datos, lo que ocurra primero".

Y GNU libc (glibc) usa las siguientes reglas para el almacenamiento en búfer:

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

Entonces, si se usa -t, desde el documento de docker , asignará un pseudo-tty, luego se stdoutconvierte line-buffered, por lo que docker run --name=myapp -it myappimagepodría ver la salida de una línea.

Y, si solo se usa -d, no se asignó tty, entonces, stdoutes decir fully-buffered, una línea App startedseguramente no puede vaciar el búfer.

Entonces, el uso -dtde make stdout line bufferedo complemento -uen python a flush the bufferes la forma de solucionarlo.

Si desea agregar su salida de impresión a su salida de Flask cuando se está ejecutando docker-compose up, agregue lo siguiente a su archivo de composición docker.

web:
  environment:
    - PYTHONUNBUFFERED=1

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

Puede ver registros en la imagen separada si cambia printa 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 todavía no he visto esta respuesta:

También puede eliminar stdout después de imprimir en él:

import time

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

Intente agregar estas dos variables de entorno a su solución PYTHONUNBUFFERED=1yPYTHONIOENCODING=UTF-8

Como solución rápida, intente esto:

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

Esto funciona para mí cuando me encuentro con los mismos problemas. Pero, para ser honesto, no sé por qué ocurre este error.

Tuve que usar PYTHONUNBUFFERED=1en mi archivo docker-compose.yml para ver la salida de django runserver.

Por lo general, lo redirigimos a un archivo específico (montando un volumen desde el host y escribiéndolo en ese archivo).

Agregar un tty usando -t también está bien. Debe recogerlo en los registros de la ventana acoplable.

Utilizando salidas de registro grandes, no tuve ningún problema con el almacenamiento del búfer sin ponerlo en el registro de los acopladores.

Si no está usando docker-composey simplemente es normal docker, puede agregar esto a su Dockerfilehost de una aplicación de matraz

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

CMD [ "flask", "run" ]