Azure WebApp bereitstellen am Beispiel von Kirby CMS inkl. CI/CD Pipeline

In dieser Anleitung erklären wir Ihnen Schritt für Schritt, wie Sie Kirby CMS mit Hilfe von Azure App Service bereitstellen und eine Pipeline über GitHub 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. Kirby CMS soll hier stellvertretend für eine Vielzahl anderer möglicher Web Apps stehen, die mit Azure und GitHub Actions bereitgestellt werden können.

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.

Eine Web App erstellen

Öffnen Sie als ersten Schritt in Ihrem Azure Portal App Services.

Fügen Sie auf dem “+” Symbol eine App hinzu
Wählen Sie eine Ressourcen Gruppe für Ihre Website oder erstellen Sie eine neue
Konfigurieren Sie die URL der Website. Zum Beispiel “MeineWebsite.azurewebsites.net”
Wählen Sie Publish als “Code” aus
Als Runtime Stack wählen Sie PHP 8.2 oder 8.3 aus. 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äferierte Region. Zum Beispiel Germany West Central.

Bei der Verwendung virtueller Maschinen führt man üblicherweise eine Konfiguration pro Maschine durch. 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.

Wir wählen den kostenfreien Plan Free F1 aus, da es sich zunächst um eine Testinstallation handelt. Bei Nutzung des F1-Plans kann die App bei Inaktivität automatisch von Azure pausiert werden und es entstehen höhere Startzeiten für nachfolgende Zugriffe. Für den produktiven Einsatz sollte somit mindestens auf den Plan Basic B1 oder einen der angebotenen Premiumpläne gewechselt werden. Dies ist im Nachgang jederzeit möglich.

Eine weiterführende Konfiguration ist nicht notwendig. Drücken Sie nun auf Erstellen.

Nachdem die Web App erstellt wurde, wird standardmäßig eine Beispiel HTML Website von Microsoft geladen.

Mainzer Datenfabrik - Azure WebApp bereitstellen am Beispiel von Kirby CMS inkl. CI/CD Pipeline

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

Template Projekt “Starterkit” als CI/DC Pipeline installieren

Folgende Möglichkeiten haben Sie, Inhalte in die Web App grundsätzlich bereitzustellen:

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

Letztere Methode wird in diesem Artikel verwendet:

Kopieren Sie das Kirby Starter-Kit in ihren eigenen Github Account. Loggen Sie sich dazu bei github.com ein und öffnen Sie das Kirby Starter-Kit. Klicken Sie auf Use this Template bzw. “Template verwenden” und wählen Sie Create new repository.

Kopieren vom Template in den eigenen Github Account

Wählen Sie einen Namen, setzen Sie die Sichtbarkeit auf Private und bestätigen Sie den Vorgang:

Kopieren des Starterkits in den eigenen Github Account

Wechseln Sie nun zurück zu Azure und der eben erstellten Web App in das Deployment Center und konfigurieren Sie nun die Inhalte für Ihre Website wie folgt. Gegebenenfalls müssen Sie sich an dieser Stelle erneut gegenüber GitHub authentifizieren.

Wählen Sie GitHub als Source und geben Sie den Account und das Repository an, welches Sie zuvor kopiert haben. Speichern Sie die Einstellung anschließend.

Nun wird vollautomatisch in GitHub Actions das Projekt erstellt (CI) und in die Web App deployed (CD). Github Actions wurde an dieser Stelle automatisch durch das Azure Portal konfiguriert und ausgelöst. Standardmäßig erfolgt nun nach jedem Commit in den main Branch die Bereitstellung vollautomatisch. Im Beispiel dauerte dieser Vorgang 1 Minute und 24 Sekunden.

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

Der erwartete Content kann nicht gefunden werden, da versucht wird, ihn über eine “example.com” URL zu laden. Dieser Fehler ist auf eine falsche Konfiguration innerhalb der Anwendung zurückzuführen. Dies ist auch nicht weiter verwunderlich, da bisher nur das Beispiel von Kirby einfach kopiert und bereitgestellt wurde. Typischerweise müssen Webanwendungen zunächst noch über bestimmte Konfigurationsdateien konfiguriert werden dies wird nachfolgend erläutert.

Zunächst wird der Nginx Webserver mit einer persistenten Konfiguration versehen und dann die config.php Datei mit der korrekten URL eingestellt.

Persistente Webserverkonfiguration

Um die Webserver Einstellungen festzulegen, öffnen Sie die SSH Konsole.

