---

April 2017

Band 32, Nummer 4

Dieser Artikel wurde maschinell übersetzt.

Azure: Die neue Azure App Service-Umgebung

Durch Compy Christina | April 2017

Der Azure App Service-Umgebung (ASE) ist ein Premium-Feature von Azure App Service bietet. Sie erhalten einer Einzelinstanz-Instanz von Azure App Service, mit der rechten in Ihrem eigenen Azure virtuellen Netzwerk (VNet) Maustaste, die Netzwerkisolation bereitstellen und Skalierung Funktionen verbesserte. Während die ursprüngliche Funktion Kunden mitgeteilt, was sie in Bezug auf die Steuerung und Isolation gesucht haben, war es nicht als "Platform as a Service (PaaS) wie" als normale App Service. Diese Verunsicherung Kunden hatten einige Probleme, die Verwaltung des Systems verursacht. Mit dem neu relaunched ASE funktionieren jedoch Dinge jetzt genauso wie die Multi-Tenant-App Service.

Verlauf

Azure App Service ist eine Multi-Tenant-Anwendung, die dem Dienst. Wenn Sie die HTTP-Listener-Clientanwendungen in einer PaaS-Dienst ausführen möchten, wird der App Service ist eine sehr schnelle und einfache Möglichkeit zum wechseln und verfügt über viele Entwickler unterstützen Funktionen. Sie können z. B. in fortlaufende Integration (CI)-Systeme zu integrieren, skalieren Ihre apps, sofort mit einer Bewegung der Maus und vieles mehr. Ist begrenzt, aber der Dienst, die bestimmte Anwendungsfälle blockiert.

Die Anwendungsfälle, die in der Multi-Tenant erfüllt werden konnte nicht, die App Service größtenteils um skalieren und app-Isolation zentriert. Während Sie Ihre apps problemlos in der Multi-Tenant-App Service skalieren können, ist begrenzt, die basierend auf den Preisplan. Die größte Anzahl von Instanzen eine app in der Multi-Tenant-Anwendungsdienst skaliert werden können, ist 20.

In Bezug auf Isolierung besteht keine Möglichkeit, den Zugriff auf Ihre apps in der Multi-Tenant-App-Dienst in einem Netzwerk auf Sperren. App Service verfügt über zwei Funktionen, die Zugriff auf Ressourcen in anderen Netzwerken, Integration von Azure Virtual Network (VNet) und Hybrid-Verbindungen, aber nichts, die apps, die Sie auf ein Netzwerk und keine Möglichkeit, vollkommen isoliert Internet-Host-apps in App Service sperren können. Dies bedeutet, dass Sie eine Line-of-Business (LOB)-Anwendung hosten konnte nicht, die Sie für die Multi-Tenant-Anwendungsdiensts nur auf eine private IP-Adresse möchten.

Um die Skalierung und Isolation Einschränkungen zu beheben, können wir in 2015 Premium ASE-Funktion bereitgestellt. Es ist eine Instanz von Azure App Service, die im VNet eines Kunden ausgeführt wird, mit den gleichen Code wie der Multi-Tenant-Anwendungsdienst jedoch mit einigen Änderungen Bereitstellung für die Verwendung weniger Ressourcen.

Mit der ersten Version von App Service-Umgebung könnten Sie bis zu 50 Instanzen skalieren und größere dedizierte Worker verwenden. App Service-Umgebung kann der hostenden Web-apps, mobilen apps, API-apps und Funktionen zur Verfügung. Da die Umgebung in einem Subnetz in der Customer-VNet ausgeführt wird, haben die apps in App Service-Umgebung einfachen Zugriff auf Ressourcen, die in das VNet selbst oder über ExpressRoute oder Standort-zu-Standort-VPN-Verbindungen sind. Siehe auch Abbildung 1, da die Umgebung in der Customer-Subnetz befindet, es kann Beschränken des Zugriffs auf die apps auf einer Netzwerkebene mithilfe von netzwerksicherheitsgruppen (NSGs).

Abbildung 1 App Service-Umgebung auf hoher Ebene Networking-Modell

Zu den Vorteilen dieser Bereitstellung ist Modell eine statische IP-Adresse, die sowohl die eingehende und ausgehende IP-Adresse für die apps in App Service-Umgebung verwendet werden kann. Die Art des Multi-Tenant-app Service ist, dass die eingehenden und ausgehenden Adressen von mehreren Mandanten gemeinsam verwendet werden. Es ist, zwar möglich, Einrichten von IP-SSL für eine app und eine IP-Adresse zugewiesen, die app besteht keine Möglichkeit, die ausgehende Adresse sperren.

