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 linguistiques et un serveur sshd. Pour accélérer la configuration de l'environnement pour des 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 reconstruire automatiquement ces images lorsque l'image de base Cloud Workstations est mise à jour. Nous vous conseillons également d'exécuter un outil d'analyse des conteneurs tel que Artifact Analysis pour inspecter les dépendances supplémentaires que vous avez ajoutées. Il vous incombe de gérer et de mettre à jour les packages et dépendances personnalisés ajoutés aux images personnalisées.

Avant de commencer

Vous avez besoin d'une machine dotée d'outils permettant de créer des images de conteneurs, comme Docker, et de transférer des images vers Artifact Registry à l'aide de la Google Cloud CLI. Vous pouvez utiliser Cloud Workstations ou l'éditeur Cloud Shell pour effectuer ces étapes, car ces outils y sont préinstallés.
Sélectionnez l'image de base que vous souhaitez utiliser dans notre liste des 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 conteneurs externes en suivant les instructions de la section Utiliser votre propre image de conteneur.
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 indiqué 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 du poste 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 fichier 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'adresse /home/.docker_data afin que les images soient conservées entre les sessions.

Pour ajouter des fonctionnalités supplémentaires au démarrage du poste 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 que racine. Pour exécuter les scripts en tant qu'utilisateur différent, utilisez la commande runuser.
Étant donné que les scripts s'exécutent dans l'ordre lexicographique, nous vous recommandons de les préfixer avec un nombre à trois chiffres supérieur à 200.

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

Modifications apportées au 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é dynamiquement au conteneur lors de l'exécution. Ce processus écrase les modifications apportées au répertoire /home lors de la création de l'image de conteneur.

Pour conserver les mises à jour, modifiez le répertoire /home lors 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 configurations au moment de la compilation qui doivent être déplacées vers le temps d'exécution du conteneur :

Configuration git par utilisateur
Dépôts git clonés 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é dynamiquement au conteneur lors de l'exécution, les utilisateurs doivent être ajoutés au démarrage du poste de travail, et non dans le fichier 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 Secure APT 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 de l'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é lors de l'interaction avec celui-ci.

Il arrive 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.

Lister les versions de l'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 liste le nom et les informations de version des IDE installés dans l'image.

