Special Requirements: To perform the evaluation of this artefact the user needs to have access to Google Cloud Platform Compute Engine resources.
The repository presents 4 folders, of which 2 needed for the deployment:
- opentofu: with the terraform scripts for the virtual machines deployment;
- ansible: with the setup and configuration of the VMs, the deployment of Kubernetes, the VPN creation and finally the tAPP-enabled OpenWhisk deployment.
The other 2 folders are:
- bench: with the functions used for the evaluation, a locustfile for the testing and a jupyter notebook to analyse the results;
- scripts: with utility scripts to setup openwhisk and run the benchmarks. These scripts are used in the setup.sh script.
There are 2 scripts in the root of the repository:
- setup.sh: a script that runs all the necessary steps to deploy the VMs, deploy and configure the Kubernetes cluster, deploy and configure OpenWhisk, deploy the function and run the benchmarks (using tAPP);
- stop.sh: a script to tear down the VMs.
By default the "setup" script will use tAPP. To run the benchmark without tAPP, use the "create_vanilla_actions.sh" script followed by the "run_locust_vanilla_functions.sh" script from the "scripts" folder.
The required dependencies to execute the commands are:
- Google Cloud Platform account with a project and a service account with the necessary permissions to create Compute Engine instances and a credentials.json file;
- Docker to use the provided container equipped with an Ubuntu environment with OpenTofu, Ansible and wsk pre-installed. The system running Docker should be an x86-64 architecture. The software is not intended or tested on ARM (e.g., the latest Apple hardware) or other architectures.
A video showing a small demo is available at: https://vimeo.com/915098870
Run the Docker container with the following command:
docker run -it scp-artifact bashThe container will start and you will be in the
Change directory to opentofu:
cd opentofuHere the provider.tf script will deploy 6 machines on Google Cloud Platform, 4 in the europe-west1-b zone, the other 2 in the us-central1-a zone.
First, create a file called terraform.tfvars with the same content as the file tfvars.example:
cp tfvars.example terraform.tfvarsThe tfvars required are:
- project: the Google Cloud Platform project ID;
- gc_user: the GCP username owner of the project;
- allowed_ip: the allowed IP that will be able to connect to the cluster (you can leave 0.0.0.0/0 to expose it completely);
You can edit the file with nano or vim:
nano terraform.tfvarsA "credentials.json" file is also needed to be present.
It can be obtained following this guide. After creating a service account with Compute Engine privileges and requesting the credentials in json format.
You can copy the contents of the json file and in the opentofu folder run:
nano credentials.jsonThen paste the content and save the file.
If missing, create a ssh key pair named ow-gcp-key:
ssh-keygen -t rsa -b 4096 -C "ow-gcp-key" -f ow-gcp-keyFinally, initialize the providers:
tofu initNow that the VMs can be created on GCP, return to the root (/app) directory:
cd /appAnd run the setup script:
./setup.shThe creation of the VMs will take a few minutes to complete.
Afterward, the script will run the ansible playbook to configure the machines and install OpenWhisk. The ansible tasks can take around 15 minutes to complete. Once finished, the script will wait for an additional 5 minutes to ensure that the OpenWhisk installation is completed.
When the ansible playbook is done, the script will
install and configure the wsk CLI tool to interact with OpenWhisk
and create two functions: refresh and first.
The refresh function is a sample function that can be used to refresh the OpenWhisk tAPP configuration, the first function is used for the benchmark.
Finally, the script will run the benchmark using the locust tool to test the OpenWhisk deployment.
The tool will generate a request_statistic.csv file with the results of the benchmark, inside the bench folder.
During the setup, a task will configure OpenWhisk with the following tAPP script:
- data:
- controller: "eu-controller"
workers:
- wrk: "eu-worker"
topology_tolerance: "all"
followup: defaultTo change and try different tAPP configurations, you can
configure different policies in the configLB.yml file located in the OpenWhisk controller persistent volume claims.
You can edit the configLB.yml from the OpenWhisk controllers persistent volume claims from the Kubernetes control-plane VM. To connect to it:
./connect_master.shEach OpenWhisk deployment will have a different name for the volume claim, but it will always be in the /var/nfs/kubedata folder starting with openwhisk-owdev-controller-.
sudo nano /var/nfs/kubedata/openwhisk-owdev-controller-<hash>/configLB.ymlOnce the configLB.yml file is updated exit from the ssh connection with:
exitFrom the container shell, request a refresh of the current configuration by invoking a function with the special -p controller_config_refresh true parameter:
wsk -i action invoke hello -p controller_config_refresh true (it might initially return error but the configuration will be updated).
Now it is possible to invoke functions using the newly updated configuration.
To create tagged functions, the -a flag to add annotations at functions creation must be used. You can add the special tag annotation to tag a function:
wsk action create example hello.js -a tag a_policy_tag -iTo also make use of the modified nginx to choose specific controllers, the policy tag must be passed at invocation time as a parameter:
wsk action invoke tagged_function -p tag a_policy_tag -r -iTo show how to forbid the execution of a function by associating it with a policy
that has no valid workers, we will modify the configLB.yml file to include a new policy tag.
To do so, first, reconnect to the master machine:
./connect_master.shRe-edit the configLB.yml file:
sudo nano /var/nfs/kubedata/openwhisk-owdev-controller-<hash>/configLB.ymlAnd add at the end of the file:
- another:
- controller: "us-controller"
workers:
- set: "non-existent"
topology_tolerance: "none"
followup: failNow return to the container shell:
exitAnd refresh the configuration:
wsk action invoke hello -p controller_config_refresh true -iNow you can create a new function with the another tag:
wsk action create forbidden hello.js -a tag another -iAs before, invoke it:
wsk action invoke forbidden -p tag another -r -iYou should see:
error: Unable to invoke action 'forbidden' ...To delete the cluster and remove all the machines, run the stop.sh script from the root folder (/app):
./stop.sh