Hosting von App Service-Umgebung in einem VNet ist ein hervorragender Start für die erste, aber es noch nicht vollständig gelöst Isolation Problem bei der ersten Veröffentlichung von App Service-Umgebung. App Service-Umgebung benötigt noch eine öffentliche VIP (virtual IP) für HTTP/S- und Veröffentlichen von Access. Es auch nur in klassischen VNets mit dem wurde ein Problem für viele Kunden bereitgestellt wird. Um diese Probleme zu lösen, Unterstützung wurde hinzugefügt, im Juni 2016 für Ressourcen-Manager-VNets und auch für internen Lastenausgleich (ILBs), siehe Abbildung 2.

Abbildung 2 App Service-Umgebung auf hoher Ebene Netzwerk mit einem internen Lastenausgleich

Das Hinzufügen von ILB-Unterstützung vorgesehen, dass Kunden nun Intranetwebsites in der Cloud gehostet werden können. Sie übernimmt eine LOB-Anwendung, die Sie nicht Internet zugegriffen werden und in der ILB-fähigen Umgebung bereitstellen möchten. Die ILB befindet sich auf einem von der VNet-IP-Adressen, also Zugriff ist nur innerhalb des Vnets oder Hosts, die im vnet über ein VPN zugreifen können.

Die ILB-fähigen Umgebung öffnen die Tür zu anderen Möglichkeiten, z. B. Web Application Firewall (WAF)-vorgelagert und zwei-Ebenen-Anwendungen. WAF vorgelagert ASE handelt konnte ein Kunde ein WAF virtuelles Gerät verwenden als Internet-Endpunkt für den ILB ASE gehosteten apps, die zusätzliche Sicherheitsstufe für Internet zugänglichen apps hinzufügt. In einer 2-Ebenen-Anwendung die webbasierte Anwendung konnte in der Multi-Tenant-app-Dienst oder von einer anderen Umgebung gehostet werden, und der Back-End-gesicherte API-apps können dann in der ILB-Umgebung gehostet werden. Wenn Sie die Multi-Tenant-App-Dienst für diesen Zweck verwendet, verwenden Sie die VNet-Integrationsfunktion dann, den sicheren Ihrer API-apps Zugriff auf herunterladen.

Wenn die ASE ursprünglich entworfen und geplant war, wurde davon ausgegangen, dass es für IT-Experten würde diese persönlichen Bereitstellung des App Service steuern möchte berücksichtigen würde, als ob es ein System handelt, die sie in ihren eigenen Rechenzentren ausgeführt wurden. Denken Sie daran, wurde ASE so konzipiert, flexibel sein. Eine Umgebung verfügt über zwei Rollen verwalten: die Front-ends, die sich als HTTP-Endpunkte für ASP.NET-Anwendungen und die Arbeitskräfte, die die apps hosten. Sie können horizontale Skalierung entweder die Menge sowie Ändern der Größe des virtuellen Computers (VM) für diese Rolle verwendet.

Es wurden bestimmte Konsequenzen zu denken auf diese Weise – ASE Rollen wurden als Ressourcen, die Systemadministratoren unabhängig verwalten würde, aber es stellte sich heraus, dass Kunden wollten oder über die Systemadministratoren für ihre Clouddienste behandelt. Die Umgebung so einfach zu verwenden wie die Multi-Tenant-Anwendungsdienst bleiben sollte. Verwaltung von Ressourcenpools und ihre apps zu war verwirrend und wurde betroffenen Funktion Annahme.

Die neue Umgebung

Nach der ersten Version von App Service-Umgebung (die als ASEv1 bezeichnet werden) wurde freigegeben, gab es umfangreiches Feedback von Kunden, die es ausprobiert und festgestellt, dass sie ihren geschäftlichen Anforderungen für einen oder anderen Grund angepasst haben. Die Hauptgründe, betreffenden erhalten haben:

• Die Komplexität der Verwaltung von Rollen ASEv1 sowie ihre apps war mühsam und nicht intuitiv.
• Hinzufügen von mehr Kapazität zu App Service-Umgebung hat zu lange gedauert. Da ASEv1 erstellt wurde, um die von Systemadministratoren für ihre Mandanten ausgeführt werden, wurden die Sorge wie schnell die Rollen bereitgestellt wurden. In Wirklichkeit war, dass ASEv1 verwendet wurde, die Person, die die Rollen ASE skaliert und derjenige, der die Anwendung bereitgestellt in der Regel ein und dieselbe wurden und die Verzögerung ein Problem aufgetreten ist.
• Das Verwaltungsmodell System gezwungen Kunden weitaus berücksichtigen die ASE-Architektur und das Verhalten als werden sollte.

Dies bringt uns auf die neue Version von App Service-Umgebung, die ASEv2 aufgerufen werden. Das Team hat das Feedback zu Herzen und für ASEv2 wir darauf konzentriert, die UX dieselbe wie in der Multi-Tenant-Anwendungsdiensts ohne Verlust von den Vorteilen, die ASEv1 bereitgestellt.