Es öffnet sich ein neues Fenster und Sie werden automatisch in der Linux Shell eingeloggt.

Beachten Sie hierbei, dass jegliche Konfiguration außerhalb des Ordners “/home/” nicht persistent ist und nach einem Neustart der Web App immer auf den Ursprung zurückgesetzt wird. Wie wir diese Daten dennoch persistent einrichten können, wird im nächsten Abschnitt erklärt.

Navigieren Sie zunächst in den Ordner sites-available.

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. Öffnen Sie die Datei mit dem Editor Ihrer Wahl (zum Beispiel vi).

vi default

Der Ort und die PHP Konfiguration müssen bestimmt werden.

Ändern Sie die Zeile nach location / { zu folgendes:

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

Es ist außerdem sinnvoll, die PHP Konfiguration anzupassen. Folgende Zeile fängt alle Fehlermeldungen ab und verwirft sie serverseitig. Wenn diese erhalten bleibt, dann ist der Debug Modus von Kirby nicht verfügbar. Setzen Sie ein # an den Anfang um die Einstellung zu deaktivieren:

# fastcgi_intercept_errors on;

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

Persistieren der Einstellungen

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

Kopieren Sie die Datei default in das home Verzeichnis:

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

Erstellen Sie nun ein Skript /home/site/startup.sh mit dem Editor Ihrer Wahl, welches bei Neustart des Servers geladen wird mit folgendem Inhalt.

#!/bin/bash
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

Kirby CMS config anpassen

Zusätzlich muss noch innerhalb des Kirby-Repository die Datei site/config/config.php angepasst werden um das Problem mit dem “example.com”-Abruf zu lösen. Wechseln Sie in GitHub zu der Datei und wählen Sie “edit file”. Ergänzen Sie anschließend die nachfolgende Zeile beginnend mit ‘url’… entsprechend Ihrer eigenen Web App URL.

return [
    'debug' => true,
    'url' => 'https://meinewebsite.azurewebsites.net',
];

Nachdem Sie die URL ergänzt haben führen Sie einen Commit aus. Die Änderungen sollen direkt in den main-branch gestellt werden.

Nachdem Sie die Änderungen mit Commit changes bereitgestellt haben, startet ein neuer GitHub Action Vorgang und die Webapp startet neu.

Gedulden Sie sich ein paar Minuten und öffnen Sie dann die Website erneut. Es sollte nun wie folgt aussehen.

CI/CD Actions Pipeline testen

Testen Sie nun abschließend die Funktionstüchtigkeit der CI/CD Pipeline in dem Sie einen Inhalt verändern. Navigieren Sie auf der GitHub Website zu folgendem Pfad: content/home/home.txt
Wie bereits zuvor bei der Konfigurations-Datei, können Sie Edit this file nutzen, um direkt den in GitHub eingebauten Editor zu verwenden und die Änderungen somit bereitstellen, beispielsweise für den Titel oder die Überschriften (Headline bzw. Subheadline).

Führen Sie anschließend einen Commit der Änderungen in den main Branch aus. In Github Actions wird ein neues Deployment gestartet.

Gedulden Sie sich wenige Minuten und laden Sie die Website nach Abschluss der Aktion neu. Sie sollten nun den geänderten Text in der Website sehen. Die Pipeline funktioniert!

Fazit

Wir haben mit dieser kurzen und prägnanten Anleitung gezeigt, wie Sie eine Azure Web App inklusive CI/CD Pipeline mit GitHub Actions am Beispiel des PHP-basierten Kirby Content Management System (CMS) bereitstellen können. Eine Web App inklusive Pipeline lässt sich in ganz ähnlicher Weise auch für andere Web Apps sowie Eigenentwicklungen auf anderen Plattformen neben PHP nutzen. Aktuell wird Python, Java, JavaScript, . NET und Go in einer Azure Web App unterstützt.

Für den produktiven Einsatz empfiehlt es sich mehrere Umgebungen zu nutzen wie eine sogenannte Testing- und Staging-Umgebung. Verbunden mit automatischen Tests und Workflows inkl. Freigaben können Sie somit eine vollautomatische Bereitstellung und Qualitätssicherung Ihrer Webapps realisieren.

Gerne helfen Ihnen unsere Experten bei diesen oder anderen Fragen weiter. Kontaktieren Sie uns hierfür einfach über das Kontaktformular und lassen sich von uns unverbindlich beraten.