Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Fase 2: (opcional) Migrar imágenes personalizadas y configuraciones del ciclo de vida
Debe actualizar las imágenes personalizadas y los scripts de configuración del ciclo de vida (LCC) para que funcionen con el modelo de ejecución local simplificado de Amazon SageMaker Studio. Si no ha creado imágenes personalizadas o configuraciones de ciclo de vida en su dominio, omita esta fase.
Amazon SageMaker Studio Classic funciona en un entorno dividido con:
-
Una
JupyterServer
aplicación que ejecuta elJupyter Server. -
Cuadernos Studio Classic que se ejecutan en una o más
KernelGateway
aplicaciones.
Studio ha dejado de ser un entorno dividido. Studio ejecuta el editor de código JupyterLab y, basado en aplicaciones Code-OSS y Visual Studio Code y código abierto, en un modelo de tiempo de ejecución local. Para obtener más información sobre el cambio de arquitectura, consulte Aumentar la productividad en Amazon SageMaker Studio
Migre imágenes personalizadas
Es posible que las imágenes personalizadas de Studio Classic que ya tengas no funcionen en Studio. Te recomendamos crear una nueva imagen personalizada que cumpla los requisitos para su uso en Studio. La versión de Studio simplifica el proceso de creación de imágenes personalizadas al proporcionar. SageMaker Imágenes de distribución SageMakerLas imágenes de distribución incluyen bibliotecas y paquetes populares para el aprendizaje automático, la ciencia de datos y la visualización del análisis de datos. Para obtener una lista de las imágenes de SageMaker distribución base y la información de la cuenta de Amazon Elastic Container Registry, consulte SageMaker Imágenes de Amazon disponibles para su uso con Studio Classic.
Para crear una imagen personalizada, complete una de las siguientes acciones.
-
Amplíe una imagen de SageMaker distribución con paquetes y módulos personalizados. Estas imágenes vienen preconfiguradas con un JupyterLab editor de código, basado en Code-OSS, Visual Studio Code: Open Source.
-
Cree un archivo Dockerfile personalizado siguiendo las instrucciones de. Especificaciones de Dockerfile Debe instalar JupyterLab el código abierto de CodeServer la imagen para que sea compatible con Studio.
Migre las configuraciones del ciclo
Debido al modelo de tiempo de ejecución local simplificado de Studio, recomendamos migrar la estructura de las LCC clásicas de Studio existentes. En Studio Classic, a menudo tienes que crear configuraciones de ciclo de vida independientes para ambas KernelGateway aplicaciones. JupyterServer Como las KernelGateway aplicaciones JupyterServer y las aplicaciones se ejecutan en recursos informáticos independientes en Studio Classic, las LCC de Studio Classic pueden ser de cualquier tipo:
-
JupyterServerLCC: estas LCC rigen principalmente las acciones domésticas del usuario, incluida la configuración del proxy, la creación de variables de entorno y el cierre automático de los recursos.
-
KernelGatewayLCC: estas LCC regulan las optimizaciones del entorno de los portátiles Studio Classic. Esto incluye actualizar las versiones de los paquetes numpy en el
Data Science 3.0
núcleo e instalar el paquete snowflake en el núcleo.Pytorch 2.0 GPU
En la arquitectura simplificada de Studio, solo se necesita un script de LCC que se ejecute al iniciar la aplicación. Si bien la migración de los scripts de LCC varía en función del entorno de desarrollo, recomendamos combinar JupyterServer y KernelGateway LCC para crear una LCC combinada.
Las LCC de Studio se pueden asociar a una de las siguientes aplicaciones:
-
JupyterLab
-
Editor de código
Los usuarios pueden seleccionar la LCC para el tipo de aplicación correspondiente al crear un espacio o usar la LCC predeterminada establecida por el administrador.
nota
Los scripts de apagado automático de Studio Classic existentes no funcionan con Studio. Para ver un ejemplo de script de apagado automático de Studio, consulta los ejemplos de configuración del ciclo de vida de SageMaker Studio
Consideraciones a la hora de refactorizar las LCC
Tenga en cuenta las siguientes diferencias entre Studio Classic y Studio al refactorizar sus LCC.
-
JupyterLab y las aplicaciones de editor de código, una vez creadas, se ejecutan igual que con y.
sagemaker-user
UID:1001
GID:101
De forma predeterminada,sagemaker-user
tiene permisos para asumir permisos sudo/root. KernelGatewaylas aplicaciones se ejecutan de formaroot
predeterminada. -
SageMaker Las imágenes de distribución que se ejecutan dentro de las aplicaciones JupyterLab y el editor de código utilizan el administrador de paquetes Debian basado,
apt-get
. -
Las aplicaciones Studio JupyterLab y Code Editor utilizan el administrador de Conda paquetes. SageMaker crea un Python3 Conda entorno base único cuando se inicia una aplicación de Studio. Para obtener información sobre la actualización de paquetes en el Conda entorno base y la creación de nuevos Conda entornos, consulteJupyterLab guía de usuario. Por el contrario, no todas las KernelGateway aplicaciones Conda se utilizan como gestores de paquetes.
-
La JupyterLab aplicación Studio usa
JupyterLab 4.0
, mientras que Studio Classic usaJupyterLab 3.0
. Comprueba que todas las JupyterLab extensiones que utilices sean compatibles con ellasJupyterLab 4.0
. Para obtener más información sobre las extensiones, consulte Compatibilidad de extensiones con la JupyterLab versión 4.0.