Erstellen einer App Service-Plan die App Service-Plans (ASP) ist ein Container mit der Skalierung, alle apps enthält. Alle apps im ASPs und beim Skalieren der ASP-Seite, Sie sind auch Skalieren alle apps im ASP. Dies gilt für die Multi-Tenant-App Service und App Service-Umgebung. Dies bedeutet, dass zum Erstellen einer app müssen Sie entweder auswählen oder erstellen ein ASP. So erstellen Sie eine ASP in ASEv1 Sie zum Auswählen einer App als den Speicherort, und wählen Sie dann einen workerpool mussten Siehe Abbildung 3. Wenn die workerpool bereitstellen möchten, genügend Kapazität hätte, müssten Sie mehrere Mitarbeiter hinzufügen, bevor Sie diese ASP erstellen konnte.

Abbildung 3: Erstellen einer App Service-Plan in ASEv1

Mit ASEv2 beim Erstellen eines ASP wählen Sie die Umgebung weiterhin als Ihren Standort, aber anstelle Kommissionierung ein workerpool Sie Tarif Karten verwenden, wie Sie außerhalb der Umgebung. Es gibt keine weitere workerpools verwalten. Beim Erstellen oder ASP skalieren, werden die notwendigen Arbeitskräfte automatisch hinzugefügt.

ASEv2 umfasst aktualisierte VMs, die verwendet werden, um Ihre apps zu hosten. Worker für ASEv2 basieren auf den VMs Dv2-Serie und übertreffen die Arbeitskräfte in der Multi-Tenant-app-Dienst verwendet. Zur Unterscheidung zwischen ASPs, die in einer ASE sind und in der Multi-Tenant-Dienst wurde ein neuer Tarif SKU erstellt. Der Name dieser SKU ist isoliert, siehe Abbildung 4. Wenn Sie eine isolierte SKU auswählen, bedeutet dies, dass Sie die zugehörigen ASP-Seite in eine ASEv2 erstellt werden soll.

Abbildung 4: Erstellen einer App Service-Plan in ASEv2

Erstellen einer app eine andere Probleme, die Annahme ASE beeinträchtigt wurde, seine Mangelnde Transparenz. Viele Kunden wissen nicht, dass die Funktion ASE vorhanden war. Zum Erstellen einer App musste ASE Erstellung eine Übersicht, Suchen von app-Erstellung vollständig getrennt wurde. In ASEv1 Kunden mussten, Mitarbeiter ihre workerpools hinzufügen, um die Pläne zu erstellen. Nun, dass Mitarbeiter automatisch hinzugefügt werden, wenn ASPs erstellt oder skaliert werden, die ASEv2 Erstellung Erfahrung platziert werden direkt im Fluss ASP erstellen, siehe Abbildung 5.

Abbildung 5: Erstellen einer App Service-Umgebung aus den App Service Plan Datenfluss der Erstellung

Zum Erstellen einer neuen ASEv2 bei der Erstellung der ASP einfach nicht ASE Region auswählen und wählen Sie dann eine neue isolierte SKU-Karten. Wenn Sie dies tun, wird die Benutzeroberfläche zur Erstellung ASE angezeigt, dem können Sie eine völlig neue ASEv2 in einem neuen oder bereits vorhandenen VNet zu erstellen.

Zeit zum Skalieren der neue ASP Erstellung Fluss war möglich, da der Prozess für die Bereitstellung neuer Arbeitskräfte beschleunigt wurde. ASEv2 stellt automatisch neue Mitarbeiter für Ihre Pläne bereit, bei der Erstellung oder skalieren ein ASP. Die einzige Möglichkeit, dies eine sinnvolle Kundenzufriedenheit, wurde reduziert die erforderliche Zeit zum Erstellen und zu skalieren. Damit dies funktioniert, so weit wie möglich, werden auf die virtuellen Festplatten für die Bereitstellung der Rolleninstanzen verwendet zusätzliche erforderlichen Neustarts minimieren. Verschieben in die Arbeitskräfte Dv2 war auch hilfreich, schnellere Kerne verfügen und SSDs verwenden. Beide dieser Methoden beschleunigen installieren und neu gestartet.

Systemmanagement In ASEv1 musste, dass der Kunde im Vordergrund verwalten endet, Arbeitskräfte und Arbeitskräfte Domäne aktualisieren. Die Front-End-Rollen Behandeln von HTTP-Datenverkehr und Datenverkehr an die Arbeitskräfte senden. Die Arbeitskräfte sind die virtuellen Computer, die Ihre apps zu hosten. Update Domäne Worker fungieren als standby-Hosts bei Upgrades oder Worker-Fehlern. Der Kunde musste mit ASEv1 wissen, wie diese Komponenten alle zusammen gearbeitet, und Skalieren die Ressourcenpools entsprechend. Wenn Mitarbeiter skaliert werden musste, um weitere Instanzen von ASP zu behandeln, mussten Benutzer weitere front-Ends hinzufügen und Aktualisieren von Domäne Worker.

