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.
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.
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
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.
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
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
Use RCTL to delete a workload identified by name. Note that a delete operation will unpublish the workload first.
./rctl delete workload <workload name>
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
- Meta File: Workload's description yaml
- Payload: The actual k8s yaml
This will download and save three files to the same folder as RCTL
- Meta File: Workload's description yaml
- Payload: The Helm chart (TGZ file)
- Values: The values.yaml file if configured.
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>