How do you deploy Allure TestOps in your environment
Please read this section from top to down.
First of all, a little bit of architecture, then we’ll try to understand the HW requirements and finally - how do we install Allure TestOps
Allure uses microservices architecture approach and has following main blocks:
- Gateway is the WEB-UI component of Allure TestOps.
- UAA is the user management component of Allure TestOps.
- Report is the report controller of Allure TestOps processing all the stuff related to the tests.
You can see here , how it all is tied together.
Allure TestOps HW requirements
Apple M1 CPU aren’t supported as these are laptop grade CPUs.
Allure TestOps recommended HW/VM parameters
Recommended HW or virtual environment:
|CPU||RAM||Storage size||Storage type|
|4vCPU||8GB||50 GB and more||SSD|
However, the requirements above aren’t final; production system could require resources adjustment based on the workload profile.
DB storage size requirements
Based on our experience 100 000 of test results daily will result in 300 GB of data in PostgreSQL database over a 1 year period.
Recommendations for Allure TestOps production system deployment
All the examples you will find in the documentation pages describing the deployment options are good for the proof of concept stages, i.e. for the cases when the number of tests results you will sent to the system is not really big, and if your Allure TestOps’ endpoint is exposed to your intranet only. For the deployment in the production we strongly recommend the following.
Users management settings
Before the production deployment of Allure TestOps, it is highly recommended to review the way the users are registered in the system, and use the following configuration parameters of UAA service to manage the system’s behaviour.
For docker-compose and Kubernetes deployment
ALLURE_REGISTRATION_ENABLED: true/false ALLURE_REGISTRATION_AUTOAPPROVE: true/false ALLURE_REGISTRATION_DEFAULT_ROLE: ROLE_AUDITOR
For deployment using packages
allure.registration.enabled=true/false allure.registration.autoapprove=true/false allure.registration.default.role=ROLE_AUDITOR
ALLURE_REGISTRATION_ENABLED / allure.registration.enabled
ALLURE_REGISTRATION_ENABLED allows enabling/disabling the registration of new users via web UI. It is mandatory to set this parameter to
false if your Allure TestOps endpoint is exposed to the internet.
ALLURE_REGISTRATION_AUTOAPPROVE / allure.registration.autoapprove
ALLURE_REGISTRATION_AUTOAPPROVE is used to manage the automatic approval of new users, i.e. the system’s administrator is to review the eligibility of a new user to access Allure TestOps. If there is no explicit approval received from the administrator (there is a checkbox in the u), the registered user won’t be able to access the system.
ALLURE_REGISTRATION_DEFAULT_ROLE / allure.registration.default.role
Configuration parameter ALLURE_REGISTRATION_DEFAULT_ROLE will assign the provided role to all newly registered users. We recommend
ROLE_AUDITOR for this role has the minimal permission set and this role does not consume any license.
Reverse proxy parameters
client_max_body_size - parameter of the reverse proxy should be set to several hundreds of megabytes to allow transferring the test results (which are being sent in batches); this will prevent the loss of test results due to reverse proxy policies. We recommend setting this parameter at least to 256 megabytes.
proxy_read_timeout - defines the time to wait for the response from a server. Sometimes the default value of this parameter could break the test results transfer to the Allure TestOps server. We recommend to set this parameter to the value = 300
DB outside of docker container
In production the database should be pulled from a container and run separately as running in a container severely degrades the performance of the database with big amount of tests.
Postgres database version requirements
Postgres database version no less than 12 requires for all new installations.
Lowest supported version of Postgres database is the 11th, we’ll discontinue its support by the end of 2021.
Postgres database ver. 9 support is discontinued by the 28th of August 2021.
S3 for test results storage
It’s highly recommended to use S3 bucket to store test results artifacts.
Additional settings for report container should be added to use it (refer to specific deployment type).
Number of report containers
For big amount of test results for faster processing it’s recommended to scale up the number of report service instances which will also prevent the loss of the test results.
docker-compose scale report=N
where N is the target number of container with type report
Currently, the following options for Allure TestOps deployment are supported:
Integrations with the infrastructure
|LDAP/AD for access management||in uaa service||Link|
|OpenId/OAuth2 for Kubernetes||in gateway||Link|
|S3 for docker-compose||in report service||Link|
|S3 for Kubernetes||in report service||Link|
|External DB for docker-compose||in uaa and report||Link|
|External DB for Kubernetes||in uaa and report||Link|