GitHub Actions in Azure

GitHub Actions ist die integrierte CI/CD- und Automatisierungsplattform von GitHub. Workflows werden in YAML-Dateien definiert, die im Verzeichnis .github/workflows/ Ihres Repositorys gespeichert und durch GitHub-Ereignisse ausgelöst werden — etwa Pushes, Pull Requests und Releases. GitHub Actions ist eng in das GitHub-Ökosystem (Issues, PRs, Pakete und Sicherheitsscans) integriert und bietet einen umfangreichen Marketplace mit Community Actions für Aufgaben wie Erstellen, Testen und Bereitstellen in Azure.

Eine GitHub-Actions-Workflowdatei besteht aus drei Abschnitten auf oberster Ebene. on definiert die auslösenden Ereignisse. env legt globale Umgebungsvariablen fest. jobs definiert einen oder mehrere Jobs, die jeweils auf einem Runner (von GitHub gehostet oder selbst gehostet) ausgeführt werden. Jeder Job enthält steps — entweder run (Shell-Skript) oder uses (eine vorgefertigte Action). Jobs werden standardmäßig parallel ausgeführt; verwenden Sie needs, um sequenzielle Abhängigkeiten zu erstellen.

Die empfohlene Methode zur Authentifizierung von GitHub Actions bei Azure ist OpenID Connect (OIDC) — dabei werden kurzlebige Token ausgestellt, ohne langlebige Geheimnisse in GitHub zu speichern. Konfigurieren Sie eine föderierte Identitätsanmeldeinformation für eine Azure-App-Registrierung oder eine verwaltete Identität und gewähren Sie ihr Vertrauen für Ihr GitHub-Repository und Ihren Branch. Verwenden Sie die Action azure/login@v2, um das GitHub-OIDC-Token gegen ein Azure-Zugriffstoken einzutauschen — Clientgeheimnisse in GitHub Secrets sind nicht erforderlich.

Die Action azure/webapps-deploy@v3 stellt Code oder ein Containerimage in Azure App Service bereit. Sie unterstützt Slot-Bereitstellungen, paketbasierte Bereitstellungen und die Bereitstellung von Docker-Images. Kombinieren Sie sie zur Authentifizierung mit azure/login@v2. Sie können einen Staging-Slot als Ziel auswählen, Smoke-Tests ausführen und ihn anschließend mit der Action azure/CLI@v2, die den Befehl zum Austauschen der Slots ausführt, austauschen — so reproduzieren Sie das Blue-Green-Bereitstellungsmuster von Azure Pipelines vollständig in GitHub Actions.

Stellen Sie mit der Action azure/k8s-deploy@v5 aus GitHub Actions in AKS bereit. Diese Action verwendet kubectl apply, um Manifeste bereitzustellen, führt eine Image-Substitution durch (dabei wird das Image-Tag durch das Tag des aktuellen Builds ersetzt) und überwacht den Zustand des Rollouts. Die Action azure/aks-set-context@v4 konfiguriert die kubectl-Anmeldeinformationen, indem sie die Kubeconfig des Clusters über die authentifizierte Azure-Sitzung abruft.

Speichern Sie vertrauliche Werte in GitHub Secrets — verschlüsselte Werte, die in Workflows als ${{ secrets.SECRET_NAME }} zugänglich sind. Nicht vertrauliche Konfigurationen gehören in GitHub Variables — sie sind als ${{ vars.VARIABLE_NAME }} zugänglich. Beide können auf ein Repository, eine Umgebung oder eine Organisation begrenzt werden. Verwenden Sie environments in GitHub Actions, um ähnlich wie bei Azure DevOps Environments Schutzregeln (erforderliche Prüfer und Bereitstellungsbranches) hinzuzufügen.

GitHub-Actions-Environments (konfiguriert unter Repository Settings → Environments) fügen ähnlich wie Azure-DevOps-Umgebungen Bereitstellungsschranken hinzu. Sie können required reviewers festlegen, die vor der Ausführung eines Jobs für diese Umgebung eine Genehmigung erteilen müssen, Bereitstellungen auf bestimmte Branches beschränken (nur main darf in Production bereitstellen) und Wartezeiten hinzufügen, um Bereitstellungen zu verzögern. Jobs für eine geschützte Umgebung werden angehalten, bis alle Schutzregeln erfüllt sind.

Vermeiden Sie doppelte CI/CD-Logik in verschiedenen Repositorys, indem Sie zwei Funktionen von GitHub Actions nutzen. Mit wiederverwendbaren Workflows können Sie einen Workflow in einem Repository definieren und ihn aus Workflows anderer Repositorys über uses: myorg/shared-workflows/.github/workflows/deploy.yml@main aufrufen. Composite Actions bündeln mehrere Schritte in einer einzelnen Action, die in einem Repository gespeichert und mit uses: myorg/my-actions/deploy@v1 wiederverwendet wird. Beide unterstützen DRY-Prinzipien in den CI/CD-Pipelines Ihrer Organisation.

Wählen Sie GitHub Actions, wenn Ihr Code auf GitHub gehostet wird, Ihr Team die GitHub-Oberfläche bevorzugt, Sie eine enge Integration mit GitHub-PR-Prüfungen und Codescans wünschen oder Open-Source-Projekte entwickeln (großzügiges kostenloses Kontingent). Wählen Sie Azure Pipelines, wenn Sie die Integration mit Azure Boards, erweiterte Tests mit Azure Test Plans, die Verwaltung von Azure-Artifact-Feeds oder Code in Azure Repos benötigen oder ein komplexes mehrstufiges Release-Management mit Gates über viele Umgebungen hinweg brauchen. Beide Lösungen unterstützen die Bereitstellung in Azure gleichermaßen gut.

Der GitHub Actions Marketplace enthält Tausende von Community- und offiziellen Actions für gängige Aufgaben. Microsoft veröffentlicht offizielle Azure-Actions: azure/login, azure/webapps-deploy, azure/aks-set-context, azure/k8s-deploy, azure/CLI, azure/arm-deploy und viele weitere. Fixieren Sie Actions immer auf ein bestimmtes Versions-Tag (z. B. @v3) oder eine Commit-SHA, um Supply-Chain-Angriffe zu verhindern, bei denen eine manipulierte Action mit schädlichem Code aktualisiert wird.

Von GitHub gehostete Runner haben nur Zugriff auf das öffentliche Internet — sie können private Azure-Ressourcen (SQL-Datenbanken, interne APIs) nicht erreichen, ohne diese Ressourcen öffentlich verfügbar zu machen. Verwenden Sie self-hosted Runner auf Azure-VMs innerhalb Ihres VNet, um private Ressourcen bereitzustellen. Registrieren Sie einen Runner, indem Sie den GitHub-Actions-Runner-Agent herunterladen, ihn mit der URL Ihres Repositorys und einem Registrierungstoken konfigurieren und als Dienst ausführen. Skalieren Sie selbst gehostete Runner mit Azure Container Apps für elastische Runner-Pools.

In dieser Lektion haben Sie gelernt: GitHub-Actions-Workflows sind YAML-Dateien in .github/workflows/, die durch GitHub-Ereignisse ausgelöst und auf Runnern ausgeführt werden, föderierte OIDC-Anmeldeinformationen ermöglichen eine Azure-Authentifizierung von GitHub Actions ohne Geheimnisse, und GitHub Environments mit Schutzregeln fügen Genehmigungsschranken für Produktionsbereitstellungen hinzu. Damit ist der Azure-DevOps-Kurs abgeschlossen — als Nächstes folgen Azure Monitor und Log Analytics.