Empfehlungen für die Infrastruktur als Code verwenden

---

Übersicht

Mit Google Cloud Policy Intelligence können Unternehmen ihre Richtlinien nachvollziehen und verwalten und so Risiken reduzieren. Durch bessere Sichtbarkeit und Automatisierung erhöhen Kunden ihre Sicherheit ohne zusätzliche Arbeitslast.

Mit Recommender können Sie Empfehlungen für Google Cloud-Ressourcen abrufen und so die Sicherheit der Cloud verbessern, Kosten sparen und vieles mehr. Eine Liste der unterstützten Empfehlungen finden Sie in der Recommender-Dokumentation. In dieser Anleitung wird die Verwendung von Größenempfehlungen für VM-Instanzen und Empfehlungen zur Identitäts- und Zugriffsverwaltung (IAM) beschrieben. Recommender verwendet maschinelles Lernen, um Administratoren Empfehlungen zum Beenden unnötigen Zugriffs auf Google Cloud-Ressourcen und zum Anpassen der Größe von Compute Engine-Instanzen für eine effizientere Ressourcennutzung zu geben.

Jede Empfehlung enthält eine vorgeschlagene Aktion und deren Auswirkungen. Nachdem Sie die Empfehlungen für die ermittelten Auswirkungen sowie andere für Ihre Umgebung spezifische Aspekte gelesen haben, können Sie die Empfehlungen auswählen, die Sie anwenden möchten. Sie können Empfehlungen manuell über die Google Cloud Console anwenden oder sie programmatisch anwenden, indem Sie sie in Ihre IaC-Pipeline (Infrastructure as Code) integrieren.

Mit IaC können Sie die Erstellung Ihrer Google Cloud-Ressourcen automatisieren. Sie müssen dafür Ihr IaC-Repository auf dem neuesten Stand halten und Änderungen der Google Cloud-Organisation dort vornehmen. IaC-Strategien in Organisationen sind im Allgemeinen nützlich, wenn sie umfassend implementiert sind und als einzige Version der Wahrheit für Ihre Cloud-Infrastruktur dienen. Es ist äußerst wichtig, Ihr IaC-Repository auf dem neuesten Stand zu halten, um Ablenkungen zwischen der Version Ihrer Infrastruktur, die Ihr IaC-Repository widerspiegelt, und dem, was Sie in der Organisation haben, zu vermeiden.

IAM-Empfehlungen

Bei einem der führenden Best Practices handelt es sich um ein gängiges Sicherheitsprinzip der geringsten Berechtigung und gründliche Überlegungen, wie Änderungen an Ihrer Organisation in Ihr IaC-Repository übernommen und synchronisiert werden.

Größenempfehlung für VMs

Mit Größenempfehlungen können Sie Ihre Kosten senken, indem Sie Vorschläge zur Größenanpassung der Maschinentypen Ihrer Instanzen erhalten, damit Sie Instanzressourcen effizienter nutzen können.

In dieser Anleitung wird beschrieben, wie Sie eine Automatisierungspipeline entwerfen und erstellen, um eine Policy Intelligence-Empfehlung programmatisch anzuwenden. Im Rahmen dieser Automatisierungspipeline erfahren Sie, wie Sie Ihr Repository mit den Änderungen aktualisieren, die Sie basierend auf der VM-Größenanpassung und der Binding-Empfehlung der IAM-Richtlinie, die Recommender zur Verfügung stellt, an Ihrer Google Cloud-Organisation vornehmen.

In dieser Anleitung wird Hashicorp Terraform als IaC-Tool verwendet, wobei die in der beschriebenen Automatisierungspipeline verwendeten Architekturmuster und -komponenten auch dann verwendet werden können, wenn Sie ein anderes IaC-Verwaltungstool wie Deployment Manager verwenden. Sie müssen die mit dieser Anleitung verfügbare Open-Source-Codebasis an Ihre spezifische IaC-Implementierung anpassen.

Dieser Leitfaden richtet sich an Architekten, Produkteigentümer und Entwickler, die für die Verwaltung, Sicherheit und Infrastrukturplanung ihrer Google Cloud verantwortlich sind.

Architektur der Automatisierungspipeline

Das folgende Diagramm zeigt die Komponenten, die Sie in dieser Automatisierungspipeline verwenden.

Ein geplanter Cloud Scheduler-Job führt den Recommender-Parser-Dienst aus. Der Dienst ruft die Recommender API auf, um Recommender-Empfehlungen für die von Ihnen angegebenen Projekte abzurufen. Anschließend parst diese VM-Größenanpassung- und IAM-Empfehlungen, um sie der Konfiguration in Ihren Terraform-Manifesten zuzuordnen. Der Dienst aktualisiert Ihre IaC-Manifeste entsprechend diesen Empfehlungen. Er generiert eine Pull-Anfrage mit den Änderungen, damit Sie die Aktualisierungen prüfen können. Nachdem Sie die Pull-Anfrage geprüft und zusammengeführt haben, führt ein Cloud Build-Job die Änderungen an Ihrer Infrastruktur in Ihrer Google Cloud-Organisation aus.

In der Pipeline werden mehrere zusätzliche Google Cloud-Dienste verwendet, um verarbeitete Empfehlungen zu verfolgen, Benachrichtigungen zum Abschluss des Builds zu generieren und den Terraform-Zustand zu speichern. Weitere Informationen zu diesen Diensten erhalten Sie im weiteren Verlauf dieser Anleitung.

In der folgenden Liste werden die Komponentenrollen und die Anforderungen der Zugriffssteuerung beschrieben:

Platform Intelligence Recommender

Zweck: Generiert Sicherheits- und VM-Größenempfehlungen

