为什么uWSGI无法在Docker中启动？
我使用uWSGI服务Python应用程序相对来说比较新，我试图用一个vassal在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.iniconfiguration文件如下所示：
# files/etc/uwsgi/emperor.ini [uwsgi] emperor = /etc/uwsgi/apps-enabled die-on-term = true log-date = true
而唯一的封臣的configuration看起来像：
# 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基础镜像（尽pipe我已经尝试过ubuntu:latest和alpine:latest并遇到同样的问题），尽pipe我正在尝试启动uWSGI进程如前所述，当从命令行直接运行时，它也会失败。 在Docker镜像中，我使用pip安装uWSGI，但也尝试使用apt-get相同的结果。
我还应该提到，我已经尝试了不同版本的uWSGI 2.0.13.1和1.9.something具有相同的结果，如果有帮助。
# 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进程尝试使用以下超级用户configuration启动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的子目录中，应用程序uWSGIconfiguration安装到/etc/uwsgi/apps-enabled 。
奇怪的是，如果我在一个新的Ubuntu VM（Docker外部）上安装了supervisor和uWSGI，并且configuration和文件都已经到位，我可以看到uWSGI正确地处理了emperor.ini并读取了vassal .ini文件。 我还没有尝试添加nginx到公式中，因为我想确保uWSGI正在首先正确地启动和正确读取configuration文件。
有没有什么办法来增加日志logging或确定为什么我只看到什么似乎是uWSGI二进制文件的版本号？ 这就像uWSGI过程完全忽略了命令行选项。 我觉得我失去了一些显而易见的东西。
预先感谢任何人都可以给的帮助！
tl; dr不使用
UWSGI_VERSION作为环境variables，显然它迫使uWSGI只打印版本号而不是开始？
我相信我解决了我自己的问题！
在Docker集线器的其他uWSGI镜像上进行实验后，我发现他们也遇到了同样的问题，所以我开始进一步研究可能的configuration问题。 我试图改变其他的权限。
但是我注意到当我使用jpetazzo / nsenter进入正在运行的容器时，我看到uWSGI启动了（而不是简单地输出上面突出显示的uWSGI版本信息）。 使用docker docker execinput时，uWSGI只会打印版本信息。 在玩了一会之后，我发现从使用docker docker exec I发起的容器内发出命令su -又一次看到了uWSGI的启动。
经过一番检查之后，我发现一个shell中的root用户与另一个shell中的环境variables之间存在一些差异。 它引导我到UWSGI_VERSION环境variables，这似乎是罪魁祸首，因为删除UWSGI_VERSION允许uWSGI启动。
我修改我的Dockerfile来使用UWSGI_PIP_VERSION来代替作为环境variables来指示要安装的uWSGI的版本，这似乎是UWSGI_VERSION一个安全替代。 因人而异。