Freigeben über

Bereitstellen der Azure-Infrastruktur mit GitHub-Aktionen

In diesem Leitfaden behandeln wir die Verwendung von CI/CD und Infrastructure as Code (IaC) für die Bereitstellung in Azure mit GitHub-Aktionen auf automatisierte und wiederholbare Weise.

Dieser Artikel ist eine Architekturübersicht und stellt eine strukturierte Lösung zum Entwerfen einer Anwendung auf Azure dar, die skalierbar, sicher, robust und hoch verfügbar ist. Um echte Beispiele für Cloudarchitekturen und Lösungsideen zu sehen, durchsuchen Sie Azure-Architekturen.

Vorteile der Verwendung von IaC und Automatisierung für Bereitstellungen

Es gibt viele Möglichkeiten, um Azure bereitzustellen, einschließlich des Azure-Portals, der CLI, der API und mehr. Für diese Anleitung verwenden wir IaC- und CI/CD-Automatisierung. Zu den Vorteilen dieses Ansatzes gehören:

  • Deklarativ: Wenn Sie Ihren Infrastruktur- und Bereitstellungsprozess im Code definieren, kann er mithilfe des Standardmäßigen Softwareentwicklungslebenszyklus versionsgesteuert und überprüft werden. IaC trägt auch dazu bei, jede Abweichung in Ihrer Konfiguration zu verhindern.

  • Konsistenz: Durch das Ausführen eines IaC-Prozesses wird sichergestellt, dass die gesamte Organisation eine standardmäßige, bewährte Methode zum Bereitstellen von Infrastruktur befolgt, die bewährte Methoden enthält und für Ihre Sicherheitsanforderungen gehärtet ist. Alle Verbesserungen an den zentralen Vorlagen können problemlos in der gesamten Organisation angewendet werden.

  • Sicherheit: Zentral verwaltete Vorlagen können von einem Cloudbetriebs- oder Sicherheitsteam gehärtet und genehmigt werden, um interne Standards zu erfüllen.

  • Self-Service: Teams können in der Lage sein, ihre eigene Infrastruktur bereitzustellen, indem zentral verwaltete Vorlagen verwendet werden.

  • Verbesserte Produktivität: Durch die Verwendung von Standardvorlagen können Teams schnell neue Umgebungen bereitstellen, ohne sich Gedanken über alle Implementierungsdetails machen zu müssen.

Weitere Informationen finden Sie unter wiederholbarer Infrastruktur im Azure Architecture Center oder der Infrastruktur als Code im DevOps Resource Center.

Architektur

Architekturübersicht über die Verwendung von CI/CD zur Bereitstellung von Azure

Datenfluss

  1. Erstellen Sie eine neue Verzweigung, und überprüfen Sie die erforderlichen IaC-Codeänderungen.
  2. Erstellen Sie eine Pull-Anforderung (PR) in GitHub, sobald Sie bereit sind, Ihre Änderungen in Ihrer Umgebung zusammenzuführen.
  3. Ein GitHub Actions-Workflow wird ausgelöst, um sicherzustellen, dass Ihr Code gut formatiert, intern konsistent ist und sichere Infrastruktur erzeugt. Darüber hinaus wird eine Terraform Plan- oder Bicep Was-wäre-wenn-Analyse ausgeführt, um eine Vorschau der Änderungen zu erstellen, die in Ihrer Azure-Umgebung erfolgen werden.
  4. Nach der entsprechenden Überprüfung kann die PR in Ihre Hauptzweige zusammengeführt werden.
  5. Ein anderer GitHub-Aktionsworkflow wird aus dem Hauptzweig ausgelöst und führt die Änderungen mit Ihrem IaC-Anbieter aus.
  6. (exklusiv für Terraform) Ein regelmäßig geplanter GitHub-Aktionsworkflow sollte auch ausgeführt werden, um nach jeder Konfigurationsabweichung in Ihrer Umgebung zu suchen und ein neues Problem zu erstellen, wenn Änderungen erkannt werden.

Voraussetzungen

