There are two files generated after running
opctl init --provider <provider>:
params.yaml- contains the fields that need to be updated to configure your deployment.
config.yaml- contains components that are going to be included in the deployment. This file is generated automatically and should not be updated.
For further information on populating the
params.yaml file, refer to the sections below. This information is also available inside the generated
Content of configuration file
The template below is automatically generated when your run
opctl init for your provider.
This particular one was generated by running
What follows is a more detailed description of each section of the
This is where you set the basic application configuration.
This is the first Namespace you want created. This could be a project name or a team name. It is set to
default by default but we recommend you use something more meaningful.
This is the domain for your Onepanel resources. Some resources like Workspaces create subdomains of this domain so they can be accessed by a browser. This can be a top level domain like
example.com or a subdomain
This is where Onepanel UI and API will be deployed. This should be a subdomain of the
domain field mentioned above. For example:
insecure field is automatically set to
true by default and will be set to
false if you add the
--enable-https when running
opctl init. Do not update this field manually.
Depending on your provider, these are either called node pools or node groups. They are labels on Kubernetes nodes that Onepanel uses for auto scaling nodes on demand.
label to identify these is
node.kubernetes.io/instance-type which most cloud providers automatically set. The value of this label is usually set to the instance type of the cloud provider.
Kubernetes 1.16.x you will need to use
AKS (all versions) and GKE 1.17.x: you would need to use
beta.kubernetes.io/instance-type as well.
EKS 1.16.x: make sure to use
beta.kubernetes.io/instance-type label in tags when adding node groups.
You can see all labels on your nodes by running:
Note that this lists many different labels, so you can pick and choose any label key/value that is unique to that node.
For example after running the
kubectl command above, you may get the following list of labels:
You can then use the label key/value pairs as follows. Note that setting
resources.limits field is required for GPUs.
See adding more nodes for more information on adding additional CPU or GPU nodes to your cluster.
In this section, you can set up the default object storage to store your Workflow and Workspace artifacts. The default object storage is set per namespace and is used to automatically save snapshots of logs, models and any other output from you Workflows or easily sync data between Workspaces and Workflows.
Currently Amazon S3, MinIO S3, Google Cloud Storage (GCS) and Azure Blob Storage are supported.
Example Amazon S3 configuration:
MinIO configurations would be similar to Amazon S3 with a different endpoint:
Google Cloud Storage (GCS)
Example Google Cloud Storage (GCS) configuration:
You can get the serviceAccount JSON with the following command:
Azure Blob Storage
Example Azure Blob Storage configuration:
If you have run
opctl init with
--dns-provider flags set, you need to configure your respective DNS provider here so that Onepanel can create and renew your TLS certificates for you.
See TLS certificates for more information about configuring this section.
This is the database settings section.
Note that you can update your settings as many times as you like and simply run
opctl apply again to update your your database settings in the cluster.
Example production database settings:
For a test cluster, you can set the database
postgres and use any
password. This database will be automatically created in the cluster with the information you entered.
Note that you cannot change the username/password for the test database once it's created, so if you make a mistake, you will have to delete the test database and run
opctl apply again:
Example test database settings:
The executor workflow engine uses to perform certain actions like monitoring pod logs, collecting artifacts, managing container lifecycles, etc.
The possible values are
dockeris more reliable, however it mounts the
docker.sockof the host makes it less secure.
pnsis more secure, however in some versions of Kubernetes, it tends to fail on tasks that take less than 15 seconds.