Freigeben über

Bereitstellung auf der Azure-Infrastruktur mit GitHub-Aktionen

  • Artikel

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.

Vorteile der Verwendung von IaC und Automatisierung bei der Bereitstellung

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.

Aufbau

Architecture overview of using CI/CD to deploy Azure

Datenfluss

  1. Erstellen Sie einen neuen Bereich und überprüfen Sie die erforderlichen Änderungen am IaC-Code.
  2. Erstellen Sie eine Pull-Anforderung (PR) in GitHub, sobald Sie bereit sind, Ihre Änderungen in Ihre Umgebung einzubinden.
  3. 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.
  4. Sobald der PR angemessen geprüft wurde, kann er in Ihren Hauptzweig eingebunden werden.
  5. Ein weiterer GitHub Actions-Workflow wird vom Hauptzweig aus getriggert und führt die Änderungen über Ihren IaC-Anbieter aus.
  6. (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.

Voraussetzungen

Verwenden von Bicep

  1. 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 der production-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.

  2. 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 Umgebungsnamen production.
    • Entitätstyp festlegen auf Pull Request.
    • Setzen Sie den Entitätstyp auf Branch und verwenden Sie den Namen der Verzweigung main.

  3. 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 Azure
    • AZURE_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.

Einsatz von Terraform

  1. 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).

  2. 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 der production-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.

  3. 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 ein read/write-Konto und geben Sie ihnen die entsprechenden Berechtigungen in Ihrem Azure-Abonnement. Außerdem benötigen beide Rollen mindestens Reader 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 auf Environment und verwenden Sie den Umgebungsnamen production.

    Erstellen Sie für die read-only-Identität zwei Verbundzugangsdaten wie folgt:

    • Setzen Sie Entity Type auf Pull Request.
    • Setzen Sie Entity Type auf Branch und verwenden Sie den Namen der Verzweigung main.

  4. 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 Azure
    • AZURE_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 der read-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.

Bereitstellen mit GitHub-Aktionen

Verwenden von Bicep

Es gibt zwei Hauptworkflows in der Referenzarchitektur:

  1. Bicep Unit Tests

    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.

  2. 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.

Einsatz von Terraform

Es gibt drei Hauptworkflows in der Referenzarchitektur:

  1. Terraform Unit Tests

    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.

  2. Terraform Plan / Anwenden

    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.

  3. Terraform Drift-Erkennung

    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.