为什么uWSGI无法在Docker中启动？

Question

我相对较不熟悉使用uWSGI服务Python应用程序，并且尝试使用附庸在Emperor模式下启动uWSGI进程，但是每次我尝试使用以下命令（以root身份）在Docker内部启动uWSGI时：

# /usr/local/bin/uwsgi --ini /etc/uwsgi/emperor.ini

我得到的回应是：

[uWSGI] getting INI configuration from /etc/uwsgi/emperor.ini
2.0.13.1

emperor.ini配置文件如下所示：

# files/etc/uwsgi/emperor.ini
[uwsgi]
emperor = /etc/uwsgi/apps-enabled
die-on-term = true
log-date = true

虽然唯一的附庸国的配置看起来像：

# files/etc/uwsgi/apps-enabled/application.ini
[uwsgi]
app_dir = /var/www/server
plugin = python
master = true
callable = app
chdir = %(app_dir)
mount = /=%(app_dir)/start.py
protocol = uwsgi
socket = :8079
uid = www-data
gid = www-data

buffer-size = 32768
enable-threads = true
single-interpreter = true
processes = 1

stats = 127.0.0.1:1717

（ 注意：上面的文件名是根据它们相对于Dockerfile的位置给出的，然后将它们复制到正确的位置，基本上删除了前缀files ）

目前，我正在使用的uWSGI Docker映像是基于ubuntu:trusty基本映像构建的（尽管我尝试了ubuntu:latest和alpine:latest并遇到了相同的问题），尽管我尝试使用以下命令启动uWSGI进程如前所述，Supervisor在直接从命令行运行时也会失败。 在Docker映像中，我正在使用pip安装uWSGI，但也尝试使用apt-get相同的结果。

我还应该提到我尝试了不同版本的uWSGI 2.0.13.1和1.9。

# Dockerfile
FROM ubuntu:trusty
MAINTAINER Sean Quinn "me@mail.com"

RUN apt-get update \
 && apt-get install -y \
      ack-grep git nano \
      supervisor \
      build-essential gcc python python-dev python-pip

RUN sed -i 's/^\(\[supervisord\]\)$/\1\nnodaemon=true/' /etc/supervisor/supervisord.conf \
 && sed -i 's/^\(\[supervisord\]\)$/\1\nloglevel=debug/' /etc/supervisor/supervisord.conf \
 && sed -i 's/^\(files = .*\)$/;\1/' /etc/supervisor/supervisord.conf \
 && sed -i 's/^\(\[include\]\)$/\1\nfiles = \/etc\/supervisor\/conf.d\/*.conf/' /etc/supervisor/supervisord.conf

ENV UWSGI_VERSION 2.0.13.1

RUN pip install uwsgi==${UWSGI_VERSION}

RUN mkdir -p /etc/uwsgi \
 && mkdir -p /etc/uwsgi/apps-available \
 && mkdir -p /etc/uwsgi/apps-enabled \
 && mkdir -p /var/log/uwsgi

COPY files/etc/supervisor/conf.d/uwsgi.conf /etc/supervisor/conf.d/uwsgi.conf
COPY files/etc/uwsgi/emperor.ini /etc/uwsgi/emperor.ini

VOLUME /etc/uwsgi/apps-enabled
VOLUME /var/www

ENTRYPOINT ["/usr/bin/supervisord"]
CMD ["-c", "/etc/supervisor/supervisord.conf"]

如前所述，受supervisord进程尝试使用以下监管器配置启动uWSGI进程。

# files/etc/supervisor/conf.d/uwsgi.conf
[program:uwsgi]
command=/usr/local/bin/uwsgi --ini /etc/uwsgi/emperor.ini
user=root

应用程序Python文件安装在/var/www的子目录中，应用程序uWSGI配置安装在/etc/uwsgi/apps-enabled 。

离奇的事情是，如果我安装上了一个新的Ubuntu虚拟机监控器和uWSGI（泊坞窗之外）的所有配置和文件的地方，我可以看到uWSGI正确处理的emperor.ini和阅读诸侯.ini文件。 我还没有尝试将nginx添加到公式中，因为我想确保uWSGI首先启动并正确读取配置文件。

有什么方法可以增加日志记录或确定为什么我只看到uWSGI二进制文件的版本号吗？ 就像uWSGI进程完全忽略了命令行选项。 我觉得我缺少一些显而易见的东西。

在此先感谢您提供任何帮助！

Answer 1

tl; dr不要将UWSGI_VERSION用作环境变量，显然它会强制uWSGI仅打印版本号而不是开始？

我相信我已经解决了自己的问题！

在Docker集线器上尝试了其他uWSGI映像后，我发现它们也遇到了相同的问题，因此我开始进一步研究可能的配置问题。 我尝试过更改权限等。

但是，我注意到，当我使用jpetazzo / nsenter进入正在运行的容器时，我看到了uWSGI启动（而不是像上面突出显示的那样简单地输出uWSGI版本信息）。 当使用docker docker exec进入时，uWSGI仅会打印版本信息。 周围多一点玩后，我发现，发出命令su -从容器内使用推出docker exec我再次看到uWSGI启动。

经过一番检查，我发现一个shell中的root用户与另一个shell中的root用户在环境变量方面存在一些差异。 它导致我进入UWSGI_VERSION环境变量，这似乎是罪魁祸首，因为删除UWSGI_VERSION允许uWSGI启动。

我将UWSGI_PIP_VERSION修改为使用UWSGI_PIP_VERSION作为环境变量来指示要安装的uWSGI的版本，这似乎是UWSGI_VERSION的安全替代方案。 因人而异。