(Opcional) Migre imagens personalizadas e configurações de ciclo de vida - SageMaker IA da Amazon
Migração de imagens personalizadasConfiguração de migração do ciclo de vida

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.

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 fornecendoSageMaker Política de suporte de imagem do Studio. 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 o Studio Classic.

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). 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 configuração de proxy, criação de variáveis de ambiente e 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.

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. Por outro lado, nem todas as aplicações do KernelGateway usam o Conda como gerenciador de pacotes.

  • O JupyterLab aplicativo Studio usaJupyterLab 4.0, enquanto o Studio Classic usaJupyterLab 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.