Plesk CI/CD: Automatisches Bereitstellen einer Node.js App (+ automatischer Frontend Build)

Mit diesem Plesk CI/CD Workflow musst kannst du komplett automatisiert deine Node.js App inkl. Frontend auf deinem Plesk Server hosten. Mit automatischem Build deiner Frontend App gehören lästige Arbeiten der Vergangenheit an.
Egal ob Vue, React, Angular & Co.: Die Bereitstellung erfolgt immer über npm run build
, dann alles auf den Server ziehen und evtl. Node.js App neu starten. Das ist alles sehr aufwendig, gerade bei kleinen Änderungen. Mit diesem Plesk CI/CD Workflow und GitHub Actions passiert das alles vollautomatisch.
Auch einfach statische Websites lassen sich so automatisiert nach einem Push ins Repository bereitstellen.
Was bedeutet CI/CD?
CI/CD steht für Continuous Integration/Continuous Delivery (fortlaufende Integration/Verteilung). Es bezeichnet Verfahren, die es Entwicklern erlauben Änderungen an einer Software ständig und automatisiert bereitzustellen. Ein einfach Beispiel: Wird eine kleine Code Änderung an einer vorhanden Anwendung durchgeführt, soll diese nach dem Commit und Push ins Repository automatisch auf einen Development oder Production Server bereitgestellt werden.
Dabei werden im Hintergrund automatisiert einige Prozesse ausgeführt, wie das Compilen und Ausführen der Unit Tests. Da verschiedene Aufgaben hintereinander ausgeführt werden spricht man auch oft von einer CI/CD Pipeline.
Voraussetzungen
Um einen Plesk CI/CD Workflow für Node.js Apps bzw. Frontend Anwendungen mit Node zu realisieren müssen zwei Voraussetzungen erfüllt sein:
- Die Plesk Git extension muss in deinem Plesk installiert sein (per Klick unter Erweiterungen > „Git“)
- Außerdem muss der Code deiner Website/App in einem GitHub Repository vorliegen
Git Repository in Plesk einrichten
Wenn du Frontend und Backend deiner App mit Plesk bereitstellen möchtest würde ich zwei Repo-Instanzen in Plesk anlegen. Beide können natürlich auf das gleiche Remote Repository verweisen. So hast du die Möglichkeit auch mal nur eine Komponente – also nur Frontend oder nur Backend – auszutauschen.

Backend
In meinem Fall stelle ich den kompletten Inhalt meines main Branches fürs Backend bereit. Über die .gitignore
habe geregelt, dass keine Frontend Builds auf diesem Branch erscheinen. Alle Dateien werden automatisch im Root-Verzeichnis meiner Anwendung in Plesk bereitgestellt.
Alles Infos zum Hosting einer Node Anwendung erfährst du in meinem ausführlichen Beitrag zum Thema Node.js App Hosting mit Plesk.
Frontend
Die zweite Repo-Instanz in Plesk ist nur fürs Frontend. Hier wird automatisch der komplette Inhalt des build Branches im Unterordner /public bereitgestellt. Im Ordner public befindet sich also der komplette Inhalt deines Frontend Builds (egal ob Vue, React, Angular, …).
Damit der Zugriff auf diese statischen Dateien funktioniert ist folgender Code in meiner index.js meiner Node Anwendung implementiert:
// handle production if (process.env.NODE_ENV === "production") { // static folder app.use(express.static(__dirname + "/public")); // handle SPA app.get(/.*/, (req, res) => res.sendFile(__dirname + "/public/index.html")); }
Falls du ein privates GitHub Repo nutzt, erfährst du hier wie du ein privates GitHub Repository mit Plesk klonen kannst.
Bis hierher werden unsere Dateien bereitgestellt, wenn wir den Pull manuell ausführen. Wenn wir also lokal einen Commit machen und ihn in unser Remote Repository pushen müssten wir uns immer in Plesk anmelden und den „Jetzt Pull ausführen“ Button klicken. Außerdem werden bei Änderungen am Frontend noch kein Build ausgeführt. Diese Automatisierungen konfigurieren wir jetzt.
GitHub Actions: Workflow für automatischen Build anlegen
Wenn wir lokal entwickeln starten wir immer einen Entwicklungsserver auf unserem Rechner. Für den Livegang (Production) müssen wir einen Befehl wie npm run build
oder ähnliches ausführen. Diesen Prozess wollen wir jetzt automatisieren. Dazu nutzen wir GitHub Actions. GitHub ermöglicht uns mit Konfigurationsdateien Pipelines/Workflows zu erstellen um eine solche Automatisierung zu realisieren.
Gehe zu deinem GitHub Repository auf den Tab „Actions“ und klicke auf „set up workflow yourself“.

