Warum startet uWSGI nicht in Docker?

Question

Ich bin relativ neu mit uWSGI Python-Anwendungen zu dienen und ich versuche, einen uWSGI-Prozess im Kaiser-Modus mit einem Vasallen zu starten, aber jedes Mal versuche ich uWSGI innerhalb von Docker mit dem folgenden Befehl zu starten (wie root):

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

Was ich als Antwort erhalten, ist:

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

Die emperor.ini Konfigurationsdatei wie folgt aussieht:

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

Während der einzige Konfiguration Vasall wie folgt aussieht:

# 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 

(NB: Die oben genannten Dateinamen in Bezug auf gegeben werden, wo sie auf die Dockerfile leben relativ, die dann im Grunde wird sie an die richtigen Stellen zu kopieren, das Entfernen von Präfix files)

Derzeit ist das uwsgi Docker Bild, das ich gebaut bin mit aus einem ubuntu:trusty Basisbild (obwohl ich ubuntu:latest und alpine:latest und traf das gleiche Problem) ausprobiert habe, und obwohl ich versuche, den uwsgi Prozess zu starten mit Vorgesetzten, wie vorher erwähnt y, schlägt es auch fehl, wenn es direkt von der Befehlszeile ausgeführt wird. Im Docker Image installiere ich uWSGI mit pip, habe aber auch versucht, apt-get mit dem gleichen Ergebnis zu verwenden.

Ich sollte auch erwähnen, dass ich verschiedene Versionen von uWSGI 2.0.13.1 und 1.9.omething mit dem gleichen Ergebnis ausprobiert habe, wenn das hilft.

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

Wie erwähnt werden die supervisord Prozess versucht, den uwsgi Prozess unter Verwendung der folgenden Supervisor Konfiguration zu starten.

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

Die Anwendung Python-Dateien werden in einem Unterverzeichnis von /var/www montiert und die Anwendung uwsgi Konfiguration wird in /etc/uwsgi/apps-enabled montiert.

Die bizarre Sache ist, wenn ich installieren Supervisor und uwsgi auf einer neuen Ubuntu VM (außerhalb von Docker) mit allen der Konfiguration und Dateien in Ort, den ich sehen kann uwsgi richtig die emperor.ini verarbeiten und die Vasallen .ini Dateien lesen. Ich habe noch nicht versucht, nginx in die Gleichung einzufügen, weil ich sicherstellen möchte, dass uWSGI in erster Linie korrekt Konfigurationsdateien startet und liest.

Gibt es eine Möglichkeit, die Protokollierung zu erhöhen oder festzustellen, warum ich nur sehe, was die Versionsnummer der uWSGI-Binärdatei zu sein scheint? Es ist so, als ob der uWSGI-Prozess Befehlszeilenoptionen komplett ignoriert. Ich fühle mich, als würde ich etwas vermissen, was offensichtlich sein sollte.

Vielen Dank im Voraus für jede Hilfe, die jemand geben kann!

Answer 1

tl; dr nicht UWSGI_VERSION als Umgebungsvariable verwenden, scheinbar zwingt es uwsgi nur statt Anfang der Versionsnummer drucken?

Ich glaube, ich habe mein eigenes Problem gelöst!

Nachdem ich mit anderen uWSGI-Images auf Docker's Hub experimentiert hatte, stellte ich fest, dass sie auch auf dasselbe Problem stießen, also begann ich, weitere mögliche Konfigurationsprobleme zu untersuchen. Ich habe versucht, Berechtigungen unter anderem zu ändern.

Ich bemerkte jedoch, dass, wenn ich jpetazzo/nsenter verwendet, um den laufenden Container, den ich sah UWSGI starten (anstatt einfach die uWSGI Versionsinformationen wie oben markiert). Bei der Eingabe mit docker exec würde uWSGI nur die Versionsinformationen drucken. Nachdem ich ein bisschen mehr herumgespielt hatte, entdeckte ich, dass ich den Befehl su - aus dem Container, der unter Verwendung von docker exec gestartet wurde, wieder sah, wie uWSGI gestartet wurde.

Nach einigen Inspektionen entdeckte ich mehrere Unterschiede in den Umgebungsvariablen zwischen dem root Benutzer in einer Shell gegenüber einer anderen. Es führte mich zur UWSGI_VERSION Umgebungsvariable, die anscheinend der Übeltäter war, weil das Entfernen von UWSGI_VERSION erlaubte uWSGI zu starten.

Ich habe meine Dockerfile geändert, um UWSGI_PIP_VERSION stattdessen als Umgebungsvariable zu verwenden, um die Version von uWSGI zu installieren, die eine sichere Alternative zu UWSGI_VERSION zu sein scheint. YMMV.