# Workloads This is a legacy version For the latest Workloads CLI information, see the [Workloads CLI](https://docs.rafay.co/workloads/wl_cli/) topic. 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 ``` * * * ### 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" ``` * * * #### Helm Workloads from different Repos Below is an example config file to create a workload with Helm Repository and values from different repository ``` name: rctl-helm-wk14 namespace: demo-ns1 type: Helm3 clusters: demo-cluster1 driftaction: "BlockAndNotify" repository_ref: default-bitnami repo_artifact_meta: helm: tag: 9.6.5 chartName: apache value_repository_ref: test-repo additional_reference: git: repoArtifactFiles: - name: apache_value relPath: valueFiles/value-apache-9-6-5.yaml fileType: HelmValuesFile revision: main extra: helm: atomic: false cleanUpOnFail: true ``` Below is an example config file to create a workload with Helm Chart and value file from git repository ``` name: workload-test-helm description: workload created using helm-in-git-rctl namespace: ns-demo project: default type: Helm3 clusters: demo-cluster2 driftaction: "BlockAndNotify" repository_ref: apps-repo repo_artifact_meta: git: revision: main repoArtifactFiles: - name: nginx-ops relPath: apps/nginx/nginx-0.1.0.tgz fileType: HelmChartFile - name: custom-ops relPath: apps/nginx/values.yaml fileType: HelmValuesFile ``` * * * ### 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 * * * ## Wait Flag RCTL provides an option for the users to wait and block the long running operations. When an automation pipeline logic becomes extremely convoluted, enabling the **--wait** flag helps to block and keep pulling the workload publish status (example: success/failure) Once a workload is created or updated and has all the placement information to publish it on the cluster, the **wait flag** helps to get the backend information of a workload creation process flow upto the publishing stage. This get operation continues to wait and show the details and status until the publishing is successful. To view the entire operation details, use the below **wait** command ``` ./rctl publish workload --wait ``` **_Example Output_** ``` 1.6431226870150652e+09 debug commands/common.go:126 Prerun 1.643122687015836e+09 info context/context.go:58 Context: {"config_dir":"/Users/user1/.rafay/cli","config_file":"config.json","verbose":true,"debug":true,"structured_output":false,"v3":false} ... ``` > **Note:** Use the **--wait** flag only when publishing the workload * * * ## Publish Workload Use RCTL to publish a workload to a fleet of clusters in a specified Project. ``` ./rctl publish workload ``` 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 ``` 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 ``` * * * ## 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 ``` 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 ``` Use the below command to fetch the real time detailed status of a workload like K8s object names, objects latest condition, and cluster events ``` ./rctl status workload --detailed --cluster=,.. ``` > **Note:** The flag **--cluster** is optional and **Helm2** type workload(s) is currently not supported **_Example_** ``` ./rctl status workload test-helminhelm --detailed --clusters=oci-cluster-1 ``` **_Output_** ``` +---------------+----------------------------------------------------------+----------------------+K8S OBJECT LATEST CONDITION+ | CLUSTER NAME | K8S OBJECT NAME | K8S OBJECT NAMESPACE | K8S OBJECT LATEST CONDITION | ... ``` * * * ## 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 [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 ``` * * *