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 artefacts, 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:
resource | requests | limits |
---|---|---|
cpu | 1 | 1 |
memory | 512Mi | 512Mi |
resource | requests | limits |
---|---|---|
cpu | 1 | 1 |
memory | 1Gi | 1Gi |
resource | requests | limits |
---|---|---|
cpu | 1 | 4 |
memory | 3Gi | 4Gi |
Storage requirements
Databases
Both the Report and UAA services rely on PostgreSQL as 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 15.
UAA service database 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.
For acceptable performance of whole system for the processing of the test results from automated tests, especially if your tests base is big and runs happen several times a day, you need to meet the following requirements:
hardware for the database storage has to be SSDs only, preferably enterprise grade; HDDs will slow down the services and can become a bottleneck.
you need to tweak the configuration of the database for proper working with SSDs as described in our manual.
under no circumstances should the database use the same disks as the artefacts storage, that'll create a competition and finally cripple both the database and the storage
Object storage
The object storage is used by the Report service for storing test artefacts — for example, the screenshots and videos produced during the test runs. The volume of such artefacts 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 acceptable performance of whole system for the processing of the test artefacts from automated tests, you need to meet the following requirements:
any AWS S3-compatible storage server
any CSI-compatible storage server (for Kubernetes deployments only).
hardware for the artefacts storage has to be SSDs only, preferably enterprise grade; HDDs will slow down the services and will become a bottleneck.
under no circumstances should the artefact storage use the same disks as the database, that'll create a competition and finally cripple both the database and the storage
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.
Redis does not require a persistent storage. It uses transient memory.