

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# アドオンをカスタマイズする
<a name="customization"></a>

## テンプレート
<a name="customization-template"></a>

テンプレートは再利用可能なワークスペース設定であり、ワークスペース作成の管理者が管理する設計図として機能します。ワークスペース設定値のデフォルトと、データサイエンティストが実行できる操作を制御するガードレールを提供します。テンプレートはクラスターレベルに存在し、名前空間間で再利用できます。

SageMaker Spaces は、データサイエンティストの開始点として 2 つのシステムテンプレートを作成します。1 つはコードエディタ用、もう 1 つは JupyterLab 用です。これらのシステムテンプレートはアドオンによって管理され、直接編集することはできません。代わりに、管理者は新しいテンプレートを作成し、デフォルトとして設定できます。

## タスクガバナンス
<a name="customization-governabce"></a>

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: my-jupyter-template
  namespace: my-namespace
  labels:
    kueue.x-k8s.io/priority-class: <user-input>-priority
spec:
  displayName: "My Custom Jupyter Lab"
  description: "Custom Jupyter Lab with specific configurations"
  defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
  allowedImages:
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  defaultResources:
    requests:
      cpu: "1"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "16Gi"
  primaryStorage:
    defaultSize: "10Gi"
    minSize: "5Gi"
    maxSize: "50Gi"
    defaultStorageClassName: "sagemaker-spaces-default-storage-class"
    defaultMountPath: "/home/sagemaker-user"
  defaultContainerConfig:
    command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"]
  defaultPodSecurityContext:
    fsGroup: 1000
  defaultOwnershipType: "Public"
  defaultAccessStrategy:
    name: "hyperpod-access-strategy"
  allowSecondaryStorages: true
  appType: "jupyterlab"
