Instanz mit einem benutzerdefinierten Container erstellen

Auf dieser Seite wird beschrieben, wie Sie eine Gemini Enterprise Agent Platform Workbench-Instanz basierend auf einem benutzerdefinierten Container erstellen.

Übersicht

Agent Platform Workbench-Instanzen unterstützen die Verwendung eines benutzerdefinierten Containers, der von einem der von Google bereitgestellten Basiscontainer abgeleitet ist. Sie können diese Basiscontainer ändern, um ein benutzerdefiniertes Container-Image zu erstellen, und diese benutzerdefinierten Container verwenden, um eine Agent Platform Workbench-Instanz zu erstellen.

Die Basiscontainer sind mit einem Container-Optimized OS auf der virtuellen Hostmaschine (VM) konfiguriert. Das Host-Image wird aus der Image-Familie cos-stable erstellt.

Beschränkungen

Beachten Sie beim Planen Ihres Projekts die folgenden Einschränkungen:

• Der benutzerdefinierte Container muss von einem von Google bereitgestellten Basiscontainer abgeleitet sein. Die Verwendung eines Containers, der nicht von einem Basiscontainer abgeleitet ist, erhöht das Risiko von Kompatibilitätsproblemen und schränkt unsere Möglichkeiten ein, Sie bei der Verwendung von Agent Platform Workbench-Instanzen zu unterstützen.

• Die Verwendung mehrerer Container mit einer Agent Platform Workbench-Instanz wird nicht unterstützt.

• Die VM, die den benutzerdefinierten Container hostet, wird auf einem Container-Optimized OS ausgeführt. Dadurch wird die Interaktion mit dem Hostcomputer eingeschränkt. Container-Optimized OS enthält beispielsweise keinen Paketmanager. Das bedeutet, dass Pakete, die auf dem Host ausgeführt werden, in einem Container mit Bereitstellungen ausgeführt werden müssen.

• Agent Platform-Workbench-Instanzen verwenden nerdctl (eine containerd-Befehlszeile) zum Ausführen des benutzerdefinierten Containers. Dies ist für die Kompatibilität mit dem Image-Streamingdienst erforderlich. Alle Containerparameter, die mithilfe eines Metadatenwerts hinzugefügt werden, müssen den von nerdctl unterstützten Parametern entsprechen.

• Agent Platform Workbench-Instanzen sind so konfiguriert, dass sie entweder aus Artifact Registry oder einem öffentlichen Container-Repository abgerufen werden. Wenn Sie eine Instanz so konfigurieren möchten, dass sie aus einem privaten Repository abgerufen wird, müssen Sie die von containerd verwendeten Anmeldedaten manuell konfigurieren.

Basiscontainer

Die Agent Platform Workbench bietet von Google erstellte Basis-Container-Images in zwei Varianten: Standard und Slim. Jede Variante enthält Python 3.10 (Standard) oder Python 3.12. Verwenden Sie den URI, der der gewünschten Python-Version entspricht, wenn Sie die FROM-Anweisung des abgeleiteten Containers schreiben.

Standard-Basiscontainer

Der Standard-Basiscontainer unterstützt alle Funktionen der Agent Platform Workbench und enthält Folgendes:

• Vorinstallierte Data-Science-Pakete.
• CUDA-Bibliotheken ähnlich wie Deep Learning Container.
• Google Cloud JupyterLab-Integrationen wie die Integrationen von Managed Service for Apache Spark und BigQuery.
• Gängige Systempakete wie curl oder git.
• Metadatenbasierte JupyterLab-Konfiguration.
• Micromamba-basierte Kernelverwaltung.

Spezifikationen

Der Standard-Basiscontainer hat die folgenden Spezifikationen:

