Common Delegate Profile Scripts

Updated 2 days ago by Michael Cretzman

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

For information on Delegate Profiles, see Delegate Profiles.

This topic provides information on script availability and some common Delegate Profile scripts:

For information on using encrypted text or files in a Delegate Profile script, for usernames, passwords, etc, see Using Secrets in a Profile.

Profile Execution

It might take a couple of minutes for a Delegate Profile to be applied to a Delegate. Ensure that a timestamp appears next to the profile before deploying anything that depends on the profile script.

For example, in the following Delegate, a script using printenv is applied:

Once the script is run, a timestamp appears next to it. You can click the timestamp to view the output:

For extensive information on installing and running the Harness Delegate, see Delegate Installation and Management.

Terraform

# Install TF
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
mv ./terraform /usr/bin/
# Check TF install
terraform --version

Helm 2

Installing Helm and Tiller in the Delegate's cluster:

If you are using remote Helm charts in your Harness Kubernetes Service, you can use the helm init --client-only option, as Tiller is not needed. See Helm charts for more information.
# Add the Helm version that you want to install
HELM_VERSION=v2.14.0
# v2.13.0
# v2.12.0
# v2.11.0

export DESIRED_VERSION=${HELM_VERSION}

echo "Installing Helm $DESIRED_VERSION ..."

curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash

# If Tiller is already installed in the cluster 
helm init --client-only

# If Tiller is not installed in the cluster
# helm init
DESIRED_VERSION is used by a function in the Helm install script.

If Helm is being installed in a cluster outside of the Delegate's cluster ensure that the kubeconfig in the Delegate cluster is pointing to the correct cluster using:

kubectl config current-context cluster_name
If you are using TLS for communication between Helm and Tiller, ensure that you use the --tls parameter with your commands. For more information, see Command Flags in  Helm Deploy Step in the Helm Deployment guide, and see  Using SSL Between Helm and Tiller from Helm, and the section Securing your Helm Installation in that document.

Here is an example of how to add a Helm chart from a private repo using secrets repoUsername and repoPassword from Harness Secrets Management.

# Other installation method
# curl https://raw.githubusercontent.com/helm/helm/master/scripts/get > get_helm.sh
# chmod 700 get_helm.sh
# ./get_helm.sh

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get | bash

helm init --client-only

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

helm repo update
For information on using encrypted text or files in a Delegate Profile script, for usernames, passwords, etc, see Using Secrets in a Profile.

Helm 3

You do not need to add a Delegate Profile for Helm 3. Harness includes Helm 3 support in any Delegate that can connect to the target Kubernetes cluster.

For more information, see Upgrade to Helm 3 Charts in Kubernetes Services and Upgrade Native Helm 2 Deployments to Helm 3.

Pip

Ensure that you run apt-get update before running any apt-get commands.
apt-get update
# Install pip
apt-get -y install python-pip
# Check pip install
pip -v

Unzip

Ensure that you run apt-get update before running any apt-get commands.
apt-get update
# Install Unzip
apt-get install unzip

AWS CLI

# Install AWS CLI
curl -L -O "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip"
unzip awscli-bundle.zip
./awscli-bundle/install -b ~/bin/aws
# Check AWS CLI install
/root/bin/aws --version

AWS Describe Instance

The following Profile describes the EC2 instance based on its private DNS hostname, which is also the name in the Delegate's Hostname field:

aws ec2 describe-instances --filters "Name=network-interface.private-dns-name,Values=ip-10-0-0-205.ec2.internal" --region "us-east-1"

The value for the Values parameter is simply the Hostname of the Delegate.

AWS List All Instances in a Region

The following Profile will list all of the EC2 instances in the region you supply:

aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,State.Name,InstanceType,PrivateIpAddress,PublicIpAddress,Tags[?Key==`Name`].Value[]]' --region "us-east-1" --output json | tr -d '\n[] "' | perl -pe 's/i-/\ni-/g' | tr ',' '\t' | sed -e 's/null/None/g' | grep '^i-' | column -t

