TestOps logo
Try TestOps

Install Allure TestOps via Kubernetes

This article describes installation of Allure TestOps version 4.x. For the newer version 5.x, click here.

This section describes how to install and run Allure TestOps as a Kubernetes cluster.

Because of its scalability, a Kubernetes cluster is the recommended way to run Allure TestOps in a production environment.

All the instructions in this guide assume that you are installing Allure TestOps into the default namespace of the Kubernetes cluster. To install it to a different namespace, add the --namespace option to the commands. For more details, see the Namespaces article on the Kubernetes website.

Preparation steps

  1. Install kubectl.

    See the installation guide on the Kubernetes website.

  2. Install Helm.

    See the installation guide on the Helm website.

  3. Deploy external storage servers (optional):

    Installation without using external storage is also possible. However, this option is intended for evaluation purposes only and is not officially supported. Maintaining and upgrading such a configuration can involve considerable downtimes or data loss.

  4. Get a license for Allure TestOps.

    To receive the license key, fill out the form for a trial version or contact us at [email protected] for a commercial license.

    When you receive the license key, you will also get a username and a password for accessing Qameta's Docker repository.

  5. Get details for configuring authentication.

    The required details depend on which approach to user authentication you choose. There are two possible approaches.

    • Standard email-based authentication, implemented by Allure TestOps itself.

      This requires a working SMTP account, e.g., a Gmail account. A new user will be able to register by entering their email address, to which Allure TestOps will send a confirmation email.

    • Authentication via an external identity provider.

      The details required for this may vary depending on what type of identity provider you use. Usually, you will need to specify an external URL and a secret token generated by the identity provider.

    See Configuration → Authentication for more details.

Creating configuration file

  1. Download the values.yaml file.

  2. Open the values.yaml file in a text editor.

    The file defines parameters that will affect behavior of your Allure TestOps instance. For the most typical setup, just do the following:

Choose TestOps release

In the version parameter, specify the version of Allure TestOps you want to use.

Check out the Release notes section for the list of available versions. In general, it is recommended to use the latest release.

Set TestOps URL

The URL of the installation is determined by three parameters:

  • host — the hostname that the users will use to access Allure TestOps.
  • gateway.service.port — the port that the users will use to access Allure TestOps.
  • network.tls.enabled — if true, the Kubernetes Ingress controller will use HTTPS protocol instead of HTTP.

In the example below, the parameters are set so that the Allure TestOps instance would be available at “http://testops.example.com/” (using port 80, which is the default port for HTTP).

host: testops.example.com
gateway:
  service:
    port: 80
# ...
network:
  tls:
    enabled: false
    # ...
  # ...
# ...

See Network configuration for more details.

Configure load balancing

There are multiple ways to manage traffic in and out from a Kubernetes cluster. Selecting the best one depends on your specific needs. However, Allure TestOps comes with two options for common use cases.

  • To use an Ingress service, set the network.ingress.enabled parameter to true.
  • To use an Istio service, set the network.istio.enabled parameter to true.

Set admin credentials

To be able to log into Allure TestOps for the first time, you need have an administrator account. Unlike all other accounts that are managed via the Members interface, the administrator account is managed via the configuration parameters directly.

In the username parameter, specify a login you want to use for the administrator account, e.g., “admin”.

In the password parameter, specify a password. Alternatively, you can leave this parameter empty, in which case a new password will be generated for the administrator account each time the allure-testops-uaa deployment is restarted. You will be able to find the generated password in the service logs.

See Configuration → Authentication for more details.

Configure authentication

A necessary step when deploying Allure TestOps is to configure how users will be registered and logged in. See Configuration → Authentication for more details.

Below are some configuration examples for various identity providers.

Authentication is performed by Allure TestOps. It's essential to have SMTP configured.

# this is just an example which won't work if applied without any changes.
allure:
  auth:
    primary: system
smtp:
  enabled: true
  host: smtp.gmail.com
  port: 465
  authEnabled: true
  from: [email protected]
  username: serice-account-for-SMTP
  password: SMPTPasswordOrAppPasswordOrAnyOtherSecretRequiredBySMTP
  startTLSEnabled: true
  startTLSRequired: true
  sslEnabled: true
  sslTrust: smtp.gmail.com

