最后，我找到了一个在Docker中运行daemonized时查看Python输出的解决方案，这要感谢GitHub上的@ ahmetalbalkan。我自己在这里回答，以供进一步参考:

使用无缓冲输出

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

而不是

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

解决问题;您现在可以通过via看到输出(包括stderr和stdout)

docker logs myapp

为什么-u ref

- print is indeed buffered and docker logs will eventually give you that output, just after enough of it will have piled up
- executing the same script with python -u gives instant output as said above
- import logging + logging.warning("text") gives the expected result even without -u

python -u ref. > python——help | grep——-u

-u     : force the stdout and stderr streams to be unbuffered;

如果将打印更改为日志记录，则可以在分离映像上看到日志。

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"]

在Django应用程序中使用python manage.py runserver时，添加环境变量PYTHONUNBUFFERED=1可以解决我的问题。打印('helloworld'， flush=True)也适用于我。

但是，python -u不适合我。

因为我还没有看到这个答案:

你也可以在输出stdout后刷新它:

import time

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

如果你不使用docker-compose，而只是普通的docker，你可以把它添加到你的Dockerfile中，这是一个flask应用程序

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

CMD [ "flask", "run" ]

请看这篇文章，详细解释了这种行为的原因:

There are typically three modes for buffering: If a file descriptor is unbuffered then no buffering occurs whatsoever, and function calls that read or write data occur immediately (and will block). If a file descriptor is fully-buffered then a fixed-size buffer is used, and read or write calls simply read or write from the buffer. The buffer isn’t flushed until it fills up. If a file descriptor is line-buffered then the buffering waits until it sees a newline character. So data will buffer and buffer until a \n is seen, and then all of the data that buffered is flushed at that point in time. In reality there’s typically a maximum size on the buffer (just as in the fully-buffered case), so the rule is actually more like “buffer until a newline character is seen or 4096 bytes of data are encountered, whichever occurs first”.

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, from docker document，它将分配一个伪tty，然后stdout变成行缓冲，因此docker run——name=myapp -it myappimage可以看到一行输出。

而且，如果只使用-d，没有分配tty，那么，stdout是完全缓冲的，一行App启动肯定不能刷新缓冲区。

然后，使用-dt使stdout行缓冲或在python中添加-u来刷新缓冲区是修复它的方法。