Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Personnaliser le module complémentaire ## Modèle Les modèles sont des configurations d'espace de travail réutilisables qui servent de plans contrôlés par l'administrateur pour la création d'espaces de travail. Ils fournissent des valeurs par défaut pour les valeurs de configuration de l'espace de travail et des garde-fous permettant de contrôler ce que les data scientists peuvent faire. Les modèles existent au niveau du cluster et peuvent être réutilisés dans les espaces de noms. SageMaker Spaces crée deux modèles de système comme point de départ pour les data scientists, un pour Code Editor et un pour JupyterLab. Ces modèles de système sont gérés par l'addon et ne peuvent pas être modifiés directement. Au lieu de cela, les administrateurs peuvent créer de nouveaux modèles et les définir par défaut. ## Gouvernance des tâches ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: my-jupyter-template namespace: my-namespace labels: kueue.x-k8s.io/priority-class: -priority spec: displayName: "My Custom Jupyter Lab" description: "Custom Jupyter Lab with specific configurations" defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" allowedImages: - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu" defaultResources: requests: cpu: "1" memory: "4Gi" limits: cpu: "4" memory: "16Gi" primaryStorage: defaultSize: "10Gi" minSize: "5Gi" maxSize: "50Gi" defaultStorageClassName: "sagemaker-spaces-default-storage-class" defaultMountPath: "/home/sagemaker-user" defaultContainerConfig: command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"] defaultPodSecurityContext: fsGroup: 1000 defaultOwnershipType: "Public" defaultAccessStrategy: name: "hyperpod-access-strategy" allowSecondaryStorages: true appType: "jupyterlab" ``` ## SMD/Images personnalisées Les clients peuvent configurer les politiques relatives aux images par le biais de modèles en fournissant une image par défaut et une liste d'images autorisées. En outre, les administrateurs peuvent choisir d'autoriser ou non les data scientists à apporter leurs propres images personnalisées. Le système utilise par défaut la dernière SageMaker distribution, mais si vous souhaitez attribuer une version particulière, vous pouvez spécifier la version SMD exacte à utiliser dans un modèle. Exigences relatives aux images personnalisées : + `curl`si vous souhaitez utiliser l'arrêt en mode veille + port 8888 + accès distant ## Exigence d'IDE à distance ### Version de VS Code exigée La version [v1.90](https://code.visualstudio.com/updates/v1_90) ou supérieure de VS Code est requise. Nous vous recommandons d’utiliser la [dernière version stable de VS Code](https://code.visualstudio.com/updates). ### Système d’exploitation exigé Vous avez besoin de l’un des systèmes d’exploitation suivants pour vous connecter à distance aux espaces Studio : + macOS 13\$1 + Windows 10 + [La prise en charge de Windows 10 prend fin le 14 octobre 2025](https://support.microsoft.com/en-us/windows/windows-10-support-ends-on-october-14-2025-2ca8b313-1946-43d3-b55c-2b95b107f281) + Windows 11 + Linux + Installez le [code Microsoft VS officiel pour Linux](https://code.visualstudio.com/docs/setup/linux) + il ne s'agit pas d'une version open source ### Prérequis pour les machines locales Avant de connecter votre code Visual Studio local aux espaces Studio, assurez-vous que votre machine locale dispose des dépendances et de l'accès réseau requis. **Note** Les environnements soumis à des restrictions d'installation de logiciels peuvent empêcher les utilisateurs d'installer les dépendances requises. Le AWS Toolkit for Visual Studio Code recherche automatiquement ces dépendances lors de l'établissement de connexions à distance et vous invite à procéder à l'installation s'il en manque une. Coordonnez-vous avec votre service informatique pour vous assurer que ces composants sont disponibles. **Dépendances locales requises** Les composants suivants doivent être installés sur votre machine locale : + **[https://code.visualstudio.com/docs/remote/ssh](https://code.visualstudio.com/docs/remote/ssh)** + — Extension VS Code Marketplace standard pour le développement à distance + **[Plug-in Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)** — Nécessaire pour la gestion sécurisée des sessions + **Client SSH** : composant standard sur la plupart des machines ([OpenSSH recommandé pour Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse)) + **[https://code.visualstudio.com/docs/configure/command-line](https://code.visualstudio.com/docs/configure/command-line)** + Généralement inclus dans l'installation de VS Code **Exigences spécifiques à la plate-forme** + **Utilisateurs de Windows** : la PowerShell version 5.1 ou ultérieure est requise pour les connexions au terminal SSH **Exigences en matière de connectivité réseau** Votre machine locale doit disposer d'un accès réseau aux [points de terminaison du gestionnaire de session](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Par exemple, dans l'est des États-Unis (Virginie du Nord) (us-east-1), il peut s'agir de : + `[ssm.us-east-1.amazonaws.com](http://ssm.us-east-1.amazonaws.com)` + `ssm.us-east-1.api.aws` + `[ssmmessages.us-east-1.amazonaws.com](http://ssmmessages.us-east-1.amazonaws.com)` + `[ec2messages.us-east-1.amazonaws.com](http://ec2messages.us-east-1.amazonaws.com)` ### Exigences relatives aux images **SageMaker Images de distribution** Lorsque vous utilisez SageMaker Distribution avec accès à distance, utilisez [SageMaker Distribution](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-distribution.html) version 2.7 ou ultérieure. **Images personnalisées** Lorsque vous [apportez votre propre image (BYOI)](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi.html) avec un accès à distance, assurez-vous de suivre les [spécifications d'image personnalisées](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi-specs.html) et de vous assurer que les dépendances suivantes sont installées : + `curl`ou `wget` — Nécessaire pour le téléchargement de AWS CLI composants + `unzip`— Nécessaire pour extraire les fichiers AWS CLI d'installation + `tar`— Nécessaire pour l'extraction des archives + `gzip`— Nécessaire pour la gestion des fichiers compressés ### Exigences relatives aux instances + **Mémoire** : 8 Go ou plus + Utilisez des instances dotées d'au moins 8 Go de mémoire. Les types d’instances suivants *ne sont pas* pris en charge en raison d’une mémoire insuffisante (moins de 8 Go) : `ml.t3.medium`, `ml.c7i.large`, `ml.c6i.large`, `ml.c6id.large` et `ml.c5.large`. Pour une liste plus complète des types d'instances, consultez la page de tarification à la [demande d'Amazon EC2](https://aws.amazon.com/ec2/pricing/on-demand/) ## Optimisation du temps de démarrage de Kubernetes en préchauffant les images des conteneurs Les performances d'extraction d'images de conteneurs constituent désormais un obstacle majeur pour de nombreux clients d'EKS, d'autant plus que les AI/ML charges de travail reposent sur des images de conteneurs de plus en plus grandes. L'extraction et le déballage de ces grandes images prennent généralement plusieurs minutes la première fois qu'elles sont utilisées sur chaque nœud EKS. Ce délai augmente considérablement la latence lors du lancement de SageMaker Spaces et a un impact direct sur l'expérience utilisateur, en particulier dans les environnements où un démarrage rapide est essentiel, tels que les ordinateurs portables ou les tâches de développement interactives. Le préchauffage des images est une technique utilisée pour précharger des images de conteneur spécifiques sur chaque nœud du EKS/HyperPod cluster avant qu'elles ne soient nécessaires. Au lieu d'attendre qu'un module déclenche la première extraction d'une image de grande taille, le cluster télécharge et met en cache les images de manière proactive sur tous les nœuds. Ainsi, lorsque les charges de travail sont lancées, les images requises sont déjà disponibles localement, éliminant ainsi les longs délais de démarrage à froid. Le préchauffage des images améliore la vitesse de démarrage de SageMaker Spaces et offre une expérience plus prévisible et réactive aux utilisateurs finaux. ### Préchauffage via DaemonSet Nous vous recommandons d'utiliser un DaemonSet pour précharger les images. A DaemonSet garantit qu'un pod s'exécute sur chaque nœud du cluster. Chaque conteneur à l'intérieur du DaemonSet module fait référence à une image que vous souhaitez mettre en cache. Lorsque Kubernetes démarre le pod, il extrait automatiquement les images et réchauffe le cache de chaque nœud. L'exemple suivant montre comment créer un DaemonSet qui précharge deux images GPU. Chaque conteneur exécute une `sleep infinity` commande légère pour maintenir le pod actif avec un minimum de surcharge. ``` cat < + Chaque conteneur fait référence à une image. + Kubernetes doit télécharger chaque image avant de démarrer le conteneur. + Une fois que le pod est en cours d'exécution sur chaque nœud, les images sont mises en cache localement. + Toute charge de travail utilisant ces images démarre désormais beaucoup plus rapidement. ## Espace de stockage par défaut (EBS) Le système utilise le pilote EBS CSI par défaut pour provisionner des volumes de stockage EBS pour chaque espace de travail. SageMaker crée une classe de stockage EBS à utiliser avec les espaces de travail, et les administrateurs peuvent personnaliser la taille par défaut et maximale de ces volumes à l'aide des paramètres du modèle. Pour les utilisateurs expérimentés utilisant des outils CLI, vous pouvez également personnaliser la classe de stockage de l'espace de travail, ce qui permet aux utilisateurs de tirer parti d'autres classes de stockage, notamment en configurant des clés KMS gérées par le client pour leurs volumes EBS. Notez que les volumes EBS sont liés à une zone de zone spécifique, ce qui signifie que les espaces de travail ne peuvent être planifiés que sur des nœuds de la même zone que leur volume de stockage. Cela peut entraîner des échecs de planification si la capacité du cluster existe mais pas dans la bonne zone de disponibilité. ## Stockage supplémentaire SageMaker Spaces permet d'associer des volumes de stockage supplémentaires tels qu'Amazon EFS, FSx for Lustre ou S3 Mountpoint à vos espaces de développement. Cela vous permet d'accéder à des ensembles de données partagés, de collaborer sur des projets ou d'utiliser un stockage haute performance pour vos charges de travail. ### Conditions préalables Avant d'ajouter de l'espace de stockage aux espaces, vous devez : 1. **Installez le module complémentaire de pilote CSI approprié** via [les modules complémentaires EKS](https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html) (pilote CSI Amazon EFS, pilote CSI Amazon FSx pour Lustre ou pilote CSI Mountpoint pour Amazon S3) 1. **Configurez les ressources de stockage et PersistentVolumeClaims** suivez la documentation du pilote CSI pour votre type de stockage spécifique 1. **Assurez-vous que le PVC est disponible** dans le même espace de noms que celui dans lequel vous prévoyez de créer votre espace ### Fixer un espace de rangement aux espaces Une fois que vous avez PersistentVolumeClaim configuré un espace, vous pouvez l'attacher à un espace à l'aide de la HyperPod CLI ou de kubectl. **HyperPod INTERFACE DE LIGNE DE COMMANDE (CLI)** ``` hyp create hyp-space \ --name my-space \ --display-name "My Space with FSx" \ --memory 8Gi \ --volume name=shared-fsx,mountPath=/shared,persistentVolumeClaimName=my-fsx-pvc ``` **kubectl** ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: my-space spec: displayName: "My Space with FSx" desiredStatus: Running volumes: - name: shared-fsx mountPath: /shared persistentVolumeClaimName: my-fsx-pvc ``` ### Volumes multiples Vous pouvez associer plusieurs volumes de stockage supplémentaires à un même espace en spécifiant plusieurs `--volume` indicateurs avec la CLI ou plusieurs entrées dans le `volumes` tableau avec kubectl. **HyperPod INTERFACE DE LIGNE DE COMMANDE (CLI)** ``` hyp create hyp-space \ --name my-space \ --display-name "My Space with Multiple Storage" \ --memory 8Gi \ --volume name=shared-efs,mountPath=/shared,persistentVolumeClaimName=my-efs-pvc \ --volume name=datasets,mountPath=/datasets,persistentVolumeClaimName=my-s3-pvc ``` **kubectl** ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: my-space spec: displayName: "My Space with Multiple Storage" desiredStatus: Running volumes: - name: shared-efs mountPath: /shared persistentVolumeClaimName: my-efs-pvc - name: datasets mountPath: /datasets persistentVolumeClaimName: my-s3-pvc ``` ## Configuration des ressources SageMaker Spaces vous permet de configurer les ressources de calcul pour vos environnements de développement, notamment les ressources du processeur, de la mémoire et du processeur graphique pour répondre aux exigences de votre charge de travail. ### Configuration du GPU SageMaker Spaces prend en charge à la fois l'allocation complète du GPU et le partitionnement du GPU à l'aide de la technologie NVIDIA Multi-Instance GPU (MIG). Cela vous permet d'optimiser l'utilisation du GPU pour différents types de charges de travail d'apprentissage automatique. #### Allocation complète du GPU **HyperPod INTERFACE DE LIGNE DE COMMANDE (CLI)** ``` hyp create hyp-space \ --name gpu-space \ --display-name "GPU Development Space" \ --image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \ --memory 16Gi \ --gpu 1 \ --gpu-limit 1 ``` **kubectl** ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: gpu-space spec: displayName: "GPU Development Space" image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu" desiredStatus: Running resources: requests: memory: "16Gi" nvidia.com/gpu: "1" limits: memory: "16Gi" nvidia.com/gpu: "1" ``` #### Partitionnement du GPU (MIG) Le partitionnement du GPU à l'aide de la technologie NVIDIA Multi-Instance GPU (MIG) vous permet de partitionner un seul GPU en instances isolées plus petites. Votre HyperPod cluster doit comporter des nœuds GPU compatibles avec le MIG et des profils MIG doivent être configurés. Pour plus d'informations sur la configuration de MIG sur votre HyperPod cluster, consultez [Partitionnement du GPU à l'aide de NVIDIA](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-gpu-partitioning-setup.html) MIG. **HyperPod INTERFACE DE LIGNE DE COMMANDE (CLI)** ``` hyp create hyp-space \ --name mig-space \ --display-name "MIG GPU Space" \ --image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \ --memory 8Gi \ --accelerator-partition-type mig-3g.20gb \ --accelerator-partition-count 1 ``` **kubectl** ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: mig-space spec: displayName: "MIG GPU Space" image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu" desiredStatus: Running resources: requests: memory: "8Gi" nvidia.com/mig-3g.20gb: "1" limits: memory: "8Gi" nvidia.com/mig-3g.20gb: "1" ``` ## Cycle de vie La configuration du cycle de vie fournit des scripts de démarrage qui s'exécutent lors de la création ou du démarrage d'un espace de travail. Ces scripts permettent aux administrateurs de personnaliser l'environnement de travail au démarrage. Il s'agit de scripts bash d'une taille maximale de 1 Ko. Si vous avez besoin d'une configuration plus importante, nous vous recommandons d'ajouter un script à l'image du conteneur et de déclencher le script à partir de la configuration du cycle de vie. [Nous utilisons les hooks du cycle de vie des conteneurs Kubernetes pour fournir cette fonctionnalité https://kubernetes. io/docs/concepts/containers/container-crochets pour le cycle de vie/.](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) Notez que Kubernetes ne fournit aucune garantie quant au moment où le script de démarrage sera exécuté par rapport au point d'entrée du conteneur. ## Arrêt d’inactivité Configurez l'arrêt automatique des espaces de travail inactifs pour optimiser l'utilisation des ressources. ### Arrêt d’inactivité ``` idleShutdown: enabled: true idleShutdownTimeoutMinutes: 30 detection: httpGet: path: /api/idle port: 8888 scheme: HTTP ``` ### Parameters **activé** (booléen, obligatoire) : active ou désactive l'arrêt inactif de l'espace de travail. **idleShutdownTimeoutMinutes** (entier, obligatoire) : nombre de minutes d'inactivité avant la fermeture de l'espace de travail. La valeur minimum est de 1. **détection** (objet, obligatoire) - Définit comment détecter l'état d'inactivité de l'espace de travail. **Detection.HttpGet** (objet, facultatif) : configuration du point de terminaison HTTP pour la détection des inactifs. Utilise la spécification Kubernetes Action. HTTPGet + **path** - chemin HTTP à demander + **port** - Numéro ou nom du port + **schéma** - HTTP ou HTTPS (par défaut : HTTP) ### Emplacements de configuration **Configuration d'espace de travail** Définissez l'arrêt en mode veille directement dans les spécifications de l'espace de travail : ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: my-workspace spec: displayName: "Development Workspace" image: jupyter/scipy-notebook:latest idleShutdown: enabled: true idleShutdownTimeoutMinutes: 30 detection: httpGet: path: /api/idle port: 8888 ``` **Configuration du modèle** Définissez le comportement d'arrêt en mode veille par défaut dans un WorkspaceTemplate : ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: jupyter-template spec: displayName: "Jupyter Template" defaultImage: jupyter/scipy-notebook:latest defaultIdleShutdown: enabled: true idleShutdownTimeoutMinutes: 30 detection: httpGet: path: /api/idle port: 8888 idleShutdownOverrides: allow: true minTimeoutMinutes: 60 maxTimeoutMinutes: 240 ``` ### Héritage et remplacements de modèles Les espaces de travail utilisant un modèle héritent automatiquement de la configuration du `defaultIdleShutdown` modèle. Les espaces de travail peuvent remplacer cette configuration si le modèle le permet. **Politique de dérogation** Les modèles contrôlent le comportement de substitution par `idleShutdownOverrides` les moyens suivants : **allow** (boolean, default : true) : indique si les espaces de travail peuvent remplacer la configuration d'arrêt en mode veille par défaut. **minTimeoutMinutes**(entier, facultatif) - Valeur de délai d'expiration minimale autorisée pour les remplacements de l'espace de travail. **maxTimeoutMinutes**(entier, facultatif) - Valeur de délai d'expiration maximale autorisée pour les remplacements de l'espace de travail. **Exemple d'héritage** Workspace hérite des paramètres par défaut du modèle : ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: my-workspace spec: displayName: "My Workspace" templateRef: name: jupyter-template # Inherits defaultIdleShutdown from template ``` **Exemple de dérogation** Workspace remplace les paramètres par défaut du modèle : ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: my-workspace spec: displayName: "My Workspace" templateRef: name: jupyter-template idleShutdown: enabled: true idleShutdownTimeoutMinutes: 60 # Must be within template bounds detection: httpGet: path: /api/idle port: 8888 ``` **Configuration verrouillée** Empêchez les remplacements d'espaces de travail : ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: locked-template spec: displayName: "Locked Template" defaultImage: jupyter/scipy-notebook:latest defaultIdleShutdown: enabled: true idleShutdownTimeoutMinutes: 30 detection: httpGet: path: /api/idle port: 8888 idleShutdownOverrides: allow: false # Workspaces cannot override ``` ### Comportement Lorsque l'arrêt en mode inactif est activé, le système vérifie régulièrement l'activité de l'espace de travail à l'aide du point de terminaison HTTP configuré. Si le point de terminaison indique que l'espace de travail est inactif pendant la durée spécifiée, l'espace de travail s'arrête automatiquement. Vous pouvez redémarrer manuellement l'espace de travail en cas de besoin. ## Mises à jour des modèles Les outils clients tels que Kubectl ou Hyperpod CLI et SDK peuvent être utilisés pour gérer les espaces au sein du cluster EKS. Les administrateurs peuvent fournir des modèles d'espace pour les configurations d'espace par défaut, tandis que les data scientists peuvent personnaliser leurs environnements de développement intégrés sans avoir à comprendre la complexité sous-jacente de Kubernetes. Pour des instructions d'utilisation détaillées, reportez-vous à la documentation de la CLI et du SDK à l'[https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html](https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html)adresse. Les administrateurs peuvent effectuer des opérations CRUD sur les modèles d'espace, qui servent de configurations de base lors de la création d'un espace. Les data scientists peuvent effectuer des opérations CRUD sur Spaces et annuler divers paramètres, notamment les profils GPU multi-instances pour des nœuds de calcul spécifiques. Ils peuvent démarrer, arrêter et se connecter aux Spaces via un VSCode accès à distance et l'interface utilisateur Web. Lorsqu'un modèle d'espace est mis à jour, tout espace créé ultérieurement sera configuré avec les paramètres du modèle mis à jour. Des contrôles de conformité seront effectués lors de la mise à jour ou du démarrage des espaces existants. Si certains paramètres sont hors limites ou ne correspondent pas, les espaces ne seront pas mis à jour ou ne démarreront pas. ## Utilisation de hyp cli et kubectl L'utilisateur peut effectuer un CRUD sur les modèles à l'aide de la CLI Hyperpod ``` ### 1. Create a Space Template hyp create hyp-space-template --file template.yaml ### 2. List Space Templates hyp list hyp-space-template hyp list hyp-space-template --output json ### 3. Describe a Space Template hyp describe hyp-space-template --name my-template hyp describe hyp-space-template --name my-template --output json ### 4. Update a Space Template hyp update hyp-space-template --name my-template --file updated-template.yaml ### 5. Delete a Space Template hyp delete hyp-space-template --name my-template ``` Pour créer des modèles personnalisés, vous pouvez utiliser nos modèles de système comme point de départ. Ce modèle fonctionnera pour les images de type SMD, mais il peut être personnalisé en fonction des images utilisées par les administrateurs. Exemple de JupyterLab modèle personnalisé : ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: my-jupyter-template namespace: my-namespace spec: displayName: "My Custom Jupyter Lab" description: "Custom Jupyter Lab with specific configurations" defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" allowedImages: - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu" defaultResources: requests: cpu: "1" memory: "4Gi" limits: cpu: "4" memory: "16Gi" primaryStorage: defaultSize: "10Gi" minSize: "5Gi" maxSize: "50Gi" defaultStorageClassName: "sagemaker-spaces-default-storage-class" defaultMountPath: "/home/sagemaker-user" defaultContainerConfig: command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"] defaultPodSecurityContext: fsGroup: 1000 defaultOwnershipType: "Public" defaultAccessStrategy: name: "hyperpod-access-strategy" allowSecondaryStorages: true appType: "jupyterlab" ``` Exemple de modèle d'éditeur de code personnalisé : ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: my-code-editor-template namespace: my-namespace spec: displayName: "My Custom Code Editor" description: "Custom Code Editor with specific configurations" defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" allowedImages: - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu" defaultResources: requests: cpu: "1" memory: "4Gi" limits: cpu: "4" memory: "16Gi" primaryStorage: defaultSize: "10Gi" minSize: "5Gi" maxSize: "50Gi" defaultStorageClassName: "sagemaker-spaces-default-storage-class" defaultMountPath: "/home/sagemaker-user" defaultContainerConfig: command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-code-editor"] defaultPodSecurityContext: fsGroup: 1000 defaultOwnershipType: "Public" defaultAccessStrategy: name: "hyperpod-access-strategy" allowSecondaryStorages: true appType: "code-editor" ```