Zugriffssteuerung: Das Google Cloud-Dienstkonto muss die erforderlichen IAM-Berechtigungen haben, um Empfehlungen mit der Recommender API abrufen zu können.

Sehen Sie sich die Recommender-Rollen und -Berechtigungen an, um die am besten geeignete Rolle für das Dienstkonto auszuwählen, mit dem Sie den Recommender-Parser ausführen.

• Berechtigungen für IAM-Empfehlungen
• Berechtigungen zur Größenanpassung von Compute Engine-Instanzen

Cloud Scheduler

Zweck: Löst den Recommender-Parser-Dienst aus. Mit Cloud Scheduler können Sie mehrere Jobs einrichten, die so viele Instanzen des Parser-Dienstes aufrufen, wie Sie benötigen. Jeder Aufruf muss die folgenden Eingaben übergeben.

• Liste der Projekte, für die Empfehlungen verarbeitet werden sollen
• Empfehlungstyp
• Name des IaC-Repositorys

Hinweis: Sie können mehrere Planerjobs einrichten, wenn mehr als ein IaC-Repository in Ihrem Unternehmen vorhanden ist. Dies ist ein allgemein gängiges Muster in großen Unternehmen.

Zugriffssteuerung: Erstellen oder bestimmen Sie ein Google Cloud-Dienstkonto, das für Aufrufe von Cloud Scheduler an Ihren Recommender-Dienst verwendet werden soll.

Weisen Sie dem Dienstkonto die Rolle "Cloud Scheduler-Dienst-Agent" zu, damit es Cloud Scheduler-Jobs ausführen kann. Zusätzlich erteilen Sie dem Dienstkonto die Rolle "Cloud Run Invoker", da dieses Konto einen Cloud Run-Dienst aufruft.

Weitere Informationen finden Sie in der Dokumentation zum Konfigurieren des authentifizierten Zugriffs für Planerjobs.

Cloud Run-Dienst

Zweck: Der Recommender-Parser-Dienst ist der Ort, an dem sich die gesamte Verarbeitungslogik befindet. Sie hat mehrere Routen, die jeweils einen bestimmten Zweck erfüllen:

• Parsing-Empfehlungen für jeden Empfehlungstyp.
• Status der verarbeiteten Empfehlungen aktualisieren

Zugriffssteuerung: Verwenden Sie IAM, um den Zugriff auf diesen Dienst zu verwalten

Weisen Sie den Dienst außerdem einem dedizierten Dienstkonto zu. Dadurch wird sichergestellt, dass nur der Dienst andere Dienste wie Firestore aufrufen kann.

Hashicorp Terraform

Zweck: Terraform 0.12 ist das IaC-Tool.

Ein Cloud Build-Builder für Terraform dient zum Aufrufen von Terraform-Befehlen. Dazu wird das Cloud Build-Dienstkonto verwendet.

Cloud Build

Zweck: Google Cloud Build automatisiert die Bereitstellung der Infrastruktur basierend auf den Änderungen, die an den IaC-Manifesten pro Richtlinien Intelligence-Empfehlungen vorgenommen wurden.

Zugriffssteuerung: Das Cloud Build-Dienstkonto muss die erforderlichen Berechtigungen für die Interaktion mit Ressourcen in Ihrem Testprojekt haben.

Weitere Informationen finden Sie in der Dokumentation zum Konfigurieren eines Cloud Build-Dienstkontos.

GitHub

Zweck: Das IaC-Repository verwendet GitHub zur Versionsverwaltung. Das IaC-Repository in GitHub ist in Cloud Build eingebunden. Wenn Commits an den Master-Branch gesendet werden, wird ein Cloud Build-Job ausgelöst, um eine Reihe vorkonfigurierter Aufgaben auszuführen.

Zugriffssteuerung: Sie müssen SSH-Schlüssel generieren, um den Zugriff auf Ihr IaC-Repository zu ermöglichen.

Außerdem müssen Sie ein persönliches Zugriffstoken generieren, um Commits an GitHub zu senden.

Hinweis: Für die Interaktion mit privaten Repositories, die in GitHub gehostet werden, sind SSH-Schlüssel und ein persönliches Zugriffstoken erforderlich. Wenn Ihr Repository öffentlich ist (nicht empfohlen), trifft dieser Punkt nicht auf Ihre Organisation zu.

Firestore

Firestore ist eine vollständig verwaltete, skalierbare NoSQL-Dokumentdatenbank, die in dieser Architektur zum Speichern von Informationen zu den Empfehlungs-IDs verwendet wird, die vom Recommender-Dienst zusammen mit den entsprechenden Details für Git-Commits geparst werden.

Die in Firestore gespeicherten Details spielen eine wichtige Rolle in der Feedbackschleife, die Teil der End-to-End-Pipeline ist. Nachdem Sie eine von der Recommender API generierte Empfehlung erhalten und bevor die Empfehlung verarbeitet wurde, markiert der Dienst den Status der Empfehlung als CLAIMED. Nachdem die Empfehlung erfolgreich angewendet wurde, fragt der Dienst die Datenbank ab, um die Empfehlungs-IDs abzurufen, die vom Cloud Build-Job erfolgreich angewendet und der Empfehlungsstatus in SUCCEEDED geändert wurde. Wenn der Cloud Build-Job fehlschlägt, wird der Empfehlungsstatus in FAILED geändert.

Zugriffssteuerung: Weitere Informationen finden Sie unter Firestore-Rollen. Der Recommender-Parser-Dienst liest Daten aus Firestore und benötigt dazu die Rolle "datastore/datastore.user".

Pub/Sub

