Trento Docs :: Trento Documentation

Installing Trento Server

Kubernetes deployment

The subsection uses the following placeholders:

TRENTO_SERVER_HOSTNAME: the host name used by the end user to access the console.
ADMIN_PASSWORD: the password of the default user created during the installation process. It must have at least 8 characters.

Installing Trento Server on an existing Kubernetes cluster

Trento Server consists of a several components delivered as container images and intended for deployment on a Kubernetes cluster. A manual production-ready deployment of these components requires Kubernetes knowledge. Customers without in-house Kubernetes expertise and who want to try Trento with a minimum of effort, can use the Trento Helm chart. This approach automates the deployment of all the required components on a single Kubernetes cluster node. You can use the Trento Helm chart to install Trento Server on a existing Kubernetes cluster as follows:

Install Helm:

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

Connect Helm to an existing Kubernetes cluster.

Use Helm to install Trento Server with the Trento Helm chart:

helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.trentoWebOrigin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD

When using a Helm version lower than 3.8.0, an experimental flag must be set as follows:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.trentoWebOrigin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD

To verify that the Trento Server installation was successful, open the URL of the Trento Web (http://TRENTO_SERVER_HOSTNAME) from a workstation on the SAP administrator’s LAN.

Installing Trento Server on K3s

If you do not have a Kubernetes cluster, or have one but do not want to use it for Trento, SUSE Rancher’s K3s provides an alternative. To deploy Trento Server on K3s, you need a small server or VM (see [sec-trento-server-requirements] for minimum requirements) and follow steps in Manually installing Trento on a Trento Server host.

The following procedure deploys Trento Server on a single-node K3s cluster. Note that this setup is not recommended for production use.

Manually installing Trento on a Trento Server host

Install K3s either as root or a non-root user.

Installing as user root:

# curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh

Installing as a non-root user:

> curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh -s - --write-kubeconfig-mode 644

Install Helm as root.

# curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

Set the KUBECONFIG environment variable for the same user that installed K3s:
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

With the same user that installed K3s, install Trento Server using the Helm chart:

helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.trentoWebOrigin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD

When using a Helm version lower than 3.8.0, an experimental flag must be set as follows:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.trentoWebOrigin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD

Monitor the creation and start-up of the Trento Server pods, and wait until they are ready and running:
watch kubectl get pods
All pods must be in the ready and running state.
Log out of the Trento Server host.
To verify that the Trento Server installation was successful, open the URL of the Trento Web (http://TRENTO_SERVER_HOSTNAME) from a workstation on the SAP administrator’s LAN.

Deploying Trento Server on selected nodes

If you use a multi-node Kubernetes cluster, it is possible to deploy Trento Server images on selected nodes by specifying the field nodeSelector in the helm upgrade command as follows:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.trentoWebOrigin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set prometheus.server.nodeSelector.LABEL=VALUE \
   --set postgresql.primary.nodeSelector.LABEL=VALUE \
   --set trento-web.nodeSelector.LABEL=VALUE \
   --set trento-runner.nodeSelector.LABEL=VALUE

..1. Configuring event pruning

The event pruning feature allows administrators to manage how long registered events are stored in the database and how often the expired events are removed.

The following configuration options are available:

pruneEventsOlderThan: The number of days registered events are stored in the database. The default value is 10. Keep in mind that pruneEventsOlderThan can be set to 0. However, this deletes all events whenever the cron job runs, making it impossible to analyze and troubleshoot issues with the application
pruneEventsCronjobSchedule: The frequency of the cron job that deletes expired events. The default value is "0 0 * * *", which runs daily at midnight.

To modify the default values, execute the following Helm command:

helm ... \
    --set trento-web.pruneEventsOlderThan=<<EXPIRATION_IN_DAYS>> \
    --set trento-web.pruneEventsCronjobSchedule="<<NEW_SCHEDULE>>"

Replace the placeholders with the desired values:

EXPIRATION_IN_DAYS: Number of days to retain events in the database before pruning.
NEW_SCHEDULE: The cron rule specifying how frequently the pruning job is performed.

Example command to retain events for 30 days and schedule pruning daily at 3 AM:

helm upgrade \
  --install trento-server oci://registry.suse.com/trento/trento-server \
  --set trento-web.trentoWebOrigin=TRENTO_SERVER_HOSTNAME \
  --set trento-web.adminUser.password=ADMIN_PASSWORD \
  --set trento-web.pruneEventsOlderThan=30 \
  --set trento-web.pruneEventsCronjobSchedule="0 3 * * *"

..2. Enabling email alerts

Email alerting feature notifies the SAP Basis administrator about important changes in the SAP Landscape being monitored by Trento.

The reported events include the following:

Host heartbeat failed
Cluster health detected critical
Database health detected critical
SAP System health detected critical

This feature is disabled by default. It can be enabled at installation time or anytime at a later stage. In both cases, the procedure is the same and uses the following placeholders:

SMTP_SERVER: The SMTP server designated to send email alerts
SMTP_PORT: Port on the SMTP server
SMTP_USER: User name to access SMTP server
SMTP_PASSWORD: Password to access SMTP server
ALERTING_SENDER: Sender email for alert notifications
ALERTING_RECIPIENT: Recipient email for alert notifications.

The command to enable email alerts is as follows:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.trentoWebOrigin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set trento-web.alerting.enabled=true \
   --set trento-web.alerting.smtpServer=SMTP_SERVER \
   --set trento-web.alerting.smtpPort=SMTP_PORT \
   --set trento-web.alerting.smtpUser=SMTP_USER \
   --set trento-web.alerting.smtpPassword=SMTP_PASSWORD \
   --set trento-web.alerting.sender=ALERTING_SENDER \
   --set trento-web.alerting.recipient=ALERTING_RECIPIENT

..3. Enabling SSL

Ingress may be used to provide SSL termination for the Web component of Trento Server. This would allow to encrypt the communication from the agent to the server, which is already secured by the corresponding API key. It would also allow HTTPS access to the Web console with trusted certificates.

Configuration must be done in the tls section of the values.yaml file of the chart of the Trento Server Web component.

For details on the required Ingress setup and configuration, refer to: https://kubernetes.io/docs/concepts/services-networking/ingress/. Particularly, refer to section https://kubernetes.io/docs/concepts/services-networking/ingress/#tls for details on the secret format in the YAML configuration file.

Additional steps are required on the Agent side.

.1. systemd deployment

A systemd installation of Trento Server, based on RPM packages, can be done manually. The latest available version of SUSE Linux Enterprise Server for SAP Applications is used as the base operating system, which is SLE 15 SP6 at the time of writing. For installations on Service Packs other than SP6, update the repository address as indicated in the respective notes provided throughout this guide.

Supported Service Packs:

.1.1. List of dependencies

.1.2. Install Trento dependencies

Install Prometheus (Optional)

Prometheus is not required to run Trento, but it is recommended, as it allows Trento to display charts for each host with useful information about the CPU load and memory.

If you choose not to install Prometheus, set CHARTS_ENABLED to false in the Trento web RPM configuration file stored in /etc/trento/trento-web, or when it is provided to the Trento web container. To use an existing Prometheus installation, set CHARTS_ENABLED to true

Use existing installation

Minimal required Prometheus version is 2.28.0.

If you have a existing Prometheus server, ensure to set the PROMETHEUS_URL environment variable to your Prometheus server’s URL as part of the Docker command when creating the trento-web container or configuring the RPM packages. Use Install Prometheus using the unsupported PackageHub repository as a reference to adjust the Prometheus configuration.

Install Prometheus using the unsupported PackageHub repository

PackageHub packages are tested by SUSE, but they do not come with the same level of support as the core SLES packages. Users should assess the suitability of these packages based on their own risk tolerance and support needs.

Enable PackageHub repository:

SUSEConnect --product PackageHub/15.5/x86_64

SLE15 SP3 requires a provided Prometheus server. The version available through SUSEConnect --product PackageHub/15.3/x86_64 is outdated and is not compatible with Trento’s Prometheus configuration. Refer to Use existing installation for SLE 15 SP3.

For SLE15 SP4 change the repository to SUSEConnect --product PackageHub/15.4/x86_64

Add the Prometheus user/group:

groupadd --system prometheus
useradd -s /sbin/nologin --system -g prometheus prometheus

Install Prometheus using Zypper:

zypper in golang-github-prometheus-prometheus

In case the missing dependency cannot be satisfied, we have already added the Prometheus user/group. This makes it safe to proceed with the installation by choosing Solution 2: break golang-github-prometheus-prometheus

Change Prometheus configuration by replacing the configuration at /etc/prometheus/prometheus.yml with:

global:
  scrape_interval: 30s
  evaluation_interval: 10s

scrape_configs:
  - job_name: "http_sd_hosts"
    honor_timestamps: true
    scrape_interval: 30s
    scrape_timeout: 30s
    scheme: http
    follow_redirects: true
    http_sd_configs:
      - follow_redirects: true
        refresh_interval: 1m
        url: http://localhost:4000/api/prometheus/targets

localhost:4000 in url:http://localhost:4000/api/prometheus/targets refers to the location where Trento web service is running.

Enable and start the Prometheus service:
```
# systemctl enable --now prometheus
```
If firewalld is running, allow Prometheus to be accessible and add an exception to firewalld:
```
firewall-cmd --zone=public --add-port=9090/tcp --permanent
firewall-cmd --reload
```

Install PostgreSQL

The current instructions are tested with the following PostgreSQL versions:

13.9 for SP3
14.10 for SP4
15.5 for SP5

Using a different version of PostgreSQL may require different steps or configurations, especially when changing the major number. For more details, refer to the official PostgreSQL documentation.

Install PostgreSQL server:
```
zypper in postgresql-server
```
Enable and start PostgreSQL server:
```
systemctl enable --now postgresql
```

Configure PostgreSQL

Start psql with the postgres user to open a connection to the database:
```
su - postgres
psql
```

Initialize the databases in the psql console:

CREATE DATABASE wanda;
CREATE DATABASE trento;
CREATE DATABASE trento_event_store;

Create the users:

CREATE USER wanda_user WITH PASSWORD 'wanda_password';
CREATE USER trento_user WITH PASSWORD 'web_password';

Grant required privileges to the users and close the connection:

\c wanda
GRANT ALL ON SCHEMA public TO wanda_user;
\c trento
GRANT ALL ON SCHEMA public TO trento_user;
\c trento_event_store;
GRANT ALL ON SCHEMA public TO trento_user;
\q

You can exit from the psql console and postgres user.

Allow the PostgreSQL database to receive connections to the respective databases and users. To do this, add the following to /var/lib/pgsql/data/pg_hba.conf:

host   wanda                      wanda_user    0.0.0.0/0   md5
host   trento,trento_event_store  trento_user   0.0.0.0/0   md5

The pg_hba.conf file works sequentially. This means that the rules on the top have preference over the ones below. The example above shows a permissive address range. So for this to work, the entires must be written at the top of the host entries. For further information, refer to the pg_hba.conf documentation.

Allow PostgreSQL to bind on all network interfaces in /var/lib/pgsql/data/postgresql.conf by changing the following line:
```
listen_addresses = '*'
```
Restart PostgreSQL to apply the changes:
```
systemctl restart postgresql
```

Install RabbitMQ

Install RabbitMQ server:
```
zypper install rabbitmq-server
```
Allow connections from external hosts by modifying /etc/rabbitmq/rabbitmq.conf, so the Trento-agent can reach RabbitMQ:
```
listeners.tcp.default = 5672
```

If firewalld is running, add a rule to firewalld:

firewall-cmd --zone=public --add-port=5672/tcp --permanent;
firewall-cmd --reload

Enable the RabbitMQ service:
```
systemctl enable --now rabbitmq-server
```

Configure RabbitMQ

To configure RabbitMQ for a production system, follow the official suggestions in the RabbitMQ guide.

Create a new RabbitMQ user:

rabbitmqctl add_user trento_user trento_user_password

Create a virtual host:
```
rabbitmqctl add_vhost vhost
```

Set permissions for the user on the virtual host:

rabbitmqctl set_permissions -p vhost trento_user ".*" ".*" ".*"

.1.3. Install Trento using RPM packages

The trento-web and trento-wanda packages come in the supported SLES4SAP distributions by default.

Install Trento web and wanda:

zypper install trento-web trento-wanda

Create the configuration files

Both services depend on respective configuration files. They must be placed in /etc/trento/trento-web and /etc/trento/trento-wanda respectively, and examples of how to modify them are available in /etc/trento/trento-web.example and /etc/trento/trento-wanda.example.

Important: The content of SECRET_KEY_BASE and ACCESS_TOKEN_ENC_SECRET in both trento-web and trento-wanda must be the same.

You can create the content of the secret variables like SECRET_KEY_BASE, ACCESS_TOKEN_ENC_SECRET and REFRESH_TOKEN_ENC_SECRET with openssl running openssl rand -out /dev/stdout 48 | base64

Depending on how you intend to connect to the console, a working hostname, FQDN, or an IP is required in TRENTO_WEB_ORIGIN for HTTPS. Otherwise websockets fail to connect, causing no real-time updates in the UI.

trento-web configuration

# /etc/trento/trento-web
AMQP_URL=amqp://trento_user:trento_user_password@localhost:5672/vhost
DATABASE_URL=ecto://trento_user:web_password@localhost/trento
EVENTSTORE_URL=ecto://trento_user:web_password@localhost/trento_event_store
ENABLE_ALERTING=false
CHARTS_ENABLED=true
PROMETHEUS_URL=http://localhost:9090
ADMIN_USER=admin
ADMIN_PASSWORD=test1234
ENABLE_API_KEY=true
PORT=4000
TRENTO_WEB_ORIGIN=trento.example.com
SECRET_KEY_BASE=some-secret
ACCESS_TOKEN_ENC_SECRET=some-secret
REFRESH_TOKEN_ENC_SECRET=some-secret

Note: Add CHARTS_ENABLED=false in Trento web configuration file if Prometheus is not installed or you do not want to use Trento’s charts functionality.

The alerting system to receive email notifications can be enabled by setting ENABLE_ALERTING to true and adding the following entries:

# /etc/trento/trento-web
ENABLE_ALERTING=true
ALERT_SENDER=<<SENDER_EMAIL_ADDRESS>>
ALERT_RECIPIENT=<<RECIPIENT_EMAIL_ADDRESS>>
SMTP_SERVER=<<SMTP_SERVER_ADDRESS>>
SMTP_PORT=<<SMTP_PORT>>
SMTP_USER=<<SMTP_USER>>
SMTP_PASSWORD=<<SMTP_PASSWORD>>

trento-wanda configuration

# /etc/trento/trento-wanda
CORS_ORIGIN=http://localhost
AMQP_URL=amqp://trento_user:trento_user_password@localhost:5672/vhost
DATABASE_URL=ecto://wanda_user:wanda_password@localhost/wanda
PORT=4001
SECRET_KEY_BASE=some-secret
ACCESS_TOKEN_ENC_SECRET=some-secret

Start the services

Enable and start the services:

systemctl enable --now trento-web trento-wanda

Monitor the services

Use journalctl to check if the services are up and running correctly. For example:

journalctl -fu trento-web

.1.4. Check the health status of trento web and wanda

You can check if Trento web and wanda services function correctly by accessing accessing the healthz and readyz API.

Check Trento web health status using curl:

curl http://localhost:4000/api/readyz

curl http://localhost:4000/api/healthz

Check Trento wanda health status using curl:

curl http://localhost:4001/api/readyz

curl http://localhost:4001/api/healthz

If Trento web and wanda are ready, and the database connection is set up correctly, the output should be as follows:

{"ready":true}{"database":"pass"}

.1.5. Install and configure NGINX

Install NGINX package:
```
zypper install nginx
```

If firewalld is running, add firewalld rules for HTTP and HTTPS:

firewall-cmd --zone=public --add-service=https --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload

Start and enable NGINX:
```
systemctl enable --now nginx
```
Create a configuration file for Trento:
```
vim /etc/nginx/conf.d/trento.conf
```

Add the following configuration to /etc/nginx/conf.d/trento.conf:

server {
    # Redirect HTTP to HTTPS
    listen 80;
    server_name trento.example.com;
    return 301 https://$host$request_uri;
}

server {
    # SSL configuration
    listen 443 ssl;
    server_name trento.example.com;

    ssl_certificate /etc/nginx/ssl/certs/trento.crt;
    ssl_certificate_key /etc/ssl/private/trento.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Wanda rule
    location ~ ^/(api/checks|api/v1/checks|api/v2/checks|api/v3/checks)/  {
        allow all;

        # Proxy Headers
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Cluster-Client-Ip $remote_addr;

        # Important Websocket Bits!
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_pass http://localhost:4001;
    }

    # Web rule
    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;

        # The Important Websocket Bits!
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_pass http://localhost:4000;
    }
}

Check the NGINX configuration:
```
nginx -t
```
If the configuration is correct, the output should be as follows:
```
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
```
If there are issues with the configuration, the output indicates what needs to be adjusted.

.1.6. Prepare SSL certificate for NGINX

Create or provide a certificate for NGINX to enable SSL for Trento.

Create a self-signed certificate

Generate a self-signed certificate:

Adjust subjectAltName = DNS:trento.example.com by replacing trento.example.com with your domain and change the value 5 to the number of days for which you need the certificate to be valid. For example, -days 365 for one year.

openssl req -newkey rsa:2048 --nodes -keyout trento.key -x509 -days 5 -out trento.crt -addext "subjectAltName = DNS:trento.example.com"

Copy the generated trento.key to a location accessible by NGINX:
```
cp trento.key /etc/ssl/private/trento.key
```
Create a directory for the generated trento.crt file. The directory must be accessible by NGINX:
```
mkdir -p /etc/nginx/ssl/certs/
```
Copy the generated trento.crt file to the created directory:
```
cp trento.crt /etc/nginx/ssl/certs/trento.crt
```
Reload NGINX to apply changes:
```
systemctl reload nginx
```

Create a signed certificate with Let’s Encrypt using PackageHub repository

Change repository if you use a Service Pack other than SP5. For example: SUSEConnect --product PackageHub/15.3/x86_64 for SLE15 SP3, SUSEConnect --product PackageHub/15.4/x86_64 for SLE15 SP4. Use packages in PackageHub at your own risk.

Add PackageHub, if it is not already added:

SUSEConnect --product PackageHub/15.5/x86_64
zypper refresh

Install Certbot and its NGINX plugin:

zypper install certbot python3-certbot-nginx

Obtain a certificate and configure NGINX with Certbot:

Replace example.com with your domain. For more information, refer to Certbot instructions for NGINX
```
certbot --nginx -d example.com -d www.example.com
```
Certbot certificates are valid for 90 days. Refer to the above link for details on how to renew certificates.

.1.7. Accessing the trento-web UI

Pin the browser to https://trento.example.com. You should be able to login using the credentials specified in the ADMIN_USER and ADMIN_PASSWORD environment variables.

.2. Containerized deployment

A containerized deployment of Trento Server is identical to the systemd deployment. However, the web and check engine components are deployed as Docker containers.

Follow the steps in systemd deployment, but skip the Install Trento using RPM packages step and follow the procedures as described below.

.2.1. Install Trento using Docker

Install Docker container runtime

Enable the containers module:

SUSEConnect --product sle-module-containers/15.5/x86_64

To use a different Service Pack than SP5, you have to choose the appropriate repository. For example, SUSEConnect --product sle-module-containers/15.3/x86_64 for SLE15 SP3, SUSEConnect --product sle-module-containers/15.4/x86_64 for SLE15 SP4.

Install Docker:
```
zypper install docker
```
Enable and start Docker:
```
systemctl enable --now docker
```

Create a dedicated Docker network for Trento

Create the Trento Docker network:

docker network create trento-net

When creating the trento-net network, Docker assigns a default subnet to it: 172.17.0.0/16. Ensure that this subnet is allowed by the rules specified in your PostgreSQL configuration. For more information, refer to the upstream pg_hba.conf documentation.

Verify the subnet of trento-net:

docker network inspect trento-net --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'

Expected output is as follows:

172.17.0.0/16

Install Trento on Docker

Create secret environment variables:

Consider using an environment variable file (see official Docker documentation). Adjust the docker command below for use with the env file. In any case, make sure you keep a copy of the generated keys in a safe location, in case you need to reuse them in the future.

WANDA_SECRET_KEY_BASE=$(openssl rand -out /dev/stdout 48 | base64)
TRENTO_SECRET_KEY_BASE=$(openssl rand -out /dev/stdout 48 | base64)
ACCESS_TOKEN_ENC_SECRET=$(openssl rand -out /dev/stdout 48 | base64)
REFRESH_TOKEN_ENC_SECRET=$(openssl rand -out /dev/stdout 48 | base64)

Install the checks on the system in a shared volume:

docker volume create trento-checks \
  && docker run \
  -v trento-checks:/usr/share/trento/checks \
  registry.suse.com/trento/trento-checks:latest

Deploy trento-wanda:

docker run -d --name wanda \
    -p 4001:4000 \
    --network trento-net \
    --add-host "host.docker.internal:host-gateway" \
    -v trento-checks:/usr/share/trento/checks:ro \
    -e CORS_ORIGIN=localhost \
    -e SECRET_KEY_BASE=$WANDA_SECRET_KEY_BASE \
    -e ACCESS_TOKEN_ENC_SECRET=$ACCESS_TOKEN_ENC_SECRET \
    -e AMQP_URL=amqp://trento_user:trento_user_password@host.docker.internal/vhost \
    -e DATABASE_URL=ecto://wanda_user:wanda_password@host.docker.internal/wanda \
    --restart always \
    --entrypoint /bin/sh \
    registry.suse.com/trento/trento-wanda:latest \
    -c "/app/bin/wanda eval 'Wanda.Release.init()' && /app/bin/wanda start"

Deploy trento-web.

Make sure to change the ADMIN_USER and ADMIN_PASSWORD, these are the credentials that are required to login to the trento-web UI. Depending on how you intend to connect to the console, a working hostname, FQDN, or an IP is required in TRENTO_WEB_ORIGIN for HTTPS. Otherwise websockets fail to connect, causing no real-time updates on the UI.

Add CHARTS_ENABLED=false if Prometheus is not installed, or you do not want to use Trento’s charts functionality.

docker run -d \
-p 4000:4000 \
--name trento-web \
--network trento-net \
--add-host "host.docker.internal:host-gateway" \
-e AMQP_URL=amqp://trento_user:trento_user_password@host.docker.internal/vhost \
-e ENABLE_ALERTING=false \
-e DATABASE_URL=ecto://trento_user:web_password@host.docker.internal/trento \
-e EVENTSTORE_URL=ecto://trento_user:web_password@host.docker.internal/trento_event_store \
-e PROMETHEUS_URL='http://host.docker.internal:9090' \
-e SECRET_KEY_BASE=$TRENTO_SECRET_KEY_BASE \
-e ACCESS_TOKEN_ENC_SECRET=$ACCESS_TOKEN_ENC_SECRET \
-e REFRESH_TOKEN_ENC_SECRET=$REFRESH_TOKEN_ENC_SECRET \
-e ADMIN_USER='admin' \
-e ADMIN_PASSWORD='test1234' \
-e ENABLE_API_KEY='true' \
-e TRENTO_WEB_ORIGIN='trento.example.com' \
--restart always \
--entrypoint /bin/sh \
registry.suse.com/trento/trento-web:latest \
-c "/app/bin/trento eval 'Trento.Release.init()' && /app/bin/trento start"

Email alerting are disabled by default, as described in enabling alerting guide. Enable alerting by setting ENABLE_ALERTING env to true. Additional required variables are: [ALERT_SENDER,ALERT_RECIPIENT,SMTP_SERVER,SMTP_PORT,SMTP_USER,SMTP_PASSWORD] All other settings should remain at their default.

Example:

docker run -d \

...[other settings]...

-e ENABLE_ALERTING=true \
-e ALERT_SENDER=<<SENDER_EMAIL_ADDRESS>> \
-e ALERT_RECIPIENT=<<RECIPIENT_EMAIL_ADDRESS>> \
-e SMTP_SERVER=<<SMTP_SERVER_ADDRESS>> \
-e SMTP_PORT=<<SMTP_PORT>> \
-e SMTP_USER=<<SMTP_USER>> \
-e SMTP_PASSWORD=<<SMTP_PASSWORD>> \

...[other settings]...

Check that everything is running as expected:

docker ps

Expected output:

CONTAINER ID   IMAGE                                         COMMAND                  CREATED          STATUS          PORTS                                       NAMES
8b44333aec39   registry.suse.com/trento/trento-web:2.2.0    "/bin/sh -c '/app/bi…"   6 seconds ago    Up 5 seconds    0.0.0.0:4000->4000/tcp, :::4000->4000/tcp   trento-web
e859c07888ca   registry.suse.com/trento/trento-wanda:1.2.0   "/bin/sh -c '/app/bi…"   18 seconds ago   Up 16 seconds   0.0.0.0:4001->4000/tcp, :::4001->4000/tcp   wanda

Both containers must run and listen on the specified ports.

.3. Automated deployment with Ansible

An automated installation of Trento Server using on RPM packages or Docker images can be performed with a Ansible playbook. For further information, refer to the official Trento Ansible project.