(Facultatif) Migration d’images personnalisées et de configurations de cycle de vie - Amazon SageMaker AI
Migration des images personnaliséesMigration des configurations de cycle de vie

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.

(Facultatif) Migration d’images personnalisées et de 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 application JupyterServer exécutant le Jupyter Server ;

  • des blocs-notes Studio Classic exécutés sur une ou plusieurs applications KernelGateway.

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.

Migration 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, consultezAmazon SageMaker Images disponibles pour une utilisation avec les blocs-notes Studio Classic.

Pour générer 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 fournies dans Apporter votre propre image (BYOI). Vous devez installer JupyterLab et le serveur CodeServer open source sur l’image pour la rendre compatible avec Studio.

Migration des configurations de cycle de vie

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 applications KernelGateway et JupyterServer. Étant donné que les KernelGateway applications JupyterServer et s'exécutent sur des ressources de calcul distinctes dans Studio Classic, Studio Classic LCCs peut être de l'un ou l'autre type :

  • JupyterServerLCC : 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.

  • KernelGatewayLCC : 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 noyau Data Science 3.0 et l’installation du package snowflake dans le noyau Pytorch 2.0 GPU.

Dans l’architecture Studio simplifiée, 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 et KernelGateway LCCs de créer un LCC combiné.

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

  • JupyterLab

  • Éditeur de code

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

Note

Les scripts existants d’arrêt automatique de Studio Classic 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 sudo/root des autorisations. KernelGatewayles applications sont exécutées root par défaut.

  • SageMaker Les images de distribution qui s'exécutent dans JupyterLab les applications de l'éditeur de code et de l'éditeur de code utilisent le gestionnaire de packages Debian basé surapt-get.

  • Les applications Studio JupyterLab et Code Editor utilisent le gestionnaire de Conda packages. SageMaker L'IA crée un Python3 Conda environnement de base unique lorsqu'une application Studio est lancée. Pour en savoir plus sur la mise à jour des packages dans l’environnement Conda de base et la création de nouveaux environnements Conda, consultez JupyterLab guide de l'utilisateur. En revanche, toutes les applications KernelGateway n’utilisent pas Conda comme gestionnaire de packages.

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