Web-Anwendungen in Azure betreiben

Ein großer Teil, der im lokalen Rechenzentrum betriebenen Anwendungen ist Web-basiert – native Client-Anwendungen verlieren zunehmend an Bedeutung. Möchten Unternehmen solche Anwendungen migrieren, können sie wahlweise ihre Hyper-V/ESXi-VMs mit allen Vor- und Nachteilen von IaaS auf Azure-VMs übertragen oder sie verwenden die Azure-App-Services und erhalten damit hochverfügbare Web-Anwendungen als PaaS.

Passende Schulungen

AZ-204 Developing Solutions for Microsoft Azure (AZ-204T00)

AZ-305 – Designing Microsoft Azure Infrastructure Solutions (AZ-305T00)

Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!

Möchtest du bestehende Web-Anwendungen schnell und schmerzfrei auf Azure migrieren, ohne den bestehenden Quellcode anpassen zu müssen, ist eine Azure VM keine schlechte Wahl. Führst du die Migration im großen Stil z. B. unter Zuhilfenahme von Azure Migrate (Link) durch, kannst du dabei auch auf die in Azure Migrate verfügbaren Assessment-Tools zurückgreifen, etwa für ein möglichst optimales Sizing der Azure-VM in Hinblick auf Kosten und Performance. Trotzdem hast du vorher eine VM und hinterher eine VM mit allen Vor- und Nachteilen von IaaS, d. h. du musst dich um das Patching der Gastsysteme, der Laufzeitumgebungen (.Net, Java/Tomcat, Node etc.), des Webservers, ggf. der Datenbank und des Web-Servers selbst kümmern.

Soll deine Webanwendung hochverfügbar sein, musst du außerdem eine Loadbalancer und mehrere Instanzen deines Webservers einplanen, was bei den Kosten zu berücksichtigen ist. Verwendest du für den Loadbalancer ebenfalls Azure-VMs, musst du diese auch hochverfügbar gestalten und ggf. Lizenzkosten z. B. für F5 berücksichtigen. Hier hilft dann Azure Migrate nur noch bedingt.

Trotzdem ist eine so genannte Lift-&-Shift-Migration immer erste Wahl, wenn du keine Zeit oder Expertise hast, den Quellcode deiner Webanwendung Cloud-Ready zu machen. Es gibt aber durchaus auch andere Migrationsmuster. Microsoft liefert in seinem https://docs.microsoft.com/de-de/azure/cloud-adoption-framework/migrate/azure-best-practices/contoso-migration-overview Cloud Adoption Framework Beispiele für Anwendungsmigrationen zu Azure. Das Umpacken (Refactoring) erfordert z. B. nur minimale Änderungen der Anwendungen, so dass du eine Verbindung mit Azure-PaaS (Platform-as-a-Service) herstellen und Cloud-Angebote nutzen kannst, wie z. B. die im folgenden erläuterten Azure App Services:

App Services und Azure App Service Pläne

Unter Azure App Services versteht Microsoft eine Sammlung zu Diensten moderner Anwendungen als PaaS, darunter Web Apps, Static Web Apps, Mobil Apps, containerisierten Web Apps, API Apps. Im Prinzip gehören auch die serverlosen Dienste Logic Apps und Function Apps dazu. Während du bei den beiden Letztgenannten die Wahl zwischen serverlos und bereitgestellt hast, werden Web-Apps über einen sogenannten App Service Plan (ASP) abrechnet. Ein solcher definiert die Infrastruktur bestehend aus einer Reihe von VM-Instanzen, bzw. Scalesets (mit Loadbalancern), die zum Bereitstellen deiner Web Anwendungen benötigt werden.

Passende Schulungen

AZ-700 – Designing and Implementing Microsoft Azure Networking Solutions (AZ-700T00)

AZ-900 – Microsoft Azure Fundamentals (AZ-900T01)

AZ-900 – Microsoft Azure Fundamentals (AZ-900T01): Der AZ 900 ist der theoretische Azure Kurs für deinen Einstieg in die Cloud!

Im Gegensatz zu IaaS kümmert sich Microsoft komplett um die Bereitstellung und Betrieb der Web-Apps und der zugehörigen Servicepläne also auch um die Hardware-Basis. Das umfasst auch die Pflege und das Patching der Laufzeitumgebung oder das automatische Sichern deiner Web-Anwendung(en). Du musst dich als Entwickler nur noch um deinen Anwendungs-Code kümmern. Unterstützt werden die Laufzeitstapel .NET, Java, Node.js, PHP und Python (Windows) sowie .NET Core, Node.js, PHP oder Ruby (Linux). Service Pläne sind in unterschiedlichen Familien (Free, Shared, Basic, Standard, Premium und Isolated) und Größen (F1;D1;B1/2/3;S1/2/3;P1/2/3 usw.) verfügbar, die sich in Funktionen und Leistung (enthaltene Hardware) Funktionen unterscheiden. So enthält beispielsweise der kleinste Plan F1 (Bild links) lediglich eine nicht näher bezifferte CPU-Leistung (Compute), auseichend Arbeitsspeicher sowie 1GB Disk-Speicher, um eine oder mehrere kostenlose Web-Apps im Summe 60 min am Tag ausführen zu können. Weitere Features sind nicht enthalten. Der kostenpflichtige Produktion-Plan „P1V2“ hingegen enthält z. B. 210 ACUs Compute-Leistung, 3,5 GB Arbeitsspeicher (pro Instanz) und 250 GB Festplattenspeicher zum Ausführen deiner Web Apps. 