ASEv2, blendet im Gegensatz dazu entfernt die Infrastruktur. Jetzt Benutzer einfach skalieren ihrer App Service-Pläne und die Infrastruktur nach Bedarf hinzugefügt wird. Wenn eine ASP mehr Worker erforderlich ist, werden die Arbeitskräfte hinzugefügt. Front-Ends und Update Domäne Worker werden automatisch hinzugefügt, wie die Anzahl der Worker dezentral skaliert wird. Wenn Kunden außergewöhnliche Anforderungen erfordern aggressivere Skalierung von Front-End-, können sie die Rate ändern, an der front-Ends ihre App hinzugefügt werden.

Siehe ASEv2 Portalseite in Abbildung 6, Dinge sind nun wesentlich einfacher. Es ist nicht mehr benötigt den Front-End-UI-Seiten oder workerpool. Jetzt Skalierung automatisch, es sind keine weitere Skalierung oder automatische Skalierung Steuerelemente. Und da die IP-Adressen, die von der Umgebung verwendeten ziemlich wichtig, zu verstehen sind, die Benutzeroberfläche dieser Informationen zusammengefasst.

Abbildung 6 App Service-Umgebung Version 2 Portal Seite

Die Version von ASEv2 ist keineswegs am Ende der ASE Feature-Entwicklung. Es ist weiterhin einen stetigen Strom Verbesserungen, aber hat keine Auswirkung auf die UX in dem Umfang der Änderungen mit ASEv2 durchgeführt haben.

Zusätzliche Vorteile aufgrund der Systemarchitektur vorgenommenen Änderungen, ASEv2 hat einige zusätzliche Vorteile ASEv1. Mit ASEv1 wurde der maximale Standardwert 50 Mitarbeiter. Es gab eine Reihe von Systemarchitektur Gründe, warum dieser Grenzwert festgelegt wurde, aber diese Probleme wurden behoben, bei der Erstellung der neuen ASEv2-Oberfläche. Mit ASEv2 ist die maximale jetzt 100, dies bedeutet, dass Sie bis zu 100 ASP-Instanzen, die in ASEv2 gehostet haben können. Dies kann alles von 100 Instanzen von einer ASP zu 100 einzelne ASPs mit nichts dazwischen sein.

Darüber hinaus verwendet ASEv2 jetzt Dv2 dedizierten Mitarbeiter. Diese neue dedizierte Mitarbeiter sind viel schneller als eine Reihe VMs ASEv1 abhängen. Sie verfügen über schnellere CPUs, erhöht sich Durchsatz und SSDs, wodurch Dateizugriff verbessert. Wie im Multi-Tenant-app-Dienst sind die Optionen für dedizierte Worker beim Erstellen eines ASP single-Core, dual-Core oder Quad-Core. Die neue ASE dedizierte Worker jedoch double Speicher ihrer Multi-Tenant-Gegenstücke haben und mit 3,5 GB, 7 GB oder 14 GB Arbeitsspeicher, bzw..

Zusammenfassung

ASEv1 ist ein wichtiger erster Schritt in Richtung durch die Kunden haben Netzwerkisolation für ihren App Service gehostete Anwendung. Basiert auf ASEv2, die eine weitaus PaaS-ähnliche Funktion auftreten, die nicht nur einfacher zu verwenden, ist aber auch sehr viel leistungsfähiger ist.

Alle Änderungen, die hier für die Umgebung erwähnt wurden haben durch eine große Anzahl von Kunden und MVPs editiert wurden. Vor der Entwicklung begonnen, wollte das Team den Ansatz mit Personen zu überprüfen, die mit einer App bereits versucht hat. Mit dieser Methode Eingabe ausschließlichem sind wir davon überzeugt, dass die neue Umgebung für ASE betrachtet eine wesentliche Verbesserung und freuen uns auf ihren Erfolg in das Feld.

---

Christina Compyist ursprünglich ein Luft-und Techniker, die das Hubble Speicherplatz Beobachtungsfernrohr gearbeitet und verfügt über mehr als 20 Jahren in der Softwarebranche arbeitet.  Sie wurde als Programmmanager bei Microsoft seit 2013 und arbeitet auf Unternehmen ausgerichteten Funktionen.

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels:  Stefan Shackow
Stefan ist Programmmanager im Azure App Services-Team, in der Web-app-Cloud bietet seit den Anfangszeiten gearbeitet hat. Stefan führt Azure ein Team von Programm-Managern, die an der Entwicklung und Bereitstellung von Azure App Service sowie die Entwicklung der Produkte von Microsoft auf-hybride arbeiten.