#Create Workbench

#Prerequisites

• Ensure you have kubectl configured and connected to your cluster.
• Ensure you have created PVC.

#Create Workbench by using the web console

#Procedure

#Connect to Workbench

After creating a workbench instance, click Workbench in the left navigation bar; your workbench instance should show up in the list. When the status becomes Running, click the Connect button to enter the workbench.

#Upload Files in JupyterLab

If you use a JupyterLab-based workbench, you can upload files from your local machine by using the Upload Files button in the file browser. This is useful when your workbench cannot access the public internet or a PyPI mirror and you need to install Python packages from local wheel files.

#Install a Python Wheel File Offline

1. Connect to the workbench and open JupyterLab.

2. In the left-side file browser, click the Upload Files button and select one or more .whl files from your local machine.

3. Open a terminal in JupyterLab and go to the directory that contains the uploaded files.

4. Install the package:

   pip install ./your_package-1.0.0-py3-none-any.whl

If the package depends on other wheel files, upload all required .whl files to the same directory and install them without accessing an external package index:

pip install --no-index --find-links . your-package

#Available Workbench Images

The platform provides a set of ready-to-use WorkspaceKind images that appear directly in the workbench creation form. Additional images are also published on Docker Hub, but they are not synchronized into the platform by default.

The following tables use the same general style as the Red Hat OpenShift AI documentation: each image is described by its intended use, and key preinstalled packages are listed for quick reference. The package lists are representative rather than exhaustive. Versions are taken from the matching image directories in the build repository and their corresponding lock files.

#Built-in images

The following images are available out of the box:

#Multi-architecture images (x86_64 and arm64)

#Additional images

The following images are available on Docker Hub but are not built into the platform by default:

#x86_64 images

These images are intended for x86_64 nodes with NVIDIA GPU support.

#arm64 images

These images are intended for arm64 nodes with Ascend NPU support.

To use an additional image, first synchronize it to your own image registry. You can do this with a tool such as skopeo, or by using the script described in the next section.

#Docker Hub Image Synchronization Script Guide

sync-from-dockerhub.sh is an automated tool for synchronizing selected Docker Hub images, especially very large images, to a private image registry such as Harbor. Large images are more likely to encounter Out-Of-Memory (OOM) or timeout failures during direct transfer because of network fluctuations. To improve reliability, the script uses a relay workflow: pull locally -> export as a tar archive -> push the tar archive to the target registry. It also cleans up temporary files automatically when the task completes or exits unexpectedly.

#Script Prerequisites

Before running this script, ensure the following tools are installed and accessible on your execution machine:

• bash (Execution environment)
• nerdctl (For pulling images and exporting layers as tar archives)
• skopeo (For pushing the tar image archives to the target private registry)

#Environment Variables Configuration

The script executes synchronization by reading environment variables, providing flexible usage without the need to modify the code.

#Required Parameters (Target Private Registry Configuration)

#Optional Parameters (Source DockerHub Configuration)

To prevent triggering DockerHub's Rate Limit when pulling a large volume of images, you can provide your DockerHub credentials to log in prior to pulling. If unnecessary, leave these blank.

#Example 1: Basic Usage (Most Common)

If you only need to synchronize the images defined within the script to your private Harbor:

# 1. Export environment variables for the target registry
export TARGET_REGISTRY="build-harbor.alauda.cn"
export TARGET_PROJECT="mlops/workbench-images"
export TARGET_USER="admin"
export TARGET_PASSWORD="YourHarborPassword"

# 2. Grant execution permissions to the script (if not already done)
chmod +x ./sync-from-dockerhub.sh

# 3. Execute the synchronization
./sync-from-dockerhub.sh

#Example 2: Single-Line Command Execution (Suitable for CI Environments)

You can declare environment variables and run the script on the same line. This approach avoids polluting the current Shell environment variables:

TARGET_REGISTRY="build-harbor.alauda.cn" \
TARGET_PROJECT="mlops/workbench-images" \
TARGET_USER="admin" \
TARGET_PASSWORD="YourHarborPassword" \
./sync-from-dockerhub.sh

#Example 3: Full Execution with DockerHub Authentication (Rate-Limit Prevention)

When pulling images frequently from the same machine, DockerHub might reject your requests. In this case, include your DockerHub credentials:

export TARGET_REGISTRY="build-harbor.alauda.cn"
export TARGET_PROJECT="mlops/workbench-images"
export TARGET_USER="admin"
export TARGET_PASSWORD="YourHarborPassword"

export DOCKERHUB_USER="alaudadockerhub"
export DOCKERHUB_PASSWORD="dckr_pat_xxx_your_token_xxx"

./sync-from-dockerhub.sh

#Troubleshooting and Notes

1. Disk Space: Since the script needs to temporarily store ultra-large images (e.g., 13GB) as tar archives, ensure that your system's /tmp directory (or its underlying root partition) has ample free space (at least 30GB recommended). The script's default staging directory is /tmp/workbench-images-export-from-hub.
2. Transfer Timeouts: The current script sets a timeout of 120 minutes (SKOPEO_TIMEOUT="120m") for pushing large files. If the process fails due to extremely slow network speeds, you can adjust this parameter value at the top of the script using any text editor.
3. Modifying the Image List: If there are images you no longer wish to synchronize, simply open sync-from-dockerhub.sh and use a # to comment out those specific lines within the WORKBENCH_IMAGES array (similar to how the minimal images were filtered out in sync.sh).

After the image is available in your registry, you also need to add the corresponding configuration to the imageConfig field of the WorkspaceKind resource that you plan to use. Below is an example patch YAML that adds a new image configuration to an existing WorkspaceKind:

[
  {
    "op": "add",
    "path": "/spec/podTemplate/options/imageConfig/values/-",
    "value": {
      "id": "jupyter-pytorch-llmcompressor-cuda-py312",
      "spawner": {
        "displayName": "Jupyter | PyTorch LLM Compressor | CUDA | Python 3.12",
        "description": "JupyterLab with PyTorch and LLM Compressor for CUDA",
        "labels": [
          {
            "key": "python_version",
            "value": "3.12"
          },
          {
            "key": "framework",
            "value": "pytorch"
          },
          {
            "key": "accelerator",
            "value": "cuda"
          }
        ]
      },
      "spec": {
        "image": "build-harbor.alauda.cn/mlops/workbench-images/odh-workbench-jupyter-pytorch-llmcompressor-cuda-py312-ubi9:3.4_ea1-v1.41",
        "imagePullPolicy": "IfNotPresent",
        "ports": [
          {
            "id": "jupyterlab",
            "displayName": "JupyterLab",
            "port": 8888,
            "protocol": "HTTP"
          }
        ]
      }
    }
  }
]

You can apply the patch to the WorkspaceKind you are using with a command similar to the following:

kubectl patch workspacekind jupyterlab-internal-3-4-ea1-v1-41 \
  --type=json \
  --patch-file add-llmcompressor-image-patch.json \
  -o yaml

This command applies the JSON patch file to the specified WorkspaceKind and updates its imageConfig so the new workbench image becomes available in the workbench creation UI.

In practice, you can adapt the name, image, and description fields according to the image you synchronized and the naming conventions used in your cluster.