Kirby CMS auf Azure bereitstellen

In dieser Anleitung erklären wir Ihnen Schritt für Schritt, wie Sie Kirby CMS mit Hilfe von Azure App Service bereitstellen. Da Kirby eigene URLs erstellt, können einige Problemfälle hinsichtlich der Installation auftreten. Diese werden wir in den folgenden Absätzen näher beleuchten und entsprechende Lösungsansätze liefern.

Warum die Installation nicht auf einer VM erfolgen sollte:

Virtuelle Maschinen sind im Allgemeinen für viele Serverbereitstellungen eine sinnvolle Lösung. Dennoch ist es notwendig, die unterliegende Software regelmäßig zu patchen. Außerdem erfordert es einen Mehraufwand, wenn CI/CD für die Website konfiguriert werden soll - diese beiden Aufgaben übernimmt Azure für Sie und stellt Ihre Website serverless bereit, somit müssen Sie sich nicht um Ausfall, Sicherheit oder Patchmanagement sorgen.

Erstellen einer Web App

Öffnen Sie als erstes die App Services in Ihrem Azure Portal.
Fügen Sie mit dem + eine App hinzu.
Wählen Sie eine passende Ressourcen Gruppe für Ihre Website aus, oder erstellen Sie eine neue über create new.

Mainzer Datenfabrik - Kirby CMS auf Azure bereitstellen

Konfigurieren Sie die URL der Website

Wählen Sie code aus.

Wir wählen in dieser Anleitung PHP8 für die Installation aus.

Leider ist die Microsoft Dokumentation für die PHP Installation etwas bedürftig. Unter PHP 7.4 wird standardmäßig Apache2 installiert. Unter PHP8 jedoch Nginx. Durch die Auswahl von PHP wird Ihnen als unterliegendes Betriebssystem nur Linux zur Verfügung gestellt.

Setzen Sie nun unter dem Dropdownmenü Region Ihre präferiere Region fest.

Unter virtuellen Maschinen ist man es gewohnt, eine Konfiguration pro Maschine durchzuführen. Unter Azure App Service wird ein “App Service Plan” erstellt. In diesem Plan können mehrere Apps laufen. Wichtig ist hierbei zu beachten, dass App Service Pläne nicht regionsübergreifend sind, d.h. Sie können keine App in der Region “West Europa” unter einem Service Plan laufen lassen, der in der Region “West Central Germany” erstellt wurde.

Wir erstellen nun einen neuen Service Plan und geben ihm einen Namen. Wählen Sie anschließend die Rechen-und Speicherleistung des Plans aus. Unterhalb des ausgewählten Plans sehen Sie dann, mit welchen Software-und Hardware Features der Plan ausgeliefert wird.

Da diese Installation nur beispielhaft ist, wählen wir den Plan “B1”. Beachten Sie, dass Sie den Plan “F1” zwar 30 Tage kostenlos nutzen können, aber z.B. keine eigene Domäne hinzufügen dürfen.

Auf der Website wird standardmäßig eine Beispiel HTML Website von Microsoft geladen.

Wie von Microsoft aufgefordert, ist es nun an der Zeit Inhalte hinzuzufügen.

Inhalte für Ihre Website bereitstellen

Folgende Möglichkeiten haben Sie, Inhalte bereitzustellen:

Datenupload über FTPS, hierfür wird Ihnen auch ein Profil bereitgestellt, dass Sie in Visual Studio importieren können
Bereitstellung über PowerShell
CI/CD Bereitstellung durch z.B. GitHub Actions

Letztere Methode wird in diesem Tutorial verwendet:

Fügen Sie das Kirby Starter-Kit zu ihrem Repository hinzu

Bestätigen Sie den Fork

Konfigurieren Sie nun die Inhalte für Ihre Website im Deployment Center wie folgt:

Speichern Sie die Einstellung.

Nun wird vollautomatisch in GitHub Actions versucht das Projekt zu bauen und deployen. Der erste Build wird daran scheitern, dass Sie keine Plugins in der composer.json gestattet haben, diese aber erforderlich sind. Damit der Build erfolgt, fügen Sie folgende Konfiguration an das Dateiende an:

"config": {
    "optimize-autoloader": true,
    "allow-plugins": true
  }

Starten Sie nun den Bauvorgang erneut, indem Sie in dem Bereitstellungscenter auf Sync klicken.

Nachdem Sie Ihre Website öffnen, werden Sie bemerken, dass es mit der jetzigen Konfiguration noch nicht getan ist:

Wenn Sie Chrome benutzen, können Sie auf untersuchen klicken und werden direkt mit der ersten Fehlermeldung konfrontiert:

In der Konsole kann man zwei Fehlerursachen diagnostizieren:

Der erwartet Content wird nicht über ein sicheres Protokoll wie Beispielsweise HTTPS geladen.
Der erwartet Content kann nicht gefunden werden, da versucht wird, ihn über eine “example.com” URL zu laden.

Um diese Fehler zu beheben, öffnen Sie die SSH Konsole Ihrer Applikation wie folgt:

Azure Portal → Ihre App → Entwicklungstools → SSH
Öffnen Sie https://.scm.azurewebsites.net/webssh/host

Beachten Sie hierbei, dass jegliche Konfiguration außerhalb des Ordners “/home/” nicht persistent ist und nach einem Neustart auf den Ursprung zurückgesetzt wird.

Wie wir diese Daten dennoch persistent einrichten können, wird Ihnen später in diesem Artikel erklärt.

Ihre Website liegt in folgendem Verzeichnis:

/home/site/wwwroot/

Öffnen Sie zunächst:

cd /etc/nginx/sites-available/

