Common Delegate Profile Scripts

Updated 2 weeks 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

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.

Pip

# Install pip
apt-get -y install python-pip
# Check pip install
pip -v

Unzip

# 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

# Install Git with auto approval
yes | apt-get install git
# Check git install
git --version

Cloud Foundry CLI

Use the following 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!

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 Delegates 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.

How did we do?