Bereitstellung auf der Azure-Infrastruktur mit GitHub-Aktionen
In dieser Anleitung erfahren Sie, wie Sie CI/CD und Infrastructure as Code (IaC) nutzen, um Azure mit GitHub Actions automatisiert und wiederholbar bereitzustellen.
Dieser Artikel bietet einen Überblick über die Architektur und stellt eine strukturierte Lösung für die Entwicklung einer Anwendung auf Azure vor, die skalierbar, sicher, stabil und hoch verfügbar ist. Weitere Beispiele für Cloud-Architekturen und Lösungsideen aus der Praxis finden Sie unter Azure-Architekturen.
Es gibt viele Möglichkeiten der Bereitstellung in Azure, darunter das Azure-Portal, CLI, API und mehr. In diesem Leitfaden werden wir IaC und CI/CD-Automatisierung verwenden. Dieser Ansatz bietet folgende Vorteile:
Deklarativ: Wenn Sie Ihre Infrastruktur und den Prozess der Bereitstellung im Code definieren, kann dieser mit Hilfe des Standard-Lebenszyklus der Softwareentwicklung versioniert und überprüft werden. IaC hilft auch, eine Abweichung in Ihrer Konfiguration zu verhindern.
Konsistenz: Die Einhaltung eines IaC-Prozesses stellt sicher, dass das gesamte Unternehmen einer standardisierten, gut etablierten Methode zur Bereitstellung der Infrastruktur folgt, die Best Practices (bewährte Verfahren) beinhaltet und für Ihre Sicherheitsanforderungen gerüstet ist. Alle Verbesserungen, die an den zentralen Vorlagen vorgenommen werden, können problemlos auf das gesamte Unternehmen übertragen werden.
Sicherheit: Zentral verwaltete Vorlagen können von einem Cloud-Betriebs- oder Sicherheitsteam abgesichert und genehmigt werden, um interne Standards zu erfüllen.
Self-Service: Teams können ihre eigene Infrastruktur mit Hilfe von zentral verwalteten Vorlagen bereitstellen.
Verbesserte Produktivität: Durch die Verwendung von Standardvorlagen können Teams neue Umgebungen schnell bereitstellen, ohne sich um alle Details der Implementierung kümmern zu müssen.
Weitere Informationen finden Sie unter wiederholbare Infrastruktur im Azure Architecture Center oder unter Infrastruktur als Code im DevOps Resource Center.
- Erstellen Sie einen neuen Bereich und überprüfen Sie die erforderlichen Änderungen am IaC-Code.
- Erstellen Sie eine Pull-Anforderung (PR) in GitHub, sobald Sie bereit sind, Ihre Änderungen in Ihre Umgebung einzubinden.
- Ein GitHub Actions Workflow wird ausgelöst, um sicherzustellen, dass Ihr Code gut formatiert und intern konsistent ist und eine sichere Infrastruktur erzeugt. Außerdem wird ein Terraform Plan oder eine Bicep Was-wäre-wenn (What-if) Analyse ausgeführt, um eine Vorschau auf die Änderungen zu erstellen, die in Ihrer Azure-Umgebung vorgenommen werden.
- Sobald der PR angemessen geprüft wurde, kann er in Ihren Hauptzweig eingebunden werden.
- Ein weiterer GitHub Actions-Workflow wird vom Hauptzweig aus getriggert und führt die Änderungen über Ihren IaC-Anbieter aus.
- (exklusiv für Terraform) Ein regelmäßig geplanter GitHub Action-Workflow sollte ebenfalls laufen, um nach Konfigurationsänderungen in Ihrer Umgebung zu suchen und eine neue Ausgabe zu erstellen, wenn Änderungen festgestellt werden.
Erstellen von GitHub-Umgebungen
Die Workflows nutzen GitHub-Umgebungen und -Geheimnisse, um die Azure-Identitätsinformationen zu speichern und einen Genehmigungsprozess für die Bereitstellung einzurichten. Erstellen Sie eine Umgebung namens
production
, indem Sie diese Anweisungen befolgen. Richten Sie in derproduction
-Umgebung eine Schutzregel ein und fügen Sie alle erforderlichen Genehmiger hinzu, die die Bereitstellung in der Produktion absegnen müssen. Sie können die Umgebung auch auf Ihren Hauptzweig beschränken. Eine ausführliche Anleitung finden Sie hier.Einrichten von Azure Identity:
Es ist eine Azure Active Directory-Anwendung erforderlich, die über die Berechtigung zur Bereitstellung innerhalb Ihres Azure-Abonnements verfügt. Erstellen Sie eine einzelne Anwendung und geben Sie ihr die entsprechenden Lese-/Schreibrechte in Ihrem Azure-Abonnement. Als nächstes richten Sie die Verbundzugangsdaten ein, damit GitHub die Identität über OpenID Connect (OIDC) nutzen kann. Siehe Azure Dokumentation für detaillierte Anweisungen. Drei Verbundzugangsdaten müssen hinzugefügt werden:
- Setzen Sie Entitätstyp auf
Environment
und verwenden Sie den Umgebungsnamenproduction
. - Entitätstyp festlegen auf
Pull Request
. - Setzen Sie den Entitätstyp auf
Branch
und verwenden Sie den Namen der Verzweigungmain
.
- Setzen Sie Entitätstyp auf
GitHub-Secrets
Hinweis
Obwohl keine der Daten über die Azure-Identitäten irgendwelche Secrets oder Credentials enthalten, verwenden wir dennoch GitHub Secrets als bequemes Mittel zur Parametrisierung der Identitätsinformationen pro Umgebung.
Erstellen Sie die folgenden Secrets für das Repository unter Verwendung der Azure-Identität:
AZURE_CLIENT_ID
: Die Anwendungs-(Client-)ID der App-Registrierung in AzureAZURE_TENANT_ID
: Die Tenant-ID von Azure Active Directory, wo die App-Registrierung definiert ist.AZURE_SUBSCRIPTION_ID
: Die Abonnement-ID, in der die App-Registrierung definiert ist.
Anweisungen zum Hinzufügen der Secrets zum Repository finden Sie hier.
Konfiguration des Terraform-Status-Speicherorts
Terraform verwendet eine Statusdatei, um Informationen über den aktuellen Status Ihrer verwalteten Infrastruktur und der zugehörigen Konfiguration zu speichern. Diese Datei muss zwischen verschiedenen Durchläufen des Workflows beibehalten werden. Es wird empfohlen, diese Datei in einem Azure-Storage-Konto oder einem anderen ähnlichen Remote-Backend zu speichern. Normalerweise würde dieser Speicher manuell oder über einen separaten Workflow bereitgestellt werden. Der Terraform-Backend-Block muss mit dem von Ihnen gewählten Speicherort aktualisiert werden (siehe hier für die Dokumentation).
Erstellen einer GitHub-Umgebung
Die Workflows nutzen GitHub-Umgebungen und -Geheimnisse, um die Azure-Identitätsinformationen zu speichern und einen Genehmigungsprozess für die Bereitstellung einzurichten. Erstellen Sie eine Umgebung namens
production
, indem Sie diese Anweisungen befolgen. Richten Sie in derproduction
-Umgebung eine Schutzregel ein und fügen Sie alle erforderlichen Genehmiger hinzu, die die Bereitstellung in der Produktion absegnen müssen. Sie können die Umgebung auch auf Ihren Hauptzweig beschränken. Eine ausführliche Anleitung finden Sie hier.Einrichten von Azure Identity:
Es ist eine Azure Active Directory-Anwendung erforderlich, die über die Berechtigung zur Bereitstellung innerhalb Ihres Azure-Abonnements verfügt. Erstellen Sie eine separate Anwendung für ein
read-only
- und einread/write
-Konto und geben Sie ihnen die entsprechenden Berechtigungen in Ihrem Azure-Abonnement. Außerdem benötigen beide Rollen mindestensReader and Data Access
Berechtigungen für das Speicherkonto, in dem der Terraform-Status aus Schritt 1 gespeichert ist. Als nächstes richten Sie die Verbundzugangsdaten ein, damit GitHub die Identität über OpenID Connect (OIDC) nutzen kann. Siehe Azure Dokumentation für detaillierte Anweisungen.Erstellen Sie für die
read/write
-Identität Verbundzugangsdaten wie folgt:- Setzen Sie
Entity Type
aufEnvironment
und verwenden Sie den Umgebungsnamenproduction
.
Erstellen Sie für die
read-only
-Identität zwei Verbundzugangsdaten wie folgt:- Setzen Sie
Entity Type
aufPull Request
. - Setzen Sie
Entity Type
aufBranch
und verwenden Sie den Namen der Verzweigungmain
.
- Setzen Sie
GitHub-Secrets
Hinweis
Obwohl keine der Daten über die Azure-Identitäten irgendwelche Secrets oder Credentials enthalten, verwenden wir dennoch GitHub Secrets als bequemes Mittel zur Parametrisierung der Identitätsinformationen pro Umgebung.
Erstellen Sie die folgenden Secrets für das Repository unter Verwendung der
read-only
-Identität:AZURE_CLIENT_ID
: Die Anwendungs-(Client-)ID der App-Registrierung in AzureAZURE_TENANT_ID
: Die Tenant-ID von Azure Active Directory, wo die App-Registrierung definiert ist.AZURE_SUBSCRIPTION_ID
: Die Abonnement-ID, in der die App-Registrierung definiert ist.
Anweisungen zum Hinzufügen der Secrets zum Repository finden Sie hier.
Erstellen Sie ein weiteres Secret in der
production
-Umgebung unter Verwendung derread-write
-Identität:AZURE_CLIENT_ID
: Die Anwendungs-(Client-)ID der App-Registrierung in Azure
Eine Anleitung zum Hinzufügen der Secrets zur Umgebung finden Sie hier. Das Secret der Umgebung hat Vorrang vor dem Secret des Repositorys, wenn der Schritt der Bereitstellung in der
production
-Umgebung durchgeführt wird und erhöhte Lese-/Schreibberechtigungen erforderlich sind.
Es gibt zwei Hauptworkflows in der Referenzarchitektur:
-
Dieser Workflow wird bei jeder Übertragung ausgeführt und besteht aus einer Reihe von Unit-Tests für den Infrastrukturcode. Es führt den Bicep-Build aus, um die Bicep in eine ARM-Vorlage zu kompilieren. Dies stellt sicher, dass es keine Formatierungsfehler gibt. Als nächstes wird eine Überprüfung durchgeführt, um sicherzustellen, dass die Vorlage bereitgestellt werden kann. Schließlich wird Checkov, ein Open-Source-Tool zur statischen Codeanalyse für IaC, ausgeführt, um Sicherheits- und Compliance-Probleme zu erkennen. Wenn das Repository GitHub Advanced Security (GHAS) verwendet, werden die Ergebnisse auf GitHub hochgeladen.
Bicep What-If / Bereitstellung
Dieser Workflow läuft bei jeder Pull-Anforderung und bei jeder Übergabe an den Hauptzweig. Die Was-wäre-wenn-Phase (What-if) des Workflows wird verwendet, um die Auswirkungen der IaC-Änderungen auf die Azure-Umgebung zu verstehen, indem What-if ausgeführt wird. Dieser Bericht wird dann zur einfachen Überprüfung an den PR angehängt. Die Bereitstellung erfolgt nach der What-if-Analyse, wenn der Workflow durch einen Push auf den Hauptzweig ausgelöst wird. In dieser Phase wird die Vorlage auf Azure bereitgestellt, nachdem eine manuelle Überprüfung stattgefunden hat.
Es gibt drei Hauptworkflows in der Referenzarchitektur:
-
Dieser Workflow wird bei jeder Übertragung ausgeführt und besteht aus einer Reihe von Unit-Tests für den Infrastrukturcode. Es wird terraform fmt ausgeführt, um sicherzustellen, dass der Code ordnungsgemäß verknüpft ist und den bewährten Verfahren von terraform entspricht. Als nächstes führt es terraform validate aus, um zu überprüfen, ob der Code syntaktisch korrekt und intern konsistent ist. Schließlich wird Checkov, ein Open-Source-Tool zur statischen Codeanalyse für IaC, ausgeführt, um Sicherheits- und Compliance-Probleme zu erkennen. Wenn das Repository GitHub Advanced Security (GHAS) verwendet, werden die Ergebnisse auf GitHub hochgeladen.
-
Dieser Workflow läuft bei jeder Pull-Anforderung und bei jeder Übergabe an den Hauptzweig. Die Planungsphase des Workflows dient dazu, die Auswirkungen der IaC-Änderungen auf die Azure-Umgebung zu verstehen, indem Terraform Plan ausgeführt wird. Dieser Bericht wird dann zur einfachen Überprüfung an den PR angehängt. Die Anwendungsphase läuft nach dem Plan, wenn der Workflow durch einen Push auf den Hauptzweig ausgelöst wird. In dieser Phase wird das Plandokument übernommen und die Änderungen werden nach einer manuellen Überprüfung übernommen, wenn noch Änderungen an der Umgebung ausstehen.
-
Dieser Workflow wird in regelmäßigen Abständen ausgeführt, um Ihre Umgebung auf Konfigurationsabweichungen oder Änderungen außerhalb von Terraform zu überprüfen. Wenn eine Abweichung festgestellt wird, wird ein GitHub Issue erstellt, um die Projektverantwortlichen zu alarmieren.