Hallo.
Ich bin inzwischen noch immer kein guter, aber ein weniger schlechter Django Programmierer und deswegen geht es jetzt in Richtung Deployment Situation testen/kennenlernen. An sich funktioniert auch Alles, aber ein paar (Verständnis)Fragen habe ich doch noch:
Mein Server Setup: nginx + Gunicorn + Postgres + Django/Python3
Mein Dev Setup: Django/Python3 runserver + sqlite
(Und ja ich weiß, man sollte beim entwickeln und Deployment den selben DB-Server haben. Das habe ich auch, da ich noch mal nen Test-Zwischenschritt über eine VM gehe, die quasi dem Setup des Servers entspricht. Aber das ignorieren wir für die folgenden Fragen bitte einfach.)
Meine Fragen:
1. Ich "synchronisiere" per git. Sehe ich es richtig, dass ich (neben Dateien wie settings.py) ALLE __pychache__ Ordner und vor allem auch die "migrations" Ordner nicht mit "synchronisiere", da diese ja den Datenbank-Stand meiner Entwicklungsumgebung widerspiegeln?
2. Aktualisierungen mit Gunicorn:
2.a. Wenn ich eine Datei (z.b. views.py) hochlade, übernimmt Gunicorn diese erst nach einem Gunicorn-Neustar. Ein klassisches "reload" (nicht restart) scheint Gunicorn nicht zu kennen, oder?
2.b. Was passiert wenn ich auf dem Server/Gunicorn ein "migrate" ausführe? Ist dann die Seite nur kurz nicht erreichbar? Werden alle Sessions gekillt?
2.c. Was passiert wenn ein User gerade nen Kommentar o.ä. schreibt während die DB (migrate) aktualisiert wird? Gibts es da Probleme? Managed Django das? Oder Postgres selbst?
Im Moment ist ja Alles einfach, da ich der einzige bin der auf der Website rumsurft. Ich will aber vermeiden, dass es Fehler gibt, wenn mal 100 Leute darauf gleichzeitig damit interagieren.
Django Deployment - Gunicorn, DB Aktualisierungen, Verständnisfragen
__pycache__ nicht migrations natürlich schon. Die Migrations benötigst du schliesslich um die Datenbank zu erstellen und das Schema verändern.SnakeBite hat geschrieben:1. Ich "synchronisiere" per git. Sehe ich es richtig, dass ich (neben Dateien wie settings.py) ALLE __pychache__ Ordner und vor allem auch die "migrations" Ordner nicht mit "synchronisiere", da diese ja den Datenbank-Stand meiner Entwicklungsumgebung widerspiegeln?
Doch.2. Aktualisierungen mit Gunicorn:
2.a. Wenn ich eine Datei (z.b. views.py) hochlade, übernimmt Gunicorn diese erst nach einem Gunicorn-Neustar. Ein klassisches "reload" (nicht restart) scheint Gunicorn nicht zu kennen, oder?
Das Datenbankschema wird verändert, ggfs. auch Daten verändert wenn du eine Datamigration hast. Die Seite kann dabei grundsätzlich erreichbar bleiben. Was konkret passiert hängt natürlich davon ab was die Migration macht.2.b. Was passiert wenn ich auf dem Server/Gunicorn ein "migrate" ausführe? Ist dann die Seite nur kurz nicht erreichbar? Werden alle Sessions gekillt?
Die Frage zu Sessions macht überhaupt keinen Sinn. Was auch immer du glaubst zu Sessions zu wissen ist vollkommen falsch, du solltest dich mit deren Grundlagen nochmal beschäftigen.
Nichts. Nein. Nein. Nein. Du entwickelst Web Anwendungen da sollte man sich mit den absoluten Grundlagen mal auseinandersetzen und halbwegs wissen was das Web ist und wie es funktioniert. Konkret hier was HTTP ist und wie es funktioniert. Selbst mit einem oberflächlichen Verständnis von HTTP würde sich die Frage nicht stellen.2.c. Was passiert wenn ein User gerade nen Kommentar o.ä. schreibt während die DB (migrate) aktualisiert wird? Gibts es da Probleme? Managed Django das? Oder Postgres selbst?
Zu 1.: es sollten keine Cache-Dateien versioniert werden, ebensowenig konkrete Zugangsdaten, Datenbanken, etc. Das migrations-Verzeichnis enthält aber keine Datenbankinhalte sondern die Struktur der Datenbank. Darauf baut ja auch Deine restliche Application auf.
2a. Ein automatisches reload möchte man eigentlich nicht bei einem Produktivsystem, weil nie garantiert werden kann, dass danach noch ein konsistenter Zustand existiert.
2b. Was bei einer Datenbankmigration geschieht, kann man so pauschal nicht sagen. Wenn nur ein paar Spalten hinzugefügt werden, kann die Anwendung weiterlaufen und merkt davon nichts. Bei größeren Änderungen kann es sein, dass man die Datenbank für mehrere Minuten/Stunden nicht verwenden kann, dann läut natürlich gar nichts. Es ist sowieso sinnvoll, eine Migration an einem System zu testen, das so gut wie identisch mit dem Produktivsystem ist. Eine mögliche Variante ist es, eine neue Datenbank(tabelle) aufzusetzen und das Programm so zu schreiben, dass es erst schaut, ob Neudaten vorhanden sind, und falls nicht, einen Fallback auf die alte Datenbank macht. So kann die Migration im Hintergrund laufen, ohne den Betrieb zu stören. All das erfordert aber eine hinreichend große Planung und ist für jeden Fall individuell zu entscheiden, welches die beste Strategie ist. Der Trend geht aber eindeutig weg von großen monolitischen Anwendungen, wie sie bei Django meist entstehen, hin zu kleinen Services, die lose gekoppelt sind und bei denen auch gleichzeitig mehrere Versionen laufen können. In 99.999% der Fälle ist aber eine Downtime von ein paar Stunden kein Problem, so dass man einfach alles abschalten kann, den Server updaten und danach wieder alles hochfährt.
2c. Solange der User nur einen Kommentar schreibt, und im Hintergrund nicht noch Zeugs nachgeladen wird, passiert gar nichts, weil der Server bekommt davon ja nichts mit. Beim Abschicken des Kommentars kann alles mögliche passieren, je nachdem was man da so bei der Migration falsch macht. Das einfachste ist, der Server ist während der Migration down, dann bekommt der User eine Meldung, dass der Server nicht erreichbar ist, und kann es später nocheinmal versuchen. Das Programm kann aber auch in einem inkonsistenten Zustand sein, was im günstigsten Fall heißt, dass der Kommentar einfach verschwindet und nie wieder auftaucht. Im ungünstigsten Fall löst eine falsch gesetzte Verknüpfung eine Kettenreaktion aus, die Dir danach nur noch Datenmüll hinterläßt.
Daher die übliche Tipps: erst Testen. Dann ein Testsystem mit dem letzten Backup aus dem Produktivsystem erzeugen und dort die Migration nochmal testen. Kommt raus, dass die Sache problemlos und in 5 Minuten erledigt ist, Backup machen, Produktivsystem-Django beenden, updaten, migrieren und wieder hochfahren. Sollte die Gefahr bestehen dass es Probleme gibt und es mehrere Stunden braucht, Nutzer rechtzeitig über das Update informieren ala "dieser Dienst ist von Montag 17:00Uhr bis voraussichtlich Dienstag 13:00Uhr nicht erreichbar" und dann wie im 5Minuten Fall fortfahren.
2a. Ein automatisches reload möchte man eigentlich nicht bei einem Produktivsystem, weil nie garantiert werden kann, dass danach noch ein konsistenter Zustand existiert.
2b. Was bei einer Datenbankmigration geschieht, kann man so pauschal nicht sagen. Wenn nur ein paar Spalten hinzugefügt werden, kann die Anwendung weiterlaufen und merkt davon nichts. Bei größeren Änderungen kann es sein, dass man die Datenbank für mehrere Minuten/Stunden nicht verwenden kann, dann läut natürlich gar nichts. Es ist sowieso sinnvoll, eine Migration an einem System zu testen, das so gut wie identisch mit dem Produktivsystem ist. Eine mögliche Variante ist es, eine neue Datenbank(tabelle) aufzusetzen und das Programm so zu schreiben, dass es erst schaut, ob Neudaten vorhanden sind, und falls nicht, einen Fallback auf die alte Datenbank macht. So kann die Migration im Hintergrund laufen, ohne den Betrieb zu stören. All das erfordert aber eine hinreichend große Planung und ist für jeden Fall individuell zu entscheiden, welches die beste Strategie ist. Der Trend geht aber eindeutig weg von großen monolitischen Anwendungen, wie sie bei Django meist entstehen, hin zu kleinen Services, die lose gekoppelt sind und bei denen auch gleichzeitig mehrere Versionen laufen können. In 99.999% der Fälle ist aber eine Downtime von ein paar Stunden kein Problem, so dass man einfach alles abschalten kann, den Server updaten und danach wieder alles hochfährt.
2c. Solange der User nur einen Kommentar schreibt, und im Hintergrund nicht noch Zeugs nachgeladen wird, passiert gar nichts, weil der Server bekommt davon ja nichts mit. Beim Abschicken des Kommentars kann alles mögliche passieren, je nachdem was man da so bei der Migration falsch macht. Das einfachste ist, der Server ist während der Migration down, dann bekommt der User eine Meldung, dass der Server nicht erreichbar ist, und kann es später nocheinmal versuchen. Das Programm kann aber auch in einem inkonsistenten Zustand sein, was im günstigsten Fall heißt, dass der Kommentar einfach verschwindet und nie wieder auftaucht. Im ungünstigsten Fall löst eine falsch gesetzte Verknüpfung eine Kettenreaktion aus, die Dir danach nur noch Datenmüll hinterläßt.
Daher die übliche Tipps: erst Testen. Dann ein Testsystem mit dem letzten Backup aus dem Produktivsystem erzeugen und dort die Migration nochmal testen. Kommt raus, dass die Sache problemlos und in 5 Minuten erledigt ist, Backup machen, Produktivsystem-Django beenden, updaten, migrieren und wieder hochfahren. Sollte die Gefahr bestehen dass es Probleme gibt und es mehrere Stunden braucht, Nutzer rechtzeitig über das Update informieren ala "dieser Dienst ist von Montag 17:00Uhr bis voraussichtlich Dienstag 13:00Uhr nicht erreichbar" und dann wie im 5Minuten Fall fortfahren.