• Basis-Image: nvidia/cuda:12.6.1-cudnn-devel-ubuntu24.04
• Image-Größe: ca. 22 GB
• URI (Python 3.10, Standard): us-docker.pkg.dev/deeplearning-platform-release/gcr.io/workbench-container:latest
• URI (Python 3.12): us-docker.pkg.dev/workbench-images/gcr.io/workbench-container-2606:latest

Slim-Basiscontainer

Der schlanke Basiscontainer bietet einen minimalen Satz von Konfigurationen, die eine Proxyverbindung zur Instanz ermöglichen. Standardfunktionen und -pakete der Agent Platform Workbench sind nicht enthalten, mit Ausnahme der folgenden:

• JupyterLab
• Metadatenbasierte JupyterLab-Konfiguration
• Micromamba-basierte Kernel-Verwaltung

Zusätzliche Pakete oder JupyterLab-Erweiterungen müssen unabhängig installiert und verwaltet werden.

Spezifikationen

Der Slim-Basiscontainer hat die folgenden Spezifikationen:

• Basis-Image: marketplace.gcr.io/google/ubuntu24.04
• Image-Größe: ca. 2 GB
• URI (Python 3.10, Standard): us-docker.pkg.dev/deeplearning-platform-release/gcr.io/workbench-container-slim:latest
• URI (Python 3.12): us-docker.pkg.dev/workbench-images/gcr.io/workbench-container-slim-2606:latest

Hinweis

Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Notebooks API, if it is not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the API

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Notebooks API, if it is not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the API

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen einer Agent Platform Workbench-Instanz mit einem benutzerdefinierten Container benötigen:

• Notebooks-Ausführer (roles/notebooks.runner) für das Nutzerkonto
• Zum Abrufen von Images aus dem Artifact Registry-Repository: Artifact Registry-Leser (roles/artifactregistry.reader) für das Dienstkonto

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Benutzerdefinierten Container erstellen

So erstellen Sie einen benutzerdefinierten Container für die Verwendung mit Agent Platform Workbench-Instanzen:

1. Erstellen Sie einen Container, der von einem von Google bereitgestellten Basiscontainer-Image abgeleitet ist.

2. Erstellen Sie den Container und übertragen Sie ihn per Push an Artifact Registry. Sie verwenden die URI des Containers, wenn Sie Ihre Agent Platform Workbench-Instanz erstellen. Dieser URI könnte so aussehen: gcr.io/PROJECT_ID/IMAGE_NAME.

Die Instanz erstellen

Sie können eine Agent Platform Workbench-Instanz basierend auf einem benutzerdefinierten Container mit der Google Cloud Console oder der Google Cloud CLI erstellen.

Console

So erstellen Sie eine Agent Platform Workbench-Instanz basierend auf einem benutzerdefinierten Container:

1. Rufen Sie in der Google Cloud Console die Seite Instanzen auf.

   Zur Seite „VM-Instanzen“

2. Klicken Sie auf  NEU ERSTELLEN.

3. Klicken Sie im Dialogfeld Neue Instanz auf Erweiterte Optionen.

4. Wählen Sie im Dialogfeld Instanz erstellen im Abschnitt Umgebung die Option Benutzerdefinierten Container verwenden aus.

5. Klicken Sie unter Docker-Container-Image auf Auswählen.

6. Rufen Sie im Dialogfeld Container-Image auswählen das Container-Image auf, das Sie verwenden möchten, und klicken Sie dann auf Auswählen.

7. Optional. Geben Sie unter Post-Startscript einen Pfad zu einem Post-Startscript ein, das Sie verwenden möchten.

8. Optional. Fügen Sie Metadaten für Ihre Instanz hinzu. Weitere Informationen finden Sie unter Benutzerdefinierte Container-Metadaten.

9. Optional. Passen Sie im Abschnitt Netzwerk die Netzwerkeinstellungen an. Weitere Informationen finden Sie unter Netzwerkkonfigurationsoptionen.

