Vorkonfigurierte Basis-Images

Google Cloud verwaltet die folgenden Basis-Images für Cloud Workstations, die von den Standard-Basis-Images von Google Cloudabgeleitet sind.

Liste der vorkonfigurierten Basis-Images

Diese Images können direkt in Workstation-Konfigurationen oder als Basis-Images verwendet werden, wenn Sie mit dem Docker-Befehl FROM benutzerdefinierte Container-Images erstellen.

Image Beschreibung
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest Cloud Workstations-Basiseditor, Code OSS für Cloud Workstations, basierend auf Code-OSS. (Standardeinstellung)
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/base:latest Basis-Image ohne installierte IDE.
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss-cuda:latest Cloud Workstations-Basiseditor, Code OSS für Cloud Workstations, basierend auf Code-OSS mit NVIDIA CUDA Toolkit.
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/clion:latest CLion IDE. Nur über JetBrains Gateway zugänglich.
Informationen zur Installation und zu den ersten Schritten finden Sie unter Code mit lokalen JetBrains-IDEs entwickeln.
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/goland:latest GoLand IDE. Nur über JetBrains Gateway zugänglich.
Informationen zur Installation und zu den ersten Schritten finden Sie unter Code mit lokalen JetBrains-IDEs entwickeln.
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/intellij-ultimate:latest IntelliJ IDEA Ultimate IDE. Nur über JetBrains Gateway zugänglich.
Informationen zur Installation und zu den ersten Schritten finden Sie unter Code mit lokalen JetBrains-IDEs entwickeln.
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/phpstorm:latest PhpStorm-IDE. Nur über JetBrains Gateway zugänglich.
Informationen zur Installation und zu den ersten Schritten finden Sie unter Code mit lokalen JetBrains-IDEs entwickeln.
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/pycharm:latest PyCharm Professional IDE. Nur über JetBrains Gateway zugänglich.
Informationen zur Installation und zu den ersten Schritten finden Sie unter Code mit lokalen JetBrains-IDEs entwickeln.
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/rider:latest Rider IDE. Nur über JetBrains Gateway zugänglich.
Informationen zur Installation und zu den ersten Schritten finden Sie unter Code mit lokalen JetBrains-IDEs entwickeln.
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/rubymine:latest RubyMine-IDE. Nur über JetBrains Gateway zugänglich.
Informationen zur Installation und zu den ersten Schritten finden Sie unter Code mit lokalen JetBrains-IDEs entwickeln.
us-central1-docker.pkg.dev/cloud-workstations-images/predefined/webstorm:latest WebStorm-IDE. Nur über JetBrains Gateway zugänglich.
Informationen zur Installation und zu den ersten Schritten finden Sie unter Code mit lokalen JetBrains-IDEs entwickeln.

Liste der Basis-Images von Drittanbietern

Bild eines Drittanbieters Drittanbieter
us-central1-docker.pkg.dev/posit-images/cloud-workstations/workbench:latest Posit Workbench (einschließlich RStudio Pro)

Wenn Sie Probleme mit der Posit Workbench-IDE oder dem Posit Workbench-Container-Image haben, melden Sie diese auf GitHub an Posit.

Struktur des Basis-Images von Cloud Workstations