Git CLI

Ensure that you run apt-get update before running any apt-get commands.
apt-get update
# Install Git with auto approval
yes | apt-get install git
# Check git install
git --version

Cloud Foundry CLI

The CF CLI installation options are described in Installing the cf CLI from PCF. Below is one example, but the version of the CF CLI you install on the Delegate should always match the PCF features you are using in your Harness PCF deployment.

For example, if you are using buildpacks in your manifest.yml in your Harness Service, the CLI you install on the Delegate should be version 3.6 or later.

Here is an example script to install the Cloud Foundry CLI on a Delegate:

sudo wget -O /etc/yum.repos.d/cloudfoundry-cli.repo https://packages.cloudfoundry.org/fedora/cloudfoundry-cli.repo

sudo yum -y install cf-cli

The -y parameter is needed for a prompt.

When the script has been applied and you click the timestamp for the Delegate the output will be similar to this:

Running transaction
  Installing : cf-cli-6.46.1-1.x86_64                                       1/1 
  Verifying  : cf-cli-6.46.1-1.x86_64                                       1/1 

Installed:
  cf-cli.x86_64 0:6.46.1-1                                                      

Complete!

For information on installing the CLI on different distributions, see Installing the cf CLI from PCF.

Docker Installation

To install Docker on the Delegate, use the following script:

apt-get update
apt-get install -y apt-utils dnsutils docker
Ensure that you run apt-get update before running any apt-get commands.

PowerShell

You can run PowerShell scripts on a Harness Delegate, even though the Delegate must be run on Linux. Linux supports PowerShell using PowerShell core.

For steps on creating your Profile, see Installing PowerShell on Linux from Microsoft.

Whatever scripts you run must be supported by the version of PowerShell you install.

Here is an example for Ubuntu 16.04:

# Download the Microsoft repository GPG keys
wget -q https://packages.microsoft.com/config/ubuntu/16.04/packages-microsoft-prod.deb

# Register the Microsoft repository GPG keys
sudo dpkg -i packages-microsoft-prod.deb

# Update the list of products
sudo apt-get update

# Install PowerShell
sudo apt-get install -y powershell

# Start PowerShell
pwsh

If apt-get is not installed on your Delegate host, you can use snap (snap install powershell --classic). See Install PowerShell Easily via Snap in Ubuntu 18.04.

Stop Shell Script Delegate

To stop a Shell Script Delegate, apply the following Delegate Profile:

./stop.sh

To start the Delegate, you will need to SSH into the Delegate host and run:

./start

Import a Certificate

The Harness Delegate makes outbound connections to the resources you set up in Harness as Artifact Servers, Verification Providers, and so on. Most of these connections are API calls, and some of them require HTTPS/TLS connections and, thus, trusted TLS certificates. The certificates are stored in the JRE keystore on the hosts running the Delegate (or truststore for back-end application certificates), and you can import the certificates manually or using a Harness Delegate Profile.

For information on TLS and the JRE, see Sun Java System Application Server Platform Edition 8.2 Administration Guide and keytool.

The following profile references a Harness encrypted text secret named ex-cert (${secrets.getValue("ex-cert")}) that contains the certificate, copied into the Harness encrypted text secret using pbcopy. The encrypted text secret is redirected into a new file ca.cer, which is then used in the keytool import command to import the certificate.

echo ${secrets.getValue("ex-cert")} | base64 -d > ca.cer

keytool -import -trustcacerts -keystore /opt/harness-delegate/jre/lib/security/cacerts -storepass changeit -alias example.com -file ca.cer -noprompt

# Depending on the different versions of JDK, the CACERT keystore might reside in different locations.

The default keystore password is used in our example, but if you change the default you can replace the password with a Harness encrypted text secret.

If you create or add to Import a Certificate that already exists in the profile, the import operation will fail and stop. Make sure to add an if block code check to prevent this, as follows:

if [$? -eq 0];
then
echo "Alias ca.cer already exists"
else

How did we do?