10. Schließen Sie den Rest des Dialogfelds zur Instanzerstellung ab und klicken Sie dann auf Erstellen.

    Agent Platform Workbench erstellt eine Instanz und startet sie automatisch. Sobald die Instanz einsatzbereit ist, aktiviert die Agent Platform Workbench den Link JupyterLab öffnen.

gcloud

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

• INSTANCE_NAME: der Name Ihrer Agent Platform Workbench-Instanz; muss mit einem Buchstaben beginnen, gefolgt von bis zu 62 Kleinbuchstaben, Ziffern oder Bindestrichen (-) und darf nicht mit einem Bindestrich enden
• PROJECT_ID: Ihre Projekt-ID.
• LOCATION: die Zone, in der sich Ihre Instanz befinden soll
• CUSTOM_CONTAINER_PATH: der Pfad zum Container-Image-Repository, z. B. gcr.io/PROJECT_ID/IMAGE_NAME
• METADATA: Benutzerdefinierte Metadaten, die auf diese Instanz angewendet werden sollen. Wenn Sie beispielsweise ein Post-Startscript angeben möchten, können Sie das Metadaten-Tag post-startup-script im folgenden Format verwenden: "--metadata=post-startup-script=gs://BUCKET_NAME/hello.sh"

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

gcloud workbench instances create INSTANCE_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --container-repository=CUSTOM_CONTAINER_URL \
    --container-tag=latest \
    --metadata=METADATA

Windows (PowerShell)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

