(Facultatif) Migrer des images personnalisées et des configurations de cycle de vie

Vous devez mettre à jour vos images personnalisées et vos scripts de configuration du cycle de vie (LCC) pour qu'ils fonctionnent avec le modèle d'exécution local simplifié d'Amazon SageMaker Studio. Si vous n'avez pas créé d'images personnalisées ou de configurations de cycle de vie dans votre domaine, ignorez cette phase.

Amazon SageMaker Studio Classic fonctionne dans un environnement partagé avec :

• Une JupyterServer application exécutant le Jupyter Server.

• ordinateurs portables Studio Classic exécutés sur une ou plusieurs KernelGateway applications.

Studio s'est éloigné d'un environnement divisé. Studio exécute l'éditeur de code JupyterLab and, basé sur les applications Code-OSS, Visual Studio Code - Open Source dans un modèle d'exécution local. Pour plus d'informations sur le changement d'architecture, consultez Boostez la productivité sur Amazon SageMaker Studio.

Migrer des images personnalisées

Vos images personnalisées Studio Classic existantes peuvent ne pas fonctionner dans Studio. Nous vous recommandons de créer une nouvelle image personnalisée répondant aux exigences d'utilisation dans Studio. La sortie de Studio simplifie le processus de création d'images personnalisées en fournissantSageMaker Politique de prise en charge des images de studio. SageMaker Les images AI Distribution incluent des bibliothèques et des packages populaires pour l'apprentissage automatique, la science des données et la visualisation de l'analyse des données. Pour obtenir la liste des images de SageMaker distribution de base et les informations relatives au compte Amazon Elastic Container Registry, consultezImages Amazon SageMaker AI disponibles pour une utilisation avec Studio Classic.

Pour créer une image personnalisée, effectuez l'une des opérations suivantes.

• Étendez une image de SageMaker distribution avec des packages et des modules personnalisés. Ces images sont préconfigurées avec un éditeur JupyterLab de code, basé sur Code-OSS, Visual Studio Code - Open Source.

• Créez un fichier Dockerfile personnalisé en suivant les instructions de. Spécifications de Dockerfile Vous devez installer JupyterLab et l'open source CodeServer sur l'image pour la rendre compatible avec Studio.

Migrer les configurations du cycle de

En raison du modèle d'exécution local simplifié de Studio, nous vous recommandons de migrer la structure de votre Studio Classic LCCs existant. Dans Studio Classic, vous devez souvent créer des configurations de cycle de vie distinctes pour les deux KernelGateway and JupyterServer applications. Parce que le JupyterServer and KernelGateway les applications s'exécutent sur des ressources de calcul distinctes dans Studio Classic. Studio Classic LCCs peut être de l'un ou l'autre type :

• JupyterServer LCC : Ils régissent LCCs principalement les actions personnelles d'un utilisateur, notamment la configuration du proxy, la création de variables d'environnement et l'arrêt automatique des ressources.

• KernelGateway LCC : ils LCCs régissent les optimisations de l'environnement des ordinateurs portables Studio Classic. Cela inclut la mise à jour des versions du package numpy dans le Data Science 3.0 noyau et l'installation du package snowflake dans le noyau. Pytorch 2.0 GPU

Dans l'architecture simplifiée de Studio, vous n'avez besoin que d'un seul script LCC qui s'exécute au démarrage de l'application. Bien que la migration de vos scripts LCC varie en fonction de l'environnement de développement, nous vous recommandons de combiner JupyterServer and KernelGateway LCCs pour construire un LCC combiné.

LCCs in Studio peut être associé à l'une des applications suivantes :

• JupyterLab

• Éditeur de code

Les utilisateurs peuvent sélectionner le LCC pour le type d'application correspondant lors de la création d'un espace ou utiliser le LCC par défaut défini par l'administrateur.

Note

Les scripts d'arrêt automatique de Studio Classic existants ne fonctionnent pas avec Studio. Pour un exemple de script d'arrêt automatique de Studio, consultez la section Exemples de configuration du cycle de vie de SageMaker Studio.

Considérations relatives à la refactorisation LCCs

Tenez compte des différences suivantes entre Studio Classic et Studio lors de la refactorisation de votre. LCCs

• JupyterLab et les applications Code Editor, une fois créées, sont exécutées comme sagemaker-user avec UID:1001 etGID:101. Par défaut, sagemaker-user dispose des autorisations nécessaires pour assumer les autorisations sudo/root. KernelGateway les applications sont exécutées root par défaut.

• SageMaker Les images de distribution qui s'exécutent dans JupyterLab les applications Code Editor et les applications Code Editor utilisent Debiangestionnaire de packages basé surapt-get.

• Les applications Studio JupyterLab et Code Editor utilisent Conda gestionnaire de packages. SageMaker L'IA crée une base unique Python3 Conda environnement lors du lancement d'une application Studio. Pour plus d'informations sur la mise à jour des packages dans la base Conda environnement et création de nouveaux Conda environnements, voirJupyterLab guide de l'utilisateur. En revanche, pas tous KernelGateway utilisation des applications Conda en tant que gestionnaire de packages.

• L' JupyterLab application Studio utiliseJupyterLab 4.0, tandis que Studio Classic utiliseJupyterLab 3.0. Validez tout cela JupyterLab les extensions que vous utilisez sont compatibles avecJupyterLab 4.0. Pour plus d'informations sur les extensions, consultez la section Compatibilité des extensions avec la JupyterLab version 4.0.