Personnaliser les images de conteneurs

Les images de base préconfigurées fournies par Cloud Workstations ne contiennent qu'un environnement minimal avec un IDE, un terminal Linux de base, des outils de langage et un serveur sshd. Pour accélérer la configuration de l'environnement de cas d'utilisation de développement spécifiques, vous pouvez créer des images de conteneurs personnalisées qui étendent ces images de base pour préinstaller des outils et des dépendances, et exécuter des scripts d'automatisation.

Pour les images de conteneurs personnalisées, nous vous recommandons de configurer un pipeline pour recompiler automatiquement ces images lorsque l'image de base Cloud Workstations est mise à jour, en plus d'exécuter un outil d'analyse de conteneurs tel qu'Artifact Analysis pour inspecter toutes les dépendances supplémentaires que vous avez ajoutées. Vous êtes responsable de la maintenance et de la mise à jour des packages et dépendances personnalisés ajoutés aux images personnalisées.

Avant de commencer

  1. Vous avez besoin d'une machine dotée d'outils permettant de créer des images de conteneurs, tels que Docker, et de transférer des images vers Artifact Registry à l'aide de la Google Cloud CLI. Pour effectuer ces étapes, vous pouvez utiliser Cloud Workstations ou l'éditeur Cloud Shell, sur lesquels ces outils sont préinstallés.

  2. Sélectionnez l'image de base que vous souhaitez utiliser dans notre liste d'images de base compatibles, par exemple us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest.

    Vous pouvez également utiliser votre propre image de conteneur ou des images de conteneur externes en suivant les instructions de la section Utiliser votre propre image de conteneur.

  3. Créez un dossier tel que CUSTOM_IMAGE_FOLDER et un fichier Dockerfile dans ce dossier, en étendant l'image de base sélectionnée, comme illustré dans les exemples suivants.

Structure de l'image de base Cloud Workstations

