Container-Images anpassen

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

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

Hinweise

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

  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 Cloud Workstations-Basis-Images

Cloud Workstations-Basis-Images haben die folgende Struktur:

  • Die Datei mit dem Basis-Image-Einstiegspunkt ist auf /google/scripts/entrypoint.sh festgelegt.

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

    Die Dateien und ihr Verhalten sind:

    • 000_configure-docker.sh: Docker wird auf der Workstation konfiguriert und ausgeführt.

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

      Da die persistente Festplatte dynamisch an den Container angehängt wird, müssen Nutzer beim Starten der Workstation hinzugefügt werden, nicht in der Dockerfile.

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

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

  • In Cloud Workstations werden Docker-Images im Basisverzeichnis unter /home/.docker_data gespeichert, damit sie zwischen Sitzungen erhalten bleiben.

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

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

  • Da Scripts in lexikalischer Reihenfolge ausgeführt werden, empfehlen wir, den Scripts eine dreistellige Zahl vorangestellt zu geben, die größer als 200 ist.

Änderungen am Basisverzeichnis

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

Wenn Sie Updates beibehalten möchten, ändern Sie das Verzeichnis /home während der Containerlaufzeit. Fügen Sie dazu ein Script in das Verzeichnis /etc/workstation-startup.d oder eine benutzerspezifische Konfiguration in das Verzeichnis /etc/profile.d hinzu. Um den Vorgang zu beschleunigen, können Sie das Einrichtungsskript als Hintergrundprozess ausführen. Fügen Sie dazu am Ende des Befehls ein kaufmännisches Und (&) hinzu, damit der Containerstart nicht blockiert wird.

Beispiele für Konfigurationen zur Buildzeit, die in die Containerlaufzeit verschoben werden sollten:

  • Nutzerspezifische git-Konfiguration
  • git Repositories, die in das Basisverzeichnis geklont wurden
  • Direkte Nutzerkonfiguration, z. B. durch Platzieren von Dateien in einem $HOME/.config-Verzeichnis
  • Nutzer erstellen

Nutzer erstellen und ändern

Da die persistente Festplatte während der Laufzeit dynamisch an den Container angehängt wird, müssen Nutzer beim Starten der Workstation hinzugefügt werden, nicht in der 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 Script 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

Die Basis-Images von Cloud Workstations sind mit einer Reihe von Tools vorinstalliert, die über Secure APT aus verschiedenen Repositories von Drittanbietern abgerufen wurden. Im Rahmen der Installation werden die von den Repository-Inhabern bereitgestellten öffentlichen Schlüssel mit gpg importiert und in einzelne Dateien unter /usr/share/keyrings/ abgelegt. Auf diese Dateien wird in den entsprechenden list-Dateien unter /etc/apt/sources.list.d/ verwiesen. So kann apt die Integrität eines bestimmten Repositories bei der Interaktion mit ihm überprüfen.

Gelegentlich ändern Repository-Inhaber von Drittanbietern den öffentlichen Schlüssel, der zur Validierung der Integrität ihres Repositorys verwendet wird. In diesem Fall zeigt apt bei der Interaktion mit dem Repository einen Fehler an. Sie können /google/scripts/refresh-preinstalled-apt-keys.sh verwenden, um dieses potenzielle Problem zu beheben. Mit diesem Tool werden die neuesten Versionen der vorinstallierten öffentlichen Schlüssel abgerufen und wieder importiert.

Installierte IDE-Versionen auflisten

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

sudo Root-Berechtigungen deaktivieren

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

So legen Sie diese Umgebungsvariable beim Erstellen der Workstationkonfiguration über die Google Cloud Console fest:

  1. Führen Sie beim Erstellen der Workstation-Konfiguration die Konfiguration für die allgemeinen Informationen und die Maschinenkonfiguration durch.
  2. Maximieren Sie im Dialogfeld Umgebungsanpassung 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.

Eigenes Container-Image verwenden

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

