Container-Images anpassen

Die vorkonfigurierte Basis-Images die von Cloud Workstations bereitgestellt werden, nur eine minimale Umgebung mit IDE, grundlegende Linux-Terminal- und Sprachtools sowie einen 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 verantwortlich für Verwalten und Aktualisieren von benutzerdefinierten Paketen und Abhängigkeiten, 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 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 unserem Liste der unterstützten Basis-Images zum Beispiel 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 von 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 Start führen Basis-Images unter /etc/workstation-startup.d/* folgende Dateien aus: lexikografische Reihenfolge zum Initialisieren der Workstationumgebung.

    Die Dateien und ihr Verhalten sind:

    • 000_configure-docker.sh: Konfiguriert Docker und führt es im .

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

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

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

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

  • Cloud Workstations speichert Docker-Images im Basisverzeichnis unter /home/.docker_data, damit die Bilder zwischen Sitzungen beibehalten werden.

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 Skripts in lexikografischer Reihenfolge ausgeführt werden, sollten Sie Stellen Sie den Skripts eine dreistellige Zahl voran, die größer als 200 ist.

Änderungen am Basisverzeichnis

Wenn die Workstationkonfiguration ein persistentes Basisverzeichnis angibt (dies ist das Standardverhalten), ein nichtflüchtiger Speicher, der das Basisverzeichnis wird zur Laufzeit dynamisch an den Container angehängt. Dabei werden Änderungen überschrieben, die beim Erstellen des Container-Images am Verzeichnis /home vorgenommen wurden.

Ändern Sie das Verzeichnis /home zur Containerlaufzeit, um die Aktualisierungen beizubehalten indem Sie im Verzeichnis /etc/workstation-startup.d ein Skript hinzufügen, oder durch Hinzufügen einer nutzerspezifischen Konfiguration im Verzeichnis /etc/profile.d. Sie können das Einrichtungsskript im Hintergrund ausführen, um den Vorgang zu beschleunigen. (fügen Sie am Ende des Befehls ein kaufmännisches Und & hinzu), um zu vermeiden, den Containerstart blockieren.

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. das Ablegen von Dateien in einem $HOME/.config-Verzeichnis
  • Nutzer erstellen

Nutzer erstellen und bearbeiten

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

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

Vorkonfigurierte sichere APT-Schlüssel aktualisieren

Die Basis-Images von Cloud Workstations sind mit einer Reihe von Tools vorinstalliert mit Secure APT aus verschiedenen Drittanbieter-Repositories. Im Rahmen der Installation werden öffentliche Schlüssel, die von den Repository-Inhabern bereitgestellt wurden, mit gpg importiert. und in einzelne Dateien unter /usr/share/keyrings/ platziert. 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 können Inhaber von Drittanbieter-Repositorys entscheiden, den öffentlichen Schlüssel zu ändern. wird verwendet, um die Integrität ihres Repositorys zu prüfen, was dazu führt, dass apt bei der Interaktion einen Fehler anzeigen. Um dieses potenzielle Problem zu beheben, können Sie /google/scripts/refresh-preinstalled-apt-keys.sh verwenden, ruft die neuesten Versionen der vorinstallierten öffentlichen Schlüssel ab und importiert sie noch einmal.

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 sudo Root-Zugriffsberechtigung in diesen Container. Um den Root-Zugriff auf den Docker-Container zu deaktivieren, legen Sie den Umgebungsvariable CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO auf true, wenn Sie die Workstationkonfiguration erstellen.

Um diese Umgebungsvariable beim Erstellen über die Google Cloud Console festzulegen Ihre Workstationkonfiguration aus, führen Sie die folgenden Schritte aus:

  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 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 einen blockierenden Prozess ausführen, wird gestartet.

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 auf der Workstation Konfiguration können Sie im Feld config.container.args eine blockieren können.

Wenn Sie Ihr eigenes Container-Image verwenden, beachten Sie Folgendes:

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

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

  • 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, dass du deine Standard-IDE oder deinen Webserver auf Port 80 ausführst.

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 ENTRYPOINT in Ihrem Dockerfile, um die Datei vollständig anzupassen. Container-Start.

Beispiele 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. Skript in /etc/workstation-startup.d/* erstellen, das ausgeführt wird nach 010_add-user.sh, 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ören die IDE in den vorkonfigurierten Basis-Images. SSH-Sitzungen sind jedoch nicht untergeordnete des Einstiegspunkts verarbeitet werden und nicht über diese Variablen festgelegt sind.

Zum Festlegen dieser Umgebungsvariablen in den SSH-Sitzungen richten Sie eine benutzerdefinierte Container-Image, das diese Umgebungsvariablen aus dem Einstiegspunktbefehl in die Datei /etc/environment ein.

Gehen Sie dazu folgendermaßen 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 die gewünschte Umgebungsvariable. Namen.

  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 aktiviert

Mit der X11-Weiterleitung können Sie Remote-Apps starten und diese weiterleiten auf einem lokalen Computer anzeigen.

Ändern Sie den OpenSSH-Daemon, um ein Container-Image zu erstellen, das die X11-Weiterleitung aktiviert Konfigurationsdatei (/etc/ssh/sshd_config), die von den Cloud Workstations-Basis-Images durch X11Forwarding yes (um die X11-Weiterleitung zuzulassen) und AddressFamily inet anfügen (um sicherzustellen, dass nur IPv4 verwendet wird). Weitere Informationen zu diesen Suchbegriffen finden Sie im OpenBSD-Web Seiten über 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 for Cloud Workstations in ein anderes Container-Image kopieren

Bei einem mehrstufigen Build können Sie mehrere FROM-Anweisungen verwenden im Dockerfile. 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. Anschließend können Sie mit 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 für Cloud Workstations für die Java-Entwicklung vorinstalliert

So erstellen Sie ein Container-Image, mit dem IDE-Erweiterungen vorinstalliert werden: Führen Sie die folgenden Befehle aus, um die Entwicklung von OSS für Cloud Workstations für Java zum Zeitpunkt der Build-Erstellung zu codieren:

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

Vorinstallierte Erweiterungen werden 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 Startskript verfügbar. Fügen Sie beispielsweise das folgende Startskript unter /etc/workstation-startup.d/120_install_extensions.sh:

/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 angezeigt und Sie können sie dort aktualisieren.

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

Beim Anpassen von Docker-Images für Workstationkonfigurationen können Sie JetBrains-IDEs und -Plug-ins wie z. B. Cloud Code for IntelliJ in das Basis-Image einfügen. Cloud Workstations-Basis-Images für JetBrains-Produkte umfassen Folgendes: Skripts für folgende Aufgaben:

  • 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 Skripts zum Zeitpunkt des Container-Builds auszuführen. Laufen vermeiden in einer bereits gestarteten Workstation.

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 verschoben wird installiert werden sollte. Wenn kein Wert angegeben ist, wird das Arbeitsverzeichnis verwendet.
  • CHECKSUM: Optionale SHA-256-Prüfsumme des angeforderten Plug-ins.
  • -f: Falls angegeben, werden vorhandene Plug-ins ü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 für IntelliJ hinzufügen möchten, verwenden Sie 8079 als PLUGIN_ID.

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

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: 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

JetBrains-IDE-Konfigurationsdateien 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 gespeichert. Wenn Sie den Standardspeicherort dieser Dateien überschreiben möchten, geben Sie Die Umgebungsvariable CLOUD_WORKSTATIONS_JETBRAINS_PERISTED_CONFIG_DIR

Weitere Informationen finden Sie unter /etc/workstation-startup.d/120_persist-jetbrains-configs.sh in beliebigen JetBrains-Basis-Image für den Lernprozess wie das in Cloud Workstations standardmäßig eingerichtet wird.

Basis-Docker-Image mit Cloud Code for IntelliJ erweitern

Das folgende Dockerfile-Snippet erweitert ein Basis-Docker-Image mit Cloud Code for IntelliJ, indem Sie 8079 als erforderliche Plug-in-ID angeben. 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 Datei .vsix auch ermitteln, indem Sie die URL aus der Link zum Herunterladen einer beliebigen Erweiterung.

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

Wenn Sie die öffnen Extension Marketplace von einer Workstation wird Installieren anstelle von Herunterladen angezeigt.

Standardcode-OSS-Einstellungen für Cloud Workstations

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

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

Wenn Sie beispielsweise das Standardfarbdesign auf „Dunkel“ setzen möchten, erweitern Sie die Basis Editorbild, unter dem das folgende Skript eingefügt wird /etc/workstation-startup.d/150_default-ide-color-theme.sh

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

Benutzerdefiniertes Container-Image erstellen

Detaillierte 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

Beachten Sie, dass das Ersetzen des Textes vor der bearbeiten Mit dem Symbol Bearbeiten werden 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: Pfad zum Image in Artifact Registry (oder Container Registry)

    Beispielsweise kann TARGET_IMAGE auf ein Zielbild verweisen. Pfad, der einem der folgenden Pfade ähnelt:

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

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

    Ersetzen Sie * bei Bedarf durch den Namen der Region und zusätzliche Kennzeichnungen.

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 den Browser herstellen, geben Sie -p 8080:80 an den docker run-Befehl weiter und öffnen Sie dann localhost:8080.
  • Wenn du eine Verbindung über SSH herstellen möchtest, musst du -p 2222:22 übergeben. in den Befehl docker run ein und führen Sie dann ssh user@localhost -p 2222 aus.

Benutzerdefiniertes Container-Image verwenden

So verwenden Sie Ihr benutzerdefiniertes Container-Image, nachdem Sie es lokal erstellt und getestet haben: Übertragen Sie Ihren Container per Push in Artifact Registry (oder Container Registry) mit folgenden Elementen: Befehl:

docker push TARGET_IMAGE

Sie können jetzt mit dem gerade erstellten und gepushten Container-Image eine Workstation-Konfiguration erstellen.

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

Probleme beheben

Informationen zum Ermitteln und Beheben von Problemen beim Ausführen des Container-Images finden Sie in der Containerausgabelogs von Ihren laufenden Workstations.

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

Wenn Sie benutzerdefinierte Images erstellen, empfehlen wir Folgendes:

Nächste Schritte