Zweck: Wenn sich der Build-Status ändert, veröffentlicht Cloud Build Nachrichten zu einem Pub/Sub-Thema. Dies ist beispielsweise bei der Erstellung Ihres Builds der Fall, wenn der Build in einen funktionsfähigen Zustand umgewandelt wird und wenn der Build abgeschlossen ist.

Das Pub/Sub-Thema, an das Cloud Build Nachrichten veröffentlicht, wird "cloud-builds" genannt. Es wird automatisch für Sie erstellt, wenn Sie die Cloud Build API in Ihrem Projekt aktivieren.

Zugriffssteuerung: Push-Abos können so konfiguriert werden, dass sie einen Authentifizierungsheader enthalten, über den sie die Anfrage autorisieren können. Weitere Informationen finden Sie unter Push-Abos verwenden.

Ziele

• Automatisierungspipeline erstellen, um
  • Empfehlungen für Platform Policy Intelligence proaktiv zu beobachten
  • Empfehlungen zu parsen und Aktualisierungen auf ein vorhandenes IaC-Repository anzuwenden
• Erfahren Sie mehr darüber, wie Sie diese Pipeline mit einer Suite von Google Cloud-Diensten, Hashicorp Terraform und GitHub erstellen.
• Machen Sie sich mit den Annahmen und Best Practices vertraut, die Sie beim Erstellen dieser Pipeline berücksichtigen müssen
• Pipeline testen

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

• Cloud Run
• Cloud Build
• Compute Engine
• Cloud Storage
• Firestore
• Pub/Sub
• Cloud Scheduler
• Recommender

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Hinweise

In dieser Anleitung wird davon ausgegangen, dass Sie ein GitHub haben und mit Git, Node.js, Terraform und Docker vertraut sind.

Versionshinweise und Annahmen

Die IaC-Tools und -Manifeste sind sehr unterschiedlich.

In den folgenden Abschnitten erfahren Sie, wie sich diese Anleitung an Ihre IaC-Pipeline anpassen lässt und welche Änderungen erforderlich sind.

• Diese Pipeline verwendet Terraform ver. 0.12. Erhebliche Änderungen an der Konfiguration der HCL-Konfiguration oder Änderungen an der Struktur der Terraform-Zustandsdatei können zu Problemen führen.
• Diese Pipeline geht davon aus, dass die IaC-Verzeichnisstrukturen nicht verschachtelt sind und dass ein IaC-Repository Ressourcen in einem oder mehreren Google Cloud-Projekten verwaltet.
• Als Umgebungsvariablen übergebene Terraform-Variablen werden nicht unterstützt. Der Prototyp geht von einer deklarativen Konfiguration von Terraform-Variablen in einer tfvars-Datei aus.
• Recommender generiert IAM-Empfehlungen, wenn eine Teilmenge von Berechtigungen für eine Rolle 60 Tage lang nicht verwendet wurde und VM-Größenempfehlungen einem ähnlichen Muster folgen. Für die Zwecke dieser Anleitung wurden Beispiele für Empfehlungsnutzlasten bereitgestellt, die zum Testen der Pipeline verwendet werden können.
• Schleifen innerhalb von Terraform werden in dieser Version nicht unterstützt.
• Terraform-Module werden nicht unterstützt. Bei der Codebasis handelt es sich um eine Open Source-Anwendung. Es wird davon ausgegangen, dass Sie alle erforderlichen Verbesserungen am Vergleichsablauf vornehmen, um an Ihre Verzeichnisstruktur und Nutzung von Modulen anzupassen.

Die aktuelle Version des Open-Source-Parser-Dienstes für Empfehlungen ist auf die folgenden bekannten Einschränkungen von IAM-Empfehlungen ausgerichtet:

• Empfehlungen können nur für IAM-Richtlinienbindungen gegeben werden, für die Folgendes gilt:
  • Sie existieren auf Projektebene.
  • Sie sind mit Nutzerkonten und nutzerverwalteten Dienstkonten verknüpft.
• IAM-Empfehlungen unterstützen nur einfache Rollen und vordefinierte Rollen. Benutzerdefinierte Rollen und bedingte Bindungen können weder evaluiert noch empfohlen werden.
• Empfohlene Rollen enthalten nur eine Teilmenge der Berechtigungen der aktuellen Rolle. Mit einer empfohlenen Rolle werden keine neuen Berechtigungen eingeführt.

Vorbereitung

1. Wählen Sie zwei Google Cloud-Projekte aus oder erstellen Sie eines.

   Zur Projektauswahl

   • Ein Build-Projekt, das die Automatisierungspipeline hostet und ausführt.
   • Ein Test-Projekt, das Google Cloud-Ressourcen hostet, die zum Testen der Automatisierungspipeline verwendet werden

2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

3. Aktivieren Sie im Test-Projekt die Recommender und die Compute Engine API.

   Enable the APIs

4. Aktivieren Sie im Build-Projekt die Cloud Run-, Firestore-, Pub/Sub and Cloud Scheduler-, IAM- und CloudResourceManager-APIs.

   Enable the APIs

Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie im Abschnitt Bereinigen.

Umgebung einrichten

1. Wählen Sie in der Google Cloud Console Ihr build-Projekt aus.

2. Rufen Sie in der Google Cloud Console Cloud Shell auf.

   Zu Cloud Shell

   Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung mit einer Eingabeaufforderung geöffnet. Cloud Shell ist eine Shell-Umgebung, im Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

   Verwenden Sie Cloud Shell für alle Terminalbefehle in dieser Anleitung.

3. Erstellen Sie mit folgendem Befehl eine Umgebungsvariable, die die Projektnummer für Ihr build-Projekt enthält:

   export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID
   

