Konfigurieren von Anwendungen und VMs
Es ist üblich, Apps und anderen benutzerdefinierten Code für Ihre Azure-Lösung zu erstellen. Benutzerdefinierte Apps können Websites, APIs und Hintergrund-Apps umfassen, die ohne menschliche Interaktion ausgeführt werden. In dieser Lerneinheit erfahren Sie, wie Sie einen Workflow entwerfen, um eine App zusammen mit ihrer Infrastruktur zu erstellen und bereitzustellen.
Erstellen von Apps
Viele Arten von Apps müssen kompiliert oder erstellt sein, bevor Sie sie verwenden können. Der Buildprozess verwendet den Quellcode für die App, führt eine Abfolge von Aktivitäten für die App aus und erstellt dann eine Reihe von bereitstellbaren Dateien.
Der Buildprozess kompiliert den Quellcode in Binärdateien oder ausführbare Dateien. Ein Buildprozess umfasst normalerweise weitere Aktivitäten wie z. B. das Komprimieren der Imagedateien, die den Benutzer*innen Ihrer Website zur Verfügung gestellt werden, das Linten Ihres Codes zum Sicherstellen, dass er den bewährten Programmierungsmethoden entspricht, und das Ausführen von Komponententests, die das Verhalten einzelner Teile Ihrer App überprüfen. Sie können auch Schritte wie das digitale Signieren der Dateien ausführen, um sicherzustellen, dass sie nicht geändert werden können.
Unabhängig von der Reihe von Schritten ist die Ausgabe des Buildprozesses ein bereitstellbares Artefakt. Das Artefakt wird normalerweise im Dateisystem des Workflowrunners gespeichert. Spätere Bestandteile Ihres Workflows müssen mit dem Artefakt arbeiten, um es über Ihre Umgebungen bereitzustellen, und testen es, während es die Qualitätsprüfpunkte durchläuft, die Sie in Ihrer Workflowdefinition definieren.
Hinweis
Möglicherweise haben Sie von den Begriffen Continuous Integration und Continuous Deployment, oder CI/CD, gehört. Ein Buildprozess befindet sich im CI-Abschnitt (Continuous Integration) Ihres Workflows.
Workflowartefakte
Die Artefakte, die in Ihrem Workflow generiert werden, werden nicht in Ihrem Git-Repository gespeichert. Sie werden aus dem Quellcode abgeleitet, sind aber nicht selbst Code und gehören daher nicht in ein Quellcodeverwaltungsrepository. Sie werden im Dateisystem des Workflowrunners erstellt. Für jeden Workflowauftrag wird ein neuer Runner erstellt, weshalb Sie eine Möglichkeit benötigen, die Dateien für Aufträge und Runner freizugeben.
Workflowartefakte bieten eine Möglichkeit zum Speichern von Dateien in GitHub-Aktionen und sie sind der bestimmten Ausführung Ihres Workflows zugeordnet. Sie weisen GitHub Actions mithilfe der Workflowaktion actions/upload-artifact an, eine Datei oder einen Ordner aus dem Dateisystem des Runners als Workflowartefakt hochzuladen:
- name: Upload folder as a workflow artifact
uses: actions/upload-artifact@v3
with:
name: my-artifact-name
path: ./my-folder
Die Eigenschaft path gibt den Speicherort für den kompilierten Code oder die Ausgabedateien im Dateisystem des Workflowrunners an. Der Inhalt an diesem Speicherort wird in das Artefakt hochgeladen. Sie können eine einzelne Datei, mehrere Dateien oder einen Ordner angeben.
Jedes Artefakt hat einen Namen, den Sie mithilfe der Eigenschaft name angeben. Sie verwenden den Artefaktnamen, um später im Workflow darauf zu verweisen. Nachfolgende Workflowaufträge können das Artefakt zur Arbeit damit herunterladen, um z. B. die Website auf dem Server bereitzustellen, auf dem sie gehostet wird:
Verwenden Sie die Aktion actions/download-artifact, um alle Workflowartefakte herunterzuladen:
- uses: actions/download-artifact@v3
Oder geben Sie einen Artefaktnamen an, um nur ein bestimmtes Artefakt herunterzuladen:
- uses: actions/download-artifact@v3
with:
name: my-artifact-name
Bereitstellen von Apps
Der Buildprozess für eine App generiert und veröffentlicht ein bereitstellbares Artefakt. Spätere Aufträge im Workflow stellen das Artefakt bereit. Wie Sie eine App bereitstellen, hängt von dem Dienst ab, den Sie zum Hosten verwenden.
Bereitstellung in Azure App Service
Ihr Spielzeugunternehmen verwendet Azure App Service, um seine Website zu hosten. Sie können eine App Service-App mithilfe von Bicep erstellen und konfigurieren, aber wenn es an der Zeit ist, die App bereitzustellen, haben Sie mehrere Optionen, um die kompilierte App in die Hostinginfrastruktur zu bringen. Diese Optionen werden als Teil der App Service-Datenebene verwaltet.
Der gängigste Ansatz ist die Verwendung der Aktion azure/webapps-deploy:
- uses: azure/webapps-deploy@v2
with:
app-name: my-app-service
package: my-artifact-name/website.zip
Sie müssen mehrere Informationen bereitstellen, um Ihre App für App Service bereitzustellen. Diese Informationen umfassen den Ressourcennamen der App Service-App, den Sie mithilfe der Eigenschaft app-name angeben. Wie Sie in der vorherigen Lerneinheit erfahren haben, sollten Sie Ihrer Bicep-Datei eine Ausgabe hinzufügen und mithilfe einer Workflowvariablen den App-Namen über Ihren Workflow weitergeben. Sie müssen außerdem unter Verwendung der Eigenschaft package eine ZIP-Datei mit der zu bereitstellenden App angeben. Dies ist in der Regel der Pfad zu einem Workflowartefakt.
App Service verfügt über ein eigenes Authentifizierungssystem auf Datenebene, das für Bereitstellungen verwendet wird. Die Aktion azure/webapps-deploy übernimmt den Authentifizierungsprozess automatisch für Sie:
Die Aktion azure/webapps-deploy verwendet die Identität, die der aktiven Azure-Sitzung Ihres Auftrags zugeordnet ist, bei der Sie sich mit einer Workloadidentität angemeldet haben
. Die Aktion erstellt die erforderlichen Anmeldeinformationen für die Bereitstellung und lädt sie herunter
. Anschließend verwendet sie die Anmeldeinformationen für die Bereitstellung, wenn sie mit der App Service-API auf Datenebene kommuniziert
.
App Service bietet auch einige andere bereitstellungsbezogene Features, einschließlich Bereitstellungsslots. Slots helfen Ihnen, neue Versionen Ihrer Apps sicher und ohne Downtime bereitzustellen. Sie helfen Ihnen auch dabei, die neue Version Ihrer Anwendung vorzubereiten und aufzuwärmen, bevor Sie Produktionsdatenverkehr an sie senden. Wir verwenden in diesem Modul keine Slots, aber wir stellen einen Link zu weiteren Informationen dazu auf der Zusammenfassungsseite des Moduls bereit.
Bereitstellen von Apps für andere Azure-Dienste
Azure bietet viele weitere Optionen zum Hosten Ihrer Apps, von denen jede über einen eigenen Bereitstellungsansatz verfügt.
Azure Functions basiert auf App Service und verwendet einen Bereitstellungsprozess, der dem zuvor beschriebenen ähnelt.
Wenn Sie auf einer VM bereitstellen, müssen Sie normalerweise eine Verbindung mit der VM-Instanz herstellen, um Ihre App zu installieren. Häufig müssen Sie spezielle Tools wie Chef, Puppet oder Ansible verwenden, um eine Bereitstellung auf VMs zu orchestrieren.
Wenn Sie Kubernetes oder Azure Kubernetes Service (AKS) verwenden, verwenden Sie normalerweise einen etwas anderen Ansatz, um Ihre Lösung zu erstellen und bereitzustellen. Nachdem Ihre App erstellt wurde, erstellt Ihr Workflow ein Containerimage und veröffentlicht es in einer Containerregistrierung, aus der Ihr Kubernetes-Cluster dann liest. Da Ihre Containerregistrierung die kompilierte Anwendung enthält, verwenden Sie in der Regel kein Workflowartefakt.
In diesem Modul konzentrieren wir uns auf Azure App Service, um die zugehörigen Workflowkonzepte zu veranschaulichen. Auf der Seite „Zusammenfassung“ am Ende des Moduls finden Sie Links zu weiteren Informationen zur Bereitstellung für andere Hostingdienste.
Testen von Apps in Ihrem Workflow
In einem vorherigen Modul haben Sie erfahren, wie wertvoll und wichtig die Ausführung automatisierter Tests aus Ihrem Workflow ist. Bei der Bereitstellung einer App sollten als Best Practice für den Workflow einige Tests durchgeführt werden, die den Code der App aufrufen. Solche Tests verringern das Risiko, dass ein App- oder Bereitstellungsfehler zu Ausfallzeiten führt. In fortgeschritteneren Szenarios können Sie sogar eine Reihe von Testfällen für Ihre App ausführen, z. B. das Aufrufen von APIs oder das Übermitteln und Überwachen einer synthetischen Transaktion.
Viele Apps implementieren Endpunkte für die Integritätsprüfung. Wenn ein Integritätsprüfungsendpunkt eine Anforderung empfängt, führt er eine Reihe von Überprüfungen für die Website durch, um beispielsweise sicherzustellen, dass Datenbanken und Netzwerkdienste über die App-Umgebung erreichbar sind. Die Antwort, die die Website zurückgibt, gibt an, ob die App fehlerfrei ist. Entwickler können eigene Integritätsprüfungen schreiben und sie an die Anforderungen der App anpassen. Wenn Ihre App über einen Endpunkt für die Integritätsprüfung verfügt, ist es oft sinnvoll, ihn über Ihren Workflow zu überwachen, nachdem der Bereitstellungsauftrag abgeschlossen ist.
Ihr Bereitstellungsworkflow
In der nächsten Übung aktualisieren Sie Ihren Bereitstellungsworkflow, um neue Aufträge für die Kompilierung der Websiteanwendung und deren Bereitstellung in den einzelnen Umgebungen hinzuzufügen:
