Container-Images anpassen

Die von Cloud Workstations bereitgestellten vorkonfigurierten Basis-Images enthalten nur eine minimale Umgebung mit IDE, einem einfachen Linux-Terminal, Sprach-Tools und 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.

Bei benutzerdefinierten 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 dafür verantwortlich, benutzerdefinierte Pakete und Abhängigkeiten, die benutzerdefinierten Images hinzugefügt wurden, zu verwalten und zu aktualisieren.

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 mit der Google Cloud CLI. Sie können Cloud Workstations oder den Cloud Shell-Editor verwenden, um diese Schritte auszuführen. Diese Tools sind dort vorinstalliert.

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

   Alternativ können Sie Ihr 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 definierte Struktur:

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

• Beim Start werden in Basis-Images Dateien unter /etc/workstation-startup.d/* in lexikografischer Reihenfolge ausgeführt, 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 die persistente Festplatte dynamisch an den Container angehängt wird, müssen Nutzer beim Start der Workstation und nicht im Dockerfile hinzugefügt werden.

  • 020_start-sshd.sh: Startet den sshd-Dienst 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 das Image einer Arbeitsstation nicht erweitern möchten, können Sie alternativ ein customize_environment-Skript in Ihrem Home-Verzeichnis erstellen.

Änderungen am Basisverzeichnis

Wenn in der Workstation-Konfiguration ein nichtflüchtiges Basisverzeichnis angegeben ist (Standardverhalten), wird ein nichtflüchtiger Speicher, der das Basisverzeichnis unterstützt, zur Laufzeit dynamisch an den Container angehängt. Bei diesem Prozess werden Änderungen überschrieben, die während des Erstellens des Container-Images am Verzeichnis /home 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 Konfiguration pro Nutzer im Verzeichnis /etc/profile.d hinzufügen. Um den Vorgang zu beschleunigen, können Sie das Einrichtungs-Script als Hintergrundprozess ausführen (fügen Sie am Ende des Befehls ein Und-Zeichen [&] hinzu), um zu vermeiden, dass der Containerstart blockiert wird.

Beispiele für Build-Zeit-Konfigurationen, die in die Containerlaufzeit verschoben werden sollten:

• Nutzerspezifische git-Konfiguration
• git-Repositories, die im 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 zur Laufzeit dynamisch an den Container angehängt wird, müssen Nutzer beim Start der Workstation und nicht im Dockerfile hinzugefügt werden. Wenn Sie Nutzer ändern oder zusätzliche Nutzer 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 sichere APT-Schlüssel aktualisieren

Auf Cloud Workstations-Basis-Images sind eine Reihe von Tools vorinstalliert, die über Secure APT aus verschiedenen Drittanbieter-Repositories bezogen wurden. Im Rahmen der Installation werden öffentliche Schlüssel, die von den Repository-Inhabern bereitgestellt werden, 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. So kann apt die Integrität eines bestimmten Repositorys bei der Interaktion damit überprüfen.

Gelegentlich ändern Drittanbieter den öffentlichen Schlüssel, der zur Validierung der Integrität ihres Repositorys verwendet wird. In diesem Fall wird in apt eine Fehlermeldung angezeigt, wenn Sie mit dem Repository interagieren. Um dieses potenzielle Problem zu beheben, können Sie /google/scripts/refresh-preinstalled-apt-keys.sh verwenden. Damit werden die neuesten Versionen der vorinstallierten öffentlichen Schlüssel abgerufen und neu importiert.

Installierte IDE-Versionen auflisten

Auf mehreren Cloud Workstations-Basis-Images ist eine IDE vorinstalliert. Das enthaltene /google/scripts/preinstalled-ide-versions.sh-Script listet den Namen und die Versionsinformationen der im Image installierten IDEs auf.

sudo-Root-Berechtigungen deaktivieren

Der Standardnutzer der Arbeitsstation hat sudo-Root-Zugriffsberechtigungen in diesen Containern. 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 über die Google Cloud -Konsole fest, wenn Sie Ihre Workstationkonfiguration erstellen:

1. Wenn Sie Ihre Workstationkonfiguration erstellen, füllen Sie die Konfiguration für „Grundlegende Informationen“ und „Maschinenkonfiguration“ aus.
2. Maximieren Sie im Dialogfeld Umgebung anpassen den Abschnitt 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 aus dem Docker-Container ausbrechen kann, kann er möglicherweise Root-Berechtigungen auf der zugrunde liegenden VM erhalten.

Anpassen ohne Bild zu erweitern

Alle Cloud Workstations-Basis-Images prüfen, ob sich unter /home/user/.workstation/customize_environment eine ausführbare Datei befindet. Falls ja, wird sie im Hintergrund als user ausgeführt. So können Sie beim Start beliebige Skripts oder Binärdateien ausführen. Anders als bei .profile oder .bashrc wird das Skript nur einmal beim Starten der Workstation ausgeführt und nicht bei jeder Shell-Anmeldung.

Da das customize_environment-Skript als user ausgeführt wird, müssen Sie die Berechtigungen beim Schreiben des Skripts 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ührungsprotokolle für customize_environment finden Sie im Container unter /var/log/customize_environment. Sie werden auch in die Container-Ausgabelogs geschrieben. Bei 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 die durch das Skript installierten Pakete bereits wenige Augenblicke nach dem Start der Workstation verfügbar sein.

Inaktivitätszeitüberschreitungen verhindern

Alle Cloud Workstations-Basis-Images enthalten ein vorinstalliertes Skript unter /google/scripts/keep_alive.sh. Dieses Skript sendet regelmäßig Keep-Alive-Nachrichten, die verhindern können, dass die Workstation aufgrund von Leerlauf-Timeouts heruntergefahren wird, wenn Sie Hintergrundprozesse ohne direkte Interaktion ausführen.

Eigenes Container-Image verwenden

Sie können auch Ihr eigenes Container-Image oder externe Container-Images verwenden, sofern sie Linux-basiert sind und beim Start des Containers ein blockierender Prozess ausgeführt wird.

Beim Einrichten des Dockerfile muss mit der ENTRYPOINT-Anweisung ein blockierender Prozess wie sleep infinity ausgeführt werden, damit der Container weiter ausgeführt wird und nicht sofort beendet wird. Alternativ können Sie in der Workstationkonfiguration das Feld config.container.args festlegen, um einen blockierenden Prozess anzugeben.

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

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

  Sie können sich die Skripts jedoch 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 standardmäßigen Basis-Image.

• 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 Workstation-Umgebung zu erstellen, haben Sie drei Möglichkeiten:

1. Aktualisieren Sie Dockerfile, um alle zusätzlichen statischen Assets hinzuzufügen, die Sie einfü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 Start des Containers automatisch in lexikografischer Reihenfolge ausgeführt. Sie können Ihrem Dateinamen also ein Präfix voranstellen, damit er zum richtigen Zeitpunkt beim Start der Workstation ausgeführt wird.
3. Überschreiben Sie ENTRYPOINT in Ihrem Dockerfile, um den Start Ihres Containers vollständig anzupassen.

Hinweis :Alle Nutzeränderungen müssen zur Laufzeit des Containers und nicht im Dockerfile vorgenommen werden. Das liegt daran, dass /home beim Start dynamisch in den Container eingebunden wird.

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 Nutzeranpassung

So passen Sie ein Container-Image an:

1. Erstellen Sie ein Skript 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.

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 Workstation-Konfigurations- oder Workstation-Ebene festgelegt sind, werden mithilfe des Einstiegspunktbefehls 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.

Um diese Umgebungsvariablen in den SSH-Sitzungen festzulegen, richten Sie ein benutzerdefiniertes Container-Image ein, das diese Umgebungsvariablen vom Entrypoint-Befehl des Containers an die Datei /etc/environment weiterleitet.

Gehen Sie dazu so vor:

1. Erstellen Sie ein Skript 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. 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 X11-Weiterleitung für SSH-Sitzungen ermöglicht

Mit X11-Forwarding können Sie Remoteanwendungen starten und die Anwendungsanzeige an einen lokalen Computer weiterleiten.

Wenn Sie ein Container-Image erstellen möchten, das X11-Weiterleitung ermöglicht, ändern Sie die Konfigurationsdatei des OpenSSH-Daemons (/etc/ssh/sshd_config), die von den Cloud Workstations-Basis-Images bereitgestellt wird, indem Sie X11Forwarding yes (um 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-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

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 damit Artefakte zwischen Build-Phasen kopiert werden. Wenn Sie Code OSS für 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 Skript /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 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, in dem IDE-Erweiterungen in Code OSS für Cloud Workstations für die Java-Entwicklung vorinstalliert sind

Führen Sie die folgenden Befehle aus, um ein Container-Image zu erstellen, in dem IDE-Erweiterungen für die Java-Entwicklung in Code OSS für Cloud Workstations zur Build-Zeit 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

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 @builtin suchen, um Ihre integrierten Erweiterungen zu finden.

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

Hinweis :Sie können Ihre VSIX-Dateien auch zur Build-Zeit herunterladen und zur Laufzeit verwenden, um den Schutz zu erhöhen 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. 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 Starten der Workstation auszuführen.

Installationsskripts

Wenn Sie die Quelldateien für die Skripts 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 entweder über JetBrains Gateway oder über SSH eine Verbindung zur Workstation her und suchen Sie dann im Stammverzeichnis nach den Skriptdateien im Verzeichnis installer-scripts.

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

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 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 jedes vorhandene Plug-in überschrieben.
• PLUGIN_ID: Die erforderliche numerische Plugin-ID vom JetBrains Marketplace. 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:

/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 jetbrains-installer.sh-Script verwendet die folgende Syntax:

jetbrains-installer.sh IDE [ pinned|latest ]

Ersetzen Sie Folgendes:

• IDE: Die JetBrains-IDE, die installiert werden soll. 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	Fahrer
  rider	Fahrer
  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:

/installer-scripts/jetbrains-installer.sh clion

Konfigurationsdateien für JetBrains-IDEs anpassen

Wenn in der Workstation-Konfiguration ein dauerhaftes Home-Verzeichnis 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 einem beliebigen JetBrains-Basis-Image. Dort wird beschrieben, wie Cloud Workstations dies standardmäßig einrichtet.

Docker-Basis-Image mit Cloud Code for IntelliJ erweitern

Das folgende Dockerfile-Snippet erweitert ein Basis-Docker-Image mit Cloud Code for IntelliJ, indem 8079 als erforderliche Plug-in-ID angegeben wird. 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 für Cloud Workstations installieren

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

Wenn Sie den Marketplace für Erweiterungen über eine Arbeitsstation öffnen, wird anstelle von Herunterladen die Option Installieren angezeigt.

Standardeinstellungen für Code OSS für Cloud Workstations

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

Wenn Sie in der Workstations-Konfiguration ein dauerhaftes Home-Verzeichnis 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 Skript 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 kann beispielsweise auf einen Zielbildpfad wie den folgenden verweisen:

  *.pkg.dev/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 aktualisieren, damit 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

Wir empfehlen und unterstützen Artifact Registry zum Hosten benutzerdefinierter Container-Images. 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 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 für 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 Ihren docker run-Befehl übergeben und dann localhost:8080 öffnen.
• Wenn Sie lieber über SSH eine Verbindung herstellen möchten, müssen Sie -p 2222:22 an Ihren 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 es mit dem folgenden Befehl in Artifact Registry:

docker push TARGET_IMAGE

Sie können jetzt eine Workstation-Konfiguration erstellen, indem Sie das Container-Image verwenden, das Sie gerade erstellt und übertragen haben.

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

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

Den Code debuggen

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

Empfohlen: Image-Pipeline schützen

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

Wenn Sie benutzerdefinierte Bilder erstellen, empfehlen wir Folgendes:

• Führen Sie ein Container-Scanning-Tool wie Artifact Analysis aus, um alle zusätzlichen Abhängigkeiten zu prüfen, die Sie hinzugefügt haben.

• Builds planen, um Images wöchentlich neu zu erstellen, oder das Neuerstellen von Container-Images automatisieren.

Nächste Schritte

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