Delegate Installation and Management

Updated 4 days ago by Michael Cretzman

The Harness Delegate is a service you run in your local network or VPC to connect your artifact servers, infrastructure, collaboration, and verification providers with the Harness Manager.

In this article:

You might need to install multiple Delegates depending on how many Continuous Delivery tasks you do concurrently, and on the compute resources you are providing to each Delegate. Typically, you will need one Delegate for every 300-500 service instances across your applications.

Intended Audience

  • DevOps

Delegate Requirements

The Delegate is installed in your network and connects to the Harness Manager.

  • Linux/UNIX server or container.
  • ​Minimum 1 CPU.
  • Minimum 8GB RAM. Ensure that you provide the minimum memory for the Delegate and enough memory for the host/node system. For example, an AWS EC2 instance type such as m5.xlarge has 16GB of RAM, 8 for the Delegate and 8 for the remaining operations.
  • Minimum 6GB Disk space.
  • Access to artifact servers, deployment environments, and cloud providers.
Multiple Delegates can be used and their scope can be managed. For more information, see Delegate Scope.

Delegate Access Requirements

  • The Harness Delegate does NOT require root account access.

Where do I Install the Delegate?

  • Evaluating Harness - When evaluating Harness, you might want to install the Delegate locally. Ensure that it has access to the artifact sources, deployment environments, and verification providers you want to use with Harness.
  • Development, QA, and Production - The Delegate should be installed behind your firewall and in the same VPC as the micro-services you are deploying. The Delegate must have access to the artifact servers, deployment environments, and cloud providers it needs.

Install the Harness Delegate

To install the Delegate:

  1. Sign into the Harness Manager.
  2. Download and install the Harness Delegate.
    1. Click Setup.
    2. Click Harness Delegates.
      You can download the Delegate scripts or copy and use the cURL commands to install the Delegate.
    3. Click Download Delegate.
    To install using cURL, click the copy icon next to the Shell Script or Docker Image options, connect to the machine or instance where you want to run the Delegate, and use cURL to download the Delegate.
    1. To use the Shell Script, unzip the file and run the start.sh script ($ ./start.sh).
    2. To use Docker, unzip the file and run the start script ($ ./launch-harness-delegate.sh). You will see the Docker image pull, for example:
    latest: Pulling from harness/delegate
    297061f60c36: Pull complete…
    Status: Downloaded newer image for harness/delegate:latest
    1. For Kubernetes, unzip the file and navigate into the extracted folder in a Terminal. Next, log into your cluster via the Terminal, and run the following commands (ensure you have kubectl installed and credentials to access your Kubernetes cluster):

      $ kubectl apply -f harness-delegate.yaml (installs or replaces the Harness Delegate)
      $ kubectl get pods -n harness-delegate (get pod names)
      $ kubectl logs <pod-name> -n harness-delegate -f (see startup logs)
      $ kubectl exec <pod-name> -n harness-delegate -it -- bash (run a shell in a pod)

      For example, with Google Cloud Platform, you can click the Connect button for your Kubernetes cluster, copy the Command-line access command, and the paste and run it in a Terminal running on the host where you downloaded the harness-delegate.yaml file. Once you are connected, you simply cd to the folder where harness-delegate.yaml is located and run:

      $ kubectl apply -f harness-delegate.yaml.
      If needed, edit the harness-delegate.yaml you unzipped to change the namespace, set proxy settings, or to enter a Delegate description.
  3. Once the Delegate is installed, the Delegate is listed in the Installations page in a few moments.

In the Installation page is the the list of installed Delegates. The information displayed includes:

  • Hostname.
  • IP Address.
  • Status.
  • Last heartbeat. This is the last time the delegate communicated with the Harness Manager. The Delegate pings the Manager once a minute.
  • Delegate version.

Installation Example: Google Cloud Platform

The following steps describe how to install the Kubernetes Delegate in a Kubernetes cluster in Google Cloud Platform. The steps assume you have Google Cloud SDK installed, as it is used to execute gcloud command-line commands. For more information on installing the Google Cloud SDK, see Install the Latest Cloud SDK version from Google.