```

## SMD / カスタムイメージ
<a name="customization-image"></a>

お客様は、デフォルトのイメージと許可されたイメージのリストを提供することで、 テンプレートを使用してイメージポリシーを設定できます。さらに、管理者はデータサイエンティストに独自のカスタムイメージの持ち込みを許可するかどうかを選択できます。システムはデフォルトで最新の SageMaker ディストリビューションを使用しますが、特定のバージョンに固定する場合は、テンプレートで使用する正確な SMD バージョンを指定できます。

カスタムイメージの要件:
+ `curl` アイドルシャットダウンを使用する場合
+ ポート 8888
+ リモートアクセス

## リモート IDE 要件
<a name="remote-ide-requirement"></a>

### VS Code バージョン要件
<a name="remote-ide-requirement-vscode"></a>

VS Code バージョン [v1.90](https://code.visualstudio.com/updates/v1_90) 以降が必要です。[VS Code の最新の安定したバージョン](https://code.visualstudio.com/updates)を使用することをお勧めします。

### オペレーティングシステムの要件
<a name="remote-ide-requirement-operate"></a>

Studio スペースにリモート接続するには、次のいずれかのオペレーティングシステムが必要です。
+ macOS 13 以降
+ Windows 10
  + [Windows 10 のサポートは、2025 年 10 月 14 日に終了します。](https://support.microsoft.com/en-us/windows/windows-10-support-ends-on-october-14-2025-2ca8b313-1946-43d3-b55c-2b95b107f281)
+ Windows 11
+ Linux
+ [Linux 用の公式 Microsoft VS Code](https://code.visualstudio.com/docs/setup/linux) をインストールする
  + オープンソースバージョンではない

### ローカルマシンの前提条件
<a name="remote-ide-requirement-machine"></a>

ローカル Visual Studio コードを Studio スペースに接続する前に、ローカルマシンに必要な依存関係とネットワークアクセスがあることを確認してください。

**注記**  
ソフトウェアのインストール制限がある環境では、ユーザーが必要な依存関係をインストールできない場合があります。 AWS Toolkit for Visual Studio Code は、リモート接続を開始するときにこれらの依存関係を自動的に検索し、不足している場合はインストールを求めます。IT 部門と連携して、これらのコンポーネントが使用可能であることを確認します。

**必要なローカル依存関係**

ローカルマシンには、次のコンポーネントがインストールされている必要があります。
+ **[https://code.visualstudio.com/docs/remote/ssh](https://code.visualstudio.com/docs/remote/ssh)**
+ — リモート開発用の標準 VS Code Marketplace 拡張機能
+ **[Session Manager プラグイン](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)** — 安全なセッション管理に必要です
+ **SSH クライアント** — ほとんどのマシンの標準コンポーネント ([Windows では OpenSSH を推奨](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse))
+ **[https://code.visualstudio.com/docs/configure/command-line](https://code.visualstudio.com/docs/configure/command-line)**
+  通常、VS Code のインストールに含まれています

**プラットフォーム固有の要件**
+ **Windows ユーザー** — SSH ターミナル接続には PowerShell 5.1 以降が必要です

**ネットワーク接続要件**

ローカルマシンには、[Session Manager エンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html)へのネットワークアクセスが必要です。たとえば、米国東部 (バージニア北部) (us-east-1) では、次のようになります。
+ `[ssm.us-east-1.amazonaws.com](http://ssm.us-east-1.amazonaws.com)`
+ `ssm.us-east-1.api.aws`
+ `[ssmmessages.us-east-1.amazonaws.com](http://ssmmessages.us-east-1.amazonaws.com)`
+ `[ec2messages.us-east-1.amazonaws.com](http://ec2messages.us-east-1.amazonaws.com)`

### イメージの要件
<a name="remote-ide-requirement-image"></a>

**SageMaker ディストリビューションイメージ**

リモートアクセスで SageMaker Distribution を使用する場合は、[SageMaker Distribution ](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-distribution.html)バージョン 2.7 以降を使用します。

**カスタムイメージ**

リモートアクセスで[独自のイメージ (BYOI) を使用する](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi.html)ときは、[カスタムイメージ仕様](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi-specs.html)に従い、次の依存関係がインストールされていることを確認してください。
+ `curl` または `wget` — AWS CLI コンポーネントのダウンロードに必要です
+ `unzip` — AWS CLI インストールファイルの抽出に必要です
+ `tar` — アーカイブの抽出に必要です
+ `gzip` — 圧縮されたファイル処理に必要です

### インスタンスの要件
<a name="remote-ide-requirement-instance"></a>
+ **メモリ** — 8GB 以上
+ 8GB 以上のメモリを持つインスタンスを使用します。メモリ不足 (8GB 未満) のため、次のインスタンスタイプはサポートされて*いません*。`ml.t3.medium`、`ml.c7i.large`、`ml.c6i.large`、`ml.c6id.large`、`ml.c5.large`。インスタンスタイプの詳細なリストについては、[Amazon EC2 オンデマンド料金ページ](https://aws.amazon.com/ec2/pricing/on-demand/)を参照してください。

## コンテナイメージの事前ウォーミングによる Kubernetes 起動時間の最適化
<a name="remote-ide-optimize-image"></a>

コンテナイメージのプルパフォーマンスは、特に AI/ML ワークロードがますます大きなコンテナイメージに依存するため、多くの EKS 顧客にとって大きなボトルネックとなっています。これらの大きなイメージをプルおよび解凍するには、通常、各 EKS ノードで初めて使用する場合に数分かかります。この遅延により、SageMaker Spaces を起動する際のレイテンシーが大幅に増加し、ユーザーエクスペリエンスに直接影響します。特に、ノートブックやインタラクティブな開発ジョブなど、高速起動が不可欠な環境では顕著です。

イメージの事前ウォーミングは、特定のコンテナイメージを EKS/HyperPod クラスター内のすべてのノードに必要な前にプリロードするために使用される手法です。ポッドが大きなイメージの最初のプルをトリガーするのを待つ代わりに、クラスターはすべてのノードでイメージをプロアクティブにダウンロードしてキャッシュします。これにより、ワークロードの起動時に必要なイメージが既にローカルで利用可能になり、コールドスタートの遅延が長くなります。イメージの事前ウォーミングにより、SageMaker Spaces の起動速度が向上し、エンドユーザーにより予測可能で応答性の高いエクスペリエンスが提供されます。

### DaemonSet による事前ウォーミング
<a name="remote-ide-optimize-image-dae"></a>

DaemonSet を使用してイメージをプリロードすることをお勧めします。DaemonSet は、クラスター内のすべてのノードで 1 つのポッドが実行されるようにします。DaemonSet ポッド内の各コンテナは、キャッシュするイメージを参照します。Kubernetes がポッドを起動すると、イメージが自動的にプルされ、各ノードのキャッシュがウォームアップされます。

次の例は、2 つの GPU イメージをプリロードする DaemonSet を作成する方法を示しています。各コンテナは軽量`sleep infinity`コマンドを実行して、最小限のオーバーヘッドでポッドをアクティブに保ちます。

```
cat <<EOF | kubectl apply -n "namespace_1" -f -
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-preload-ds
spec:
  selector:
    matchLabels:
      app: image-preloader
  template:
    metadata:
      labels:
        app: image-preloader
    spec:
      containers:
      - name: preloader-3-4-2
        image: public.ecr.aws/sagemaker/sagemaker-distribution:3.4.2-gpu
        command: ["sleep"]
        args: ["infinity"]
        resources:
          requests:
            cpu: 1m
            memory: 16Mi
          limits:
            cpu: 5m
            memory: 32Mi
      - name: preloader-3-3-2
        image: public.ecr.aws/sagemaker/sagemaker-distribution:3.3.2-gpu
        command: ["sleep"]
        args: ["infinity"]
        resources:
          requests:
            cpu: 1m
            memory: 16Mi
          limits:
            cpu: 5m
            memory: 32Mi
EOF
```

### 仕組み
<a name="remote-ide-optimize-image-how"></a>
+ 各コンテナは 1 つのイメージを参照します。
+ Kubernetes は、コンテナを起動する前に各イメージをダウンロードする必要があります。
+ ポッドがすべてのノードで実行されると、イメージはローカルにキャッシュされます。
+ これらのイメージを使用するワークロードは、はるかに高速に開始されるようになりました。

## スペースデフォルトストレージ (EBS)
<a name="space-storage"></a>

システムはデフォルトで EBS CSI ドライバーを使用して、各ワークスペースに EBS ストレージボリュームをプロビジョニングします。SageMaker はワークスペースで使用する EBS ストレージクラスを作成し、管理者はテンプレート設定を使用してこれらのボリュームのデフォルトサイズと最大サイズをカスタマイズできます。CLI ツールを使用する上級ユーザーの場合、ワークスペースのストレージクラスをカスタマイズすることもできます。これにより、ユーザーは EBS ボリュームのカスタマーマネージド KMS キーの設定など、他のストレージクラスを活用できます。

EBS ボリュームは特定の AZ にバインドされることに注意してください。つまり、ワークスペースはストレージボリュームと同じ AZ 内のノードでのみスケジュールできます。これにより、クラスター容量は存在するが、正しい AZ にない場合、スケジューリングが失敗する可能性があります。

## 追加ストレージ
<a name="space-additional-storage"></a>

SageMaker Spaces は、Amazon EFS、FSx for Lustre、S3 Mountpoint などの追加のストレージボリュームを開発スペースにアタッチすることをサポートしています。これにより、共有データセットへのアクセス、プロジェクトでのコラボレーション、ワークロードの高性能ストレージの使用が可能になります。

### 前提条件
<a name="space-additional-storage-prereq"></a>

追加のストレージをスペースにアタッチする前に、以下を行う必要があります。

1. [EKS](https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html) **アドオンを介して適切な CSI ドライバー**アドオンをインストールする (Amazon EFS CSI ドライバー、Amazon FSx for Lustre CSI ドライバー、または Mountpoint for Amazon S3 CSI ドライバー)

1. 特定の**ストレージタイプの CSI ドライバードキュメントに従ってストレージリソースと PersistentVolumeClaims を設定する** 

1. スペースを作成する予定の同じ名前空間で **PVC が使用可能であることを確認します**。

### スペースへのストレージのアタッチ
<a name="space-additional-storage-attach"></a>

PersistentVolumeClaim を設定したら、HyperPod CLI または kubectl を使用してスペースにアタッチできます。

**HyperPod CLI**

```
hyp create hyp-space \
    --name my-space \
    --display-name "My Space with FSx" \
    --memory 8Gi \
    --volume name=shared-fsx,mountPath=/shared,persistentVolumeClaimName=my-fsx-pvc
```

**kubectl**

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-space
spec:
  displayName: "My Space with FSx"
  desiredStatus: Running
  volumes:
  - name: shared-fsx
    mountPath: /shared
    persistentVolumeClaimName: my-fsx-pvc
```

### 複数のボリューム
<a name="space-additional-storage-multiple"></a>

CLI で複数の`--volume`フラグを指定するか、kubectl で`volumes`配列内の複数のエントリを指定することで、複数の追加のストレージボリュームを 1 つのスペースにアタッチできます。

**HyperPod CLI**

```
hyp create hyp-space \
    --name my-space \
    --display-name "My Space with Multiple Storage" \
    --memory 8Gi \
    --volume name=shared-efs,mountPath=/shared,persistentVolumeClaimName=my-efs-pvc \
    --volume name=datasets,mountPath=/datasets,persistentVolumeClaimName=my-s3-pvc
```

**kubectl**

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-space
spec:
  displayName: "My Space with Multiple Storage"
  desiredStatus: Running
  volumes:
  - name: shared-efs
    mountPath: /shared
    persistentVolumeClaimName: my-efs-pvc
  - name: datasets
    mountPath: /datasets
    persistentVolumeClaimName: my-s3-pvc
```

## リソース設定
<a name="space-resource-configuration"></a>

SageMaker Spaces では、ワークロードの要件に合わせて CPU、メモリ、GPU リソースなど、開発環境のコンピューティングリソースを設定できます。

### GPU 設定
<a name="space-gpu-configuration"></a>

SageMaker Spaces は、NVIDIA マルチインスタンス GPU (MIG) テクノロジーを使用した GPU 割り当て全体と GPU パーティショニングの両方をサポートしています。これにより、さまざまなタイプの機械学習ワークロードの GPU 使用率を最適化できます。

#### GPU 全体の割り当て
<a name="space-gpu-whole"></a>

**HyperPod CLI**

```
hyp create hyp-space \
    --name gpu-space \
    --display-name "GPU Development Space" \
    --image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
    --memory 16Gi \
    --gpu 1 \
    --gpu-limit 1
```

**kubectl**

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: gpu-space
spec:
  displayName: "GPU Development Space"
  image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  desiredStatus: Running
  resources:
    requests:
      memory: "16Gi"
      nvidia.com/gpu: "1"
    limits:
      memory: "16Gi"
      nvidia.com/gpu: "1"
```

#### GPU パーティショニング (MIG)
<a name="space-gpu-mig"></a>

NVIDIA マルチインスタンス GPU (MIG) テクノロジーを使用した GPU パーティショニングを使用すると、1 つの GPU をより小さく分離されたインスタンスに分割できます。HyperPod クラスターには、MIG をサポートする GPU ノードがあり、MIG プロファイルが設定されている必要があります。HyperPod クラスターで MIG を設定する方法の詳細については、[「NVIDIA MIG を使用した GPU パーティショニング](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-gpu-partitioning-setup.html)」を参照してください。

**HyperPod CLI**

```
hyp create hyp-space \
    --name mig-space \
    --display-name "MIG GPU Space" \
    --image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
    --memory 8Gi \
    --accelerator-partition-type mig-3g.20gb \
    --accelerator-partition-count 1
```

**kubectl**

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: mig-space
spec:
  displayName: "MIG GPU Space"
  image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  desiredStatus: Running
  resources:
    requests:
      memory: "8Gi"
      nvidia.com/mig-3g.20gb: "1"
    limits:
      memory: "8Gi"
      nvidia.com/mig-3g.20gb: "1"
```

## Lifecycle
<a name="space-lifecycle"></a>

ライフサイクル設定は、ワークスペースの作成時または起動時に実行される起動スクリプトを提供します。これらのスクリプトにより、管理者は起動時にワークスペース環境をカスタマイズできます。これらは、最大サイズが 1 KB の bash スクリプトです。より大きなセットアップ設定が必要な場合は、コンテナイメージにスクリプトを追加し、ライフサイクル設定からスクリプトをトリガーすることをお勧めします。

Kubernetes コンテナライフサイクルフックを活用して、この機能 [https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) を提供します。Kubernetes は、コンテナのエントリポイントに関連して起動スクリプトが実行されるタイミングを保証しないことに注意してください。

## アイドルシャットダウン
<a name="space-idle-shutdown"></a>

アイドル状態のワークスペースの自動シャットダウンを設定して、リソースの使用を最適化します。

### アイドルシャットダウン
<a name="space-idle-shutdown-spec"></a>

```
idleShutdown:
  enabled: true
  idleShutdownTimeoutMinutes: 30
  detection:
    httpGet:
      path: /api/idle
      port: 8888
      scheme: HTTP
```

### パラメータ
<a name="space-idle-shutdown-parameter"></a>

**有効** (ブール値、必須) - ワークスペースのアイドルシャットダウンを有効または無効にします。

**idleShutdownTimeoutMinutes** (整数、必須) - ワークスペースがシャットダウンするまでの非アクティブの分数。最小値は 1 です。

**detection** (オブジェクト、必須) - ワークスペースのアイドル状態を検出する方法を定義します。

**detection.httpGet** (オブジェクト、オプション) - アイドル検出用の HTTP エンドポイント設定。Kubernetes HTTPGetAction 仕様を使用します。
+ **path** - リクエストする HTTP パス
+ **port** - ポート番号または名前
+ **スキーム** - HTTP または HTTPS (デフォルト: HTTP)

### 設定場所
<a name="space-idle-shutdown-configure"></a>

**WorkSpace の設定**

ワークスペース仕様でアイドルシャットダウンを直接定義します。

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:

      name: my-workspace
spec:
  displayName: "Development Workspace"
  image:
      jupyter/scipy-notebook:latest
  idleShutdown:
    enabled: true

      idleShutdownTimeoutMinutes: 30
    detection:
      httpGet:
        path:
      /api/idle
        port: 8888
```

**テンプレート設定**

WorkspaceTemplate でデフォルトのアイドルシャットダウン動作を定義します。

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: jupyter-template
spec:
  displayName: "Jupyter Template"
  defaultImage: jupyter/scipy-notebook:latest
  defaultIdleShutdown:
    enabled: true
    idleShutdownTimeoutMinutes: 30
    detection:
      httpGet:
        path: /api/idle
        port: 8888
  idleShutdownOverrides:
    allow: true
    minTimeoutMinutes: 60
    maxTimeoutMinutes: 240
```

### テンプレートの継承と上書き
<a name="space-idle-shutdown-inherit"></a>

テンプレートを使用する Workspace は、テンプレート`defaultIdleShutdown`の設定を自動的に継承します。テンプレートで許可されている場合、WorkSpaces はこの設定を上書きできます。

**ポリシーを上書きする**

テンプレートは、 を通じてオーバーライド動作を制御します`idleShutdownOverrides`。

**allow** (ブール値、デフォルト: true) - ワークスペースがデフォルトのアイドルシャットダウン設定を上書きできるかどうか。

**minTimeoutMinutes** (整数、オプション) - ワークスペースオーバーライドで許可される最小タイムアウト値。

**maxTimeoutMinutes** (整数、オプション) - ワークスペースオーバーライドの最大許容タイムアウト値。

**継承の例**

WorkSpace はテンプレートのデフォルトを継承します。

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-workspace
spec:
  displayName: "My Workspace"
  templateRef:
    name: jupyter-template
  # Inherits defaultIdleShutdown from template
```

**オーバーライドの例**

WorkSpace はテンプレートのデフォルトを上書きします。

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-workspace
spec:
  displayName: "My Workspace"
  templateRef:
    name: jupyter-template
  idleShutdown:
    enabled: true
    idleShutdownTimeoutMinutes: 60  # Must be within template bounds
    detection:
      httpGet:
        path: /api/idle
        port: 8888
```

**ロックされた設定**

ワークスペースの上書きを防止します。

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: locked-template
spec:
  displayName: "Locked Template"
  defaultImage: jupyter/scipy-notebook:latest
  defaultIdleShutdown:
    enabled: true
    idleShutdownTimeoutMinutes: 30
    detection:
      httpGet:
        path: /api/idle
        port: 8888
  idleShutdownOverrides:
    allow: false  # Workspaces cannot override
```

### 行動
<a name="space-idle-shutdown-behavior"></a>

アイドルシャットダウンを有効にすると、システムは設定された HTTP エンドポイントを使用してワークスペースのアクティビティを定期的にチェックします。エンドポイントが、指定されたタイムアウト時間ワークスペースがアイドル状態であることを示している場合、ワークスペースは自動的に停止します。必要に応じて、ワークスペースを手動で再起動できます。

## テンプレートの更新
<a name="customization-template-updates"></a>

Kubectl や Hyperpod CLI や SDK などのクライアントツールは、EKS クラスター内のスペースの管理に使用できます。管理者はデフォルトのスペース設定用にスペーステンプレートをプロビジョニングできますが、データサイエンティストは基盤となる Kubernetes の複雑さを理解することなく、統合された開発環境をカスタマイズできます。詳細な使用手順については、[https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html](https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html) の CLI と SDK のドキュメントを参照してください。

管理者は、スペーステンプレートで CRUD オペレーションを実行できます。これは、スペースを作成する際の基本設定として機能します。データサイエンティストは、スペースで CRUD オペレーションを実行し、特定のコンピューティングノードのマルチインスタンス GPU プロファイルなど、さまざまなパラメータを上書きできます。リモート VSCode アクセスとウェブ UI を使用して、Spaces を起動、停止、接続できます。スペーステンプレートが更新されると、後で作成されるスペースは、更新されたテンプレートの設定で設定されます。コンプライアンスチェックは、既存のスペースが更新または開始されたときに実行されます。いずれかの設定が範囲外であるか、一致しない場合、スペースは更新または起動に失敗します。

## hyp CLI と kubectl の使用
<a name="customization-hyp-cli"></a>

ユーザーは Hyperpod CLI を使用してテンプレートで CRUD を実行できます

```
### 1. Create a Space Template
hyp create hyp-space-template --file template.yaml

### 2. List Space Templates
hyp list hyp-space-template
hyp list hyp-space-template --output json

### 3. Describe a Space Template
hyp describe hyp-space-template --name my-template
hyp describe hyp-space-template --name my-template --output json

### 4. Update a Space Template
hyp update hyp-space-template --name my-template --file updated-template.yaml

### 5. Delete a Space Template
hyp delete hyp-space-template --name my-template
```

カスタムテンプレートを作成するには、システムテンプレートを開始点として使用できます。このテンプレートは SMD のようなイメージで機能しますが、管理者が使用するイメージに基づいてカスタマイズできます。

カスタム JupyterLab テンプレートの例:

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: my-jupyter-template
  namespace: my-namespace
spec:
  displayName: "My Custom Jupyter Lab"
  description: "Custom Jupyter Lab with specific configurations"
  defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
  allowedImages:
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  defaultResources:
    requests:
      cpu: "1"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "16Gi"
  primaryStorage:
    defaultSize: "10Gi"
    minSize: "5Gi"
    maxSize: "50Gi"
    defaultStorageClassName: "sagemaker-spaces-default-storage-class"
    defaultMountPath: "/home/sagemaker-user"
  defaultContainerConfig:
    command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"]
  defaultPodSecurityContext:
    fsGroup: 1000
  defaultOwnershipType: "Public"
  defaultAccessStrategy:
    name: "hyperpod-access-strategy"
  allowSecondaryStorages: true
  appType: "jupyterlab"
```

カスタムコードエディタテンプレートの例:

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: my-code-editor-template
  namespace: my-namespace
spec:
  displayName: "My Custom Code Editor"
  description: "Custom Code Editor with specific configurations"
  defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
  allowedImages:
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  defaultResources:
    requests:
      cpu: "1"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "16Gi"
  primaryStorage:
    defaultSize: "10Gi"
    minSize: "5Gi"
    maxSize: "50Gi"
    defaultStorageClassName: "sagemaker-spaces-default-storage-class"
    defaultMountPath: "/home/sagemaker-user"
  defaultContainerConfig:
    command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-code-editor"]
  defaultPodSecurityContext:
    fsGroup: 1000
  defaultOwnershipType: "Public"
  defaultAccessStrategy:
    name: "hyperpod-access-strategy"
  allowSecondaryStorages: true
  appType: "code-editor"
```