Configuration files
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 params.yaml
template.
tip
It is highly recommended that you commit params.yaml
file into a private repository and encrypt it with BlackBox or use a secret management service like Azure Key Vault, AWS Secret Manager, GCP Secret Manager or HashiCorp Vault.
params.yaml
Content of configuration file important
The template below is automatically generated when your run opctl init
for your provider.
This particular one was generated by running
Sections
What follows is a more detailed description of each section of the params.yaml
file.
application
This is where you set the basic application configuration.
defaultNamespace
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.
domain
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 sub.example.com
.
fqdn
This is where Onepanel UI and API will be deployed. This should be a subdomain of the domain
field mentioned above. For example: app.example.com
or app.sub.example.com
.
insecure
The 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.
nodePool
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.
A common 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.
important
Kubernetes 1.16.x you will need to use beta.kubernetes.io/instance-type
instead.
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.
artifactRepository
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.
Amazon S3
Example Amazon S3 configuration:
MinIO S3
MinIO configurations would be similar to Amazon S3 with a different endpoint:
Google Cloud Storage (GCS)
Example Google Cloud Storage (GCS) configuration:
tip
You can get the serviceAccount JSON with the following command:
Azure Blob Storage
Example Azure Blob Storage configuration:
certManager
If you have run opctl init
with --enable-https
, --enable-cert-manager
and --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.
database
This is the database settings section.
Production database
For a production deployment, use a managed PostgresSQL database like Amazon RDS, Azure Database or Google Cloud SQL.
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:
Test database
For a test cluster, you can set the database host
to postgres
and use any username
or 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:
workflowEngine
containerRuntimeExecutor
The executor workflow engine uses to perform certain actions like monitoring pod logs, collecting artifacts, managing container lifecycles, etc.
The possible values are docker
and pns
:
docker
is more reliable, however it mounts thedocker.sock
of the host makes it less secure.pns
is more secure, however in some versions of Kubernetes, it tends to fail on tasks that take less than 15 seconds.