Deploying Eggplant DAI in Containers
Before proceeding with the installation of Eggplant DAI in containers, you should ensure engineers in your organisation are Certified Kubernetes Administrators (https://www.cncf.io/training/certification/cka/) or have equivalent experience.
Eggplant DAI can be installed on Kubernetes using Helm. You will need to meet the following requirements:
Requirement | Notes |
---|---|
Kubernetes cluster | Tested version 1.31. |
ingress-nginx | Tested version 1.11.5 (chart version 4.11.5). |
Keda v2 | Optional, for autoscaling engines. Tested version 2.17.2. |
Eggplant DAI license | Speak to support if needed. |
When you've met those requirements, you can install the default Eggplant DAI deployment by creating a Helm values file. In the example below, substitute all the values to work for your own deployment.
global:
# Please omit the enclosing square brackets when you specify
# your licenses below. Including them can cause issues with
# the yaml file formatting.
devLicense: a-real-license-goes-here
execLicense: a-real-license-goes-here
featLicenses: comma-separated-feature-licenses-go-here
ingress:
host: dai.example.com
keycloak:
host: kc-dai.example.com
user: kcadmin
password: kcadminpassword
objectStorage:
minio:
rootUser: eggplant
rootPassword: eggplant
postgresql:
auth:
postgresPassword: postgres
keycloak:
auth:
# note adminUser and adminPassword must match global.keycloak.user and global.keycloak.password
adminUser: kcadmin
adminPassword: kcadminpassword
externalDatabase:
# This must match the value of global.postgresql.auth.postgresPassword
password: postgres
keycloak-user-provisioner:
adminUsers:
daiAdmin:
username: admin-username
password: admin-password
email: admin-email
A few notes:
global.ingress.host
andglobal.keycloak.host
do not have to be the same domain, but they do have to be resolvable. You can do this either by having something like ExternalDNS deployed on your cluster or manually creating the records and pointing them at your cluster.- When running in containers DAI must be used in conjunction with TLS. The TLS can either be terminated within the cluster by adding a certificate to the ingress or on an external loadbalancer. See the TLS configuration section below for details.
- The hostname configured under
global.ingress.host
must be solely for DAI use. Running other applications on the same subdomain is not supported. keycloak-user-provisioner.adminUsers.daiAdmin.password
must be at least 12 characters long. You can add additional admin users by adding extra keys underkeycloak-user-provisioner.adminUsers
.- DAI makes use of configuration snippets within the ingress rules. If you are running a recent version of the ingress-nginx controller, then you must ensure that this is configured to allow-snippet-annotations. This can be achieved by setting
controller.allowSnippetAnnotations
totrue
if installing ingress-nginx with helm.
Full documentation for all values can be found here.
Then deploy it to your Kubernetes cluster:
$ helm upgrade --install \ --namespace dai \ --create-namespace dai \ oci://harbor.dai.eggplant.cloud/charts/dai \ --version 1.22.4 \ --values dai.yaml \ --wait Release "dai" does not exist. Installing it now. NAME: dai LAST DEPLOYED: Fri Feb 17 08:20:17 2023 NAMESPACE: dai STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Thank you for installing dai.
Your release is named dai.
To learn more about the release, try:
$ helm status dai $ helm get all dai
You can access your DAI instance by visiting dai.example.com.
admin username: admin-username admin password: admin-password
The Helm chart installs these dependencies, but it doesn't manage backups of data stored in PostgreSQL or MinIO. You need to arrange backups of these services in a production deployment as part of your disaster recovery plan. There's an example of one approach to backups later in this documentation.
OpenShift
As of version 25.3, you can install DAI into an OpenShift-based Kubernetes cluster by following the instructions on this page. No additional changes to values are required. Before you install DAI, please ensure you have the following:
- The Kubernetes ingress-nginx controller is installed (if the configured
IngressClass
is anything other thannginx
then this will need configuring Ingress Class below). - An OpenShift project is available, with Administrator access to the project.
DAI requires the Kubernetes ingress-nginx controller to manage inbound traffic. This is because the Ingress definitions rely on annotations specific to that controller.
Other controllers — such as OpenShift Routes or the F5 NGINX Ingress Controller — are not compatible and will not function correctly.
If you're running on OpenShift, you must install the community-maintained ingress-nginx controller. This may require elevated, cluster-wide permissions. Please consult your cluster administrator if needed.
For installation instructions and manifests, refer to the official project on GitHub: https://github.com/kubernetes/ingress-nginx
To install DAI first ensure that you are logged into OpenShift and have the correct project selected. The installation is then broadly the same as any other cluster, with the exception of omitting the --create-namespace
flag, as the namespace should already exist as part of the project:
$ oc login https:///<cluster_hostname>:6443 -u <username> $ oc project <project_name> $ helm upgrade --install dai \ oci://harbor.dai.eggplant.cloud/charts/dai \ --version 1.22.4 \ --values dai.yaml \ --wait Release "dai" does not exist. Installing it now. NAME: dai LAST DEPLOYED: Fri Jul 4 12:28:05 2025 NAMESPACE: dai STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Thank you for installing dai.
Your release is named dai.
To learn more about the release, try:
$ helm status dai $ helm get all dai
You can access your DAI instance by visiting dai.example.com.
admin username: admin-username admin password: admin-password
Supported customizations
In the default installation above, all dependencies are deployed to Kubernetes with data stored in persistent volumes for PostgreSQL and MinIO. If you have an existing solution in place for PostgreSQL or AWS S3 compatible object storage you want to use instead, you can customise the Eggplant DAI installation to use these. Further, you may want to pass credentials using Kubernetes secrets rather than in the values file for improved security.
This section of the documentation gives examples showing how to customize your installation. All examples will use secrets for credentials. All the examples given are just snippets that are meant to be added to the default installation values demonstrated above.
Ingress Class
DAI requires the Kubernetes ingress-nginx controller to manage inbound traffic. This is because the Ingress definitions rely on annotations specific to that controller. DAI defaults to using an ingress class called nginx
. If you wish to use a different ingress class then you can override this in the values by setting global.ingress.className
to your preferred value within dai.yaml
.
Object storage configuration
Eggplant DAI depends on an S3 compatible object storage solution for persisting assets such as test screenshots. The Helm chart gives several options for configuring this.
Bundled MinIO (Default)
By default, the Eggplant DAI Helm chart deploys MinIO as a sub-chart with a random root-user and root-password.
You can override these random values by providing an existing secret. First, prepare an existing secret with credentials in:
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: dai-objectstorage
stringData:
root-user: username
root-password: password
$ kubectl -n dai apply -f dai-objectstorage.yaml
Then update your values file to point to the existing secret and run Helm upgrade:
global:
objectStorage:
minio:
existingSecret: dai-objectstorage
minio:
auth:
existingSecret: dai-objectstorage
$ helm upgrade dai oci://harbor.dai.eggplant.cloud/charts/dai --version 1.22.4 -f dai.yaml --wait
Note global.objectStorage.minio.existingSecret
and minio.auth.existingSecret
must match.
You can further customize your MinIO installation by passing values under the minio
key in your values file. MinIO installation is provided by the Bitnami chart, so please refer to their documentation for available options.
Changes to the MinIO configuration will not be supported by Eggplant.
Existing MinIO
If you have an existing MinIO installation you can use this instead as follows, using the same secret created above.
global:
objectStorage:
minio:
existingSecret: dai-objectstorage
endpoint: my.minio.deployment.example.com
minio:
enabled: false
Note the minio
key setting enabled
to false
. This prevents the bundled MinIO from being deployed.
Eggplant cannot provide support for MinIO installations external to your DAI installation.
S3
AWS S3 can be configured for object storage with an existing secret as follows. First, prepare an existing secret with credentials in:
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: dai-objectstorage
stringData:
aws-access-key-id: my-access-key-id
aws-secret-access-key: my-secret-access-key
$ kubectl -n dai apply -f dai-objectstorage.yaml
Modify your values file to update or add the following keys as follows:
global:
objectStorage:
provider: "aws"
aws:
existingSecret: dai-objectstorage
awsAccessKeyIdKey: aws-access-key-id
awsSecretAccessKeyKey: aws-secret-access-key
region: "eu-west-1"
minio:
enabled: false
Now you can deploy it to your cluster with Helm.
PostgreSQL
Eggplant DAI uses PostgreSQL for data storage. The Helm chart provides several options for configuring it.
Bundled PostgreSQL (Default)
By default, the Eggplant DAI Helm chart deploys PostgreSQL as a sub-chart with username and password both set to postgres
.
To override this, create a secret with credentials in:
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: dai-postgres
stringData:
postgres-password: my-access-key-id
Modify your values file to update or add the following keys and apply it to your cluster with Helm:
global:
postgresql:
auth:
existingSecret: dai-postgres
keycloak:
externalDatabase:
existingSecret: dai-postgres
existingSecretPasswordKey: postgres-password
Note keycloak.externalDatabase.existingSecretPasswordKey
: by default, the Bitnami chart expects the existing secret to have the database password under the key password
, but the Bitnami PostgreSQL chart and DAI default to postgres-password
as the key. You can either overrirde the behaviour of the Keycloak chart, as above, or alternatively you could set global.postgresql.auth.secretKeys.adminPasswordKey
.
The PostgreSQL installation is provided by the Bitnami chart. You can further customize it by passing options to it under the postgresql
key in your values file. See the Bitnami documentation for available options.
If you override extraEnvVars
, you need to ensure you also set the POSTGRESQL_DATABASE
environment variable to keycloak
. This creates the Keycloak database that is configured under the keycloak
key in the default values.
Eggplant cannot support changes to the PostgreSQL configuration.
Existing PostgreSQL
If you have an existing PostgreSQL installation, or would like to use an external service like AWS RDS, you can do so.
Using the same existing secret as above, modify your values file to set the following keys:
global:
postgresql:
host: my.postgresql.host.example.com
auth:
existingSecret: dai-postgres
keycloak:
externalDatabase:
existingSecret: dai-postgres
existingSecretPasswordKey: postgres-password
host: my.postgresql.host.example.com
postgresql:
enabled: false
Note that if you use an existing PostgreSQL deployment, you also need to update the Keycloak configuration to use this.
Engine scaling
The engine component of Eggplant DAI is used for test execution and report generation. As your DAI instance becomes busier, you will need to scale this component to handle greater test volumes. We recommend using Keda to manage this scaling.
To use Keda, first install it according to upstream instructions.
Only Keda v2 is supported.
Then enable Keda by adding the following to your values file:
ai-engine:
keda:
enabled: true
If you can't use Keda for some reason, you can manually manage the number of engine replicas by adding the following to your values file, increasing it as your instance becomes busier. If you are not using KEDA then we recommend you configure n + 1 engines, where n is the number of tests you wish to run in parallel.
ai-engine:
replicaCount: 2
Keycloak
Eggplant DAI depends on Keycloak for authentication and authorization services. We bundle this as a sub-chart and do not currently support using your own Keycloak installation.
Configuring TLS
When running DAI in containers, the use of TLS certificates is mandatory. However, starting with DAI version 7.3 it is possible use TLS certificates signed by a private certificate authority (see the Adding a custom TLS Certificate Authority (CA) section below). How you add TLS is up to you and is likely to depend on your infrastructure. This may include:
- Adding the TLS certificates to a loadbalancer, external to the cluster and terminating the TLS connections there
- Adding wildcard certificates to the ingress-nginx controller so that all ingress rules / hosts can share a common certificate
- Adding a Kubernetes secret containing the TLS certificates to the DAI namespace and supplying the secret details to DAI via values.
The first two options will be dependent on your infrastructure and do not require DAI configuration changes. If you would like to add a TLS certificate to DAI you can:
-
Obtain your certificate and key in PEM format. The certificate should include the full chain.
-
Create the TLS in the DAI namespace. (note that you may have to create the namespace first).
kubectl create secret tls tls-secret --cert=path/to/cert/file --key=path/to/key/file -n dai
-
Update the ingress section of your DAI helm values file to add
tls
sections underglobal.ingress
andglobal.keycloak
as per below (update the hostname and secret name to suit your installation):dai.yamlglobal:
ingress:
host: dai.example.com
tls:
- hosts:
- dai.example.com
secretName: tls-secret
keycloak:
tls:
secretName: tls-secret -
Complete the helm install as normal.