Personnaliser les images de conteneurs

La des images de base préconfigurées fournis par Cloud Workstations ne contiennent qu'un environnement minimal avec IDE, des outils de base de terminal et de langage Linux et un serveur sshd. Pour accélérer le processus, configuration de l'environnement de cas d'utilisation spécifiques pour le développement, vous pouvez créer qui étendent ces images de base aux outils de préinstallation dépendances et qui exécutent des scripts d'automatisation.

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

Avant de commencer

  1. Vous avez besoin d'une machine dotée d'outils pour créer des images de conteneurs, Docker et le transfert d'images Artifact Registry (ou Container Registry) Google Cloud CLI ; Vous pouvez utiliser Cloud Workstations ou l'éditeur Cloud Shell pour effectuer ces étapes, où cet outil est préinstallé.

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

    Vous pouvez également utiliser votre propre image de conteneur ou des fichiers des images de conteneurs en suivant les instructions Utilisez votre propre image de conteneur.

  3. 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 du 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 des fichiers sous /etc/workstation-startup.d/* dans 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 le station de travail.

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

      Comme le disque persistant est associé dynamiquement 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 service sshd 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'adresse /home/.docker_data afin que les images soient conservées entre les sessions.

Pour ajouter des fonctionnalités 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 par défaut en tant que racine. Pour exécuter les scripts en tant que un autre utilisateur, utilisez la commande runuser.

  • Les scripts s'exécutant dans l'ordre lexicographique, nous vous recommandons préfixer les scripts d'un nombre à trois chiffres supérieur à 200.

Modifications du 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 sauvegardant le répertoire d'accueil est associé dynamiquement au conteneur lors de l'exécution. Ce processus écrase modifications apportées au répertoire /home au moment de la création 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 arrière-plan (ajoutez une esperluette & à la fin de la commande) pour éviter bloquant le démarrage du conteneur.

Quelques exemples de configuration au moment de la compilation à déplacer vers un conteneur d'exécution:

  • Configuration git par utilisateur
  • git dépôts clonés dans le répertoire d'accueil
  • Configuration utilisateur directe, par exemple le placement de fichiers dans un répertoire $HOME/.config
  • Création de compte utilisateur

Création et modification d'utilisateurs

Comme le disque persistant s'associe dynamiquement 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 créer votre propre script qui s'exécute au démarrage.

De plus, vous pouvez modifier le profil bash par défaut pour les utilisateurs en mettant à jour les fichiers dans /etc/profile.d.

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

Les images de base Cloud Workstations sont préinstallées, ainsi qu'un certain nombre d'outils à partir de divers référentiels tiers à l’aide de Secure APT. Dans le cadre 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é 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é lorsque interagir avec elle.

Il peut arriver que des propriétaires de référentiels tiers décident de modifier la clé publique pour valider l'intégrité de leur dépôt. apt d'afficher une erreur lors de l'interaction avec elle. 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 pour plus de commodité, consultez les /google/scripts/preinstalled-ide-versions.sh inclus qui liste le nom et la version des IDE installés l'image.

Désactiver les droits racine sudo

L'utilisateur de la station de travail par défaut dispose des droits d'accès racine sudo dans ces containers. Pour désactiver l'accès racine au conteneur Docker, définissez Variable d'environnement CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO à 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 la configuration de votre station de travail, procédez comme suit:

  1. Lorsque vous créez la configuration de votre station de travail, terminez la configuration pour obtenir des 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 et sélectionnez Variables d'environnement.
  3. Cliquez sur ajouterAjouter une variable.
  4. Saisissez CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO et true comme valeur.

Utiliser votre propre image de conteneur

Vous pouvez aussi utiliser votre propre image de conteneur ou des images de conteneurs externes, à condition qu'ils soient basés sur Linux et qu'ils exécutent un processus de blocage démarre.

Lors de la configuration du Dockerfile, l'instruction ENTRYPOINT doit exécuter une un processus bloquant tel que sleep infinity, afin que le conteneur continue au lieu de s'exécuter immédiatement. Sinon, dans la station de travail vous pouvez définir le champ config.container.args pour spécifier 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 provenant de Image de base Cloud Workstations

    Vous pouvez toutefois consulter les scripts dans /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 Valeur par défaut : /etc/workstation-startup.d/020_start-sshd.sh image de base pour découvrir comment Cloud Workstations le configure 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 afin de créer une image personnalisée pour votre environnement de poste de travail, vous pouvez adopter trois approches:

  1. Mettez à jour votre Dockerfile pour inclure tous les éléments statiques supplémentaires que vous 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 sont automatiquement s'exécutent dans l'ordre lexicographique au démarrage du conteneur, ce qui vous permet pour l'exécuter au bon moment lors du démarrage de la station de travail.
  3. Remplacez ENTRYPOINT dans votre Dockerfile pour personnaliser entièrement votre le démarrage du conteneur.

Exemples de fichiers Dockerfile personnalisés

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

Image du conteneur avec emacs préinstallé

Pour créer une image de conteneur avec emacs préinstallé, exécutez la commande suivante : commandes:

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:

  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, puis $USERNAME par le nom de l'utilisateur.

  2. En supposant que vous avez nommé votre script 011_customize-user.sh, ajoutez la méthode à l'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 les variables d'environnement de conteneurs dans les sessions SSH

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

Pour définir ces variables d'environnement dans les sessions SSH, configurez un une image de conteneur qui relaie ces variables d'environnement à partir de l'API Entréepoint au fichier /etc/environment.

Pour cela, 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 la variable d'environnement prévue. son nom.

  2. En supposant que vous avez nommé votre script 011_add-ssh-env-variables.sh, ajoutez la méthode à l'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 les transférer afficher sur un ordinateur local.

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

Voici un exemple de Dockerfile, qui effectue 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 Dockerfile. Chaque instruction FROM peut utiliser une base différente et active copier des artefacts entre les étapes de compilation. Pour ajouter Code OSS pour Cloud Workstations à Une autre image de conteneur utilise une compilation en plusieurs étapes pour copier le dossier de l'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 Dockerfile qui copie Code OSS dans IntelliJ JetBrains Image ultime. Vous pouvez ensuite interagir avec l'un 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 des extensions IDE dans Code OSS pour Cloud Workstations pour le développement Java

Pour créer une image de conteneur qui préinstalle les extensions IDE dans Coder 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 s'afficher dans la section des applications installées sur le Extensions Marketplace. Cependant, 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 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 Extensions Marketplace et vous à partir de là.

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

Lorsque vous personnalisez des images Docker pour des configurations de stations de travail, vous pouvez installer IDE et 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 éléments suivants : scripts pour vous aider à:

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

Si nécessaire, utilisez ces scripts pour personnaliser l'image de base et les appeler avec une de démarrage rapide, ou pour les exécuter après le démarrage de la station de travail.

Scripts d'installation

Pour afficher les fichiers sources pour jetbrains-installer.sh et Scripts plugin-installer.sh, démarrer une station de travail à l'aide d'une station de travail qui utilise l'une des images prédéfinies JetBrains, connectez-vous 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 au moment de la création du conteneur. Éviter de courir dans une station de travail déjà démarrée.

Utiliser le script du programme 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é. S'il n'est pas spécifié, le répertoire de travail est utilisé.
  • CHECKSUM: somme de contrôle SHA-256 facultative du plug-in demandé.
  • -f: si spécifié, tous les plug-ins existants seront écrasés.
  • PLUGIN_ID: identifiant numérique de plug-in requis Place de marché JetBrains. Par exemple, pour ajouter Fléchette 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:

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

Utiliser le script d'installation JetBrains

Nous vous recommandons d'utiliser le script d'installation JetBrains Extension d'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 en utiliser un des abréviations 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 le fichier épinglé 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 : :

jetbrains-installer.sh clion

Personnaliser les fichiers de configuration de l'IDE JetBrains

Si un répertoire d'accueil persistant est spécifié dans les stations de travail de base Cloud Workstations avec des IDE JetBrains conserver automatiquement la 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 au cours de tout Image de base JetBrains pour en savoir plus comment Cloud Workstations le configure par défaut.

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

L'extrait de fichier 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 éventuellement version 22.9.3-222 comme version numéro, /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 IDE supplémentaires dans Code OSS pour Cloud Workstations

Trouvez des extensions IDE supplémentaires sur le Ouvrez VSX Registry. Vous pouvez également trouver l'URL du fichier .vsix en copiant l'URL à partir du Télécharger le lien de téléchargement de n'importe quelle extension.

Ouvrez la page VSX de l&#39;extension de langue Go affichant le bouton &quot;Télécharger&quot;.

Si vous ouvrez Extensions Marketplace sur station de travail, Installer apparaît à la place de Télécharger.

Paramètres OSS de code par défaut pour Cloud Workstations

Pour en savoir plus sur le stockage des paramètres dans Code OSS pour Cloud Workstations, consultez la section 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 des paramètres $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 la base l'image de l'éditeur pour inclure le script suivant /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 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 remplacer le texte qui précède la balise modifier L'icône Modifier met à jour les autres exemples de cette page.

Remplacez les éléments suivants :

  • CUSTOM_IMAGE_FOLDER: chemin d'accès à 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 une image cible. un chemin d'accès semblable à l'un des chemins suivants:

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

*.gcr.io/cloud-workstations-external/customimage:latest

    Si nécessaire, remplacez * 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'il pointe vers le dépôt.

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

Héberger votre image de conteneur personnalisé

Pour héberger des images de conteneurs personnalisés, nous vous recommandons d'utiliser Artifact Registry. Si vous utilisez GitHub ou tout autre dépôt public ou privé, Cloud Workstations peuvent ne pas fonctionner comme prévu. Pour en savoir plus, consultez la remarque importante dans le Utiliser une image de conteneur personnalisée .

Tester votre image de conteneur personnalisé

Une fois votre conteneur créé, vous pouvez le tester à l'aide des éléments suivants : :

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 avec 8080:80 attribue le port 8080 à utiliser localement et le port 80 à utiliser 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 la commande 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 à la 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é après l'avoir compilée et testée en local, transférez votre conteneur vers Artifact Registry (ou Container Registry) à l'aide des éléments suivants : :

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éez un dépôt Docker avec Artifact Registry.

Problèmes de débogage

Pour identifier et déboguer les problèmes liés à l'exécution de votre image de conteneur, consultez le Journaux de sortie du conteneur depuis vos stations de travail en cours d'exécution.

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

Si vous créez des images personnalisées, nous vous recommandons de procéder comme suit:

Étape suivante