Infrastructure Testing
This section describe how to test each individual service that compose the Keyless Stack
Testing the correct deployment of Keyless service can be done with the following methods.
To test the correct configuration of Circuit Storage it is possible to use the following commands to upload a file from your local environment to the storage.
If Circuit Storage is exposed outside the cluster ( meaning it has been deployed with
publicRoute: true ) you can issue the following command to test the service$ curl --location --request POST '<host>.<domain>:<port which the ingress controller is listening on>/api/v1/circuits/qqF0FC59D87AA45dC15DA1F8A3377A17E423E1F0833343A5865D5E365133090A/qqqB155F07FA55A74FDB3C244B600D5E727EC0982392B89EEDF72DB37A346235/ad000008374B155F07FA55A7000000106F54E35F5FC8C87BF8E4691E9AA98CB8/a4aqa107D779ABDEA0CC5DEF5623F1BB2691D49AFD0A7DDBB6FB0FF3CF0B00101D75AE93C21C3' --form 'pipelineId="pipeline_1"' --form '[email protected]"/home/$USER/<a test file>.txt"'
If Circuit Storage is not exposed with an Ingress object or it is not possible to reach it directly from outside the cluster you can issue a port-forward command so that the Circuit Storage service is exposed on localhost:
$ kubectl port-forward service/circuit-storage-keylessd -n <namespace> 8080:8080
Then it is possible to issue the following command from your local machine to upload a test file
$ curl --location --request POST 'localhost:8080/api/v1/circuits/qqF0FC59D87AA45dC15DA1F8A3377A17E423E1F0833343A5865D5E365133090A/qqqB155F07FA55A74FDB3C244B600D5E727EC0982392B89EEDF72DB37A346235/ad000008374B155F07FA55A7000000106F54E35F5FC8C87BF8E4691E9AA98CB8/a4aqa107D779ABDEA0CC5DEF5623F1BB2691D49AFD0A7DDBB6FB0FF3CF0B00101D75AE93C21C3' --form 'pipelineId="pipeline_1"' --form '[email protected]"/home/$USER/<a test file>.txt"'
It is possible to test Keyless Node, running a dedicated docker testing container as shown below:
docker run -it -e KL_API_KEY="<your_sdk_key>" -e KL_HOSTNAME_PORT="<fqdn_of_node>:<port>" quay.io/keyless_technologies/kl-node-test:v2.2.3_int
As the docker is hosted on our quay.io registry make sure to be authenticated to it before running the command.
To test the correct configuration of Operations API it is possible to use the following commands to upload a file from your local environment to the storage.
If Operations API is exposed outside the cluster ( meaning it has been deployed with
publicRoute: true ) you can issue the following command to test the service:curl -H "X-Api-Key:<you-sdk-key>" -vv http://<host>.<domain>:<port which the ingress controller is listening on>/v2/operations/<operation-id>
If Operations API is not exposed with an Ingress object or it is not possible to reach it directly from outside the cluster you can issue a port-forward command so that the Circuit Storage service is exposed on localhost:
kubectl port-forward service/operations-api-keylessd -n <namespace> 8080:8080
Then it is possible to issue the following command to read an operation-id, given that it is available in the database:
curl -H "X-Api-Key:<you-sdk-key>" -vv http://localhost:8080/v2/operations/<operation-id>
Starting from release 0.1.3 it is possible to test Keyless deployment automatically, using helm testing feature as show below
After deploying the Keyless service stack successfully ( please refer to this page to know how to do so) it is sufficient to invoke the following command
# with 'keylessd' as the release name
helm test keylessd --logs
The above command will trigger individual test pods, one per each service.
It is also possible to adjust test configurations to fit customer's needs, in the
test section of each service in values.yaml, as shown below:keylessd:
circuit-storage:
...
test:
image: postman/newman
resources: {}
operations-api:
...
test:
image: postman/newman
resources: {}
node-persistence:
...
test:
image: postman/newman
resources: {}
node:
...
# The following variables are used to test the deployment
# running `helm test <release-name>`
test:
# -- Name of the docker containing the test tool
image: quay.io/keyless_technologies/kl-node-test:v2.2.3_int
# -- Hostname endpoint of the Node (FQDN)
hostname: ""
# -- Test suit is shipped with 2 certificates
# /ca/rootCA.crt is a test certifificate for local development
# keylessCA.crt is used for client testing purposes, please use this one if in doubt
cert: "/ca/rootCA.crt"
# -- Api key available in the database
apiKey: ""
# -- Port where the service is expected to be exposed
# If test is executed with hostname = fqdn it is the port
# the cluster exposes as part of the external endpoint
# probably 443
port: ""
resources: {}
Circuit Storage, Operations API and Node Persistence services have a similar setup:
Tests for these services need a container with Postman so the default one from Docker Hub is set as default. It is still possible to change the image ( for example if you have an internal Postman image or if Docker Hub registy cannot be exposed internally )
In any case tests are executed from within the Kubernetes Cluster.
Node tests are instead conducted from a proprietary container image. This test simulates a client connecting to the node from outside the cluster.
hostname: It is possible to specify the FQDN of the node ( i.e. the DNS record the node will be exposed outside the cluster, given that the endpoint is reachable)
cert: make sure the value is set to
keylessCA.crt as this certificate is generated and trusted by the internal CA of Keyless. apiKey: this is the same API Key we release to customers.
port: if the service is exposed externally the traffic flows from the internet towards the Ingress Controller which usually exposes his services with an https endpoint, so in most cases this port is
443.For any service it is possible to limit the resources used by the test pod specifying them as shown below:
resources:
## -- Limits
limits:
cpu: 1000m
memory: 1024Mi
## -- Requests
requests:
cpu: 800m
memory: 1024Mi
Last modified 10mo ago