我有一个Python(2.7)应用程序,它在我的dockerfile中启动:

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

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 ... 

Attach也不显示任何东西:

$ 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

当前回答

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

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不适合我。

如果你想在运行docker-compose up时将打印输出添加到Flask输出中,请将以下内容添加到docker compose文件中。

web:
  environment:
    - PYTHONUNBUFFERED=1

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

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

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

CMD [ "flask", "run" ]

如果有人使用conda运行python应用程序,你应该在命令中添加——no-capture-output,因为conda默认情况下会缓冲到stdout。

ENTRYPOINT ["conda", "run", "--no-capture-output", "-n", "my-app", "python", "main.py"]

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

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来刷新缓冲区是修复它的方法。