Gestione degli ambienti
È possibile eseguire attività di gestione degli ambienti, come la creazione o la personalizzazione di un modello di ambiente, l'arresto dei runtime e la promozione degli ambienti in uno spazio di distribuzione. È necessario disporre del ruolo Amministratore o dell' Editor in un progetto.
- Modificare il template di ambiente di un notebook
- Promuovere un modello di ambiente a uno spazio
- Arresta runtime attivi
- Aggiornamento ed eliminazione delle definizioni di runtime personalizzate
Modifica dell'ambiente di un notebook
È possibile cambiare ambiente per diversi motivi, ad esempio, è possibile:
- Selezionare un ambiente con più potenza di elaborazione o più RAM
- Passaggio dall'utilizzo di un ambiente senza Spark a un ambiente Spark
È possibile modificare l'ambiente di un notebook solo se il notebook è sbloccato. È possibile modificare l'ambiente:
Dal notebook aperto in modalità di modifica:
- Salvare le modifiche del notebook.
- Fare clic sull'icona Informazioni sul blocco note (
) nella barra degli strumenti del blocco note, quindi fare clic su Ambiente. - Selezionare un altro modello con la capacità di calcolo e la capacità di memoria dall'elenco.
- Selezionare Modifica ambiente. Questo arresta il runtime attivo e avvia l'ambiente appena selezionato.
Dalla pagina Asset del progetto:
- Selezionare il blocco note nella sezione Blocco note, fare clic su Azioni> Modifica ambiente e selezionare un altro ambiente. Il kernel deve essere arrestato prima di poter modificare l'ambiente. Questo nuovo ambiente di runtime verrà istanziato la volta successiva che il notebook viene aperto per la modifica.
Promuovere un modello di ambiente in uno spazio
Se hai creato un modello di ambiente e lo hai associato a una risorsa che hai promosso in uno spazio di distribuzione, puoi promuovere anche il modello di ambiente nello stesso spazio. La promozione del modello di ambiente nello stesso spazio consente di eseguire la risorsa nello stesso ambiente utilizzato nel progetto.
Puoi promuovere solo i modelli di ambiente che hai creato tu. Tuttavia, non è possibile promuovere un modello di ambiente personalizzato se questo utilizza un'immagine di runtime personalizzata. In questo caso, è necessario utilizzare un'immagine separata per Watson Machine Learning creata da un amministratore.
Per promuovere un modello di ambiente associato a una risorsa che è stata promossa in uno spazio di distribuzione:
- Nella scheda Gestisci del tuo progetto, nella pagina Ambienti alla voce Modelli, seleziona il modello di ambiente personalizzato e fai clic su Azioni > Promuovi.
- Seleziona lo spazio in cui hai promosso la tua risorsa come spazio di distribuzione di destinazione e, se lo desideri, inserisci una descrizione e dei tag.
Arresto dei runtime attivi
I runtime dei Jupyter Notebook vengono avviati per utente e non per singolo notebook. L'arresto del kernel di un notebook non interrompe l'esecuzione dell'ambiente in cui il kernel è stato avviato, poiché altri notebook potrebbero essere stati avviati nello stesso ambiente. Interrompi l'esecuzione di un notebook solo se sei sicuro che non ci siano altri kernel di notebook attivi.
Solo i processi di esecuzione avviati per i lavori vengono chiusi automaticamente al termine del lavoro pianificato. Ad esempio, se si pianifica l'esecuzione di un notebook una volta al giorno per due mesi, l'istanza di runtime viene attivata ogni giorno per la durata del processo pianificato e disattivata nuovamente al termine dello stesso.
Gli utenti del progetto con il ruolo di amministratore possono arrestare tutti i runtime del progetto. Gli utenti aggiunti al progetto con il ruolo di Editor possono arrestare le istanze di runtime da loro avviate, ma non possono arrestare quelle avviate da altri utenti del progetto. Gli utenti aggiunti al progetto con il ruolo di "Viewer" non possono visualizzare i runtime presenti nel progetto.
È possibile arrestare i runtime nella sezione " Tool runtimes " della pagina "Ambienti ", nella scheda "Gestisci" del proprio progetto.
Timeout predefiniti in stato di inattività
Se non si interrompe un'istanza attiva quando non è più necessaria, questa verrà interrotta automaticamente dopo un periodo di inattività prestabilito.
La tabella seguente mostra i valori predefiniti del timeout di inattività per i runtime, suddivisi per strumento e tipo di runtime.
| Strumento | Timeout di inattività durante l'esecuzione |
|---|---|
| editor notebook Jupyter | Tempi di esecuzione su CPU e GPU: 18 ore Tempi di esecuzione su Spark: 30 minuti |
| JupyterLab | Tempi di esecuzione su CPU e GPU: 18 ore Tempi di esecuzione su Spark: 30 minuti |
| RStudio | 2 ore |
| SPSS Modeler | 15 minuti |
Gli amministratori del cluster possono disabilitare il timeout di inattività predefinito per i runtime CPU e GPU e per RStudio. Per ulteriori dettagli, consultare la sezione "Disattivazione del timeout predefinito di inattività della CPU e della GPU ".
La modifica di questo timeout di inattività non influisce sui processi. Si applica solo ai contenuti interattivi.
Migrazione dei modelli di ambiente personalizzati da Runtime 24.1 a Runtime 25.1
In Runtime 25.1, anziché una combinazione di conda ambienti virtuali e conda gestore di pacchetti, viene utilizzata una combinazione di ambienti virtuali Python i e pip gestore di pacchetti.
Se utilizzi i pacchetti predefiniti di un runtime, non noterai alcuna differenza. Tuttavia, se hai apportato qualsiasi tipo di personalizzazione ai pacchetti (all'interno di un notebook o tramite un ambiente personalizzato) in un modello di ambiente basato su Runtime 24.1 e che utilizza conda, devi migrarlo prima che Runtime 24.1 venga rimosso.
Pacchetti aggiuntivi installati su un notebook
| Prima | Dopo | Note |
|---|---|---|
Stai utilizzando pip per installare pacchetti aggiuntivi |
Non sono necessarie modifiche | N/D |
Stai utilizzando conda per installare pacchetti aggiuntivi python |
Cerca il pacchetto corrispondente su PyPI e usa pip per installarlo. |
Se il pip pacchetto richiede librerie di sistema aggiuntive che non sono incluse nel pacchetto stesso e che non sono presenti nelle immagini predefinite, consigliamo di verificare innanzitutto se esiste un'alternativa valida che non richieda librerie di sistema aggiuntive. Se ciò non fosse possibile, contatta l'assistenza di IBM. |
Stai utilizzando conda per installare pacchetti aggiuntivi R |
L'installazione di pacchetti aggiuntivi R non è più supportata. |
Contatta l'assistenza di IBM se la tua attività richiede pacchetti aggiuntivi R . |
Pacchetti aggiuntivi installati tramite ambienti personalizzati
| Prima | Dopo | Note |
|---|---|---|
Hai utilizzato solo la pip sezione del conda.yaml |
Converti in requirements.txt formato |
Non sono necessarie modifiche, se non quella relativa al formato. Vedi l'esempio |
Sono python presenti voci di pacchetto al di fuori della pip sezione |
Trova i file di sostituzione dell' PyPI e per conda i pacchetti e aggiungili a requirements.txt |
Se il pip pacchetto richiede librerie di sistema aggiuntive che non sono incluse nel pacchetto stesso e che non sono presenti nelle immagini predefinite, consigliamo di verificare innanzitutto se esiste un'alternativa valida che non richieda librerie di sistema aggiuntive. Se ciò non fosse possibile, contatta l'assistenza di IBM. |
Sono R presenti voci di pacchetto al di fuori della pip sezione |
L'installazione di pacchetti aggiuntivi R non è più supportata. |
Contatta l'assistenza di IBM se la tua attività richiede pacchetti aggiuntivi R . |
Trasferimento dei requisiti da conda.yaml a requirements.txt
Per spostare i requisiti da conda.yaml a requirements.txt, estrarre tutti i pacchetti dalla pip sezione e poi elencarli nel requirements.txt file (un pacchetto per riga):
Vecchio: conda.yaml
dependencies:
- pip:
- pandas==1.5.0
- numpy==1.23.0
- scikit-learn==1.1.0
Novità: requirements.txt
pandas==1.5.0
numpy==1.23.0
scikit-learn==1.1.0