GCP locations installation

Run a Control Plane on GCP using Compute Engine, to set up your Private Locations and run load generators in your own GCP network.

GCP Compute Engine is a computing and hosting service that lets you create and run virtual machines on Google infrastructure.

In this example:

• we use Compute Engine to configure a service to run the Gatling Control Plane
• Compute Engine runs our Docker containers on a VM on the GCP infrastructure
• the Control Plane configuration file is loaded from a Secret Manager

This is only an example.

Secret Manager#

In the GCP management console, open the Secret Manager (or search for “Secret Manager” in the search bar). Set the right project and click CREATE SECRET.

Choose a name for the secret, and upload the Control Plane configuration

Configure other options as preferred.

Click CREATE SECRET.

Service account#

We need a service account which will allow a VM to:

• download the Control Plane’s configuration file, stored in a secret
• spawn new load generators on GCP when running a simulation

Role creation#

In the GCP management console, open Roles (or search for “Roles” in the search bar).

Enable the following required permissions:

compute.disks.create
compute.instances.create
compute.instances.delete
compute.instances.list
compute.instances.setMetadata
compute.subnetworks.use
compute.subnetworks.useExternalIp
secretmanager.versions.access

Some permissions may be required based on configuration:

• compute.images.useReadOnly when using custom image
• compute.instanceTemplates.useReadOnly for instance templates

Service account creation#

In the GCP management console, open Service accounts (or search for “Service Accounts” in the search bar). Click CREATE SERVICE ACCOUNT.

Fill details with:

• a name
• an ID
• a description of the control plane service account

Then, choose the previously created role.

Click Done.

VM instance creation#

In the GCP management console, open VM Instances (or search for “VM instances” in the search bar). Click CREATE INSTANCE.

Set the VM instance:

• name
• region
• zone

Choose a machine type.

Click DEPLOY CONTAINER.

Set the image to gatlingcorp/control-plane, and then click ADD A VOLUME MOUNT.

Volume type is Directory, mount path is set to /app/conf/control-plane.conf and host path to /etc/control-plane/control-plane.conf.

The control plane configuration from the secret manager will be downloaded to the host path later.

Configure the Identity and API access for the previously created service account.

The last step is configuring an automation that downloads the control plane configuration on start.

To do so, go to advanced options in the Management section and set the Automation startup script to:

#! /bin/bash

sudo mkdir /etc/control-plane
sudo touch /etc/control-plane/control-plane.conf

toolbox gcloud version
toolbox gcloud secrets versions access latest --secret=<secret-name> | sudo tee /etc/control-plane/control-plane.conf

This script downloads the control plane configuration secret from the secret manager on the disk to a path mounted on the control plane container.

Click *Create

Your Control Plane is up and running!#

After a short time, you should see your Control Plane get the “up” status in Gatling Enterprise Cloud.

You can now configure a simulation to run on one or more of this Control Plane’s locations!

Troubleshooting#

Deployment failed#

It’s important to note that, based on your configuration, certain permissions may be missing, leading to deployment failures.

If you encounter the following error within Gatling Enterprise Cloud:

Control plane 'cp_example' failed to deploy private location 'prl_example' failed to deploy: com.google.api.gax.rpc.PermissionDeniedException: Forbidden

In this scenario, you should establish a connection to the instance where the control plane container is active. Subsequently, you can inspect the container’s log by using the command: docker logs <container-id>.

Then search for missing permissions exception for the Google Cloud SDK, such as:

"errors": [
  {
    "message": "Required 'compute.instanceTemplates.useReadOnly' permission for 'projects/example/global/instanceTemplates/gatling-template'",
    "domain": "global",
    "reason": "forbidden"
  },
  {
    "message": "Required 'compute.images.useReadOnly' permission for 'projects/example/global/images/classic-openjdk-17'",
    "domain": "global",
    "reason": "forbidden"
  },
  {
    "message": "Required 'compute.instances.setServiceAccount' permission for 'projects/example/zones/europe-west3-a/instances/unusedName'",
    "domain": "global",
    "reason": "forbidden"
  }
]

Control plane is down#

Containers take some time to become operational on the VM when deploying containers with konlet. To verify the status of the control plane, you can inspect the instance by running the command: docker ps -a.

If docker ps displays the konlet container as running, it indicates that the control-plane container has not yet been deployed.

If you do not see any output for an extended period, it’s advisable to review the konlet logs using the command: sudo journalctl -u konlet-startup.

Timeout#

Control plane deployed the instances successfully; however, a timeout occurred during the deployment process. This is likely due to issues with the load generator initialization script, such as missing requirements on a custom image or lack of internet access.

You can examine these logs directly within containers by executing the command: sudo journalctl -u google-startup-scripts.service.

If the instance is stopped, it can be maintained in an operational state by setting debug.keep-load-generator-alive to true in the location configuration. However, remember to delete it manually when no longer needed.

Edit this page on GitHub