Dazu kommen eine Reihe interessanter Funktionen, die im Plan enthalten sind wie z. B. die Unterstützung für „Benutzerdefinierte Domänen und SSL“, „automatische Skalierung“, „Bereitstellungsslots“ und globaler Lastausgleich mittels Traffic Manager. Außerdem führt Microsoft für dich täglich Sicherungen deiner Web Apps aus. Um Kosten zu sparen kannst du nach Belieben auch mehrere Web-Apps auf dem gleichen Service Plan ausführen. Bei den Plänen der Free- und Shared-Familie ist es ohnehin so, dass du dir den Service-Plan mit anderen Kunden teilst.

Der “Isolated”-Plan hostet Apps in einer privaten, dedizierten Azure-Umgebung und eignet sich für Apps, die eine sichere Verbindung mit dem lokalen Netzwerk oder zusätzliche Leistung und Skalierung erfordern. App Service-Pläne rechnet Microsoft immer sekundengenau ab.

Der F1-Plan ist übrigens auch immer eine gute Idee, wenn du einen ursprünglich verwendeten größeren Plan eine Weile nicht benötigst, denn im Gegensatz zu IaaS (VMs) kannst du PaaS-Dienste nicht pausieren; eine Azure-VMs kannst du z. B. herunterfahren, solange du sie nicht brauchst. Das Downsizing klappt freilich nur, wenn der kleinere Plan auch die im größeren enthaltene Features abdecken kann, andernfalls müsstest du Funktionen vorab gezielt deaktivieren.

ACUs

In jedem Fall gibt Azure die Compute-Leistung von Service-Plänen in Form so genannter ACUs (Azure Compute Units) an. Hierbei handelt es sich um dedizierte Compute-Ressourcen, die zum Ausführen von im App Service-Plan bereitgestellten Anwendungen benötigt werden. Sobald du einen App Service-Plan in einer bestimmten Region erstellst, kreiert Azure in dieser Region ein Satz mit Compute-Ressourcen mit den angegeben ACUs. Insofern ist die ACU ein guter Vergleichswert um beurteilen zu können, wie „stark“ dein Service-Plan im Vergleich zu dedizieren Azure-VM-Größen ist. Derzeit ist der ACU-Wert auf für eine kleine Azure-VM vom Typ Standard_A1 mit dem Wert 100 „geeicht“. So kannst du an den anderen SKUs https://docs.microsoft.com/en-us/azure/virtual-machines/acu leicht ablesen, wie die gewählte ACU leistungstechnisch (im Vergleich zu konkreten CPU/Core-Angaben) darsteht. ACUs nutzen Intels Turbo-Technologie, um bei Bedarf Leistungssteigerungen durch Übertaktung zu erzielen.

Web App Features

Unter dem Strich bietet das Bereitstellen von  Web-Anwendungen auf Basis eines Plattform-as-a-Service wie Azure App Services;  Amazon Elastic Beanstalk oder Red Hat Open Shift zahleiche Vorteile. Diese sind bei Azure:

• verhältnismäßig hoher SLA von 99,95 ohne zusätzliche Redundanzmaßnahmen
• App Service ist ISO-, SOC- und PCI-konform.
• Entwickler können die Azure Identity Platform nutzen, um die Nutzer Ihrer Apps via  Azure Active Directory, Google, Facebook, Twitter oder Microsoft-Konto zu authentifizieren.
• Unterstützung für alle wichtigen Sprachen und Frameworks (siehe oben) einschließlich Powershell-Skripts und der Möglichkeit, ausführbare Dateien als Hintergrunddienste durchzuführen
• Alternativ Bereitstellung von Apps in Docker- oder Windows-Containern
• Globale Skalierung und Verfügbarkeit.
• Devops und CI/CD-Integration mit Unterstützung für Azure DevOps, GitHub, BitBucket, Docker Hub oder Azure Container Registry zur fortlaufenden Bereitstellung von Apps einschließlich Unterstützung für Staging-Umgebungen in Form der o. e. Bereitstellungsslots.
• Visual Studio- und Visual Studio Code-Integration
• Über 50 Connectoren zur Integration von SaaS-Lösungen wie SAP oder SAP oder Salesforce und anderen Internetdiensten (z. B. Facebook)

