GKE Enterprise-Toolchain mit Active Assist verwenden

---

Das Dokument ist Teil einer Reihe, in der Architekturmuster erläutert werden, mit denen Unternehmen ihren Cloud-Fußabdruck mit Active Assist umfassend optimieren können. In dieser Anleitung wird beschrieben, wie Sie eine Automatisierungs-Pipeline für Active Assist-Empfehlungen erstellen, die mit der GKE Enterprise-Toolchain funktioniert. Dieses Dokument ist für Nutzer gedacht, die Config Sync zum Verwalten ihrer GKE Enterprise-Umgebungen und Config Connector zum Verwalten von Google Cloud-Ressourcen verwenden. Die anderen Teile der Reihe:

• Muster für die Nutzung von Active Assist in großem Umfang
• Serverlose Pipelines mit Active Assist verwenden
• GKE Enterprise-Toolchain mit Active Assist verwenden (dieses Dokument)

Die in dieser Anleitung erstellte Automatisierungspipeline hilft Ihnen bei folgenden Aufgaben:

• Die Verwendung des Active Assist-Portfolios in Ihrer Organisation skalieren
• Active Assist in Ihre CI/CD-Pipeline (Continuous Integration, Continuous Delivery) einbinden
• Prüfen und Umsetzen von Active Assist-Empfehlungen mithilfe von Konstrukten wie GitHub-Problemen und Pull-Anfragen steuern

Außerdem wird in dieser Anleitung kpt verwendet, ein Open-Source-Toolkit, das von Google entwickelt wurde, um Datendateien der Kubernetes-Ressourcenkonfiguration zu verwalten, zu bearbeiten, anzupassen und anzuwenden.

Architektur

Im folgenden Diagramm sehen Sie die Komponenten, die Sie in dieser Anleitung verwenden.

Die Komponenten werden so verwendet:

• Ein GitHub-DRY-Repository (Don't Repeat Yourself), das für Config Connector-Vorlagen verwendet wird, die Sie in Projekten in Ihrer Google Cloud-Organisation bereitstellen.
• Ein oder mehrere GitHub-Repositories, die für ein Projekt oder eine Umgebung spezifisch sind und hydrierte Konfigurationsdateien enthalten. Diese hydrierten Repositories sind für die Umgebungen vorgesehen, die Config Sync verwaltet. Mit Config Connector können Sie Google Cloud-Ressourcen in der Google Cloud-Organisation nutzen und verwalten.
• Einen GKE-Cluster, der Config Sync für die Versionsverwaltung und Drifterkennung verwendet. In diesem Cluster ist auch Config Connector installiert. Mit Config Connector kann der Cluster Google Cloud-Ressourcen in der Google Cloud-Organisation verwalten.
• Ein Cloud Build-Trigger, der einen Build auslöst, wenn eine Vorlage per Push in das GitHub-DRY-Repository übertragen wird.
• Ein geplanter Cloud Build-Trigger, der regelmäßig einen Build auslöst. Der Build-Job verwendet eine kpt-Funktion. Die Funktion ruft die Active Assist Recommender APIs auf, um aktive Empfehlungen abzurufen. Sie prüft und parst Empfehlungen, um zu ermitteln, ob die von Config Connector verwalteten Google Cloud-Ressourcen angepasst oder optimiert werden müssen. Die kpt-Funktion erstellt ein GitHub-Problem im DRY-Repository mit den Details der empfohlenen Änderung, wenn die von Config Connector verwalteten Google Cloud-Ressourcen skaliert oder optimiert werden müssen.

Der Workflow für diese Architektur sieht so aus:

1. Autorisierte Teams mit Zugriff auf das DRY-Repository erstellen und Config Connector-Vorlagen im Repository verwalten.
2. Ein Cloud Build-Job wird ausgelöst, wenn eine Vorlage erstellt oder geändert und in den main-Zweig eingecheckt wird.
3. Der Cloud Build-Job hydriert die Vorlagen durch Aufrufen von kpt-Settern. Der Job überträgt die hydrierten Konfigurationsdateien in das hydrierte GitHub-Repository. Secret Manager wird zum Speichern von GitHub-Bereitstellungsschlüsseln für das private Repository verwendet.
4. Config Sync achtet auf Änderungen am hydrierten Repository und wendet die im Repository gefundenen Aktualisierungen auf den verwalteten Cluster an.
5. Config Connector achtet auf Änderungen und nutzt Google Cloud-Ressourcen, wenn Ressourcen aufgrund der von Config Sync angewendeten KRM-Änderungen (Kubernetes Resource Model) erstellt oder aktualisiert werden müssen.
6. Ein geplanter Cloud Build-Trigger wird regelmäßig ausgeführt, um die Recommender API aufzurufen und aktive Empfehlungen für die von Config Connector verwalteten Projekte abzurufen.
7. Der geplante Cloud Build-Job führt eine benutzerdefinierte kpt-Funktion aus, um die Recommender API aufzurufen und aktive Empfehlungen abzurufen und zu parsen.
8. Die kpt-Funktion erstellt ein GitHub-Problem, das einen Vergleich der aktuellen Ressourcenkonfiguration und der empfohlenen Konfiguration für die Ressource zeigt. Bei diesem Ansatz werden GitHub-Probleme im DRY-Repository erstellt, wodurch Änderungen am Repository besser nachverfolgt werden können.

Ziele

• Die folgenden GitHub-Beispiel-Repositories erstellen:
  • Ein DRY-Repository für Config Connector-KRMs
  • Ein Repository für hydrierte Konfigurationsdateien, die mit kpt-Settern generiert wurden
• Einen GKE-Cluster mit Config Sync und Config Connector erstellen
• Eine kpt-Beispielfunktion erstellen, um Active Assist-Empfehlungen für von Config Connector verwaltete Projekte abzurufen
• Einen Cloud Build-Trigger erstellen, der ausgelöst wird, wenn eine Vorlage per Push an den main-Zweig des DRY-Repositorys übertragen wird.
• Einen geplanten Cloud Build-Job erstellen, der regelmäßig ausgeführt wird, um verfügbare Active Assist-Empfehlungen für die von Config Connector verwalteten Ressourcen abzurufen
• Die End-to-End-Pipeline mit den Stub-Empfehlungen testen, die im GitHub-Repository für diese Anleitung bereitgestellt werden

Kosten

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

• Cloud Build
• Cloud Run
• Firestore
• Pub/Sub
• Container Registry
• Cloud Scheduler
• Google Kubernetes Engine (GKE) Enterprise Edition

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.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

1. Rufen Sie in der Google Cloud Console die Seite für die Projektauswahl auf.

   Zur Projektauswahl

2. Wählen Sie ein Google Cloud-Projekt aus oder erstellen Sie eines.

   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.
3. Notieren Sie sich die Google Cloud-Projekt-ID. Sie verwenden diese ID im nächsten Abschnitt, wenn Sie Ihre Umgebung einrichten. Dieses Projekt wird in der gesamten Anleitung als build-Projekt bezeichnet.

4. Cloud Build, Firestore, App Engine, Pub/Sub, Cloud Run, Cloud Schedule und Cloud Source Repositories APIs aktivieren.

   Aktivieren Sie die APIs

   In dieser Anleitung verwenden Sie die Standardanmeldedaten für Anwendungen. Wenn Sie aufgefordert werden, Anmeldedaten auf der Seite Anmeldedaten zu Ihrem Projekt hinzufügen zu erstellen, klicken Sie auf Abbrechen.

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

Umgebung einrichten

In dieser Anleitung führen Sie alle Befehle in Cloud Shell aus.

1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

   Cloud Shell aktivieren

2. Legen Sie Variablen für die Projekt-ID und die Projektnummer des aktuellen Google Cloud-build-Projekts fest:

   export RECO_MGR_PROJECT=PROJECT_ID
   gcloud config set project $RECO_MGR_PROJECT
   export RECO_MGR_PROJECT_NUMBER=$(gcloud projects describe $RECO_MGR_PROJECT --format='value(projectNumber)')
   

   Ersetzen Sie PROJECT_ID durch die Projekt-ID, die Sie im vorherigen Abschnitt notiert haben.

3. Legen Sie Variablen für die Bereitstellungsregion fest:

   export REGION=us-central1
   export ZONE=us-central1-a
   

4. Klonen Sie das Repository, das den Code der in dieser Anleitung verwendeten Beispielanwendung enthält:

   git clone https://github.com/GoogleCloudPlatform/activeassist-anthos-toolchain.git
   

5. Wechseln Sie zum Projektverzeichnis:

   cd activeassist-anthos-toolchain
   

Pipeline erstellen

In diesem Abschnitt erstellen Sie die Komponenten, mit denen die Pipeline erstellt wird. Active Assist-Empfehlungen werden anhand von Nutzungsmustern und Systemmesswerten generiert. Für jede Empfehlungskategorie kann ein anderes Standardzeitfenster verwendet werden, um Nutzungsdaten und Messwerte auf der Grundlage der generierten Empfehlungen zu analysieren. Zum Testen der End-to-End-Pipeline bietet das Repository, das Sie in einem vorherigen Schritt geklont haben, Beispielempfehlungen (Stubs), die Sie zum Ausführen der End-to-End-Pipeline verwenden.

Wenn Sie die Pipeline in einem Beispielprojekt mit vorhandenen Ressourcen und Empfehlungen ausführen, können Sie auch geeignete Änderungen am Beispielcode vornehmen und dann die Pipeline ausführen.

Private GitHub-Beispielrepositories einrichten

In den folgenden Abschnitten richten Sie die GitHub-Beispielrepositories für diese Anleitung ein.

Privates DRY-GitHub-Repository einrichten

1. Erstellen Sie ein privates GitHub-Repository für das DRY-Repository. Notieren Sie sich den Namen, den Sie dem Repository geben.

2. Erstellen Sie in Cloud Shell eine Umgebungsvariable für Ihren GitHub-Nutzernamen und den Namen des DRY-Repositorys:

   export REPO_OWNER=YOUR_GITHUB_USERNAME
   export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO
   

   Dabei gilt:

   • YOUR_GITHUB_USERNAME: Ihr GitHub-Nutzername
   • YOUR_PRIVATE_DRY_REPO: der Name des DRY-Repositorys

3. Erstellen Sie ein persönliches Zugriffstoken (PAT), um Probleme in diesem Repository zu erzeugen. Die Pipeline erzeugt GitHub-Probleme, wenn es Active Assist-Empfehlungen gibt, die überprüft werden müssen. Weitere Informationen zum Erstellen von PATs in GitHub finden Sie in der GitHub-Dokumentation.

   Wenn Sie für dieses Token einen Bereich festlegen, wählen Sie Vollständige Kontrolle über private Repositories aus.

4. Erstellen Sie in Cloud Shell eine Umgebungsvariable für das generierte PAT:

   export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
   

   Ersetzen Sie YOUR_PERSONAL_ACCESS_TOKEN durch Ihr eigenes Token.

Privates hydriertes GitHub-Repository einrichten

1. Erstellen Sie ein privates GitHub-Repository für das hydrierte Repository. Notieren Sie sich den Namen, den Sie dem Repository geben.

2. Legen Sie in Cloud Shell eine Umgebungsvariable für das hydrierte Repository fest:

   export HYDRATED_REPO_NAME=YOUR_PRIVATE_HYDRATED_REPO
   export HYDRATED_REPO='[e-mail]:$REPO_OWNER/$HYDRATED_REPO_NAME.git'
   

   Ersetzen Sie YOUR_PRIVATE_HYDRATED_REPO durch den Namen des hydrierten Repositorys.

3. Erstellen Sie ein Bereitstellungsschlüsselpaar:

   ssh-keygen -t rsa -b 4096 \
   -C 'active-assist-robot' \
   -N '' \
   -f $(pwd)/active-assist-robot
   

   Mit einem Bereitstellungsschlüssel können Sie das private GitHub-Repository bereitstellen, wenn Sie einen Cloud Build-Job ausführen, um Konfigurationsdateien zu hydrieren.

4. Geben Sie den generierten Schlüssel aus:

   cat $(pwd)/active-assist-robot.pub
   

5. Fügen Sie den Bereitstellungsschlüssel dem privaten GitHub-Repository hinzu. Wählen Sie beim Hinzufügen des Bereitstellungsschlüssels Schreibzugriff zulassen aus. Informationen zum Hinzufügen von Bereitstellungsschlüsseln zu GitHub-Repositories finden Sie in der GitHub-Dokumentation unter Bereitstellungsschlüssel verwalten.

GitHub-Schlüssel in Secret Manager hochladen

1. Erstellen Sie in Cloud Shell ein Secret zum Speichern des privaten Schlüssels aus dem Bereitstellungsschlüsselpaar:

   gcloud secrets create github-ssh-key \
     --data-file=$(pwd)/active-assist-robot
   

2. Erstellen Sie ein Secret zum Speichern des PAT:

   echo $GITHUB_TOKEN | gcloud secrets create github-pat --data-file=-
   

GKE-Cluster erstellen

In diesem Abschnitt erstellen Sie einen GKE-Cluster mit dem Add-on „Config Connector“, erstellen eine Identität und konfigurieren Config Connector. Außerdem konfigurieren Sie Config Sync. Sie können mit Config Sync eine gemeinsame Konfiguration für Ihre gesamte Infrastruktur erstellen, einschließlich benutzerdefinierter Richtlinien, und diese sowohl lokal als auch in der Cloud anwenden. Config Sync ermittelt Änderungen und überträgt sie auf alle Kubernetes-Cluster, damit diese immer den gewünschten Status haben.

1. Erstellen Sie in Cloud Shell einen neuen GKE-Cluster mit aktiviertem Config Connector-Add-on:

   gcloud container clusters create sample-ops \
     --machine-type n1-standard-4 \
     --zone $ZONE \
     --release-channel regular \
     --addons ConfigConnector \
     --workload-pool=$RECO_MGR_PROJECT.svc.id.goog \
     --enable-stackdriver-kubernetes \
     --enable-ip-alias
   

2. Führen Sie die folgenden Abschnitte aus der Anleitung Mit dem GKE-Add-on installieren aus, um eine Identität zu erstellen und Config Connector zu konfigurieren.

   1. Identität erstellen
   2. Config Connector konfigurieren

3. Installieren Sie Config Sync im von Ihnen erstellten GKE-Cluster. Bei der Konfiguration von Config Sync müssen Sie Folgendes tun:

   1. Verwenden Sie ein Token, um Config Sync Lesezugriff auf Git zu gewähren. Verwenden Sie das GitHub-Token, das Sie beim Einrichten eines privaten DRY-GitHub-Repositorys erstellt haben. Das Token ist über die Umgebungsvariable $GITHUB_TOKEN verfügbar.
   2. Konfigurieren Sie Config Sync mit gcloud. Legen Sie die folgenden Einstellungen fest:
      1. sourceFormat: hierarchy
      2. syncRepo: https://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
      3. syncBranch: main
      4. secretType: token
      5. policyDir: Diese Option nicht ausfüllen

Cloud Build-Trigger zur Push-Übertragung in das hydrierte Repository erstellen

In den folgenden Abschnitten erstellen Sie einen Cloud Build-Trigger, der ausgelöst wird, wenn Vorlagen per Push an den Hauptzweig des Repositorys YOUR_PRIVATE_DRY_REPO übertragen werden. Dieser Trigger führt die Schritte aus, mit denen die config-as-data-KRM-Vorlagen im Repository YOUR_PRIVATE_DRY_REPO hydriert und die hydrierten Konfigurationsdateien per Push in das Repository YOUR_PRIVATE_HYDRATED_REPO übertragen werden.

Cloud Build mit GitHub-Repositories verbinden

In diesem Abschnitt verbinden Sie die GitHub-Repositories YOUR_PRIVATE_DRY_REPO und YOUR_PRIVATE_HYDRATED_REPO mit Cloud Build.

1. Rufen Sie die GitHub Marketplace-Seite für die Cloud Build-Anwendung auf.

   Zur Seite der Cloud Build-Anwendung

2. Klicken Sie auf Setup with Google Cloud Build (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 das Drop-down-Menü Repositories auswählen, um den Zugriff auf Ihre Repositories YOUR_PRIVATE_DRY_REPO und YOUR_PRIVATE_HYDRATED_REPO über die Cloud Build-Anwendung zu ermöglichen.

5. Klicken Sie auf Installieren.

6. Melden Sie sich in Google Cloud an. Auf der Seite Autorisierung werden Sie aufgefordert, die Anwendung Google Cloud Build 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. Wählen Sie das Kästchen für die Zustimmung aus und klicken Sie auf Weiter.

10. Klicken Sie auf Installieren.

11. Melden Sie sich in Google Cloud an. Auf der Seite Autorisierung werden Sie aufgefordert, die Anwendung Google Cloud Build für die Verbindung mit Google Cloud zu autorisieren.

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

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

14. Wählen Sie das Kästchen für die Zustimmung aus und klicken Sie auf Weiter.

15. Wählen Sie auf der Seite Repository auswählen die folgenden GitHub-Repositories aus:

    • YOUR_PRIVATE_DRY_REPO
    • YOUR_PRIVATE_HYDRATED_REPO

16. Klicken Sie auf Verbinden und dann auf Fertig.

Cloud Build-Trigger für das DRY-Repository erstellen

1. Führen Sie in Cloud Shell den folgenden Befehl aus:

   envsubst < cloudbuild.template.yaml > cloudbuild.yaml
   

   Der Befehl generiert eine cloudbuild.yaml-Datei.

2. Erstellen Sie den Trigger:

   gcloud beta builds triggers create github \
     --name ActiveAssistDemo \
     --repo-name=$DRY_REPO_NAME \
     --repo-owner=$REPO_OWNER \
     --branch-pattern="main" \
     --build-config=cloudbuild.yaml
   

3. Gewähren Sie dem Cloud Build-Dienstkonto die Berechtigung für den Zugriff auf Secret Manager:

   gcloud secrets add-iam-policy-binding github-ssh-key  \
     --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
     --role="roles/secretmanager.secretAccessor"
   
   gcloud secrets add-iam-policy-binding github-pat  \
     --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
     --role="roles/secretmanager.secretAccessor"
   

Geplanten Cloud Build-Trigger für Active Assist-Empfehlungen erstellen

Hinweis: In dieser Anleitung verwenden Sie Stubs, um die Pipeline zu testen. Wenn Sie die Pipeline für Ihre Google Cloud-Projekte verwenden, muss das Cloud Build-Dienstkonto die Berechtigungen erhalten, die zum Abrufen von Active Assist-Empfehlungen erforderlich sind.

In den folgenden Abschnitten erstellen Sie einen geplanten Cloud Build-Trigger, der regelmäßig ausgeführt wird. Dieser Trigger ruft Active Assist-Empfehlungen mit einer kpt-Funktion ab und bestimmt, ob es aktive Empfehlungen für die Ressourcen in Ihrem Repository YOUR_PRIVATE_HYDRATED_REPO gibt. Die kpt-Funktion erzeugt auch ein GitHub-Problem in Ihrem YOUR_PRIVATE_HYDRATED_REPO-Repository, wenn es aktive Empfehlungen für die Ressourcenkonfiguration gibt, die überprüft und bearbeitet werden muss.

Cloud Build-Image generieren

In diesem Abschnitt generieren Sie ein Cloud Build-Image mit kpt, gh und Knotenkomponenten.

1. Erstellen Sie in Cloud Shell ein Docker-Image und übertragen Sie es per Push an Container Registry:

   gcloud auth configure-docker
   
   docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
   
   docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
   

Cloud Build-Trigger für das hydrierte Repository erstellen

1. Erstellen Sie in Cloud Shell die Konfigurationsdatei, die zum Einrichten des geplanten Cloud Build-Triggers erforderlich ist:

    envsubst < cloudbuild-scheduled-recommendations.template.yaml > cloudbuild-scheduled-recommendations.yaml
   

2. Erstellen Sie den Cloud Build-Trigger:

   gcloud beta builds triggers create github \
     --name ActiveAssistScheduledRecommendations \
     --repo-name=YOUR_PRIVATE_HYDRATED_REPO \
     --repo-owner=$REPO_OWNER \
     --branch-pattern="main" \
     --build-config=cloudbuild-scheduled-recommendations.yaml
   

3. Rufen Sie die ID dieses Triggers ab:

   export TRIGGER_ID=`gcloud beta builds triggers describe \
     ActiveAssistScheduledRecommendations \
     --format="value(id)"`
   

Cloud Scheduler-Job erstellen, um den Trigger aufzurufen

1. Erstellen Sie in Cloud Shell ein Dienstkonto:

   gcloud iam service-accounts create build-invoker \
      --description "Service Account used by Cloud Scheduler to invoke the sample scheduled Cloud Build job" \
      --display-name "recommender-scheduler-sa" \
      --project $RECO_MGR_PROJECT
   

   Cloud Scheduler-Jobs verwenden dieses Dienstkonto, um den recommender-parser-Dienst auszuführen.

2. Erteilen Sie dem Dienstkonto die Berechtigung zum Aufrufen eines Cloud Build-Jobs:

   gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
     --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
     --role roles/cloudbuild.builds.editor \
     --project $RECO_MGR_PROJECT
   
    gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
      --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
      --role roles/serviceusage.serviceUsageConsumer \
      --project $RECO_MGR_PROJECT
   

3. Erstellen Sie einen Cloud Scheduler-Job, um den Trigger aufzurufen, den Sie im vorherigen Schritt erstellt haben:

   gcloud scheduler jobs create http scheduled-build \
      --project $RECO_MGR_PROJECT \
      --time-zone "America/Los_Angeles" \
      --schedule="0 */3 * * *" \
      --uri="https://cloudbuild.googleapis.com/v1/projects/${RECO_MGR_PROJECT}/triggers/${TRIGGER_ID}:run" \
      --description="Scheduler job to invoke Cloud Build" \
      --oauth-service-account-email="build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com" \
      --headers="Content-Type=application/json" \
      --http-method="POST" \
   

   Wählen Sie Y aus, wenn die folgende Meldung angezeigt wird:

   There is no App Engine app in the project.

   Wenn Sie aufgefordert werden, die Region auszuwählen, in der sich die App Engine-Anwendung befinden soll, wählen Sie die Region us-central aus.

Commit durchführen und Cloud Build-Konfigurationsdateien per Push an GitHub übertragen

Übertragen Sie die beiden von Ihnen erstellten Cloud Build-Konfigurationsdateien per Push in das Repository YOUR_PRIVATE_DRY_REPO:

git remote add dry https://github.com/$REPO_OWNER/$DRY_REPO_NAME.git

git add cloudbuild.yaml
git add cloudbuild-scheduled-recommendations.yaml
git commit -m "Added cloudbuild configuration YAMLs"
git push dry main

Sie werden möglicherweise aufgefordert, Ihre GitHub-Anmeldedaten einzugeben, wenn Sie Daten per Push in Ihr privates Repository übertragen.

Ergebnis des Cloud Build-Jobs prüfen

Wenn Sie einen Commit durchführen und die Änderungen per Push in das Repository YOUR_PRIVATE_DRY_REPO übertragen, wird der Cloud Build-Job ausgelöst. Wenn der Cloud Build-Job erfolgreich ausgeführt wird, werden mehrere Ressourcen erstellt. In diesem Abschnitt prüfen Sie, ob die Ressourcen nach Abschluss des Cloud Build-Jobs erstellt werden.

1. Prüfen Sie in Cloud Shell in Ihrem sample-ops-Cluster, ob Sie einen Namespace namens activeassist-kcc haben:

   kubectl get ns | grep activeassist-kcc
   

2. Config Connector stellt eine laufende Compute Engine-Beispielinstanz in Ihrem PROJECT_ID-Projekt bereit.

   Prüfen Sie, ob sich die Compute Engine-Instanz im Projekt befindet:

    gcloud compute instances list | grep \
    computeinstance-sample-cloudmachine
   

   Der Typ MACHINE_TYPE für diese Maschine ist n1-standard-1.

End-to-End-Tests ausführen

Wenn Sie die End-to-End-Pipeline testen möchten, bietet das Repository, das Sie für diese Anleitung geklont haben, Beispielempfehlungen (Stubs). Mit diesen Stubs können Sie die End-to-End-Pipeline ausführen. Der Stub imitiert eine Active Assist-Empfehlungsnutzlast und empfiehlt eine Änderung des Maschinentyps für die Compute Engine-Instanz, der vom Instanztyp n1-standard-1 im Instanztyp g1-small bereitgestellt wurde.

In diesem Abschnitt rufen Sie den geplanten Cloud Build-Trigger manuell auf, um den Job auszuführen, der eine kpt-Funktion verwendet, um Active Assist-Empfehlungen abzurufen. Sie prüfen auch, ob in Ihrem YOUR_PRIVATE_DRY_REPO-Repository ein GitHub-Problem erzeugt wurde.

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

   Seite "Build-Trigger" öffnen

2. Wählen Sie den ActiveAssistScheduledRecommendations-Trigger aus.

3. Klicken Sie in der Triggerliste neben dem Triggereintrag auf Ausführen, um den Trigger manuell zu testen.

   Der Trigger erstellt ein GitHub-Problem im Repository YOUR_PRIVATE_DRY_REPO. Die entsprechende Ausgabe sieht etwa so aus:

   gcloud auth configure-docker
   
   docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
   
   docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
   

   Im Beispielproblem zeigt die Ausgabe der kpt-Funktion, dass der aktuelle MACHINE_TYPE-Typ für die Compute Engine-Instanz n1-standard-1 ist. Gemäß der Active Assist-Empfehlung sollte der Typ in g1-small geändert werden.

   Versionsprüfer in Ihrem Unternehmen können automatisierte GitHub-Probleme prüfen und bei Bedarf Maßnahmen für Ihr Unternehmen ergreifen.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

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.
1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

   Zur Seite „Ressourcen verwalten“

2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Nächste Schritte

• Weitere Informationen zu serverlosen Google Cloud-Technologien.
• Policy Intelligence-Empfehlungen in eine IaC-Pipeline (Infrastructure as Code) integrieren.