Container-Images anpassen

Die von Cloud Workstations bereitgestellten vorkonfigurierten Basis-Images enthalten nur eine minimale Umgebung mit IDE, einfachen 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 auf vorinstallierte Tools und Abhängigkeiten erweitern und Automatisierungsscripts ausführen.

Für benutzerdefinierte Container-Images empfehlen wir, eine Pipeline einzurichten, die diese Images bei der Aktualisierung des Cloud Workstations-Basis-Images automatisch neu erstellt. Außerdem empfiehlt es sich, ein Container-Scantool wie Artifact Analysis auszuführen, um alle zusätzlichen Abhängigkeiten zu überprüfen, die Sie hinzugefügt haben. Sie sind für die Verwaltung und Aktualisierung von benutzerdefinierten Paketen und Abhängigkeiten verantwortlich, die benutzerdefinierten Images hinzugefügt wurden.

Hinweise

1. Sie benötigen eine Maschine mit Tools, um Container-Images wie Docker zu erstellen und Images über die Google Cloud CLI an Artifact Registry (oder Container Registry) zu übertragen. Sie können Cloud Workstations oder den Cloud Shell-Editor verwenden, um diese Schritte auszuführen, in denen dieses Tool vorinstalliert ist.

   Hinweis: Container Registry wurde verworfen und wird eingestellt. Organisationen, die Container Registry vor dem 8. Januar 2024 nicht verwendet haben, werden standardmäßig neue gcr.io-Repositories in Artifact Registry gehostet. Nach dem 15. Mai 2024 unterstützen Google Cloud-Projekte ohne vorherige Verwendung von Container Registry nur das Hosting und die Verwaltung von Images für die Domain gcr.io in Artifact Registry.

   Container Registry soll am 18. März 2025 eingestellt werden. Weitere Informationen zur Einstellung finden Sie unter Einstellung von Container Registry.

2. Wählen Sie aus unserer Liste der unterstützten Basis-Images das zu verwendende 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 in diesem Ordner einen Ordner wie CUSTOM_IMAGE_FOLDER und ein Dockerfile, um das ausgewählte Basis-Image zu erweitern, wie in den folgenden Beispielen gezeigt.

Basis-Image-Struktur von Cloud Workstations

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

• Die Basis-Image-Einstiegspunktdatei 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 Workstationumgebung zu initialisieren.

  Die Dateien und ihr Verhalten sehen so aus:

  • 000_configure-docker.sh: Konfiguriert Docker und führt es 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 sshd-Dienst 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 Images zwischen Sitzungen erhalten bleiben.

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

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

• Da Skripts in lexikografischer Reihenfolge ausgeführt werden, sollten Sie ihnen eine dreistellige Zahl größer als 200 voranstellen.

Basisverzeichnisänderungen

Wenn in der Workstationkonfiguration ein persistentes Basisverzeichnis angegeben ist (Standardverhalten), wird ein nichtflüchtiger Speicher zur Sicherung des Basisverzeichnisses zur Laufzeit dynamisch an den Container angehängt. Dieser Prozess überschreibt Änderungen, die zum Zeitpunkt des Container-Image-Builds am Verzeichnis /home vorgenommen wurden.

Damit Aktualisierungen beibehalten werden, müssen Sie das Verzeichnis /home zur Containerlaufzeit ändern. Fügen Sie dazu im Verzeichnis /etc/workstation-startup.d ein Skript ein oder fügen Sie eine nutzerspezifische Konfiguration im Verzeichnis /etc/profile.d hinzu. Um den Vorgang zu beschleunigen, können Sie das Einrichtungsskript als Hintergrundprozess ausführen (fügen Sie am Ende des Befehls das Und-Zeichen & hinzu), damit der Containerstart nicht blockiert wird.

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

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

Erstellen und Ändern von Nutzern

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, sollten Sie /etc/workstation-startup.d/010_add-user.sh aktualisieren oder ein eigenes Skript erstellen, das beim Start ausgeführt wird.

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

Vorkonfigurierte sichere APT-Schlüssel aktualisieren

Auf Basis-Images von Cloud Workstations ist eine Reihe von Tools vorinstalliert, die mithilfe von Secure APT aus verschiedenen Repositories von Drittanbietern abgerufen wurden. 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/ platziert. Auf diese Dateien wird in den entsprechenden list-Dateien unter /etc/apt/sources.list.d/ verwiesen. Dadurch kann apt bei der Interaktion mit einem bestimmten Repository die Integrität prüfen.

Gelegentlich können Inhaber von Drittanbieter-Repositories den öffentlichen Schlüssel zur Validierung der Integrität ihres Repositorys ändern. Dies führt dazu, dass apt bei der Interaktion mit dem Repository einen Fehler anzeigt. Dieses potenzielle Problem können Sie mit /google/scripts/refresh-preinstalled-apt-keys.sh beheben. Dieser ruft die neuesten Versionen vorinstallierter öffentlicher Schlüssel ab und importiert sie noch einmal.

Installierte IDE-Versionen auflisten

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

Root-Berechtigungen für sudo deaktivieren

Der Nutzer der Standardworkstation hat in diesen Containern die Root-Zugriffsberechtigungen sudo. Wenn Sie den Root-Zugriff auf den Docker-Container deaktivieren möchten, legen Sie beim Erstellen der Workstationkonfiguration die Umgebungsvariable CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO auf true fest.

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

1. Schließen Sie beim Erstellen der Workstationkonfiguration die grundlegenden Informationen und die Maschinenkonfiguration ab.
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.

Hinweis: Wenn ein Nutzer in der Lage ist, den Docker-Container aufzubrechen, kann er unter Umständen Root-Berechtigungen für die zugrunde liegende VM erhalten.

Eigenes Container-Image verwenden

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

Beim Einrichten des Dockerfiles muss die Anweisung ENTRYPOINT einen blockierenden Prozess wie sleep infinity ausführen, damit der Container weiter ausgeführt wird, anstatt ihn sofort zu beenden. Alternativ können Sie in der Workstationkonfiguration das Feld config.container.args festlegen, um einen Blockierungsprozess anzugeben.

Beachten Sie Folgendes, wenn Sie ein eigenes Container-Image verwenden:

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

  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 die Funktion der einzelnen Skripts an.

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

• Wir empfehlen, Ihre Standard-IDE oder Ihren 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 Workstationumgebung zu erstellen, haben Sie drei Möglichkeiten:

1. Aktualisieren Sie Dockerfile, um weitere statische Assets hinzuzufügen, die Sie hinzufügen möchten.
2. Fügen Sie unter /etc/workstation-startup.d/ weitere ausführbare Dateien hinzu, um den laufenden Container anzupassen. Dateien in diesem Verzeichnis werden beim Containerstart automatisch in lexikografischer Reihenfolge ausgeführt. Sie können dem Dateinamen also ein Präfix voranstellen, damit er beim Start der Workstation zum richtigen Zeitpunkt ausgeführt wird.
3. Überschreiben Sie ENTRYPOINT im Dockerfile, um den Containerstart vollständig anzupassen.

Hinweis: Alle Nutzeränderungen müssen zur Containerlaufzeit und nicht im Dockerfile vorgenommen werden. Das liegt daran, dass /home beim Start dynamisch im Container bereitgestellt wird.

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 Nutzeranpassung

So passen Sie ein Container-Image an:

1. Erstellen Sie ein Script in /etc/workstation-startup.d/*, 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. Wenn Sie Ihr Skript 011_customize-user.sh genannt haben, fügen Sie dem 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 Workstationkonfigurations- oder Workstationebene festgelegt sind, werden mit dem Befehl „Einstiegspunkt“ an direkte Unterprozesse übergeben. Dies gilt auch für die IDE in den vorkonfigurierten Basis-Images. SSH-Sitzungen sind jedoch keine untergeordneten Prozesse des Einstiegspunkts und für sie sind diese benutzerdefinierten Umgebungsvariablen nicht festgelegt.

Zum Festlegen dieser Umgebungsvariablen in den SSH-Sitzungen richten Sie ein benutzerdefiniertes Container-Image ein, das diese Umgebungsvariablen vom Einstiegspunktbefehl des Containers an die Datei /etc/environment weiterleitet.

Gehen Sie dazu folgendermaßen vor:

1. Erstellen Sie ein Script in /etc/workstation-startup.d/*, 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. Wenn Sie Ihr Skript 011_add-ssh-env-variables.sh genannt haben, fügen Sie dem 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 aktiviert

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

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

Hier sehen Sie ein Beispiel-Dockerfile, in dem die erforderlichen Änderungen vorgenommen werden:

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

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

Führen Sie die folgenden Befehle aus, um ein Container-Image zu erstellen, das bei der Build-Erstellung IDE-Erweiterungen in Code OSS for Cloud Workstations for Java 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

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

Alternativ können Sie ein Startskript ausführen, um Erweiterungen beim Start zu installieren. 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

Mit dieser Methode wird die Erweiterung in im Extensions Marketplace angezeigt und kann von dort aus aktualisiert werden.

Hinweis: Sie können Ihre VSIX-Dateien auch zum Zeitpunkt der Build-Erstellung vorab herunterladen und zur Laufzeit verwenden, um zusätzlichen Schutz zu bieten und die Startleistung zu verbessern.

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 umfassen 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, mit einem Startskript aufzurufen oder nach dem Start der Workstation auszuführen.

Installationsskripts

Wenn Sie sich die Quelldateien für die Skripts jetbrains-installer.sh und plugin-installer.sh ansehen möchten, starten Sie eine Workstation mit einer Workstationkonfiguration, die eines der vordefinierten Images von JetBrains verwendet, stellen Sie entweder über JetBrains Gateway oder SSH eine Verbindung zur Workstation her und durchsuchen Sie dann die Skriptdateien im Verzeichnis installer-scripts, das sich im Stammverzeichnis befindet.

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

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 ist das optionale Verzeichnis, in dem das Plug-in installiert werden soll. Wenn kein Wert 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-Kennung aus dem JetBrains Marketplace. Wenn Sie beispielsweise Dart hinzufügen möchten, verwenden Sie 6351 als PLUGIN_ID. Verwenden Sie 8079 als PLUGIN_ID, um Cloud Code for IntelliJ hinzuzufügen.

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: 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 des Clion zu installieren:

jetbrains-installer.sh clion

Konfigurationsdateien für JetBrains-IDE anpassen

Wenn in der Workstationkonfiguration ein persistentes Basisverzeichnis angegeben ist, speichern Cloud Workstations-Basis-Images mit JetBrains-IDEs automatisch die Konfigurationsdateien $IDE.vmoptions und $IDE.properties. 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, um zu erfahren, wie Cloud Workstations dies standardmäßig einrichtet.

Docker-Basis-Image mit Cloud Code for IntelliJ erweitern

Das folgende Dockerfile-Snippet erweitert ein Docker-Basis-Image mit Cloud Code for IntelliJ, indem 8079 als erforderliche Plug-in-ID angegeben wird. Im Beispiel wird 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 Open VSX Registry. Sie können die URL der Datei .vsix auch ermitteln, indem Sie die URL aus dem Downloadlink der jeweiligen Erweiterung kopieren.

Wenn Sie den Extensions Marketplace auf einer Workstation öffnen, wird Installieren anstelle von Herunterladen 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 Workstationkonfiguration ein persistentes Basisverzeichnis angeben, können Sie Standardeinstellungen für Code OSS für Cloud Workstations konfigurieren. Dazu fügen Sie ein Startskript hinzu, das Einstellungen in $HOME/.codeoss-cloudworkstations/data/Machine/settings.json schreibt.

Wenn Sie beispielsweise „Dunkel“ als Standardfarbschema festlegen möchten, erweitern Sie das Basiseditorbild um das folgende Skript unter /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

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 ist der Pfad zu dem Ordner, den Sie zum Speichern Ihres benutzerdefinierten Images erstellt haben.

• TARGET_IMAGE ist der Pfad zu Ihrem Image in Artifact Registry (oder Container Registry).

  Beispielsweise kann TARGET_IMAGE auf einen Zielbildpfad verweisen, der einem der folgenden Pfade ä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 Kennzeichnungen.

  Hinweis: Container Registry wurde verworfen und wird eingestellt. Organisationen, die Container Registry vor dem 8. Januar 2024 nicht verwendet haben, werden standardmäßig neue gcr.io-Repositories in Artifact Registry gehostet. Nach dem 15. Mai 2024 unterstützen Google Cloud-Projekte ohne vorherige Verwendung von Container Registry nur das Hosting und die Verwaltung von Images für die Domain gcr.io in Artifact Registry.

  Container Registry soll am 18. März 2025 eingestellt werden. Weitere Informationen zur Einstellung finden Sie unter Einstellung von Container Registry.

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:

• Docker-Repository mit Artifact Registry erstellen
• Namenskonventionen für Repository- und Image-Namen.

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, funktioniert 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 Container-Portnummer

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 Basiseditor-Image von Cloud Workstations erweitern, führen Sie den Befehl docker aus und testen Sie dann das Workstation-Image. Stellen Sie dazu über Ihren lokalen Browser eine Verbindung zur Workstation her oder führen Sie ssh aus, um eine Verbindung zu Ihrem Container herzustellen:

• Wenn Sie eine Verbindung über Ihren Browser herstellen, müssen Sie -p 8080:80 an den docker run-Befehl übergeben und dann localhost:8080 öffnen.
• Wenn Sie eine Verbindung über SSH herstellen möchten, müssen Sie -p 2222:22 an den docker run-Befehl ü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 den Container mit dem folgenden Befehl per Push an Artifact Registry (oder Container Registry):

docker push TARGET_IMAGE

Sie können jetzt mit dem gerade erstellten und per Push übertragenen Container-Image eine Workstationkonfiguration erstellen.

Wichtig: Wenn das Image in einem privaten Repository gehostet wird, muss in Ihrer Workstationkonfiguration auch ein Dienstkonto angegeben sein, das Pull-Berechtigungen für das Repository hat.

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

Probleme beheben

Prüfen Sie die Containerausgabelogs Ihrer laufenden Workstations, um Probleme beim Ausführen des Container-Images zu ermitteln und zu beheben.

Empfohlen: Image-Pipeline sichern

Sie sind dafür verantwortlich, benutzerdefinierte Pakete und Abhängigkeiten, die benutzerdefinierten Images hinzugefügt wurden, zu verwalten und zu aktualisieren.

Wenn Sie benutzerdefinierte Images erstellen, empfehlen wir Folgendes:

• Schützen Sie Ihre Image-Pipeline. Erstellen Sie dazu diese Images automatisch neu, wenn das Cloud Workstations-Basis-Image aktualisiert wird.

• Führen Sie ein Container-Scantool wie Artifact Analysis aus, um alle zusätzlich hinzugefügten Abhängigkeiten zu überprüfen.

• Planen Sie Builds, um Images wöchentlich neu zu erstellen, oder informieren Sie sich, wie Sie die Neuerstellung von Container-Images automatisieren.

Nächste Schritte

• Automatisieren Sie die Neuerstellung von Container-Images, um Basis-Image-Updates mit Cloud Build und Cloud Scheduler zu synchronisieren.
• Best Practices für die Sicherheit einrichten
• Weitere Informationen zur Artefaktanalyse