フェーズ 2: (オプション) カスタムイメージとライフサイクル設定を移行する

Amazon SageMaker Studio で簡略化されたローカル実行モデルを使用するには、カスタムイメージとライフサイクル設定 (LCC) スクリプトを更新する必要があります。ドメインにカスタムイメージまたはライフサイクル設定を作成していない場合は、このフェーズをスキップします。

Amazon SageMaker Studio Classic は、分割環境で以下の操作を行います。

• を実行するJupyterServerアプリケーションJupyter Server。

• 1 つ以上のKernelGatewayアプリケーションで実行されている Studio Classic ノートブック。

Studio が分割環境から移行しました。Studio は、ローカルランタイムモデルで Code-OSS、Visual Studio Code - Open Source アプリケーションに基づいて、 JupyterLab および Code Editor を実行します。アーキテクチャの変更の詳細については、「Amazon SageMaker Studio での生産性の向上」を参照してください。

カスタムイメージの移行

既存の Studio Classic カスタムイメージが Studio で機能しない場合があります。Studio での使用要件を満たす新しいカスタムイメージを作成することをお勧めします。Studio のリリースにより、 を提供することでカスタムイメージの構築プロセスが簡素化されますSageMaker ディストリビューションイメージ。 SageMaker ディストリビューションイメージには、機械学習、データサイエンス、データ分析の視覚化用の一般的なライブラリとパッケージが含まれています。基本ディス SageMaker トリビューションイメージと Amazon Elastic Container Registry アカウント情報のリストについては、「」を参照してくださいStudio Classic で使用できる Amazon SageMaker イメージ。

カスタムイメージを構築するには、次のいずれかを実行します。

• カスタムパッケージとモジュールを使用して SageMaker ディストリビューションイメージを拡張します。これらのイメージは、Code-OSS、Visual Studio Code - Open Source に基づいて、 JupyterLab および Code Editor で事前設定されています。

• 「」の手順に従って、カスタム Dockerfile ファイルを構築しますDockerfile の仕様。Studio と互換性を持たせるには、イメージCodeServerに JupyterLabとオープンソースをインストールする必要があります。

ライフサイクル設定の移行

Studio ではローカルランタイムモデルが簡略化されているため、既存の Studio Classic LCCsの構造を移行することをお勧めします。Studio Classic では、多くの場合、 KernelGatewayと JupyterServer アプリケーションの両方に対して個別のライフサイクル設定を作成する必要があります。JupyterServer および KernelGatewayアプリケーションは Studio Classic 内の個別のコンピューティングリソースで実行されるため、Studio Classic LCCsはどちらのタイプでもかまいません。

• JupyterServer LCC: これらの LCCsは主に、プロキシの設定、環境変数の作成、リソースの自動シャットダウンなど、ユーザーのホームアクションを管理します。

• KernelGateway LCC: これらの LCCs Studio Classic ノートブック環境の最適化を管理します。これには、カーネルの numpy Data Science 3.0 パッケージバージョンの更新と、カーネルの snowflake Pytorch 2.0 GPU パッケージのインストールが含まれます。

簡略化された Studio アーキテクチャでは、アプリケーションの起動時に実行される LCC スクリプトは 1 つだけ必要です。LCC スクリプトの移行は開発環境によって異なりますが、 JupyterServerと KernelGateway LCCsを組み合わせて結合 LCC を構築することをお勧めします。

Studio LCCs は、次のいずれかのアプリケーションに関連付けることができます。

• JupyterLab

• コードエディタ

ユーザーは、スペースの作成時にそれぞれのアプリケーションタイプの LCC を選択するか、管理者が設定したデフォルトの LCC を使用できます。

注記

既存の Studio Classic 自動シャットダウンスクリプトは Studio では機能しません。Studio 自動シャットダウンスクリプトの例については、SageMaker 「Studio ライフサイクル設定の例」を参照してください。

LCCsリファクタリングする際の考慮事項

LCCs をリファクタリングするときは、Studio Classic と Studio の次の違いを考慮してください。

• JupyterLab および Code Editor アプリケーションは、作成時に UID:1001および sagemaker-userと同様に実行されますGID:101。デフォルトでは、 sagemaker-userには sudo/root アクセス許可を引き受けるアクセス許可があります。 KernelGatewayアプリケーションはrootデフォルトで として実行されます。

• SageMaker JupyterLab および Code Editor アプリ内で実行されるディストリビューションイメージは、 Debianベースのパッケージマネージャー を使用しますapt-get。

• Studio アプリケーション JupyterLab とコードエディタアプリケーションは、Condaパッケージマネージャーを使用します。Studio アプリケーションの起動時に 1 つのベースPython3Conda環境 SageMaker を作成します。ベースConda環境でパッケージを更新し、新しいConda環境を作成する方法については、「」を参照してくださいJupyterLab ユーザーガイド。対照的に、すべてのKernelGatewayアプリケーションがパッケージマネージャーCondaとして を使用するわけではありません。

• Studio JupyterLab アプリケーションは を使用しJupyterLab 4.0、Studio Classic は を使用しますJupyterLab 3.0。使用するすべてのJupyterLab拡張機能が と互換性があることを確認しますJupyterLab 4.0。拡張機能の詳細については、「 Extension Compatibility with JupyterLab 4.0」を参照してください。