4 Installation #

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 those 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:

Note

The examples in this section do not specify a Kubernetes namespace for simplicity. By default, Helm installs to the default namespace.

For production deployments, create and use a dedicated namespace.

Example:

kubectl create namespace trento
helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --namespace trento \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD

If you do not have a Kubernetes cluster, or you have one but you do not want to use it for Trento, you can use SUSE Rancher’s K3s as an alternative. To deploy Trento Server on K3s, you need a server or VM (see Section 3.1, “Trento Server requirements” for minimum requirements) and follow steps in Section 4.1.1.2.1, “Manually installing Trento on a Trento Server host”.

Important

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

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 global.trentoWeb.origin=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

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:

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:

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 global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
  --set trento-web.adminUser.password=ADMIN_PASSWORD \
  --set trento-web.pruneEventsOlderThan=30 \
  --set trento-web.pruneEventsCronjobSchedule="0 3 * * *"

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:

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:

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 global.trentoWeb.origin=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

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.

The trento-web and trento-wanda packages are available by default on supported SUSE Linux Enterprise Server for SAP applications distributions.

Install Trento web, wanda and checks:

zypper install trento-web trento-wanda

4.1.2.3.1 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.

Note

You can create the content of the secret variables such as SECRET_KEY_BASE, ACCESS_TOKEN_ENC_SECRET and REFRESH_TOKEN_ENC_SECRET using openssl:

openssl rand -out /dev/stdout 48 | base64

Also ensure that a valid hostname, FQDN, or IP address is configured in TRENTO_WEB_ORIGIN when using HTTPS. Otherwise, WebSocket connections will fail, preventing real-time updates in the web interface.

# /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=false
ADMIN_USER=admin
ADMIN_PASSWORD=trentodemo
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
CHECKS_SERVICE_BASE_URL=/wanda
OAS_SERVER_URL=https://trento.example.com

# /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>>

# /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
OAS_SERVER_URL=https://trento.example.com/wanda
AUTH_SERVER_URL=http://localhost:4000

4.1.2.3.4 Start the services #

 

Note

In some SUSE Linux Enterprise Server for SAP applications environments, SELinux may be enabled and set to enforcing mode by default. If Trento services fail to start or show permission-related errors, check the SELinux status:

getenforce

If SELinux is set to enforcing, switch it to permissive mode either temporarily or permanently:

• Temporary change (until reboot):

  setenforce 0

• Permanent change (persists after reboot):

  Edit /etc/selinux/config and set:

  SELINUX=permissive

Enable and start the services:

systemctl enable --now trento-web trento-wanda

journalctl -fu trento-web

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

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"}

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

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.

These variables affect how the playbooks execute. The available configuration options are:

Supply playbook-level variables using --extra-vars or -e on the command line during every playbook execution:

$ ansible-playbook -i <path-to-inventory> suse.trento.site -e provision_postgres=false -e provision_rabbitmq=false

Note

When disabling the provisioning of a Trento component, you must manually set the respective *_host role-level variables, which the playbook otherwise populates automatically. For example, if you specify -e provision_postgres=false when executing the server or site playbook, explicitly set trento_postgres_host in your inventory.

Almost all settings are configured via role-level variables. Set them in the inventory file under the vars: section:

all:
  children:
    trento_server:
      hosts: ...
    postgres_hosts:
      hosts: ...
    rabbitmq_hosts:
      hosts: ...
    prometheus_hosts:
      hosts: ...
    agents:
      hosts: ...

  vars:
    trento_server_name: "trento-deployment.example.com",
    trento_web_admin_password: "adminpassword",
    trento_web_postgres_password: "postgres",
    trento_wanda_postgres_password: "postgres",
    trento_rabbitmq_password: "guest",
    rproxy_ssl_cert: "<SSL certificate in base64>",
    rproxy_ssl_key: "<SSL certificate key in base64>"

Some role-level variables are mandatory.

For Trento Server, these are:

For Trento Agent, they are:

The rest of the variables are optional. You can find the full listing on the Trento Ansible project page.

The following inventory file installs every Trento component on a different host. It also enables and configures optional e-mail alerting:

all:
  children:
    trento_server:
      hosts:
        vitellone:
          ansible_host: "your-host"
          ansible_user: "your-user"
    postgres_hosts:
      hosts:
        vitellone-pg:
          ansible_host: "your-host"
          ansible_user: "your-user"
    rabbitmq_hosts:
      hosts:
        vitellone-mq:
          ansible_host: "your-host"
          ansible_user: "your-user"
    prometheus_hosts:
      hosts:
        vitellone-metrics:
          ansible_host: "your-host"
          ansible_user: "your-user"
    agents:
      hosts:
        hana01:
          ansible_host: "your-hana01-host"
          ansible_user: root
        hana02:
          ansible_host: "your-hana02-host"
          ansible_user: root

  vars:
    trento_server_name: "yourserver.com"
    trento_web_admin_password: "adminpassword"
    trento_web_postgres_password: "pass"
    trento_wanda_postgres_password: "wanda"
    trento_rabbitmq_password: "trento"
    rproxy_ssl_cert: |-
      -----BEGIN CERTIFICATE-----
      MIIEZDCCA0ygAwIBAgIUAue46Y/9kwT+zvPPW2xfuNv1+Z4wDQYJKoZIhvcNAQEL
      ...
      vzczKRPmQOQbiu02WM2hivWtPBH//A5N
      -----END CERTIFICATE-----
    rproxy_ssl_key: |-
      -----BEGIN PRIVATE KEY-----
      MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC1L7Ddc6oYaNPC
      ...
      mpNiKDOPALNTs+Ukdkt5KlE=
      -----END PRIVATE KEY-----

    web_enable_alerting: true
    web_alert_sender: "trento@example.com"
    web_alert_recipient: "trento_maintainers@example.com"
    web_smtp_server: "smtp.example.com"
    web_smtp_port: 587
    web_smtp_user: "smtp_user"
    web_smtp_password: "stmp_pass"

Execute Ansible by running the following command:

$ ansible-playbook -i <path-to-inventory> suse.trento.site

The following inventory file does not provision PostgreSQL, RabbitMQ, or Prometheus.

Note

There is no configuration for postgres_hosts, rabbitmq_hosts, and prometheus_hosts. Instead, explicit trento_postgres_host and trento_rabbitmq_host variables are configured.

all:
  children:
    trento_server:
      hosts:
        vitellone:
          ansible_host: "your-host"
          ansible_user: "your-user"
    agents:
      hosts:
        hana01:
          ansible_host: "your-hana01-host"
          ansible_user: root
        hana02:
          ansible_host: "your-hana02-host"
          ansible_user: root

  vars:
    trento_postgres_host: "yourexternalpg.com"
    trento_rabbitmq_host: "yourexternalrabbit.com:5671"

    trento_server_name: "your-servername.com"
    trento_web_admin_password: "adminpassword"
    trento_web_postgres_username: "postgres"
    trento_web_postgres_password: "trentoansible1"
    trento_wanda_postgres_username: "postgres"
    trento_wanda_postgres_password: "trentoansible1"
    trento_rabbitmq_username: "trentoansible"
    trento_rabbitmq_password: "trentoansible1"
    rproxy_ssl_cert: |-
      -----BEGIN CERTIFICATE-----
      MIIEZDCCA0ygAwIBAgIUAue46Y/9kwT+zvPPW2xfuNv1+Z4wDQYJKoZIhvcNAQEL
      ...
      vzczKRPmQOQbiu02WM2hivWtPBH//A5N
      -----END CERTIFICATE-----
    rproxy_ssl_key: |-
      -----BEGIN PRIVATE KEY-----
      MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC1L7Ddc6oYaNPC
      ...
      mpNiKDOPALNTs+Ukdkt5KlE=
      -----END PRIVATE KEY-----

Execute Ansible using the following command:

$ ansible-playbook -i <path-to-inventory> suse.trento.site -e provision_postgres=false -e provision_rabbitmq=false -e provision_prometheus=false

Use the following inventory file to install and configure only the Trento agents. You must explicitly specify the agent_web_api_key variable. Acquire this key manually before running the agent playbook alone.

all:
  children:
    agents:
      hosts:
        hana01:
          ansible_host: "your-hana01-host"
          ansible_user: root
        hana02:
          ansible_host: "your-hana02-host"
          ansible_user: root

  vars:
    agent_web_api_key: "yourserver.com"

Execute Ansible by specifying the agent playbook:

$ ansible-playbook -i <path-to-inventory> suse.trento.agent

Note

Custom-tailored inventories are not a requirement. They are used only to highlight which parameters are needed in specific cases. You can easily use a single, fully populated inventory and run only a subset of the operations, such as installing only the agent or skipping the PostgreSQL installation. The playbook automatically picks up or skips variables in the inventory as appropriate for the desired execution configuration.