In fast allen meinen Azure-Trainings geht es (auch) um die verschiedenen Wege, Anwendungen – insbesondere Web-Anwendungen und Cloud-native Apps – in der Cloud zu betreiben. In diesem Rahmen werden meist auch die Vor- und Nachteile von IaaS (VM, Container) versus PaaS (WebApps, Managed Databases) aus verschiedenen Perspektiven wie Deployment, Sicherheit oder Verwaltbarkeit diskutiert.
Vorkonzipierte Azure-Trainings bieten meist nicht den zeitlichen Rahmen, die einzelnen Varianten an einem konkreten Beispiel durchzuspielen. Dies möchten wir in dieser Beitragsserie am Beispiel WordPress nachholen. WordPress, als weltweit populärstes CMS steht hier stellvertretend für eine PHP-basierte Web-Anwendung mit LAMP- oder XAMP-Stack. Sie können die gewonnenen Erkenntnisse aber problemlos auch auf andere CMS-Systeme wie Joomla, Drupal, Foren-Lösungen wie phpBB oder BBPress oder andere Webanwendungs-Genres übertragen. Hier eine Auswahl von Hosting-Varianten von WordPress in Azure ohne Anspruch auf Vollständigkeit
- WordPress auf Azure VM mit Datenbank
- WordPress auf App Service mit integrierter „App Service Datenbank“
- WordPress auf App Service mit Flexible Server für Azure MySQL Database
- WordPress auf App Service als Docker Container
- WordPress auf Azure VM als Docker Container
- WordPress auf Azure Container Instance
Hinzu kommen die verschiedenen Deployment-Varianten (deklarativ versus imperativ) mit und ohne CI/CD. Ob Sie sich für die eine oder andere Variante (VM, Container, Webapp) entscheiden, hängt im Einzelfall von vielen Faktoren und Rahmenbedingungen sowie von der Zielsetzung ab. Letztere führt zu jeweils anderen Architektur-Entscheidungen, je nachdem, ob Ihr primäres Ziel z. B. im einfachen Deployment, Devops-Integration, Kostenoptimierung, Robustheit (Ausfallsicherheit), Performance, Skalierbarkeit oder Sicherheit priorisiert.
Die Variante „Wordpress auf Azure-VM“, also einem monolithischen Full-LAMP-Stack auf einer virtuellen Maschine lassen wir für die Betrachtung aus, da sich das Vorgehen nicht von einer Installation auf eine Hyper-V- oder VMware oder nur geringfügig von der Installation auf einem physischen Host unterscheiden. Marginale Unterschiede gibt es dabei verständlicherweise beim zugrundeliegenden Host-OS, also Windows, Linux (Deb) oder Linux (RPM). Wir starten im ersten Teil mit WordPress als App Service. Weitere Teile widmen sich den Container-Varianten sowie den Vor- und Nachteilen unter Berücksichtigung der verschiedenen Zielsetzungen, wie Kosten, Performance oder Ausfallsicherheit. Hier beziehen wir dann die VM-Lösung mit ein.
WordPress auf App Service in App Service Datenbank
Sie erahnen vielleicht schon, dass sich für das Betreiben einer PHP-basierten Web-Anwendung wie WordPress in Azure die „Azure App Services“ geradezu aufdrängen. Die Azure App Services erlauben das Hosten nativen Web-Anwendungen unter Windows und Linux, sowie das Hosten containerisierte Web-Anwendungen unter Linux mit Docker oder unter Windows.
Wir widmen uns zuerst der Variante mit WordPress (PHP) unter Windows statt Linux, um von der 2016 eingeführten Funktion MySQL in-app profitieren zu können. Da mit diesem Feature die erforderliche MySQL direkt „in“, bzw. als Bestandteil von Azure App Service gehostet wird, kommen Sie mit dieser Variante z. B. für Testzwecke am schnellsten zum Ziel. Allerdings ist diese Lösung nicht (mehr) offiziell supported. Das liegt unter anderem am EOL von PHP 7.4 im Allgemeinen sowie am nicht mehr vorhandenen PHP-Support der Azure App Services auf Windows ab PHP 8. Das merken Sie u. a. daran, dass Sie bei Verwendung des Azure-Portals in den App Services bei Auswahl von „PHP“ als Software-Plattform nicht mehr „Windows“ als Hardware-Stack wählen können, was in diesem Fall ausgegraut ist.
Es gibt jedoch in den Azure Quickstart Templates ein fertiges ARM-Template für WordPress on App Service with MySQL In App, mit diesem Sie Ihre WordPress-Blog in Azure App Service mit maximal 3 Mausklicks bereitstellen können.
Mit „Deploy to Azure“ stellen leiten Sie die Bereitstellung im Azure-Portal ein. An Parametern bedarf es lediglich, einer Ressourcengruppen, einer Region und einer SKU. Wählen Sie bei letzterer „F1“, können Sie Ihre WordPressblog kostenfrei ausprobieren, dürfen aber dabei eine Performance-Wunder erwarten und verzichten auf automatische Skalierung, denn F1 stellt nur 60 Minuten am Tag Compte-Leistung zur Verfügung. Bei einem geplanten produktiven Einsatz – Support-Anspruch haben Sie wie gesagt Keinen, müssen Sie S1 wählen.
Rufen Sie nach der Breitstellung die Website-URL auf, werden Sie direkt vom WordPress-Installer begrüßt. Das kann bei einen F1-Serviceplan nach dem Aufruf der URL durchaus ein paar Sekunden dauern.
Der Vorteil der Lösung mit MySQL-in-App ist, dass Sie sich nicht und die Frontend-Backend-Integration von WordPress kümmern brauchen, d. h. Sie müssen selbst keine MSQL-Datenbank anlegen, keinen Benutzer mit Passwort einrichten und Beides auch nicht durch Bearbeiten der „wp-config.php“ bekannt machen. Sie müssen nur den WordPress-Einrichtungsassistenten vervollständigen beginnend mit Auswahl der Sprache. Spätestens hier wird Ihnen wahrscheinlich aufgehen, dass die kryptische App-Services-URL (hier: http://4xxepodronwiswebsite.azurewebsites.net) wahrscheinlich keine gute Idee für eine produktive Website ist. Die Azure App Services unterstützen allerdings verschiedene Möglichkeiten, einen benutzerdefinierten Domainnamen zu verwenden. Hier müssen Sie nur „in“ der Web App auf „Benutzerdefinierte Domänen“ klicken. Das Thema Domainnamen sprengt allerdings die eigentliche Zielsetzung dieses Beitrages.
WordPress auf App Service mit Flexible Server MySQL-Database
Der o. g. Use Case ist leider von Microsoft nicht supported, allerdings gibt es auch ein WordPress-Hosting direkt von Microsoft, das ebenfalls auf dem App Service basiert und eine verwaltete MySQL-Datenbank in Azure als Backend verwendet („Flexible Server für Azure MySQL Database“). Suchen Sie dazu im Marketplace nach „Wordpress on App Service“ und klicken auf „Erstellen“. Haben Sie dann wie gewohnt Ressourcengruppe, Region und einen eindeutigen DNS-Präfix für Ihre App gewählt, klicken Sie bei „Hosting Plan“ auf „Plan ändern“, um sich für einen der angebotenen Hosting-Pläne entscheiden zu können. Ferner können Sie durch Setzen der Option „Enable multisite“ mit ganz wenig Aufwand problemlos ein Multisite-Setup aufsetzen.
Zudem können Sie im Abschnitt “Erweitert“ mit Leichtigkeit die Anwendungsleistung beschleunigen, indem Sie WordPress über ein Content Delivery Network (CDN) ausliefern und damit näher an Ihre Endanwender bringen. Dies klappt wahlweise mit Hilfe des Azure-CDNs oder mit Hilfe von Azure Front Door (AFDS). Beide Optionen sind derzeit noch Preview und schließen einander aus. Während Azure CDN lediglich das Caching statischer Inhalte in der Nähe des Benutzerstandortes nutzt, ermöglicht Front Door zusätzlich eine dynamische Website-Beschleunigung, welche nicht nur die Antwortzeiten reduziert, sondern auch die Inhaltsübermittlung ermöglicht.
Sie können außerdem die vom Webserver zu bewältigende Last weiter reduzieren, indem Sie Azure Blob Storage mit dem App Service integrieren, um Bilder, Videos und andere Dateien direkt vom Speicherkonto ausliefern zu lassen, wenn Nutzer über die vom CDN generierte URL auf die Web-Anwendung zugreifen. Dies reduziert effektiv die Last auf Ihrem Webserver und verbessert so die Leistung und die Benutzerfreundlichkeit.
Außerdem wird die Word Press App automatisch mit einem virtuellen Azure-Netzwerk Ihrer Wahl integriert. Der Servername, der Datenbankname, der (Datenbank)-Benutzername (den WordPress-Benutzer haben Sie ja bereits festgelegt), das VNET und das Subnetz werden automatisch erzeugt. Sie können die entsprechenden Namen bereits vor dem Bereitstellen auf der letzten Seite des Assistenten „Wordpress auf App Service erstellen“ ablesen.
Sie finden die vorkonfigurierten Konfigurationseinstellungen wie Passwörter oder Verbindungszeichenfolgen aber auch in Anschluss an die Bereitstellung im Menü „Konfiguration“ Ihrer Web App. Die meisten dieser so genannten „Anwendungseinstellungen“ werden in Form von Umgebungsvariablen über eine verschlüsselten Kanal zur Laufzeit für den Zugriff durch die Anwendung verfügbar gemacht.
Im Unterschied zur ersten Lösung ist WordPress hier schon vollständig konfiguriert und installiert, sodass Sie die Standard-URL der Web App (hier: https://driwponappservice.azurewebsites.net/) direkt mit Ihrem Blog begrüßt.
Erstellen Sie nun unter https://driwponapp-d5ec931da7-djewe3gqgkcve9fw.z01.azurefd.net/wp-admin/edit.php einen ersten Post, der wenigstens ein grafisches Element enthält und veröffentlichen ihn, finden Sie den WordPress-Standardorder „../wp-content“ unmittelbar als Blob-Container in dem vom App Service angelegten Speicherkonto wieder.
Sie könnten außerdem mit Tools wie https://www.uptrends.com/ Uptrends ausprobieren, ob Azure Front Door seinen Zweck erfüllt und die Leistung Ihrs Blogs von weltweit verschiedenen Standorten aus testen: bei dieser mit Front Door integrierten und in Amsterdam (west Europe) betriebenen Web Anwendung erhielten wir beispielweise bei einem Test von Frankfurt Ladezeiten von in Summe ca. 300 ms.
Das ist zwar ohne Lastsimulation nicht besonders aussagekräftig, lässt sich aber gut zu Vergleichen mit anderen Standorten heranziehen.
Verantwortlich für die Anwendungsbeschleunigung ist letztendlich Azure Front Door. Der Dienst sorgt im Dank der App-Service-Integration automatisch angelegte Frond-Door-Profil einerseits dafür, dass statische Inhalte vom zugehörigen Speicherkonto in Amsterdam (West Europe) ausgeliefert werden (die für den Dienst erforderliche Datenbank „Flexible Server für Azure MySQL Database“ ist leider in Deutschland derzeit nicht verfügbar) …
... und andererseits dynamische Inhalte aus der Datenbank abgerufen und netzwerkoptimiert durch das CDN ausgeliefert werden.
WordPress on App Service mit CI/CD-Integration
WordPress ist, da es sich um eine Standard-Applikation eines Drittanbieters handelt, welche zudem eine eigene Aktualisierungsverwaltung mitbringt, nicht das optimale Beispiel für Continuous Integration.
Möchten Sie die diesbezüglichen Möglichkeiten der Azure App Service trotzdem ergründen, müssen Sie WordPress zunächst von der Produktseite herunterladen und dann wahlweise in einen lokalen-Git-Repository oder einen GitHub-Repository bereitstellen. Letztes bietet sicherlich weiterreichende Funktionen der Zusammenarbeit. Ob Sie Ihr Selfmade-Wordpress-Repository auf Github öffentlich oder privat hosten, bleibt Ihnen überlassen. Letztendlich müssen Sie – ein Github-Konto vorausgesetzt – in „GitHub/Repositories“ mit einem Klick auf „New“ zunächst ein neues Repository anlegen. Dabei legen Sie auch fest, ob Dieses „Public“ oder „Privat“ sein soll und ob automatisch eine Readme-Datei und ggf. eine Lizenz-File generiert werden sollen.
Danach können Sie den lokal heruntergeladen WordPress-Quellcode beispielsweise via „git push“ in das neue GitHub-Rep veröffentlichen oder Sie klicken bei „Quick setup“ auf „uloading an existing“ file und die ziehen die WordPress-Dateien per Drag-and-Drop in das sich öffnende Browser-Fenster. Aber Achtung: der Upload auf diesem Weg ist auf 100 Dateien pro Durchgang beschränkt. Einfacher ist daher der Upload via „git push“ von ihren lokalen WordPress-Repo aus. Das Ergebnis sollte so aussehen:
Legen sie nun händisch, d. h. ohne Verwenden einer ARM-Vorlage einen neuen Azure-App-Service an, wählen PHP 8 unter Linux als Runtimestapel sowie einen Tarifplan ihrer Wahl und erstellen zunächst die App mit „Überprüfen und Erstellen“.
Um Ihren WordPress-Quellcode bereitstellen zu können, wechseln Sie nun ins Menü „Bereitstellungscenter“ und wählen im Menü „Quelle“ als Codequelle Ihre GitHub-Konto sowie ihr oben angelegtes WordPress-Repository aus. Klicken Sie dann oben links auf „Speichern“ wird Ihr WordPress bereitgestellt. Allerdings fehlen hier im Gegensatz zum Beispiel oben noch die Verbindung zur Datenbank und die initiale Konfiguration; die im Rahmen des WordPress-Installers getriggert werden.
Dazu benötigen Sie aber zunächst eine Datenbank. Auch hier sollten Sie den „Azure Database for MySQL-Server“ verwenden. Da dieser selbstverständlich mehrere Datenbanken hosten kann, könnten Sie den Server aus dem vorherigen Beispiel problemlos verwenden.
Zwar könnten Sie hier mit “Hinzufügen“ eine neue Datenbank mit einem Namen Ihrer Wahl (hier „wp-incas“) ergänzen, Sie könnten aber auch einfach die bestehende Datenbank mit verwenden. WordPress sieht diesem Fall vor, sodass Sie später im WordPress-Installer problemlos für jedes weitere Blog einen anderen Tabellen-Präfix wählen können wie z. B. „wp1_“, „wp2_“ .. usw. (siehe unten).
Die Verbindung zur Datenbank würden Sie dann wie oben beschrieben z. B. als „Anwendungseinstellungen“ in der Web App konfigurieren. Sie können dazu aber auch den WordPress-Installer bemühen, in dem Sie die URL „https://<URL Ihrer Web App>/wp-admin/install.php) aufrufen.
Dabei weist Sie der Installer darauf hin, dass Sie für eine erfolgreiche Installation Datenbank-Name, Datenbank-Benutzername, Datenbank-Passwort und Datenbank-Name, Datenbank-Benutzername, Datenbank-Passwort und Datenbank-Host kennen müssen, mit denen der Installer die zugrundeliegende „wp-config.php“- Datei füttert. Da wir den Server auf dem zweiten Beispiel übernommen haben, können Sie die gesuchten Optionen beispielsweise in den „Anwendungseinstellungen“ der ersten Webapp ablesen.
Achtung: Da wir die zweite Lösung in diesem Beitrag (Microsoft Azure WordPress Hosting) mit VNET-Integration konfiguriert haben, wurde die zugehörige Datenbank auch mit einer einschränkenden Firewall-Regel erstellt, welche den Zugriff auf die Datenbank nur aus dem virtuellen Netzwerk zulässt.
Verwenden Sie die gleiche Datenbank wie in diesem Beispiel auch für die dritte Lösung mit selbst-gehostetem WordPress, müssten Sie auch hier die VNET-Integration für „ausgehenden Datenverkehr“ aus Sicht der Web App zulassen. Dies erreichen Sie im Abschnitt „Netzwerk“ idem Sie im Abschnitt „Ausgehenden Datenverkehr“ auf „VNET-Integration“ klicken und dann mit „+ VNET hinzufügen“ das passende VNET hinzufügen. Das klappt übriges nicht mit einem kostenlosen F1-Plan. Diesen müssen Sie dann im Menü „Aufskalieren“ zunächst auf einen B1 oder S1 updaten.
Fazit
Sie haben nun drei Varianten kennengelernt, WordPress mit seinem klassischen LAMP-Stack auf einem Azure Web App als Plattform-as-a-Service bereitzustellen, sodass Sie sich weder um Bereitstellung und Wartung der Compute-Infrastruktur, noch um Bereitstellung und Patching der Datenbank kümmern müssen. Variante 1 hostet die MysQL-Datenbank „mit“ auf dem App Service. Die Lösung basiert allerdings auf einen PHP-7.4-Stack auf Windows, der aktuell nicht mehr supportet ist. Variante 2 verwendet eine in Azure gehostete MySQL-Datenbank und macht mit der Verwendung von Front Door und Storage Accounts vom gesamten Programm der Anwendungsbeschleunigung Gebrauch. Variante 3 demonstriert die CI/CD-Integration. Im nächsten Teil widmen wir uns verschiedenen Varianten der WordPress-Bereitstellung auf Containern (Docker und Windows-Container).