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 et des outils de langage, ainsi qu'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 conteneur 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 conteneur personnalisées, nous vous recommandons de configurer un pipeline pour reconstruire automatiquement ces images lorsque l'image de base de Cloud Workstations est mise à jour, en plus d'exécuter un outil d'analyse de conteneur tel que Artifact Analysis pour inspecter les dépendances supplémentaires que vous avez ajoutées. Vous êtes responsable de la maintenance et de la mise à jour des packages et des dépendances personnalisés ajoutés aux images personnalisées.
Avant de commencer
Vous avez besoin d'une machine équipée d'outils permettant de créer des images de conteneur telles que Docker et de transférer des images vers Artifact Registry (ou Container Registry) à l'aide de la Google Cloud CLI. Pour effectuer ces étapes, vous pouvez utiliser Cloud Workstations ou l'éditeur Cloud Shell, qui 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 conteneur externes en suivant les instructions pour utiliser votre propre image de conteneur.
Créez un dossier tel que
CUSTOM_IMAGE_FOLDER
et un Dockerfile dans ce dossier é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 alphabétique 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 de la station de travail, et non dans le Dockerfile.
020_start-sshd.sh
: démarre le servicesshd
dans le conteneur.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 au démarrage de la station de travail, ajoutez vos scripts dans le répertoire /etc/workstation-startup.d/
:
Les scripts de ce répertoire s'exécutent en tant qu'utilisateur racine par défaut. 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 alphabétique, nous vous recommandons d'ajouter un nombre à trois chiffres supérieur à 200 en préfixe.
Modifications apportées au répertoire d'accueil
Lorsque la configuration de la station de travail spécifie un répertoire d'accueil persistant (ce qui est le comportement par défaut), un disque persistant qui sert de base au 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 création de l'image du 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 un 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 - 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 s'associe de manière dynamique au conteneur au moment de l'exécution, les utilisateurs doivent être ajoutés au démarrage de la station 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.
En outre, vous pouvez modifier le profil bash par défaut pour les utilisateurs en mettant à jour les fichiers dans /etc/profile.d
.
Modifier les clés APT sécurisées préconfigurées
Les images de base de Cloud Workstations sont préinstallées avec un certain nombre d'outils obtenus à partir de divers 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 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
lorsqu'il interagit 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 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 liste le nom et les informations de version des IDE installés dans l'image.
Désactiver les droits root sudo
L'utilisateur par défaut de la station de travail dispose des 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 lorsque vous créez la configuration de votre station de travail, procédez comme suit:
- Lorsque vous créez la configuration de votre poste de travail, remplissez les sections "Informations de base" et "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
ettrue
comme valeur.
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 bloquant au démarrage du conteneur.
Lors de la configuration du Dockerfile, l'instruction ENTRYPOINT
doit exécuter un processus bloquant tel que sleep infinity
pour 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.
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 fichier indiquent la fonction de chaque script.Nous vous recommandons d'exécuter un serveur SSH dans le conteneur. Reportez-vous à
/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
.
É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 suivre trois approches:
- Mettez à jour votre
Dockerfile
pour inclure tous 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 alphabétique au démarrage du conteneur. Vous pouvez donc ajouter un préfixe à votre nom de fichier pour l'exécuter au moment opportun au démarrage de la station de travail. - Forcez le
ENTRYPOINT
dans votre Dockerfile pour personnaliser complètement 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 Docker.
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 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ès010_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 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 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 ces variables d'environnement personnalisées ne sont pas définies.
Pour définir ces variables d'environnement dans les sessions SSH, configurez une image de conteneur personnalisée qui transfère ces variables d'environnement de 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ès010_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é.En supposant que vous ayez nommé votre script
011_add-ssh-env-variables.sh
, ajoutez les éléments suivants à 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 à distance et de transférer l'affichage de l'application vers une machine locale.
Pour créer une image de conteneur qui active le transfert X11, modifiez le fichier de configuration du daemon OpenSSH (/etc/ssh/sshd_config
) fourni par les images de base de 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 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 version 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 démarrer 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'IDE de votre choix:
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 préinstallant 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
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 risquent de ne pas apparaître 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
:
/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 , et vous pouvez la mettre à jour à partir de là.
Installer les IDE et les plug-ins JetBrains dans des images de base
Lorsque vous personnalisez des images Docker pour des 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 JetBrainsplugin-installer.sh
: installe des plug-ins, tels que Cloud Code pour IntelliJ
Utilisez ces scripts si nécessaire pour personnaliser l'image de base, pour les appeler avec un script de démarrage ou pour 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 de JetBrains, connectez-vous à la station de travail via JetBrains Gateway ou via 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 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 cet élément est spécifié, tout plug-in existant sera écrasé.PLUGIN_ID
: identifiant numérique du plug-in requis sur la place de marché JetBrains. Par exemple, pour ajouter Dart, utilisez6351
comme PLUGIN_ID. Pour ajouter Cloud Code pour IntelliJ, utilisez8079
comme PLUGIN_ID.
Par exemple, pour installer la dernière version du plug-in Dart dans IntelliJ, exécutez la commande suivante:
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 estlatest
.
Par exemple, pour installer la dernière version de Clion, exécutez la commande suivante:
jetbrains-installer.sh clion
Personnaliser les fichiers de configuration de l'IDE JetBrains
Si un répertoire d'accueil persistant est spécifié dans la configuration des stations de travail, les images de base de 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 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 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.
Si vous ouvrez Extensions Marketplace à partir d'une station de travail, Installer s'affiche à la place de Télécharger.
Paramètres par défaut de Code OSS 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", développez 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 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 (ou Container Registry).Par exemple,
TARGET_IMAGE
peut pointer vers un chemin d'image cible semblable à l'un des chemins suivants:*.pkg.dev/cloud-workstations-external/customimage:latest *.gcr.io/cloud-workstations-external/customimage:latest
Remplacez * si nécessaire par le nom de la région et tout identifiant supplémentaire.
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:
- Créer un dépôt Docker avec Artifact Registry
- Conventions d'attribution de noms pour les noms de dépôt et d'image.
Héberger votre image de conteneur personnalisée
Pour héberger des images de conteneur personnalisées, nous vous recommandons d'utiliser Artifact Registry, qui est compatible avec cette fonctionnalité. Si vous utilisez GitHub ou tout autre dépôt public ou privé, Cloud Workstations risquent 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 la compilation de votre conteneur terminée, vous pouvez le tester avec la commande suivante:
docker run --privileged -p LOCAL_PORT:CONTAINER_PORT TARGET_IMAGE
Remplacez les éléments suivants :
LOCAL_PORT
: numéro de port localCONTAINER_PORT
: numéro de port du conteneur
Par exemple, remplacer LOCAL_PORT
:CONTAINER_PORT
par 8080
:80
attribue le port 8080
à l'utilisation locale et le port 80
à l'utilisation dans le conteneur.
Si vous étendez l'image de l'éditeur de base de Cloud Workstations, exécutez la commande docker
, puis testez l'image de la station de travail en vous connectant à celle-ci 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 commandedocker run
, puis ouvrezlocalhost:8080
. - Si vous préférez vous connecter via SSH, veillez à transmettre
-p 2222:22
à votre commandedocker run
, puis exécutezssh 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 (ou Container 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 la section Créer un dépôt Docker avec Artifact Registry.
Problèmes de débogage
Pour rechercher et déboguer les problèmes d'exécution de votre image de conteneur, consultez les journaux de sortie du conteneur à partir de vos stations de travail en cours d'exécution.
Recommandation: sécurisez votre pipeline d'images
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 ce qui suit:
Protégez votre pipeline d'images en reconstruisant automatiquement ces images lorsque l'image de base de Cloud Workstations est mise à jour.
Exécutez un outil d'analyse de conteneur tel que Artifact Analysis pour inspecter les dépendances supplémentaires que vous avez ajoutées.
Planifiez des compilations pour recréer des images chaque semaine ou découvrez comment automatiser la recréation d'images de conteneur.
Étape suivante
- Automatisez la recompilation des images de conteneur pour synchroniser les mises à jour des images de base à l'aide de Cloud Build et de Cloud Scheduler.
- Mettre en place des bonnes pratiques de sécurité
- En savoir plus sur Artifact Analysis