(Opcional) Migre imagens personalizadas e configurações de ciclo de vida - Amazon SageMaker
Migrar imagens personalizadasMigre as configurações 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 SageMaker Studio. 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:

  • Um JupyterServer aplicativo executando o Jupyter Server.

  • Notebooks Studio Classic executados em um ou mais KernelGateway aplicativos.

O Studio se afastou de um ambiente dividido. O Studio executa o JupyterLab e o Code Editor, com base nos aplicativos de código aberto Code-OSS, Visual Studio Code - 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.

Migrar 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 Imagens de distribuição. SageMakerAs imagens de distribuição 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 o JupyterLab Code Editor, baseado em Code-OSS, Visual Studio Code - Open Source.

  • Crie um arquivo Dockerfile personalizado seguindo as instruções em. Especificações do Dockerfile Você deve instalar JupyterLab e o código aberto CodeServer na imagem para torná-la compatível com o Studio.

Migre as configurações 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, você geralmente precisa criar configurações de ciclo de vida separadas para ambos KernelGateway e JupyterServer aplicações. Porque o JupyterServer e KernelGateway aplicativos executados em recursos computacionais separados no Studio Classic, o Studio Classic LCCs pode ser de qualquer tipo:

  • JupyterServer LCC: 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.

  • KernelGateway LCC: Eles LCCs governam as otimizações do ambiente do notebook Studio Classic. Isso inclui atualizar as versões do pacote numpy no Data Science 3.0 kernel e instalar o pacote snowflake no kernel. Pytorch 2.0 GPU

Na arquitetura simplificada do Studio, você só precisa de um LCC script que seja executado na inicialização do aplicativo. Embora a migração de seus LCC scripts varie com base no ambiente de desenvolvimento, recomendamos combinar JupyterServer e KernelGateway LCCspara construir um combinadoLCC.

LCCsno Studio pode ser associado a um dos seguintes aplicativos:

  • JupyterLab

  • Editor de código

Os usuários podem selecionar o LCC para o respectivo tipo de aplicativo ao criar um espaço ou usar o padrão LCC definido 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 permissões sudo/root. KernelGateway os aplicativos são root executados como padrão.

  • SageMaker As imagens de distribuição que são executadas internamente JupyterLab e os aplicativos do Code Editor usam o Debiangerenciador de pacotes baseado,apt-get.

  • Os aplicativos Studio JupyterLab e Code Editor usam o Conda gerenciador de pacotes. SageMaker cria uma única base Python3 Conda ambiente quando um aplicativo Studio é iniciado. Para obter informações sobre a atualização de pacotes na base Conda ambiente e criação de novos Conda ambientes, vejaJupyterLab guia do usuário. Em contraste, nem todos KernelGateway uso de aplicativos Conda como gerenciador de pacotes.

  • O JupyterLab aplicativo Studio usaJupyterLab 4.0, enquanto o Studio Classic usaJupyterLab 3.0. Valide tudo isso JupyterLab as extensões que você usa são compatíveis comJupyterLab 4.0. Para obter mais informações sobre extensões, consulte Compatibilidade de extensões com JupyterLab 4.0.