2. Run tests

2.1. How to use the ArmoniK C++ SDK

2.1.1. Build worker and dynamic worker (Linux only)

To utilize ArmoniK with the C++ SDK, you must first build a dynamic worker image. This image is subsequently deployed alongside other ArmoniK components during the deployment phase. The worker runtime offers a suite of business services to ArmoniK clients. It is essential to configure the worker to load a shared library that contains the implementation of the calculation library corresponding to the provided services.

In order to build the dynamic worker image (armonik-sdk-cpp-dynamicworker) and the worker test (libArmoniK.SDK.Worker.Test.so), please run the following script:

./tools/build-deploy-end2end.sh

This script generates the dynamic worker image that is used to deploy ArmoniK with. The script also generates the shared library used by the worker to perform the ArmoniK call on the desired services. The script will also copy this shared library into the right folder so it can be loaded by the ArmoniK worker. It is also possible to use the worker image available in the docker hub ANEO and build the shared library separately.

The dynamic worker searches for the shared library to be loaded in the ArmoniK deployment data directory. Tthe /tools/build-deploy-end2end.shtakes an argument -b  [Dynamic library path] to specify this directory. A default value is defined, it assumes that the current repository has been cloned at the same level as the ArmoniK’s main repository. Hence, we advice you to set the variable manually to the correct directory.

Note: If you are using a cloud deployment of ArmoniK (AWS/GCP), you need to manually copy the shared library to the correct bucket (S3/GCS).

2.1.2. Deploy ArmoniK

ArmoniK must be configured with a partitition dedicated to the C++ worker image. To do so, you should perform the following actions:

  • Fetch ArmoniK’s main repository from github if you have not yet done so:

  git clone https://github.com/aneoconsulting/ArmoniK.git
  cd ArmoniK
  • Add the C++ worker image, either by:

    • Replacing the default partition image with the C++ dynamic worker image. This is done by modifying the default partition parameters.tfvars. For example, using the dynamic worker image provided by the ArmoniK Team:

      default = {
        # number of replicas for each deployment of compute plane
        replicas = 0
        # ArmoniK polling agent
        polling_agent = {...
        }
        # ArmoniK workers
        worker = [
          {
      -     image = "dockerhubaneo/armonik_worker_dll"
      +     image = "dockerhubaneo/armonik-sdk-cpp-dynamicworker"
      +     tag = "0.4.2" 
            limits = {...}
            requests = {...}
          }
        ]
        hpa = {...
        }
      }
      

    or

    • Creating a new partition for the C++ worker: You will need to edit the parameters.tfvars file and add the new partition with the right image name and tag. For example, assuming you built your own worker armonik-sdk-cpp-dynamicworker and gave it the tag 0.0.0-local:

      +cppdynamic = {
      +  # number of replicas for each deployment of compute plane
      +  replicas = 0
      +  # ArmoniK polling agent
      +  polling_agent = {...
      +  }
      +  # ArmoniK workers
      +  worker = [
      +    {
      +      image = "armonik-sdk-cpp-dynamicworker"
      +      tag = "0.0.0-local" 
      +      limits = {...}
      +      requests = {...}
      +    }
      +  ]
      +  hpa = {...
      +  }
      +}
      

      Note: This choice requires specifying the partition name in the task options in order to run correctly. If no partition is given in the task options, ArmoniK will use the worker defined in the default partition which, almost surely wont be compatible with your Cpp worker.

      Note: We support AWS, GCP and a localhost deployments, you should modify the parameters.tfvars accordingly. If you cloned the ArmoniK repository in your $HOME directory, the file will be located in one of these subdirectories:

        $HOME/ArmoniK/infrastructure/
        └── quick-deploy
            ├── aws
            ├── gcp
            ├── localhost
            └── onpremise -> localhost
      
  • Then deploy ArmoniK following the instructions from the dedicated documentation.

2.1.3. Build the client test and submit jobs

Once the worker is built and ArmoniK is deployed, It is possible to submit jobs by using the client test in the repository. In order to do so, build the client test by launching the cmake at the project root with the flags BUILD_CLIENT=ON and BUILD_END2END=ON. After the test build, the environment variable GrpcClient__Endpoint must be set to the ArmoniK control plane address in the test environment. To get the control plane address and port, we can use the following kubectl commands:

export CPIP=$(kubectl get svc control-plane -n armonik -o custom-columns="IP:.spec.clusterIP" --no-headers=true)
export CPPort=$(kubectl get svc control-plane -n armonik -o custom-columns="PORT:.spec.ports[*].port" --no-headers=true)
export GrpcClient__Endpoint=http://$CPIP:$CPPort

The worker lib version WorkerLib__Version must also be specified if the default one (0.1.0-local) is not used. These values can also be specified in the appsettings.json file when used. Then run in your build environment:

cd /app/install/bin
./ArmoniK.SDK.Client.Test

It is also possible to use the test image armonik_sdk_client_test generated by the script /tools/build-deploy-end2end.sh to run tests. This docker image provides an environment with ArmoniK Client and Client Test built to run tests and submit tasks to ArmoniK. For example, if you chose to create a partition cppdynamic for the worker as explained above, you may execute the tests with:

docker run --rm -t --network host -e PartitionId=cppdynamic -e GrpcClient__Endpoint=http://$CPIP:$CPPort -e WorkerLib__Version="$lib_version" armonik_sdk_client_test:"$version"

Note: In this subsection we are assuming that you deployed ArmoniK without tls validation. If this is not your case, the previous commands should be adapted to:

  • Use an https ulr instead

  • The docker run command should include the options to mount a volume with the certificate, authority and key to perform the ssl validation.

  • Provide the client code the necessary configuration for the ssl validation, this can be done via a JSON file or from environment variables.