4. Erstellen Sie eine Umgebungsvariable für die Projektnummer Ihres test-Projekts . Kopieren Sie die Testprojekt-ID manuell und ersetzen Sie PROJECT-ID durch sie.

   export TEST_PROJECT_ID=PROJECT-ID

5. Sie weisen Standardeinstellungen für Werte zu, die in der gesamten Anleitung verwendet werden, z. B. Region und Zone. In dieser Anleitung wird us-central1 als Standardregion und us-central1-b als Standardzone verwendet.

6. Legen Sie mit dem folgenden Befehl die Standardregion und -zone für diese Anleitung fest:

   gcloud config set compute/zone us-central1-b --project $BUILD_PROJECT_ID
   gcloud config set compute/zone us-central1-b --project $TEST_PROJECT_ID
   

7. Legen Sie Ihr build-Projekt als Standardprojekt fest:

   gcloud config set project $BUILD_PROJECT_ID
   

8. Erstellen Sie eine Umgebungsvariable namens BUILD_PROJECT_NUMBER für Ihrebuild-Projektnummer

   export BUILD_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
   

9. Klonen Sie das GitHub-Repository für diese Anleitung:

   Hinweis: Führen Sie alle Befehle in dieser Anleitung in Cloud Shell aus, sofern nicht anders angegeben.

Bucket für Terraform-Zustand erstellen

Erstellen Sie einen Cloud Storage-Bucket in Ihrem Build-Projekt, um die Terraform-Zustandsdatei zu speichern.

gcloud storage buckets create gs://recommender-tf-state-$BUILD_PROJECT_ID \
  --project=${BUILD_PROJECT_ID} --location=us-central1

GitHub-Repository erstellen

GitHub-Repository als Beispiel-IaC-Repository erstellen

1. Erstellen Sie ein neues privates GitHub-Repository. Dieses IAC-REPO-NAME-Repository dient in dieser Anleitung als IaC-Repository

2. In den folgenden Setups übertragen Sie die Dateien im Unterverzeichnis sample-iac des geklonten Repositorys an Ihr GitHub-Konto.

   1. Kopieren Sie in Cloud Shell das sample-iac-Verzeichnis in Ihr Basisverzeichnis. Sie verwenden dieses Verzeichnis, um ein neues lokales Repository zu erstellen und es an GitHub zu übertragen.

      cp -r recommender-iac-pipeline-nodejs-tutorial/sample-iac $HOME
      

   2. Gehen Sie zum neuen Verzeichnis

      cd $HOME/sample-iac
      

   3. Initialisieren Sie das Repository auf Ihrem lokalen Computer.

      git init
      

   4. Fügen Sie IAC-REPO-NAME als Remote-Repository hinzu. Ersetzen Sie dabei IAC-REPO-NAME und GITHUB-ACCOUNT durch die entsprechenden Werte:

      git remote add origin https://github.com/GITHUB-ACCOUNT/IAC-REPO-NAME

   5. Ersetzen Sie die Platzhalter in den Dateien in diesem Repository durch Ihre Projekt-ID test und den Namen des Terraform Cloud Storage-Buckets.

      sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./terraform.tfvars
      
      sed -i "s|__STATE_BUCKET_NAME__|recommender-tf-state-$BUILD_PROJECT_ID|g" ./backend.tf
      

   6. Fügen Sie GitHub hinzu, führen Sie einen Commit durch und laden Sie es in GitHub hoch.

      git add .
      git commit -m "First Commit"
      git push origin master
      

   7. Melden Sie sich bei Aufforderung in Ihrem GitHub-Konto an.

SSH-Schlüssel für Ihr Repository generieren

Richten Sie die SSH-Schlüsselauthentifizierung mit Ihrem IaC-Repository in GitHub ein und laden Sie die Schlüssel in Cloud Storage hoch.

1. Generieren Sie SSH-Schlüssel für Ihr GitHub-Repository.

   1. Generieren Sie ein SSH-Schlüsselpaar. Ersetzen Sie [e-mail] durch Ihre GitHub-E-Mail-Adresse. In Cloud Shell:

      ssh-keygen -t rsa -b 4096 -m PEM -C "[e-mail]"

   2. Wenn Sie die Aufforderung "Geben Sie eine Datei an, in der der Schlüssel gespeichert werden soll" angezeigt werden, drücken Sie die Eingabetaste. Dies akzeptiert den Standardspeicherort der Datei.

   3. Drücken Sie die , um eine Passphrase einzugeben.

2. Notieren Sie sich das SSH-KEYS-DIR-Verzeichnis, in dem Sie die heruntergeladenen SSH-Schlüssel speichern. Standardmäßig ist der Standort $HOME/.ssh/.

3. Kopieren Sie den öffentlichen SSH-Schlüssel, den Sie generiert haben, als Deploy Key in Ihr GitHub-Repository.

   1. Kopieren Sie den öffentlichen SSH-Schlüssel, den Sie in Cloud Shell generiert haben. Ersetzen Sie SSH-KEYS-DIR durch Ihren Verzeichnispfad.

      cat SSH-KEYS-DIR/id_rsa.pub

   2. Rufen Sie in Ihrem GitHub-Konto das IAC-REPO-NAME-Repository auf.

   3. Klicken Sie auf Settings > Deploy Keys.

   4. Klicken Sie auf Add Deploy Key und fügen Sie den öffentlichen SSH-Schlüssel ein, den Sie kopiert haben. Wählen Sie einen Namen für den Schlüssel aus.

   5. Klicken Sie auf das Kästchen Schreibzugriff zulassen.

   6. Klicken Sie auf Speichern.

4. Kehren Sie zur Cloud Shell-Sitzung zurück.

