ml workspace
0.13.2
Все в одном веб-среда разработки для машинного обучения
Начало работы • Особенности и скриншоты • Поддержка • Сообщите об ошибке • FAQ • Известные проблемы • Вклад
ML Workspace-это веб-IDE, специализирующаяся на машинном обучении и науке о данных. Его прост в развертывании и запускает вас в течение нескольких минут для продуктивно построенных решений ML на ваших собственных машинах. Это рабочее пространство является окончательным инструментом для разработчиков, предварительно загруженных с различными популярными библиотеками науки о данных (например, Tensorflow, Pytorch, Keras, Sklearn) и Dev (например, Jupyter, VS Code, Tensorboard), идеально настроенных, оптимизированных и интегрированных.
Рабочая область требует, чтобы Docker был установлен на вашем компьютере (руководство по установке).
Развернуть один экземпляр рабочей пространства так же просто, как:
docker run -p 8080:8080 mltooling/ml-workspace:0.13.2Вуаля, это было легко! Теперь Docker вытянет новейшее изображение рабочей области на вашу машину. Это может занять несколько минут, в зависимости от скорости вашего интернета. Как только рабочее пространство запускается, вы можете получить к нему доступ через http: // localhost: 8080.
Если запустить на другой машине или с другим портом, обязательно используйте IP/DNS и/или открытый порт машины.
Чтобы развернуть один экземпляр для продуктивного использования, мы рекомендуем применить хотя бы следующие параметры:
docker run -d
-p 8080:8080
--name " ml-workspace "
-v " ${PWD} :/workspace "
--env AUTHENTICATE_VIA_JUPYTER= " mytoken "
--shm-size 512m
--restart always
mltooling/ml-workspace:0.13.2 Эта команда запускает контейнер на фоне ( -d ), соединяет ваш текущий рабочий каталог в папку /workspace ( -v ), защищает рабочее пространство через предоставленный токен ( --env AUTHENTICATE_VIA_JUPYTER ), обеспечивает 512 МБ общей памяти ( --shm-size ), чтобы предотвратить неожиданные аварии (см. В разделе «Известные проблемы»), и сохраняет контейнер, работающие на системном восстановлении), которые всегда используются в системном рестаграмме (даже в рамках системы ( --restart always (. Вы можете найти дополнительные параметры для Docker Run здесь и параметры конфигурации рабочей области в разделе ниже.
Рабочая область предоставляет множество параметров конфигурации, которые можно использовать путем установки переменных среды (через Docker Run Option: --env ).
| Переменная | Описание | По умолчанию |
|---|---|---|
| Workspace_base_url | Базовый URL, под которым будут доступны Юпитер и все другие инструменты. | / |
| Workspace_ssl_enabled | Включить или отключить SSL. При установке в True любой сертификат (CERT.CRT) должен быть установлен на /resources/ssl или, если нет, контейнер генерирует самопоглашенный сертификат. | ЛОЖЬ |
| Workspace_Auth_user | Основное имя пользователя Auth. Чтобы включить Basic Auth, необходимо установить как пользователь, так и пароль. Мы рекомендуем использовать AUTHENTICATE_VIA_JUPYTER для обеспечения рабочего пространства. | |
| WorkPace_Auth_password | Базовый пароль пользователя Auth. Чтобы включить Basic Auth, необходимо установить как пользователь, так и пароль. Мы рекомендуем использовать AUTHENTICATE_VIA_JUPYTER для обеспечения рабочего пространства. | |
| Workspace_port | Конфигурирует основной контейнер-внутренний порт прокси-сервера рабочей области. Для большинства сценариев эта конфигурация не должна быть изменена, а конфигурация порта через Docker должна использоваться вместо рабочего пространства, должна быть доступна из другого порта. | 8080 |
| Config_backup_enabled | Автоматическое резервное копирование и восстановление конфигурации пользователя в папку Permisted /workspace , такую как .ssh, .jupyter или .gitConfig из домашнего каталога пользователей. | истинный |
| Shared_links_enabled | Включить или отключить возможность обмена ресурсами через внешние ссылки. Это используется для включения совместного использования файлов, доступа к портам в рабочем пространстве и простой настройки SSH на основе команд. Все общие ссылки защищены через токен. Тем не менее, существуют определенные риски, поскольку токен не может быть легко недействительным после обмена и не истекает. | истинный |
| Включите_tutorials | Если true , выбор учебных ноутбуков и введения ноутбуков добавляется в папку /workspace при запуске контейнера, но только в том случае, если папка пуста. | истинный |
| Max_num_threads | Количество потоков, используемых для вычислений при использовании различных общих библиотек (MKL, OpenBlas, OMP, Numba, ...). Вы также можете использовать auto , чтобы рабочее пространство динамически определять количество потоков на основе доступных ресурсов ЦП. Эта конфигурация может быть перезаписана пользователем из рабочей области. Как правило, хорошо установить его по или ниже количества процессоров, доступных для рабочей области. | авто |
| Конфигурация Юпитера: | ||
| Shutdown_inactive_kernels | Автоматически выключить неактивные ядра после данного тайм -аута (очистить память или ресурсы графического процессора). Значение может быть либо тайм -аутом в секундах, либо установить на true со значением по умолчанию 48 часов. | ЛОЖЬ |
| Authenticate_via_jupyter | Если true , все HTTP -запросы будут аутентифицированы против сервера Jupyter, что означает, что метод аутентификации, настроенный с Jupyter, также будет использоваться и для всех других инструментов. Это может быть деактивировано false . Любое другое значение активирует эту аутентификацию и будет применяться в качестве токена через NoteBookApp.token Configuration of Jupyter. | ЛОЖЬ |
| Notebook_args | Добавить и перезаписать параметры конфигурации Юпитера через командную строку ARG. Обратитесь к этому обзору для всех вариантов. | |
Чтобы сохранить данные, вам необходимо установить объем в /workspace (через опцию Docker Run: -v ).
Справочник по умолчанию в контейнере - это /workspace , которое также является корневым каталогом экземпляра Юпитера. Справочник /workspace предназначено для использования для всех важных рабочих артефактов. Данные в других каталогах сервера (например, /root ) могут быть потеряны при перезапусках контейнеров.
Мы настоятельно рекомендуем включить аутентификацию через один из следующих двух вариантов. Для обоих вариантов пользователь должен будет аутентифицировать подлинность для доступа к любому из предварительно установленных инструментов.
Аутентификация работает только для всех инструментов, доступных через основной порт рабочего пространства (по умолчанию:
8080). Это работает для всех предустановленных инструментов и функции портов доступа. Если вы выставляете другой порт контейнера, пожалуйста, обязательно закрепите его с аутентификацией!
Активируйте аутентификацию на основе токков на основе реализации аутентификации jupyter через переменную AUTHENTICATE_VIA_JUPYTER :
docker run -p 8080:8080 --env AUTHENTICATE_VIA_JUPYTER= " mytoken " mltooling/ml-workspace:0.13.2 Вы также можете использовать <generated> , чтобы Jupyter генерировал случайный токен, который распечатывается в журналах контейнеров. Значение true не установит ни одного токена, но активируется, что каждый запрос на любой инструмент в рабочей области будет проверяться с помощью экземпляра Jupyter, если пользователь будет аутентифицирован. Это используется для таких инструментов, как jupyterhub, которые настраивают свой собственный способ аутентификации.
Активировать основную аутентификацию через WORKSPACE_AUTH_USER и WORKSPACE_AUTH_PASSWORD переменная:
docker run -p 8080:8080 --env WORKSPACE_AUTH_USER= " user " --env WORKSPACE_AUTH_PASSWORD= " pwd " mltooling/ml-workspace:0.13.2 Основная аутентификация настроена через прокси Nginx и может быть более эффективной по сравнению с другим опцией, поскольку с помощью AUTHENTICATE_VIA_JUPYTER каждый запрос на любой инструмент в рабочей области будет проверять через экземпляр Jupyter, если пользователь (на основе файлов cookie -запроса) будет аутентифицирован.
Мы рекомендуем включить SSL, чтобы рабочее пространство было доступно через HTTPS (зашифрованная связь). Шифрование SSL может быть активировано через переменную WORKSPACE_SSL_ENABLED .
При установке true , файл cert.crt и cert.key должен быть установлен на /resources/ssl или, если файлы сертификата не существуют, контейнер генерирует самоопределенные сертификаты. Например, если файлы /path/with/certificate/files в локальной системе содержит действительный сертификат для домена хоста ( cert.crt и cert.key file), его можно использовать из рабочей области, как показано ниже:
docker run
-p 8080:8080
--env WORKSPACE_SSL_ENABLED= " true "
-v /path/with/certificate/files:/resources/ssl:ro
mltooling/ml-workspace:0.13.2 Если вы хотите разместить рабочее пространство на общественном доступе, мы рекомендуем использовать Let's Encrypt, чтобы получить доверенный сертификат для вашего домена. Чтобы использовать сгенерированный сертификат (например, через инструмент Certbot) для рабочей области, privkey.pem соответствует файлу cert.key и fullchain.pem в файл cert.crt .
Когда вы включите поддержку SSL, вы должны получить доступ к рабочее пространство по сравнению с
https://, а не на простыхhttp://.
По умолчанию контейнер Workspace не имеет ограничений ресурсов и может использовать столько данного ресурса, насколько позволяет планировщик ядра хоста. Docker предоставляет способы управления тем, сколько памяти или ЦП может использовать контейнер, установив флагов конфигурации времени выполнения команды Docker Run.
Рабочая пространство требует как минимум 2 процессоров и 500 МБ для работы стабильной и использования.
Например, следующая команда ограничивает рабочую область для использования только максимум 8 процессоров, 16 ГБ памяти и 1 ГБ общей памяти (см. Известные проблемы):
docker run -p 8080:8080 --cpus=8 --memory=16g --shm-size=1G mltooling/ml-workspace:0.13.2Для получения дополнительных вариантов и документации по ограничениям ресурсов, пожалуйста, обратитесь к официальному руководству Docker.
Если требуется прокси, вы можете передать конфигурацию прокси через переменные среды HTTP_PROXY , HTTPS_PROXY и NO_PROXY .
В дополнение к основному изображению рабочей области ( mltooling/ml-workspace ) мы предоставляем другие ароматы изображения, которые расширяют функции или минимизируют размер изображения, чтобы поддержать различные варианты использования.
Минимальный вкус ( mltooling/ml-workspace-minimal ) является нашим наименьшим изображением, которое содержит большинство инструментов и функций, описанных в разделе функций без большинства библиотек Python, которые предварительно установлены в нашем основном изображении. Любая библиотека Python или исключенный инструмент может быть установлен вручную во время выполнения пользователем.
docker run -p 8080:8080 mltooling/ml-workspace-minimal:0.13.2 Вкус R ( mltooling/ml-workspace-r ) основан на нашем изображении рабочей области по умолчанию и расширяет его с помощью R-Interpreter, ядра R-Jupyter, сервера RSTUDIO (доступ через Open Tool -> RStudio ) и множество популярных пакетов из экосистемы R.
docker run -p 8080:8080 mltooling/ml-workspace-r:0.12.1 Вкус Spark ( mltooling/ml-workspace-spark ) основан на нашем изображении R-Flaure Workspace и расширяет его со временем выполнения Spark, ядра Spark-Jupyter, ноутбука Zeppelin (доступ через Open Tool -> Zeppelin ), Pyspark, Hadoop, ядра Java и несколько дополнительных библиотеков и Jupyter Extensions.
docker run -p 8080:8080 mltooling/ml-workspace-spark:0.12.1В настоящее время поля GPU только поддерживает CUDA 11.2. Поддержка других версий CUDA может быть добавлена в будущем.
Вкус GPU ( mltooling/ml-workspace-gpu ) основан на нашем изображении рабочей области по умолчанию и расширяет его с помощью CUDA 10.1 и готовых к графическим процессорам различных библиотек машинного обучения (например, Tensorflow, Pytorch, CNTK, JAX). Это изображение GPU имеет следующие дополнительные требования для системы:
>=460.32.03 (инструкции).docker run -p 8080:8080 --gpus all mltooling/ml-workspace-gpu:0.13.2docker run -p 8080:8080 --runtime nvidia --env NVIDIA_VISIBLE_DEVICES= " all " mltooling/ml-workspace-gpu:0.13.2Вкус GPU также поставляется с несколькими дополнительными вариантами конфигурации, как объяснено ниже:
| Переменная | Описание | По умолчанию |
|---|---|---|
| Nvidia_visible_devices | Управление, какие графические процессоры будут доступны в рабочем пространстве. По умолчанию все графические процессоры от хоста доступны в рабочей области. Вы можете использовать all , none , либо указать список идентификаторов устройства, разделяемый запятыми (например, 0,1 ). Вы можете узнать список доступных идентификаторов устройства, запустив nvidia-smi на хост-машине. | все |
| Cuda_visible_devices | Управляют, какие приложения CUDA CUDA, работающие внутри рабочего пространства. По умолчанию будут видны все графические процессоры, к которым имеет доступ к рабочему пространству. Чтобы ограничить приложения, предоставьте список внутренних идентификаторов внутренних устройств (например, 0,2 ), разделяемый запятыми на основе доступных устройств в рабочем пространстве (Run nvidia-smi ). По сравнению с NVIDIA_VISIBLE_DEVICES , пользователь Workspace все еще сможет получить доступ к другим графическим процессорам, перезаписывая эту конфигурацию из рабочей области. | |
| TF_FORCE_GPU_ALLY_GROWTH | По умолчанию большая часть памяти GPU будет выделена первым выполнением графика TensorFlow. Хотя это поведение может быть желательным для производственных трубопроводов, оно менее желательно для интерактивного использования. Используйте true , чтобы включить динамическое распределение памяти GPU или false , чтобы обучить TensorFlow распределять всю память при выполнении. | истинный |
Рабочая область разработана как среда разработки с одним пользователем. Для многопользовательской настройки мы рекомендуем развернуть? Ml Hub. ML Hub основан на jupyterhub с задачей, чтобы нереститься, управлять и прокси -экземпляры рабочей области для нескольких пользователей.
ML Hub позволяет легко настроить многопользовательскую среду на одном сервере (через Docker) или кластер (через Kubernetes) и поддерживает различные сценарии использования и поставщиков аутентификации. Вы можете попробовать ML Hub через:
docker run -p 8080:8080 -v /var/run/docker.sock:/var/run/docker.sock mltooling/ml-hub:latestДля получения дополнительной информации и документации о ML Hub, пожалуйста, посмотрите на сайт GitHub.
Этот проект поддерживается Бенджамином Ратляйном, Лукасом Масухом и Яном Калканом. Пожалуйста, поймите, что мы не сможем оказать индивидуальную поддержку по электронной почте. Мы также считаем, что помощь гораздо более ценна, если она публично разделяется, чтобы больше людей могли извлечь выгоду из этого.
| Тип | Канал |
|---|---|
| Отчеты об ошибках | |
| ? Запросы функций | |
| ? Вопросы об использовании | |
| ? Объявления | |
| ❓ Другие запросы |
Jupyter • GUI на рабочем столе • VS Code • JupyterLab • Интеграция GIT • Обмен файлами • Порты доступа • Тенордорборд • Расширенность • Мониторинг аппаратного обеспечения • Доступ SSH • Удаленная разработка • Выполнение задания
Рабочая область оснащена подборкой лучших в своем классе инструментов разработки с открытым исходным кодом, которые помогут с рабочим процессом машинного обучения. Многие из этих инструментов могут быть запущены из меню Open Tool от Jupyter (основное применение рабочего пространства):
В вашем рабочем пространстве у вас есть полные привилегии root & sudo для установки любой библиотеки или инструмента, который вам нужен через терминал (например,
pip,apt-get,condaилиnpm). Вы можете найти больше способов расширения рабочего пространства в разделе расширяемости
Notebook Jupyter-это веб-интерактивная среда для написания и запуска кода. Основными строительными блоками Юпитера являются File-Browser, редактор ноутбуков и ядра. File-Browser предоставляет интерактивный файловый диспетчер для всех записей, файлов и папок в каталоге /workspace .
Новая ноутбука может быть создана, нажав на New кнопку раскрываемости в верхней части списка и выбрав желаемое языковое ядро.
Вы также можете породить интерактивные экземпляры терминала , выбрав
New -> Terminalв файловом браузере.
Редактор ноутбуков позволяет пользователям автора документов, которые включают в себя живой код, текст разметки, команды оболочки, уравнения латекса, интерактивные виджеты, графики и изображения. Эти записные документы предоставляют полную и автономную запись о вычислении, которые могут быть преобразованы в различные форматы и поделились с другими.
Это рабочее пространство имеет множество сторонних расширений Юпитера . Вы можете настроить эти расширения на вкладке NBEXTENSIONS:
nbextensionsв браузере файлов
Ноутбук позволяет запускать код в различных языках программирования. Для каждого документа Notebook, который открывается пользователь, веб -приложение запускает ядро , которое запускает код для этого ноутбука и возвращает вывод. Это рабочее пространство имеет предварительно установленный ядро Python 3. Дополнительные ядра могут быть установлены для получения доступа к другим языкам (например, R, Scala, GO) или дополнительным вычислительным ресурсам (например, графические процессоры, процессоры, память).
Python 2 дефицит, и мы не рекомендуем его использовать. Тем не менее, вы все равно можете установить ядро Python 2.7 по этой команде:
/bin/bash /resources/tools/python-27.sh
Это рабочее пространство обеспечивает доступ к VNC на основе HTTP к рабочей области через NOVNC. Таким образом, вы можете получить доступ и работать в рабочей области с помощью полнофункционального графического интерфейса настольных компьютеров. Чтобы получить доступ к этому графическому интерфейсу на рабочем столе, перейдите на Open Tool , выберите VNC и нажмите кнопку Connect . В случае вас просят пароль, используйте vncpassword .
Как только вы подключитесь, вы увидите графический интерфейс на рабочем столе, который позволяет устанавливать и использовать полноценные веб-браузеры или любой другой инструмент, доступный для Ubuntu. В папке Tools на рабочем столе вы найдете коллекцию сценариев установки, которая позволяет установить некоторые из наиболее часто используемых инструментов разработки, таких как Atom, Pycharm, R-Runtime, R-Studio или почтальон (просто дважды щелкните по сценарию).
Буфер обмена: если вы хотите поделиться буфером обмена между вашей машиной и рабочей областью, вы можете использовать функциональность копирования вставки, как описано ниже:
Продолжительные задачи: используйте графический интерфейс настольного графического интерфейса для длительных исполнений Юпитера. Запустив записные книжки из браузера вашего графического интерфейса рабочего пространства, все выводы будут синхронизированы с ноутбуком, даже если вы отключили свой браузер от ноутбука.
Visual Studio Code ( Open Tool -> VS Code )-это легкий, но мощный редактор кода с открытым исходным кодом с встроенной поддержкой различных языков и богатой экосистемой расширений. Он объединяет простоту редактора исходного кода с мощным инструментом разработчика, такими как завершение кода Intellisense и отладка. Workspace интегрирует код VS как веб-приложение, доступное через браузер, на Awesome Code-Server Project. Это позволяет настроить каждую функцию по своему вкусу и устанавливать любое количество сторонних расширений.
Рабочая область также предоставляет интеграцию кода VS в Юпитер, позволяющий открыть экземпляр кода VS для любой выбранной папки, как показано ниже:
Jupyterlab ( Open Tool -> JupyterLab ) -это пользовательский интерфейс следующего поколения для Project Jupyter. Он предлагает все знакомые строительные блоки классического ноутбука Jupyter (ноутбук, терминал, текстовый редактор, браузер файлов, богатые выходы и т. Д.) В гибком и мощном пользовательском интерфейсе. Этот экземпляр jupyterlab предварительно установлен с несколькими полезными расширениями, такими как jupyterlab-toc, jupyterlab-git и juptyterlab-tensorboard.
Управление версией является важным аспектом продуктивного сотрудничества. Чтобы сделать этот процесс максимально плавным, мы интегрировали настраиваемое расширение Jupyter, .md на толкание отдельных ноутбуков, полноценного веб-клиента GIT (UNGIT), инструмента для открытия и редактирования простых текстовых документов (например .py Кроме того, JupyterLab и VS Code также предоставляют GIT-клиенты на основе графического интерфейса.
Для клонирования репозитории через https мы рекомендуем перейти к желаемой корневой папке и нажать кнопку git , как показано ниже:
Это может запрашивать некоторые необходимые настройки и, впоследствии, открывает Ungit, веб-клиент GIT с чистым и интуитивным пользовательским интерфейсом, который делает его удобным для синхронизации ваших артефактов кода. В пределах Ungit вы можете клонировать любой репозиторий. Если требуется аутентификация, вас попросят ваши учетные данные.
Чтобы совершить и выдвинуть один ноутбук в репозиторий удаленного GIT, мы рекомендуем использовать плагин GIT, интегрированный в Jupyter, как показано ниже:
Для более продвинутых операций GIT мы рекомендуем использовать Ungit. С UNGIT вы можете выполнять большинство общих действий GIT, таких как толкание, тяга, слияние, ветвь, тег, кассе и многие другие.
Записные книжки с Юпитером великолепны, но они часто представляют собой огромные файлы, с очень специфическим форматом файла JSON. Чтобы обеспечить беспрепятственное различие и слияние через GIT, это рабочее пространство предварительно установлено с NBDime. NBDIME понимает структуру ноутбуков и, следовательно, автоматически принимает интеллектуальные решения при различии и слиянии ноутбуков. В случае, если у вас есть конфликты слияния, NBDIME позаботится о том, чтобы ноутбук все еще читается Юпитером, как показано ниже:
Кроме того, рабочее пространство поставляется на предварительном установке с помощью Jupytext, плагина Jupyter, который читает и записывает записные книжки в виде простых текстовых файлов. Это позволяет вам открывать, редактировать и запускать сценарии или файлы разметки (например, .py , .md ) в качестве ноутбуков в Jupyter. На следующем скриншоте мы открыли файл разметки через Jupyter:
В сочетании с GIT JupyText обеспечивает четкую историю Diff и простое объединение конфликтов версий. С обоими этими инструментами сотрудничество на ноутбуках Jupyter с git становится простым.
У рабочего пространства есть функция, чтобы обмениваться любым файлом или папкой с кем-либо по ссылке, защищенной от токена. Чтобы поделиться данными по ссылке, выберите любой файл или папку из дерева каталогов Юпитера и нажмите кнопку «Поделиться», как показано на следующем скриншоте:
Это генерирует уникальную ссылку, защищенную через токен, которая дает всем, кто имеет доступ к ссылке, для просмотра и загрузки выбранных данных через пользовательский интерфейс FileBrowser:
Чтобы деактивировать или управлять (например, предоставление разрешений на редактирование) общие ссылки, откройте FileBrowser через Open Tool -> Filebrowser и выберите Settings->User Management .
Можно безопасно получить доступ к любому внутреннему порту рабочего пространства, выбрав Open Tool -> Access Port . С помощью этой функции вы можете получить доступ к API REST или веб -приложения, работающему внутри рабочего пространства непосредственно с вашим браузером. Эта функция позволяет разработчикам создавать, запускать, тестировать и отлаживать API REST или веб -приложения непосредственно из рабочей области.
Если вы хотите использовать HTTP -клиент или поделиться доступом к данному порту, вы можете выбрать опцию Get shareable link . Это генерирует ссылку, защищенную токеном, которую любой, кто имеет доступ к ссылке, может использовать для доступа к указанному порту.
Приложение HTTP требует разрешения из относительного пути URL или настройки базового пути (
/tools/PORT/). Инструменты, сделанные доступным таким образом, обеспечены системой аутентификации рабочей области! Если вы решите опубликовать какой -либо другой порт контейнера самостоятельно вместо того, чтобы использовать эту функцию, чтобы сделать инструмент доступным, пожалуйста, закрепите его с помощью механизма аутентификации!
1234 , выполнив эту команду в терминале в рабочем пространстве: python -m http.server 1234Open Tool -> Access Port , порт 1234 ввода 1234 и выберите параметр « Get shareable link .Access , и вы увидите контент, предоставленный Python http.server . SSH предоставляет мощный набор функций, которые позволяют вам быть более продуктивными с вашими задачами разработки. Вы можете легко настроить безопасное и без пароля подключения SSH на рабочее пространство, выбрав Open Tool -> SSH . Это будет генерировать безопасную команду настройки, которую можно запустить на любой машине Linux или Mac для настройки подключения без пароля и безопасного SSH -соединения в рабочее пространство. В качестве альтернативы, вы также можете загрузить скрипт настроек и запустить его (вместо использования команды).
Сценарий настройки работает только на Mac и Linux. Windows в настоящее время не поддерживается.
Просто запустите команду настройки или сценарий на машине, откуда вы хотите настроить соединение с рабочей областью и введите имя для соединения (например, my-workspace ). Вас также может попросить немного дополнительного ввода во время процесса, например, установить удаленное ядро, если будет установлен remote_ikernel . После успешной настройки и протестирования подключения без пароля вы можете безопасно подключиться к рабочему пространству, просто выполнив ssh my-workspace .
Помимо возможности выполнять команды на удаленной машине, SSH также предоставляет множество других функций, которые могут улучшить ваш рабочий процесс разработки, как описано в следующих разделах.
Подключение SSH может использоваться для туннельных портов приложений от удаленной машины до локальной машины, или наоборот. Например, вы можете выставить внутренний порт 5901 Workspace (VNC Server) на локальную машину на порту 5000 , выполнив:
ssh -nNT -L 5000:localhost:5901 my-workspaceЧтобы разоблачить порт приложения с локальной машины в рабочую область, используйте опцию
-R(вместо-L).
После установки туннеля вы можете использовать своего любимого VNC Viewer на своей локальной машине и подключиться к vnc://localhost:5000 (пароль по умолчанию: vncpassword ). Чтобы сделать туннельное соединение более устойчивым и надежным, мы рекомендуем использовать Autossh для автоматического перезапуска SSH -туннелей в случае, когда соединение умирает:
autossh -M 0 -f -nNT -L 5000:localhost:5901 my-workspaceПорт-туннелирование весьма полезно, когда вы запустили любой серверный инструмент в рабочей области, который вам нравится для того, чтобы сделать доступным для другой машины. В своем настройке по умолчанию у рабочего пространства есть множество инструментов, уже работающих на разных портах, например:
8080 : основной порт рабочей области с доступом ко всем интегрированным инструментам.8090 : сервер Юпитера.8054 : VS -кодовый сервер.5901 : VNC Server.22 : SSH Server.Вы можете найти информацию порта во всех инструментах в конфигурации супервизора.
Для получения дополнительной информации о порт -туннелинге/пересылки, мы рекомендуем это руководство.
SCP позволяет надежно копировать файлы и каталоги с различными машинами через SSH -соединения. Например, чтобы скопировать локальный файл ( ./local-file.txt ) в папку /workspace внутри рабочего пространства, выполнить:
scp ./local-file.txt my-workspace:/workspace Чтобы скопировать каталог /workspace от my-workspace в рабочий каталог локальной машины, выполнить:
scp -r my-workspace:/workspace .Для получения дополнительной информации о SCP, мы рекомендуем это руководство.
RSYNC - это утилита для эффективной передачи и синхронизации файлов между различными машинами (например, через SSH -соединения), сравнивая время изменения и размеры файлов. Команда RSYNC определит, какие файлы необходимо обновлять каждый раз, когда она запускается, что гораздо более эффективно и удобно, чем использование чего -то вроде SCP или SFTP. Например, для синхронизации всего содержания локальной папки ( ./local-project-folder/ ) в папку /workspace/remote-project-folder/ папку внутри рабочего пространства, выполнить:
rsync -rlptzvP --delete --exclude= " .git " " ./local-project-folder/ " " my-workspace:/workspace/remote-project-folder/ "Если у вас есть некоторые изменения в папке в рабочей области, вы можете синхронизировать эти изменения обратно в локальную папку, изменив аргументы источника и назначения:
rsync -rlptzvP --delete --exclude= " .git " " my-workspace:/workspace/remote-project-folder/ " " ./local-project-folder/ "Вы можете повторить эти команды каждый раз, когда вы хотите синхронизировать последнюю копию ваших файлов. RSYNC позаботится о том, чтобы только обновления будут переданы.
Вы можете найти больше информации о RSYNC на этой странице человека.
Помимо копирования и синхронизации данных, соединение SSH также может использоваться для монтажа каталогов с удаленной машины в локальную файловую систему через SSHFS. Например, чтобы установить каталог /workspace my-workspace в локальный путь (например /local/folder/path ), выполнить:
sshfs -o reconnect my-workspace:/workspace /local/folder/pathКак только удаленный каталог установлен, вы можете взаимодействовать с удаленной файловой системой так же, как с любым локальным каталогом и файлом.
Для получения дополнительной информации о SSHFS мы рекомендуем это руководство.
Рабочая область может быть интегрирована и используется в качестве удаленного времени выполнения (также известного как удаленное ядро/машину/интерпретатор) для различных популярных инструментов и IDES, таких как Юпитер, VS -код, Pycharm, Colab или Atom Wydrogen. Таким образом, вы можете подключить свой любимый инструмент разработки, работающий на локальной машине к удаленной машине для выполнения кода. Это обеспечивает опыт разработки локального качества с дистанционными вычислительными ресурсами.
Эти интеграции обычно требуют подключения SSH без пароля от локальной машины до рабочей области. Чтобы настроить соединение SSH, следуйте шагам, объясненным в разделе доступа SSH.
Рабочая область может быть добавлена в экземпляр Jupyter в качестве удаленного ядра, используя инструмент remote_ikernel. Если вы установили remote_ikernel ( pip install remote_ikernel ) на локальную машину, сценарий установки SSH автоматически предложит вам возможность настроить удаленное соединение ядра.
При запуске ядра на удаленных машинах сами записные книжки будут сохранены в локальной файловой системе, но ядро будет иметь доступ только к файловой системе удаленной машины, работающей на ядре. Если вам нужно синхронизировать данные, вы можете использовать RSYNC, SCP или SSHF, как это было объяснено в разделе Access SSH.
Если вы хотите вручную настроить и управлять удаленными ядрами, используйте инструмент командной строки remote_ikernel, как показано ниже:
# Change my-workspace with the name of a workspace SSH connection
remote_ikernel manage --add
--interface=ssh
--kernel_cmd= " ipython kernel -f {connection_file} "
--name= " ml-server (Python) "
--host= " my-workspace " Вы можете использовать функциональность командной строки remote_ikernel для списка ( remote_ikernel manage --show ) или delete ( remote_ikernel manage --delete <REMOTE_KERNEL_NAME> ) Соединения с удаленным ядром.
Удаленный код Visual Studio - расширение SSH позволяет открывать удаленную папку на любой удаленной машине с доступом SSH и работать с ней так же, как если бы папка была на вашей собственной машине. После подключения к удаленной машине вы можете взаимодействовать с файлами и папками в любом месте удаленной файловой системы и в полной мере воспользоваться набором функций VS Code (Intellisense, Debuging и поддержка расширения). Обнаружения и работают без ящиков с помощью SSH-соединений без пароля, настроенных с помощью скрипта настройки SSH Workspace. Чтобы позволить вашему приложению локального кодового кода подключиться к рабочей области:
Вы можете найти дополнительные функции и информацию о удаленном расширении SSH в этом руководстве.
Tensorboard предоставляет набор инструментов визуализации, чтобы упростить понимание, отладка и оптимизировать ваши экспериментальные пробеги. Он включает в себя функции ведения журнала для скалярной, гистограммы, структуры модели, встраивания, а также визуализации текста и изображений. Рабочая область поставляется на предварительном установке с расширением jupyter_tensorboard, которое интегрирует Tensorboard в интерфейс Jupyter с функциональными возможностями для запуска, управления и остановки экземпляров. Вы можете открыть новый экземпляр для действительного каталога журналов, как показано ниже:
Если вы открыли экземпляр Tensorboard в действительном каталоге журнала, вы увидите визуализации ваших регистрационных данных:
Tensorboard можно использовать в сочетании со многими другими фреймворками ML, помимо Tensorflow. Используя библиотеку Tensorboardx, вы можете войти в основном из любой библиотеки на основе Python. Кроме того, Pytorch имеет прямую интеграцию с тенсорным домом, как описано здесь.
Если вы предпочитаете видеть тенденсорбус непосредственно в вашем ноутбуке, вы можете использовать следующее за Yupyter Magic :
%load_ext tensorboard
%tensorboard --logdir /workspace/path/to/logs
Рабочая пространство предоставляет два предварительно установленных веб-инструмента, которые помогут разработчикам во время обучения модели и других экспериментальных задач, чтобы получить представление обо всем, что происходит в системе, и выяснить узкие места производительности.
NetData ( Open Tool -> Netdata ) -это панель аппаратного обеспечения и мониторинга аппаратного обеспечения и производительности в реальном времени, которая визуализирует процессы и услуги в ваших системах Linux. Он контролирует метрики о процессоре, графическом процессоре, памяти, дисках, сети, процессах и многом другом.
Glances ( Open Tool -> Glances ) -это панель аппаратного мониторинга на основе веб -оборудования, которая может использоваться в качестве альтернативы NetData.
NetData и Glance покажут вам статистику оборудования для всей машины, на которой работает контейнер Workspace.
Задача определяется как любая вычислительная задача, которая работает в течение определенного времени до завершения, например, модель обучения или конвейер данных.
Изображение рабочей области также можно использовать для выполнения произвольного кода Python без запуска ни одного предварительно установленного инструмента. This provides a seamless way to productize your ML projects since the code that has been developed interactively within the workspace will have the same environment and configuration when run as a job via the same workspace image.
To run Python code as a job, you need to provide a path or URL to a code directory (or script) via EXECUTE_CODE . The code can be either already mounted into the workspace container or downloaded from a version control system (eg, git or svn) as described in the following sections. The selected code path needs to be python executable. In case the selected code is a directory (eg, whenever you download the code from a VCS) you need to put a __main__.py file at the root of this directory. The __main__.py needs to contain the code that starts your job.
You can execute code directly from Git, Mercurial, Subversion, or Bazaar by using the pip-vcs format as described in this guide. For example, to execute code from a subdirectory of a git repository, just run:
docker run --env EXECUTE_CODE= " git+https://github.com/ml-tooling/ml-workspace.git#subdirectory=resources/tests/ml-job " mltooling/ml-workspace:0.13.2For additional information on how to specify branches, commits, or tags please refer to this guide.
In the following example, we mount and execute the current working directory (expected to contain our code) into the /workspace/ml-job/ directory of the workspace:
docker run -v " ${PWD} :/workspace/ml-job/ " --env EXECUTE_CODE= " /workspace/ml-job/ " mltooling/ml-workspace:0.13.2In the case that the pre-installed workspace libraries are not compatible with your code, you can install or change dependencies by just adding one or multiple of the following files to your code directory:
requirements.txt : pip requirements format for pip-installable dependencies.environment.yml : conda environment file to create a separate Python environment.setup.sh : A shell script executed via /bin/bash . The execution order is 1. environment.yml -> 2. setup.sh -> 3. requirements.txt
You can test your job code within the workspace (started normally with interactive tools) by executing the following python script:
python /resources/scripts/execute_code.py /path/to/your/jobIt is also possible to embed your code directly into a custom job image, as shown below:
FROM mltooling/ml-workspace:0.13.2
# Add job code to image
COPY ml-job /workspace/ml-job
ENV EXECUTE_CODE=/workspace/ml-job
# Install requirements only
RUN python /resources/scripts/execute_code.py --requirements-only
# Execute only the code at container startup
CMD [ "python" , "/resources/docker-entrypoint.py" , "--code-only" ]The workspace is pre-installed with many popular interpreters, data science libraries, and ubuntu packages:
conda , pip , apt-get , npm , yarn , sdk , poetry , gdebi ...The full list of installed tools can be found within the Dockerfile.
For every minor version release, we run vulnerability, virus, and security checks within the workspace using safety, clamav, trivy, and snyk via docker scan to make sure that the workspace environment is as secure as possible. We are committed to fix and prevent all high- or critical-severity vulnerabilities. You can find some up-to-date reports here.
The workspace provides a high degree of extensibility. Within the workspace, you have full root & sudo privileges to install any library or tool you need via terminal (eg, pip , apt-get , conda , or npm ). You can open a terminal by one of the following ways:
New -> TerminalApplications -> Terminal EmulatorFile -> New -> TerminalTerminal -> New Terminal Additionally, pre-installed tools such as Jupyter, JupyterLab, and Visual Studio Code each provide their own rich ecosystem of extensions. The workspace also contains a collection of installer scripts for many commonly used development tools or libraries (eg, PyCharm , Zeppelin , RStudio , Starspace ). You can find and execute all tool installers via Open Tool -> Install Tool . Those scripts can be also executed from the Desktop VNC (double-click on the script within the Tools folder on the Desktop VNC).
For example, to install the Apache Zeppelin notebook server, simply execute:
/resources/tools/zeppelin.sh --port=1234 After installation, refresh the Jupyter website and the Zeppelin tool will be available under Open Tool -> Zeppelin . Other tools might only be available within the Desktop VNC (eg, atom or pycharm ) or do not provide any UI (eg, starspace , docker-client ).
As an alternative to extending the workspace at runtime, you can also customize the workspace Docker image to create your own flavor as explained in the FAQ section.
The workspace can be extended in many ways at runtime, as explained here. However, if you like to customize the workspace image with your own software or configuration, you can do that via a Dockerfile as shown below:
# Extend from any of the workspace versions/flavors
FROM mltooling/ml-workspace:0.13.2
# Run you customizations, e.g.
RUN
# Install r-runtime, r-kernel, and r-studio web server from provided install scripts
/bin/bash $RESOURCES_PATH/tools/r-runtime.sh --install &&
/bin/bash $RESOURCES_PATH/tools/r-studio-server.sh --install &&
# Cleanup Layer - removes unneccessary cache files
clean-layer.shFinally, use docker build to build your customized Docker image.
For a more comprehensive Dockerfile example, take a look at the Dockerfile of the R-flavor.
To update a running workspace instance to a more recent version, the running Docker container needs to be replaced with a new container based on the updated workspace image.
All data within the workspace that is not persisted to a mounted volume will be lost during this update process. As mentioned in the persist data section, a volume is expected to be mounted into the /workspace folder. All tools within the workspace are configured to make use of the /workspace folder as the root directory for all source code and data artifacts. During an update, data within other directories will be removed, including installed/updated libraries or certain machine configurations. We have integrated a backup and restore feature ( CONFIG_BACKUP_ENABLED ) for various selected configuration files/folders, such as the user's Jupyter/VS-Code configuration, ~/.gitconfig , and ~/.ssh .
If the workspace is deployed via Docker (Kubernetes will have a different update process), you need to remove the existing container (via docker rm ) and start a new one (via docker run ) with the newer workspace image. Make sure to use the same configuration, volume, name, and port. For example, a workspace (image version 0.8.7 ) was started with this command:
docker run -d
-p 8080:8080
--name "ml-workspace"
-v "/path/on/host:/workspace"
--env AUTHENTICATE_VIA_JUPYTER="mytoken"
--restart always
mltooling/ml-workspace:0.8.7
and needs to be updated to version 0.9.1 , you need to:
docker stop "ml-workspace" && docker rm "ml-workspace"docker run -d -p 8080:8080 --name "ml-workspace" -v "/path/on/host:/workspace" --env AUTHENTICATE_VIA_JUPYTER="mytoken" --restart always mltooling/ml-workspace:0.9.1 If you want to directly connect to the workspace via a VNC client (not using the noVNC webapp), you might be interested in changing certain VNC server configurations. To configure the VNC server, you can provide/overwrite the following environment variables at container start (via docker run option: --env ):
| Переменная | Описание | По умолчанию |
|---|---|---|
| VNC_PW | Password of VNC connection. This password only needs to be secure if the VNC server is directly exposed. If it is used via noVNC, it is already protected based on the configured authentication mechanism. | vncpassword |
| VNC_RESOLUTION | Default desktop resolution of VNC connection. When using noVNC, the resolution will be dynamically adapted to the window size. | 1600x900 |
| VNC_COL_DEPTH | Default color depth of VNC connection. | 24 |
Unfortunately, we currently do not support using a non-root user within the workspace. We plan to provide this capability and already started with some refactoring to allow this configuration. However, this still requires a lot more work, refactoring, and testing from our side.
Using root-user (or users with sudo permission) within containers is generally not recommended since, in case of system/kernel vulnerabilities, a user might be able to break out of the container and be able to access the host system. Since it is not very common to have such problematic kernel vulnerabilities, the risk of a severe attack is quite minimal. As explained in the official Docker documentation, containers (even with root users) are generally quite secure in preventing a breakout to the host. And compared to many other container use-cases, we actually want to provide the flexibility to the user to have control and system-level installation permissions within the workspace container.
The workspace comes preinstalled with various common tools to create isolated Python environments (virtual environments). The following sections provide a quick-intro on how to use these tools within the workspace. You can find information on when to use which tool here. Please refer to the documentation of the given tool for additional usage information.
venv (recommended):
To create a virtual environment via venv, execute the following commands:
# Create environment in the working directory
python -m venv my-venv
# Activate environment in shell
source ./my-venv/bin/activate
# Optional: Create Jupyter kernel for this environment
pip install ipykernel
python -m ipykernel install --user --name=my-venv --display-name= " my-venv ( $( python --version ) ) "
# Optional: Close enviornment session
deactivatepipenv (recommended):
To create a virtual environment via pipenv, execute the following commands:
# Create environment in the working directory
pipenv install
# Activate environment session in shell
pipenv shell
# Optional: Create Jupyter kernel for this environment
pipenv install ipykernel
python -m ipykernel install --user --name=my-pipenv --display-name= " my-pipenv ( $( python --version ) ) "
# Optional: Close environment session
exitvirtualenv :
To create a virtual environment via virtualenv, execute the following commands:
# Create environment in the working directory
virtualenv my-virtualenv
# Activate environment session in shell
source ./my-virtualenv/bin/activate
# Optional: Create Jupyter kernel for this environment
pip install ipykernel
python -m ipykernel install --user --name=my-virtualenv --display-name= " my-virtualenv ( $( python --version ) ) "
# Optional: Close environment session
deactivateconda :
To create a virtual environment via conda, execute the following commands:
# Create environment (globally)
conda create -n my-conda-env
# Activate environment session in shell
conda activate my-conda-env
# Optional: Create Jupyter kernel for this environment
python -m ipykernel install --user --name=my-conda-env --display-name= " my-conda-env ( $( python --version ) ) "
# Optional: Close environment session
conda deactivateTip: Shell Commands in Jupyter Notebooks:
If you install and use a virtual environment via a dedicated Jupyter Kernel and use shell commands within Jupyter (eg !pip install matplotlib ), the wrong python/pip version will be used. To use the python/pip version of the selected kernel, do the following instead:
import sys
!{ sys . executable } - m pip install matplotlibThe workspace provides three easy options to install different Python versions alongside the main Python instance: pyenv, pipenv (recommended), conda.
pipenv (recommended):
To install a different python version (eg 3.7.8 ) within the workspace via pipenv, execute the following commands:
# Install python vers
pipenv install --python=3.7.8
# Activate environment session in shell
pipenv shell
# Check python installation
python --version
# Optional: Create Jupyter kernel for this environment
pipenv install ipykernel
python -m ipykernel install --user --name=my-pipenv --display-name= " my-pipenv ( $( python --version ) ) "
# Optional: Close environment session
exitpyenv :
To install a different python version (eg 3.7.8 ) within the workspace via pyenv, execute the following commands:
# Install python version
pyenv install 3.7.8
# Make globally accessible
pyenv global 3.7.8
# Activate python version in shell
pyenv shell 3.7.8
# Check python installation
python3.7 --version
# Optional: Create Jupyter kernel for this python version
python3.7 -m pip install ipykernel
python3.7 -m ipykernel install --user --name=my-pyenv-3.7.8 --display-name= " my-pyenv (Python 3.7.8) "conda :
To install a different python version (eg 3.7.8 ) within the workspace via conda, execute the following commands:
# Create environment with python version
conda create -n my-conda-3.7 python=3.7.8
# Activate environment session in shell
conda activate my-conda-3.7
# Check python installation
python --version
# Optional: Create Jupyter kernel for this python version
pip install ipykernel
python -m ipykernel install --user --name=my-conda-3.7 --display-name= " my-conda ( $( python --version ) ) "
# Optional: Close environment session
conda deactivateTip: Shell Commands in Jupyter Notebooks:
If you install and use another Python version via a dedicated Jupyter Kernel and use shell commands within Jupyter (eg !pip install matplotlib ), the wrong python/pip version will be used. To use the python/pip version of the selected kernel, do the following instead:
import sys
!{ sys . executable } - m pip install matplotlib Certain desktop tools (eg, recent versions of Firefox) or libraries (eg, Pytorch - see Issues: 1, 2) might crash if the shared memory size ( /dev/shm ) is too small. The default shared memory size of Docker is 64MB, which might not be enough for a few tools. You can provide a higher shared memory size via the shm-size docker run option:
docker run --shm-size=2G mltooling/ml-workspace:0.13.2 In general, the performance of running code within Docker is nearly identical compared to running it directly on the machine. However, in case you have limited the container's CPU quota (as explained in this section), the container can still see the full count of CPU cores available on the machine and there is no technical way to prevent this. Many libraries and tools will use the full CPU count (eg, via os.cpu_count() ) to set the number of threads used for multiprocessing/-threading. This might cause the program to start more threads/processes than it can efficiently handle with the available CPU quota, which can tremendously slow down the overall performance. Therefore, it is important to set the available CPU count or the maximum number of threads explicitly to the configured CPU quota. The workspace provides capabilities to detect the number of available CPUs automatically, which are used to configure a variety of common libraries via environment variables such as OMP_NUM_THREADS or MKL_NUM_THREADS . It is also possible to explicitly set the number of available CPUs at container startup via the MAX_NUM_THREADS environment variable (see configuration section). The same environment variable can also be used to get the number of available CPUs at runtime.
Even though the automatic configuration capabilities of the workspace will fix a variety of inefficiencies, we still recommend configuring the number of available CPUs with all libraries explicitly. Например:
import os
MAX_NUM_THREADS = int ( os . getenv ( "MAX_NUM_THREADS" ))
# Set in pytorch
import torch
torch . set_num_threads ( MAX_NUM_THREADS )
# Set in tensorflow
import tensorflow as tf
config = tf . ConfigProto (
device_count = { "CPU" : MAX_NUM_THREADS },
inter_op_parallelism_threads = MAX_NUM_THREADS ,
intra_op_parallelism_threads = MAX_NUM_THREADS ,
)
tf_session = tf . Session ( config = config )
# Set session for keras
import keras . backend as K
K . set_session ( tf_session )
# Set in sklearn estimator
from sklearn . linear_model import LogisticRegression
LogisticRegression ( n_jobs = MAX_NUM_THREADS ). fit ( X , y )
# Set for multiprocessing pool
from multiprocessing import Pool
with Pool ( MAX_NUM_THREADS ) as pool :
results = pool . map ( lst )If you encounter the following error within the container logs when starting the workspace, it will most likely not be possible to run the workspace on your hardware:
exited: nginx (terminated by SIGILL (core dumped); not expected)
The OpenResty/Nginx binary package used within the workspace requires to run on a CPU with SSE4.2 support (see this issue). Unfortunately, some older CPUs do not have support for SSE4.2 and, therefore, will not be able to run the workspace container. On Linux, you can check if your CPU supports SSE4.2 when looking into the cat /proc/cpuinfo flags section. If you encounter this problem, feel free to notify us by commenting on the following issue: #30.
Requirements : Docker and Act are required to be installed on your machine to execute the build process.
To simplify the process of building this project from scratch, we provide build-scripts - based on universal-build - that run all necessary steps (build, test, and release) within a containerized environment. To build and test your changes, execute the following command in the project root folder:
act -b -j buildUnder the hood it uses the build.py files in this repo based on the universal-build library. So, if you want to build it locally, you can also execute this command in the project root folder to build the docker container:
python build.py --makeFor additional script options:
python build.py --helpRefer to our contribution guides for more detailed information on our build scripts and development process.
Licensed Apache 2.0 . Created and maintained with ❤️ by developers from Berlin.