Les images de base Cloud Workstations partagent la structure définie suivante :

  • Le fichier de point d'entrée de l'image de base est défini sur /google/scripts/entrypoint.sh.

  • Au démarrage, les images de base exécutent les fichiers sous /etc/workstation-startup.d/* dans l'ordre lexicographique pour initialiser l'environnement de la station de travail.

    Les fichiers et leur comportement sont les suivants :

    • 000_configure-docker.sh : configure et exécute Docker dans la station de travail.

    • 010_add-user.sh : crée l'utilisateur par défaut dans Cloud Workstations.

      Étant donné que le disque persistant est associé de manière dynamique au conteneur, les utilisateurs doivent être ajoutés au démarrage du poste de travail, et non dans le Dockerfile.

    • 020_start-sshd.sh : démarre le service sshd dans le conteneur.

    • 030_customize-environment.sh : exécute /home/user/.workstation/customize_environment en tant que user.

    • 110_start-$IDE.sh : démarre l'IDE pour l'image.

  • Cloud Workstations stocke les images Docker dans le répertoire d'accueil à l'emplacement /home/.docker_data afin qu'elles soient conservées entre les sessions.

Pour ajouter des fonctionnalités supplémentaires lors du démarrage de la station de travail, ajoutez vos scripts dans le répertoire /etc/workstation-startup.d/ :

  • Par défaut, les scripts de ce répertoire s'exécutent en tant qu'utilisateur racine. Pour exécuter les scripts en tant qu'autre utilisateur, utilisez la commande runuser.

  • Étant donné que les scripts s'exécutent dans l'ordre lexicographique, nous vous recommandons de faire précéder les scripts d'un nombre à trois chiffres supérieur à 200.

Si vous ne souhaitez pas étendre une image de station de travail, vous pouvez également créer un script customize_environment dans votre répertoire d'accueil.

Modifications du répertoire d'accueil

Lorsque la configuration de la station de travail spécifie un répertoire d'accueil persistant (comportement par défaut), un disque persistant sauvegardant le répertoire d'accueil est associé de manière dynamique au conteneur au moment de l'exécution. Ce processus écrase les modifications apportées au répertoire /home au moment de la compilation de l'image de conteneur.

Pour conserver les mises à jour, modifiez le répertoire /home au moment de l'exécution du conteneur en ajoutant un script dans le répertoire /etc/workstation-startup.d ou en ajoutant une configuration par utilisateur dans le répertoire /etc/profile.d. Pour accélérer le processus, envisagez d'exécuter le script de configuration en tant que processus en arrière-plan (ajoutez une esperluette, &, à la fin de la commande) pour éviter de bloquer le démarrage du conteneur.

Voici quelques exemples de configuration au moment de la compilation qui doivent être déplacés vers l'environnement d'exécution du conteneur :

  • Configuration git par utilisateur
  • git dépôt cloné dans le répertoire d'accueil
  • Configuration directe de l'utilisateur, par exemple en plaçant des fichiers dans un répertoire $HOME/.config
  • Création de compte utilisateur

Création et modification d'utilisateurs

Étant donné que le disque persistant est associé de manière dynamique au conteneur au moment de l'exécution, les utilisateurs doivent être ajoutés au démarrage du poste de travail, et non dans le Dockerfile. Pour modifier ou créer des utilisateurs supplémentaires, nous vous recommandons de mettre à jour /etc/workstation-startup.d/010_add-user.sh ou de créer votre propre script qui s'exécute au démarrage.

Vous pouvez également modifier le profil Bash par défaut des utilisateurs en mettant à jour les fichiers dans /etc/profile.d.

Mettre à jour les clés APT sécurisées préconfigurées

Les images de base Cloud Workstations sont préinstallées avec un certain nombre d'outils obtenus à partir de différents dépôts tiers à l'aide de Secure APT. Lors du processus d'installation, les clés publiques fournies par les propriétaires du dépôt sont importées à l'aide de gpg et placées dans des fichiers individuels sous /usr/share/keyrings/. Ces fichiers sont référencés à partir des fichiers list correspondants sous /etc/apt/sources.list.d/. Cela permet à apt de vérifier l'intégrité d'un dépôt donné lorsqu'il interagit avec lui.

Il peut arriver que les propriétaires de dépôts tiers décident de modifier la clé publique utilisée pour valider l'intégrité de leur dépôt, ce qui entraîne l'affichage d'une erreur par apt lors de l'interaction avec celui-ci. Pour résoudre ce problème potentiel, vous pouvez utiliser /google/scripts/refresh-preinstalled-apt-keys.sh, qui obtient les dernières versions des clés publiques préinstallées et les réimporte.

Vous pouvez également exécuter ce script directement dans votre Dockerfile personnalisé avant d'exécuter apt-get update :

# Refresh the preinstalled APT keys
RUN /google/scripts/refresh-preinstalled-apt-keys.sh

RUN apt-get update

Lister les versions d'IDE installées

Plusieurs images de base Cloud Workstations sont préinstallées avec un IDE. Pour plus de commodité, consultez le script /google/scripts/preinstalled-ide-versions.sh inclus, qui répertorie le nom et les informations de version des IDE installés dans l'image.

Désactiver les droits racine sudo

L'utilisateur de la station de travail par défaut dispose de droits d'accès racine sudo dans ces conteneurs. Pour désactiver l'accès racine au conteneur Docker, définissez la variable d'environnement CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO sur true lors de la création de la configuration de la station de travail.

Pour définir cette variable d'environnement via la console Google Cloud lors de la création de votre configuration de station de travail, procédez comme suit :

  1. Lorsque vous créez votre configuration de station de travail, renseignez les informations de base et la configuration de la machine.
  2. Dans la boîte de dialogue Personnalisation de l'environnement, développez la section Options avancées des conteneurs, puis sélectionnez Variables d'environnement.
  3. Cliquez sur addAjouter une variable.
  4. Saisissez CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO et true comme valeur.

Personnaliser sans étendre une image

Pour plus de commodité, toutes les images de base Cloud Workstations vérifient la présence d'un fichier exécutable situé dans /home/user/.workstation/customize_environment et, s'il existe, l'exécutent en arrière-plan en tant que user. Cela vous permet d'exécuter n'importe quel script ou binaire au démarrage. Contrairement à .profile ou .bashrc, le script ne s'exécute qu'une seule fois au démarrage de la station de travail, et non une fois pour chaque connexion au shell.

Étant donné que le script customize_environment s'exécute en tant que user, veillez à mettre à jour les autorisations si nécessaire lors de l'écriture de votre script. Par exemple, si vous souhaitez installer Emacs à chaque démarrage de votre station de travail, le contenu de customize_environment peut ressembler à ceci :

#!/bin/bash
sudo apt-get update
sudo apt-get install -y emacs

Les journaux d'exécution de customize_environment se trouvent dans le conteneur à l'emplacement /var/log/customize_environment et sont également écrits dans les journaux de sortie du conteneur. Une fois l'exécution de customize_environment réussie, un fichier est créé dans /var/run/customize_environment_done. Étant donné que customize_environment s'exécute en parallèle du démarrage de la station de travail, les packages installés par le script peuvent être disponibles quelques instants après le démarrage de votre station de travail.

Empêcher les délais d'inactivité

Pour plus de commodité, toutes les images de base Cloud Workstations incluent un script préinstallé sur /google/scripts/keep_alive.sh. Ce script envoie régulièrement des messages de persistance, ce qui peut empêcher l'arrêt de la station de travail en raison de délais d'inactivité lorsque vous exécutez des processus en arrière-plan sans interaction directe.

Éviter les délais d'inactivité avec les agents IA

De plus, les images de base Cloud Workstations incluent des exemples de scripts de configuration d'agent sous /google/samples/agents/keepalive/. Ces exemples de configuration vous permettent de configurer des agents de codage IA (tels que Claude Code et Antigravity CLI) dans la station de travail pour la maintenir automatiquement active pendant qu'ils travaillent activement sur des tâches. Lorsque l'agent termine ses tâches ou s'interrompt pour attendre une entrée utilisateur, le script cesse d'envoyer des messages de persistance, ce qui permet à la station de travail d'expirer en raison de l'inactivité. Ces configurations fonctionnent mieux lorsque la configuration de la station de travail est définie pour utiliser la suspension de la station de travail (idleAction défini sur SUSPEND), ce qui permet à la station de travail d'enregistrer l'état de la mémoire et de reprendre l'activité de manière fluide lorsque vous revenez.

Pour en savoir plus sur la configuration des workflows assistés par agent et des hooks de persistance, consultez Développement optimisé pour les agents.

Utiliser votre propre image de conteneur

Vous pouvez également utiliser votre propre image de conteneur ou des images de conteneur externes, à condition qu'elles soient basées sur Linux et qu'elles exécutent un processus de blocage au démarrage du conteneur.

Lors de la configuration du fichier Dockerfile, l'instruction ENTRYPOINT doit exécuter un processus de blocage tel que sleep infinity afin que le conteneur continue de s'exécuter au lieu de se fermer immédiatement. Vous pouvez également définir le champ config.container.args dans la configuration de la station de travail pour spécifier un processus bloquant.

Lorsque vous utilisez votre propre image de conteneur, tenez compte des points suivants :

  • Cloud Workstations ne nécessite pas de scripts supplémentaires de l'image de base Cloud Workstations.

    Vous pouvez toutefois consulter les scripts du répertoire /etc/workstation-startup.d/ dans un conteneur exécutant l'image de base Cloud Workstations. Les noms de fichiers indiquent ce que fait chaque script.

  • Nous vous recommandons d'exécuter un serveur SSH dans le conteneur. Consultez /etc/workstation-startup.d/020_start-sshd.sh dans l'image de base par défaut pour découvrir comment Cloud Workstations configure cela par défaut.

  • Nous vous recommandons d'exécuter votre IDE ou votre serveur Web par défaut sur le port 80.

Google Cloud fournit des images de base standards que vous pouvez utiliser pour créer une image de conteneur entièrement personnalisée.

Étendre les images de base Cloud Workstations

Lorsque vous étendez une image de base Cloud Workstations pour créer une image personnalisée pour votre environnement de station de travail, vous pouvez adopter trois approches :

  1. Mettez à jour votre Dockerfile pour inclure tous les éléments statiques supplémentaires que vous souhaitez ajouter.
  2. Ajoutez des fichiers exécutables supplémentaires sous /etc/workstation-startup.d/ pour personnaliser le conteneur en cours d'exécution. Les fichiers de ce répertoire s'exécutent automatiquement dans l'ordre lexicographique au démarrage du conteneur. Vous pouvez donc ajouter un préfixe à votre nom de fichier pour l'exécuter au moment approprié lors du démarrage de la station de travail.
  3. Remplacez ENTRYPOINT dans votre Dockerfile pour personnaliser entièrement le démarrage de votre conteneur.

Exemples de fichiers Dockerfile personnalisés

Cette section fournit des exemples de scénarios et des instructions pour créer vos propres fichiers Dockerfile.

Image de conteneur avec emacs préinstallé

Pour créer une image de conteneur avec emacs préinstallé, exécutez les commandes suivantes :

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

RUN sudo apt update
RUN sudo apt install -y emacs

Image de conteneur avec personnalisation de l'utilisateur

Pour personnaliser une image de conteneur, procédez comme suit :

  1. Créez un script dans /etc/workstation-startup.d/* qui s'exécute après 010_add-user.sh, par exemple 011_customize-user.sh :

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

    Remplacez $GROUP par le nom du nouveau groupe et $USERNAME par le nom d'utilisateur de l'utilisateur.

  2. En supposant que vous avez nommé votre script 011_customize-user.sh, ajoutez ce qui suit à votre image dans votre Dockerfile et rendez-le exécutable :

    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

Image de conteneur qui définit des variables d'environnement de conteneur dans les sessions SSH

Les variables d'environnement définies au niveau de la configuration de la station de travail ou de la station de travail sont transmises aux sous-processus directs à l'aide de la commande de point d'entrée. Cela inclut l'IDE dans les images de base préconfigurées. Cependant, les sessions SSH ne sont pas des processus enfants du point d'entrée et ne disposent pas de ces variables d'environnement personnalisées.

Pour définir ces variables d'environnement dans les sessions SSH, configurez une image de conteneur personnalisée qui transmet ces variables d'environnement de la commande de point d'entrée du conteneur au fichier /etc/environment.

Pour ce faire, procédez comme suit :

  1. Créez un script dans /etc/workstation-startup.d/* qui s'exécute après 010_add-user.sh, par exemple 011_add-ssh-env-variables.sh :

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

    Remplacez CUSTOM_ENV_VAR par le nom de la variable d'environnement souhaité.

  2. En supposant que vous avez nommé votre script 011_add-ssh-env-variables.sh, ajoutez ce qui suit à votre image dans votre Dockerfile et rendez-le exécutable :

    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

Image de conteneur qui active le transfert X11 pour les sessions SSH

Le transfert X11 vous permet de démarrer des applications distantes et de transférer l'affichage de l'application vers une machine locale.

Pour créer une image de conteneur qui permet le transfert X11, modifiez le fichier de configuration du daemon OpenSSH (/etc/ssh/sshd_config) fourni par les images de base Cloud Workstations en ajoutant X11Forwarding yes (pour autoriser le transfert X11) et AddressFamily inet (pour vous assurer que seul IPv4 est utilisé). Pour en savoir plus sur ces mots clés, consultez les pages Web OpenBSD sur AddressFamily et X11Forwarding.

Voici un exemple de fichier Dockerfile qui apporte les modifications nécessaires :

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

Copier Code OSS pour Cloud Workstations dans une autre image de conteneur

Une compilation multi-étapes vous permet d'utiliser plusieurs instructions FROM dans votre Dockerfile. Chaque instruction FROM peut utiliser une base différente et permet de copier des artefacts entre les étapes de compilation. Pour ajouter Code OSS pour Cloud Workstations à une autre image de conteneur, utilisez une compilation en plusieurs étapes pour copier le dossier d'application /opt/code-oss dans votre image. Si vous souhaitez lancer Code OSS pour Cloud Workstations au démarrage du conteneur, copiez également le script /etc/workstation-startup.d/110_start-code-oss.sh dans votre conteneur.

Voici un exemple de fichier Dockerfile qui copie Code OSS dans l'image JetBrains IntelliJ Ultimate. Vous pouvez ensuite interagir avec l'un ou l'autre des IDE :

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"]

Image de conteneur qui préinstalle les extensions d'IDE dans Code OSS pour Cloud Workstations pour le développement Java

Pour créer une image de conteneur qui préinstalle les extensions d'IDE dans Code OSS pour Cloud Workstations pour le développement Java au moment de la compilation, exécutez les commandes suivantes :

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/

Si vous préinstallez des extensions, elles sont considérées comme des extensions intégrées. Vous ne pourrez pas mettre à jour ces extensions, et elles n'apparaîtront peut-être pas dans la section "Installées" de l'Extensions Marketplace . Toutefois, vous pouvez trouver vos extensions intégrées en recherchant @builtin.

Pour installer des extensions au démarrage, vous pouvez également exécuter un script de démarrage. Par exemple, incluez le script de démarrage suivant sous /etc/workstation-startup.d/120_install_extensions.sh :

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

Avec cette méthode, l'extension apparaît sur l'Extensions Marketplace, et vous pouvez la mettre à jour à partir de là.

Installer des IDE et des plug-ins JetBrains dans des images de base

Lorsque vous personnalisez des images Docker pour les configurations de stations de travail, vous pouvez installer des IDE et des plug-ins JetBrains, tels que Cloud Code pour IntelliJ, dans l'image de base. Les images de base Cloud Workstations pour les produits JetBrains incluent les scripts suivants pour vous aider :

  • jetbrains-installer.sh : installer les IDE JetBrains
  • plugin-installer.sh : installez des plug-ins, tels que Cloud Code pour IntelliJ.

Utilisez ces scripts si nécessaire pour personnaliser l'image de base, les appeler avec un script de démarrage ou les exécuter après le démarrage de la station de travail.

Scripts d'installation

Pour afficher les fichiers sources des scripts jetbrains-installer.sh et plugin-installer.sh, démarrez une station de travail à l'aide d'une configuration de station de travail qui utilise l'une des images prédéfinies JetBrains, connectez-vous à la station de travail via JetBrains Gateway ou SSH, puis parcourez les fichiers de script dans le répertoire installer-scripts, situé dans le répertoire racine.

Nous vous recommandons d'exécuter ces scripts au moment de la compilation du conteneur. Évitez de les exécuter dans une station de travail déjà démarrée.

Utiliser le script d'installation du plug-in

Le script plugin-installer.sh utilise la syntaxe suivante :

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

Remplacez les éléments suivants :

  • VERSION : numéro de version facultatif du plug-in à installer.
  • DESTINATION-DIRECTORY : répertoire facultatif dans lequel le plug-in doit être installé. Si aucune valeur n'est spécifiée, le répertoire de travail est utilisé.
  • CHECKSUM : somme de contrôle SHA-256 facultative du plug-in demandé.
  • -f : si spécifié, tout plug-in existant sera écrasé.
  • PLUGIN_ID : identifiant numérique obligatoire du plug-in sur la place de marché JetBrains. Par exemple, pour ajouter Dart, utilisez 6351 comme PLUGIN_ID. Pour ajouter Cloud Code pour IntelliJ, utilisez 8079 comme PLUGIN_ID.

Par exemple, pour installer la dernière version du plug-in Dart dans IntelliJ, exécutez la commande suivante :

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

Utiliser le script d'installation JetBrains

Nous vous recommandons d'utiliser le script d'installation JetBrains lorsque vous étendez une image de base préconfigurée pour les IDE JetBrains.

Le script jetbrains-installer.sh utilise la syntaxe suivante :

jetbrains-installer.sh IDE [ pinned|latest ]

Remplacez les éléments suivants :

  • IDE : IDE JetBrains à installer. Vous devez utiliser l'une des abréviations d'IDE suivantes :

    IDE Produit installé
    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 : facultatif. Utilisez la version épinglée ou la dernière version de l'IDE. La valeur par défaut est latest.

Par exemple, pour installer la dernière version de Clion, exécutez la commande suivante :

/installer-scripts/jetbrains-installer.sh clion

Personnaliser les fichiers de configuration des IDE JetBrains

Si un répertoire d'accueil persistant est spécifié dans la configuration des stations de travail, les images de base Cloud Workstations avec les IDE JetBrains conservent automatiquement les fichiers de configuration $IDE.vmoptions et $IDE.properties. Pour remplacer l'emplacement par défaut de ces fichiers, spécifiez la variable d'environnement CLOUD_WORKSTATIONS_JETBRAINS_PERISTED_CONFIG_DIR.

Pour en savoir plus, consultez /etc/workstation-startup.d/120_persist-jetbrains-configs.sh dans n'importe quelle image de base JetBrains pour découvrir comment Cloud Workstations configure cela par défaut.

Étendre une image Docker de base avec Cloud Code pour IntelliJ

L'extrait de Dockerfile suivant étend une image Docker de base avec Cloud Code pour IntelliJ en incluant 8079 comme identifiant de plug-in requis. L'exemple spécifie également, de manière facultative, version 22.9.3-222 comme numéro de version, /opt/ideaIU/plugins/ comme répertoire de destination et 89628279ed9042c526a81facc09bf53f8fb8b83b4595b0d329d94c1611e0c379 comme somme de contrôle :

...
# 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
...

Installer des extensions d'IDE supplémentaires dans Code OSS pour Cloud Workstations

Vous trouverez d'autres extensions d'IDE dans le registre Open VSX. Vous pouvez également trouver l'URL du fichier .vsix en copiant l'URL du lien Télécharger pour n'importe quelle extension.

Page Open VSX de l'extension du langage Go, qui affiche le bouton de téléchargement.

Si vous ouvrez l'Extensions Marketplace depuis un poste de travail, l'option Installer s'affiche à la place de Télécharger.

Paramètres Code OSS par défaut pour Cloud Workstations

Pour en savoir plus sur le stockage des paramètres dans Code OSS pour Cloud Workstations, consultez Personnaliser les paramètres.

Si vous spécifiez un répertoire d'accueil persistant dans la configuration des stations de travail, vous pouvez configurer les paramètres par défaut de Code OSS pour Cloud Workstations en ajoutant un script de démarrage qui écrit les paramètres dans $HOME/.codeoss-cloudworkstations/data/Machine/settings.json.

Par exemple, si vous souhaitez définir le thème de couleur par défaut sur "Sombre", étendez l'image de l'éditeur de base pour inclure le script suivant sous /etc/workstation-startup.d/150_default-ide-color-theme.sh.

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

Créer une image de conteneur personnalisée

Pour en savoir plus sur les commandes Docker, consultez la documentation de référence sur Docker. Saisissez la commande suivante pour créer votre conteneur :

docker build CUSTOM_IMAGE_FOLDER -t TARGET_IMAGE

Notez que le remplacement du texte qui précède l'icône Modifier Modifier met à jour les autres exemples de cette page.

Remplacez les éléments suivants :

  • CUSTOM_IMAGE_FOLDER : chemin d'accès au dossier que vous avez créé pour stocker votre image personnalisée.

  • TARGET_IMAGE : chemin d'accès à votre image dans Artifact Registry.

    Par exemple, TARGET_IMAGE peut pointer vers un chemin d'image cible semblable au suivant :

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

    Remplacez * par le nom de la région et tout autre identifiant, si nécessaire.

Vous pouvez également mettre à jour la variable d'environnement CLOUD_WORKSTATIONS_CUSTOM_IMAGE pour qu'elle pointe vers le dépôt.

Pour en savoir plus sur le stockage d'images Docker dans Artifact Registry, consultez les sections suivantes :

Héberger votre image de conteneur personnalisée

Pour héberger des images de conteneurs personnalisés, nous recommandons et prenons en charge Artifact Registry. Si vous utilisez GitHub ou un autre dépôt public ou privé, il est possible que Cloud Workstations ne fonctionne pas comme prévu. Pour en savoir plus, consultez la remarque importante de la section Utiliser une image de conteneur personnalisée.

Tester votre image de conteneur personnalisée

Une fois la compilation de votre conteneur terminée, vous pouvez le tester à l'aide de la commande suivante :

docker run --privileged -p LOCAL_PORT:CONTAINER_PORT TARGET_IMAGE

Remplacez les éléments suivants :

  • LOCAL_PORT : numéro de port local
  • CONTAINER_PORT : numéro de port du conteneur

Par exemple, remplacer LOCAL_PORT:CONTAINER_PORT par 8080:80 attribue le port 8080 pour une utilisation locale et le port 80 pour une utilisation dans le conteneur.

Si vous étendez l'image de l'éditeur de base Cloud Workstations, exécutez la commande docker, puis testez l'image de la station de travail en vous connectant à la station de travail via votre navigateur local ou en exécutant ssh pour vous connecter à votre conteneur :

  • Si vous vous connectez via votre navigateur, veillez à transmettre -p 8080:80 à votre commande docker run, puis ouvrez localhost:8080.
  • Si vous préférez vous connecter via SSH, veillez à transmettre -p 2222:22 à votre commande docker run, puis exécutez ssh user@localhost -p 2222.

Utiliser une image de conteneur personnalisée

Pour utiliser votre image de conteneur personnalisée après l'avoir créée et testée localement, transférez votre conteneur vers Artifact Registry à l'aide de la commande suivante :

docker push TARGET_IMAGE

Vous pouvez maintenant créer une configuration de station de travail à l'aide de l'image de conteneur que vous venez de créer et de transférer.

Pour en savoir plus, consultez Créer un dépôt Docker avec Artifact Registry.

Débogage de problèmes

Pour identifier et résoudre les problèmes d'exécution de votre image de conteneur, consultez les journaux de sortie du conteneur de vos stations de travail en cours d'exécution.

Vous êtes responsable de la gestion et de la mise à jour des packages et des dépendances personnalisés ajoutés aux images personnalisées.

Si vous créez des images personnalisées, nous vous recommandons de suivre les conseils ci-dessous :

Étapes suivantes