5. Erstellen Sie die Datei known_hosts für GitHub. Führen Sie in der Cloud Shell-Sitzung den folgenden Befehl aus:

   ssh-keyscan github.com >> ~/.ssh/known_hosts
   

6. Erstellen Sie einen Cloud Storage-Bucket in Ihrem build-Projekt und laden Sie Ihre SSH-Schlüssel und Ihre known_hosts-Datei hoch. Ersetzen Sie SSH-KEYS-DIR durch den Pfad zu dem Verzeichnis, in dem Sie die SSH-Schlüssel generiert haben.

   gcloud storage buckets create gs://github-keys-$BUILD_PROJECT_ID --project=${BUILD_PROJECT_ID} --location=us-central1
   
   gcloud storage cp SSH-KEYS-DIR/id_rsa* gs://github-keys-$BUILD_PROJECT_ID
   gcloud storage cp SSH-KEYS-DIR/known_hosts gs://github-keys-$BUILD_PROJECT_ID

7. Generieren Sie ein persönliches Zugriffstoken für GitHub. Dieses Token wird verwendet, wenn Git-Vorgänge mit API-Aufrufen ausgeführt werden, die der Recommender-Parser-Dienst zum Generieren von Pull-Anfragen ausführt.

   1. Klicken Sie in Ihrem GitHub-Konto rechts oben auf einer beliebigen Seite auf Ihr Profilbild und dann auf Einstellungen.

   2. Klicken Sie in der linken Seitenleiste auf Entwicklereinstellungen.

   3. Klicken Sie auf der linken Seitenleiste auf Persönliche Zugriffstokens.

   4. Klicken Sie auf "Neues Token erstellen".

   5. Geben Sie Ihrem Token einen aussagekräftigen Namen.

   6. Wählen Sie die Bereiche als Repository aus.

   7. Klicken Sie auf Token generieren.

   8. Kopieren Sie das Token in die Zwischenablage.

   9. Erstellen Sie in Ihrer Cloud Shell-Sitzung eine Umgebungsvariable.

      export GITHUB_PAT=personal-access-token-you-copied

Cloud Build einrichten

1. Stellen Sie eine Verbindung Ihres Git-Repositories IAC-REPO-NAME zur Integration in Cloud Build her.

   1. Rufen Sie im GitHub Marketplace die Seite Cloud Build App auf.
   2. Scrollen Sie zum Ende der Seite und klicken Sie auf Mit Google Cloud Build einrichten.
   3. Wenn Sie dazu aufgefordert werden, melden Sie sich bei GitHub an.
   4. Wählen Sie Nur Repositories auswählen aus. Verwenden Sie die Drop-down-Liste Repositories auswählen, um nur den Zugriff auf Ihre IAC-REPO-NAME in der Cloud Build-App zu aktivieren.
   5. Klicken Sie auf Installieren.

   6. Melden Sie sich in Google Cloud an.

      Auf der Autorisierungsseite werden Sie aufgefordert, die Google Cloud-Build-App für die Verbindung mit Google Cloud zu autorisieren.

   7. Klicken Sie auf Google Cloud Build durch GoogleCloudBuild autorisieren. Sie werden zur Google Cloud Console weitergeleitet.

   8. Wählen Sie Ihr Google Cloud-Projekt aus.

   9. Klicken Sie auf das Kästchen für die Zustimmung und dann auf Weiter.

   10. Wählen Sie auf der Seite Repository auswählen das GitHub-Repository IAC-REPO-NAME aus.

   11. Klicken Sie auf Repository verbinden.

   12. Klicken Sie auf Trigger erstellen. Dadurch wird eine Triggerdefinition für Sie erstellt.

   13. Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

   Weitere Informationen finden Sie unter Builds auf GitHub ausführen.

2. Das kopierte Verzeichnis enthält eine cloudbuild.yaml-Datei. In dieser Konfigurationsdatei werden die Schritte beschrieben, die ein Cloud Build-Job beim Auslösen ausführt.

   steps:
   - name: hashicorp/terraform:0.12.0
     args: ['init']
   - name: hashicorp/terraform:0.12.0
     args: ['apply', '-auto-approve']
   

3. Fügen Sie Ihrem Cloud Build-Dienstkonto Berechtigungen hinzu, damit es Dienstkonten erstellen, Rollen und virtuelle Maschinen (Compute Engine-Instanzen) im Testprojekt erstellen kann

   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:$[e-mail] \
     --role roles/compute.admin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:$[e-mail] \
     --role roles/iam.serviceAccountAdmin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
   --member serviceAccount:$[e-mail] \
   --role roles/iam.securityAdmin \
   --project $TEST_PROJECT_ID
   

4. Rufen Sie die Seite „Build-Trigger” in der Google Cloud Console auf.

5. Wählen Sie build-Projekt aus und klicken Sie auf Öffnen.

6. Aktualisieren Sie die Definition des Triggers:

   1. Klicken Sie auf das Menü und dann auf Bearbeiten.
   2. Wählen Sie unter Konfiguration die Option Cloud Build-Konfigurationsdatei (YAML oder JSON) aus und geben Sie cloudbuild.yaml in das Textfeld ein.
   3. Klicken Sie auf Speichern.

7. Klicken Sie in der Triggerliste neben dem Triggereintrag auf Trigger ausführen, um den Build-Trigger manuell zu testen.

8. Prüfen Sie, ob eine Compute Engine-Instanz mit dem Namen tf-compute-1 und ein Dienstkonto mit dem Namen Terraform Recommender Test im Testprojekt von Cloud Build erstellt wurden, das Sie im vorherigen Schritt ausgeführt haben.

