Ezy deploy & integration

[thomas-fossati]

At present, in order for the Veraison verifier to do useful work, three different services and their dependencies (e.g., stores, plugins) needs to be manually instantiated.

In general, this yields poor end-user experience. In particular, it makes creating demos as well as putting together an integration testing environment that can be run as part of the CI more complex than necessary.

As an incremental step to improve the status quo, we need to:

1. automate the startup / shutdown phases of the system as a whole
2. allow easy setup of the endorsement, trust anchor and policy stores
3. allow easy setup of the plugins (both VTS and provisioning)
4. allow easy manipulation of the configuration of each service
5. document any newly introduced interface
6. document the set up of a PSA demonstrator

Achieving these goals will give us the building blocks for quickly assembling demonstrators, and also define the SUT for a subsequent "integration testing" story.

The envisaged solution will be based on the containerisation of each service (e.g., using Docker) in a way compatible with standard orchestration engines (e.g., docker-compose, k3s, k8s).

[SabreenKaur]

Below I will document the implementation choices for the first 3 above steps:

1. We chose to use Docker containers and docker-compose as the mechanism for container orchestration. It utilises 3 containers, one for each service that makes up Veraison. All three services can be started up using the docker compose up command
2. In this step we set up each of the stores within the vts service, during container initialisation when running the docker compose command, using an sqlite backend (the backend makes use of kv-store as the storage method). This implementation choice restricts us to only use sqlite as the backend, however this could change upon further refinement of the deployment model
3. In this step we setup only plugins provided by Veraison and there is currently no ability for a user to provide their own plugin. This too could change upon further refinement of the deployment model

[SabreenKaur]

Implementation choices for configuration (point 4.):

• Python script makes use of jinja to template the configuration for each service and generate a config file for each one
• The templates make use of environment variables passed into the docker build to populate the settings

[SabreenKaur]

Documentation (point 5. and 6.)

• Documentation for the new docker interface can be found here
• Documentation of PSA end to end demo with docker can be found here