Приложение Python ничего не печатает при запуске отсоединенного в докере

У меня есть приложение Python (2.7), которое запускается в моем файле docker:

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

main.py печатает некоторые строки при запуске и затем переходит в цикл:

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

Пока я запускаю контейнер с флагом -it, все работает так, как ожидалось:

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

И я могу увидеть тот же вывод через журналы позже:

$ docker logs myapp
> App started

Если я пытаюсь запустить тот же контейнер с флагом -d, контейнер, похоже, запускается нормально, но я не вижу никакого вывода:

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

Но контейнер все еще работает,

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

В приложении ничего не отображается:

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

Любые идеи, что происходит не так? Выполняется ли "печать" по-разному при работе в фоновом режиме?

Версия для докеров:

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

Ответ 1

Наконец, я нашел решение увидеть вывод Python при запуске demonized в Docker, благодаря @ahmetalpbalkan на GitHub. Отвечая на него здесь для дальнейших ссылок:

Использование небуферизованного вывода с

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

вместо

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

решает проблему; вы можете видеть выходные данные (как stderr, так и stdout) через

docker logs myapp

сейчас

Ответ 2

В моем случае запуск Python с -u ничего не изменил. Однако фокус в том, чтобы установить PYTHONUNBUFFERED=0 в качестве переменной среды:

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

Ответ 3

Для меня это особенность, а не ошибка. Без псевдо-TTY нет ничего общего с stdout. Поэтому простым решением является выделение псевдотематического TTY для запускаемого контейнера:

$ docker run -t ...

Ответ 4

См. эту статью, в которой подробно объясняется причина такого поведения:

Обычно существует три режима буферизации:

Если дескриптор файла не буферизован, то буферизация вообще не происходит, и вызовы функций, которые читают или записывают данные, происходят немедленно (и будут блокироваться).

Если файловый дескриптор полностью буферизован, то используется буфер фиксированного размера, а вызовы чтения или записи просто читают или пишут из буфера. Буфер не очищается, пока не заполнится.

Если файловый дескриптор буферизирован строкой, то буферизация ждет, пока не увидит символ новой строки. Таким образом, данные будут буферизоваться и буферизоваться до тех пор, пока не будет замечено \n, а затем все данные, которые буферизуются, сбрасываются в этот момент времени. В действительности обычно существует максимальный размер буфера (как и в случае с полной буферизацией), поэтому правило на самом деле больше похоже на "буфер до тех пор, пока не появится символ новой строки или не встретится 4096 байт данных, в зависимости от того, что произойдет первым".

А GNU libc (glibc) использует следующие правила для буферизации:

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

Таким образом, если использовать -t из документа докера, он выделит псевдотетти, тогда stdout станет line-buffered, поэтому docker run --name=myapp -it myappimage сможет увидеть однострочный вывод.

И, если просто использовать -d, tty не был выделен, то stdout - это fully-buffered, одна строка App started наверняка не сможет очистить буфер.

Затем используйте -dt для make stdout line buffered или добавьте -u в python к flush the buffer - это способ исправить это.

Ответ 5

В качестве быстрого исправления попробуйте следующее:

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

Это работает для меня, когда я сталкиваюсь с теми же проблемами. Но, честно говоря, я не знаю, почему эта ошибка происходит.

Ответ 6

Вы можете увидеть журналы на отдельном изображении, если изменить print на 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"]

Ответ 7

Обычно мы перенаправляем его в определенный файл (монтируя том с хоста и записывая его в этот файл).

Добавление tty с использованием -t тоже подойдет. Вы должны поднять это в журналах докера.

Используя большие выходы журнала, у меня не было никаких проблем с хранением буфера все, не помещая это в журнал докеров.