Hinweis: Es kann einen Moment dauern, bis der Cloud Build-Job abgeschlossen ist und Sie die Erstellung von Ressourcen in Ihrem Testprojekt prüfen können.

Recommender-Parser für Cloud Run-Dienst bereitstellen

1. Wechseln Sie in Cloud Shell zum Verzeichnis, das durch Klonen des Repositorys erstellt wurde

   cd $HOME/recommender-iac-pipeline-nodejs-tutorial/parser-service
   

2. Konfigurieren Sie Google Cloud so, dass es eine Standardregion für Cloud Run-Dienste verwendet. In dieser Anleitung verwenden Sie die Region us-central1. Sie können jedoch auch eine andere unterstützte Region auswählen.

   gcloud config set run/region us-central1
   

3. Das Verzeichnis parser-service hat ein Stub-Unterverzeichnis mit einigen JSON-Beispielnutzdaten, damit Sie den Recommender-Parser-Dienst testen können. Führen Sie die folgenden sed-Befehle aus, um die PROJECT_ID-Platzhalter in diesen JSON-Dateien durch Ihre Testprojekt-ID zu ersetzen.

   sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/iam.json
   sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/vm.json
   

4. Führen Sie den folgenden Befehl aus, um eine Umgebungsvariable für das Docker-Image zu erstellen.

   export IMAGE=gcr.io/$BUILD_PROJECT_ID/recommender-parser:1.0
   

5. Erstellen Sie das Image und laden Sie es in Container Registry hoch

   gcloud builds submit --tag $IMAGE .
   

6. Erstellen Sie ein Dienstkonto für den Recommender-Parser-Dienst, um mit anderen Google Cloud-Diensten in der Pipeline zu interagieren. Es empfiehlt sich, detaillierte Berechtigungen für Cloud Run-Dienste zu gewähren. Weitere Informationen finden Sie unter Cloud Run-Dienstidentität.

   gcloud beta iam service-accounts create recommender-parser-sa \
     --description "Service account that the recommender-parser service uses to invoke other Google Cloud services" \
     --display-name "recommender-parser-sa" \
     --project $BUILD_PROJECT_ID
   

7. Der Recommender-Parser-Dienst muss auf die GitHub-SSH-Schlüssel und den Terraform-Zustand zugreifen, den Sie zuvor in Cloud Storage-Buckets hochgeladen haben. Fügen Sie dem Cloud Storage-Bucket das Dienstkonto als Mitglied hinzu.

   gcloud storage buckets add-iam-policy-binding gs://github-keys-$BUILD_PROJECT_ID \
     --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/storage.objectUser
   
   gcloud storage buckets add-iam-policy-binding gs://recommender-tf-state-$BUILD_PROJECT_ID \
     --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/storage.objectUser
   

8. Gewähren Sie dem Dienstkonto des Recommender-Parsers Zugriff auf Firestore, Recommender und die Service Usage API.

   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/datastore.user
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.iamAdmin
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.iamViewer
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.computeAdmin
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/serviceusage.serviceUsageConsumer
   

9. Stellen Sie den Cloud Run-Dienst mit dem Namen recommender-parser mit dem Befehl bereit. Ersetzen Sie GITHUB-ACCOUNT durch den Nutzernamen Ihres GitHub-Kontos, nicht durch E-Mail. Nehmen Sie alle Systemaufforderungen an.

   gcloud run deploy \
    --image=${IMAGE} \
    --no-allow-unauthenticated \
    --region us-central1 \
    --platform managed \
    --service-account recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --set-env-vars="GITHUB_ACCOUNT=github.com:GITHUB-ACCOUNT,GITHUB_PAT=${GITHUB_PAT},SSH_KEYS_BUCKET=github-keys-${BUILD_PROJECT_ID},TERRAFORM_STATE_BUCKET=recommender-tf-state-$BUILD_PROJECT_ID" \
    --project $BUILD_PROJECT_ID \
    recommender-parser

Firestore einrichten

1. Rufen Sie in der Google Cloud Console in Ihrem build-Projekt die Firestore-Seite auf.
2. Wenn Sie zur Auswahl des Modus aufgefordert werden, klicken Sie auf Nativen Modus auswählen.
3. Wählen Sie us-east1 als Standardstandort aus.
4. Klicken Sie auf Datenbank erstellen.

Der recommender-parser-Dienst schreibt Dokumente zu folgenden Zwecken in diese Sammlung:

• Um die von der Recommender API abgerufenen Empfehlungen zu verfolgen
• Rufen Sie die Recommender API auf, sobald die Empfehlungen verarbeitet wurden, um den Status jeder verarbeiteten Empfehlung auf SUCCEEDED oder FAILED zu aktualisieren. Dies ist ein wichtiger Schritt, der die Pipeline idempotent macht, indem sichergestellt wird, dass Empfehlungen nicht unvollständig oder mehrmals verarbeitet werden.

Cloud Scheduler-Job einrichten

1. Erstellen Sie ein Dienstkonto, mit dem Cloud Scheduler-Jobs den Recommender-Parser-Dienst ausführen.

   gcloud beta iam service-accounts create recommender-scheduler-sa \
     --description "Service Account used by Cloud Scheduler to invoke the recommender-parser service" \
     --display-name "recommender-scheduler-sa" \
     --project $BUILD_PROJECT_ID
   

2. Weisen Sie dem Dienstkonto die Rolle "run/invoker" zu, um den Cloud Run-Dienst aufrufen zu können.

   gcloud beta run services add-iam-policy-binding recommender-parser \
   --member=serviceAccount:recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/run.invoker \
   --region=us-central1
   