A Kubernetes cluster in Google Cloud Platform has a variety of settings that are different from other vendors. For example, when creating your cluster in Google Cloud Platform, you might need to add more or less CPUs or RAM to your nodes than you would with another cloud vendor or an Internal cluster.
  1. Sign up for a free tier Google Cloud Platform account.
  2. In Google Cloud Platform, create a Kubernetes cluster.
    1. In Kubernetes Engine, click CREATE CLUSTER.
    2. Choose the Standard cluster template.
    3. Customize the template:
      Name: Enter the name for the cluster.
      Location type: Select Zonal for this example.
      Zone: Select the default Compute Engine compute zone, as the location type is Zonal.
    4. For Node pools, do the following:
      Number of nodes: Enter 3 nodes.
      Machine type: Enter 4vCPU, and click Customize. In Memory, enter 12GB. 8GB is for the Delegate. The remaining memory is for Kubernetes.
    5. Click the Advanced edit button.
    6. In the Edit node pool panel, below Size, click Enable autoscaling.
    7. Enter a Minimum of 3 and a Maximum of 8.
      When you are done, your setting will look something like this:
    8. Click Save.
    9. Click Create to create the cluster. It will take a few minutes to create the Kubernetes cluster.
  3. When the cluster is created, click the Connect button.
  4. In the Connect to the cluster dialog, copy the Command-line access command.
  5. On your local machine, open a Terminal, and paste the command, and press Enter. You are now connected to the Kubernetes cluster.

    By default, your cluster should be able to connect to the Internet. If you run into errors, ensure the GCE firewall isn’t blocking port 22 to your VMs. For more information, see SSH troubleshooting from Kubernetes.
    1. Let's quickly confirm that the cluster you created can connect to the Harness platform. Enter the following command:

      wget -p https://app.harness.io/ -O /dev/null
      A successful connection will display the following output:
      Resolving app.harness.io (app.harness.io)... 35.197.53.196
      Connecting to app.harness.io (app.harness.io)|35.197.53.196|:443... connected.
      HTTP request sent, awaiting response... 200 OK
  6. Download the Kubernetes Delegate from Harness.
    1. In Harness, click Setup, and then click Harness Delegates.
    2. Click Download Delegate and then click Kubernetes YAML.
    3. In the Delegate Setup dialog, enter a name for the Delegate, such as harness-sample-k8s-delegate, and click Submit. the YAML file is downloaded to your machine.
  7. Install the Delegate in your cluster.
    1. In the Terminal you used to connect to the Kubernetes cluster, navigate to the folder where you downloaded the Harness Delegate YAML file.
      For example, cd ~/Downloads.
    2. Extract the YAML file: tar -zxvf harness-delegate-kubernetes.tar.gz.
    3. Navigate to the harness-delegate folder that was created:
      cd harness-delegate-kubernetes
    4. Paste the following installation command into the Terminal and press enter:
      kubectl apply -f harness-delegate.yaml
      You will see the following output (this delegate is named k8s-test):
      namespace/harness-delegate created
      clusterrolebinding.rbac.authorization.k8s.io/harness-delegate-cluster-admin created
      statefulset.apps/k8s-test-vutpmk created
  8. Run this command to verify that the Delegate pod was created:
    kubectl get pods -n harness-delegate

    You will see output with the status Pending. The Pending status simply means that the cluster is still loading the pod.
  9. Wait a few moments for the cluster to finish loading the pod and for the Delegate to connect to Harness Manager.
  10. In Harness Manager, in the Harness Delegates page, the new Delegate will appear. You can refresh the page if you like.

Installation Example: Amazon Web Services and ECS

The following steps show you how to install the ECS Delegate in a ECS cluster to enable the Delegate to connect to your AWS resources. We use ECS as an example, although the steps are the same for other AWS services.

Requirements for ECS Delegate

