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?
Docker, Django in production
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
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.
Ich würde es in zwei separaten Containern laufen lassen. Name des Clusters und der Secret-Key der Django-Umgebung müssen identisch sein.
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
Danke.
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 (...)"
-
- 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 (...)"
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
- noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
Gruß, noisefloor
+1 - mache ich auch so.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.
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 übersichtlicherAls ich gesehen habe, wie viele CLI-Parameter uWSGI hat, hatte ich schon keine Lust mehr.
Gruß, noisefloor
-
- 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?
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 (...)"