3. Rufen Sie die URL des Recommender-Dienstes ab:

   gcloud beta run services list --platform managed --project $BUILD_PROJECT_ID
   

   Der Cloud Scheduler-Job ruft die /recommendation/iam-Route des Recommender-Parsers auf, um IAM-Empfehlungen zu parsen, und die /recommender/vm-Route, um die Größenempfehlungen für VM zu parsen.

4. Erstellen Sie eine Variable für den Endpunkt, den Cloud Scheduler-Jobs aufrufen. Ersetzen Sie RECOMMENDER-SERVICE-URL durch die Recommender-URL, die Sie im vorherigen Schritt kopiert haben.

   export RECOMMENDER_ROUTE_TO_INVOKE_IAM=RECOMMENDER-SERVICE-URL/recommendation/iam

   Die URL sollte nach dem Anhängen der Routeninformationen so aussehen:

   RECOMMENDER-SERVICE-URL/recommendation/iam
   

5. Erstellen Sie einen Cloud Scheduler-Job mit dem Namen recommender-iam-scheduler.

   • Ändern Sie die ausgewählte Zeitzone basierend auf Ihrem Standort.
   • Ersetzen Sie IAC-REPO-NAME durch den Namen des von Ihnen erstellten GitHub-Repositorys.

   Der Nachrichtentext erfordert drei Eingaben und muss so aufgebaut werden:

   • repo: Dies ist der Name Ihres GitHub-Repositorys IAC-REPO-NAME, den Sie unter GitHub-Repository erstellen erstellt haben.

   • projects: Eine Liste/ein Array der Google Cloud-Projekt-IDs, denen dieses IaC GitHub-Repository zugeordnet ist. In dieser Anleitung ist es Ihr test-Projekt.

   • stub: Recommender generiert IAM-Empfehlungen, wenn eine Teilmenge der Berechtigungen für eine Rolle 60 Tage lang nicht verwendet wurde und VM-Größenempfehlungen einem ähnlichen Muster folgen. Zum Testen dieser Pipeline on demand kann stub als true übergeben werden, sodass die Pipeline mit den Beispiel-Nutzlasten in dem Repository getestet wird, die Sie geklont haben.

   gcloud beta scheduler jobs create http recommender-iam-scheduler \
     --project $BUILD_PROJECT_ID \
     --time-zone "America/Los_Angeles" \
     --schedule="0 */3 * * *" \
     --uri=$RECOMMENDER_ROUTE_TO_INVOKE_IAM \
     --description="Scheduler job to invoke recommendation pipeline" \
     --oidc-service-account-email="recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com" \
     --headers="Content-Type=application/json" \
     --http-method="POST" \
     --message-body="{ \"repo\": \"IAC-REPO-NAME\", \"projects\": [\"$TEST_PROJECT_ID\"], \"location\": \"global\", \"stub\": true }"

Hinweis: --schedule="0 */3 * * *" führt den Scheduler-Job alle drei Stunden aus. Dies können Sie nach Ihren eigenen Anforderungen ändern. Wenn Sie einen geplanten Job zum Parsen von VM-Größenempfehlungen erstellen müssen, sollten Sie die Dienst-URL your-recommender-parser an /recommendation/vm anhängen und das Attribut location im Parameter --message-body in eine gültige Zone setzen.

Weitere Schritte

Cloud Build veröffentlicht Build-Informationen in einem Pub/Sub-Thema namens "cloud-builds", das automatisch erstellt wurde, als Sie die Cloud Build API in Ihrem Build-Projekt aktiviert haben.

1. Prüfen Sie mit dem folgenden Befehl, ob das Thema „cloud-builds“ in Ihrem build-Projekt vorhanden ist:

   gcloud pubsub topics describe cloud-builds
   

   Wenn das Thema vorhanden ist, wird die folgende Ausgabe angezeigt, wobei BUILD-PROJECT-ID Ihre Build-Projekt-ID ist:

   name: projects/BUILD-PROJECT-ID/topics/cloud-builds
   

   Wenn Sie eine Fehlermeldung erhalten, die besagt, dass die Ressource nicht gefunden wurde, folgen Sie der Anleitung zum Abonnieren von Build-Benachrichtigungen, um das Thema manuell zu erstellen.

2. Erstellen Sie ein Dienstkonto, mit dem Pub/Sub den Dienstendpunkt für den Recommender-Parser aufruft.

   gcloud beta iam service-accounts create recommender-ci-subscription-sa \
     --description "Service Account used by Cloud Pub/Sub to push Cloud Build events to the recommender-parser service" \
     --display-name "recommender-ci-subscription-sa" \
     --project $BUILD_PROJECT_ID
   

3. Das Pub/Sub-Dienstkonto sollte mit den Rollen verknüpft sein, die zum Veröffentlichen von Nachrichten und zum Aufrufen des Recommender-Parser-Dienstes erforderlich sind.

   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/pubsub.publisher \
     --project $BUILD_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/pubsub.subscriber \
     --project $BUILD_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/run.invoker \
     --project $BUILD_PROJECT_ID
   

4. Fügen Sie das von Ihnen erstellte recommender-ci-subscription-sa-Dienstkonto dem Recommender-Parser-Dienst als Mitglied mit der Rolle invoker hinzu.

   gcloud beta run services add-iam-policy-binding recommender-parser \
     --member=serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/run.invoker --region=us-central1
   

5. Rufen Sie in der Google Cloud Console Pub/Sub auf.

6. Klicken Sie auf das Thema "cloud-builds".

7. Klicken Sie auf Abo erstellen.

8. Geben Sie als Abo-ID recommender-service-build-events ein.

9. Wählen Sie als Zustellungstyp Push aus.

10. Für Endpunkt geben Sie die URL Ihres Recommender-Dienstes mit der Endung /ci ein.

