Verwenden eines GitHub Actions-Workflows zum Bereitstellen einer statischen Website in Azure Storage
Artikel
Verwenden Sie als Einstieg in GitHub Actions einen Workflow zum Bereitstellen einer statischen Website in einem Azure-Speicherkonto. Nachdem Sie einen GitHub Actions-Workflow eingerichtet haben, können Sie Ihre Website über GitHub automatisch in Azure bereitstellen, wenn Sie Änderungen am Code der Website vornehmen.
Hinweis
Wenn Sie Azure Static Web Apps verwenden, müssen Sie keinen GitHub Actions-Workflow manuell einrichten.
Azure Static Web Apps erstellt für Sie automatisch einen GitHub Actions-Workflow.
Ein GitHub-Repository mit dem Code Ihrer statischen Website. Wenn Sie kein GitHub-Konto besitzen, können Sie sich kostenlos registrieren.
funktionierende, in Azure Storage gehostete statische Website. Informieren Sie sich, wie Sie eine statische Website in Azure Storage hosten. Wenn Sie diesem Beispiel folgen möchten, sollten Sie auch Azure CDN bereitstellen.
Hinweis
Es ist üblich, ein Content Delivery Network (CDN) zu verwenden, um die Latenz für Ihre Benutzer auf der ganzen Welt zu reduzieren und die Anzahl der Transaktionen in Ihrem Speicherkonto zu verringern. Durch Bereitstellen statischer Inhalte in einem cloudbasierten Speicherdienst kann eine potenziell kostspielige Compute-Instanz vermieden werden. Weitere Informationen finden Sie unter Muster für das Hosten von statischen Inhalten.
Generieren von Anmeldeinformationen für die Bereitstellung
az ad sp create-for-rbac --name "myML" --role contributor \
--scopes /subscriptions/<subscription-id>/resourceGroups/<group-name> \
--json-auth
Der Parameter --json-auth ist in Azure CLI-Versionen >= 2.51.0 verfügbar. Frühere Versionen nutzen --sdk-auth mit einer Einstellungswarnung.
Ersetzen Sie im obigen Beispiel die Platzhalter durch Ihre Abonnement-ID, den Ressourcengruppennamen und den App-Namen. Die Ausgabe ist ein JSON-Objekt mit den Anmeldeinformationen für die Rollenzuweisung, die ähnlich wie unten Zugriff auf Ihre App Service-App gewähren. Kopieren Sie dieses JSON-Objekt zur späteren Verwendung.
OpenID Connect ist eine Authentifizierungsmethode, die kurzlebige Token verwendet. Das Einrichten von OpenID Connect mit GitHub Actions ist komplexer und bietet mehr Sicherheit.
Dieser Befehl gibt JSON mit einem appId aus, das Ihrem client-id entspricht. Dies objectId ist APPLICATION-OBJECT-ID und wird zum Erstellen von Verbundanmeldeinformationen mit Graph-API-Anrufen verwendet. Speichern Sie den Wert, der später als AZURE_CLIENT_IDGitHub-Geheimnis verwendet werden soll.
Erstellen eines Dienstprinzipals. Ersetzen Sie $appID durch die AppId aus Ihrer JSON-Ausgabe. Dieser Befehl generiert eine JSON-Ausgabe mit einem anderen objectId, was im nächsten Schritt verwendet wird. Der neue objectId ist der assignee-object-id.
Dieser Befehl generiert eine JSON-Ausgabe mit einem anderen objectId und wird im nächsten Schritt verwendet. Der neue objectId ist der assignee-object-id.
Kopieren Sie die appOwnerTenantId, um sie später als GitHub-Geheimnis für AZURE_TENANT_ID zu verwenden.
az ad sp create --id $appId
Erstellen Sie eine neue Rollenzuweisung nach Abonnement und Objekt. Standardmäßig ist die Rollenzuweisung an Ihr Standardabonnement gebunden. Ersetzen Sie $subscriptionId durch Ihre Abonnement-ID, $resourceGroupName durch den Namen Ihrer Ressourcengruppe und $assigneeObjectId durch die generierte assignee-object-id (die neu erstellte Dienstprinzipalobjekt-ID).
az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id $assigneeObjectId --assignee-principal-type ServicePrincipal --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName
Ersetzen Sie APPLICATION-OBJECT-ID durch die ObjectId (die beim Erstellen der Anwendung generiert wurde) für Ihre Microsoft Entra-Anwendung.
Legen Sie einen Wert für CREDENTIAL-NAME fest, um später auf ihn zu verweisen.
Legen Sie die subject fest. Dieser Wert wird von GitHub in Abhängigkeit von Ihrem Workflow festgelegt:
Aufträge in Ihrer GitHub Actions-Umgebung: repo:< Organization/Repository >:environment:< Name >
Bei Aufträgen, die nicht an eine Umgebung gebunden sind, fügen Sie den Referenzpfad für den Branch/Tag auf der Grundlage des für die Auslösung des Workflows verwendeten Referenzpfads ein: repo:< Organization/Repository >:ref:< ref path>. Zum Beispiel: repo:n-username/ node_express:ref:refs/heads/my-branch oder repo:n-username/ node_express:ref:refs/tags/my-tag.
Für Workflows, die durch ein Pull Request-Ereignis ausgelöst werden: repo:< Organization/Repository >:pull_request.
az ad app federated-credential create --id <APPLICATION-OBJECT-ID> --parameters credential.json
("credential.json" contains the following content)
{
"name": "<CREDENTIAL-NAME>",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:octo-org/octo-repo:environment:Production",
"description": "Testing",
"audiences": [
"api://AzureADTokenExchange"
]
}
Wählen Sie Security > Secrets and variables > Actions (Sicherheit > Geheimnisse und Variablen > Aktionen) aus.
Wählen Sie New repository secret (Neues Repositorygeheimnis) aus.
Fügen Sie die gesamte JSON-Ausgabe aus dem Azure CLI-Befehl in das Wertfeld des Geheimnisses ein. Geben Sie dem Geheimnis den Namen AZURE_CREDENTIALS.
Klicken Sie auf Add secret (Geheimnis hinzufügen).
Sie müssen die Client-ID Ihrer Anwendung, die Mandanten-ID und die Abonnement-ID für die Anmeldeaktion bereitstellen. Diese Werte können entweder direkt im Workflow bereitgestellt werden oder in GitHub-Geheimnissen gespeichert und darauf in Ihrem Workflow verwiesen werden. Das Speichern der Werte als GitHub-Geheimnisse ist die sicherere Option.
Wählen Sie Security > Secrets and variables > Actions (Sicherheit > Geheimnisse und Variablen > Aktionen) aus.
Wählen Sie New repository secret (Neues Repositorygeheimnis) aus.
Erstellen Sie Geheimnisse für AZURE_CLIENT_ID, AZURE_TENANT_ID und AZURE_SUBSCRIPTION_ID. Verwenden Sie diese Werte aus Ihrer Microsoft Entra-Anwendung für Ihre GitHub-Geheimnisse:
GitHub-Geheimnis
Microsoft Entra-Anwendung
AZURE_CLIENT_ID
Anwendungs-ID (Client)
AZURE_TENANT_ID
Verzeichnis-ID (Mandant)
AZURE_SUBSCRIPTION_ID
Abonnement-ID
Speichern Sie jedes Geheimnis, indem Sie Geheimnis hinzufügen auswählen.
Navigieren Sie für Ihr GitHub-Repository zu Actions (Aktionen).
Wählen Sie Set up your workflow yourself (Workflow selbst einrichten) aus.
Löschen Sie alles nach dem Abschnitt on: Ihrer Workflowdatei. Der verbleibende Workflow könnte beispielsweise wie folgt aussehen.
name: CI
on:
push:
branches: [ main ]
Benennen Sie den Workflow in Blob storage website CI um, und fügen Sie die Aktionen zum Auschecken und Anmelden hinzu. Diese Aktionen checken Ihren Websitecode aus und authentifizieren Sie mithilfe des zuvor erstellten GitHub-Geheimnisses AZURE_CREDENTIALS mit Azure.
name: Blob storage website CI
on:
push:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
Verwenden Sie die Azure CLI-Aktion, um Ihren Code in Azure Blob Storage hochzuladen und den CDN-Endpunkt zu bereinigen. Ersetzen Sie für az storage blob upload-batch den Platzhalter durch den Namen Ihres Speicherkontos. Das Skript wird in den $web-Container hochgeladen. Ersetzen Sie für az cdn endpoint purge die Platzhalter durch den Namen Ihres CDN-Profils, CDN-Endpunkts und der Ressourcengruppe. Um die CDN-Bereinigung zu beschleunigen, können Sie die --no-wait-Option zu az cdn endpoint purge hinzufügen. Um die Sicherheit zu erhöhen, können Sie auch die --account-key Option mit Ihrem Speicherkontoschlüsselhinzufügen.
Vervollständigen Sie Ihren Workflow, indem Sie eine Aktion zum Abmelden von Azure hinzufügen. Hier sehen Sie den fertigen Workflow: Die Datei wird im Ordner .github/workflows Ihres Repositorys angezeigt.
Navigieren Sie für Ihr GitHub-Repository zu Actions (Aktionen).
Wählen Sie Set up your workflow yourself (Workflow selbst einrichten) aus.
Löschen Sie alles nach dem Abschnitt on: Ihrer Workflowdatei. Der verbleibende Workflow könnte beispielsweise wie folgt aussehen:
name: CI with OpenID Connect
on:
push:
branches: [ main ]
Fügen Sie einen Abschnitt für die Berechtigungen hinzu.
name: CI with OpenID Connect
on:
push:
branches: [ main ]
permissions:
id-token: write
contents: read
Fügen Sie Check-Out- und Anmeldeaktionen hinzu. Diese Aktionen checken Ihren Websitecode aus und authentifizieren Sie mithilfe der zuvor erstellten GitHub-Geheimnisse mit Azure.
name: CI with OpenID Connect
on:
push:
branches: [ main ]
permissions:
id-token: write
contents: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
Verwenden Sie die Azure CLI-Aktion, um Ihren Code in Azure Blob Storage hochzuladen und den CDN-Endpunkt zu bereinigen. Ersetzen Sie für az storage blob upload-batch den Platzhalter durch den Namen Ihres Speicherkontos. Das Skript wird in den $web-Container hochgeladen. Ersetzen Sie für az cdn endpoint purge die Platzhalter durch den Namen Ihres CDN-Profils, CDN-Endpunkts und der Ressourcengruppe. Um die CDN-Bereinigung zu beschleunigen, können Sie die --no-wait-Option zu az cdn endpoint purge hinzufügen. Um die Sicherheit zu erhöhen, können Sie auch die --account-key Option mit Ihrem Speicherkontoschlüsselhinzufügen.
Vervollständigen Sie Ihren Workflow, indem Sie eine Aktion zum Abmelden von Azure hinzufügen. Hier sehen Sie den fertigen Workflow: Die Datei wird im Ordner .github/workflows Ihres Repositorys angezeigt.
Navigieren Sie für Ihr GitHub-Repository zu Actions (Aktionen).
Öffnen Sie das erste Ergebnis, um ausführliche Protokolle zur Ausführung des Workflows anzuzeigen.
Bereinigen von Ressourcen
Wenn Ihre statische Website und das GitHub-Repository nicht mehr benötigt werden, bereinigen Sie die bereitgestellten Ressourcen, indem Sie die Ressourcengruppe und Ihr GitHub-Repository löschen.