Hoste eine Webseite in Azure

Ich hatte neulich einen Kunden, der eine interne HTML-basierte Webseite mit PDF Berichten hostet. Diese Seite war mal auf einem Webserver im internen Unternehmensnetz gespeichert, soll aber nun aus dem Internet erreichbar sein, damit per Smartphone darauf zugegriffen werden kann.

Die HTML-Seiten der Webseite selber werden übrigens mittels Excel und vieler Makros generiert. Das ist auch ein spannendes Konstrukt, aber von dem erzähle ich euch ein anders Mal.

Es gibt an das Hosting der Webseite einige Anforderungen:

• Sie soll nur für Mitarbeiter des Unternehmens sichtbar sein
• Der bestehende Erzeugungsmechanismus soll bestehen bleiben. Nur der bisherige “Kopier” Mechanismus auf den lokalen Webserver soll durch einen ebenso einfachen anderen Mechanismus ersetzt werden.

Das können wir mittels Azure und einer kleinen “nodejs” Anwendung abbilden

Eine Webapp im Azure anlegen

Legen wir zunächst die Webseite im Azure an. Dazu öffnen wir zuerst die Azure Startseite

https://portal.azure.com/↗

und suchen dann oben in der Suchleiste nach “App Services”.

Dann wählen wir oben links “Create” und erstellen eine neue Web App.

Nun gelangen wir auf den Erstellungsformular einer neuen Webapp. Hier müssen wir zunächst eine ResourceGroup anlegen. Das ist eine Art Ordner, der verschiedene inhaltlich zusammengehörende Azure Dienste bündelt. Ich wähle hier “HTMLFileHosting”. Der Name ist aber im Prinzip egal.

Danach müssen wir die Programmiersprache auswählen, in der unsere App geschrieben ist. Im Moment haben wir zwar noch keine App, sondern nur ein paar HTML-Dateien, aber wir werden im Folgenden eine “nodejs” Applikation erstellen, mit der wir die HTML-Dateien hosten. Daher wählen wir “Node 22. LTS” aus. Die Region (Das Rechenzentrum), in dem wir die WebApp hosten wollen, setze ich auf “Germany West Central” (Das im Moment mir nächste Rechenzentrum)

Danach klicke ich unten auf den “Review & Create” Button und auf dem nächsten Screen auf den “Create” Button. Nun wird die Webapp erstellt. Ich warte nun, bis mir mitgeteilt wird, dass das Deployment beendet wurde. Danach klicke ich auf “Go to resource”, um auf den Konfigurationsbildschirm der Webapp zu kommen.

Konfiguration und Sicherheit

Gut, nun haben wir eine leere Webapp erzeugt. Bei der Webapp müssen wir nun zwei Dinge einstellen:

• einen einfachen Deployment Mechanismus
• Authentifizierung. Wir wollen, dass nur Mitarbeiter des Unternehmens diese Seite sehen dürfen.

Wir befinden uns nun erstmal auf der Haupt-Konfigurationsseite der Webapp.

Auf der rechten Seite sehen wir die URL der App. Wir können sie im Browser öffnen und sehen einen Platzhalter-Text. Die URL sieht etwas kryptisch aus, aber dem Kunden war das erstmal egal. Wir können unsere eigene URL für diese App definieren, aber das tue ich nicht im Rahmen dieses Beitrags.

Wir beginnen mit der Konfiguration, indem wir links im Menu auf “Settings”-> “Configuration” klicken

Hier müssen wir zwei Schalter auf “On” setzten:

• “SCM Basic Auth Publishing enabled”
• “FTP Basic Auth Publishing enabled”

Mit diesen beiden Schaltern aktiviere wir später auf dem “Deployment” Bildschirm die Möglichkeit, dass wir per Git und unserem eigenen Passwort deployen können.

Zunächst sichern wir die App aber erstmal ab. Dazu wechseln wir auf den “Authentication” Bildschirm.

Hier ist noch kein Identity Provider installiert. Das bedeutet, dass die App für jeden aus dem Internet zugreifbar ist. Das ändern wir, indem wir auf “Add Identity Provider” klicken

Wir wählen den Provider “Microsoft” aus und lassen alle anderen Einstellungen so, wie sie sind. Der Effekt ist nun, dass nur noch Benutzer auf die Seite zugreifen können, die im Microsoft Entra des Unternehmens aufgelistet sind. Damit ist schonmal eine der Anforderungen erfüllt.

Deployment Einstellungen

Nun müssen wir die App noch einfach deployen können. Dazu wechseln wir ins “Deployment Center”.

Hier können wir uns als Quelle für das Deployment verschiedene Versionsverwaltungssysteme auswählen. Danach könnten wir definieren, dass die App automatisch neu deployt werden soll, sobald sich in dem Versionsverwaltungssystem etwas ändern.

In diesem Szenario hat der Kunde aber keines, sondern nur automatisch erzeugte HTML-Dateien. Daher wählen wir hier zur Einfachheit die Variante “Local Git”. Damit wird uns in der WebApp ein Git Zugang bereitgestellt. Wenn wir dorthin Dateien per Git pushen, dann werden diese automatisch in die Webapp deployt. Wunderbar, das lässt sich einfach lokal skripten. Dazu aber später mehr.

Zunächst wählen wir hier “Local Git” und klicken auf “Save”.