Konfigurieren Sie nun die Datei default. Diese Konfiguration wird von der nginx.conf Datei nach dem Start des Nginx Dienstes evaluiert.

vi default

Es ist zwar der erste Instinkt, doch es nicht notwendig in dieser Datei den Servernamen, offene Ports oder andere Protokolle einzurichten. Lediglich der Ort und die PHP Konfiguration muss bestimmt werden.

Löschen Sie die Standardkonfiguration der index.php Datei und ändern Sie sie wie folgt:

location / {
    try_files $uri $uri/ /index.php$is_args$args;
  }

Es ist außerdem unabdingbar, die PHP Konfiguration anzupassen. Wenn dies nicht erfolgt, ist der Debug Modi von Kirby nicht verfügbar. Löschen Sie nun folgende Zeile:

fastcgi_intercept_errors on;

Es werden nun PHP Fehler von Kirby abgefangen und die direkte Konfiguration von Nginx ist abgeschlossen.

Öffnen Sie nun folgende Datei:

vi /home/site/wwwroot/site/config/config.php

In dieser Konfigurationsdatei ist es abschließend notwendig die URL zu bestimmen.

return [
    'debug' => true,
    'url' => 'https://<ihreDomäne>.azurewebsites.net',
];

Falls Sie eine eigene Domäne bereits konfiguriert haben, ändern Sie die URL dementsprechend und speichern die Datei.

Um die angepassten Einstellungen außerhalb des /home persistent zu konfigurieren, sind eine folgende kurze Schritte notwendig.

cp /etc/nginx/sites-available/default /home/site/nginx.conf

Erstellen Sie nun ein Skript, welches bei Neustart des Servers geladen wird.

vi startup.sh

cp /home/site/nginx.conf /etc/nginx/sites-available/default
service nginx restart

Speichern Sie diese Datei und öffnen anschließend das Azure Portal.

Setzen Sie nun folgenden Befehl als Startup-Command:

/home/site/startup.sh

Starten Sie nun die Webapp neu. Wenn Sie den Link öffnen, sollte es wie folgt aussehen:

GitHub Actions Pipeline Testen

Geschafft! Testen Sie nun die Funktionstüchtigkeit der CI/CD Pipeline. Navigieren Sie auf der GitHub Website zu folgendem Pfad: /starterkit/content/home/home.txt/

Title: Home

----

Headline: Hello World! 

----

Subheadline: A fully documented example project

Committen Sie die Veränderung zu dem verbundenen Branch in Azure. Gedulden Sie sich wenige Minuten und laden Sie die Website neu.

Die Pipeline funktioniert!

Troubleshooting:

Bei einer derartigen Installation können schon kleine Syntax Fehler die Website komplett blockieren. Wenn Sie auf Fehlersuche gehen, eignet sich hierfür die von Azure selbst bereitgestellte Log Stream Funktion. Diese finden Sie im Menüpunkt Monitoring der Website an vorletzter Stelle.

Restarting nginx: nginx failed!

Wenn der Nginx Dienst nicht starten kann, ist die Website nicht erreichbar. Öffnen Sie hierfür die Konsole:

nginx -t

In diesem Beispiel fehlt eine geschweifte Klammer. Wenn Sie die Nginx Konfiguration bearbeiten, vergewissern Sie sich, dass Sie die /home/site/nginx.conf Datei bearbeiten, da die /etc/nginx/sites-available/default Datei wie erwähnt, nicht persistent ist.

Failed to load resource: net::ERR_NAME_NOT_RESOLVED

Falls auch nach Konfiguration der config.php Datei Ihre Website nicht korrekt lädt, überprüfen Sie die Korrektheit der URL. Wichtig ist, dass Sie nicht mit einem “/” endet und mit “https://” anfängt. Halten Sie Ihre Maus über den Link, der geladen werden soll. Vielleicht erkennen Sie hier schon den Syntax Fehler. Im Falle, dass so der Fehler nicht gelöst werden kann, probieren Sie es an Stelle der absoluten URL mit einem relativen Pfad.

'url' => '/',

Durch diese Einstellung wird der Link wie folgt aufgerufen:

assets/js/prism.js und nicht “https://.azurewebsites.net/assets/js/prism.js“

Eventuell kann es auch daran liegen, dass Sie kein Komma nach der Debug Einstellung gesetzt haben. Somit kann das Array nicht richtig geladen werden - und damit ebenfalls nicht Ihre URL Konfiguration.

'debug' => 'true', <---

Nginx Logging aktivieren

Um genauere Information über die eintreffenden Anfragen zu erhalten aktivieren Sie die Logging Funktion von Nginx.

Bearbeiten Sie erneut die /home/site/nginx.conf Datei. Fügen Sie die folgenden zwei Zeilen Code hinzu:

error_log  /var/log/nginx/access.log;
access_log /var/log/nginx/error.log;

Starten Sie nun den Dienst neu:

service nginx restart

Mit dieser kurzen und prägnanten Anleitung sollten Sie nun in der Lage sein, das Kirby Content Management System (CMS) auf der Azure Web App bereitstellen zu können. Bei Rückfragen oder Problemen helfen Ihnen gerne unsere Experten weiter. Kontaktieren Sie uns hierfür einfach über das Kontaktformular und lassen sich von uns unverbindlich beraten.

Kirby CMS auf Azure bereitstellen

Erstellen einer Web App

Inhalte für Ihre Website bereitstellen

GitHub Actions Pipeline Testen

Nginx Logging aktivieren

Auf dieser Seite

Interesse geweckt?

Unsere Expert:innen stehen Ihnen bei allen Fragen rund um Ihre IT Infrastruktur zur Seite.