Skip to content

Draft: Deployment

Jump to bottom
Stephano Vogel edited this page Sep 27, 2024 · 3 revisions

Wahl der Art des Deployments

Es gäbe ein paar Optionen, um den Code und die Build Artifacts (vendor Verzeichnis in PHP und unter Umständen node_modules für Node.js/npm Packages) auf den Server zu bekommen und im Rahmen eines Deployments zu releasen:

  • Manuelles Deployment per S/FTP, rsync, etc.
  • git clone auf dem Ziel
  • git archive auf dem Ziel
  • Generieren der Artifacts und Kopieren per rsync auf das Ziel

Im Rahmen dieser Optionen habe ich auch nach ein paar gängigen Tools geschaut und aus der Vergangenheit ein, zwei Optionen im Sinn.

Deployer

Eine davon nennt sich Deployer und ist mir schon bei ein, zwei Projekten aufgefallen. Prinzipiell handelt es sich um ein Toolset, das Tasks und einzelne Schritte auf dem Zielserver und damit das Deployment ausführt.

Um Zero-Downtime zu erzielen, arbeitet Deployer mit Symlinks und verschiedenen Ordnern von Releases, um im Zweifel wieder auf einen vorherigen Stand rollbacken zu können.

Die Ordnerstruktur würde in unserem Setup dann in etwa so aussehen:

/var/www/virtual/ccfiae24/eventguru     // Das root-Verzeichnis vom Deployment
 |- current -> releases/1               // Symlink zum aktuellen Release
 |- releases                            // Alle Releases
    |- 1                                // eigentliche Ordner der Applikation-Releases
       |- ...
       |- .env -> shared/.env           // Symlink zur geteilten .env Datei
 |- shared                              // Verzeichnis für weitere geteilte Ordner/Dateien (Uploads, Bilder, ...)
    |- ...
    |- .env                             // Beispiel: geteilte .env file
 |- .dep                                // Deployer Konfigurationsdateien

/var/www/virtual/ccfiae24/html          // Symlink auf das current/public Verzeichnis im Deployment

Deployer bietet zudem eine GitHub Action für das Deployment.

Ein Nachteil, den ich hier sehe: Es wird mit Git für das Deployment gearbeitet. Immerhin kann man zwischen git clone und git archive entscheiden (letzteres lässt wohl den .git Ordner weg), die Installation der Abhängigkeiten geschieht trotzdem noch auf dem Server selbst - das kann man nun gut oder schlecht sehen.
... allerdings könnte man auch mit ein wenig Fleißarbeit einen eigenen Prozess schreiben, der ein Artifact-Paket auf dem Runner schnürt, welches dann auf den Server per rsync deployed wird. Im Code vom Magento 2 Recipe sieht man den Prozess - statt in PHP-Syntax kann man die Recipes auch in YAML schrieben.

Was auch ganz nett ist: Es gibt sogenannte Recipes, die gängige Tasks für Frameworks abkürzen und damit die gesamte Deployment-Konfiguration etwas schlanker machen könnnen. So gibt es auch für Laravel ein Recipe.

Artifacts im CI/CD Prozess bauen und Releasen

Eine weitere Möglichkeit wäre das Schnüren von Artifacts als Release, die dann (in Begleitung von ein paar weiteren Tasks wie Cache Building, Ausführung von Datenbank-Migrationen) auf den Server kopiert werden. Das ist alles direkt in einem GitHub Action Workflow möglich - allerdings müssten wir etwas Mehraufwand für ein Zero-Downtime Deployment betreiben.

Ein Beispiel für das Deployment einer PHP Applikation über eine GitHub Action ist hier zu finden - hier am Beispiel eines Azure Cloud Deployments:
https://docs.github.com/en/actions/use-cases-and-examples/deploying/deploying-php-to-azure-app-service

Vorteil hier: Das Generieren der Artifacts geschieht auf den leistungsstärkeren Runnern im Vergleich zu einem Webspace wie dem von uns bisher verwendeten Uberspace.

Clone this wiki locally