Installing a BlazeMeter Agent using a Helm Chart

You want to install a BlazeMeter Agent for Kubernetes on your server/instance behind your firewall. This article shows you how to deploy a BlazeMeter Private Location to your Kubernetes cluster using Helm, the package manager for Kubernetes. This procedure uses a Helm chart which enables you to make advanced configurations to your BlazeMeter Private Location deployment.

Prerequisites

  • A BlazeMeter account

  • A Kubernetes cluster

  • Latest Helm installed

  • Before proceeding with the installation, ensure that your Kubernetes cluster meets the minimum requirements.
    For more information, see Private Location System Requirements.

Obtain Location ID, Agent ID, and Auth Token from BlazeMeter

For this installation, identify your Private Location ID (formerly Harbour_ID), BlazeMeter Agent ID (formerly Ship_ID), and your BlazeMeter API Auth_token, and store them in a text file in a safe location.

harbor ship

Choose one of the following alternatives how to obtain these values:

Get the Location ID, Agent ID and Auth Token through BlazeMeter web UI

For more information, see Where can I find the Harbor ID and Ship ID?

  1. Log in to BlazeMeter with Workspace Admin permissions.

  2. Create a Private Location.

  3. After the Private Location has been created in BlazeMeter, copy the Private Location ID.

  4. Start following the procedure how to Create an Agent.

    1. Give the agent a name.

    2. (Optional) Enter the IP address of the agent.

    3. Click Create.

    4. Do not run any generated command.
      Instead, copy the following values from the Helm chart tab into a text file:

      • HARBOR_ID — your Private Location ID

      • SHIP_ID — your Agent ID

      • AUTH_TOKEN — your API authentication token

Get the Location ID, Agent ID and Auth Token through BlazeMeter API

Use your BlazeMeter API key and secret ready to log in.

  1. Create a Private Location using an API call.

  2. Copy the Private Location ID (Harbour ID) from the response.

  3. Create an Agent using an API call.

  4. Copy the Agent ID (Ship_ID) from the response.

  5. Generate the docker command using an API call.

  6. Copy the Auth_token from the response.

Do not run the generated command.

Download the helm chart

  1. Download the latest Helm chart TAR file from the GitHub repository.

  2. Unpack the chart with the given version using the following command:

    tar -xvf helm-crane-version.tgz

Configure the helm chart values

The values.yaml file contains the default values for your chart.

  1. Open the values.yaml file in a text editor of your choice.

  2. Add your Location ID, Agent ID, and Auth Token, in quotation marks, to the env: section, using the following format:

    env: 
    # if you plan to pass the AUTH_TOKEN through secret in the crane ENV variables set secret to yes and add secret name and key
    secret_authtoken:
        enable: no
        secretName: "your-secretName"
        secretKey: "authtoken"
    authtoken: "your BlazeMeter API Auth token"
    harbour_id: "your Private Location ID"
    ship_id: "your Agent ID"

If you require the AUTH_TOKEN for any crane installation to be secret or secure, you can inherit the env values for the AUTH_TOKEN from the kubernetes secret. You will need to make changes to the secret_authtoken part of the values file. In this case, the authtoken value is ignored. Make sure the cluster/namespace has the secret applied in the following format:

apiVersion: v1
    kind: Secret
    metadata:
    name: <your-secretName>
    namespace: <namespace name>
    type: Opaque
    data:
    authtoken: ZjIzZjU...zZTc3Mzg2Yw==

Additionally, you can configure deployment settings, such as non-default serviceAccount, role and clusterrole name, and restart policy in the following section of the values file:

deployment:
    # This is the name of roles and clusterroles created by the chart.
    role: "roleCrane"
    clusterrole: "cluster-roleCrane"
    serviceAccount:
        # Specifies whether a ServiceAccount should be created.
        create: false
        # The name of the ServiceAccount to use, keep empty to use default ServiceAccount.
        name:
        restartPolicy: "Always"

Configure the default image settings

You can configure the settings for image pull-policy, auto-update, etc. in the image values. If the auto-update is not a desired option, you can it set to false, which will disable the auto-update for crane and its components. Similarly, the pull policy can be changed to Always or IfNotPresent as per your requirements.

If you configure the cluster cache to preserve the images for a longer duration, change the pull policy as well.

image:
        docker_registry: "gcr.io/verdant-bulwark-278"  #default registry for Blazemeter crane (DO NOT CHANGE)
        image: "gcr.io/verdant-bulwark-278/blazemeter/crane"  #default image for Blazemeter crane (DO NOT CHANGE)
        tag: "latest-master"
        auto_update: true
        auto_update_running_containers: false   #Controls auto update of components, default false. Also, either AUTO_UPDATE or AUTO_KUBERNETES_UPDATE must be true for this option to work, depending on the platform Crane is running on.
        pullPolicy: "Always"
