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.