BlogWeb-Anwendungen in Azure betreiben

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.

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.

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.

Compute-Leistung zum Ausführen von Azure Web Apps werden in Form von Service-Plänen abgerechnet.

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.

WordPress gibt es z. B. als Vorlage zur Bereitstellung als Web-App im Marketplace oder den Quickstarts

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.

Das Erstellen einer Web-App erfordert nur wenige Angaben, darunter der gewünschte Laufzeitstapel.

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.

Seit der Übernahme von GitHub im Jahr 2018, gehören GitHub/GitHub Actions zu den bevorzugten Devops-Toolsets in Azure.

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 Übersichtsseite Ihrer Web-App zeigt oben rechts die Anwendungs-URL.

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.

Die in wenigen Minuten bereitgestellte Web-App mit der Hostingstart-Seite.

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.

Mit Hilfe von Kudu erhalten Sie unter anderem auch eine SSL-gesicherte SSH-Sitzung zu Ihrer Web-App.

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.

Kontakt

Dein INCAS Team
Akkordion öffnen
telephone-icon-contact-coaching-box
0800 4772466
email-icon-contact-coaching-box
info@incas-training.de

*“ zeigt erforderliche Felder an

Hidden
Dieses Feld dient zur Validierung und sollte nicht verändert werden.

Schulungen die dich interessieren könnten

Bewertungen

Kundenstimme männlich
Torsten B.
Westdeutscher Rundfunk WDR
star-participantstar-participantstar-participantstar-participantstar-participant
Das Seminar hat nicht nur Spaß gemacht, sondern auch wirklich 'ne Menge gebracht :-)
Kundenstimme männlich
Martin S.
Bundeseisenbahnvermögen
star-participantstar-participantstar-participantstar-participantstar-participant
Das Training zeichnet sich durch einen sehr hohen Praxisbezug und Raum für individuelle Hilfe persönlicher Problemstellungen sowie durch einen engagierten und hoch kompetenten Trainer aus.
Kundenstimme männlich
Thomas M.
Aldi GmbH & Co. KG
star-participantstar-participantstar-participantstar-participantstar-participant
Lernen in einem sehr entspannten und angenehmen Klima. Prima!
Kundenstimme männlich
Markus H.
CARAT Dreieich
star-participantstar-participantstar-participantstar-participantstar-participant
Der Trainer machte einen sehr netten und kompetenten Eindruck und ging auf unsere Wünsche und Anregungen sehr praxisorientiert ein .