allure:
  auth:
    primary: ldap
    ldap:
      enabled: false
      auth:
        user: user
        pass: pass
      referral: follow
      url: ldap://ldap.example.com:389
      usernamesToLowercase: true
      passwordAttribute: userPassword
      user:
        searchBase: dc=example,dc=com
        searchFilter: (&((objectClass=Person))(uid={0}))
      syncRoles: false
      uidAttribute: uid
      group:
        searchBase: ou=qa,ou=Security Groups,dc=example,dc=com
        searchFilter: (&(objectClass=Person)(uid={1}))
        roleAttribute: cn
      userGroupName: allure_users
      adminGroupName: allure_admins

allure:
  auth:
    primary: saml2
    saml:
      enabled: false
      provider: crowd
      ACSLocation: https://<your-domain>/api/login/saml2/sso/crowd
      entityId: https://<testops>/api/login/saml2/service-provider-metadata/crowd
      identityProviderMetadataUri: https:///path/to/metadata.xml
      syncRoles: false
      firstNameAttribute: firstNameAttribute
      lastNameAttribute: lastNameAttribute
      emailAttribute: emailAttribute
      groups:
        groupRoleAttribute: groupRoleAttribute
        roleUserGroups: roleUserGroups
        roleAdminGroups: roleAdminGroups

Configure storage services

Specify the details for connecting to the storage services required for Allure TestOps.

  • Connection to the Redis storage server

    • redis.host — server hostname.
    • redis.port — server port.
    • redis.auth.password — password for connecting to the storage.

  • Connection to the PostgreSQL databases

    • postgresql.enabled — if true, Kubernetes will create a new database inside the cluster instead of using the connection parameters. Not recommended for production environment.

    • The authentication database

      • postgresql.external.uaaHost — database server hostname.
      • postgresql.external.uaaPort — database server port.
      • postgresql.external.uaaDbName — database name.
      • postgresql.external.uaaUsername — username for connecting to the database.
      • postgresql.external.uaaPassword — password for connecting to the database.

    • The application database

      • postgresql.external.reportHost — database server hostname.
      • postgresql.external.reportPort — database server port.
      • postgresql.external.reportDbName — database name.
      • postgresql.external.reportUsername — username for connecting to the database.
      • postgresql.external.reportPassword — password for connecting to the database.

  • Connection to the RabbitMQ server

    • rabbitmq.enabled — if true, Kubernetes will create a new RabbitMQ server inside the cluster instead of using the connection parameters. Not recommended for production environment.
    • rabbitmq.external.hosts — comma-separated list of server locations, each one in the AMQP format.
    • rabbitmq.auth.username — username for connecting to the message queue.
    • rabbitmq.auth.password — password for connecting to the message queue.

  • Connection to the S3-compatible storage server

    • If you are using an external S3 server:

      • minio.enabled — false.
      • fs.s3.external — true.
      • fs.s3.endpoint — server URL.
      • fs.s3.bucket — S3 bucket name.
      • fs.s3.region — S3 region name.
      • fs.s3.accessKey — access key for connecting to the bucket.
      • fs.s3.secretKey — secret key for connecting to the bucket.

    • If you are using an S3 server inside the cluster (not recommended for production environment):

      • minio.enabled — true.
      • fs.s3.external — false.

Deploying Allure TestOps

Installing the chart

Once you have prepared the values.yaml file, you can install the Helm Chart and run Allure TestOps.

  1. Open a terminal application.

  2. Connect Kubernetes to the Qameta's Helm repository.

    helm repo add qameta https://dl.qameta.io/artifactory/helm

  3. Refresh the repository data.

    helm repo update

  4. Navigate to the directory containing the values.yaml file, for example:

    cd ~/allure-testops

Deploying the application

Examples do not contain the commands for the creation of a separate name space for Allure TestOps, please consider creating dedicated name space for Allure TestOps and use the reference to the created name space in all commands.

  1. Deploy Allure TestOps with the Helm Chart and configured values.yaml file.

    helm install allure-testops qameta/allure-testops --values values.yaml --set readinessProbe.enabled=false --set livenessProbe.enabled=false

    At this point, you will need to wait for two time-consuming operation to finish:

    1. Before any services can start, Kubernetes needs to download the necessary images from the Qameta Software's images registry.
    2. During the startup, the Allure UAA and Allure Report services will need to initialize their databases.

    The --set overrides in the command above disable the readiness and liveness probes for the services, which prevents Kubernetes from killing them due to timeouts. This measure will also be needed whenever you upgrade Allure TestOps.

  2. Wait for the three deployments (allure-gateway, allure-report, allure-uaa) to become ready.

    Use kubectl get all to view the status of the deployments and pods. When each pod becomes READY, the initialization of Allure TestOps is completed.

  3. Once the initialization is completed, enable the readiness and liveness probes that were disabled during installation. To do so, upgrade the chart without the --set overrides.

    helm upgrade allure-testops qameta/allure-testops --values values.yaml

