Allure Testops architecture

An Allure Testops instance consists of three services. All three services must be running for Allure Testops to work.

Gateway service provides both the web interface and the API of the instance. When processing a request, it uses the UAA service to authenticate each request. It then sends the request to the Report service and sends its response back to the client. The service uses Redis for storing user sessions. It is recommended to put the service behind a Reverse proxy. See Network configuration for more details.

UUA service manages user authentication. To store user accounts and their roles, the service uses a dedicated PostgreSQL database. Depending on the settings, the service may interact with external identity providers. See Authentication for more details.

Report service implements the main test-related functionality of Allure Testops. The service receives test results from external sources, such as the allurectl and integration plugins, and stores them in a dedicated PostgreSQL database. For storing artifacts, it uses an object storage (e.g., Ceph or MinIO). The server also uses a RabbitMQ for asynchronous jobs and as a temporary storage.

When installed via Docker Compose, DEB or RPM, the services interact with each other via HashiCorp Consul. In a Kubernetes installation, Consul is not included, and the standard Kubernetes API is used instead.

Deployment diagram

The deployed of Allure Testops instance will have 2 stateful components:

• the database
• the artefacts storage

It is highly recommended having these components deployed as stand-alone solutions for easier maintenance and upgrades procedures. Implementing these components as a part of Allure Testops deployment will be easier on the deployment stage, but will require more efforts and more downtime during the operation, and especially during potential upgrades. So, we recommend deploying Allure Testops as it's shown in the diagrams below.

Hardware requirements

The optimal hardware configuration for your Allure Testops instance depends on the production workload. For a small project, we recommend starting with 4 vCPU and 8 GB of RAM and scale up as needed.

In Kubernetes, you can define minimum and maximum memory for each service individually. Here is the recommended configuration:

Storage requirements

Allure Testops uses various storage services, each one for different purpose.

• Databases

  Both the Report and UAA services rely on PostgreSQL as their main data storage. The two storages may share the same database server, but each one must be a separate database (not schema). The minimal supported version is PostgreSQL 14.

  The UAA service normally takes an insignificant amount of disk space, since it only stores Allure Testops user accounts and their permissions.

  For the Report service, the required disk space depends entirely on the amount of test results that you are going to process with your Allure Testops instance. A project with 100 000 tests is likely to take 300 GB in the Report database after 1 year of daily runs.

• Object storage

  The object storage is used by the Report service for storing test artifacts — for example, the screenshots and videos produced during the test runs. The volume of such artifacts depend on the tests that you will be running. For a small project, we recommend to start with at least 50 GB of disk space and then scale up as needed.

  For the object storage, you may use:

  • any S3-compatible storage server, e.g., MinIO,
  • any CSI-compatible storage server (for Kubernetes deployments only).

• Message queue

  A RabbitMQ message queue server is used internally by the Report service.

• Session storage

  A Redis instance is used for storing user authentication sessions by the Gateway service.