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.
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.
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
In the GCP management console, open Roles (or search for “Roles” in the search bar).
Enable the following required permissions:
Some permissions may be required based on configuration:
compute.images.useReadOnlywhen using custom image
compute.instanceTemplates.useReadOnlyfor 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.
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:
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
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:
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.
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!
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:
"message": "Required 'compute.instanceTemplates.useReadOnly' permission for 'projects/example/global/instanceTemplates/gatling-template'",
"message": "Required 'compute.images.useReadOnly' permission for 'projects/example/global/images/classic-openjdk-17'",
"message": "Required 'compute.instances.setServiceAccount' permission for 'projects/example/zones/europe-west3-a/instances/unusedName'",
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.
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.