Désactiver les droits root `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 du poste de travail.

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

Lorsque vous créez la configuration de votre poste de travail, renseignez les informations de base et la configuration de la machine.
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.
Cliquez sur AjouterAjouter une variable.
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é à l'adresse /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 à Cloud Shell.

Étant donné que le script customize_environment s'exécute en tant que user, veillez à mettre à jour les autorisations si nécessaire lorsque vous écrivez votre script. Par exemple, si vous souhaitez installer Emacs chaque fois que votre poste de travail démarre, le contenu de customize_environment peut ressembler à ce qui suit :

#!/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'adresse /var/log/customize_environment et sont également écrits dans les journaux de sortie du conteneur. Si l'exécution de customize_environment réussit, un fichier est créé dans /var/run/customize_environment_done. Étant donné que customize_environment s'exécute en parallèle avec le démarrage de Workstation, les packages installés par le script peuvent être disponibles quelques instants après le démarrage de votre station de travail.

Éviter les délais d'inactivité

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

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 bloquant 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 de blocage.

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

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

Toutefois, vous pouvez examiner 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 cette option par défaut.
Nous vous recommandons d'exécuter votre IDE ou serveur Web par défaut sur le port 80.

É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 poste de travail, vous pouvez adopter trois approches :

Mettez à jour votre Dockerfile pour inclure les éléments statiques supplémentaires que vous souhaitez ajouter.
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 opportun lors du démarrage du poste de travail.
Remplacez ENTRYPOINT dans votre fichier 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 Dockerfiles.

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 par l'utilisateur

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

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 nouveau nom du groupe et $USERNAME par le nom d'utilisateur de l'utilisateur.

En supposant que vous ayez nommé votre script 011_customize-user.sh, ajoutez les éléments suivants à votre image dans votre fichier 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 les variables d'environnement du conteneur dans les sessions SSH

Les variables d'environnement définies au niveau de la configuration ou du poste de travail sont transmises aux sous-processus directs à l'aide de la commande entrypoint. Cela inclut l'IDE dans les images de base préconfigurées. Toutefois, 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 relaie ces variables d'environnement depuis la commande du point d'entrée du conteneur vers le fichier /etc/environment.

Pour ce faire, procédez comme suit :

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ée.

En supposant que vous ayez nommé votre script 011_add-ssh-env-variables.sh, ajoutez les éléments suivants à votre image dans votre fichier 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 permet le transfert X11 pour les sessions SSH

Le transfert X11 vous permet de démarrer des applications à distance 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 démon 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 en plusieurs étapes vous permet d'utiliser plusieurs instructions FROM dans votre fichier 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 démarrer Code OSS pour les stations de travail Cloud au moment du 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 IDE dans Code OSS pour les stations de travail Cloud pour le développement Java

Pour créer une image de conteneur qui préinstalle les extensions d'IDE dans Code OSS pour les stations de travail Cloud 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 il est possible qu'elles n'apparaissent pas dans la section "Installées" de la place de marché des extensions. Toutefois, vous pouvez trouver vos extensions intégrées en recherchant @builtin.

Une autre façon d'installer des extensions au démarrage consiste à 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 la place de marché des extensions de , 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 des configurations de postes 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 selon vos besoins 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 un poste de travail à l'aide d'une configuration de poste de travail qui utilise l'une des images prédéfinies JetBrains, connectez-vous au poste de travail via JetBrains Gateway ou SSH, puis parcourez les fichiers de script dans le répertoire installer-scripts, qui se trouve dans le répertoire racine.

Nous vous recommandons d'exécuter ces scripts lors de la création 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 cette option est spécifiée, tout plug-in existant sera écrasé.
PLUGIN_ID : identifiant numérique requis 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`	Pilote
`rider`	Pilote
`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 personnel persistant est spécifié dans la configuration des stations de travail, les images de base Cloud Workstations avec des 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 cette option par défaut.

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

L'extrait 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 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 (facultatif) :

...
# 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 IDE supplémentaires dans Code OSS pour les stations de travail Cloud

Vous trouverez d'autres extensions d'IDE sur 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.

Ouvrez la page VSX de l'extension du langage Go, qui affiche le bouton "Télécharger".

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

Paramètres Code OSS par défaut pour les 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 personnel 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 de 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 edit 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'accès à l'image cible semblable à celui-ci :
```
*.pkg.dev/cloud-workstations-external/customimage:latest
```
Remplacez * par le nom de la région et tous les identifiants supplémentaires, 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 des images Docker dans Artifact Registry, consultez les sections suivantes :

Découvrez comment créer un dépôt Docker avec Artifact Registry.
Conventions de dénomination pour les noms de dépôts et d'images.

Héberger votre image de conteneur personnalisée

Pour héberger des images de conteneurs personnalisées, nous vous recommandons Artifact Registry et le prenons en charge. Si vous utilisez GitHub ou tout autre dépôt public ou privé, Cloud Workstations risque de ne pas fonctionner comme prévu. Pour en savoir plus, consultez la note importante de la section Utiliser une image de conteneur personnalisée.

Tester votre image de conteneur personnalisée

Une fois votre conteneur créé, 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, en remplaçant LOCAL_PORT:CONTAINER_PORT par 8080:80, vous attribuez 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, assurez-vous de transmettre -p 8080:80 à votre commande docker run, puis ouvrez localhost:8080.
Si vous préférez vous connecter via SSH, assurez-vous de 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, importez votre conteneur dans Artifact Registry à l'aide de la commande suivante :

docker push TARGET_IMAGE

Vous pouvez désormais créer une configuration de poste 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.

Faire du débogage

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

Recommandation : sécuriser votre pipeline d'images

Vous êtes responsable de la gestion et de la mise à jour des packages et 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 suivants :

Exécutez un outil d'analyse de conteneurs tel qu'Artifact Analysis pour inspecter les dépendances supplémentaires que vous avez ajoutées.
Planifiez des compilations pour reconstruire les images chaque semaine ou découvrez comment automatiser la reconstruction des images de conteneurs.

Étape suivante

Automatisez la reconstruction des images de conteneur pour synchroniser les mises à jour des images de base à l'aide de Cloud Build et Cloud Scheduler.
Mettre en place des bonnes pratiques de sécurité
En savoir plus sur Artifact Analysis

Personnaliser les images de conteneurs Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

Structure de l'image de base Cloud Workstations

Modifications apportées au répertoire d'accueil

Création et modification d'utilisateurs

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

Lister les versions de l'IDE installées

Désactiver les droits root sudo

Personnaliser sans étendre une image

Éviter les délais d'inactivité

Utiliser votre propre image de conteneur

Étendre les images de base Cloud Workstations

Exemples de fichiers Dockerfile personnalisés

Image de conteneur avec emacs préinstallé

Image de conteneur avec personnalisation par l'utilisateur

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

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

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

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

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

Scripts d'installation

Utiliser le script d'installation du plug-in

Utiliser le script d'installation JetBrains

Personnaliser les fichiers de configuration des IDE JetBrains

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

Installer des extensions IDE supplémentaires dans Code OSS pour les stations de travail Cloud

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

Créer une image de conteneur personnalisée

Héberger votre image de conteneur personnalisée

Tester votre image de conteneur personnalisée

Utiliser une image de conteneur personnalisée

Faire du débogage

Recommandation : sécuriser votre pipeline d'images

Étape suivante

Personnaliser les images de conteneurs

Désactiver les droits root `sudo`

Image de conteneur avec `emacs` préinstallé