Activating license

When you run your Allure TestOps installation for the first time, you need to activate it by entering a license key.

  1. In a web browser, go to the URL that you configured on the Set TestOps URL step. An authentication form should appear.

    If you get an “Unable to connect” or “This site can't be reached” error in the browser, it may indicate that some services are still initializing. Normally, the initialization takes no more than a couple of minutes.

    If the web browser still cannot open the page after five minutes, see the Troubleshooting section.

  2. In the authentication form, enter the login and password that you configured on the Set admin credentials step.

    Click Continue.

  3. In the activation form, enter the license key that you got from Qameta sales team. Make sure to paste the key without any extra spaces or other characters.

    Click Activate license.

Upgrading

These instructions are only applicable to upgrading between minor releases within the 4.x version. If you plan to upgrade to the newer major version, see Migrating from 4.x to 5.x instead.

Before you begin, make sure to read the release notes for the Allure TestOps version you are upgrading to. The release notes may contain crucial information on how to adapt your configuration files or migrate your data to the new version of Allure TestOps. In case you are skipping one or more versions, read the release notes for the skipped versions, too.

Don't forget to add the --namespace option to the commands if you are using a namespace other than default.

  1. Open a terminal application.

  2. Refresh the repository data.

    helm repo update

  3. Navigate to the directory containing the values.yaml file, for example:

    cd ~/allure-testops

  4. Perform the upgrade:

    helm upgrade allure-testops qameta/allure-testops --values values.yaml --set readinessProbe.enabled=false --set livenessProbe.enabled=false

    At this point, you will need to wait for two time-consuming operations to finish:

    1. Before any services can start, Kubernetes needs to download the necessary images from the internet.
    2. During the startup, the Allure UAA and Allure Report services will need to re-initialize their databases.

    The --set overrides in the command above disable the readiness and liveness probes for the services, which prevents Kubernetes from killing them due to timeouts.

  5. Wait for the three deployments (allure-gateway, allure-report, allure-uaa) to become ready.

    Use kubectl get all to view the status of the deployments and pods. When each pod becomes READY, the re-initialization of Allure TestOps is completed.

  6. Once the re-initialization is completed, enable the readiness and liveness probes that were disabled during installation. To do so, upgrade the chart once again, this time without the --set overrides.

    helm upgrade allure-testops qameta/allure-testops --values values.yaml

Uninstalling

To uninstall the Allure TestOps instance:

  1. Open a terminal application.

  2. Remove the Helm Chart and all related data. 

    helm delete allure-testops

    If Allure TestOps is installed in a namespace other than default, add the --namespace option to the command.

    helm delete allure-testops --namespace ...

Troubleshooting

If you run into any issues, please check our FAQ page.

Also, in case of any troubles, do not immediately bring Allure TestOps down and up. We need the log files of each component to understand what has happened.

If you encounter an issue not covered in the FAQ, feel free to create a support ticket using your corporate email address. Please include the following information in the ticket:

  1. Description of the problem you are experiencing.
  2. Versions of Allure TestOps and all extra components you are having problems with (allurectl, integration plugins, etc.).
  3. Logs from your system as attachments to the ticket (see the details below). Please only send us the logs described below and only as an attachment.

To get proper debug information you need to perform the following set of the commands:

Get the list of all the installed components

kubectl get all

Save logs for each Allure TestOps component

kubectl logs -l app=allure-testops-uaa > uaa-log.txt
kubectl logs -l app=allure-testops-report > report-log.txt
kubectl logs -l app=allure-testops-gateway > gateway-log.txt

Continuous logging

kubectl logs -f -l app=allure-testops-uaa
kubectl logs -f -l app=allure-testops-report
kubectl logs -f -l app=allure-testops-gateway
© Qameta Software Inc. All rights reserved.