Django mit Git und Fabric deployen

[orschiro]

Hallo Leute,

bisher habe ich mit Django recht konventionell gearbeitet, sprich kein VCS, sondern die veränderten Dateien einfach per SSHFS auf den Server geladen.

Nun habe ich mir Git näher angeschaut und gleich mal mein Django-Projekt in ein Repo gepackt, wo ich es nun sehr schön verwalten kann.

Jetzt geht es allerdings wieder um das Deployen. Wie stelle ich das am besten an?

Wie macht ihr das, sofern ihr ein VCS nutzt?

Ich habe mir dazu mal Fabric näher angeschaut und im Grunde wäre es eine Ergänzung wie ich sie gesucht habe.

Code: Alles auswählen

def deploy():
    run("synchronisiere den Server mit meinen lokalem Repo")
    reload()
       
def reload():
    run("reloade den fcgi prozess")

Allerdings ist mir nicht so ganz klar, wie der Server die aktuellsten Daten aus dem Repo bekommen soll. Muss ich ein zusätzliches Repo auf dem Server anlegen oder reicht mein lokales nicht aus?

Danke für eure Antworten. Ich bin noch etwas verwirrt.

[Leonidas]

Du kannst es ja auf ein Repo auf deinem Server pushen, von wo sich die Production-Version die Änderungen pullt. Mit git ist das doch überhaupt kein Problem.

[orschiro]

Hallo Leonidas,

das war ja meine Frage, ob es nur über dieses zusätzliche Repo auf meinem Server geht, von dem die Änderungen in ein Verzeichnis auf dem Server gepullt werden.

[Leonidas]

Nein, du kannst es auch direkt auf das Deployment-Repo pushen, musst nur wegen dem Working Tree aufpassen, welches er dann auf dem Server auscheckt.

[cofi]

Hallo Leonidas,

das war ja meine Frage, ob es nur über dieses zusätzliche Repo auf meinem Server geht, von dem die Änderungen in ein Verzeichnis auf dem Server gepullt werden.

Wenn du kein zusaetzliches Repository auf dem Server willst, kannst du es auch einfach weiterhin so machen, wie du es bisher gemacht hast.

Wenn du Bandbreite sparen willst, kannst du auch Patches von Git generieren lassen und die dann auf dem Server anwenden.

[orschiro]

Das klingt interessant. Danke euch beiden.

[sma]

Ich hatte neulich eine Lösung prototypisiert, wo auf einem Server ein Git-Repo liegt, aus dem dann, wenn ich da hinein Pushe, automatisch (per post-update-Hook) in ein zweites Repo gepullt wird aus dem heraus die Webanwendung betrieben wird. Diese wird nach einem erfolgreichen pull automatisch neu gestartet. Ich habe versucht, das Verfahren von Heroku (die so einen Service für Ruby bieten) nachzuahmen.

Einfacher könnte sein, vier Scripte z.B. mit fab oder einem ähnlichen Tool auszuführen:

1. Erzeuge ein neues zentrales git-Repo "xyz.git" für das Projekt "xyz". Nutzt man "ssh:" statt "git:" als Protokoll, braucht man auch keinen dedizierten Git-Server auf seinem Server. Das Script muss nicht mehr machen als "cd .../repo"; mkdir xyz.git; cd xyz.git; git init --bare"

2. Erzeuge ein Script, was ebenfalls auf dem Server ablaufen soll, das eine Ausführungsumgebung initialisiert, indem es das zentrale repo dahin clont und je nach Webserver und/oder mod_python/wsgi die richtigen Einstellungen tätigt.

3. Erzeuge ein Script, welches auf dem Server das git repo der Ausführungsumgebung aus dem zentralen repo aktualisiert (es sollte ein "git pull origin master" reichen, aber das könnte sich, wenn man nicht aufpasst und lokal Dateien ändert, auch mal verklemmen)

4. Erzeuge ein Script, welches auf dem Server den Webserver starten oder stoppen kann.

Man möchte vielleicht noch Support für eine Datenbank haben und diese vor einer Aktualisierung des Programms automatisch backuppen. Oder - eine weitere Idee von Capistrano - erst mal alle Tests laufen lassen, bevor man nach dem aktualisieren wirklich auf die Live-Umgebung umschaltet.

Stefan

[orschiro]

Das mit dem Datenbankbackup ist eine sehr gute Idee. Ich weiß sowieso nach wie vor noch nicht, wie ein Update meines Projektes ablaufen soll, ohne die Produktivdatenbank in irgendeiner Weise beschädigen.

Ich meine, wenn ich lokal unter Testbedingungen beispielsweise meine Änderung an den Models testen will, so kann ich einfach meine lokale Test-Datenbank resetten oder sie notfalls manuell editieren.

Wie aber mache ich so etwas im Idealfall auf dem Produktivserver?

[sma]

Wie aber mache ich so etwas im Idealfall auf dem Produktivserver?

Ein Dump vom Server ist in der Regel das einfachste Problem. Wenn du jedoch feststellst, dass die das Update (vielleicht mit automatischer Schemamigration) die DB zerschossen hat, heißt es hoffen, dass a) der Restore schnell geht und b) zwischenzeitlich keine unentbehrlichen Änderungen stattgefunden haben und man das System nur kurz vom Netz nehmen muss. Für eine Anwendung, die ein paar Duzend oder Hundert Leute einsetzen, ist es eher kein Problem, wenn die man 10 Minuten weg ist, als einer Seite, auf der Millionen von Kunden tagtäglich einkaufen wollen und dich so 10 Minuten Downtime nicht nur Hunderte von Euros kosten sondern auch noch einen schlechten Ruf.

Stefan

[orschiro]

Das heißt, man kommt im Grunde nicht darum herum, die Seite kurz vom Netz zu nehmen, sofern ein Update die Datenbankstruktur betrifft?

Denn wie du sagst, es könnten zwischenzeitlich unentbehrliche Änderungen stattgefunden haben.

[sma]

Letztlich ja. Man könnte alternativ ein schemaloses Ding wie CouchDB einsetzen, welches auch nicht wirklich etwas löscht, sondern immer nur neue Versionen schreibt, dann verliert man theoretisch nichts, sondern muss es ggf. "nur" wiederfinden. Wenn aber nicht der Upgrade selbst Probleme macht, sondern durch diesen eingeschleuste Fehler, die erst Tage später auftreten, ist es auch dort ein Problem.

Letztlich hilft nur Testen.

Und eine möglichst einfache Datenbank-Struktur, damit man diese überblickt und Konsequenzen vollständig abschätzen kann.

Und vielleicht beten...

Mögen dir die Geister der ewigen Speichergründe gewogen sein.

Und immer Weihwasser gegen Dämonenprozesse bereithalten.

Stefan

[Leonidas]

Man sollte auch noch erwähnen, dass PostgreSQL auch ALTER TABLE-Operationen im Laufenden Betrieb bietet. Natürlich sollte man vorher ein Backup ziehen, aber dennoch bin ich sehr froh dass ein Update des Schemas so einfach geht.