Der Azure Marketplace sowie die Azure Quickstarts enthalten zahlreiche Anwendungsvorlagen für Azure-App-Service-basierten Web-Anwendungen wie Drupal, Joomla oder WordPress.

Individueller Code

Du kannst deine Web-App auch einfach nur mit einer Standard-Hosting-Start-Seite bereitstellen und deinen individuellen Anwendungscode später via CI/CD-Pipeline (Azure Devops/Azure Pipelines, GitHub, Bitbucket) automatisiert aus deinem bevorzugten Quellcode-Repository oder manuell via FTP/FTPS, bzw. direkt über die Konsolen-Verbindung zu Ihrem App-Service einspielen. Microsoft beschreibt  zahlreiche Bereitstellungsvarianten für die unterstützen Sprachen-Frameworks und Technologie-Stapel /ASP.NET, Node.js, Java, Python, Ruby, Static Web Seite und auch für WordPress in seiner sehr guten https://docs.microsoft.com/en-us/azure/app-service/quickstart-wordpress Dokumentation.

Beim initialen Bereitstellen der Web-App wählst du zunächst, ob du den Code veröffentlichen oder deine Web-App in einem Container bereitstellen, bzw. eine statische Web-App erstellen möchtest. Letztes ist ein eigenständiger Azure-Service. Bei Veröffentlichen von Code wählst du dann den gewünschten Laufzeitstapel und die Region aus. Den zugrunde liegenden App-Service-Plan kannst du vorher oder direkt hier beim Konfigurieren der Web-App erstellen; Microsoft schlägt ohnehin automatisch einen Plan (Premium V2 P2v2) für 62,18 Euro/Monat vor.

Je nachdem für welchen Laufzeitstapel und welche OS-Plattform du dich entscheidest, kannst du im nächsten Schritt „Bereitstellung“ des Bereitstellungsassistenten ggf. schon deine CI/CD-Integration mit GitHub als Quell-Code-Repository und GitHub Actions als Build-Anbieter einrichten. Das gilt aber nur für diese Kombination. Andere Kombinationen von Quellcode-Anbieter und Build-Service kannst du später im Bereitstellungscenter konfigurieren. Der App Service bringt in jedem Fall auch einen eigenen Build-Service mit.

Nach Fertigstellung der App findest du auf der Übersichtsseite oben rechts die Anwendungs-URL und ggf. den von Azure erzeugten FTP/FTPS-Hostnamen nebst zugehörigen FTP-Bereitstellungsnutzer, falls du deine App doch klassisch „Betanken“ möchtest.

Die URL führt dann zur Standard-Hosting-Start-Seite des Service und hört auf den DNS-Suffix „…azurewebsites.net“. Benutzerdefinierte Domänennamen kannst du später wahlweise  mit Hilfe eines CNAME-Records bei deinen eigenen DNS-Registrar erzeugen, sofern du im Besitz einer eigenen Domäne bist oder du erwirbst eine exklusive Domain für deinen App-Service mit Hilfe des Azure-Dienstes https://docs.microsoft.com/en-us/azure/app-service/manage-custom-dns-buy-domain  App Service-Domäne für einen Festpreis von 11,99 USD/Jahr. Auf dem Service Plan selbst ist die kostingstart.html-Seite bei einem Linux-Unterbau z. B. unter /home/site/wwwroot zu finden. Das kannst du leicht verifizieren, wenn du dich unter https://<app_name>.scm.azurewebsites.net/webssh/host mit Hilfe der so genannten Kudu-Konsole via SSH mit deinem Webserver verbindest.

Das klappt, weil Kudu die Engine hinter vielen Funktionen der Azure App Services zur Bereitstellung mithilfe der Quellcodeverwaltung und anderen Bereitstellungsmethoden wie die Synchronisierung mit Dropbox und OneDrive ist. Wenn du eine Web-App erstellst, erstellt der App Service stets eine zweite, begleitende HTTPS-geschützt App, die unter der angegeben Kudu-URL erreichbar ist. So kannst du auf diesen Weg deinen individuellen Code auch mit klassischen Unix-Tools bereitstellen.  Vorrangig dient Kudu aber u. a. dazu, z. B. IIS-Speicherabbilder oder Docker-Protokollen herunterzuladen oder IIS-Prozesse und Websiteerweiterungen zu verwalten. Kudu selbst ist ein Open-Source-Projekt.

Mehr zu den unterschiedlichen Bereitstellungsoptionen wie z. B. CI/CD via GitHub, Bitbucket usw., Azure Devops, Azure Pipelines, FTPS oder Kudu, zur Konfiguration von App-Einstellungen, Standardpfaden/Handlern und Umgebungsvariablen sowie zu ergänzenden Features wie automatischer Skalierung, automatischen Sicherungen, SSL-Zertifikaten oder dem Implementieren einer Authentifizierungsebene über das Azure Identity Framework via OpenID-Connect erfährst du in weiteren Beiträgen.