Container-Images anpassen

Die von Cloud Workstations bereitgestellten vorkonfigurierten Basis-Images enthalten nur eine minimale Umgebung mit IDE, grundlegendem Linux-Terminal und Sprachtools sowie einem sshd-Server. Um die Einrichtung der Umgebung für bestimmte Entwicklungsanwendungsfälle zu beschleunigen, können Sie benutzerdefinierte Container-Images erstellen, die diese Basis-Images erweitern, um Tools und Abhängigkeiten vorzuinstallieren und Automatisierungsskripts auszuführen.

Für benutzerdefinierte Container-Images empfehlen wir, eine Pipeline einzurichten, um diese Images automatisch neu zu erstellen, wenn das Cloud Workstations-Basis-Image aktualisiert wird. Außerdem sollten Sie ein Container-Scanning-Tool wie Artifact Analysis ausführen, um alle zusätzlichen Abhängigkeiten zu prüfen, die Sie hinzugefügt haben. Sie sind für die Wartung und Aktualisierung benutzerdefinierter Pakete und Abhängigkeiten verantwortlich, die benutzerdefinierten Images hinzugefügt wurden.

Hinweis

  1. Sie benötigen einen Computer mit Tools zum Erstellen von Container-Images wie Docker und zum Übertragen von Images in die Artifact Registry mithilfe der Google Cloud CLI. Sie können Cloud Workstations oder den Cloud Shell-Editor verwenden, um diese Schritte auszuführen. Diese Tools sind bereits vorinstalliert.

  2. Wählen Sie aus der Liste der unterstützten Basis-Images das gewünschte Basis-Image aus, z. B. us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest.

    Alternativ können Sie ein eigenes Container-Image oder externe Container-Images verwenden. Folgen Sie dazu der Anleitung unter Eigenes Container-Image verwenden.

  3. Erstellen Sie einen Ordner wie CUSTOM_IMAGE_FOLDER und ein Dockerfile in diesem Ordner, das das ausgewählte Basis-Image erweitert, wie in den folgenden Beispielen gezeigt.

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.

Eigenes Container-Image verwenden

Sie können auch Ihr eigenes Container-Image oder externe Container-Images verwenden, sofern diese Linux-basiert sind und beim Start des Containers einen blockierenden Prozess ausführen.

Beim Einrichten des Dockerfile muss die Anweisung ENTRYPOINT einen blockierenden Prozess wie sleep infinity ausführen, damit der Container weiter ausgeführt wird, anstatt sofort beendet zu werden. Alternativ können Sie in der Workstation-Konfiguration das Feld config.container.args festlegen, um einen blockierenden Prozess anzugeben.

Beachten Sie bei der Verwendung Ihres eigenen Container-Images Folgendes:

  • Cloud Workstations erfordert keine zusätzlichen Skripts aus dem Cloud Workstations-Basis-Image.

    Sie können sich jedoch die Skripts im Verzeichnis /etc/workstation-startup.d/ in einem Container ansehen, in dem das Cloud Workstations-Basis-Image ausgeführt wird. Die Dateinamen geben an, was die einzelnen Skripts tun.

  • Wir empfehlen, einen SSH-Server im Container auszuführen. Informationen dazu, wie Cloud Workstations dies standardmäßig einrichtet, finden Sie unter /etc/workstation-startup.d/020_start-sshd.sh im Basis-Image.

  • Wir empfehlen, Ihre Standard-IDE oder Ihren Webserver auf Port 80 auszuführen.

Google Cloud bietet Standard-Basis-Images, mit denen Sie ein vollständig benutzerdefiniertes Container-Image erstellen können.

Cloud Workstations-Basis-Images erweitern

Wenn Sie ein Cloud Workstations-Basis-Image erweitern, um ein benutzerdefiniertes Image für Ihre Workstation-Umgebung zu erstellen, haben Sie drei Möglichkeiten:

  1. Aktualisieren Sie Ihre Dockerfile, um alle zusätzlichen statischen Assets einzuschließen, die Sie hinzufügen möchten.
  2. Fügen Sie unter /etc/workstation-startup.d/ weitere ausführbare Dateien hinzu, um den ausgeführten Container anzupassen. Dateien in diesem Verzeichnis werden beim Containerstart automatisch in lexikografischer Reihenfolge ausgeführt. Sie können also den Dateinamen mit einem Präfix versehen, damit die Datei zum richtigen Zeitpunkt während des Workstation-Starts ausgeführt wird.
  3. Überschreiben Sie den ENTRYPOINT in Ihrem Dockerfile, um den Containerstart vollständig anzupassen.