The ECS setup used to host the ECS Delegate must have the following:

  • ECS Cluster.
  • ECS Cluster must have 8GM memory for each ECS Delegate service added (t2.large minimum).
  • AWS IAM Role containing the required policies. The AWS policies are described in detail in ECS (Existing Cluster). For information on adding an IAM role to the ECS Delegate task definition, see Trust Relationships and Roles.

For information on adding the IAM role and policy, see Amazon ECS Container Instance IAM Role from AWS.

Ensure that you add the IAM roles and policies to your ECS cluster when you create it. You cannot add the IAM roles and policies to an existing ECS cluster. You can add policies to whatever role is already assigned to an existing ECS cluster.

Need a Cluster? If you do not have an AWS account, you can use an AWS Free Tier account and create an ECS cluster by following the steps in ECS Getting Started from Amazon. If you do have an AWS account and you want to evaluate Harness with ECS, you can simply create a new ECS cluster in your AWS account.

As a best practice, install the Delegate in the same VPC as the AWS resources Harness will use. You can even choose to install the Delegate in the same subnet. Installing the Delegate in the same VPC will help you to avoid cross-VPC networking complexities.

Set up ECS Delegate in AWS

There are two specs in the Harness ECS Task Spec download, ecs-task-spec.json and service-spec-for-awsvpc-mode.json. For EC2 or awsvpc and Fargate, use the ecs-task-spec.json spec to create the default task definition named harness-delegate-task-spec.

For EC2, you simply reference the definition name when using the aws ecs create-service command.

For awsvpc network mode and Fargate, use the service-spec-for-awsvpc-mode.json service spec when using the aws ecs create-service command and it will reference the harness-delegate-task-spec task definition.

