Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
(Optional) Migrieren Sie benutzerdefinierte Images und Lebenszykluskonfigurationen
Sie müssen Ihre benutzerdefinierten Images und Lebenszykluskonfigurationsskripten (LCC) aktualisieren, damit sie mit dem vereinfachten lokalen Ausführungsmodell in Amazon SageMaker Studio funktionieren. 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:
-
Eine
JupyterServer
Anwendung, auf der das ausgeführt wird Jupyter Server. -
Studio Classic-Notebooks, die auf einer oder mehreren
KernelGateway
Anwendungen ausgeführt werden.
Studio hat sich von einer geteilten Umgebung verabschiedet. Studio führt den JupyterLab und den Code-Editor, der auf Code-OSS, Visual Studio Code — Open-Source-Anwendungen basiert, in einem lokalen Laufzeitmodell aus. Weitere Informationen zur Änderung der Architektur finden Sie unter Steigern Sie die Produktivität in Amazon SageMaker Studio
Migrieren Sie benutzerdefinierte Bilder
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 SageMaker Verteilung von Bildern von. SageMakerZu den Distributions-Images gehören beliebte Bibliotheken und Pakete für maschinelles Lernen, Datenwissenschaft und Datenanalyse-Visualisierung. Eine Liste der SageMaker Basis-Distribution-Images und Kontoinformationen der Amazon Elastic Container Registry finden Sie unter SageMaker Amazon-Bilder sind für die Verwendung mit Studio Classic verfügbar.
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 einem JupyterLab Code-Editor vorkonfiguriert, der auf Code-OSS, Visual Studio Code - Open Source basiert.
-
Erstellen Sie eine benutzerdefinierte Dockerfile-Datei, indem Sie den Anweisungen unter folgen. Dockerfile-Spezifikationen Sie müssen installieren JupyterLab und das Open Source CodeServer auf dem Bild, um es mit Studio kompatibel zu machen.
Migrieren Sie Lebenszyklus-Konfigurationen
Aufgrund des vereinfachten lokalen Laufzeitmodells in Studio empfehlen wir, die Struktur Ihres vorhandenen Studio Classic LCCs zu migrieren. In Studio Classic müssen Sie häufig separate Lebenszykluskonfigurationen für beide erstellen KernelGateway and JupyterServer Anwendungen. Weil die JupyterServer and KernelGateway Bei Anwendungen, die auf separaten Rechenressourcen in Studio Classic ausgeführt werden, LCCs kann es sich bei Studio Classic um einen der folgenden Typen handeln:
-
JupyterServer LCC: Diese regeln LCCs hauptsächlich die Home-Aktionen eines Benutzers, einschließlich der Einstellung eines Proxys, der Erstellung von Umgebungsvariablen und des automatischen Herunterfahrens von Ressourcen.
-
KernelGateway LCC: Diese LCCs regeln die Optimierungen der Studio Classic-Notebook-Umgebung. Dazu gehören die Aktualisierung der Numpy-Paketversionen im
Data Science 3.0
Kernel und die Installation des Snowflake-Pakets im Kernel.Pytorch 2.0 GPU
In der vereinfachten Studio-Architektur benötigen Sie nur ein LCC Skript, das beim Start der Anwendung ausgeführt wird. Die Migration Ihrer LCC Skripts hängt zwar von der Entwicklungsumgebung ab, wir empfehlen jedoch, sie zu kombinieren JupyterServer and KernelGateway LCCsum eine Kombination zu erstellenLCC.
LCCsin Studio kann mit einer der folgenden Anwendungen verknüpft werden:
-
JupyterLab
-
Code-Editor
Benutzer können beim Erstellen eines Bereichs den LCC für den jeweiligen Anwendungstyp auswählen oder den vom Administrator LCC festgelegten Standard verwenden.
Anmerkung
Bestehende Studio Classic-Skripts zum automatischen Herunterfahren funktionieren nicht mit Studio. Ein Beispiel für ein Studio-Skript zum automatischen Herunterfahren finden Sie unter Beispiele für die SageMaker Studio-Lebenszykluskonfiguration
Überlegungen beim Refactoring LCCs
Beachten Sie beim Refactoring Ihres die folgenden Unterschiede zwischen Studio Classic und Studio. LCCs
-
JupyterLab und Code-Editor-Anwendungen werden, wenn sie erstellt wurden, wie
sagemaker-user
mitUID:1001
und ausgeführt.GID:101
Standardmäßigsagemaker-user
ist es berechtigt, Sudo-/Root-Rechte anzunehmen. KernelGateway Anwendungen werden standardmäßig ausgeführt.root
-
SageMaker Distributions-Images, die innerhalb JupyterLab von Code Editor-Apps ausgeführt werden, verwenden die Debianbasierter Paketmanager,
apt-get
. -
Studio JupyterLab - und Code Editor-Anwendungen verwenden die Conda Paketmanager. SageMaker erstellt eine einzige Basis Python3 Conda Umgebung, wenn eine Studio-Anwendung gestartet wird. Für Informationen zum Aktualisieren von Paketen in der Basis Conda Umgebung und Schaffung neuer Conda Umgebungen, sieheJupyterLab benutzerhandbuch. Im Gegensatz dazu nicht alle KernelGateway Anwendungen verwenden Conda als Paketmanager.
-
Die JupyterLab Studio-Anwendung verwendet
JupyterLab 4.0
, während Studio Classic verwendetJupyterLab 3.0
. Bestätigen Sie das alles JupyterLab Die von Ihnen verwendeten Erweiterungen sind kompatibel mitJupyterLab 4.0
. Weitere Informationen zu Erweiterungen finden Sie unter Erweiterungskompatibilität mit JupyterLab 4.0.