Cloud Workstations-Basis-Images haben die folgende definierte Struktur:

  • Die Entrypoint-Datei des Basis-Images ist auf /google/scripts/entrypoint.sh festgelegt.

  • Beim Start führen Basis-Images Dateien unter /etc/workstation-startup.d/* in lexikografischer Reihenfolge aus, um die Workstation-Umgebung zu initialisieren.

    Die Dateien und ihr Verhalten sind wie folgt:

    • 000_configure-docker.sh: Konfiguriert und führt Docker auf der Workstation aus.

    • 010_add-user.sh: Erstellt den Standardnutzer in Cloud Workstations.

      Da der nichtflüchtige Speicher dynamisch an den Container angehängt wird, müssen Nutzer beim Start der Workstation hinzugefügt werden, nicht im Dockerfile.

    • 020_start-sshd.sh: Startet den Dienst sshd im Container.

    • 030_customize-environment.sh: Führt /home/user/.workstation/customize_environment als user aus.

    • 110_start-$IDE.sh: Startet die IDE für das Image.

  • Cloud Workstations speichert Docker-Images im Basisverzeichnis unter /home/.docker_data, damit die Images zwischen Sitzungen erhalten bleiben.

Wenn Sie beim Starten der Workstation zusätzliche Funktionen hinzufügen möchten, fügen Sie Ihre Skripts im Verzeichnis /etc/workstation-startup.d/ hinzu:

  • Skripts in diesem Verzeichnis werden standardmäßig als Root ausgeführt. Wenn Sie die Skripts als anderer Nutzer ausführen möchten, verwenden Sie den Befehl runuser.

  • Da Skripts in lexikografischer Reihenfolge ausgeführt werden, empfehlen wir, den Skripts eine dreistellige Zahl voranzustellen, die größer als 200 ist.

Wenn Sie ein Workstations-Image nicht erweitern möchten, können Sie alternativ ein customize_environment-Skript in Ihrem Basisverzeichnis erstellen.

Änderungen am Basisverzeichnis

Wenn in der Workstation-Konfiguration ein nichtflüchtiges Basisverzeichnis angegeben ist (Standardverhalten), wird ein nichtflüchtiger Speicher, der das Basisverzeichnis sichert, zur Laufzeit dynamisch an den Container angehängt. Bei diesem Vorgang werden Änderungen am Verzeichnis /home überschrieben, die beim Erstellen des Container-Images vorgenommen wurden.

Wenn Sie Aktualisierungen beibehalten möchten, ändern Sie das Verzeichnis /home zur Containerlaufzeit, indem Sie ein Skript im Verzeichnis /etc/workstation-startup.d oder eine nutzerspezifische Konfiguration im Verzeichnis /etc/profile.d hinzufügen. Um den Vorgang zu beschleunigen, können Sie das Setupscript als Hintergrundprozess ausführen (fügen Sie am Ende des Befehls ein kaufmännisches Und-Zeichen, &, hinzu), um zu vermeiden, dass der Containerstart blockiert wird.

Beispiele für die Build-Konfiguration, die in die Containerlaufzeit verschoben werden sollte:

  • git-Konfiguration pro Nutzer
  • git Repositorys im Basisverzeichnis geklont
  • Direkte Nutzerkonfiguration, z. B. durch Ablegen von Dateien in einem $HOME/.config-Verzeichnis
  • Nutzer erstellen

Nutzererstellung und -änderung

Da der nichtflüchtige Speicher zur Laufzeit dynamisch an den Container angehängt wird, müssen Nutzer beim Start der Workstation hinzugefügt werden, nicht im Dockerfile. Wenn Sie zusätzliche Nutzer ändern oder erstellen möchten, empfehlen wir, /etc/workstation-startup.d/010_add-user.sh zu aktualisieren oder ein eigenes Skript zu erstellen, das beim Start ausgeführt wird.

Außerdem können Sie das Standard-Bash-Profil für die Nutzer ändern, indem Sie die Dateien in /etc/profile.d aktualisieren.

Vorkonfigurierte Secure APT-Schlüssel aktualisieren

Auf den Basis-Images von Cloud Workstations sind eine Reihe von Tools vorinstalliert, die über Secure APT aus verschiedenen Drittanbieter-Repositories abgerufen werden. Im Rahmen des Installationsvorgangs werden die von den Repository-Inhabern bereitgestellten öffentlichen Schlüssel mit gpg importiert und in einzelnen Dateien unter /usr/share/keyrings/ abgelegt. Diese Dateien werden von entsprechenden list-Dateien unter /etc/apt/sources.list.d/ referenziert. Dadurch kann apt die Integrität eines bestimmten Repositorys überprüfen, wenn damit interagiert wird.

Gelegentlich entscheiden sich Inhaber von Drittanbieter-Repositories, den öffentlichen Schlüssel zu ändern, der zur Validierung der Integrität ihres Repositorys verwendet wird. Dies führt dazu, dass apt bei der Interaktion mit dem Repository einen Fehler anzeigt. Um dieses potenzielle Problem zu beheben, können Sie /google/scripts/refresh-preinstalled-apt-keys.sh verwenden, das die aktuellen Versionen der vorinstallierten öffentlichen Schlüssel abruft und sie neu importiert.

Sie können dieses Script auch direkt in Ihrem benutzerdefinierten Dockerfile ausführen, bevor Sie apt-get update ausführen:

# Refresh the preinstalled APT keys
RUN /google/scripts/refresh-preinstalled-apt-keys.sh

RUN apt-get update

Installierte IDE-Versionen auflisten

Auf mehreren Cloud Workstations-Basis-Images ist eine IDE vorinstalliert. Der Einfachheit halber finden Sie im enthaltenen /google/scripts/preinstalled-ide-versions.sh-Skript die Namen und Versionsinformationen der im Image installierten IDEs.

sudo-Root-Berechtigungen deaktivieren

Der Standard-Workstation-Nutzer hat in diesen Containern sudo-Root-Zugriffsberechtigungen. Wenn Sie den Root-Zugriff auf den Docker-Container deaktivieren möchten, setzen Sie beim Erstellen der Workstation-Konfiguration die Umgebungsvariable CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO auf true.

So legen Sie diese Umgebungsvariable beim Erstellen Ihrer Workstation-Konfiguration über die Google Cloud Console fest:

  1. Schließen Sie beim Erstellen der Workstation-Konfiguration die Konfiguration für „Grundlegende Informationen“ und „Maschinenkonfiguration“ ab.
  2. Maximieren Sie im Dialogfeld Umgebung anpassen den Bereich Erweiterte Containeroptionen und wählen Sie Umgebungsvariablen aus.
  3. Klicken Sie auf HinzufügenVariable hinzufügen.
  4. Geben Sie CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO und true als Wert ein.

Image anpassen, ohne es zu erweitern

Der Einfachheit halber prüfen alle Cloud Workstations-Basis-Images, ob eine ausführbare Datei unter /home/user/.workstation/customize_environment vorhanden ist. Wenn ja, wird sie im Hintergrund als user ausgeführt. So können Sie beim Start ein beliebiges Skript oder eine beliebige Binärdatei ausführen. Im Gegensatz zu .profile oder .bashrc wird das Skript nur einmal beim Start der Workstation ausgeführt und nicht einmal für jede Shell-Anmeldung.

Da das Script customize_environment als user ausgeführt wird, müssen Sie die Berechtigungen beim Schreiben des Scripts entsprechend aktualisieren. Wenn Sie beispielsweise Emacs bei jedem Start Ihrer Workstation installieren möchten, könnte der Inhalt von customize_environment so aussehen:

#!/bin/bash
sudo apt-get update
sudo apt-get install -y emacs

Ausführungslogs für customize_environment finden Sie im Container unter /var/log/customize_environment. Sie werden auch in die Containerausgabe-Logs geschrieben. Nach erfolgreicher Ausführung von customize_environment wird eine Datei in /var/run/customize_environment_done erstellt. Da customize_environment parallel zum Start der Workstation ausgeführt wird, können vom Script installierte Pakete bereits wenige Augenblicke nach dem Start der Workstation verfügbar sein.

Inaktivitäts-Timeouts verhindern

Der Einfachheit halber enthalten alle Cloud Workstations-Basis-Images ein vorinstalliertes Skript unter /google/scripts/keep_alive.sh. Dieses Script sendet regelmäßig Keep-Alive-Nachrichten, die verhindern können, dass die Workstation aufgrund von Zeitüberschreitungen bei Inaktivität heruntergefahren wird, wenn Sie Hintergrundprozesse ohne direkte Interaktion ausführen.

Inaktivitäts-Timeouts mit KI-Agenten verhindern

Außerdem enthalten die Cloud Workstations-Basis-Images Beispielskripts für die Agent-Konfiguration unter /google/samples/agents/keepalive/. Mit diesen Beispielkonfigurationen können Sie KI-Codierungs-Agents (wie Claude Code und Antigravity CLI) in der Workstation so konfigurieren, dass die Workstation automatisch aktiv bleibt, während sie aktiv an Aufgaben arbeiten. Wenn der KI-Agent seine Aufgaben abgeschlossen hat oder auf eine Nutzereingabe wartet, sendet das Script keine Keep-Alive-Nachrichten mehr. Die Workstation kann dann aufgrund von Inaktivität beendet werden. Diese Konfigurationen funktionieren am besten, wenn die Workstationkonfiguration so eingestellt ist, dass die Workstationsperre verwendet wird (idleAction auf SUSPEND gesetzt). Dadurch kann die Workstation den Speicherstatus speichern und nahtlos fortgesetzt werden, wenn Sie zurückkehren.

Weitere Informationen zum Einrichten von KI-Agent-gestützten Workflows und Keep-Alive-Hooks finden Sie unter Agent-optimierte Entwicklung.

Nächste Schritte