WordPress-Deployment in der Microsoft-Cloud: die Varianten
IaaS versus PaaS: Teil 1 – WordPress on App Service
In fast allen unseren Azure-Kursen geht es (auch) um die verschiedenen Wege, Anwendungen – insbesondere Webanwendungen 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. Die einzelnen Kurse bieten jedoch nicht den zeitlichen Rahmen, die einzelnen Varianten an einem konkreten Beispiel durchzuspielen.
Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!
Dieses 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. Du kannst die gewonnenen Erkenntnisse auch problemlos 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 du dich für die eine oder andere Variante (VM, Container, Webapp) entscheidest, 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 dein 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 unterscheidet. 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
Du erahnst 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 nativer Web-Anwendungen unter Windows und Linux, sowie das Hosten containerisierter 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 https://azure.microsoft.com/en-us/blog/mysql-in-app-preview-app-service/ 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, kommst du 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 https://github.com/azure-deprecation/dashboard/issues/110 EOL von PHP 7.4 im Allgemeinen, sowie am nicht mehr vorhandenen PHP-Support der Azure App Services auf Windows ab PHP 8. Das merkst du u. a. daran, dass du bei Verwendung des Azure-Portals in den App Services bei Auswahl von „PHP“ als Software-Plattform nicht mehr „Windows“ als Hardware-Stack wählen kannst, was in diesem Fall ausgegraut ist.
Es gibt jedoch in den Azure Quickstart Templates ein fertiges ARM-Template für https://learn.microsoft.com/de-de/samples/azure/azure-quickstart-templates/wordpress-app-service-mysql-inapp/ WordPress on App Service with MySQL In App, mit dem du dein WordPress-Blog in Azure App Service mit maximal 3 Mausklicks bereitstellen kannst.
Mit „Deploy to Azure“ leitest du die Bereitstellung im Azure-Portal ein. An Parametern bedarf es lediglich einer Ressourcengruppe, einer Region und einer SKU. Wählst du bei letzterer „F1“, kannst du deinen WordPressblog kostenfrei ausprobieren, darfst aber dabei keine Performance-Wunder erwarten. Verzichte auf automatische Skalierung, denn F1 stellt nur 60 Minuten am Tag Compte-Leistung zur Verfügung. Bei einem geplanten produktiven Einsatz – Support-Anspruch hast du wie gesagt keinen – musst du S1 wählen.
Rufst du nach der Breitstellung die Website-URL auf, wirst du direkt vom WordPress-Installer begrüßt. Das kann bei einem F1-Serviceplan nach dem Aufruf der URL ein paar Sekunden dauern.
Der Vorteil der Lösung mit MySQL-in-App ist, dass du dich nicht um die Frontend-Backend-Integration von WordPress kümmern brauchst, d. h. du musst selbst keine MSQL-Datenbank anlegen, keinen Benutzer mit Passwort einrichten und beides auch nicht durch Bearbeiten der „wp-config.php“ bekannt machen. Du musst nur den WordPress-Einrichtungsassistenten vervollständigen, beginnend mit Auswahl der Sprache. Spätestens hier wird dir wahrscheinlich auffallen, 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 musst du 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 Flexibler Server MySQL-Database
Der o. g. Use Case ist leider von Microsoft nicht supported, allerdings gibt es 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“). Suche dazu im Marketplace nach „Wordpress on App Service“ und klicke auf „Erstellen“. Hast du dann wie gewohnt Ressourcengruppe, Region und einen eindeutigen DNS-Präfix für deine App gewählt, klicke bei „Hosting Plan“ auf „Plan ändern“, um dich für einen der angebotenen Hosting-Pläne entscheiden zu können. Durch Setzen der Option „Enable multisite“ kannst du mit ganz wenig Aufwand problemlos ein Multisite-Setup aufsetzen.
Zudem kannst du im Abschnitt “Erweitert“ mit Leichtigkeit die Anwendungsleistung beschleunigen, indem du WordPress über ein Content Delivery Network (CDN) auslieferst und damit näher an deine Endanwender bringst. 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, die nicht nur die Antwortzeiten reduziert, sondern auch die Inhaltsübermittlung ermöglicht.
Du kannst außerdem die vom Webserver zu bewältigende Last weiter reduzieren, indem du Azure Blob Storage mit dem App Service integrierst, 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. Das reduziert effektiv die Last auf deinem Webserver und verbessert so die Leistung und die Benutzerfreundlichkeit.
Außerdem wird die Word Press App automatisch mit einem virtuellen Azure-Netzwerk deiner Wahl integriert. Der Servername, der Datenbankname, der (Datenbank)-Benutzername (den WordPress-Benutzer hast du ja bereits festgelegt), das VNET und das Subnetz werden automatisch erzeugt. Du kannst die entsprechenden Namen bereits vor dem Bereitstellen auf der letzten Seite des Assistenten „Wordpress auf App Service erstellen“ ablesen.
Du findest die vorkonfigurierten Konfigurationseinstellungen wie Passwörter oder Verbindungszeichenfolgen auch im Anschluss an die Bereitstellung im Menü „Konfiguration“ deiner Web App. Die meisten dieser so genannten „Anwendungseinstellungen“ werden in Form von Umgebungsvariablen über einen 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 du die Standard-URL der Web App (hier: https://driwponappservice.azurewebsites.net/) direkt mit deinem Blog begrüßt.
Erstelle unter https://driwponapp-d5ec931da7-djewe3gqgkcve9fw.z01.azurefd.net/wp-admin/edit.php einen ersten Post, der wenigstens ein grafisches Element enthält und veröffentliche ihn, ….
… finde den WordPress-Standardorder „../wp-content“ unmittelbar als Blob-Container in dem vom App Service angelegten Speicherkonto wieder.
Du kannst außerdem mit Tools wie https://www.uptrends.com/ Uptrends ausprobieren, ob Azure Front Door seinen Zweck erfüllt und die Leistung deines 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 zum Vergleich mit anderen Standorten heranziehen.
Verantwortlich für die Anwendungsbeschleunigung ist letztendlich Azure Front Door. Der Dienst sorgt Dank der App-Service-Integration automatisch angelegte Frond-Door-Profile 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 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, die eine eigene Aktualisierungsverwaltung mitbringt, nicht das optimale Beispiel für Continuous Integration.
Möchtest du die Möglichkeiten der Azure App Service trotzdem ergründen, musst du WordPress zunächst von der Produktseite herunterladen und dann wahlweise in einen lokalen-Git-Repository oder einen GitHub-Repository bereitstellen. Letzterer bietet sicherlich weiterreichende Funktionen der Zusammenarbeit. Ob du dein Selfmade-Wordpress-Repository auf Github öffentlich oder privat hostest, bleibt dir überlassen. Letztendlich musst du – ein Github-Konto vorausgesetzt – in „GitHub/Repositories“ mit einem Klick auf „New“ zunächst ein neues Repository anlegen. Dabei legst du fest, ob dieses „Public“ oder „Privat“ sein soll und ob automatisch eine Readme-Datei und ggf. ein Lizenz-File generiert werden sollen.
Danach kannst du den lokal heruntergeladen WordPress-Quellcode beispielsweise via „git push“ in das neue GitHub-Rep veröffentlichen oder du klickst bei „Quick setup“ auf „uploading an existing“ file und ziehst 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 deinem lokalen WordPress-Repo aus. Das Ergebnis sollte so aussehen:
Lege nun händisch, d. h. ohne Verwenden einer ARM-Vorlage einen neuen Azure-App-Service an, wähle PHP 8 unter Linux als Runtimestapel sowie einen Tarifplan deiner Wahl und erstelle die App mit „Überprüfen und Erstellen“.
Um deinen WordPress-Quellcode bereitstellen zu können, wechsele nun ins Menü „Bereitstellungscenter“ und wähle im Menü „Quelle“ als Codequelle deines GitHub-Konto sowie dein oben angelegtes WordPress-Repository aus. Klicke dann oben links auf „Speichern“ und dein WordPress wird 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ötigst du zunächst eine Datenbank. Auch hier solltest du den „Azure Database for MySQL-Server“ verwenden. Da dieser selbstverständlich mehrere Datenbanken hosten kann, kannst du den Server aus dem vorherigen Beispiel problemlos verwenden.
Zwar könntest du hier mit “Hinzufügen“ eine neue Datenbank mit einem Namen deiner Wahl (hier „wp-incas“) ergänzen, du kannst aber auch einfach die bestehende Datenbank verwenden. WordPress sieht diesen Fall vor, sodass du später im WordPress-Installer problemlos für jedes weitere Blog einen anderen Tabellen-Präfix wählen kannst, wie z. B. „wp1_“, „wp2_“ .. usw. (siehe unten).
Die Verbindung zur Datenbank würdest du dann wie oben beschrieben z. B. als „Anwendungseinstellungen“ in der Web App konfigurieren. Dazu kannst du auch den WordPress-Installer bemühen, in dem du die URL „https://<URL Ihrer Web App>/wp-admin/install.php) aufrufst.
Dabei weist dich der Installer darauf hin, dass du für eine erfolgreiche Installation Datenbank-Name, Datenbank-Benutzername, Datenbank-Passwort und Datenbank-Name, Datenbank-Benutzername, Datenbank-Passwort und Datenbank-Host kennen musst, mit denen der Installer die zugrundeliegende „wp-config.php“- Datei füttert. Da wir den Server aus dem zweiten Beispiel übernommen haben, kannst du 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.
Verwendest du die gleiche Datenbank wie in diesem Beispiel auch für die dritte Lösung mit selbst-gehostetem WordPress, müsstest du auch hier die VNET-Integration für „ausgehenden Datenverkehr“ aus Sicht der Web App zulassen. Das erreichst du im Abschnitt „Netzwerk“, indem du im Abschnitt „Ausgehenden Datenverkehr“ auf „VNET-Integration“ klickst und dann mit „+ VNET hinzufügen“ das passende VNET hinzufügst. Das klappt übriges nicht mit einem kostenlosen F1-Plan. Diesen müsstest du im Menü „Aufskalieren“ zunächst auf einen B1 oder S1 updaten.
Fazit
Du hast nun drei Varianten kennengelernt, WordPress mit seinem klassischen LAMP-Stack auf einem Azure Web App als Plattform-as-a-Service bereitzustellen, sodass du dich weder um Bereitstellung und Wartung der Compute-Infrastruktur, noch um Bereitstellung und Patching der Datenbank kümmern musst. 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).
Kontakt
„*“ zeigt erforderliche Felder an
powered by Borlabs Cookie