Verwenden von Bicep

  1. Erstellen von GitHub-Umgebungen

    Die Workflows verwenden GitHub-Umgebungen und geheime Schlüssel, um die Azure-Identitätsinformationen zu speichern und einen Genehmigungsprozess für Bereitstellungen einzurichten. Erstellen Sie eine Umgebung mit dem Namen production , indem Sie diese Anweisungen befolgen. Richten Sie in der production Umgebung eine Schutzregel ein, und fügen Sie alle erforderlichen genehmigenden Personen hinzu, die sich bei Produktionsbereitstellungen abmelden müssen. Sie können die Umgebung auch auf Ihren Hauptzweig beschränken. Ausführliche Anweisungen finden Sie hier.

  2. Einrichten von Azure Identity:

    Eine Azure Active Directory-Anwendung ist erforderlich, die über Berechtigungen zum Bereitstellen in Ihrem Azure-Abonnement verfügt. Erstellen Sie eine einzelne Anwendung, und erteilen Sie ihm die entsprechenden Lese-/Schreibberechtigungen in Ihrem Azure-Abonnement. Richten Sie als Nächstes die Verbundanmeldeinformationen ein, damit GitHub die Identität mithilfe von OpenID Connect (OIDC) nutzen kann. Ausführliche Anweisungen finden Sie in der Azure-Dokumentation . Drei verbundene Anmeldeinformationen müssen hinzugefügt werden:

    • Legen Sie den Entitätstyp auf Environment fest und verwenden Sie den Umgebungsnamen production.
    • Setzen Sie den Entitätstyp auf Pull Request.
    • Legen Sie den Entitätstyp auf Branch fest, und verwenden Sie den Verzweigungsnamen main.

  3. Hinzufügen von GitHub-Geheimschlüsseln

    Hinweis

    Obwohl keine der Daten über die Azure-Identitäten geheime Schlüssel oder Anmeldeinformationen enthält, verwenden wir weiterhin GitHub-Geheimnisse als praktische Möglichkeit, die Identitätsinformationen pro Umgebung zu parametrisieren.

    Erstellen Sie die folgenden geheimen Schlüssel im Repository mithilfe der Azure-Identität:

    • AZURE_CLIENT_ID : Die Anwendungs-ID (Client) der App-Registrierung in Azure
    • AZURE_TENANT_ID : Die Mandanten-ID von Azure Active Directory, in dem die App-Registrierung definiert ist.
    • AZURE_SUBSCRIPTION_ID : Die Abonnement-ID, in der die App-Registrierung definiert ist.

    Anweisungen zum Hinzufügen der geheimen Schlüssel zum Repository finden Sie hier.

Einsatz von Terraform

  1. Standort des Terraform-Zustands konfigurieren

    Terraform verwendet eine Zustandsdatei , um Informationen zum aktuellen Zustand Ihrer verwalteten Infrastruktur und der zugehörigen Konfiguration zu speichern. Diese Datei muss zwischen verschiedenen Ausführungsläufen des Workflows beibehalten werden. Der empfohlene Ansatz besteht darin, diese Datei in einem Azure Storage-Konto oder einem anderen ähnlichen Remote-Back-End zu speichern. Normalerweise wird dieser Speicher manuell oder über einen separaten Workflow bereitgestellt. Der Terraform-Back-End-Block muss mit Ihrem ausgewählten Speicherort aktualisiert werden (siehe hier zur Dokumentation).

  2. Erstellen einer GitHub-Umgebung

    Die Workflows verwenden GitHub-Umgebungen und geheime Schlüssel, um die Azure-Identitätsinformationen zu speichern und einen Genehmigungsprozess für Bereitstellungen einzurichten. Erstellen Sie eine Umgebung mit dem Namen production , indem Sie diese Anweisungen befolgen. Richten Sie in der production-Umgebung eine Schutzregel ein und fügen Sie alle erforderlichen Genehmigenden hinzu, die Produktionsbereitstellungen genehmigen müssen. Sie können die Umgebung auch auf Ihre Hauptzweige beschränken. Ausführliche Anweisungen finden Sie hier.

  3. Einrichten von Azure Identity:

    Eine Azure Active Directory-Anwendung ist erforderlich, die über Berechtigungen zum Bereitstellen in Ihrem Azure-Abonnement verfügt. Erstellen Sie eine separate Anwendung für ein read-only und read/write Konten, und geben Sie ihnen die entsprechenden Berechtigungen in Ihrem Azure-Abonnement. Darüber hinaus benötigen beide Rollen mindestens Reader and Data Access Berechtigungen für das Speicherkonto, in dem sich der Terraform-Zustand aus Schritt 1 befindet. Richten Sie als Nächstes die Verbundanmeldeinformationen ein, damit GitHub die Identität mithilfe von OpenID Connect (OIDC) nutzen kann. Ausführliche Anweisungen finden Sie in der Azure-Dokumentation .

    Erstellen Sie für die read/write Identität eine Verbundanmeldeinformation wie folgt:

    • Setzen Sie Entity Type auf Environment und verwenden Sie den Umgebungsnamen production.

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

    • Legen Sie Entity Type auf Pull Request fest.
    • Legen Sie Entity Type auf Branch fest und verwenden Sie den Verzweigungsnamen main.

  4. Hinzufügen von GitHub-Geheimschlüsseln

    Hinweis

    Obwohl keine der Daten über die Azure-Identitäten geheime Schlüssel oder Anmeldeinformationen enthält, verwenden wir weiterhin GitHub-Geheimnisse als praktische Möglichkeit, die Identitätsinformationen pro Umgebung zu parametrisieren.

    Erstellen Sie die folgenden geheimen Schlüssel für das Repository mithilfe der read-only Identität:

    • AZURE_CLIENT_ID : Die Anwendungs-ID (Client) der App-Registrierung in Azure
    • AZURE_TENANT_ID : Die Mandanten-ID von Azure Active Directory, in dem die App-Registrierung definiert ist.
    • AZURE_SUBSCRIPTION_ID : Die Abonnement-ID, in der die App-Registrierung definiert ist.

    Anweisungen zum Hinzufügen der geheimen Schlüssel zum Repository finden Sie hier.

    Erstellen Sie ein weiteres Geheimnis in der production-Umgebung mithilfe der read-write-Identität:

    • AZURE_CLIENT_ID : Die Anwendungs-ID (Client) der App-Registrierung in Azure

    Anweisungen zum Hinzufügen der geheimen Schlüssel zur Umgebung finden Sie hier. Der geheime Umgebungsschlüssel überschreibt den geheimen Repositoryschlüssel, wenn der Bereitstellungsschritt für die production Umgebung ausgeführt wird, wenn erhöhte Lese-/Schreibberechtigungen erforderlich sind.

