在使用docker/fig运行Django dev服务器时，为什么会隐藏一些日志输出？

我正在编写一个Dockerfile，它需要在

CMD

指令中运行多个命令，我认为正确的方法是运行一个shell脚本，通过

exec

执行主守护进程。不幸的是，作为这个过程的一部分，我的一些输出（stdout？stderr？我不知道，我也不知道如何找到）丢失了

以下是shell脚本：

#!/bin/sh

python manage.py migrate
exec python manage.py runserver 0.0.0.0:8000

其思想是，

migrate

命令只运行一次，并显示其输出，然后，

runserver

命令应该接管，容器运行直到该进程退出

实际问题是，

migrate

的输出显示正确，但是

runserver

的即时输出没有显示。奇怪的是，

runserver

的后续请求日志显示得很好

为了澄清，以下是我预期的结果：

[...]
No migrations to apply.
[...]
Starting development server at http://0.0.0.0:8000/
Quit the server with CONTROL-C.
[21/Jan/2015 16:27:06] "GET / HTTP/1.1" 200 15829

以下是我从图中得到的信息：

[...]
No migrations to apply.
[...]
[21/Jan/2015 16:27:06] "GET / HTTP/1.1" 200 15829

我甚至不确定这是谁的错。

runserver

命令是否会根据其运行方式更改其输出？这是

exec

的问题吗？是docker/fig吗

作为一个附加数据点，我注意到，当使用

fig run web

运行容器时，我确实获得了所有输出，但当我使用

fig up

时，我没有得到所有输出，但我不明白这是如何不同或相关的

---

注意：对于标签垃圾邮件，我很抱歉，一旦我知道实际原因，我会减少标签。

我今天使用docker composer发现了这个老问题。Python日志模块检查输出是否为终端，因此需要向服务添加

tty:true

。例如：

version: '2'
services:
  django:
    tty: true
    command: python -u manage.py runserver 0.0.0.0:8080
    ports:
    - "8080:8080"

---

您可以手动重定向输出，以后再使用追加重定向。@Paul您的意思是什么？我没有使用任何

>

附加重定向。为什么在每个runserver之前运行migrate？您可以将

django admin.py

设置为入口点，并像

fig run migrate

@KrzysztofSzularz那样运行迁移这是一个面向非技术人员的开发环境设置。源代码将通过主机共享卷连接。我不能期望他们在每次迁移更改时键入

fig run migrate

（假设他们不知道迁移是什么，也不知道何时提交了新迁移，也不关心）。设置只需始终在

fig up

上运行。现在无法测试此功能，但听起来似乎是一个非常合理的解释，因此感谢您在此处发布您的发现！非常适合我，谢谢。这个答案应该被接受。接受，基于罗宾的确认。