Beispiele für benutzerdefinierte Dockerfiles

In diesem Abschnitt finden Sie Beispielszenarien und Anleitungen zum Erstellen eigener Dockerfiles.

Container-Image mit vorinstalliertem emacs

Führen Sie die folgenden Befehle aus, um ein Container-Image mit vorinstalliertem emacs zu erstellen:

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

RUN sudo apt update
RUN sudo apt install -y emacs

Container-Image mit Nutzeranpassung

So passen Sie ein Container-Image an:

  1. Erstellen Sie in /etc/workstation-startup.d/* ein Skript, das nach 010_add-user.sh ausgeführt wird, z. B. 011_customize-user.sh:

    #!/bin/bash
# Create new group
groupadd $GROUP
# Add the user to a new group
usermod -a -G $GROUP $USERNAME

    Ersetzen Sie $GROUP durch den neuen Gruppennamen und $USERNAME durch den Nutzernamen des Nutzers.

  2. Angenommen, Sie haben Ihr Skript 011_customize-user.sh genannt. Fügen Sie Ihrem Image im Dockerfile Folgendes hinzu und machen Sie es ausführbar:

    FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

COPY 011_customize-user.sh /etc/workstation-startup.d/

RUN chmod +x /etc/workstation-startup.d/011_customize-user.sh

Container-Image, das Container-Umgebungsvariablen in SSH-Sitzungen festlegt

Umgebungsvariablen, die auf der Ebene der Workstation-Konfiguration oder der Workstation festgelegt sind, werden mit dem Einstiegspunktbefehl an direkte Unterprozesse übergeben. Dazu gehört auch die IDE in den vorkonfigurierten Basis-Images. SSH-Sitzungen sind jedoch keine untergeordneten Prozesse des Einstiegspunkts und haben diese benutzerdefinierten Umgebungsvariablen nicht festgelegt.

Wenn Sie diese Umgebungsvariablen in den SSH-Sitzungen festlegen möchten, richten Sie ein benutzerdefiniertes Container-Image ein, das diese Umgebungsvariablen vom Einstiegspunktbefehl des Containers an die Datei /etc/environment weiterleitet.

Gehen Sie dazu so vor:

  1. Erstellen Sie in /etc/workstation-startup.d/* ein Skript, das nach 010_add-user.sh ausgeführt wird, z. B. 011_add-ssh-env-variables.sh:

    #!/bin/bash
#
echo "CUSTOM_ENV_VAR=$CUSTOM_ENV_VAR" >> /etc/environment

    Ersetzen Sie CUSTOM_ENV_VAR durch den gewünschten Namen der Umgebungsvariablen.

  2. Angenommen, Sie haben Ihr Skript 011_add-ssh-env-variables.sh genannt. Fügen Sie Ihrem Image im Dockerfile Folgendes hinzu und machen Sie es ausführbar:

    FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

COPY 011_add-ssh-env-variables.sh /etc/workstation-startup.d/

RUN chmod +x /etc/workstation-startup.d/011_add-ssh-env-variables.sh

Container-Image, das die X11-Weiterleitung für SSH-Sitzungen ermöglicht

Mit der X11-Weiterleitung können Sie Remote-Anwendungen starten und die Anzeige der Anwendung an einen lokalen Computer weiterleiten.

Wenn Sie ein Container-Image erstellen möchten, das die X11-Weiterleitung ermöglicht, ändern Sie die OpenSSH-Daemon-Konfigurationsdatei (/etc/ssh/sshd_config), die von den Cloud Workstations-Basis-Images bereitgestellt wird. Hängen Sie dazu X11Forwarding yes (um die X11-Weiterleitung zuzulassen) und AddressFamily inet (um sicherzustellen, dass nur IPv4 verwendet wird) an. Weitere Informationen zu diesen Schlüsselwörtern finden Sie auf den OpenBSD-Webseiten zu AddressFamily und X11Forwarding.

Hier ist ein Beispiel für ein Dockerfile, das die erforderlichen Änderungen vornimmt:

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

# Permit X11 forwarding using only IPv4
RUN cat >> /etc/ssh/sshd_config <<-EOF

AddressFamily inet
X11Forwarding yes
EOF

Code OSS for Cloud Workstations in ein anderes Container-Image kopieren

Bei einem mehrstufigen Build können Sie mehrere FROM-Anweisungen in Ihrem Dockerfile verwenden. Jede FROM-Anweisung kann eine andere Basis verwenden und ermöglicht das Kopieren von Artefakten zwischen Build-Phasen. Wenn Sie Code OSS for Cloud Workstations einem anderen Container-Image hinzufügen möchten, verwenden Sie einen mehrstufigen Build, um den Anwendungsordner /opt/code-oss in Ihr Image zu kopieren. Wenn Sie Code OSS for Cloud Workstations beim Containerstart starten möchten, kopieren Sie zusätzlich das Script /etc/workstation-startup.d/110_start-code-oss.sh in Ihren Container.

Hier ist ein Beispiel-Dockerfile, das Code OSS in das JetBrains IntelliJ Ultimate-Image kopiert. Sie können dann mit einer der beiden IDEs interagieren:

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest as code-oss-image

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/jetbrains-intellij:latest

# Copy Code OSS for Cloud Workstations and startup scripts into our custom image
COPY --from=code-oss-image /opt/code-oss /opt/code-oss
COPY --from=code-oss-image /etc/workstation-startup.d/110_start-code-oss.sh /etc/workstation-startup.d/110_start-code-oss.sh

# Use the existing entrypoint script which will execute all scripts in /etc/workstation-startup.d/
ENTRYPOINT ["/google/scripts/entrypoint.sh"]

Container-Image, das IDE-Erweiterungen in Code OSS for Cloud Workstations für die Java-Entwicklung vorinstalliert

Führen Sie die folgenden Befehle aus, um ein Container-Image zu erstellen, das IDE-Erweiterungen in Code OSS for Cloud Workstations für die Java-Entwicklung zur Build-Zeit vorinstalliert:

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

RUN wget https://open-vsx.org/api/vscjava/vscode-java-debug/0.40.1/file/vscjava.vscode-java-debug-0.40.1.vsix && \
unzip vscjava.vscode-java-debug-0.40.1.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/java-debug

RUN wget https://open-vsx.org/api/vscjava/vscode-java-dependency/0.19.1/file/vscjava.vscode-java-dependency-0.19.1.vsix && \
unzip vscjava.vscode-java-dependency-0.19.1.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/java-dependency

RUN wget https://open-vsx.org/api/redhat/java/1.6.0/file/redhat.java-1.6.0.vsix && \
unzip redhat.java-1.6.0.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/redhat-java

RUN wget https://open-vsx.org/api/vscjava/vscode-maven/0.35.2/file/vscjava.vscode-maven-0.35.2.vsix && \
unzip vscjava.vscode-maven-0.35.2.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/java-maven

RUN wget https://open-vsx.org/api/vscjava/vscode-java-test/0.35.0/file/vscjava.vscode-java-test-0.35.0.vsix && \
unzip vscjava.vscode-java-test-0.35.0.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/java-test

RUN chmod a+rwx -R /opt/code-oss/extensions/

Wenn Sie Erweiterungen vorinstallieren, gelten sie als integrierte Erweiterungen. Sie können diese Erweiterungen nicht aktualisieren und sie werden möglicherweise nicht im Abschnitt „Installiert“ im Extensions Marketplace angezeigt. Sie können jedoch nach Ihren integrierten Erweiterungen suchen, indem Sie nach @builtin suchen.

Eine weitere Möglichkeit, Erweiterungen beim Start zu installieren, ist die Ausführung eines Startskripts. Fügen Sie beispielsweise das folgende Startskript unter /etc/workstation-startup.d/120_install_extensions.sh ein:

sudo -u user /opt/code-oss/bin/codeoss-cloudworkstations --install-extension vscjava.vscode-java-debug@0.40.1 \
--install-extension vscjava.vscode-java-dependency@0.19.1  \
--install-extension redhat.java@1.6.0 \
--install-extension vscjava.vscode-maven@0.35.2 \
--install-extension vscjava.vscode-java-test@0.35.0

Bei dieser Methode wird die Erweiterung im Extensions Marketplace von angezeigt und Sie können sie von dort aus aktualisieren.

JetBrains-IDEs und ‑Plug-ins in Basis-Images installieren

Wenn Sie Docker-Images für Workstation-Konfigurationen anpassen, können Sie JetBrains-IDEs und ‑Plug-ins wie Cloud Code for IntelliJ im Basis-Image installieren. Die Cloud Workstations-Basis-Images für JetBrains-Produkte enthalten die folgenden Skripts, die Ihnen helfen:

  • jetbrains-installer.sh: JetBrains-IDEs installieren
  • plugin-installer.sh: Plug-ins wie Cloud Code for IntelliJ installieren

Verwenden Sie diese Skripts nach Bedarf, um das Basis-Image anzupassen, sie mit einem Startskript aufzurufen oder sie nach dem Start der Workstation auszuführen.

Installationsskripts

Wenn Sie die Quelldateien für die Scripts jetbrains-installer.sh und plugin-installer.sh aufrufen möchten, starten Sie eine Workstation mit einer Workstation-Konfiguration, die eines der vordefinierten JetBrains-Images verwendet. Stellen Sie dann entweder über JetBrains Gateway oder über SSH eine Verbindung zur Workstation her und rufen Sie die Scriptdateien im Verzeichnis installer-scripts auf, das sich im Stammverzeichnis befindet.

Wir empfehlen, diese Skripts beim Erstellen des Containers auszuführen. Führen Sie sie nicht auf einer bereits gestarteten Workstation aus.

Plug-in-Installationsskript verwenden

Das Skript plugin-installer.sh verwendet die folgende Syntax:

plugin-installer.sh [-v VERSION] [-d DESTINATION-DIRECTORY] [-c CHECKSUM] [-f] PLUGIN_ID

Ersetzen Sie Folgendes:

  • VERSION: optionale Versionsnummer des zu installierenden Plug-ins.
  • DESTINATION-DIRECTORY: optionales Verzeichnis, in dem das Plug-in installiert werden soll. Wenn nichts angegeben ist, wird das Arbeitsverzeichnis verwendet.
  • CHECKSUM: optionale SHA-256-Prüfsumme des angeforderten Plug-ins.
  • -f: Wenn angegeben, wird ein vorhandenes Plug-in überschrieben.
  • PLUGIN_ID: die erforderliche numerische Plug-in-ID aus dem JetBrains-Marktplatz. Wenn Sie beispielsweise Dart hinzufügen möchten, verwenden Sie 6351 als PLUGIN_ID. Wenn Sie Cloud Code for IntelliJ hinzufügen möchten, verwenden Sie 8079 als PLUGIN_ID.

Führen Sie beispielsweise den folgenden Befehl aus, um die aktuelle Version des Dart-Plug-ins in IntelliJ zu installieren:

/installer-scripts/plugin-installer.sh -d /opt/ideaIU/plugins/ 6351

JetBrains-Installationsskript verwenden

Wir empfehlen, das JetBrains-Installationsskript zu verwenden, wenn Sie ein vorkonfiguriertes Basis-Image für JetBrains-IDEs erweitern.

Das Skript jetbrains-installer.sh verwendet die folgende Syntax:

jetbrains-installer.sh IDE [ pinned|latest ]

Ersetzen Sie Folgendes:

  • IDE: die zu installierende JetBrains-IDE. Sie müssen eine der folgenden IDE-Abkürzungen verwenden:

    IDE Produkt installiert
    cl CLion
    clion CLion
    go GoLand
    goland GoLand
    iiu Intellij Ultimate
    intellij Intellij Ultimate
    pcp PyCharm Professional
    pycharm PyCharm Professional
    ps PHPStorm
    phpstorm PHPStorm
    rd Rider
    rider Rider
    rm RubyMine
    rubymine RubyMine
    ws WebStorm
    webstorm WebStorm

  • pinned|latest: Optional – Verwenden Sie entweder die angepinnte oder die aktuelle Version der IDE. Die Standardeinstellung ist latest.

Führen Sie beispielsweise den folgenden Befehl aus, um die aktuelle Version von Clion zu installieren:

/installer-scripts/jetbrains-installer.sh clion

JetBrains-IDE-Konfigurationsdateien anpassen

Wenn in der Workstation-Konfiguration ein nichtflüchtiges Basisverzeichnis angegeben ist, speichern die Cloud Workstations-Basis-Images mit JetBrains-IDEs die Konfigurationsdateien $IDE.vmoptions und $IDE.properties automatisch. Wenn Sie den Standardspeicherort dieser Dateien überschreiben möchten, geben Sie die Umgebungsvariable CLOUD_WORKSTATIONS_JETBRAINS_PERISTED_CONFIG_DIR an.

Weitere Informationen finden Sie unter /etc/workstation-startup.d/120_persist-jetbrains-configs.sh in einem beliebigen JetBrains-Basis-Image. Dort erfahren Sie, wie Cloud Workstations dies standardmäßig einrichtet.

Docker-Basis-Image mit Cloud Code for IntelliJ erweitern

Im folgenden Dockerfile-Snippet wird ein Docker-Basis-Image mit Cloud Code for IntelliJ erweitert. Dazu wird 8079 als erforderliche Plug-in-ID eingefügt. Im Beispiel werden optional auch version 22.9.3-222 als Versionsnummer, /opt/ideaIU/plugins/ als Zielverzeichnis und 89628279ed9042c526a81facc09bf53f8fb8b83b4595b0d329d94c1611e0c379 als Prüfsumme angegeben:

...
# Install IDE and Plugins
RUN bash /installer-scripts/jetbrains-installer.sh intellij pinned && \
  # Install Cloud Code - https://plugins.jetbrains.com/plugin/8079-cloud-code
  bash /installer-scripts/plugin-installer.sh \
      -v 22.9.3-222 \
      -d /opt/ideaIU/plugins/ \
      -c 89628279ed9042c526a81facc09bf53f8fb8b83b4595b0d329d94c1611e0c379 \
      8079

# Register IDE with JetBrains Gateway
RUN echo 'runuser user -c "/opt/ideaIU/bin/remote-dev-server.sh registerBackendLocationForGateway"' > /etc/workstation-startup.d/110_register-intellij-with-gateway.sh \
    echo 'echo "IntelliJ-Ultimate ready for incoming gateway connection"' >> /etc/workstation-startup.d/110_register-intellij-with-gateway.sh
...

Zusätzliche IDE-Erweiterungen in Code OSS for Cloud Workstations installieren

Weitere IDE-Erweiterungen finden Sie in der Open VSX Registry. Sie können die URL der .vsix-Datei auch ermitteln, indem Sie die URL aus dem Downloadlink einer beliebigen Erweiterung kopieren.

Öffnen Sie die VSX-Seite für die Go-Spracherweiterung, auf der der Download-Button angezeigt wird.

Wenn Sie den Extensions Marketplace von einer Workstation aus öffnen, wird Installieren anstelle von Herunterladen angezeigt.

Standardeinstellungen für Code OSS for Cloud Workstations

Ausführliche Informationen zum Speichern von Einstellungen in Code OSS for Cloud Workstations finden Sie unter Einstellungen anpassen.

Wenn Sie in der Workstation-Konfiguration ein nichtflüchtiges Basisverzeichnis angeben, können Sie Standardeinstellungen für Code OSS for Cloud Workstations konfigurieren. Fügen Sie dazu ein Startskript hinzu, das Einstellungen in $HOME/.codeoss-cloudworkstations/data/Machine/settings.json schreibt.

Wenn Sie beispielsweise das Standardfarbschema auf „Dunkel“ festlegen möchten, erweitern Sie das Basis-Editor-Image, um das folgende Script unter /etc/workstation-startup.d/150_default-ide-color-theme.sh einzufügen:

cat <<< $(jq '. += {"workbench.colorTheme": "Default Dark Modern"}' settings.json) > settings.json

Benutzerdefiniertes Container-Image erstellen

Ausführliche Informationen zu Docker-Befehlen finden Sie in der Docker-Referenz. Geben Sie den folgenden Befehl ein, um den Container zu erstellen:

docker build CUSTOM_IMAGE_FOLDER -t TARGET_IMAGE

Wenn Sie den Text vor dem Symbol Bearbeiten Bearbeiten ersetzen, werden die anderen Beispiele auf dieser Seite aktualisiert.

Ersetzen Sie Folgendes:

  • CUSTOM_IMAGE_FOLDER: der Pfad zu dem Ordner, den Sie zum Speichern Ihres benutzerdefinierten Images erstellt haben.

  • TARGET_IMAGE: der Pfad zu Ihrem Image in Artifact Registry.

    TARGET_IMAGE könnte beispielsweise auf einen Ziel-Image-Pfad wie den folgenden verweisen:

    *.pkg.dev/cloud-workstations-external/customimage:latest

    Ersetzen Sie * nach Bedarf durch den Namen der Region und zusätzliche Kennungen.

Sie können auch die Umgebungsvariable CLOUD_WORKSTATIONS_CUSTOM_IMAGE so aktualisieren, dass sie auf das Repository verweist.

Weitere Informationen zum Speichern von Docker-Images in Artifact Registry finden Sie in den folgenden Abschnitten:

Benutzerdefiniertes Container-Image hosten

Zum Hosten benutzerdefinierter Container-Images empfehlen und unterstützen wir Artifact Registry. Wenn Sie GitHub oder ein anderes öffentliches oder privates Repository verwenden, funktionieren Cloud Workstations möglicherweise nicht wie erwartet. Weitere Informationen finden Sie im wichtigen Hinweis im Abschnitt Benutzerdefiniertes Container-Image verwenden.

Benutzerdefiniertes Container-Image testen

Nachdem der Container erstellt wurde, können Sie ihn mit dem folgenden Befehl testen:

docker run --privileged -p LOCAL_PORT:CONTAINER_PORT TARGET_IMAGE

Ersetzen Sie Folgendes:

  • LOCAL_PORT: die lokale Portnummer
  • CONTAINER_PORT: die Containerportnummer

Wenn Sie beispielsweise LOCAL_PORT:CONTAINER_PORT durch 8080:80 ersetzen, wird Port 8080 für die lokale Verwendung und Port 80 für die Verwendung im Container zugewiesen.

Wenn Sie das Basis-Editor-Image von Cloud Workstations erweitern, führen Sie den Befehl docker aus und testen Sie dann das Workstation-Image, indem Sie über Ihren lokalen Browser eine Verbindung zur Workstation herstellen oder ssh ausführen, um eine Verbindung zu Ihrem Container herzustellen:

  • Wenn Sie die Verbindung über Ihren Browser herstellen, müssen Sie -p 8080:80 an den Befehl docker run übergeben und dann localhost:8080 öffnen.
  • Wenn Sie eine Verbindung über SSH herstellen möchten, müssen Sie -p 2222:22 an den Befehl docker run übergeben und dann ssh user@localhost -p 2222 ausführen.

Benutzerdefiniertes Container-Image verwenden

Wenn Sie Ihr benutzerdefiniertes Container-Image verwenden möchten, nachdem Sie es lokal erstellt und getestet haben, übertragen Sie Ihren Container mit dem folgenden Befehl per Push in Artifact Registry:

docker push TARGET_IMAGE

Sie können jetzt mit dem Container-Image, das Sie gerade erstellt und per Push übertragen haben, eine Workstation-Konfiguration erstellen.

Weitere Informationen finden Sie unter Docker-Repository mit Artifact Registry erstellen.

Probleme beheben

Wenn Sie Probleme beim Ausführen Ihres Container-Images finden und beheben möchten, sehen Sie sich die Containerausgabe-Logs Ihrer laufenden Workstations an.

Sie sind für die Verwaltung und Aktualisierung von benutzerdefinierten Paketen und Abhängigkeiten verantwortlich, die benutzerdefinierten Images hinzugefügt wurden.

Wenn Sie benutzerdefinierte Images erstellen, empfehlen wir Folgendes:

Nächste Schritte