Bereitstellen mit GitHub Actions

Verwenden von Bicep

Es gibt zwei Hauptworkflows in der Referenzarchitektur:

  1. Bicep Unit Tests

    Dieser Workflow wird für jeden Commit ausgeführt und besteht aus einer Reihe von Komponententests für den Infrastrukturcode. Es führt bicep build aus, um den Bicep in eine ARM-Vorlage zu kompilieren. Dadurch wird sichergestellt, dass keine Formatierungsfehler auftreten. Als Nächstes führt sie eine Überprüfung durch, um sicherzustellen, dass die Vorlage bereitgestellt werden kann. Schließlich wird Checkov, ein Analysetool für statischen Open Source-Code für IaC, ausgeführt, um Sicherheits- und Complianceprobleme zu erkennen. Wenn das Repository GitHub Advanced Security (GHAS) verwendet, werden die Ergebnisse auf GitHub hochgeladen.

  2. Bicep What-If / Bereitstellen

    Dieser Workflow wird für jede Pullanforderung und für jeden Commit an die Hauptzweigung ausgeführt. Die Was-wäre-wenn-Phase des Workflows wird verwendet, um die Auswirkungen der IaC-Änderungen auf die Azure-Umgebung zu verstehen, indem Was-wäre-wenn ausgeführt wird. Dieser Bericht wird dann zur einfachen Überprüfung an die PR angefügt. Die Bereitstellungsphase wird nach der "Was-wäre-wenn"-Analyse ausgeführt, wenn der Workflow durch einen Push an die Hauptbranch ausgelöst wird. In dieser Phase wird die Vorlage nach einer manuellen Überprüfung bereitgestellt in Azure.

Einsatz von Terraform

Es gibt drei Hauptworkflows in der Referenzarchitektur:

  1. Terraform Unit Tests

    Dieser Workflow wird für jeden Commit ausgeführt und besteht aus einer Reihe von Komponententests für den Infrastrukturcode. Es führt terraform fmt aus, um sicherzustellen, dass der Code ordnungsgemäß formatiert ist und den bewährten Terraform-Methoden folgt. Als Nächstes führt es terraform validate aus, um zu überprüfen, dass der Code syntaktisch korrekt und intern konsistent ist. Schließlich wird Checkov, ein Analysetool für statischen Open Source-Code für IaC, ausgeführt, um Sicherheits- und Complianceprobleme zu erkennen. Wenn das Repository GitHub Advanced Security (GHAS) verwendet, werden die Ergebnisse auf GitHub hochgeladen.

  2. Terraform-Plan / Anwenden

    Dieser Workflow wird für jede Pullanforderung und für jeden Commit an die Hauptzweigung ausgeführt. Die Planungsphase des Workflows wird verwendet, um die Auswirkungen der IaC-Änderungen auf die Azure-Umgebung durch ausführen eines Terraformplans zu verstehen. Dieser Bericht wird dann für eine einfache Überprüfung an die PR angefügt. Die anwendende Phase wird nach dem Plan ausgeführt, wenn der Workflow durch einen Push an die Hauptzweigung ausgelöst wird. Diese Phase übernimmt das Plandokument und wendet die Änderungen an, nachdem eine manuelle Überprüfung abgeschlossen wurde, sofern ausstehende Änderungen an der Umgebung vorhanden sind.

  3. Terraform Drift Detection

    Dieser Workflow wird regelmäßig ausgeführt, um Ihre Umgebung nach konfigurationsabweichungen oder Änderungen zu scannen, die außerhalb von Terraform vorgenommen wurden. Wenn eine Abweichung erkannt wird, wird ein GitHub-Issue eröffnet, um die Betreuer des Projekts zu benachrichtigen.

  • Last updated on