Do not change the default BlazeMeter registry, image, or tag values here; use the imageOverride section to override the default settings.

Configure the image override settings

You can override the default image settings by adding the imageOverride section in the values.yaml file by switching the enable value to yes. Replace the docker_registry and image values with the custom registry and image path.

You can replace the path:pathToYourRepo with the custom image path and available version tag in your private repository. For an example, refer to the commented code snippet below.

If auto-update is not a desired option, you can set it to false, which will disable the auto-update for crane and its components.

Similarly, the pull policy can be changed to Always or IfNotPresent as per your requirements.

imageOverride:
    enable: no
    #If imageOverride is enabled, also make sure to change/modify the docker_registry as well as image path below.
    docker_registry: "gcr.io/<custom-registry>"
    image: "gcr.io/<custom-registry>/blazemeter/crane"
    tag: "latest-master"
    auto_update: true
    auto_update_running_containers: false   #Controls auto update of components, default false. 
    # Either AUTO_UPDATE or AUTO_KUBERNETES_UPDATE must be true for this option to work, depending on the platform Crane is running on.
    # Example: {"blazemeter/crane:latest":"gcr.io/verdant-bulwark-278/blazemeter/crane:3.6.47"}
    images: {"taurus-cloud:latest": "<pathToYourRepo>/<image_name:version_number>", "torero:latest": "<pathToYourRepo>/<image_name:version_number>", "blazemeter/service-mock:latest": "pathToYourRepo/<image_name:version_number>", "blazemeter/mock-pc-service:latest": "pathToYourRepo/<image_name:version_number>", "blazemeter/sv-bridge:latest": "pathToYourRepo/<image_name:version_number>", "blazemeter/doduo:latest": "pathToYourRepo/<image_name:version_number>"}
    pullPolicy: "Always"

Optional Settings

Configure the following settings depending on your requirements.

Configure the proxy

If your environment requires a proxy, configure it now:

  1. Set enable in the proxy: section to yes. By default, this is set to no.
  2. Set http_proxy or https_proxy to yes, or both.
  3. Make sure to set these values to yes before you add the proxy path.
    The section should look similar to the following example: 
proxy:
    enable: yes
    http_proxy: yes
    http_path: "http://your_server:your_port" 
    https_proxy: yes
    no_proxy: "kubernetes.default,127.0.0.1,localhost,yourHostname.com"

Configure certificates

To configure your Kubernetes installation to use CA certificates, make changes to the ca_bundle: section of the values.yaml file.

  1. Change the enable option to yes. By default, this is set to no.

  2. Provide the path to your certificate file for both, ca_subpath and aws_subpath, respectively. Copy or move these cert files into the same directory as the Helm chart and define the name of the certs instead of a complete path.

ca_bundle:
    enable: yes
    request_ca_bundle: "certificate.crt"
    aws_ca_bundle: "certificate2.crt"
    volume:
        volume_name: "volume-cm"
        mount_path: "/var/cm"
        readOnly: true

Add gridProxy configuration

If you plan to configure your crane installation to use a Grid Proxy, make changes to the following section of the values.yaml file. Grid Proxy enables you to run Selenium functional tests in BlazeMeter without using a local server. You can run Grid Proxy over the HTTPS protocol using the following methods:

gridProxy:
    enable: yes
    a_environment: 'https://your.environment.net'
    tlsKeyGrid: "certificate.key"      # The private key for the domain used to run the BlazeMeter Grid proxy over HTTPS. Value in string format.
    tlsCertGrid: "certificate.crt"     # The public certificate for the domain used to run the BlazeMeter Grid proxy over HTTPS. Value in string format.
    mount_path: "/etc/ssl/certs/doduo"
    doduoPort:  9070                   # The user-defined port where to run Doduo (BlazeMeter Grid Proxy). By default, Doduo listens on port 8000.
    volume:
        volume_name: "tls-files"
        mount_path: "/etc/ssl/certs/doduo"
        readOnly: true

The values TLS_CERT_GRID and TLS_KEY_GRID reference the file in the pod where the ConfigMap is mounted.

Deploy non_privilege container - non-root deployment

Non-root deployment requires an additional feature to be enabled at account level, please contact support for enabling this feature.

If you plan to deploy the BlazeMeter crane as a non-privileged installation, make changes to the non_privilege_container: part of the values file. By default, this is set to no. Change the enable to yes to automatically run the deployment and consecutive pods as non-root/non-privilege. You can amend the runAsGroup and runAsUser to any value of your choice. You can only have same user/groupId for both crane and child resources.

non_privilege_container:
    enable: no
    runAsGroup: 1337
    runAsUser: 1337