gcloud workbench instances create INSTANCE_NAME `
    --project=PROJECT_ID `
    --location=LOCATION `
    --container-repository=CUSTOM_CONTAINER_URL `
    --container-tag=latest `
    --metadata=METADATA

Windows (cmd.exe)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

gcloud workbench instances create INSTANCE_NAME ^
    --project=PROJECT_ID ^
    --location=LOCATION ^
    --container-repository=CUSTOM_CONTAINER_URL ^
    --container-tag=latest ^
    --metadata=METADATA

Weitere Informationen zum Befehl zum Erstellen einer Instanz über die Befehlszeile ausführen, siehe gcloud CLI Dokumentation.

Agent Platform Workbench erstellt eine Instanz und startet sie automatisch. Sobald die Instanz einsatzbereit ist, aktiviert die Agent Platform Workbench den Link JupyterLab öffnen in der Google Cloud Console.

Optionen für die Netzwerkkonfiguration

Zusätzlich zu den allgemeinen Netzwerkoptionen muss eine Agent Platform Workbench-Instanz mit einem benutzerdefinierten Container Zugriff auf den Artifact Registry-Dienst haben.

Wenn Sie den Zugriff über öffentliche IP-Adressen für Ihre VPC deaktiviert haben, muss der privater Google-Zugriff aktiviert sein.

Image-Streaming aktivieren

Der benutzerdefinierte Containerhost ist für die Interaktion mit Image-Streaming in Google Kubernetes Engine (GKE) bereitgestellt. Dadurch werden Container schneller abgerufen und die Initialisierungszeit für große Container wird reduziert, sobald sie im GKE-Remote-Dateisystem im Cache gespeichert sind.

Die Anforderungen zum Aktivieren von Image-Streaming finden Sie unter Anforderungen. Häufig kann Image-Streaming mit Agent Platform Workbench-Instanzen verwendet werden, indem die Container File System API aktiviert wird.

Container-Dateisystem-API aktivieren

So führt die Host-VM den benutzerdefinierten Container aus

Anstatt Docker zum Ausführen des benutzerdefinierten Containers zu verwenden, verwendet die Host-VM nerdctl im Kubernetes-Namespace, um den Container zu laden und auszuführen. Dadurch kann Agent Platform Workbench Image-Streaming für benutzerdefinierte Container verwenden.

# Runs the custom container.
sudo /var/lib/google/nerdctl/nerdctl --snapshotter=gcfs -n k8s.io run --name payload-container

Beispielinstallation: benutzerdefinierter Container mit einem benutzerdefinierten Standardkernel

Im folgenden Beispiel wird gezeigt, wie Sie einen neuen Kernel mit einem vorinstallierten pip-Paket erstellen.

1. Erstellen Sie einen neuen benutzerdefinierten Container:

   FROM us-docker.pkg.dev/deeplearning-platform-release/gcr.io/workbench-container:latest
   
   ENV MAMBA_ROOT_PREFIX=/opt/micromamba
   
   RUN micromamba create -n ENVIRONMENT_NAME -c conda-forge python=PYTHON_VERSION -y
   
   SHELL ["micromamba", "run", "-n", "ENVIRONMENT_NAME", "/bin/bash", "-c"]
   
   RUN micromamba install -c conda-forge pip -y
   RUN pip install PACKAGE
   RUN pip install ipykernel
   RUN python -m ipykernel install --prefix /opt/micromamba/envs/ENVIRONMENT_NAME --name ENVIRONMENT_NAME --display-name KERNEL_NAME
   # Creation of a micromamba kernel automatically creates a python3 kernel
   # that must be removed if it's in conflict with the new kernel.
   RUN rm -rf "/opt/micromamba/envs/ENVIRONMENT_NAME/share/jupyter/kernels/python3"

2. Fügen Sie den neuen Container zu Artifact Registry hinzu:

   gcloud auth configure-docker REGION-docker.pkg.dev
   docker build -t REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME .
   docker push REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME:latest

3. Instanz erstellen:

   gcloud workbench instances create INSTANCE_NAME  \
       --project=PROJECT_ID \
       --location=ZONE \
       --container-repository=REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME \
       --container-tag=latest

Persistente Kernel für benutzerdefinierte Container

Benutzerdefinierte Agent Platform Workbench-Container stellen nur ein Datenlaufwerk im Verzeichnis /home/USER in jedem Container bereit, wobei jupyter der Standardnutzer ist. Das bedeutet, dass alle Änderungen außerhalb von /home/USER nur vorübergehend sind und nach einem Neustart nicht mehr vorhanden sind. Wenn installierte Pakete für einen bestimmten Kernel beibehalten werden sollen, können Sie einen Kernel im Verzeichnis /home/USER erstellen.

Hinweis: Basiscontainer werden mit einem Bereitstellungspunkt unter /home/USER konfiguriert. Wenn Sie beim Erstellen eines benutzerdefinierten Images einen persistenten Kernel erstellen möchten, müssen Sie Docker BuildKit aktivieren. Siehe Hinweise zum Angeben von Volumes. Weitere Informationen zu BuildKit finden Sie in der BuildKit-Dokumentation.

So erstellen Sie einen Kernel im Verzeichnis /home/USER:

1. Erstellen Sie eine Micromamba-Umgebung:

   micromamba create -p /home/USER/ENVIRONMENT_NAME -c conda-forge python=3.11 -y
   micromamba activate /home/USER/ENVIRONMENT_NAME
   pip install ipykernel
   pip install -r ~/requirement.txt
   python -m ipykernel install --prefix "/home/USER/ENVIRONMENT_NAME" --display-name "Example Kernel"

   Ersetzen Sie Folgendes:

   • USER: der Name des Nutzerverzeichnisses, standardmäßig jupyter
   • ENVIRONMENT_NAME: der Name der Umgebung
   • PYTHON_VERSION: die Python-Version, z. B. 3.11

2. Warten Sie 30 Sekunden bis 1 Minute, bis die Kernel aktualisiert wurden.

Start des Basiscontainers aktualisieren

Der Basiscontainer für eine Agent Platform Workbench-Instanz (us-docker.pkg.dev/deeplearning-platform-release/gcr.io/workbench-container:latest) startet JupyterLab durch Ausführen von /run_jupyter.sh.

Wenn Sie den Start des Containers in einem abgeleiteten Container ändern, müssen Sie /run_jupyter.sh anhängen, um die Standardkonfiguration von JupyterLab auszuführen.

Im Folgenden finden Sie ein Beispiel dafür, wie das Dockerfile geändert werden könnte:

# DockerFile
FROM us-docker.pkg.dev/deeplearning-platform-release/gcr.io/workbench-container:latest

CP startup_file.sh /
# Ensure that you have the correct permissions and startup is executable.
RUN chmod 755 /startup_file.sh && \
    chown jupyter:jupyter /startup_file.sh

# Override the existing CMD directive from the base container.
CMD ["/startup_file.sh"]

# /startup_file.sh

echo "Running startup scripts"
...

/run_jupyter.sh

JupyterLab-Konfiguration im Basiscontainer aktualisieren

Wenn Sie die JupyterLab-Konfiguration im Basiscontainer ändern müssen, gehen Sie so vor:

• Achten Sie darauf, dass JupyterLab für Port 8080 konfiguriert ist. Unser Proxy-Agent ist so konfiguriert, dass alle Anfragen an Port 8080 weitergeleitet werden. Wenn der Jupyter-Server nicht auf den richtigen Port wartet, treten bei der Instanz Bereitstellungsprobleme auf.

• Ändern Sie JupyterLab-Pakete in der Micromamba-Umgebung jupyterlab. Wir stellen eine separate Paketumgebung zum Ausführen von JupyterLab und dem zugehörigen Plug-in bereit, um Abhängigkeitskonflikte mit der Kernel-Umgebung zu vermeiden. Wenn Sie eine zusätzliche JupyterLab-Erweiterung installieren möchten, müssen Sie sie in der jupyterlab-Umgebung installieren. Beispiel:

  # DockerFile
  FROM us-docker.pkg.dev/deeplearning-platform-release/gcr.io/workbench-container:latest
  RUN micromamba activate jupyterlab && \
    jupyter nbextension install nbdime

Benutzerdefinierte Container-Metadaten

Zusätzlich zur Standardliste der Metadaten, die auf eine Gemini Enterprise Agent Platform Workbench-Instanz angewendet werden können, enthalten Instanzen mit benutzerdefinierten Containern die folgenden Metadaten zum Verwalten der Instanziierung des Nutzlastcontainers:

Funktion	Beschreibung	Metadatenschlüssel	Gültige Werte und Standardeinstellungen
Aktiviert Cloud Storage FUSE in einem Container-Image	/dev/fuse wird im Container bereitgestellt und gcsfuse für die Verwendung im Container aktiviert	container-allow-fuse	true: Aktiviert Cloud Storage FUSE false (Standardeinstellung): Cloud Storage FUSE ist nicht aktiviert
Zusätzliche Parameter für die Containerausführung	Hängt zusätzliche Containerparameter an nerdctl run an, wobei nerdctl die Containerd-Befehlszeile ist.	container-custom-params	Ein String mit Parametern für die Containerausführung. Beispiel: --v /mnt/disk1:/mnt/disk1.
Zusätzliche Flags für Containerumgebungen	Speichert Umgebungsvariablen in einem Flag unter /mnt/stateful_partition/workbench/container_env und hängt es an nerdctl run an.	container-env-file	Ein String mit Container-Umgebungsvariablen. Beispiel: CONTAINER_NAME=derivative-container.

Benutzerdefinierten Container aktualisieren

Wenn Ihre Instanz zum ersten Mal gestartet wird, ruft sie das Container-Image von einem URI ab, der in den custom-container-payload-Metadaten gespeichert ist. Wenn Sie das Tag :latest verwenden, wird der Container bei jedem Neustart aktualisiert. Der Metadatenwert custom-container-payload kann nicht direkt geändert werden, da es sich um einen geschützten Metadatenschlüssel handelt.

Wenn Sie das benutzerdefinierte Container-Image Ihrer Instanz aktualisieren möchten, können Sie die folgenden Methoden verwenden, die von der Google Cloud CLI, Terraform oder der Notebooks API unterstützt werden.

gcloud

Mit dem folgenden Befehl können Sie die Metadaten des benutzerdefinierten Container-Images auf einer Agent Platform Workbench-Instanz aktualisieren:

gcloud workbench instances update INSTANCE_NAME \
    --container-repository=CONTAINER_URI \
    --container-tag=CONTAINER_TAG

Terraform

Sie können das Feld container_image in der Terraform-Konfiguration ändern, um die Container-Nutzlast zu aktualisieren.

Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

resource "google_workbench_instance" "default" {
  name     = "workbench-instance-example"
  location = "us-central1-a"

  gce_setup {
    machine_type = "n1-standard-1"
    container_image {
      repository = "us-docker.pkg.dev/deeplearning-platform-release/gcr.io/workbench-container"
      family  = "latest"
    }
  }
}

Notebooks API

Verwenden Sie die Methode instances.patch mit Änderungen an gce_setup.container_image.repository und gce_setup.container_image.tag in der updateMask.

Diagnosetool ausführen

Das Diagnosetool prüft den Status verschiedener Agent Platform Workbench-Dienste. Weitere Informationen finden Sie unter Vom Diagnosetool ausgeführte Aufgaben.

Wenn Sie eine Agent Platform Workbench-Instanz mit einem benutzerdefinierten Container erstellen, ist das Diagnosetool nicht als Skript in der Hostumgebung verfügbar, das Nutzer ausführen können. Stattdessen wird er in eine Binärdatei kompiliert und in einen Google-Laufzeitcontainer geladen, der für die Ausführung von Diagnosediensten in einer Container-Optimized OS-Umgebung entwickelt wurde. Weitere Informationen finden Sie unter Übersicht über Container-Optimized OS.

Führen Sie die folgenden Schritte aus, um das Diagnosetool auszuführen:

1. Stellen Sie eine SSH-Verbindung zur Agent Platform Workbench-Instanz her.

2. Führen Sie im SSH-Terminal den folgenden Befehl aus:

   sudo docker exec diagnostic-service ./diagnostic_tool

3. Führen Sie den folgenden Befehl aus, um zusätzliche Befehlsoptionen aufzurufen:

   sudo docker exec diagnostic-service ./diagnostic_tool --help

Weitere Informationen zu den Optionen des Diagnosetools finden Sie in der Dokumentation zum Monitoring des Systemzustands.

Informationen zum Ausführen des Diagnosetools mit der REST API finden Sie in der REST API-Dokumentation.

Auf die Instanz zugreifen

Sie können über eine Proxy-URL auf Ihre Instanz zugreifen.

Nachdem die Instanz erstellt wurde und aktiv ist, können Sie den Proxy-URL mithilfe der gcloud CLI abrufen.

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

• INSTANCE_NAME: der Name Ihrer Agent Platform Workbench-Instanz
• PROJECT_ID: Ihre Projekt-ID.
• LOCATION: Zone, in der sich Ihre Instanz befindet.

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

gcloud workbench instances describe INSTANCE_NAME \
--project=PROJECT_ID \
--location=LOCATION | grep proxy-url

Windows (PowerShell)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

gcloud workbench instances describe INSTANCE_NAME `
--project=PROJECT_ID `
--location=LOCATION | grep proxy-url

Windows (cmd.exe)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

gcloud workbench instances describe INSTANCE_NAME ^
--project=PROJECT_ID ^
--location=LOCATION | grep proxy-url

proxy-url: 7109d1b0d5f850f-dot-datalab-vm-staging.googleusercontent.com

Der Befehl describe gibt die Proxy-URL zurück. Um auf Ihre Instanz zuzugreifen, öffnen Sie die Proxy-URL in einem Webbrowser.

Weitere Informationen zum Befehl zum Beschreiben einer Instanz über die Befehlszeile siehe gcloud CLI Dokumentation.