Docker, Django in production

Django, Flask, Bottle, WSGI, CGI…
Antworten
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Hallo,

ich möchte meine erste Djangoapp per Docker in production ausliefern und bin mir noch unsicher.

Die App nutzt Django-Q. Muss das in einen separaten Container, um dann mit docker-compose ausgeführt zu werden oder kommt das alles in einen?

Nutzt man nativ uWSGI für production?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Benutzeravatar
sparrow
User
Beiträge: 4164
Registriert: Freitag 17. April 2009, 10:28

Wenn du in den Issues in dem Github-Projekt schaust, wirst du dort eine Diskussion darüber finden.
Ich würde es in zwei separaten Containern laufen lassen. Name des Clusters und der Secret-Key der Django-Umgebung müssen identisch sein.
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Danke.
sparrow hat geschrieben: Donnerstag 13. Mai 2021, 17:39 (...)
Name des Clusters und der Secret-Key der Django-Umgebung müssen identisch sein.
Das heißt genau was? Wie stelle ich das sicher?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Benutzeravatar
sparrow
User
Beiträge: 4164
Registriert: Freitag 17. April 2009, 10:28

Indem du die Dokumentation von Django und Django-Q liest. Dann wirst du sehen, dass es eine Datei namens "settings.py" gibt, in der man sowohl den Q_CLUSTER als auch einen secret_key definiert.
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Das ist mir bewusst, aber ich verstehe nicht, warum du das im Zuge von Docker erwähnst? Muss ich mit den Variablen etwas besonderes machen?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
nezzcarth
User
Beiträge: 1632
Registriert: Samstag 16. April 2011, 12:47

naheliegend hat geschrieben: Donnerstag 13. Mai 2021, 17:11 Nutzt man nativ uWSGI für production?
Ich denke schon. Persönlich verwende ich dafür lieber jedoch gunicorn (hinter einem Reverse Proxy). Das läuft bei mir sehr stabil und ich kann nichts Negatives darüber sagen.

Als ich gesehen habe, wie viele CLI-Parameter uWSGI hat, hatte ich schon keine Lust mehr. (Ich weiß, dass das keine technische Begründung, sondern wohl nur eine Frage des Design(geschmack)s ist … Das wirkte so, als hätte jemand die Optionen einer Konfigurationsdatei komplett auf Argumente gemapped. ).

Code: Alles auswählen

$ uwsgi -h | grep -c "^\s*\-\-"
915
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Persönlich verwende ich dafür lieber jedoch gunicorn (hinter einem Reverse Proxy). Das läuft bei mir sehr stabil und ich kann nichts Negatives darüber sagen.
+1 - mache ich auch so.
Als ich gesehen habe, wie viele CLI-Parameter uWSGI hat, hatte ich schon keine Lust mehr.
Ging mir genau so. gunicorn ist da deutlich übnersichtlicher. Wobei man ja dazu sagen muss, da uwsgi auch Ruby und Perl Applikationen ausliefern kann und dafür ein Teil der Parameter ist. Macht's für Python-Programmierer aber nicht übersichtlicher ;-)

Gruß, noisefloor
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

Okey. Ob Gunicorn oder uWSGI wäre meine nächste Frage gewesen, die ja schon beantwortet wurde.

Was ich mich noch frage ist, welches Pythonimage man denn für den Container der App benutzen sollte? Also Alpine, Buster, eine Slimvariante oder doch eine Größere?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Antworten