Beim Einrichten der Dockerfile muss die ENTRYPOINT-Anweisung 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 Workstationkonfiguration das Feld config.container.args so festlegen, dass ein Blockierungsprozess angegeben wird.

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

  • Für Cloud Workstations sind keine zusätzlichen Scripts aus dem Cloud Workstations-Basis-Image erforderlich.

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

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

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

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 aufzunehmen, die Sie hinzufügen möchten.
  2. Fügen Sie unter /etc/workstation-startup.d/ zusätzliche ausführbare Dateien hinzu, um den laufenden Container anzupassen. Dateien in diesem Verzeichnis werden beim Starten des Containers automatisch in lexikalischer Reihenfolge ausgeführt. Sie können also ein Präfix für den Dateinamen angeben, um die Datei zum richtigen Zeitpunkt beim Starten der Workstation auszuführen.
  3. Überschreiben Sie die ENTRYPOINT in Ihrem Dockerfile, um den Containerstart vollständig anzupassen.

Beispiel für benutzerdefinierte Dockerfiles

Dieser Abschnitt enthält 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 benutzerdefinierten Einstellungen

So passen Sie ein Container-Image an:

  1. Erstellen Sie in /etc/workstation-startup.d/* ein Script, 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.

  2. Angenommen, Sie haben Ihr Script 011_customize-user.sh genannt, fügen Sie Ihrem Image in Ihrem 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 in der Workstation-Konfiguration oder auf Workstation-Ebene festgelegt sind, werden über den Befehl „entrypoint“ 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 /etc/environment-Datei weiterleitet.

Gehen Sie dazu so vor:

  1. Erstellen Sie in /etc/workstation-startup.d/* ein Script, 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 Namen der gewünschten Umgebungsvariablen.

  2. Angenommen, Sie haben Ihr Script 011_add-ssh-env-variables.sh genannt, fügen Sie Ihrem Image in Ihrem 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 Remoteanwendungen starten und das Anwendungsdisplay 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 Basis-Images der Cloud Workstations bereitgestellt wird, indem Sie X11Forwarding yes (um die X11-Weiterleitung zuzulassen) und AddressFamily inet (um sicherzustellen, dass nur IPv4 verwendet wird) anhängen. Weitere Informationen zu diesen Keywords finden Sie auf den OpenBSD-Webseiten zu AddressFamily und X11Forwarding.

Hier ist ein Beispiel für ein Dockerfile mit den erforderlichen Änderungen:

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 für Cloud Workstations in ein anderes Container-Image kopieren

Bei einem mehrstufigen Build können Sie mehrere FROM-Anweisungen in Ihrem Dockerfile verwenden. Für jede FROM-Anweisung kann eine andere Basis verwendet werden. Außerdem können Artefakte zwischen den Build-Phasen kopiert werden. 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 für 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 für ein Dockerfile, das Code OSS in das JetBrains IntelliJ Ultimate-Image kopiert. Sie können dann mit einer der folgenden 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, mit dem IDE-Erweiterungen in Code OSS für Cloud Workstations für die Java-Entwicklung vorinstalliert werden

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

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

Wenn Sie Erweiterungen vorinstallieren, werden sie als integrierte Erweiterungen betrachtet. Sie können diese Erweiterungen nicht aktualisieren und sie werden möglicherweise nicht im Abschnitt „Installiert“ im Marktplatz für Erweiterungen angezeigt. Sie können sie jedoch finden, 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:

/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 Marktplatz für Erweiterungen angezeigt und Sie können sie dort 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 in das Basis-Image installieren. Die Cloud Workstations-Basis-Images für JetBrains-Produkte enthalten die folgenden Scripts, die Ihnen helfen können:

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

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

Installationsscripts

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

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

Installationsskript für das Plug-in verwenden

Das plugin-installer.sh-Script 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 das das Plug-in installiert werden soll. Wenn keine Angabe gemacht wird, wird das Arbeitsverzeichnis verwendet.
  • CHECKSUM: Optionale SHA-256-Prüfsumme des angeforderten Plug-ins.
  • -f: Wenn angegeben, wird jedes vorhandene 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.

Wenn Sie beispielsweise die neueste Version des Dart-Plug-ins in IntelliJ installieren möchten, führen Sie den folgenden Befehl aus:

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 jetbrains-installer.sh-Script 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 neueste Version der IDE. Die Standardeinstellung ist latest.

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

jetbrains-installer.sh clion

Konfigurationsdateien der JetBrains-IDE anpassen

Wenn in der Workstation-Konfiguration ein dauerhaftes Basisverzeichnis angegeben ist, werden die Konfigurationsdateien $IDE.vmoptions und $IDE.properties in Cloud Workstations-Basis-Images mit JetBrains-IDEs automatisch beibehalten. 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 jedem JetBrains-Basis-Image. Dort wird beschrieben, wie dies standardmäßig in Cloud Workstations eingerichtet wird.

Basis-Docker-Image mit Cloud Code for IntelliJ erweitern

Im folgenden Dockerfile-Snippet wird ein Basis-Docker-Image um Cloud Code for IntelliJ erweitert, indem 8079 als erforderliche Plug-in-ID angegeben wird. Optional wird im Beispiel 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 für Cloud Workstations installieren

Weitere IDE-Erweiterungen finden Sie in der Open VSX Registry. Sie können die URL der .vsix-Datei auch finden, indem Sie die URL aus dem Link Herunterladen für eine beliebige Erweiterung kopieren.

Öffnen Sie die VSX-Seite für die Go-Spracherweiterung, auf der die Schaltfläche „Herunterladen“ angezeigt wird.

Wenn Sie den Marketplace für Erweiterungen auf einer Workstation öffnen, wird anstelle von Herunterladen die Option Installieren angezeigt.

Standard-Code OSS für Cloud Workstations-Einstellungen

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

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

Wenn Sie beispielsweise das Standardfarbdesign 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 auch die anderen Beispiele auf dieser Seite aktualisiert.

Ersetzen Sie Folgendes:

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

  • TARGET_IMAGE: Der Pfad zu Ihrem Image in Artifact Registry (oder Container Registry).

    TARGET_IMAGE kann beispielsweise auf einen Pfad zum Zielbild verweisen, der einem der folgenden ähnelt:

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

*.gcr.io/cloud-workstations-external/customimage:latest

    Ersetzen Sie * nach Bedarf durch den Namen der Region und alle zusätzlichen 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

Wir empfehlen und unterstützen Artifact Registry für das Hosten benutzerdefinierter Container-Images. Wenn Sie GitHub oder ein anderes öffentliches oder privates Repository verwenden, funktionieren Cloud Workstations möglicherweise nicht wie erwartet. Weitere Informationen finden Sie 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 Container-Portnummer

Wenn Sie beispielsweise LOCAL_PORT:CONTAINER_PORT durch 8080:80 ersetzen, wird Port 8080 lokal und Port 80 im Container verwendet.

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 zum Container herzustellen:

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

Benutzerdefiniertes Container-Image verwenden

Wenn Sie Ihr benutzerdefiniertes Container-Image verwenden möchten, nachdem Sie es lokal erstellt und getestet haben, können Sie es mit dem folgenden Befehl in die Artifact Registry (oder Container Registry) verschieben:

docker push TARGET_IMAGE

Sie können jetzt mit dem gerade erstellten und gepushten Container-Image eine Workstationkonfiguration 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 Containerausgabeprotokolle Ihrer laufenden Workstations an.

Sie sind für die Pflege und Aktualisierung benutzerdefinierter Pakete und Abhängigkeiten verantwortlich, die benutzerdefinierten Images hinzugefügt wurden.

Wenn Sie benutzerdefinierte Bilder erstellen, empfehlen wir Folgendes:

Nächste Schritte