Distri.AI
English
English
  • ๐ŸชŸIntroduction
    • ๐ŸงฒWhat is Distri.AI
    • ๐Ÿ—ž๏ธWhitepaper
  • ๐Ÿ•น๏ธGetting Started
    • ๐Ÿ›’User
    • ๐Ÿ› ๏ธCompute Node
    • ๐ŸšฐFaucet
  • ๐Ÿ”ฑDistri.AI Aggregator
    • ๐Ÿ๏ธGPU Market
    • ๐Ÿ›ซModel Hub
    • ๐Ÿ“‘Dataset Repository
  • ๐Ÿ“ฆML Workspace
    • ๐ŸคนJupyter
    • ๐Ÿคนโ€โ™€๏ธDesktop GUI
    • ๐Ÿคนโ€โ™€๏ธVisual Studio Code
    • ๐Ÿคนโ€โ™‚๏ธJupyterLab
    • ๐ŸคนGit Integration
    • ๐Ÿคนโ€โ™€๏ธFile Sharing
    • ๐Ÿคนโ€โ™‚๏ธAccess Ports
    • ๐ŸคนTensorboard
    • ๐Ÿคนโ€โ™€๏ธExtensibility
    • ๐Ÿคนโ€โ™‚๏ธHardware Monitoring
    • ๐ŸคนSSH Access
    • ๐Ÿคนโ€โ™€๏ธRemote Development
    • ๐Ÿคนโ€โ™‚๏ธRun as a job
    • ๐Ÿ“ฌFAQ
  • ๐Ÿ“žContact & Social Media
Powered by GitBook
On this page
  1. ML Workspace

FAQ

PreviousRun as a jobNextContact & Social Media

Last updated 1 year ago

How to customize the workspace image (create your own flavor)? (click to expand...)

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.10.4

# 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.sh

Finally, use to build your customized Docker image.

๐Ÿ“– For a more comprehensive Dockerfile example, take a look at the .

How to update a running workspace container? (click to expand...)

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.

Update Example (click to expand...)

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:

  1. Stop and remove the running workspace container: docker stop "ml-workspace" && docker rm "ml-workspace"

  2. Start a new workspace container with the newer image and same configuration: 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

How to use a non-root user within the workspace? (click to expand...)

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 , 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.

How to create and use a virtual environment? (click to expand...)

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 . Please refer to the documentation of the given tool for additional usage information.

venv (recommended):

To create a virtual environment via , 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
deactivate

pipenv (recommended):

To create a virtual environment via , 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
exit

virtualenv:

To create a virtual environment via , 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
deactivate

conda:

To create a virtual environment via , 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 deactivate

Tip: Shell Commands in Jupyter Notebooks:

If you install and use a virtual environment via a dedicated Jupyter Kernel and use shell commands within Jupyter (e.g. !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
How to install a different Python version? (click to expand...)

The workspace provides three easy options to install different Python versions alongside the main Python instance: , (recommended), .

pipenv (recommended):

To install a different python version (e.g. 3.7.8) within the workspace via , 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
exit

pyenv:

To install a different python version (e.g. 3.7.8) within the workspace via , 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 (e.g. 3.7.8) within the workspace via , 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 deactivate

Tip: Shell Commands in Jupyter Notebooks:

If you install and use another Python version via a dedicated Jupyter Kernel and use shell commands within Jupyter (e.g. !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
๐Ÿ“ฆ
๐Ÿ“ฌ
docker build
Dockerfile of the R-flavor
official Docker documentation
here
venv
pipenv
virtualenv
conda
pyenv
pipenv
conda
pipenv
pyenv
conda