Install Istio-based crane for Service Virtualization deployment within the kubernetes cluster.

If you have installed and configured istio because this Private Location is intended to run virtual services using istio-ingress, make changes to the istio_ingress: section of the values file. For more information, see Installing a BlazeMeter Agent for Kubernetes (Service Virtualization). By default, this is set to no.

istio_ingress:
    enable: no
        credentialName: "wildcard-credential"
        web_expose_subdomain: "yourdomain.local"
        pre_pulling: "true"
        istio_gateway_name: "bzm-gateway"

You can either use istio-ingress or nginx-ingress for mock service deployment. However, you cannot use both at the same time.

Install Nginx Ingress-based crane for Service Virtualization deployment

If you have installed and configured nginx because this Private Location is intended to run virtual services using nginx-ingress, make changes to the nginx_ingress: section of the values file. The default is no. For more information, see Installing a BlazeMeter Agent for Kubernetes (Service Virtualization). 

nginx_ingress:
    enable: no
        credentialName: "wildcard-credential"
        web_expose_subdomain: "yourdomain.local"

You can either use istio-ingress or nginx-ingress for mock service deployment. However, you cannot use both at the same time.

Configure deployment to support child pods to inherit labels from the crane

If users or admins require certain set of labels as part of the deployment of a cluster resource, configure the labels values.These labels can be set for crane as well as the child pods. Add labels in a JSON format as per the example.

labelsCrane:
    enable: no
    syntax: {"label_1": "label_1_value", "label_2": "label_2_value"
labelsExecutors:
    enable: no
    syntax: {"label_1": "label_1_value", "label_2": "label_2_value"}

Note: labelsCrane is for labels set for crane and labelsExecutors is for labels set for child pods.

Configure deployment to support tolerations

Use this configuration to specify the tolerations for crane and child pods. Switch the enable to yes and add tolerations for crane and child resources. Add tolerations in a Json format as shown in the example:

tolerationCrane:
    enable: no
    syntax: [{ "effect": "NoSchedule", "key": "lifecycle", "operator": "Equal", "value": "spot" }]
tolerationExecutors:
    enable: no
    syntax: [{ "effect": "NoSchedule", "key": "lifecycle", "operator": "Equal", "value": "spot" }]
Use the section tolerationCrane to set tolerations for crane. Use the section tolerationExecutors to set tolerations for child pods.

Configure deployment to support node selector for crane and child resources

Use this configuration to specify the node selector for crane and child pods. Switch the enable to yes and add node selectors for crane and child resources. Add node selectors in a Json format as shown in the example:

nodeSelectorCrane:
    enable: no
    syntax:  {"label_1": "label_1_value", "label_2": "label_2_value"}
nodeSelectorExecutor:
    enable: no
    syntax:  {"label_1": "label_1_value", "label_2": "label_2_value"}
Use the section nodeSelectorCrane to set node selectors for crane. Use the section nodeSelectorExecutor to set node selectors for child pods.

Configure resources limits and requests for the crane and child resources

If users or admins require a CPU or memory or EphemeralStorage limits/requests to be applied to crane and its child resources, configure the resourcesCrane or resourcesExecutors values.

The values in resourcesCrane values will be applied to crane deployment, while the values in resourcesExecutors will be applied to the child resources. You can either use one of them or both. Add required values in the below value section in the values.yaml file.

# CPU and Memory limits and requests for resources for crane deployment. You can also specify ephemeral storage requests for the crane.
resourcesCrane:
    requests:
        CPU: 250m
        MEM: 512Mi
        storage: #100
    limits:
        CPU: #1
        MEM: #2Gi
        storage: #1024    # This is in MB
# CPU and Memory limits and requests for resources created by agent. You can also specify ephemeral storage limits for the child resources.
resourcesExecutors:
    requests:
        CPU: 1000m
        MEM: 4096         # This value should be an integer unlike other values that support the k8s standard for declaring resource limits/requests.
        storage: #100     # This is in MB
    limits:
        CPU: #2
        MEM: #8Gi
        storage: #1024

Verify the helm chart

After you have configured the values, run the following command to verify if the values are correctly used in the Helm chart:

helm lint <path-to-chart>
helm template <path-to-chart>

The command prints the template that Helm will use to install this chart.

Check the values and if something is missing, edit the values.yaml file again according to your requirements.

Install the helm chart

To install the BlazeMeter Agent through the Helm chart, use the following command:

helm install crane /path/to/chart --namespace <your-namepace-name>

Verify the helm chart installation

To verify the installation of the BlazeMeter Agent through the Helm chart, run:

helm list -n  <your-namepace-name>

Verify that its lists all the helm charts installed in the given namespace.

Uninstall the helm chart

To uninstall the Helm chart, run:

helm uninstall <release-name> -n <your-namepace-name>