See our Templates repository for a list of ready to use Workspace Templates. You can also use these as reference for defining youur own Workspace Templates.
Getting started with Workspace Templates
You can define reusable templates for Workspaces. Workspace Templates are a combination of Docker images and a YAML definition. Each section in this template abstracts and simplifies Kubernetes YAML and at the same time provides maximum flexibility.
Onepanel's Workspace Template YAML definitions are composed of subsets of Kubernetes and Istio YAML definitions.
Here's a simple NGINX Workspace Template definition:
You can define and use parameters in your Workspace Templates. These parameters are displayed in the Workspace creation form (or are made available via CLI) and can be referenced in the template like so:
The syntax for parameter definitions are as follows:
If a parameter is defined,
value are required.
nameis the name of the parameters, only alphanumeric characters and
valueis the default value for the parameter
displayNameis the text that is displayed to the user
typeindicates how the parameter is rendered in the Workspace creation form in the Web UI. Possible values are:
input.textrenders a textbox
input.numberrenders a textbox that only accepts numbers
input.radiorenders radio buttons
select.selectrenders a dropdown
textarea.textarearenders a textarea
optionsdefine options if
This is where you define the container(s) that your Workspace needs to function.
The name of the container, should be unique in this template definition.
The image you want to use for your application.
Some examples include:
command and args
If you want to override the Docker image ENTRYPOINT, then you can use a combination of
args fields to do that, for example:
For more information, see Define a Command and Arguments for a Container in Kubernetes docs.
These are environment variables that you want to define specifically for this Workspace.
Onepanel automatically adds certain Environment variables along with the ones you define in the Settings section before these environment variables. Though not recommended, you can override those by naming these environment variables the same.
These are the ports needed by the image you use. Make sure to add all of the ones you want to have access to.
- For the
nginxdemos/hellowe need port 80.
jupyter/tensorflow-notebookwe need port 8888.
This is where you define volumes to be mounted in a container. Onepanel will automatically create these volumes and mount them to the container. You can choose the size of the volume when you start the workspace.
For example, the following will mount a volume in your container at
You can mount an number of volumes allowed by the cloud provider's machine type. There is generally a limit on how many disks you can attach based on the size of the machine.
These identify what ports your workspace exposes and the protocol used. These are NOT the same as container ports. Your workspace will have a url you can visit in your browser, and it is the ports defined under this section that are visible.
Each port can map to a container port. So if you have port 8888 on your container, but you want to reach it via http (port 80), use:
These are the urls that you can reach on your workspace. Each one must map to a port defined under
For example, if you want the root of your workspace to take you to your only container running under port
You can also do regex matching:
Or query parameter matching:
By setting the
volumeClaimTemplates field, you can override the volumes that Onepanel automatically generates. This is useful if you want to define your own
storageClass or make the storage size to a static number.
Note that the automatically generated volume is overwritten only if the
volumeClaimTemplates matches the
This is a DAG workflow that runs after your workspace is ready. For more information, see Workflow Templates.
More involved example
Let's look at a more complicated example to cement some of these ideas.
For this example, we're going to have both JupyterLab and Visual Studio Code in the same workspace.
JupyterLab will be accessible at
<url>/jupyterlab and Visual Studio Code will be at the root
Here's the final YAML, we've added comments to explain different parts.
The comments in the YAML above should provide most of the information about the setup.
The key points here are:
- We can have multiple containers running on the same workspace
portssection can be thought of as a mapping for
- jupyter allows you to run at
/jupyteras a setting. Not all software supports something like this.