Skip to content

CLI

RCTL can be used to manage the end-to-end lifecycle of a workload from an external CI system such as Jenkins etc. The table below describes the workload operations that can be automated using RCTL.

Resource Create Get Update Delete Publish Unpublish
Workload YES YES YES YES YES YES

Create Workload

Create a new workload using a definition file as the input. The workload definition is a YAML file that captures all the necessary details required for the Controller to manage the lifecycle of the workload.

Important

It is strongly recommended that customers version control their workload definition files in their Git repositories.

./rctl create workload <path to workload definition file>

Helm Chart Workloads

Both Helm v3 and v2 are supported.

  • For Helm v3 based workloads, the controller acts as the Helm client.
  • For Helm v2 based workloads, the controller translates the payload into k8s resources before applying it to the cluster.

An illustrative example for a Helm based workload definition is shown below

#Provide unique name for workload
name: voting-results
#Indicate namespace where the workload should be deployed
namespace: vote
#Indicate the name of the Project where the workload should be deployed
project: defaultproject
#Specify type of workload (Helm or Helm3)
type: Helm3
#Specify list of clusters. Use comma as delimiter
clusters: eks-oregon-dev, eks-london-dev
#Use backslash for Windows and forward slash for Linux and macOS
#For Linux and macOS
payload: "./results.tgz"
values: "./values-dev.yaml"

k8s Yaml Workloads

An illustrative example for a k8s YAML based workload definition is shown below

#Provide unique name for workload
name: voting-results
#Indicate namespace where the workload should be deployed
namespace: vote
#Indicate the name of the Project where the workload should be deployed
project: defaultproject
#Specify type of workload
type: NativeYaml
#Specify list of clusters. Use comma as delimiter
clusters: eks-oregon-dev, eks-london-dev
#Specify the k8s YAML file
#Use backslash for Windows and forward slash for Linux and macOS
#For Linux and macOS
payload: ./results.yaml

List Workloads

Use RCTL to retrieve/list all workloads in the specified Project.

In the example below, the command will list all the workloads in clusters in the "qa" project.

./rctl get workload --project qa

NAME     NAMESPACE   TYPE         STATE   ID
apache   apache      NativeHelm   READY   2d0zjgk
redis    redis       NativeHelm   READY   k5xzdw2

The command will return all the workloads with metadata similar to that in the Web Console.

  • Name
  • Namespace
  • Type
  • State
  • ID

Publish Workload

Use RCTL to publish a workload to a fleet of clusters in a specified Project.

./rctl publish workload <workload name>

In the example below, the command will attempt to publish the "apache" workload in the "qa" project.

./rctl publish workload apache --project qa

Unpublish Workload

Use RCTL to unpublish a workload.

./rctl unpublish workload <workload name>

In the example below, the "apache" workload will be unpublished in the "qa" project

./rctl unpublish workload apache --project qa

Delete Workload

Use RCTL to delete a workload identified by name. Note that a delete operation will unpublish the workload first.

./rctl delete workload <workload name>

Status

Use this command to check status of a workload. The status of a workload can be checked on all deployed clusters with a single command.

./rctl status workload <workload name>

If the workload has not yet been published, it will return a "Status = Not Ready". If the publish is in progress, it will return a "Status = Pending". Once publish is successful, it will return a "Status = Ready". Status is presented by cluster for all configured clusters. The workload states transition as follows "Not Ready -> Pending -> Ready".

An illustrative example is shown below. In this example, the publish status of the workload is listed by cluster.

./rctl status workload apache --project qa

CLUSTER      PUBLISH STATUS   MORE INFO
qa-cluster   Published

Update Workload Config

Use this when you need to update the "Workload Definition" for an existing workload. For example, you may want to add a new cluster location where the workload needs to be deployed.

Workload definitions can be updated even if it is already published and operational on clusters. Once the workload definition is updated, ensure that you follow up with a "publish" operation to make sure that the updated workload definition is applied.

./rctl update workload <path-to-workload-definition-json-file> [flags]

Download Workload Config

Users can download an existing workload's configuration from the Controller. A common use case is to retrieve this and store this in a version controlled Git repository. Users can also create the workload using the Console and then download the workload configuration via RCTL.

In the example below, we requested the download of the config for the workload "apache". The downloaded configuration file is available in "apache.yaml"

./rctl download workload apache --project qa

Meta file: apache.yaml
Payload file: ./apache-7.5.1.tgz
Values file: N/A

k8s Yaml Workload

This will download and save two files to the same folder as RCTL

  1. Meta File: Workload's description yaml
  2. Payload: The actual k8s yaml

Helm Workload

This will download and save three files to the same folder as RCTL

  1. Meta File: Workload's description yaml
  2. Payload: The Helm chart (TGZ file)
  3. Values: The values.yaml file if configured.

Validate Workload

Note

This is a convenience function that is supported only for workloads based on the "Workload Wizard".

Users can use this to validate their "workload definitions" before attempting to publish them to ensure they can identify misconfigurations earlier in the process.

./rctl validate workload <workload name>