#Создание Workbench

#Предварительные требования

• Убедитесь, что kubectl настроен и подключен к вашему кластеру.
• Убедитесь, что вы создали PVC.

#Создание Workbench через веб-консоль

#Порядок действий

#Подключение к Workbench

После создания экземпляра workbench нажмите Workbench в левой панели навигации; ваш экземпляр workbench должен отображаться в списке. Когда статус станет Running, нажмите кнопку Connect, чтобы войти в workbench.

#Загрузка файлов в JupyterLab

Если вы используете workbench на базе JupyterLab, вы можете загрузить файлы с локального компьютера с помощью кнопки Upload Files в браузере файлов. Это полезно, когда ваш workbench не может получить доступ к общедоступному интернету или зеркалу PyPI, и вам нужно установить Python-пакеты из локальных файлов wheel.

#Установка файла Python Wheel в автономном режиме

1. Подключитесь к workbench и откройте JupyterLab.

2. В левом браузере файлов нажмите кнопку Upload Files и выберите один или несколько файлов .whl на локальном компьютере.

3. Откройте терминал в JupyterLab и перейдите в каталог, содержащий загруженные файлы.

4. Установите пакет:

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

Если пакет зависит от других файлов wheel, загрузите все необходимые файлы .whl в тот же каталог и установите их без обращения к внешнему индексу пакетов:

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

#Доступные образы Workbench

Платформа предоставляет набор готовых к использованию образов WorkspaceKind, которые отображаются непосредственно в форме создания workbench. Дополнительные образы также публикуются в Docker Hub, но по умолчанию не синхронизируются в платформу.

Следующие таблицы используют тот же общий стиль, что и документация Red Hat OpenShift AI: каждый образ описывается с точки зрения его назначения, а ключевые предустановленные пакеты приводятся для быстрого ознакомления. Списки пакетов являются репрезентативными, а не исчерпывающими. Версии взяты из соответствующих каталогов образов в репозитории сборки и их lock-файлов.

#Встроенные образы

Следующие образы доступны из коробки:

#Многоархитектурные образы (x86_64 и arm64)

#Дополнительные образы

Следующие образы доступны в Docker Hub, но по умолчанию не встроены в платформу:

#Образы x86_64

Эти образы предназначены для узлов x86_64 с поддержкой NVIDIA GPU.

#Образы arm64

Эти образы предназначены для узлов arm64 с поддержкой Ascend NPU.

Чтобы использовать дополнительный образ, сначала синхронизируйте его в свой реестр образов. Это можно сделать с помощью такого инструмента, как skopeo, или с помощью скрипта, описанного в следующем разделе.

#Руководство по скрипту синхронизации образов Docker Hub

sync-from-dockerhub.sh — это автоматизированный инструмент для синхронизации выбранных образов Docker Hub, особенно очень больших образов, в частный реестр образов, например Harbor. При прямой передаче больших образов из-за сетевых колебаний чаще возникают сбои Out-Of-Memory (OOM) или таймауты. Для повышения надежности скрипт использует промежуточный рабочий процесс: сначала выполняет pull локально → затем экспортирует в tar-архив → затем отправляет tar-архив в целевой реестр. Он также автоматически очищает временные файлы по завершении задачи или при неожиданном выходе.

#Предварительные требования к скрипту

Перед запуском этого скрипта убедитесь, что на машине, где он будет выполняться, установлены и доступны следующие инструменты:

• bash (среда выполнения)
• nerdctl (для загрузки образов и экспорта слоев в tar-архивы)
• skopeo (для отправки tar-архивов образов в целевой частный реестр)

#Настройка переменных окружения

Скрипт выполняет синхронизацию, считывая переменные окружения, что обеспечивает гибкость использования без необходимости изменять код.

#Обязательные параметры (настройка целевого частного реестра)

#Необязательные параметры (настройка исходного DockerHub)

Чтобы не сработал Rate Limit DockerHub при загрузке большого количества образов, вы можете указать свои учетные данные DockerHub для входа перед выполнением загрузки. Если это не требуется, оставьте эти поля пустыми.

#Пример 1: Базовое использование (наиболее распространенный сценарий)

Если вам нужно только синхронизировать образы, определенные в скрипте, в ваш частный 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

#Пример 2: Выполнение одной командой (подходит для CI-сред)

Вы можете объявить переменные окружения и запустить скрипт в той же строке. Такой подход позволяет не засорять текущие переменные окружения Shell:

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

#Пример 3: Полный запуск с аутентификацией DockerHub (предотвращение Rate Limit)

При частом извлечении образов с одной и той же машины DockerHub может отклонять ваши запросы. В этом случае укажите свои учетные данные DockerHub:

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

#Устранение неполадок и примечания

1. Место на диске: поскольку скрипту требуется временно хранить очень большие образы (например, 13GB) в виде tar-архивов, убедитесь, что в каталоге /tmp вашей системы (или в его базовом корневом разделе) достаточно свободного места (рекомендуется не менее 30GB). Каталог промежуточного хранения по умолчанию для скрипта — /tmp/workbench-images-export-from-hub.
2. Таймауты передачи: текущий скрипт задает таймаут 120 минут (SKOPEO_TIMEOUT="120m") для отправки больших файлов. Если процесс завершается сбоем из-за очень низкой скорости сети, вы можете изменить значение этого параметра в начале скрипта с помощью любого текстового редактора.
3. Изменение списка образов: если есть образы, которые вы больше не хотите синхронизировать, просто откройте sync-from-dockerhub.sh и закомментируйте # нужные строки в массиве WORKBENCH_IMAGES (аналогично тому, как минимальные образы были отфильтрованы в sync.sh).

После того как образ станет доступен в вашем реестре, вам также нужно добавить соответствующую конфигурацию в поле imageConfig ресурса WorkspaceKind, который вы планируете использовать. Ниже приведен пример patch YAML, который добавляет новую конфигурацию образа в существующий 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"
          }
        ]
      }
    }
  }
]

Вы можете применить этот patch к используемому WorkspaceKind с помощью команды, подобной следующей:

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

Эта команда применяет JSON patch-файл к указанному WorkspaceKind и обновляет его imageConfig, чтобы новый образ workbench стал доступен в пользовательском интерфейсе создания workbench.

На практике вы можете адаптировать поля name, image и description в соответствии с образом, который вы синхронизировали, и соглашениями об именовании, используемыми в вашем кластере.