Deploymentstrategie für PHP-Projekte

alinnert

Mitglied
Hallo zusammen,

ich hab derzeit ein PHP-Projekt am Laufen, das auch so gut wie fertig ist. Ich häng grad nur an dem Punkt, wie ich es sinnvoll deployen kann.

Die Live-Umgebung ist eine typische PHP-Hosting-Umgebung mit Zugriff über SSH und theoretisch wäre auch Git auf dem System verfügbar.

Der Quellcode liegt auf GitHub und ich hab bereits eine GitHub-Action eingerichtet, die Composer-Dependencies installiert und mit Node und npm die Frontend-Assets kompiliert. Anschließend wird das ganze via rsync auf den Server synchronisiert (neben der tatsächlichen Live-Instanz). Soweit ganz gut.

Jetzt hab ich auf dem Server nur zwei Stände:

a) der neue Stand, der per rsync übertragen wurde
b) der aktuell laufende Live-Stand

In der Ordner-Struktur des Live-Standes befinden sich nun aber diverse laufzeitgenerierte Dateien (Uploads, Caches, Logs etc.). Wie führt man die beiden Stände nun zusammen und das möglichst atomar (= nicht jede Datei einzeln von A nach B kopieren)? Mein aktueller Ansatz wäre ein Shell-Skript zu schreiben, das Ordner kopiert und per rename dann am Stück ersetzt.

Dabei frag ich mich auch, wie sowas bei größeren Projekten oder Deploymentdiensten (z. B. CircleCI) umgesetzt wird. Hat da jemand Erfahrung oder Tipps diesbezüglich?
 
Welche Deployment-Strategie sinnvoll ist, ist stark von deinem Projekt abhängig, weil du zwischen Verfügbarkeit der Anwendung und Komplexität des Deployments/der Architektur abwägen musst.

Wenn Downtime grundsätzlich erlaubt ist, steht dir eine Reihe von relativ simplen Deployment-Strategien zur Verfügung, z. B. Update des Quellcodes über Git mit anschließendem Update der Dependencies. Vielleicht klingt dieser Ansatz etwas stumpf, aber die meisten privaten Webseiten verkraften eine minimale Downtime. Da lohnt sich die Erhöhung der Komplexität für eine höhere Verfügbarkeit kaum.

Wenn Downtime nicht erlaubt ist, muss das Deployment in einem neuen Verzeichnis auf dem Server erfolgen, wo ggf. auch alle Dependencies installiert werden. Sobald das erledigt ist, kannst du den Root des Webservers als Symlink auf dieses neue Verzeichnis legen. Falls du mit dem neuen Deployment einen Bug auf der Produktivseite eingeführt hast, kannst du den Symlink wieder auf ein älteres Deployment legen. Dieser Ansatz ist eigentlich der way to go.

Dann gibts aber noch das Problem, dass du beschrieben hast: Mit jedem neuen Deployment verschwinden die von dir genannten zur Laufzeit generierten Dateien. Gut, eigentlich ist das nur ein Problem bei Projekten, die nicht für Zero Downtime konzipiert wurden und es jetzt trotzdem sein wollen - die großen Projekte, die wirklich hochverfügbar sein müssen, sind das per Design. Als Workaround könntest du von Usern hochgeladene Dateien auslagern und unter einer anderen Subdomain verfügbar machen. Ein anderer Workaround für dieses Problem wäre, die Dateien vom letzten Release in das aktuelle Deployment-Verzeichnis zu kopieren. Auch hier musst du wieder abwägen, ob dir die höhere Verfügbarkeit den höheren Speicherbedarf wert ist.

Dabei frag ich mich auch, wie sowas bei größeren Projekten oder Deploymentdiensten (z. B. CircleCI) umgesetzt wird.

Größere Projekte nutzen für Deployments ohne Downtime üblicherweise Rolling Updates in Kubernetes. CircleCI ändert deinen Deployment-Prozess eigentlich nicht, sondern automatisiert ihn nur. Es gibt zwar vorgefertigte Jobs für Deployments auf verschiedene Plattformen (sog. Orbs), aber die verwenden intern auch nur den CLI-Befehl der jeweiligen Plattform, im Zweifelsfall ssh.
 
Dependencies installieren mach ich, wie beschrieben, auf GitHub. Auf der Hosting-Umgebung hab ich kein Node zur Verfügung. Das sind aber, denk ich, nur Details.

Das mit der Subdomain ist eine sehr gute Idee. Das dürfte durchaus problemlos möglich sein. Bleiben noch Logs und Caches. (...) Ohhhh! Ohhh! 😲 Man kann in Craft den Pfad des Ordners anpassen, der diese Dateien beinhaltet. Oh yes! Damit wär auch das Rätsel gelöst.
(Craft wär so gut, wenn es nicht auf dem XAMP-Stack basieren würde... 😅 *hust hust*)

Ich glaube den Rest krieg ich dann mit Symlinks hin, ja. Danke für den Denkanstoß :D
 
Zurück
Oben Unten