The following procedure describes how to set up the ECS Delegate for the EC2 scenario:

  1. Download the ECS Delegate Task Spec.
    1. In Harness Manager, click Setup, and then click Harness Delegates.
    2. Click Download Delegate, and click the copy icon next to ECS Task Spec.
      The Delegate Setup dialog appears.
    3. In Delegate Group Name, enter the name for your Delegate. When you add more ECS Delegates in the future, you can add to this group. All Delegates in this group use the same Task Definition, share the same Delegate settings, including Tags. When you change a Tag, it will apply to all Delegates running under that Group.
    4. In Profile, select a Profile for the Delegate. For more information, see Delegate Profiles.
    5. In Hostname, enter a host name for the ECS Delegate. If you do not enter a hostname, ECS will use your Docker container ID as the hostname for the ECS Delegate. If you provide a hostname, ECS uses it.
    6. Click SUBMIT. The ECS Task Spec is downloaded. Next, you will use the aws CLI to register the ECS Task Spec and then create the ECS service for the ECS Delegate.
  2. Register the ECS Task Spec in AWS.
    1. Open a Terminal and navigate to the folder where you downloaded the ECS Task Spec.

    $ cd /Users/johnsmith/Desktop/delegates/ECS
    1. Extract the ECS Task Spec download.

      $ tar -zxvf harness-delegate-ecs.tar.gz
    2. Navigate to the extracted folder: cd harness-delegate-ecs.
    3. Log into AWS using your AWS Access Key ID and AWS Secret Key ID.

      $ aws configure
      AWS Access Key ID [****************LPAA]: XXXXXXX
      AWS Secret Access Key [****************4z52]: XXXXXXX
    4. Register the ECS task definition using the Harness ECS Task Spec.

      $ aws ecs register-task-definition --cli-input-json file://ecs-task-spec.json

      The JSON for the task is output.
    5. View the completed task.

      $ aws ecs list-task-definitions

      The taskDefinitionArns is output.
  3. Obtain the name of the ECS cluster where you want to create the ECS service. The cluster must have a minimum of 8GB of memory (t2.large minimum).
  4. Create the ECS service for ECS Delegate.
    1. Create the ECS service using the task definition, providing the service name in --service-name, cluster name in --cluster, and the desired number of tasks in --desired-count. The cluster will need a minimum of 8GB of memory per task.

      $ aws ecs create-service --service-name ecs-delegate --task-definition harness-delegate-task-spec --cluster default --desired-count 1

      The output will display the JSON for the new service.

      {
      "service": {
      "status": "ACTIVE",
      "serviceRegistries": [],
      "pendingCount": 0,
      "launchType": "EC2",
      "schedulingStrategy": "REPLICA",
      "loadBalancers": [],
      "placementConstraints": [],
      "createdAt": 1551222417.28,
      "desiredCount": 1,
      "serviceName": "ecs-delegate",
      ...
    2. View the new service.

      $ aws ecs list-services

      The output will display the new service:

      {
      "serviceArns": [
      "arn:aws:ecs:us-west-1:023826572170:service/ecs-delegate",
      ...
      }
    3. Wait 5 to 10 minutes for ECS to allocate resources for the service.
  5. View the new ECS Delegate in Harness Manager.
    1. In Harness Manager, in the Installations page. When the ECS Delegate connects to the Harness Manager, it is listed with a status of Connected:
      Congratulations! You are done installing and running the ECS Delegate.

      The following steps simply show you how to use a tag name to identify this delegate when making a connection to AWS. You simply instruct Harness to connect to AWS using the same IAM role as the Delegate via its tag name.
  6. Once the Delegate is listed in Harness Manager, assign a tag to the Delegate.
    1. Next to the Tags label in the Delegate listing, click Edit.
    2. In the Edit Tags dialog, enter a tag name, for example, ecs-delegate, and press Enter. Click SUBMIT. The tag is listed.
  7. Use the ECS Delegate for a Cloud provider connection.
    1. In Harness Manager, click Setup.
    2. Click Cloud Providers. The Cloud Providers page appears.
    3. Click Add Cloud Provider. The Cloud Provider dialog appears.
    4. In Type, select AWS.
    5. In Display Name, enter a name for the Cloud Provider, such as aws-ecs.
    6. Enable the Assume IAM Role on Delegate option.
    7. In Delegate Tag, click to select the tag you gave the Delegate.
    8. Click SUBMIT. The Cloud Provider is added.

Later, when you create a Harness Service or a Service Infrastructure in a Harness Environment, you will select this Cloud Provider and Harness will use the connection to obtain ECS cluster and networking information.

Multiple ECS Delegates

You can add multiple ECS Delegates using the following methods:

  • Add more tasks to the ECS service - If you installed the ECS Delegate as a ECS service, you can update the number of tasks in the ECS service. Find the task in the ECS console and click Run more like this. New delegates will be created and will have same Delegate Group in the Harness Manager.
  • Add more services - Create a new ECS service, in same or another cluster, using same ECS task definition.
  • Add more tasks - If you are running the ECS Delegate as an individual task, and not as an ECS service, you can create more ECS tasks using same ECS task definition. It does not matter if you use the same ECS cluster.

ECS Delegate Options

You can use the ECS Delegate Task Spec to set up the ECS Delegate in one of two ways:

  • Recommended - Create ECS services using the task definition created from the ECS Delegate Task Spec. An ECS service will spin up a new ECS Delegate task if any ECS Delegate task goes down, thus maintaining a persistent ECS Delegate.
  • Create and run individual ECS tasks using the task definition created from the ECS Delegate Task Spec.

Network Modes

When you download the ECS Delegate Task Spec, you can select awsvpc as the network mode. When you create the service using the ECS Delegate Task Spec, use the service-spec-for-awsvpc-mode.json file:

aws ecs create-service --cli-input-json file://<$PATH>/service-spec-for-awsvpc-mode.json

The ECS console will request network configuration info when you run the Delegate task or service, including subnets, security groups, and public IP (for Fargate launch type).

Change ECS Delegate Defaults

To change CPU, memory, port mappings, or hostname, edit the default values in ecs-task-spec.json file. You can also change any other JSON fields as needed.

Trust Relationships and Roles

If you have an IAM role that you want an ECS task to use, you need to add a trust relationship using a taskRoleArn definition in the ECS task definition. Consequently, if you have an IAM role that you want the ECS Delegate to use, you need to add a taskRoleArn definition in the ECS Delegate task definition.

The taskRoleArn is the resource ARN of an IAM role that grants containers in the task permission to call AWS APIs on your behalf.

By default, the ECS Delegate task definition does not use a taskRoleArn, but uses the cluster-level IAM role that was used to create the existing cluster.

Here is an example of a ECS Delegate task definition with the taskRoleArn added before the container definition:

{
"ipcMode": null,
"executionRoleArn": null,
"taskRoleArn": "arn:aws:iam::123456789012:role/my-task-role"
"containerDefinitions": [
{
"dnsSearchDomains": null,
"logConfiguration": null,
"entryPoint": null,
"portMappings": [
{
...
For more information, see Modifying a Role from AWS.

Delegate Proxy Settings

All of the Delegate settings include proxy settings you can use to change how the Delegate connects to the Harness Manager.

By default, the Harness Delegate uses HTTP and HTTPS in its Proxy Scheme settings.

Shell Script Proxy Settings

Run the setup-proxy.sh script included in the Delegate download and provide the proxy information.

  • Proxy URL - The syntax for the proxy URL must be of the form http[s]://<host>[:port].

The following settings are optional:

  • Username - Enter username if required.
  • Password - Enter password.
  • Suffixes - Enter a comma-separated list of suffixes that do not need the proxy. For example, .company.com,hostname,etc. Do not use leading wildcards.
Do not edit the setup-proxy.sh script. Simply run the script and provide the proxy information.

Docker Proxy Settings

The proxy settings are in the launch-harness-delegate.sh file:

-e PROXY_HOST= \
-e PROXY_PORT= \
-e PROXY_SCHEME= \
-e PROXY_USER= \
-e PROXY_PASSWORD= \
-e NO_PROXY= \

Kubernetes Proxy Settings

The proxy settings are in the harness-delegate.yaml file:

...
- name: PROXY_HOST
value: ""
- name: PROXY_PORT
value: ""
- name: PROXY_SCHEME
value: ""
- name: NO_PROXY
value: ""
- name: PROXY_USER
valueFrom:
secretKeyRef:
name: doc-example-proxy
key: PROXY_USER
- name: PROXY_PASSWORD
valueFrom:
secretKeyRef:
name: doc-example-proxy
key: PROXY_PASSWORD
...

Delegate Scope

By default, a Delegate will perform all connections you set up and processes you run. To limit, or scope, a Delegate, you can set specific boundaries and associations for each Delegate you run. You can scope a Delegate to:

  • A specific command.
  • Application.
  • Environment.
  • Environment type.
  • Service infrastructure.

Delegate Scope Example

You need to restrict access to a production environment. Without defining a scope, the Delegate scans all network ports to map out the environment and performs checks to access the artifact and cloud providers it needs. By defining a scope, you can limit the Delegate to connect to only the specific environments, applications, and service infrastructure it needs. 

Defining a scope is optional, but if you use scoping you can prevent the Delegate from constantly looking for what’s available or accessible.

Scope a Delegate

To scope a Delegate, do the following:

  1. On the Harness Delegates page, which lists all of the Delegates, select a Delegate and click Scope Included or Scope Excluded.
    The Delegate Scope dialog appears.
  2. Click New scope, and then click ADD SCOPE. The dialog changes to display the scope properties.
  3. Enter a name for the scope, and then select its properties, such as the command, Harness Application, Environment, and Service Infrastructure to which the scope applies.
    If you clicked Scope Included, then the Delegate is only used for the properties selected.
    If you clicked Scope Excluded, then the Delegate is excluded from running for the properties selected.
  4. Click SUBMIT. The scope is added to the Delegate.

Delegate Profiles

A Delegate Profile enables you to run a startup script on the host/container/pod for a Harness Delegate when the Delegate is installed. You can create a single Delegate Profile and apply it to multiple Delegates.

For example, if you need to install and run Helm every time a Harness Kubernetes Delegate is added, then you could create a Delegate Profile named Helm-Install containing the commands for installing and running Helm.

Each time you add a Kubernetes Delegate, you apply the Helm-Install profile. For example:

When the Delegate is started, the commands to install and run Helm are executed.

Another example would be a Delegate Profile that installs Terraform:

curl -O -L https://releases.hashicorp.com/terraform/0.11.13/terraform_0.11.13_linux_amd64.zip
unzip terraform_0.11.13_linux_amd64.zip
sudo mv terraform /usr/local/bin/
terraform --version

What Can I Run In a Profile?

You can add any commands supported on the host/container/pod running the Delegate. Linux shell commands are most common. If kubectl, Helm, or Docker is running on the host/container/pod where you install the Delegate, then you can use their commands.

The base image for the Delegate is Ubuntu 16.04, and so any default Ubuntu packages may be used in the Delegate Profile script.

All Delegates include cURL and unzip as part of their installation package, and so you may use cURL and unzip in your Delegate Profile scripts without installing them. The following script will work without having to install any packages:

usr/bin/apt-get install -y python
curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
unzip awscli-bundle.zip
./awscli-bundle/install -b ~/bin/aws

When is the Profile Executed?

Delegate Profiles are applied under the following conditions:

  • New Delegate - If you add a Delegate Profile when you create the Delegate, the profile commands are executed after the Delegate is started.
  • Running Delegate - If you apply a Delegate Profile to a running Delegate, either by applying it as a new profile or switching the Delegate’s current profile, the profile commands are executed immediately.
  • Edited Profile - If you edit a Delegate Profile, the new commands in the profile are applied to all Delegates using the profile.

Create a Delegate Profile

To create a Delegate Profile, do the following:

  1. In Harness, click Setup.
  2. Click Harness Delegates.
  3. Click Manage Delegate Profiles, and then click Add Delegate Profile.
    The Manage Delegate Profile dialog appears.
  4. In Name, enter a name for the profile.
  5. In Startup Script, enter the script you want to run when the profile is applied, such as when the Delegate is started. Here is an example of a profile that installs and runs Helm:
  6. Click SUBMIT. The profile is created. Now you can apply the profile to new or existing Delegates.

Applying a Profile

You can apply a profile in the following ways:

  • Kubernetes and ECS Task Delegate - For a Harness Kubernetes or ECS Task Delegate, you can apply a profile when you download the Kubernetes YAML file or ECS Task Spec for the Delegate, or after the Delegate is installed and running.
  • Shell Script and Docker Image Delegate - For the Harness Shell Script and Docker Image delegates, you download, install, and run the Delegates first, and then apply the profile using the Harness Manager.
Applying a Profile Example

To apply a profile to a new Kubernetes Delegate, do the following:

  1. In Harness Manager, click Setup.
  2. Click Harness Delegates.
  3. Click Download Delegate, and then click Kubernetes YAML.
    The Delegate dialog appears.
  4. In Delegate Name, enter a name for the new Kubernetes Delegate. In this example, we will use the name profiles-delegate.
  5. In Delegate Profile, select the profile for the Delegate. In this example, we will select the profile named Helm-Install.
  6. Click SUBMIT. Once the Kubernetes Delegate is install and running, the profile is listed in the Delegate information, next to Profile:

For the ECS Task Delegate, you can apply the Delegate Profile when you select ECS Task Spec in the Download Delegate menu.

Apply Profile to a Running Delegate

You can apply a profile to a running Delegate. You can apply a profile for the first time, or switch from the profile currently applied to a new profile.

To apply a profile to an existing Delegate, do the following:

  1. In Harness, click Setup.
  2. Click Harness Delegates.
  3. Locate the Delegate to which you want to apply the profile.
  4. Next to Profile, click Select Profile, and then click the profile you want applied to the Delegate.
  5. In the confirmation dialog, click Confirm.
Notes
  • It might take a few minutes to apply the new profile.
  • When switching profiles, any binaries installed as part of the earlier profile are not removed automatically. If you need to remove them, then restart the Kubernetes pod hosting the Kubernetes Delegate or manually clean up the VM hosting the Shell or Docker delegate.
  • To remove a profile from a Delegate, click Select Profile, and then click None.

Managing Profiles

When you update a Delegate Profile, the changes are applied to the Delegates using the profile. You can also delete a profile and it will be removed from the Delegates using it.

When editing or deleting profiles, any binaries installed as part of the earlier profile are not removed automatically. If you need to remove them, then restart the Kubernetes pod hosting the Kubernetes Delegate or manually clean up the VM hosting the Shell or Docker Delegate.

To update a profile, do the following:

  1. In Harness Manager, click Setup.
  2. Click Harness Delegates.
  3. Click Manage Delegate Profiles, and then click the profile you want to update.
    To delete a profile, simply click the X next to the profile, and then confirm.
  4. In the Manage Delegate Profile dialog, edit the Name, Description, or Startup Script for the profile, and then click SUBMIT. The profile is updated with all delegates using it.

Profile Logs

You can view the execution log of the Profile script for each Delegate. For example, the following Delegate has a Profile attached that simply prints out its environment variables using printenv:

The date next to the Profile name, printenv, is a timestamped link to the script execution log. Click the link to see the log:

Using Secrets in a Profile

Harness Secrets Management feature can be used to provide credentials and other secret information inside the Delegate Profile commands.

For example, if you wanted to add a Helm repo that requires login credentials to every Kubernetes pod running a Harness Kubernetes Delegate, you can create encrypted text in Harness Secrets Management for those credentials, and then use variable names for those credentials in the Delegate Profile.

Let’s walk through this example:

  1. In Harness, hover over Continuous Security, and then click Secrets Management.
    The Secrets Management page appears.
  2. Under Execution Credentials, click Encrypted Text. The Encrypted Text page appears.
  3. Click Add Encrypted Text. The Add Encrypted Text dialog appears.
  4. In Name, enter repoUsername. This name will be used later in the Delegate Profile script to reference this secret.
  5. In Usage Scope, click the X next to both All Applications rows, as this secret is scoped to Account-level Delegates.
  6. In Value, enter any username.
  7. Delete any Usage Scope settings. The ${secrets.getValue()} variable demonstrated later in this section can be used in Delegate Profiles only if the secret it is referencing is Account-level, with no Applications in its Usage Scope. For more information, see Secrets Management.

    The dialog will look like this:
  8. Click SUBMIT.
  9. Add a second encrypted text with the name repoPassword, using any password. Be sure to delete the Usage Scope settings, also. The dialog will look like this:
  10. Click SUBMIT. Now you can create a Delegate Profile and use these secrets.
  11. Click Setup.
  12. Click Harness Delegates.
  13. Click Manage Delegate Profiles, and then Add Delegate Profile.
    The Manage Delegate Profile dialog appears.
  14. In Name, enter Helm Repo.
  15. In Startup Script, enter your Helm commands using the secrets you created:

    helm init --client-only

    helm repo add --username${secrets.getValue(“repoUsername”)}--password${secrets.getValue(“repoPassword”)}nginx https://charts.bitnami.com/bitnami

    helm repo update

    The secrets are referenced as variables using ${secrets.getValue()} and the names you gave them, repoUsername and repoPassword:

    ${secrets.getValue(“repoUsername”)}
    ${secrets.getValue(“repoPassword”)}
    The ${secrets.getValue()} variable demonstrated in this section can be used in Delegate Profiles only if the secret it is referencing is Account-level, with no Applications in its Usage Scope. For more information, see Secrets Management.
    The Manage Delegate Profile dialog will look like this:
  16. Click SUBMIT.

Now when you add this profile to a Kubernetes Delegate, it will add the Helm repo using the credentials you added as Encrypted Text in Harness Secrets Management.

Delegate Tags

When Harness makes a connection via its Delegates, it will select the best Delegate according to its history or round robin between delegates. To ensure a specific Delegate is used by a Harness entity, you can scope the delegate as explained in Delegate Scope, or you can add tags to delegates and then reference the tags in commands and configurations.

For example, in a Delegate listing in Harness Delegates, click Edit next to Tags.

In the Edit Tags dialog, type in the tag name, such as Local, and press Enter. Click SUBMIT. The tag is added.

Elsewhere, such as in a Shell Script command in a Workflow, you can use the tag to ensure that this Delegate is used when executing the command.

The most common use of a Delegate Tag is in a Cloud Provider. For example, you can install a Delegate in an AWS VPC and tag in with a name such as ecs-delegate.

When you set up an AWS Cloud Provider, you can select the Delegate installed in your AWS VPC using its tag.

Now the AWS Cloud Provider will use the Delegate's credentials to connect with AWS.

Troubleshooting

This section contains troubleshooting tips for installing and running the Delegate.

WARNING: ulimit -n is too low (1024)

In Linux, you can change the maximum amount of open files allowed. You modify this number using the ulimit command. It grants you the ability to control the resources available for the shell or process started by it.

The Harness Shell Script Delegate requires a minimum of 10000. By default, most Linux virtual machines will have 1024.

To increase the ulimit, do the following:

  1. Open an SSH session into your Linux virtual machine.
  2. Open the limits configuration file as a root user:

    $ sudo nano /etc/security/limits.conf
  3. Add the following settings:

    * soft nofile 10000
    * hard nofile 10000
    root soft nofile 10000
    root hard nofile 10000

    You can also set the limit for a user named fred like this:

    fred soft nofile 10000
    fred hard nofile 10000
  4. Save the limits configuration file (Ctrl+x).
  5. Log out and back into the SSH session.
  6. View the ulimit:

    $ ulimit -n
    10000
  7. You may now navigate to the Shell Script Delegate folder and run the Delegate without encountering the ulimit error.

If you are simply testing a Delegate on your local Mac, use the following commands to display and raise the ulimit:

$ launchctl limit maxfiles

$ sudo launchctl limit maxfiles 65536 200000

Google Cloud Platform: Cluster has unschedulable pods

If you do not have enough space available in your Kubernetes cluster, you might receive the following error:

Cause

Depending on the size of your cluster, without Autoscaling enabled or enough space, your cluster cannot run the delegate.

Solution

Add more space (see Delegate Requirements above), or turn on Autoscaling, wait for the cluster to restart, reconnect to the cluster, and then rerun the command:

$ kubectl apply -f harness-delegate.yaml

For more information, see Autoscaling Deployments from Google.

Deleting a Kubernetes Delegate

In the case where you have to delete a Harness Delegate from your Kubernetes cluster, you can delete the StatefulSet for the Delegate. Once created, the StatefulSet ensures that the desired number of pods are running and available at all times. Deleting the pod without deleting the StatefulSet will result in the pod being recreated.

For example, if you have the Delegate pod name mydelegate-vutpmk-0, you can delete the StatefulSet with the following command:

$ kubectl delete statefulset -n harness-delegate mydelegate-vutpmk

Note that the -0 suffix in the pod name is removed for the StatefulSet name.

Need to Use Long Polling for Delegate Connection to Harness Manager

By default, the Harness Delegate connects to the Harness Manager over a TLS-backed WebSocket connection, sometimes called a Secure WebSocket connection, using the wss:// scheme ( RFC 6455). Some network intermediaries, such as transparent proxy servers and firewalls that are unaware of WebSocket, might drop the WebSocket connection. To avoid this uncommon error, you can instruct the Delegate to use long polling.

To set up the Delegate to use long polling, you use the Delegate YAML file.

For a Kubernetes Delegate, you can set the POLL_FOR_TASKS setting to true in the harness-delegate.yaml file:

...
env:
...
- name: POLL_FOR_TASKS
value: "true"
...

For the Shell Script Delegate, edit the pollForTasks setting to true in the config-delegate.yml file:

pollForTasks: true

For the Docker Delegate, edit the POLL_FOR_TASKS setting to true in the config-delegate.yml file:

-e POLL_FOR_TASKS=true \

For the ECS Delegate, edit the POLL_FOR_TASKS setting in the ecs-task-spec.json file:

{
"name": "POLL_FOR_TASKS",
"value": "true"
},


How did we do?