Laden...

Organisation von Web App Projekten in Azure

Erstellt von JimStark vor 3 Jahren Letzter Beitrag vor 3 Jahren 303 Views
JimStark Themenstarter:in
309 Beiträge seit 2020
vor 3 Jahren
Organisation von Web App Projekten in Azure

Hi,

angenommen ich will eine einfache Website mit ASP.NET bauen.
Teile sind einfache statische HTML Seiten, aber auch aus der Datenbank erzeugte Seiten (z.B. ein Blog).

Das ganze Projekt soll möglichst effizent mit Azure aufgebaut werden.

  1. Verbindung DB und Web App
    Darüber habe ich in den Docs jetzt zwei Vorgehensweisen gesehen. Entweder ein virtuelles Netz aufbauen in dem Web App und Datenbank sind oder die Web App-IPs auf die Whitelist der Datenbank-Firewall geben. Gibt es einen besonderen Vorteil mit dem Virtuellen Netz oder reicht die Firewall-Freigabe?

  2. Bilder/Inhalte der Website
    Um Bilder anzuzeigen, sollte man ja wahrscheinlich einen Blob Storage nutzen. Verlinke ich da einfach die Direkt-URLs der Bildddateien im HTML-Code? Also bleiben die statisch? Oder sollte ich mich in der Web App damit verbinden und die Links automatisch erzeugen.
    Sollte man css-Dateien, js,... auch in den Blob Storage stecken?

Die Blog Posts sollen in Cosmos DB gespeichert werden.
Um den Inhalt des Blogpostes formatieren zu können, könnte ich ja den Bloginhalt als HTML in dem Post-Objekt speichern und dann in Razor-Pages per @Html.Raw(Model.HtmlContent) rendern. Gibt es da noch eine schönere Variante oder kann man das so machen?

Danke!

16.806 Beiträge seit 2008
vor 3 Jahren

Gibt es einen besonderen Vorteil mit dem Virtuellen Netz oder reicht die Firewall-Freigabe?

Les mal den Absatz ganz, dann siehst Du, dass Du mit der generellen Azure Freigabe alle Azure-Endpunkte erlaubst.
Also nicht nur die Deines Tenants, sondern jede Verbindung aus Azure - egal von wem.

Das isolierte Netz ist dafür gedacht, dass Du so eine komplette Trennung von allem anderen erreichst und dann zB. nur die App drauf zugreifen lassen kannst.
Das isolierte Netz ist aber nur im teuersten Premium-Plan verfügbar, da Du hier eine physikalisch isolierte Instanz bekommst.
Das ist also eher selten.

Eine erhöhte Sicherheit bekommst Du mit System Identities, mit der Du dann gewährleisten kannst, dass nur Ressourcen aus Deinem AAD Tenant mit der Datenbank kommunizieren kann.

Bilder/Inhalte der Website

Gibt hier viele verschiedene Wege.

Mein Blog liefert das einfach vom App Storage; der Benefit von CDN ist hier eher gering.
Das Forum liefert den Content aus dem Blob: in der Datenbank liegt der Unique Blobname und beim Ausliefern wird der CDN-Link zusammen gebaut.

