View a markdown version of this page

(Facoltativo) Migrazione di immagini personalizzate e configurazioni del ciclo di vita - Amazon SageMaker AI
Migrazione di immagini personalizzateMigrazione delle configurazioni del ciclo di vita

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

(Facoltativo) Migrazione di immagini personalizzate e configurazioni del ciclo di vita

È necessario aggiornare le immagini personalizzate e gli script di configurazione del ciclo di vita (LCC) per utilizzare il modello di esecuzione locale semplificato di Amazon Studio. SageMaker Se non hai creato immagini o configurazioni del ciclo di vita personalizzate nel tuo dominio, salta questa fase.

Amazon SageMaker Studio Classic funziona in un ambiente diviso con:

  • Un’applicazione JupyterServer che esegue il Jupyter Server.

  • Notebook Studio Classic eseguiti su una o più applicazioni KernelGateway.

Studio non utilizza più un ambiente diviso. Studio esegue le applicazioni JupyterLab and Code Editor, basate su Visual Studio Code - Open Source Code-OSS, in un modello di runtime locale. Per ulteriori informazioni sulla modifica dell'architettura, consulta Aumentare la produttività su Amazon SageMaker Studio.

Migrazione di immagini personalizzate

Le immagini personalizzate esistenti di Studio Classic potrebbero non funzionare in Studio. Ti consigliamo di creare una nuova immagine personalizzata che soddisfi i requisiti di Studio. La versione di Studio semplifica il processo di creazione di immagini personalizzate fornendoSageMaker Politica di supporto delle immagini di Studio. SageMaker Le immagini di AI Distribution includono librerie e pacchetti popolari per l'apprendimento automatico, la scienza dei dati e la visualizzazione dell'analisi dei dati. Per un elenco delle immagini di SageMaker distribuzione di base e informazioni sull'account Amazon Elastic Container Registry, consultaSageMaker Immagini Amazon disponibili per l'uso con i notebook Studio Classic.

Per creare un’immagine personalizzata, utilizza una delle operazioni seguenti.

  • Estendi un'immagine di SageMaker distribuzione con pacchetti e moduli personalizzati. Queste immagini sono preconfigurate con un JupyterLab editor di codice basato su Code-OSS Visual Studio Code - Open Source.

  • Crea un file Dockerfile personalizzato seguendo le istruzioni riportate in Bring Your Own Image (BYOI). Per assicurare la compatibilità con Studio, devi installare JupyterLab e CodeServer open source sull’immagine.

Migrazione delle configurazioni del ciclo di vita

Se utilizzi il modello di runtime locale semplificato di Studio, ti consigliamo di eseguire la migrazione della struttura delle LCC esistenti di Studio Classic. In Studio Classic, spesso è necessario creare configurazioni del ciclo di vita separate per entrambe le applicazioni, KernelGateway e JupyterServer. Poiché le applicazioni JupyterServer e KernelGateway vengono eseguite su risorse di calcolo separate all’interno di Studio Classic, le LCC di Studio Classic possono essere di due tipi:

  • LCC JupyterServer: queste LCC gestiscono principalmente le azioni domestiche di un utente, tra cui l’impostazione del proxy, la creazione di variabili di ambiente e lo spegnimento automatico delle risorse.

  • LCC KernelGateway: queste LCC regolano le ottimizzazioni dell’ambiente del notebook Studio Classic. Queste includono l’aggiornamento delle versioni del pacchetto numpy nel kernel Data Science 3.0 e l’installazione del pacchetto snowflake nel kernel Pytorch 2.0 GPU.

Nell’architettura semplificata di Studio, è necessario solo uno script LCC da eseguire all’avvio dell’applicazione. Sebbene la migrazione delle LCC vari in base all’ambiente di sviluppo, consigliamo di combinare le LCC JupyterServer e KernelGateway per creare una LCC combinata.

Le LCC in Studio possono essere associate a una delle applicazioni seguenti:

  • JupyterLab

  • Editor di codici

Gli utenti possono selezionare la LCC per il rispettivo tipo di applicazione durante la creazione di uno spazio oppure possono utilizzare la LCC predefinita impostata dall’amministratore.

Nota

Gli script di spegnimento automatico di Studio Classic esistenti non funzionano con Studio. Per un esempio di script di spegnimento automatico di Studio, consulta Esempi di configurazione del ciclo di vita di SageMaker Studio.

Considerazioni sulla rifattorizzazione delle LCC

Considera queste differenze tra Studio Classic e Studio quando rifattorizzi le LCC.

  • JupyterLab e le applicazioni Code Editor, una volta create, vengono eseguite come con e. sagemaker-user UID:1001 GID:101 Per impostazione predefinita, sagemaker-user dispone delle autorizzazioni necessarie per assumere le sudo/root autorizzazioni. KernelGatewayle applicazioni vengono eseguite come impostazione root predefinita.

  • SageMaker Le immagini di distribuzione eseguite all'interno delle app Code Editor JupyterLab e Code Editor utilizzano il gestore di pacchetti Debian basato,apt-get.

  • Le applicazioni Studio JupyterLab e Code Editor utilizzano il gestore di Conda pacchetti. SageMaker L'intelligenza artificiale crea un unico Python3 Conda ambiente di base all'avvio di un'applicazione Studio. Per informazioni sull’aggiornamento dei pacchetti nell’ambiente Conda di base e sulla creazione di nuovi ambienti Conda, consulta JupyterLab guida per l'utente. D’altro canto, non tutte le applicazioni KernelGateway utilizzano Conda come gestore dei pacchetti.

  • L' JupyterLab applicazione Studio utilizzaJupyterLab 4.0, mentre Studio Classic utilizzaJupyterLab 3.0. Verifica che tutte le estensioni JupyterLab che utilizzi siano compatibili con JupyterLab 4.0. Per ulteriori informazioni sulle estensioni, consulta Compatibilità delle estensioni con JupyterLab 4.0.