Planen Ihrer Azure Static Web App
Ihr Endziel besteht darin, Ihre App in Azure zu hosten. Azure Static Web Apps stellt automatisch alle erforderlichen Azure-Ressourcen für Sie bereit.
Bevor die App gehostet werden kann, müssen Sie jedoch dafür sorgen, dass Ihre App auch beim Vornehmen von Änderungen erstellt wird. Diese Änderungen können über Commits oder Pull Requests an Ihr Repository erfolgen. Eine wichtige Funktion von Azure Static Web Apps ist die Einrichtung eines GitHub Actions-Workflows zum Erstellen und Veröffentlichen Ihrer Anwendung.
Beim Erstellen der Azure Static Web Apps-Ressource erstellt diese den GitHub Actions-Workflow. Der Workflow wird sofort ausgelöst und übernimmt das Erstellen und Veröffentlichen Ihrer App. Der Workflow wird auch jedes Mal ausgelöst, wenn Sie eine Änderung am überwachten Branch in Ihrem Repository vornehmen.
Azure Static Web Apps
Beim Bereitstellen einer Web-App gibt es zwei automatisierte Aspekte. Der erste stellt die zugrunde liegenden Azure-Ressourcen bereit, aus denen Ihre App besteht. Der zweite ist ein GitHub-Actions-Workflow, mit dem Ihre Anwendung erstellt und veröffentlicht wird.
Wenn Sie Ihre App mit Azure Static Web Apps im Web veröffentlichen, können Sie die Web-App und skalierbare APIs schnell hosten lassen. Außerdem profitieren Sie von einem einheitlichen Erstellungs- und Bereitstellungsworkflow, der von GitHub Actions bereitgestellt wird.
Verbinden Ihrer Static Web Apps-Instanz mit GitHub
Azure Static Web Apps ist für das Hosten von Anwendungen konzipiert, deren Quellcode sich auf GitHub befindet. Beim Erstellen einer Static Web Apps-Instanz melden Sie sich bei GitHub an und geben das Repository mit dem Code Ihrer App an.
Außerdem müssen Sie drei Ordnerpfade in Ihrem Repository angeben, damit Ihre App automatisch erstellt und bereitgestellt werden kann:
| Speicherort | Beispiel für Speicherort | Beschreibung | Erforderlich |
|---|---|---|---|
| App-Speicherort | / | Speicherort des Quellcodes für die Web-App | Ja |
| Ausgabespeicherort des App-Builds | dist | Speicherort der Buildausgabe Ihrer App, relativ zum Speicherort der App | Nein |
| API-Speicherort | api | Speicherort des Quellcodes für Ihre API | Nein |
Die App-Buildausgabe ist ein Pfad relativ zum Build-Ausgabeverzeichnis Ihrer Anwendung. Angenommen, wir verfügen über eine App in my-app, die ihre erstellten Ressourcen in den Ordner my-app/dist ausgibt. In diesem Fall geben Sie für diesen Speicherort dist an.
Vom Quellcode zu statischen Ressourcen mit GitHub Actions
Ihr GitHub-Repository enthält Quellcode, der kompiliert werden muss, bevor er veröffentlicht werden kann.
Wenn Sie eine Static Web Apps-Instanz erstellen, erstellt Azure einen GitHub Actions-Workflow in Ihrem Repository. Der Workflow erstellt Ihre App jedes Mal, wenn Sie Änderungen pushen oder einen Pull Request für den Branch erstellen, den Sie nachverfolgen möchten. Mit diesem Buildprozess wird der Quellcode in statische Ressourcen umgewandelt, die von Azure bereitgestellt werden. Nach dem Abschluss des Buildvorgangs stellt die Aktion die Ressourcen bereit.
Die GitHub-Aktion wird Ihrem Repository im Ordner .github/workflows hinzugefügt. Sie können diese Datei überprüfen und ggf. ändern. Die beim Erstellen der Ressource eingegebenen Einstellungen werden in der Datei der GitHub-Aktion gespeichert.
Integrierte API mit Azure Functions
Wenn Ihre App eine API erfordert, können Sie sie als Azure Functions-Projekt in Ihrem Repository implementieren. Ihre API wird automatisch von ihrer statischen Web Apps-Instanz bereitgestellt und gehostet. Der GitHub Actions-Workflow, mit dem Ihre App erstellt und bereitgestellt wird, sucht die API in Ihrem Repository anhand des angegebenen Ordnernamens.
In der Regel speichern Sie die API-App in einem Ordner mit dem Namen api oder functions. Sie können dem Ordner aber einen beliebigen Namen geben.
Sie verfügen noch über keine API? Keine Sorge! Wenn Azure Static Web Apps im angegebenen Ordner keine API finden kann, wird keine API veröffentlicht, die App wird aber trotzdem veröffentlicht.
Verarbeiten von Fallbackrouten
Der Fehler 404 wird beim Aktualisieren der Seite angezeigt, da der Browser eine Anforderung zum Bereitstellen von /products an die Hostingplattform sendet. Auf dem Server ist keine Seite mit dem Namen products vorhanden. Glücklicherweise kann dieser Fehler einfach durch Erstellen einer Fallbackroute behoben werden. Eine Fallbackroute ist eine Route, die allen Seitenanforderungen ohne Übereinstimmung an den Server entspricht.
Azure Static Web Apps unterstützt benutzerdefinierte Routingregeln, die in einer optionalen Datei staticwebapp.config.json im Buildausgabeordner der App definiert sind.
Sie können Ihre Anwendung so konfigurieren, dass sie Regeln verwendet, die eine Fallbackroute implementieren, wie im folgenden Beispiel gezeigt, in dem ein Pfadplatzhalter mit Dateifilter verwendet wird:
{
"navigationFallback": {
"rewrite": "index.html",
"exclude": ["/images/*.{png,jpg,gif,ico}", "/*.{css,scss,js}"]
}
}
Diese Regel weist Azure Static Web Apps an, index.html bereitzustellen, wenn eine angeforderte Ressource nicht gefunden wird, mit Ausnahme der im exclude-Ausdruck angegebenen Bilder und CSS-Dateien.
Speicherort der Datei „routes“
Azure Static Web Apps erwartet, dass sich Ihre Datei staticwebapp.config.json standardmäßig in output_location befindet. Wenn Ihr Buildprozess die Datei staticwebapp.config.json in output_location kopiert, ist keine Aktion Ihrerseits erforderlich. Bei den meisten Projekten ist der output_location relativ zum app_location.
Die Datei staticwebapp.config.json für Ihre Anwendung befindet sich im Ordner angular-app/src/assets.
Die Datei staticwebapp.config.json befindet sich im Ordner react-app.
Die Datei staticwebapp.config.json befindet sich im Ordner svelte-app/public.
Die Datei staticwebapp.config.json befindet sich im Ordner vue-app/public.
Nächste Schritte
Was benötigen Sie also, damit Sie Ihre Web-App in Azure Static Web Apps veröffentlichen können? Ihre App muss sich lediglich in Ihrem GitHub-Repository befinden.