11. Klicken Sie das Kästchen Authentifizierung aktivieren an.

    1. Wählen Sie das Dienstkonto recommender-ci-subscription-sa aus, das Sie erstellt haben.
    2. Klicken Sie als Antwort auf die Eingabeaufforderung auf Erteilen.

12. Wählen Sie Bestätigungsfrist als 60 Sekunden aus.

13. Behalten Sie die restlichen Standardeinstellungen bei.

14. Klicken Sie auf Erstellen.

Pipeline testen

Recommender generiert IAM-Empfehlungen, wenn eine Teilmenge von Berechtigungen für eine Rolle 60 Tage lang nicht verwendet wurde. Die Empfehlungen zur VM-Größe folgen einem ähnlichen Muster. Zum on demand-Testen dieser Pipeline verwenden Sie die JSON-Nutzlasten der Beispielempfehlungen, die im Unterverzeichnis stub des Repositorys enthalten sind, das Sie für diese Anleitung geklont haben. So können Sie die Pipeline testen und die API-Aufrufe, die der Recommender-Parser an den Recommender API-Endpunkt sendet, aktualisieren, um den Status der empfohlenen Empfehlungen zu aktualisieren.

Wenn Sie in Ihren Google Cloud-Projekten aktive Empfehlungen haben, können Sie die Pipeline End-to-End-Funktion testen, ohne Stubs zu verwenden. Das unten aufgeführte Ergebnis gilt für die Verwendung der Beispielnutzlasten zum Testen der Pipeline. Die Schritte zum Testen dieser Pipeline ohne Beispiele bleiben jedoch unverändert.

1. Gehen Sie in der Google Cloud Console zu Ihrem Testprojekt und prüfen Sie die erstellte Ressource. Sie sollten Folgendes haben:

   1. Eine Compute Engine-Instanz namens tf-compute-1 mit dem Maschinentyp g1-small.
   2. Ein Dienstkonto mit dem Namen Terraform Recommender Test und der Rolle editor für Ihr Testprojekt.

2. Klicken Sie auf der Seite Cloud Scheduler in der Konsole im Projekt build auf Jetzt ausführen für den Job recommender-iam-scheduler.

3. Klicken Sie auf den Job, um die Logs anzuzeigen. Sie können auch die Recommender-Dienstlogs ansehen, um eine detaillierte Ansicht der vom Dienst ausgeführten Schritte zu erhalten.

4. Rufen Sie nach Abschluss der Ausführung des Dienstes Ihr GitHub-Repository IAC-REPO-NAME auf. Der recommender-parser-Dienst sollte eine Pull-Anfrage für Sie generiert haben. Prüfen Sie die geänderten IaC-Manifeste, die diese Pull-Anfrage enthalten, und klicken Sie auf Pull-Anfrage zusammenführen, wenn Sie mit den Änderungen an Ihren IaC-Manifesten zufrieden sind.

   Warnung: In Produktionsumgebungen empfehlen wir, einen robusten Genehmigungs-Workflow einzurichten, der die manuelle Prüfung von Pull-Anfragen vor dem Zusammenführen von Änderungen beinhaltet. Die Reviewer sollten in der Lage sein, die in den Empfehlungen genannten Auswirkungen sowie die Auswirkungen auf Ihre Infrastruktur und Ihr Unternehmen zu bewerten. Die Anwendung von Empfehlungen ohne ordnungsgemäße Bewertung kann zu unerwarteten Änderungen führen, z. B. zu Problemen mit der Systemleistung, schlechter Zuverlässigkeit oder den Verlust erforderlicher Berechtigungen. In der GitHub-Dokumentation finden Sie eine Anleitung zum Einrichten eines Prüfungsprozesses.

5. Wenn Sie die Pull-Anfrage zusammenführen, wird ein neuer Commit für den Master-Branch erstellt. Dadurch wird ein Cloud Build-Job ausgelöst, der die Änderungen an den Google Cloud-Ressourcen in Ihrem test-Projekt ausführt. Warten Sie kurz, bis der Cloud Build-Job abgeschlossen ist. Sie können den Status in der Google Cloud Console prüfen.

   Hinweis: Beim Einrichten Ihrer DevOps-Pipelines sollten Sie eine funktionierende Rollback-Strategie haben. Beispielsweise können die Infrastrukturänderungen, die von der in dieser Anleitung erstellten Automatisierungspipeline bereitgestellt wurden, durch Zurücksetzen auf ein vorheriges Git-Commit rückgängig gemacht werden. Weitere Informationen zu https://git-scm.com/docs/git-reset und Git zurücksetzen finden Sie in dieser Git-Dokumentation.

6. Gehen Sie nach Abschluss des Jobs zu Ihrem Testprojekt. Mit den angegebenen Beispielnutzlasten werden die folgenden Änderungen an den Ressourcen in Ihrem Testprojekt vorgenommen.

   • Das Terraform-Dienstkonto, das zuvor die Rolle editor hat, wird bei der Bereitstellung in viewer geändert.
   Hinweis: Wenn Sie den Cloud Scheduler-Dienst ausführen, um Empfehlungen für die Parsing-VM-Größe auf dem Endpunkt "/recommendation/vm" aufzurufen, wird die Compute Engine-Instanz tf-compute-1, die ursprünglich den Maschinentyp g1-small hat, in f1-micro geändert.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie beide Projekte, die Sie erstellt haben.

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das zum Ausführen der Anleitung erstellte Projekt löschen.

So löschen Sie das Projekt:

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Nächste Schritte

• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center
• Weitere Informationen zu Google Cloud Policy Intelligence finden Sie in der Dokumentation.