Hello Everybody.
Introduction
This article will discuss the functionality of how we can use Custom Selectors to automate the process of Delegate selection based on the context of the Application resources. This acts as a great alternative to Scoping where you can provide the Selector details in the Workflow Steps to make sure Delegates assigned that Selector are picked up as expected. Harness does provide three Implicit Selectors which are generated at the time of Delegate creation.
These Implicit Selectors cannot be changed once the delegate has been created and in order to use them you would need to provide the exact hostname of the Delegate in the Workflow step. However this would mean in order for a step in the Workflow to select a Delegate for its execution would always be fixed to a delegate and would need to be explicitly provided each time in order for the selection process to be as required. There is need to automate this as it becomes tedious to scale while providing explicit values to each Workflow step. This is where the Custom Selectors come in.
In this Article we will walk through the Setup of this use-case on how using built in variables can help us provide Delegate selection Dynamically at the Workflow level using different conditions and how they can be used to fit your use case.
Lets Get Started !
Setup
Pre-requisites:
We will be using 2 Delegates as an example in this case to convey the idea of how this can be leveraged with N Number of Delegates.
Step-1 : Simple K8s Workflow Setup
To test the behavior and set this up we will be creating a simple Kubernetes Type Rolling Workflow, which would look something like below :
Here we are using a Templatised Workflow which will be executing the Shell Script. Since this is a Templatised Workflow workflow we will be using Two different Environments to check if the Delegate selection to run the Shell Script during Deployment is done Dynamically.
How we will achieve this is by using Custom Selectors, take the example of the Workflow “Test WF”. This workflow is part of the Application “Zee-K8s” the expectation here is for a specific delegate to pick up the Task of executing the Shell script during deployments.
We can achieve this using the Implicit Selectors on the Delegate end. However, this would be very specific and not dynamic, The requirement is for the Delegate selection to take place based on the Environment in which the Workflow execution is taking place which can be done by using Custom Selectors.
We have 2 Environments, one Prod and the other Non-Prod which we will be Deploying to and expect the specific delegates to pick up the Shell Script task based on which Enviroment we are deploying to without providing the details of the Delegate explicitly to the Workflow.
Setting up the Selectors will ensure that the selection is as expected.
Step-2: Adding Custom Selectors to the Delegates
In order for the required Delegate to be picked up, we will start by adding the below selectors to the Delegates. Since there are 2 Delegates in the account we will be providing selectors to them as mentioned in the image where Env 1 is Non-Prod while Env 2 is Prod.
We have added the Custom Selectors as mentioned to the Delegates which will now help allow them to be picked up dynamically at run time. The expectation is to have Delegate “new-del” be picked up when a Deployment is done to PROD
And Delegate “usheertestk8del” should be picked up when the Deployment is done to NON_PROD.
Step-3: Adding the Dynamic Variable at the Workflow Level
Now that the selectors are in place, lets place the built-in variables at the Workflow level which will resolve to match to the Custom selectors we have set on the Delegate end, these variables are picked up from the Built-in Variables which Harness supports mentioned here : Built-in Variables List - Harness.io Docs
In the Shell script step for the Workflow we will place the below built-in variable ${env.environmentType}
During Runtime this variable will resolve to the Type of Env the Workflow is being executed with, and since this is part of a templatised Worklow all the dependent resources like the Service, Environment can be changed as required and these variables will ensure that depending on the resolution the appropriate delegate is picked up
Conclusion:
We will first try deploying to Non_Prod Environment which is ENV-1 and see which delegate is assigned the Task, the expectation is to have the Delegate “usheertestk8del” be picked up when the Deployment is done.
In the Deployment Page, we can see that the variable resolution worked as expected and the Appropriate Delegate “usheertestk8del” has been assigned the Task
If we now deploy to the Prod Environment which is ENV-2, the expectation is to have the Delegate “new-del” be picked up when the Deployment is done.
In the Deployment Page, we can see that the variable resolution worked as expected and the Appropriate Delegate “new-del” has been assigned the Task
Using this functionality and setup we can leverage multiple built-in variables and use Custom Selectors to have Deployments dynamically pick up the delegates based on the required context linked to them.
Thank you for Reading.