Danach ändert sich der Bildschirm und wir können uns die “Git Clone URL” kopieren. Das ist die Adresse, an die wir später per Git unsere Webseite pushen können

Dazu brauchen wir aber Benutzername und Passwort. Die können wir uns unter dem Reiter “Local Git/FTPS Credentials” im Bereich “User Scope” selber setzen

Eine nodejs App als Webserver

Nun müssen wir in einem lokalen Verzeichnis unsere Webapplikation erstellen. Das klingt schlimmer als es ist - sie besteht nur aus zwei Textdateien und einem Ordner.

Legen wir zunächst den leeren Ordner “public” an. In diesem Ordnet legen wir dann später die HTML-Dateien ab, die wir später hosten wollen.

Dann legen wir eine leere Datei namens “package.json” and und fügen diesen Inhalt ein:

	  
{
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^5.1.0"
  }
}

	

Das ist die Haupt-Projektdatei unseres Webservers. Sie enthält eigentlich nur zwei Einträge: Die Definition, wie der Server zu starten ist und die Information, dass der Server die Bibliothek “Express” braucht. Das reicht der Webapp erstmal.

Nun legen wir eine weitere Textdatei namens “server.js” an.

	  
const express = require('express')
const app = express()
const port = process.env.PORT


app.use(express.static('public'))

app.listen(port, () => {
  console.log(`App Listening ${port}`)
})

Die paar Zeilen Code definieren einen Webserver, der alle Dateien aus dem Verzeichnis “public” hosted. Fügt nun noch die HTML und CSS Dateien in das public Verzeichnis ein und dann war es das mit der Erstellung des Servers.

Jetzt müssen wir dieses Verzeichnis nur noch automatisch per Skript in unsre Webapp deployen.

Deployment per Git

Das machen wir, wie oben schon angedeutet, über das Git-Tool. Das ist eigentlich ein Tool zur Versionskontrolle von Quellcode, es lässt sich aber auch anderes anwenden. Zunächst müssen wir das Tool installieren, falls es noch nicht geschehen ist.

Ladet euch dazu den Installer von dieser Webseite↗ herunter und führt ihn aus.

Öffnet danach eine Windows Kommandozeile oder Powershell und navigiert in das Verzeichnis, was wir eben erstellt haben. Ich klicke eigentlich immer mit der rechten Maustaste irgendwo in das Verzeichnis und wähle “In Terminal öffnen”, aber das könnt ihr machen, wie ihr wollt.

Wichtig ist nur, dass ihr für die nächsten Schritte in dem Verzeichnis seid, das wir vorhin angelegt haben.

Führt nun nacheinander die folgenden Kommandos aus:

Zunächst initialisieren wir ein leere Git-Repository in dem Ordner

	  git init

Dann fügen wir alle Dateien in dem Ordner zum Repository hinzu und checken sie mit dem Kommentar “Initiales Einchecken” ein

    git add *
    git commit -m "Initiales Einchecken"

Jetzt definieren wir ein neues Remote-Repository namens “azure” mit der Git-URL, die wir in einem der Schritte oben definiert haben.

    git remote add azure <GITURL>

Also zum Beispiel in meinem Fall. Kopiert das aber nicht, benutzt in jedem Fall eure eigene URL.

    git remote add azure https://htmlfilehosting-b8hcakgbeffggsad.scm.germanywestcentral-01.azurewebsites.net:443/HTMLFileHosting.git

Wunderbar. Nun führen wir als letztes den folgenden Befehl aus

    git push azure main:master

Damit weisen wir Git an, unser lokales Repository an das Deployment Repository im Azure zu verschicken. Anders ausgedrückt: Wir weisen Git an, das Deployment zu starten.

Ihr werdet nun noch auf die eine oder andere Art nach einem Benutzernamen und Passwort gefragt werden. Gebt hier die Credentials ein, die wir oben als User Credentials vergeben haben. Git speichert die Daten für zukünftige Deployments.

Die Webseite deployt nun und ist nach ein paar Sekunden unter der App URL verfügbar.

Beim ersten Login müsst ihr wahrscheinlich noch einmal der Berechtigungsanfrage von Microsoft Entra zustimmen, aber danach läuft die App per Password abgesichert.

Wir sind nun mit dem initialen Deployment fertig.

Und nun?

Super, jetzt ist die Seite deployt und per Entra Authentifizierung abgesichert. Vielleicht denkt ihr nun, dass das alles ein wenig kompliziert war und dass ihr das noch bei jeder Änderung der HTML-Dateien wiederholen wollt.

Das braucht ihr aber auch glücklicherweise nicht.

Falls sich in Zukunft etwas an den HTML-Dateien ändert, dann braucht ihr nur in dem Verzeichnis diese drei folgenden Befehle ausführen

    git add *
    git commit -m "Neue Version der Dateien"
    git push azure main:master

Git wird dann alle geänderten Dateien einchecken und deployen. Wenn ihr diese drei Befehle nun in z.B. in den Windows Scheduler einträgt und sie jeden Tag ausgeführt werden, dann werden immer alle im Laufe des Tages erzeugten Dateien im Verzeichnis “public” deployt. Sollte es keine Änderungen gegeben haben, führen die drei Kommandos ansonsten auch kein weiteres Deployment durch.