Du erhältst diesen Editor, der eine Datei im YAML Format bereitstellt.

Ich habe dir eine Vorlage erstellt, um automatisch bei einem Push auf einen beliebigen Branch (in diesem Fall master) unseren Build auszuführen. Wird also ein Push registriert soll der automatisierte Build ausgeführt werden. Die Node.js Version kannst du über Zeile 17 einstellen.
In meinen Fullstack Anwendungen organisiere ich das Frontend immer in einem Unterordner client. Für React und Vue habe ich diesen Workflow getestet. Bei ähnlichen Frameworks wird dieser Plesk CI/CD Workflow auch funktionieren. Für Details zum Build schau am besten einfach in der Dokumentation deines Frontend Frameworks nach.
In Zeile 27 wird zuerst ein npm i
ausgeführt und danach ein npm run build
. Der Parameter --prefix client
bewirkt, dass die Befehle im Unterordner für unseren Client ausgeführt werden.
Im letzten Schritt pushen wir den kompletten Build auf den Branch build des gleichen Repositories. Der Inhalt wird im Unterordner server/public bereitgestellt.
# This workflow will do a build of your frontend and automatically push it to a build branch # For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions name: Node.js CI/CD Workflow with frontend on: push: branches: [ "master" ] jobs: build: runs-on: ubuntu-latest strategy: matrix: node-version: [16.x] steps: - uses: actions/checkout@v3 - name: Use Node.js ${{ matrix.node-version }} uses: actions/setup-node@v3 with: node-version: ${{ matrix.node-version }} cache: 'npm' - name: Build Frontend run: npm i --prefix client && npm run build --prefix client env: CI: false - name: Push to build branch uses: s0/git-publish-subdir-action@develop env: REPO: self BRANCH: build # The branch name where you want to push the assets FOLDER: server/public # The directory where your assets are generated GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # GitHub will automatically add this - you don't need to bother getting a token MESSAGE: "Build: ({sha}) {msg}" # The commit message
Sobald du die Workflow Datei abspeicherst wird der Job automatisch ausgeführt und dein Frontend gebaut und auf den build Branch gepusht. Das kann je nach Frontend auch mal 1-2 Minuten dauern.

Diesen Workflow kannst du noch doch eigene Jobs ergänzen. Beispielsweise das Ausführen automatischer Unit Tests passen hier optimal rein.
Webhooks: Automatisches Abrufen neuer Pushes
Was haben wir bisher: Frontend und Backend werden jetzt in den richtigen Verzeichnissen auf unserem Plesk Server gehostet und unser Frontend wird automatisch mit GitHub Actions gebaut. Für einen kompletten Plesk CI/CD Workflow fehlt nur noch, dass neue Pushes automatisch von Plesk erkannt werden und bereit gestellt werden. Dazu nutzen wir Webhooks.
In den Repository Einstellungen in Plesk findest du eine Webhook-URL, die du dir rauskopieren musst.

Anschließend gehst du in die Repository Einstellungen in deinem GitHub Repo unter Settings > Webooks und klickst auf „Add webhook“. Hier fügst du die URL ein und lässt alle anderen Einstellungen auf ihren Standardwerten.

Fertig! Alle Teile unseres automatisierten Plesk CI/CD Workflows sind fertig. Wenn du jetzt lokal eine Änderung machst, diesen commitest und auf den main Branch in dein Remote Repository pusht, wird die GitHub Action ausgeführt und das Frontend gebaut. Sobald der Build auf den build Branch automatisiert gepusht wurde erkennt Plesk über einen Ping auf der Webhook URL und stellt die Änderungen automatisch bereit.
Wie fandest du diesen Beitrag?

