(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

(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 de cycle de vie (LCC) pour qu’ils fonctionnent avec le modèle d’exécution local simplifié dans 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 divisé 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 JupyterLab et l’éditeur de code, 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 Augmenter 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 génération d’images personnalisées en fournissant la Politique de support des images SageMaker Studio. Les images de distribution SageMaker AI incluent des bibliothèques et des packages populaires pour le machine learning, la science des données et la visualisation de l’analytique des données. Pour obtenir la liste des images de distribution SageMaker de base et les informations relatives aux comptes Amazon Elastic Container Registry, consultez Images Amazon SageMaker 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 distribution SageMaker avec des packages et des modules personnalisés. Ces images sont préconfigurées avec JupyterLab et l’éditeur 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é dans Studio, nous vous recommandons de migrer la structure de vos configurations LCC de Studio Classic existantes. 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 applications JupyterServer et KernelGateway s’exécutent sur des ressources de calcul distinctes dans Studio Classic, les configurations LCC de Studio Classic peuvent être de l’un ou l’autre type :

  • Configurations LCC JupyterServer : ces configurations régissent 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.

  • Configurations LCC KernelGateway : ces configurations régissent les optimisations de l’environnement de bloc-notes 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 les configurations LCC JupyterServer et KernelGateway pour générer une configuration LCC combinée.

Les configurations LCC dans Studio peuvent être associées à 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 voir un exemple de script d’arrêt automatique de Studio, consultez les exemples de configuration de cycle de vie de SageMaker Studio.

Considérations relatives à la refactorisation des configurations LCC

Tenez compte des différences suivantes entre Studio Classic et Studio lorsque vous refactorisez vos configurations LCC.

  • Les applications JupyterLab et d’éditeur de code, une fois créées, sont exécutées sous la forme sagemaker-user avec UID:1001 et GID:101. Par défaut, sagemaker-user dispose des autorisations nécessaires pour assumer les autorisations sudo/root. Les applications KernelGateway sont exécutées en tant que root par défaut.

  • Les images de distribution SageMaker qui s’exécutent dans les applications JupyterLab et d’éditeur de code utilisent le gestionnaire de packages basé sur Debian, apt-get.

  • Les applications Studio JupyterLab et d’éditeur de code utilisent le gestionnaire de packages Conda. SageMaker AI crée un environnement Conda du kit Python3 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 Guide de l’utilisateur JupyterLab. En revanche, toutes les applications KernelGateway n’utilisent pas Conda comme gestionnaire de packages.

  • L’application Studio JupyterLab utilise JupyterLab 4.0, tandis que Studio Classic utilise JupyterLab 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 Compatibilité des extensions avec JupyterLab 4.0.