Erstellen einer statischen Web-App mit einer serverlosen API
Erfahren Sie, wie Sie lokal eine statische Web-App mit einer serverlosen API in Azure bereitstellen. In diesem Lernprogramm wird die Vorschauversion des neuesten Programmiermodells von Azure Functions Node.js verwendet. Da in diesem Artikel eine Vorschauversion von Azure Functions verwendet wird, wird sie als separate App von der statischen Web-App bereitgestellt.
In diesem Artikel werden folgende Themen erläutert:
- Lokales Ausführen einer statischen Web-App (SWA) mit einer Azure-Funktions-App
- Lokale Proxy-Front-End-Anforderungen an die lokale Back-End-API mithilfe der SWA CLI.
- Stellen Sie denselben Code bereit und führen Sie denselben Code remote aus.
Der Proxy zwischen front-end und Backend-Endis, die von der Static Web App CLI bereitgestellt werden, bietet:
- Die URL in React gibt
/api/todo
nicht die Server- oder Portnummer für die API an. Anforderungen, die diese URL verwenden, können problemlos lokal verwendet werden, da die SWA-Befehlszeilenschnittstelle den Proxy für Sie verwaltet. - Lokaler Authentifizierungsemulator beim Zugriff auf
/.auth/login/<provider>
- Routenverwaltung und Autorisierung
Authentifizierung in diesem Beispiel
Die Authentifizierung in diesem Beispiel wird für Front-End-Benutzer aus dem Azure Static Web-Apps-Dienst bereitgestellt:
- Anmeldung/Abmeldung
- Öffentliche und private Inhalte
Quellcode in diesem Beispiel
Der Quellcode in diesem Beispiel soll erfahren, wie Sie eine statische Web-App mit einer serverlosen API erstellen und bereitstellen. Der Code ist nicht für die Produktion vorgesehen.
Sie finden mehrere Stellen im Code, die nicht den bewährten Sicherheitspraktiken entsprechen. Beispielsweise wird console.log
der Code verwendet, um in die Browserkonsole zu schreiben.
Wenn Sie zu einer Produktionsumgebung wechseln, sollten Sie code überprüfen und entfernen, der gegen bewährte Methoden für Die Sicherheit für Ihre Organisation verstößt.
1. Vorbereiten Ihrer Entwicklungsumgebung
Erstellen Sie die folgenden Konten:
- Azure-Abonnement – Erstellen eines kostenlosen Azure-Kontos
- GitHub-Konto – Sie benötigen ein GitHub-Konto, um es in diesem Lernprogramm bereitzustellen.
Installieren Sie Folgendes auf Ihrem lokalen Entwicklungscomputer:
- Node.js v18 oder höher
- Visual Studio Code (VS Code)
- Azure Static Web-Apps (SWA) CLI global mit
-g
Flag installiert - Azure Functions Core Tools v4.0.5095+ (wenn lokal ausgeführt) global mit
-g
Flag installiert - TypeScript v4 oder höher
2. Verzweigung des Beispiel-Repositorys auf GitHub
Sie müssen über eine eigene Verzweigung des Beispiel-Repositorys verfügen, um die Bereitstellung von GitHub abzuschließen. Während des Verzweigungsprozesses müssen Sie nur die main
Verzweigung kopieren.
Verzweigen Sie das Beispiel-Repository: https://github.com/Azure-Samples/azure-typescript-e2e-apps
.
3. Klonen des verzweigten Beispiel-Repositorys
Klonen Sie in einem Bash-Terminal Ihr Verzweigungsrepository auf Ihrem lokalen Computer. Klonen Sie das ursprüngliche Beispiel-Repository nicht. Eine Beispiel-URL ist
https://github.com/YOUR-ACCOUNT-NAME/azure-typescript-e2e-apps
git clone YOUR-FORKED-REPO-URL
Installieren von Abhängigkeiten für die lokale Front-End-App:
cd app-react-vite && npm install
Installieren von Abhängigkeiten für die lokale Back-End-App:
cd ../api-inmemory && npm install && cd ..
4. Optional, Erstellen und Ausführen einer lokalen App
Das Beispiel-Repository verfügt über mehrere Versionen der Front-End- und Back-End-Apps. Die folgenden Schritte verwenden die React 18 (Vite)-Version des Front-Ends und die Azure Function v4 mit Node.js Version des Back-End mit den /status
und /todo
API-Routen.
Verwenden Sie aus dem Stamm der Beispiel-App die SWA CLI mit der
./swa-cli.config.json
Datei, um die Front-End- und Back-End-Apps zu erstellen:swa build
Wenn Fehler auftreten, die je nach Version der verschiedenen Pakete und Ihrer Umgebung auftreten können, beheben Sie die Fehler, bevor Sie fortfahren. Es ist wichtig zu wissen, dass Ihr Projekt erfolgreich lokal erstellt wird, bevor Sie zur Bereitstellung zu Azure Static Web-Apps wechseln.
Verwenden Sie aus dem Stamm der Beispiel-App die SWA CLI, um die Apps mit einem Proxy zu starten.
swa start
Wenn die folgenden Zeilen im Bash-Terminal angezeigt werden, wurde das Projekt erfolgreich gestartet.
[swa] Serving static content: [swa] /workspaces/azure-typescript-e2e-apps/app-react-vite/dist [swa] [swa] Serving API: [swa] /workspaces/azure-typescript-e2e-apps/api-inmemory [swa] [swa] Azure Static Web Apps emulator started at http://0.0.0.0:4280. Press CTRL+C to exit.
Öffnen Sie einen Webbrowser für die proxygeschützte URL,
http://localhost:4280
. Die folgende Seite sollte angezeigt werden:Sie können sich mit der von der SWA CLI bereitgestellten Authentifizierung anmelden. Der Prozess simuliert die Authentifizierung in cloudbasierten Azure Static Web Apps. Der Front-End-Code verwendet den
/.auth/me
Endpunkt, um die Identität des Benutzers abzurufen. Geben Sie einen gefälschten Benutzernamen ein, und ändern Sie nicht die restlichen Felder.Nachdem ein Benutzer authentifiziert wurde, zeigt das Front-End private Informationen wie die Umgebungsvariablen der API an.
Der Quellcode der Azure Function v4-App für diese API lautet:
import { app, HttpRequest, HttpResponseInit, InvocationContext } from "@azure/functions"; import { name, version } from '../../package.json'; function isObject(v) { return '[object Object]' === Object.prototype.toString.call(v); }; function sortJson(o){ if (Array.isArray(o)) { return o.sort().map(sortJson); } else if (isObject(o)) { return Object .keys(o) .sort() .reduce(function(a, k) { a[k] = sortJson(o[k]); return a; }, {}); } return o; } export async function status(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> { context.log(`Http function processed request for url "${request.url}"`); const sortedEnv = sortJson(process.env); return { jsonBody: { name, version, env: sortedEnv, requestHeaders: request.headers }}; }; app.http('status', { route: "status", methods: ['GET'], authLevel: 'anonymous', handler: status });
Erweitern Sie die öffentlichen und privaten Abschnitte, um den Inhalt aus der API anzuzeigen.
5. Erstellen einer neuen Azure Functions-App
Der vorherige Abschnitt zum Ausführen der statischen Web-App mit der API war optional. Die restlichen Abschnitte des Artikels sind erforderlich, um die App und API in der Azure-Cloud bereitzustellen.
Um die Vorschauversion der Azure Functions v4-Laufzeit zu verwenden, müssen Sie eine neue Azure Functions-App erstellen. Ihre statische Web-App muss auch neu erstellt und erneut bereitgestellt werden, um den Azure Functions-App-URI in den Fetch-Anforderungen an die API zu verwenden, anstatt eine proxygesteuerte und verwaltete API zu verwenden.
Öffnen Sie in einem Webbrowser die Azure-Portal, um eine neue Azure Functions-App zu erstellen: Erstellen einer neuen App
Verwenden Sie die folgenden Informationen, um die Funktions-App zu erstellen::
Tab:Setting Wert Grundlagen: Abonnement Wählen Sie das Abonnement aus, das Sie verwenden möchten. Grundlagen: Ressourcengruppe Erstellen Sie eine neue Ressourcengruppe, z first-static-web-app-with-api
. B. . Der Name wird nicht in der öffentlichen URL der App verwendet. Ressourcengruppen helfen Ihnen beim Gruppieren und Verwalten verwandter Azure-Ressourcen.Grundlagen: Instanzdetails: Funktions-App-Name Geben Sie einen global eindeutigen Namen ein, z swa-api
. B. mit drei zufälligen Zeichen, die am Ende hinzugefügt wurden, zswa-api-123
. B. .Grundlagen: Instanzdetails: Code oder Container Wählen Sie Code
aus.Grundlagen: Instanzdetails: Laufzeitstapel Wählen Sie Node.js
aus.Grundlagen: Instanzdetails: Laufzeitstapel Wählen Sie 18LTS
aus.Grundlagen: Betriebssystem Wählen Sie Linux
aus.Grundlagen: Hosting Wählen Sie Consumption
aus.Speicher: Speicherkonto Nehmen Sie hier keine Änderungen vor. Es wird ein neues Azure Storage-Konto erstellt, um Funktionsereignisse zu unterstützen. Netzwerk Ändern Sie nichts. Monitoring: Application Insights: Enable Application Insights Wählen Sie Yes
aus. Ändern Sie nicht den angegebenen Standardnamen.Bereitstellung: GitHub-Aktionseinstellungen: Kontinuierliche Bereitstellung Wählen Sie Enable
aus.Bereitstellung: GitHub-Konto Wählen Sie Ihr GitHub-Konto. Bereitstellung: Organisation Wählen Sie Ihr GitHub-Konto aus, das Sie beim Verzweigen des Beispiel-Repositorys verwendet haben. Bereitstellung: Repository Wählen Sie ihren Verzweigungs-Repositorynamen aus. azure-typescript-e2e-apps
Bereitstellung: Branch Wählen Sie main
aus.Tags Ändern Sie nichts. Überprüfen + erstellen Wählen Sie Create
aus.Der Schritt fügt Ihrem Verzweigungs-Repository eine GitHub-Yaml-Workflowdatei hinzu.
Wenn die Ressource erstellt wird, wählen Sie die
Go to resource
Schaltfläche aus.Wählen Sie "Einstellungen" aus–> Konfiguration fügen Sie dann eine Konfigurationseinstellung für die Azure Function Node.js v4 Runtime mit Name
AzureWebJobsFeatureFlags
und WertEnableWorkerIndexing
hinzu.Klicken Sie auf Speichern, um die Einstellung zu speichern.
Verwenden Sie git in einem Bash-Terminal, um die neue Yaml-Workflowdatei aus Ihrem GitHub-Repository auf Ihren lokalen Computer zu ziehen.
git pull origin main
Öffnen Sie in Visual Studio Code die neue Yaml-Workflowdatei unter
./.github/workflows/
.Die für Sie bereitgestellte Standardworkflowdatei geht davon aus, dass sich der Funktionsquellcode im Stammverzeichnis des Repositorys befindet und die einzige App im Repository ist, dies ist jedoch nicht der Fall bei diesem Beispiel. Bearbeiten Sie die Datei, um dies zu beheben. Die zu bearbeitenden Zeilen werden im folgenden Yaml-Block hervorgehoben und unten erläutert:
# Docs for the Azure Web Apps Deploy action: https://github.com/azure/functions-action # More GitHub Actions for Azure: https://github.com/Azure/actions # Deploy Azure Functions Node.js v4 runtime # with api-inmemory subdir name: Azure Function App - api-inmemory on: push: branches: - main paths: - 'api-inmemory/**' workflow_dispatch: env: AZURE_FUNCTIONAPP_PACKAGE_PATH: 'api-inmemory' # set this to the path to your web app project, defaults to the repository root NODE_VERSION: '18.x' # Azure Functions v4 runtime requires 18 VERBOSE: true # For debugging jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: 'Checkout GitHub Action' uses: actions/checkout@v2 - name: Setup Node ${{ env.NODE_VERSION }} Environment uses: actions/setup-node@v1 with: node-version: ${{ env.NODE_VERSION }} - name: 'Resolve Project Dependencies Using Npm' shell: bash run: | pushd './${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}' npm install npm run build --if-present npm run test --if-present popd - name: 'Upload artifact for deployment job' # For debugging uses: actions/upload-artifact@v3 with: name: azure-function-v4-app path: | ${{env.AZURE_FUNCTIONAPP_PACKAGE_PATH}} !${{env.AZURE_FUNCTIONAPP_PACKAGE_PATH}}/node_modules !${{env.AZURE_FUNCTIONAPP_PACKAGE_PATH}}/dist - name: 'Run Azure Functions Action' uses: Azure/functions-action@v1 id: fa with: app-name: 'swa-api' # change this to your Azure Function app name slot-name: 'Production' package: ${{env.AZURE_FUNCTIONAPP_PACKAGE_PATH}} publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_123 }} scm-do-build-during-deployment: false enable-oryx-build: false
Eigenschaftenänderung Zweck name
Kürzen Sie den Namen, damit Sie ihn ganz einfach in der GitHub-Aktionsliste Ihrer Verzweigung finden können. paths
Fügen Sie den Pfadabschnitt hinzu, um die Ausführung der Bereitstellung nur zu beschränken, wenn sich der Azure Functions-API-Code ändert. Wenn Sie die Workflowdatei bearbeiten, können Sie die Bereitstellung manuell auslösen. AZURE_FUNCTIONAPP_PACKAGE_PATH
Wenn Sie eine Unterdirektion für Quellcode verwenden, muss dies dieser Unterverzeichnispfad und -name sein. VERBOSE
Diese Einstellung ist hilfreich beim Debuggen des Build- und Bereitstellungsprozesses. Schritt mit dem Namen Upload artifact for deployment job
Dieser Schritt erstellt ein herunterladbares Artefakt. Dies ist hilfreich beim Debuggen genau der Dateien, die in Ihrer Azure-Funktion bereitgestellt werden. Upload artifact for deployment job
ist optional. Es wird verwendet, um zu verstehen und zu debuggen, welche Dateien in Azure Functions bereitgestellt werden oder um diese Dateien in einer separaten Umgebung zu verwenden.Speichern Sie die Datei, fügen Sie die Datei hinzu, übernehmen Sie ihn, und übertragen Sie sie mit GitHub zurück:
git add . git commit -m "fix the workflow for a subdir" git push origin main
Führen Sie in einem Browser den Workflow auf GitHub im Aktionsbereich Ihrer Verzweigung erneut aus.
Warten Sie, bis die Aktion erfolgreich abgeschlossen wurde, bevor Sie fortfahren.
Verwenden Sie in einem Webbrowser den externen API-Endpunkt Ihrer Funktions-App, um zu überprüfen, ob die App erfolgreich bereitgestellt wurde.
https://YOUR-FUNCTION-APP-NAME.azurewebsites.net/api/todo
Das für die Speicherdaten zurückgegebene JSON-Ergebnis lautet:
{ "1": "Say hello" }
Notieren Sie sich die URL Ihrer Funktion. Sie benötigen dies im nächsten Abschnitt.
Sie wissen, dass Ihre Azure Function-App in der Cloud funktioniert. Jetzt müssen Sie Ihre statische Web-App in der Cloud erstellen, um die API zu verwenden.
6. Erstellen einer neuen statischen Azure-Web-App
Dieser Erstellungsprozess stellt dasselbe Verzweigungs-GitHub-Beispielrepository in Azure bereit. Sie konfigurieren die Bereitstellung so, dass nur die Front-End-App verwendet wird.
Öffnen Sie die Azure-Portal, und melden Sie sich mit Ihrem Azure-Konto an: Azure-Portal.
Führen Sie die folgenden Informationen aus, um die Erstellungsschritte auszuführen:
Eingabeaufforderung Einstellung Subscription Wählen Sie das Abonnement aus, das Sie verwenden möchten. Ressourcengruppe Wählen Sie aus, und geben Sie Create new
eine neue für die Ressourcengruppe ein, zfirst-static-web-app
. B. . Der Name wird nicht in der öffentlichen URL der App verwendet. Ressourcengruppen helfen Ihnen beim Gruppieren von Ressourcen, die für ein einzelnes Projekt verwendet werden.Typ des Hostingplans Wählen Sie Free
aus.Details zu Azure Functions und Staging Ändern Sie die Standardeinstellung nicht. Sie stellen die Funktions-API nicht innerhalb der statischen Web-App bereit. Bereitstellungsdetails – Quelle Wählen Sie GitHub
aus.Bereitstellungsdetails – GitHub Melden Sie sich bei GitHub bei Bedarf an. Bereitstellungsdetails – Organisation Wählen Sie Ihr GitHub-Konto. Bereitstellungsdetails – Repository Wählen Sie das verzweigte Repository mit dem Namen aus azure-typescript-e2e-apps
.Bereitstellungsdetails – Branch Wählen Sie die main
Verzweigung aus.Builddetails – Build presents Wählen Sie Custom
aus.Builddetails – App-Speicherort Geben Sie /app-react-vite
ein.Builddetails – API-Speicherort Leer lassen Builddetails – Ausgabespeicherort Geben Sie den Speicherort des Ausgabeverzeichnisses des Front-End-Verzeichnisses ein. dist
Klicken Sie aufÜberprüfen + erstellen und dann auf Erstellen.
Wenn die Ressource erstellt wird, wählen Sie die
Go to resource
Schaltfläche aus.Notieren Sie sich auf der Seite "Übersicht" die URL Ihrer statischen Web-App. Sie benötigen dies im nächsten Abschnitt, wenn Sie die CORS-Einstellung der Azure-Funktion festlegen.
Der Erstellungsprozess erstellt eine GitHub-Yaml-Workflowdatei in Ihrem verzweigten GitHub-Repository. Ziehen Sie diese Änderung mit dem folgenden Befehl nach unten:
git pull origin main
Die GitHub-Aktion, die unter
./.github/workflows/azure-static-web-apps-*.yml
"GitHub" zu finden ist, ist für das Erstellen und Bereitstellen der Front-End-App verantwortlich. Bearbeiten Sie die Datei, um eine Umgebungsvariable für die cloudbasierte Back-End-API-URL hinzuzufügen. Die zu bearbeitenden Zeilen werden im folgenden Yaml-Block hervorgehoben und unterhalb des Yaml-Blocks erläutert.name: Azure Static Web Apps CI/CD on: push: branches: - main paths: - 'app-react-vite/**' pull_request: types: [opened, synchronize, reopened, closed] branches: - main paths: - 'app-react-vite/**' workflow_dispatch: jobs: build_and_deploy_job: if: github.event_name == 'push' || github.event_name == 'workflow_dispatch' || (github.event_name == 'pull_request' && github.event.action != 'closed') runs-on: ubuntu-latest name: Build and Deploy Job steps: - uses: actions/checkout@v2 with: submodules: true - name: Build And Deploy id: builddeploy uses: Azure/static-web-apps-deploy@v1 with: azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_ORANGE_DUNE_123 }} repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments) action: "upload" ###### Repository/Build Configurations - These values can be configured to match your app requirements. ###### # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig app_location: "/app-react-vite" # App source code path api_location: "" # Api source code path - optional output_location: "dist" # Built app content directory - optional ###### End of Repository/Build Configurations ###### env: VITE_BACKEND_URI: https://swa-api-123.azurewebsites.net VITE_CLOUD_ENV: production close_pull_request_job: if: github.event_name == 'pull_request' && github.event.action == 'closed' runs-on: ubuntu-latest name: Close Pull Request Job steps: - name: Close Pull Request id: closepullrequest uses: Azure/static-web-apps-deploy@v1 with: azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_ORANGE_DUNE_123 }} action: "close"
Eigenschaftenänderung Zweck paths
Fügen Sie den Pfadabschnitt hinzu, um die Ausführung der Bereitstellung nur zu beschränken, wenn sich der Azure Functions-API-Code ändert. Wenn Sie die Workflowdatei bearbeiten, können Sie die Bereitstellung manuell auslösen. workflow_dispatch
Fügen Sie nur beim Erlernen des Bereitstellungsprozesses hinzu, und debuggen Sie workflow_dispatch
alle Probleme im Vite-Build. Entfernen Sie diese Zeile, wenn Sie diesen Quellcode über diesen Artikel hinaus fortsetzen.if ... || github.event_name == 'workflow_dispatch'
Schließen Sie das workflow_dispatch
Ereignis so ein, dass nur ein Build generiert werden darf, während Sie den Bereitstellungsprozess erlernen und alle Probleme im Vite-Build debuggen.env
Fügen Sie die Umgebungsvariablen hinzu, die erforderlich sind, um die URL der Azure-Funktions-API in den statischen Build mit Vite aufzunehmen. VITE_BACKEND_URL ist die URL Ihrer Azure-Funktions-App. VITE_CLOUD_ENV ist ein Parameter, der angibt, wann die VITE_BACKEND_URL-URL verwendet werden soll. Verwenden Sie NODE_ENV für dieses Beispiel nicht, da sie unbeabsichtigte Auswirkungen hat. Speichern Sie die Datei, fügen Sie die Datei hinzu, übernehmen Sie ihn, und übertragen Sie sie mit GitHub zurück:
git add . git commit -m "fix the workflow for a subdir" git push origin main
Führen Sie in einem Browser den Workflow auf GitHub im Aktionsbereich Ihrer Verzweigung für Ihre statische Web-App erneut aus.
Ihre Front-End-App wird in Azure bereitgestellt. Jetzt müssen Sie die Azure Function-App so konfigurieren, dass CORS-Anforderungen aus Ihrer statischen Web-App zugelassen werden.
7. Konfigurieren von CORS für Ihre Azure Function-App
Wenn Sie eine separate Azure Function-App anstelle einer verwalteten Funktions-App verwenden, müssen Sie CORS so konfigurieren, dass Anforderungen von Ihrer statischen Web-App zugelassen werden.
- Öffnen Sie in der Azure-Portal Ihre Azure-Funktions-App.
- Fügen Sie im Abschnitt "API –> CORS " die URL Ihrer statischen Web-App zur Liste der zulässigen Ursprünge hinzu.
8. Testen Ihrer statischen Web-App
- Öffnen Sie in einem Browser Ihre statische Web-App.
- Interagieren Sie mit der App, um sich anzumelden, öffentliche und private Informationen anzuzeigen und sich erneut abzumelden.
9. Bereinigen aller in dieser Artikelreihe verwendeten Ressourcen
Bereinigen Sie alle Ressourcen, die in dieser Artikelserie erstellt wurden.
- Löschen Sie in der Azure-Portal Ihre Ressourcengruppe, die die statische Web-App und die Funktions-App löscht.
- Löschen Sie im GitHub-Portal Ihr Verzweigungs-Repository.
Problembehandlung
In diesem Beispiel wird eine Liste bekannter Probleme und Lösungen beibehalten. Wenn Ihr Problem nicht aufgeführt ist, öffnen Sie ein Problem.
Öffentliche URLs für statische Web-App und Funktions-App
Sie finden immer die URL Ihrer statischen Web-App und die URL Ihrer Funktions-App im Azure-Portal auf der Seite "Übersicht" jeder Ressource. Diese URLs sind standardmäßig öffentlich.