(Optional) Migrieren von benutzerdefinierten Images und Lebenszykluskonfigurationen - Amazon SageMaker AI
Migrieren von benutzerdefinierten ImagesMigrieren von Lebenszykluskonfigurationen

(Optional) Migrieren von benutzerdefinierten Images und Lebenszykluskonfigurationen

Sie müssen Ihre benutzerdefinierten Images und LCC-Skripte (Lifecycle Configuration) aktualisieren, um mit dem vereinfachten lokalen Ausführungsmodell in Amazon SageMaker Studio arbeiten zu können. Wenn Sie in Ihrer Domain keine benutzerdefinierten Images oder Lebenszykluskonfigurationen erstellt haben, überspringen Sie diese Phase.

Amazon SageMaker Studio Classic arbeitet in einer geteilten Umgebung mit:

  • einer JupyterServer-Anwendung, auf der der Jupyter Server ausgeführt wird.

  • Studio-Classic-Notebooks, die auf einer oder mehreren KernelGateway-Anwendungen ausgeführt werden.

Studio hat keine geteilte Umgebung mehr. Studio führt JupyterLab und Code Editor aus, die auf Anwendungen von Code-OSS, Visual Studio Code – Open-Source in einem lokalen Laufzeitmodell basieren. Weitere Informationen zur Änderung der Architektur finden Sie unter Steigern der Produktivität in Amazon SageMaker Studio.

Migrieren von benutzerdefinierten Images

Ihre vorhandenen benutzerdefinierten Studio-Classic-Images funktionieren möglicherweise nicht in Studio. Wir empfehlen, ein neues benutzerdefiniertes Image zu erstellen, das die Anforderungen für die Verwendung in Studio erfüllt. Die Version von Studio vereinfacht das Erstellen benutzerdefinierter Images durch die Bereitstellung von Richtlinie zur Unterstützung von Images in SageMaker Studio. Images von SageMaker AI Distribution umfassen gängige Bibliotheken und Pakete für maschinelles Lernen, Datenwissenschaft und Datenanalysevisualisierung. Eine Liste der Basis-Images von SageMaker Distribution und Informationen zum Registry-Konto von Amazon Elastic Container finden Sie unter Amazon-SageMaker-Images, die für die Verwendung mit Notebooks von Studio Classic verfügbar sind.

Um ein benutzerdefiniertes Image zu erstellen, führen Sie einen der folgenden Schritte aus.

  • Erweitern Sie ein SageMaker-Distribution-Image mit benutzerdefinierten Paketen und Modulen. Diese Images sind mit JupyterLab und Code Editor vorkonfiguriert, basierend auf Code-OSS, Visual Studio Code – Open Source.

  • Erstellen Sie eine benutzerdefinierte Dockerfile-Datei, indem Sie den Anweisungen unter Bring Your Own Image (BYOI) folgen. Sie müssen JupyterLab und den Open-Source-CodeServer auf dem Image installieren, damit es mit Studio kompatibel ist.

Migrieren von Lebenszykluskonfigurationen

Aufgrund des vereinfachten lokalen Laufzeitmodells in Studio empfehlen wir, die Struktur Ihrer bestehenden Studio-Classic-LCCs zu migrieren. In Studio Classic ist es häufig erforderlich, separate Lebenszykluskonfigurationen für beide Anwendungen KernelGateway und JupyterServer zu erstellen. Da die Anwendungen JupyterServer und KernelGateway auf separaten Rechenressourcen innerhalb von Studio Classic ausgeführt werden, können Studio-Classic-LCCs einer der folgenden Typen sein:

  • JupyterServer-LCC: Diese LCCs regeln hauptsächlich die Aktionen eines Benutzers auf seinem Rechner, darunter die Einrichtung von Proxys, das Erstellen von Umgebungsvariablen und das automatische Herunterfahren von Ressourcen.

  • KernelGateway-LCC: Diese LCCs regeln die Optimierungen der Notebook-Umgebung von Studio Classic. Dies umfasst die Aktualisierung der Numpy-Paketversionen im Data Science 3.0-Kernel und die Installation des Snowflake-Pakets im Pytorch 2.0 GPU-Kernel.

In der vereinfachten Studio-Architektur benötigen Sie nur ein LCC-Skript, das beim Start der Anwendung ausgeführt wird. Die Migration Ihrer LCC-Skripte hängt von der Entwicklungsumgebung ab. Wir empfehlen jedoch, JupyterServer- und KernelGateway-LCCs zu kombinieren, um ein kombiniertes LCC zu erstellen.

LCCs in Studio können mit einer der folgenden Anwendungen verknüpft werden:

  • JupyterLab

  • Code Editor

Benutzer können bei der Erstellung eines Raums die LCC für den jeweiligen Anwendungstyp auswählen oder die vom Administrator festgelegte Standard-LCC verwenden.

Anmerkung

Die vorhandenen Skripte zum automatischen Herunterfahren von Studio Classic sind mit Studio nicht kompatibel. Ein Beispiel für ein Studio-Skript zum automatischen Herunterfahren finden Sie unter Beispiele für die Lebenszykluskonfiguration von SageMaker Studio.

Überlegungen zum Faktorwechsel von LCCs

Beachten Sie beim Faktorwechsel Ihrer LCCs die folgenden Unterschiede zwischen Studio Classic und Studio.

  • JupyterLab- und Code-Editor-Anwendungen werden nach ihrer Erstellung als sagemaker-user mit UID:1001 und GID:101 ausgeführt. Standardmäßig verfügt sagemaker-user über Berechtigungen, um sudo/root-Berechtigungen zu übernehmen. KernelGateway-Anwendungen werden standardmäßig als root ausgeführt.

  • SageMaker-Distribution-Images, die in JupyterLab- und Code-Editor-Anwendungen ausgeführt werden, verwenden den auf Debian basierenden Paketmanager apt-get.

  • Die Anwendungen Studio JupyterLab und Code Editor nutzen den Paketmanager Conda. SageMaker AI erstellt beim Start einer Studio-Anwendung eine einzige Basisumgebung von Python3 Conda. Informationen zum Aktualisieren von Paketen in der Conda-Basisumgebung und zum Erstellen neuer Conda-Umgebungen finden Sie unter JupyterLab-Benutzerhandbuch. Im Gegensatz dazu verwenden nicht alle KernelGateway-Anwendungen Conda als Paketmanager.

  • Die Anwendung von Studio JupyterLab verwendet JupyterLab 4.0, während Studio Classic JupyterLab 3.0 verwendet. Stellen Sie sicher, dass alle von Ihnen verwendeten JupyterLab-Erweiterungen mit JupyterLab 4.0 kompatibel sind. Weitere Informationen zu Erweiterungen finden Sie unter Erweiterungskompatibilität mit JupyterLab 4.0.