As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# (Opcional) Migre imagens personalizadas e configurações de ciclo de vida
Você deve atualizar suas imagens personalizadas e scripts de configuração do ciclo de vida (LCC) para trabalhar com o modelo de execução local simplificado no Amazon Studio. SageMaker Se você não criou imagens personalizadas ou configurações de ciclo de vida em seu domínio, pule esta fase.
O Amazon SageMaker Studio Classic opera em um ambiente dividido com:
+ Uma aplicação do `JupyterServer` executando o Jupyter Server.
+ Cadernos do Studio Classic em execução em um ou mais aplicações do `KernelGateway`.
O Studio se afastou de um ambiente dividido. O Studio executa o JupyterLab e o Code Editor, com base nos aplicativos Code-OSS, Visual Studio Code - Open Source em um modelo de tempo de execução local. Para obter mais informações sobre a mudança na arquitetura, consulte [Aumentar a produtividade no Amazon SageMaker Studio](https://aws.amazon.com/blogs//machine-learning/boost-productivity-on-amazon-sagemaker-studio-introducing-jupyterlab-spaces-and-generative-ai-tools/).
## Migração de imagens personalizadas
Suas imagens personalizadas existentes do Studio Classic podem não funcionar no Studio. Recomendamos criar uma nova imagem personalizada que atenda aos requisitos de uso no Studio. O lançamento do Studio simplifica o processo de criação de imagens personalizadas fornecendo[SageMaker Política de suporte de imagem do Studio](sagemaker-distribution.md). SageMaker As imagens de distribuição de IA incluem bibliotecas e pacotes populares para visualização de aprendizado de máquina, ciência de dados e análise de dados. Para obter uma lista de imagens básicas de SageMaker distribuição e informações da conta do Amazon Elastic Container Registry, consulte[SageMaker Imagens da Amazon disponíveis para uso com notebooks Studio Classic](notebooks-available-images.md).
Para criar uma imagem personalizada, preencha uma das opções a seguir.
+ Estenda uma imagem de SageMaker distribuição com pacotes e módulos personalizados. Essas imagens são pré-configuradas com um editor JupyterLab de código, baseado em Code-OSS, Visual Studio Code - Open Source.
+ Crie um arquivo Dockerfile personalizado seguindo as instruções em [Traga sua própria imagem (BYOI)](studio-updated-byoi.md). Você deve instalar JupyterLab e o código aberto CodeServer na imagem para torná-la compatível com o Studio.
## Configuração de migração do ciclo de vida
Devido ao modelo simplificado de tempo de execução local no Studio, recomendamos migrar a estrutura do seu Studio Classic LCCs existente. No Studio Classic, geralmente é necessário criar configurações de ciclo de vida separadas para ambos e para as aplicações do KernelGateway e JupyterServer. Como os KernelGateway aplicativos JupyterServer e são executados em recursos computacionais separados no Studio Classic, o Studio Classic LCCs pode ser de qualquer tipo:
+ JupyterServerLCC: elas controlam LCCs principalmente as ações domésticas do usuário, incluindo a configuração do proxy, a criação de variáveis de ambiente e o desligamento automático de recursos.
+ KernelGatewayLCC: Eles LCCs controlam as otimizações do ambiente do notebook Studio Classic. Isso inclui a atualização das versões do pacote numpy no kernel `Data Science 3.0` e a instalação do pacote snowflake no kernel `Pytorch 2.0 GPU`.
Na arquitetura simplificada do Studio, você só precisa de um script de LCC que seja executado na inicialização da aplicação. Embora a migração de seus scripts de LCC varie com base no ambiente de desenvolvimento, recomendamos combinar JupyterServer e KernelGateway LCCs criar uma LCC combinada.
LCCs no Studio pode ser associado a um dos seguintes aplicativos:
+ JupyterLab
+ Editor de código
Os usuários podem selecionar a LCC para o respectivo tipo de aplicação ao criar um espaço ou usar a LCC padrão definida pelo administrador.
**nota**
Os scripts de desligamento automático existentes do Studio Classic não funcionam com o Studio. Para ver um exemplo do script de desligamento automático do Studio, consulte Exemplos de configuração do [ciclo de vida do SageMaker Studio](https://github.com/aws-samples/sagemaker-studio-apps-lifecycle-config-examples).
### Considerações ao refatorar LCCs
Considere as seguintes diferenças entre o Studio Classic e o Studio ao refatorar seu. LCCs
+ JupyterLab e os aplicativos do Code Editor, quando criados, são executados como `sagemaker-user` com `UID:1001` `GID:101` e. Por padrão, `sagemaker-user` tem permissões para assumir sudo/root permissões. KernelGatewayos aplicativos são `root` executados como padrão.
+ SageMaker As imagens de distribuição que são executadas dentro JupyterLab e os aplicativos do Code Editor usam o gerenciador de pacotes Debian baseado,`apt-get`.
+ Os aplicativos Studio JupyterLab e Code Editor usam o gerenciador de Conda pacotes. SageMaker A IA cria um Python3 Conda ambiente básico único quando um aplicativo Studio é lançado. Para informações sobre a atualização de pacotes no ambiente Conda base e a criação de novos ambientes Conda, consulte [JupyterLab guia do usuário](studio-updated-jl-user-guide.md). Por outro lado, nem todas as aplicações do KernelGateway usam o Conda como gerenciador de pacotes.
+ O JupyterLab aplicativo Studio usa`JupyterLab 4.0`, enquanto o Studio Classic usa`JupyterLab 3.0`. Verifique se todas as extensões do JupyterLab que você usa são compatíveis com o `JupyterLab 4.0`. Para obter mais informações sobre extensões, consulte [Compatibilidade de extensões com JupyterLab 4.0](https://github.com/jupyterlab/jupyterlab/issues/14590).