Bei der Detailansicht (aka "Download eines Attachments) liefert das Forum eine HEAD-Antwort mit der Url zum CDN.
Dadurch können wir die Zugriffe kontrollieren / steuern / whatever.

Sollte man css-Dateien, js,... auch in den Blob Storage stecken?

Kann man; muss man nicht.
Macht das DevOps komplexer und lohnt sich i.d.R. nur bei größeren Anwendungen.

Gibt es da noch eine schönere Variante oder kann man das so machen?

Hat mit Azure wenig am Hut, aber rohes HTML zu speichern ist halt immer so ne Sache.
Raw() hat halt immer ein Restrisiko.

Mein Blog hat einfach Markdown-Dateien, die als Quelle dienen und das Razor rendert einfach Markdown.
Gleiches Prinzip hat das Forum hier: wir speichern BBCode / Markdown in der Datenbank und Rendern beim Ausliefern. Wir brauchen nirgends Html.Raw und haben damit auch das potentielle Risiko von Content Injection nicht.

JimStark Themenstarter:in
309 Beiträge seit 2020
vor 3 Jahren

Danke für die ausführliche Antwort.

Les mal den Absatz ganz, dann siehst Du, dass Du mit der generellen Azure Freigabe alle Azure-Endpunkte erlaubst.
Also nicht nur die Deines Tenants, sondern jede Verbindung aus Azure - egal von wem.

Verbindungen vom öffentlichen Azure Netzwerk habe ich deaktiviert, nur Portal. Also sicherheitstechnisch würde es für mich ausreichen die IPs von der Web App in der DB Firewall zu erlauben?

Mein Blog liefert das einfach vom App Storage; der Benefit von CDN ist hier eher gering.

App Storage ist jetzt einfach der Storage der Web App? Also z.B. die Bilder bleiben im wwwroot des Repos das deployt wird?
Gibt es bei dem Basic Tarif auch irgendeine Traffic-Beschränkung? FInde dazu leider nichts. Habe bei Free Nutzungskontingente für ausgehende Daten und das wäre bei vielen Besucher schnell erreicht.

Mein Blog hat einfach Markdown-Dateien, die als Quelle dienen und das Razor rendert einfach Markdown.

Gute Idee, das werde ich auch machen

16.806 Beiträge seit 2008
vor 3 Jahren

Verbindungen vom öffentlichen Azure Netzwerk habe ich deaktiviert, nur Portal.

Was ist ein "öffentliches Azure Netzwerk"?
Es gibt nur: Azure-only Connections und Everyone.

Also sicherheitstechnisch würde es für mich ausreichen die IPs von der Web App in der DB Firewall zu erlauben?

Welche IP Adresse willst denn erlauben?
Nur der isolierte Plan hat eine fixe Adresse. Deswegen heisst er isolierter Plan, weil Du dedizierte / fixe Ressourcen bekommst.

Im Standard Plan kannst theoretisch auch nen VNet setzen, aber auch nur mit den neuen Standard Plänen.
Beim VNet spielt dann die IP weniger eine Rolle, weil Du ja dann ein privates Netz zwischen zwei Ressourcen hast und alles andere verbietest.

Du hast aber den Basic Tarif genannt, da hast Du überhaupt keine Möglichkeit irgendeine VNET oder dedizierte IP zu erhalten.
Geht einfach auch nicht, weil der Basic Tarif natürlich nur shared resources hat.
Aber wie gesagt: System Identity.

App Storage ist jetzt einfach der Storage der Web App?

Richtig.

Also z.B. die Bilder bleiben im wwwroot des Repos das deployt wird?

Richtig.

Gibt es bei dem Basic Tarif auch irgendeine Traffic-Beschränkung?

Siehe Pricing Übersicht des Traffics.

Mit einem App Service buchst Du Leistung, keine Bandbreite.
Daher ist hier auch nichts enthalten.

Habe bei Free Nutzungskontingente für ausgehende Daten und das wäre bei vielen Besucher schnell erreicht.

Definier viele Besucher. 10? 100? 100000? Pro Stunde? Pro Tag?

Aber Bandbreite kann man optimieren; vor allem bei statsichem Content.
zB eben mit CloudFlare.

Mein Blog erzeugt ca. 30 GB Daten / Monat an Besucher.
Davon werden aber 28 GB durch CloudFlare zwischengespeichert, sodass nur 2GB an Azure ankommen.
Ich schreib nen Artikel ein mal und dann verändert der sich nich so schnell. Gibt keinen dynamischen Content, sodass mein Content 7 Tage im CF Cache liegt.
Und den Blog betreibe ich mit dem aller kleinsten 11€ App Service und komme selbst in Peaks nicht über 15% CPU; aber wie auch bei 99% statischem Inhalt 😉
Nen App Service Plan mit VNet Support beginnt halt bei 100+€. Da brauchst also schon nen sehr sehr sehr gut laufenden Blog, dass sich das lohnt.

Das Forum hier erzeugt eher so 150 GB Daten / Monat. Es kann aber viel weniger gecached werden, sodass die Quote vom Cache hier nur 7% ist.