diff --git a/trento/adoc/trento-container-install.adoc b/content/internal-notes/trento-container-install.adoc similarity index 88% rename from trento/adoc/trento-container-install.adoc rename to content/internal-notes/trento-container-install.adoc index a12616a4..a1552e39 100644 --- a/trento/adoc/trento-container-install.adoc +++ b/content/internal-notes/trento-container-install.adoc @@ -1,19 +1,18 @@ -include::product-attributes.adoc[] +:trento: Trento -== Containerized deployment +=== Containerized deployment :revdate: 2025-08-05 - -A containerized deployment of {trserver} is identical to the systemd +A containerized deployment of {trento} is identical to the systemd deployment. However, the web and check engine components are deployed as Docker containers. -Follow the steps in <>, but skip the *Install -Trento using RPM packages* step and follow the procedures as described below. +Follow the steps in link:https://www.trento-project.io/docs/user-guide/trento-install-server.html#sec-systemd-deployment[systemd installation], but skip the *Install +{trento} using RPM packages* step and follow the procedures as described below. -=== Install Trento using Docker +==== Install Trento using Docker -==== Install Docker container runtime +===== Install Docker container runtime . Enable the containers module (replace `15.x` with the correct Service Pack version): + @@ -35,9 +34,9 @@ zypper install docker systemctl enable --now docker ---- -==== Create a dedicated Docker network for Trento +==== Create a dedicated Docker network for {trento} -. Create the Trento Docker network: +. Create the {trento} Docker network: + [source,bash] ---- @@ -61,7 +60,7 @@ The output should be similar to this (the exact address may vary): . Open the _/var/lib/pgsql/data/pg_hba.conf_ file for editing and replace `0.0.0.0/0` with the address returned by the command in the previous step. . Restart the PostgreSQL server using the `systemctl restart postgresql` command. -==== Install Trento on Docker +==== Install {trento} on Docker . Create secret environment variables: + @@ -104,6 +103,8 @@ docker run -d --name wanda \ -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 \ + -e OAS_SERVER_URL=https://trento.example.com/wanda \ + -e AUTH_SERVER_URL=http://localhost:4000 \ --restart always \ --entrypoint /bin/sh \ registry.suse.com/trento/trento-wanda:latest \ @@ -121,7 +122,7 @@ the UI. [NOTE] ==== Add `+CHARTS_ENABLED=false+` if Prometheus is not installed, or you do -not want to use Trento's charts functionality. +not want to use {trento}'s charts functionality. ==== + [source,bash] diff --git a/content/trento-docs-site/preview-docs-with-docker.adoc b/content/trento-docs-site/preview-docs-with-docker.adoc new file mode 100644 index 00000000..5bd74e18 --- /dev/null +++ b/content/trento-docs-site/preview-docs-with-docker.adoc @@ -0,0 +1,36 @@ +== Local Documentation Preview with Docker + +Easy way to locally preview documentation changes without installing repository dependencies (like Node.js or Antora) on your host machine. + +=== Prerequisites + +* Docker Engine (or Podman). +* Docker Compose. + +=== Workflow + +. **Start the Preview** ++ +To start the build process inside a container, navigate to the root directory of the repository and run the following command: ++ +[source,bash] +---- +docker compose up +---- ++ + +. **Check the Docs** ++ +Once the build is complete and the server starts, open your browser and navigate to: ++ +http://localhost:3000 + +. **Review and Rebuild** ++ +The container builds the site and serves it. To view new changes: ++ +* Stop the container (press `Ctrl+C`). +* Make your changes to the source files. +* Run `docker compose up` again. ++ +The container will rebuild the documentation with your new changes for preview. \ No newline at end of file diff --git a/docker-compose.yml b/docker-compose.yml new file mode 100644 index 00000000..72d6152c --- /dev/null +++ b/docker-compose.yml @@ -0,0 +1,18 @@ +services: + trento-docs: + image: node:20-bullseye + volumes: + - .:/workspace:z + - trento-docs-node_modules:/workspace/trento-docs-site/node_modules + working_dir: /workspace/trento-docs-site + command: > + bash -lc " + npm install --no-save antora http-server && + npx antora antora-playbook.yml && + npx http-server build/trento-docs-site-public/ -c-1 -p 3000 + " + ports: + - "3000:3000" + +volumes: + trento-docs-node_modules: \ No newline at end of file diff --git a/trento-docs-site/antora.yml b/trento-docs-site/antora.yml index 62c7c1fe..e25d40d1 100644 --- a/trento-docs-site/antora.yml +++ b/trento-docs-site/antora.yml @@ -107,6 +107,9 @@ ext: - dir: trento-docs-site/build/tmp_components/mcp-server/docs files: ['**/*.adoc', '!README.adoc'] into: modules/mcp-server/pages + - dir: trento-docs-site/build/tmp_components/mcp-server/docs/images + files: '**/*.{png,jpg,jpeg,svg,gif}' + into: modules/mcp-server/images/ ## Trento Photofinish https://github.com/trento-project/photofinish - scan: - dir: trento-docs-site/build/tmp_components/photofinish diff --git a/trento-docs-site/modules/developer/nav_developer.adoc b/trento-docs-site/modules/developer/nav_developer.adoc index 31d17dd4..562d4635 100644 --- a/trento-docs-site/modules/developer/nav_developer.adoc +++ b/trento-docs-site/modules/developer/nav_developer.adoc @@ -35,9 +35,11 @@ ** Internal Notes *** xref:internal-notes/pr-env-ssl-certificate-setup.adoc[SSL Certificate creation and setup Guide for Pull Request Environments] *** xref:internal-notes/release.adoc[Release Process] +*** xref:internal-notes/trento-container-install.adoc[Containerized deployment] ** Trento Documentation Page *** xref:trento-docs-site/README.adoc[Documentation Page] +*** xref:trento-docs-site/preview-docs-with-docker.adoc[Local Documentation Preview with Docker] *** xref:trento-docs-site/contribution-upstream/components-nav-guide.adoc[Component Documentation Navigation Guide] *** xref:trento-docs-site/collaboration-docs-team/docs-git-workflow.adoc[Git Workflow for Trento Documentation] *** xref:trento-docs-site-ui/README.adoc[Documentation Page UI] diff --git a/trento/adoc/helm-event-pruning.adoc b/trento/adoc/helm-event-pruning.adoc deleted file mode 100644 index e29ea503..00000000 --- a/trento/adoc/helm-event-pruning.adoc +++ /dev/null @@ -1,46 +0,0 @@ -include::generic-attributes.adoc[] -include::product-attributes.adoc[] - -[[helm-event-pruning]] -== Configuring event pruning -:revdate: 2025-05-23 - - -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: - -[source,bash] ----- -helm ... \ - --set trento-web.pruneEventsOlderThan=<> \ - --set trento-web.pruneEventsCronjobSchedule="<>" ----- - -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: - -[source,bash] ----- -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 * * *" ----- \ No newline at end of file diff --git a/trento/adoc/trento-activity-log.adoc b/trento/adoc/trento-activity-log.adoc index d2c5fa46..a1dd58a9 100644 --- a/trento/adoc/trento-activity-log.adoc +++ b/trento/adoc/trento-activity-log.adoc @@ -11,7 +11,7 @@ console. Each entry in the Activity Log includes the following: -* A timestamp: the day and time (server time, not browser time) the +* A timestamp: the day and time (UTC timezone) the system event or the user action occurred * A message: type of the occurred event or user action * The user that triggered the event or performed the action. User system @@ -32,7 +32,7 @@ The Activity Log allows you to filter by the type of event or user action (commonly referred to as resource type), by the user that triggered the event or performed the action, and by severity status. Only active users are available for filtering. The Activity Log also allows you to filter out entries that are -newer and/or older than an specific date and time (server time). +newer and/or older than an specific date and time (UTC timezone). Once a filter has been set, click Apply to filter out the undesired entries and Reset to remove all the filters. @@ -66,4 +66,4 @@ The default retention time for entries in the Activity Log is one month. This can be changed in the Activity Log section under Settings. Changing the retention time requires the `+all:settings+` permissions. Entries older than the specified retention time are deleted every day at -midnight (server time). +midnight (UTC timezone). diff --git a/trento/adoc/trento-analyze-problems.adoc b/trento/adoc/trento-analyze-problems.adoc index fecc50fe..b762dd16 100644 --- a/trento/adoc/trento-analyze-problems.adoc +++ b/trento/adoc/trento-analyze-problems.adoc @@ -2,98 +2,90 @@ include::product-attributes.adoc[] [[sec-trento-problemanalysis]] == Problem Analysis -:revdate: 2025-06-10 +:revdate: 2025-10-27 -This section covers common problems and how to analyze them. - === {trserver} -There are two tools you can use to analyze issues with {trserver} in a -{k8s} scenario. These tools collect information and data that can be -useful when troubleshooting and analyzing the issue. +There are two tools you can use to collect information and data that can be useful when troubleshooting and analyzing issues with {trento} Server. + +==== {trento} support plugin + +The {trento} support plugin consists of the `trento-support.sh` script and the support plugin itself. The tool automates the collection of logs and relevant runtime information on the server side. It can be used in two different scenarios: + +* A deployment on K3s +* A systemd deployment -==== {trento} Support Plugin +==== Using the {trento} support plugin with a K3s deployment -The {trento} support plugin automates the collection of logs and -relevant runtime information on the server side. Using the plugin -requires a host with the following setup: +Using the plugin with a K3s deployment requires a {sles4sap} 15 SP3 or higher host with the following setup: -* The packages jq and python3-yq are installed. -* Helm is installed. -* The command `+kubectl+` is installed and connected to the {k8s} -cluster where {trserver} is running. +* Packages `jq` and `yq` are installed +* Helm is installed +* `kubectl` is installed and connected to the {k8s} cluster where {trserver} is running To use the plugin, proceed as follows: -. Download the {trento} support plugin script: +. Install the {trento} support plugin: + ==== [source,subs="attributes"] ---- -{prompt_root}wget https://raw.githubusercontent.com/trento-project/support/refs/heads/main/trento-support.sh +{prompt_root}zypper ref +{prompt_root}zypper install supportutils-plugin-trento ---- ==== + -[NOTE] -.Package available in {sles4sap} 15 SP3 and higher -==== -Customers of {sles4sap} 15 SP3 and higher can install the -trento-supportconfig-plugin package directly from the official -{sles4sapa} 15 repos using {zypper}. The Containers Module is required -for installation. -==== -. Make the script executable: +. Run the `trento-support.sh` script: + ==== [source,subs="attributes"] ---- -{prompt_root}chmod +x trento-support.sh +{prompt_root}trento-support.sh --output file-tgz --collect all ---- ==== + -. Make sure that `+kubectl+` is connected to the {k8s} cluster where -{trserver} is running and execute the script: +. Send the generated archive file to support for analysis. + +The script accepts the following options: + +* `-o`, `--output` Output type (`stdout`, `file`, `file-tgz`) +* `-c`, `--collect` Collection options (`configuration`, `base`, `kubernetes`, `all`) +* `-r`, `--release-name` Release name to use for the chart installation. Default is `trento-server` +* `-n`, `--namespace` {k8s} namespace used when installing the chart.Default is `default` +* `--help` Shows help messages + +==== Using the {trento} support plugin with a systemd deployment + +To use the plugin in this scenario, proceed as follows: + +. Install the {trento} support plugin: + ==== [source,subs="attributes"] ---- -{prompt_root}./trento-support.sh --output file-tgz --collect all +{prompt_root}zypper ref +{prompt_root}zypper install supportutils-plugin-trento ---- ==== + -. Send the generated archive file to support for analysis. +. Execute supportconfig as described in https://documentation.suse.com/sles/html/SLES-all/cha-adm-support.html\#sec-admsupport-cli. The `supportconfig` tool will call the {trento} support plugin. +. Send the generated output to support for analysis. -The {trento} support plugin accepts the following options: +=== Scenario dump script -`+-o+`, `+--output+`:: - Output type. Options: stdout|file|file-tgz -`+-c+`, `+--collect+`:: - Collection options: configuration|base|kubernetes|all -`+-r+`, `+--release-name+`:: - Release name to use for the chart installation. "trento-server" by - default. -`+-n+`, `+--namespace+`:: - {kube} namespace used when installing the chart. "default" by - default. -`+--help+`:: - Shows help messages +A scenario dump is a dump of the {trento} database. It helps the {trento} team to recreate the scenario to test it. -==== Scenario dump +A script is available in the {trento} upstream project. The script helps generate a scenario dump when the server is running on a {k8s} cluster. Using this script requires a host with the following setup: -The scenario dump is a dump of the {trento} database. It helps the -{trento} team to recreate the scenario to test it. Using the script -that generates the dump requires a host with the following setup: - -* The command `+kubectl+` is installed and connected to the {k8s} -cluster where {trento} Server is running. +* `kubectl` is installed and connected to the {k8s} cluster where {trserver} is running. To generate the dump, proceed as follows: . Download the latest version of the dump script: + ==== -[source,bash,subs="attributes"] +[source,subs="attributes"] ---- {prompt_user}wget https://raw.githubusercontent.com/trento-project/web/main/hack/dump_scenario_from_k8.sh ---- @@ -102,53 +94,47 @@ To generate the dump, proceed as follows: . Make the script executable: + ==== -[source,bash,subs="attributes"] +[source,subs="attributes"] ---- {prompt_user}chmod +x dump_scenario_from_k8.sh ---- ==== + -. Make sure that `+kubectl+` is connected to the {k8s} cluster where -{trserver} is running and execute the script as follows: +. Make sure that `kubectl` is connected to the {k8s} cluster where {trserver} is running and run the script: + ==== -[source,bash,subs="attributes"] +[source,subs="attributes"] ---- {prompt_user}./dump_scenario_from_k8.sh -n SCENARIO_NAME -p PATH ---- ==== + -. Go to `+/scenarios/+`, collect all the JSON files and send them to -support for analysis. +. Go to `PATH/scenarios/SCENARIO_NAME`, package all the generated JSON files, and send the package to support for analysis. -==== Pods descriptions and logs +=== Pods descriptions and logs -In addition to the output of the {trento} Support Plugin and the Dump -Scenario script, the descriptions and logs of the {trserver} pods can -be useful for analysis and troubleshooting purposes. These descriptions -and logs can be easily retrieved with the `+kubectl+` command. For this -to work, you need a host where kubectl is installed and connected to the -{k8s} cluster running {trserver}. +In case of a deployment on K3s, the descriptions and logs of the {trserver} pods can be useful for analysis and troubleshooting purposes (in addition to the output of the trento-support.sh script and the dump scenario script). These descriptions and logs can be obtained with the `kubectl` command. For this to work, you need a host with `kubectl` is installed and connected to the K3s cluster running {trserver}. -. List the pods running in {k8s} cluster and their statuses. -{trserver} currently consists of the following six pods: +. List the pods running in {k8s} cluster and their statuses. Run the command below to view {trserver} pods: + ==== -[source,bash,subs="attributes"] +[source,subs="attributes"] ---- {prompt_user}kubectl get pods -trento-server-prometheus-server-* -trento-server-postgresql-0 -trento-server-web-* -trento-server-wanda-* -trento-server-rabbitmq-0 + +NAME READY STATUS RESTARTS AGE +trento-server-postgresql-0 1/1 Running 0 87m +trento-server-prometheus-server-7b5c9474bc-wmv8s 2/2 Running 0 87m +trento-server-rabbitmq-0 1/1 Running 0 87m +trento-server-wanda-67ffbb79dc-7t6xw 1/1 Running 0 87m +trento-server-web-7df8f65794-vdbhs 1/1 Running 0 87m ---- ==== + . Retrieve the description of a pod as follows: + ==== -[source,bash,subs="attributes"] +[source,subs="attributes"] ---- {prompt_user}kubectl describe pod POD_NAME ---- @@ -157,7 +143,7 @@ trento-server-rabbitmq-0 . Retrieve the log of a pod as follows: + ==== -[source,bash,subs="attributes"] +[source,subs="attributes"] ---- {prompt_user}kubectl logs POD_NAME ---- @@ -166,60 +152,8 @@ trento-server-rabbitmq-0 . Monitor the log of a pod as follows: + ==== -[source,bash,subs="attributes"] +[source,subs="attributes"] ---- {prompt_user}kubectl logs POD_NAME --follow ---- -==== - -=== {tragent} - -The first source to analyze issues with the {tragent} is the {tragent} -status. It can be retrieved as follows: - -==== -[source,bash,subs="attributes"] ----- -{prompt_sudo}systemctl status trento-agent ----- -==== - -If further analysis is required, activate debug log level for the agent. -A detailed log can be then retrieved from the journal: - -. Add parameter `+log-level+` with value `+debug+` to the -`+/etc/trento/agent.yaml+` configuration file. -+ -==== -[source,bash,subs="attributes"] ----- -{prompt_sudo}vi /etc/trento/agent.yaml ----- -==== -+ -. Add the following entry: -+ -==== -[source,bash] ----- -log-level: debug ----- -==== -+ -. Restart the agent: -+ -==== -[source,bash,subs="attributes"] ----- -{prompt_sudo}systemctl restart trento-agent ----- -==== -+ -. Retrieve the log from the journal: -+ -==== -[source,bash,subs="attributes"] ----- -{prompt_sudo}journalctl -u trento-agent ----- -==== +==== \ No newline at end of file diff --git a/trento/adoc/trento-ansible-install.adoc b/trento/adoc/trento-ansible-install.adoc index f4956134..c178515f 100644 --- a/trento/adoc/trento-ansible-install.adoc +++ b/trento/adoc/trento-ansible-install.adoc @@ -1,6 +1,6 @@ include::product-attributes.adoc[] -== Automated deployment with Ansible +=== Automated deployment with Ansible :revdate: 2025-08-05 diff --git a/trento/adoc/trento-install-agents.adoc b/trento/adoc/trento-install-agents.adoc index 0623131b..83b52435 100644 --- a/trento/adoc/trento-install-agents.adoc +++ b/trento/adoc/trento-install-agents.adoc @@ -45,7 +45,7 @@ amqp://trento:trento@TRENTO_SERVER_HOSTNAME:5672/. If the default RabbitMQ username and password (`+trento:trento+`) were updated using Helm, the parameter must use a user-defined value. + -In a systemd or containerized deployment, the correct value is +In a systemd deployment, the correct value is `+amqp://TRENTO_USER:TRENTO_USER_PASSWORD@TRENTO_SERVER_HOSTNAME:5672/vhost+`. If `+TRENTO_USER+` and `+TRENTO_USER_PASSWORD+` have been replaced with custom values, you must use them. diff --git a/trento/adoc/trento-install-server.adoc b/trento/adoc/trento-install-server.adoc index 0fa7c694..c95ec8e6 100644 --- a/trento/adoc/trento-install-server.adoc +++ b/trento/adoc/trento-install-server.adoc @@ -2,232 +2,8 @@ include::product-attributes.adoc[] [[sec-trento-installing-trentoserver]] == Installing {trserver} -:revdate: 2025-08-05 +:revdate: 2025-10-16 - -[[sec-trento-k8s-deployment]] -=== {k8s} 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. - -[[sec-trento-install-trentoserver-on-existing-k8s-cluster]] -==== Installing {trserver} on an existing {k8s} cluster - -{trserver} consists of a several components delivered as container images and intended for deployment on a {k8s} cluster. A manual production-ready deployment of these components requires {k8s} knowledge. Customers without in-house {k8s} 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 {k8s} cluster node. You can use the {trento} Helm chart to install {trserver} on a existing {k8s} cluster as follows: - -. Install Helm: -+ -==== -[source,bash,subs="attributes"] ----- -curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash ----- -==== -+ -. Connect Helm to an existing {k8s} cluster. -. Use Helm to install {trserver} with the {trento} Helm chart: -+ -==== -[source,bash,subs="attributes"] ----- -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: -+ -==== -[source,bash] ----- -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 {trserver} installation was successful, open the URL of the {trweb} (`http://TRENTO_SERVER_HOSTNAME`) from a workstation on the {sap} administrator's LAN. - -[[sec-trento-install-trentoserver-on-k3s]] -==== Installing {trserver} on K3s - -If you do not have a {k8s} cluster, or have one but do not want to use it for {trento}, {suse} Rancher's K3s provides an alternative. To deploy {trserver} on K3s, you need a small server or VM (see <> for minimum requirements) and follow steps in <>. - -[IMPORTANT] -==== -The following procedure deploys {trserver} on a single-node K3s cluster. Note that this setup is not recommended for production use. -==== - -[[pro-trento-manually-installing]] -===== Manually installing Trento on a {trserver} host - -. Log in to the {trserver} host. -+ -[[st-install-k3s]] -. Install K3s either as {rootuser} or a non-{rootuser} user. -+ -* Installing as user {rootuser}: -+ -==== -[source,subs="attributes"] ----- -curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh ----- -==== -+ -* Installing as a non-{rootuser} user: -+ -==== -[source,bash,subs="attributes"] ----- -curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh -s - --write-kubeconfig-mode 644 ----- -==== -+ -[[st-install-helm]] -. Install Helm as {rootuser}. -+ -==== -[source,subs="attributes"] ----- -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: -+ -==== -[source,bash] ----- -export KUBECONFIG=/etc/rancher/k3s/k3s.yaml ----- -==== -+ -[[st-deploy-k3s]] -. With the same user that installed K3s, install {trserver} using the Helm chart: -+ -==== -[source,bash] ----- -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: -+ -==== -[source,bash] ----- -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 {trserver} pods, and wait until they are ready and running: -+ -==== -[source,bash] ----- -watch kubectl get pods ----- -==== -+ -All pods must be in the ready and running state. -+ -. Log out of the {trserver} host. -. To verify that the {trserver} installation was successful, open the URL of the {trweb} (`http://TRENTO_SERVER_HOSTNAME`) from a workstation on the {sap} administrator's LAN. - -[[sec-trento-deploying-trento-on-selected-nodes]] -==== Deploying {trserver} on selected nodes - -If you use a multi-node {k8s} cluster, it is possible to deploy {trserver} images on selected nodes by specifying the field `nodeSelector` in the helm upgrade command as follows: -==== -[source,bash] ----- -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 ----- -==== - -include::helm-event-pruning.adoc[leveloffset=+2] - -[[sec-trento-enabling-email-alerts]] -==== 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: - -[source,bash] ----- -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 ----- - -[[sec-trento-enabling-ssl]] -==== Enabling SSL - -Ingress may be used to provide SSL termination for the Web component of {trserver}. 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 {trserver} 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. -// toms 2022-09-14: which steps? - -include::trento-systemd-install.adoc[leveloffset=+1] -include::trento-container-install.adoc[leveloffset=+1] -include::trento-ansible-install.adoc[leveloffset=+1] \ No newline at end of file +include::trento-kubernetes-install.adoc[] +include::trento-systemd-install.adoc[] +include::trento-ansible-install.adoc[] \ No newline at end of file diff --git a/trento/adoc/trento-kubernetes-install.adoc b/trento/adoc/trento-kubernetes-install.adoc new file mode 100644 index 00000000..c46b031e --- /dev/null +++ b/trento/adoc/trento-kubernetes-install.adoc @@ -0,0 +1,267 @@ +include::product-attributes.adoc[] + +[[sec-trento-k8s-deployment]] +=== {k8s} deployment +:revdate: 2025-10-16 + +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. + +[[sec-trento-install-trentoserver-on-existing-k8s-cluster]] +==== Installing {trserver} on an existing {k8s} cluster + +{trserver} consists of a several components delivered as container images and intended for deployment on a {k8s} cluster. A manual production-ready deployment of these components requires {k8s} knowledge. Customers without in-house {k8s} 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 {k8s} cluster node. You can use the {trento} Helm chart to install {trserver} on a existing {k8s} cluster as follows: + +. Install Helm: ++ +==== +[source,bash,subs="attributes"] +---- +curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash +---- +==== ++ +. Connect Helm to an existing {k8s} cluster. +. Use Helm to install {trserver} with the {trento} Helm chart: ++ +==== +[source,bash,subs="attributes"] +---- +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: ++ +==== +[source,bash] +---- +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 {trserver} installation was successful, open the URL of the {trweb} (`http://TRENTO_SERVER_HOSTNAME`) from a workstation on the {sap} administrator's LAN. + +[[sec-trento-install-trentoserver-on-k3s]] +==== Installing {trserver} on K3s + +If you do not have a {k8s} cluster, or have one but do not want to use it for {trento}, {suse} Rancher's K3s provides an alternative. To deploy {trserver} on K3s, you need a small server or VM (see <> for minimum requirements) and follow steps in <>. + +[IMPORTANT] +==== +The following procedure deploys {trserver} on a single-node K3s cluster. Note that this setup is not recommended for production use. +==== + +[[pro-trento-manually-installing]] +===== Manually installing Trento on a {trserver} host + +. Log in to the {trserver} host. ++ +[[st-install-k3s]] +. Install K3s either as {rootuser} or a non-{rootuser} user. ++ +* Installing as user {rootuser}: ++ +==== +[source,subs="attributes"] +---- +curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh +---- +==== ++ +* Installing as a non-{rootuser} user: ++ +==== +[source,bash,subs="attributes"] +---- +curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh -s - --write-kubeconfig-mode 644 +---- +==== ++ +[[st-install-helm]] +. Install Helm as {rootuser}. ++ +==== +[source,subs="attributes"] +---- +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: ++ +==== +[source,bash] +---- +export KUBECONFIG=/etc/rancher/k3s/k3s.yaml +---- +==== ++ +[[st-deploy-k3s]] +. With the same user that installed K3s, install {trserver} using the Helm chart: ++ +==== +[source,bash] +---- +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: ++ +==== +[source,bash] +---- +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 {trserver} pods, and wait until they are ready and running: ++ +==== +[source,bash] +---- +watch kubectl get pods +---- +==== ++ +All pods must be in the ready and running state. ++ +. Log out of the {trserver} host. +. To verify that the {trserver} installation was successful, open the URL of the {trweb} (`http://TRENTO_SERVER_HOSTNAME`) from a workstation on the {sap} administrator's LAN. + +[[sec-trento-deploying-trento-on-selected-nodes]] +==== Deploying {trserver} on selected nodes + +If you use a multi-node {k8s} cluster, it is possible to deploy {trserver} images on selected nodes by specifying the field `nodeSelector` in the helm upgrade command as follows: +==== +[source,bash] +---- +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 +---- +==== + +[[helm-event-pruning]] +==== Configuring event pruning +:revdate: 2025-05-23 + + +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: + +[source,bash] +---- +helm ... \ + --set trento-web.pruneEventsOlderThan=<> \ + --set trento-web.pruneEventsCronjobSchedule="<>" +---- + +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: + +[source,bash] +---- +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 * * *" +---- + +[[sec-trento-enabling-email-alerts]] +==== 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: + +[source,bash] +---- +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 +---- + +[[sec-trento-enabling-ssl]] +==== Enabling SSL + +Ingress may be used to provide SSL termination for the Web component of {trserver}. 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 {trserver} 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. +// toms 2022-09-14: which steps? diff --git a/trento/adoc/trento-lifecycle.adoc b/trento/adoc/trento-lifecycle.adoc index 2ec0e4af..aa5263af 100644 --- a/trento/adoc/trento-lifecycle.adoc +++ b/trento/adoc/trento-lifecycle.adoc @@ -12,7 +12,7 @@ include::product-attributes.adoc[] + Delivery mechanism::: RPM package for {sles4sap} 15 SP3 and newer. -Supported runtime::: Supported in {sles4sap} 15 SP3 and newer on x86_64 and ppc64le architectures. +Supported runtime::: Supported in {sles4sap} 15 SP4 and newer, and {sles4sap} 16.0, on x86_64 and ppc64le architectures. // Variable List for trserver {trserver}:: @@ -25,4 +25,4 @@ Delivery mechanisms::: A set of container images from the {suse} public registry * If you don't have a {k8s} cluster, and need enterprise support, {suse} recommends {suse} {rke} (RKE) version 1 or 2. * If you do not have a {k8s} enterprise solution but you want to try {trento}, {suse} Rancher's K3s provides you with an easy way to get started. But keep in mind that K3s default installation process deploys a single node {k8s} cluster, which is not a recommended setup for a stable Trento production instance. -systemd and containerized deployments::: Supported in {sles4sap} 15 SP3 and newer. +systemd deployments::: Supported in {sles4sap} 15 SP4 and newer, and {sles4sap} 16.0. diff --git a/trento/adoc/trento-report-issue.adoc b/trento/adoc/trento-report-issue.adoc index 90b88b94..6bfdab73 100644 --- a/trento/adoc/trento-report-issue.adoc +++ b/trento/adoc/trento-report-issue.adoc @@ -2,24 +2,23 @@ include::product-attributes.adoc[] [[sec-trento-report-problem]] == Reporting an Issue -:revdate: 2025-06-10 +:revdate: 2025-10-27 -{suse} customers with registered {sles4sap}{nbsp}15 (SP3 or higher) +{suse} customers with registered {sles4sap}{nbsp}15 (SP4 or higher) or {sles4sap} 16.0 distributions can report {trento} issues either directly in the {scc} or through the corresponding vendor, depending on their licensing model. Problems must be reported under {sles4sap}{nbsp}15 and component trento. When opening a support case for {trento}, provide the relevant -deployment option for {trserver}: {k8s}, systemd or containerized. +deployment option for {trserver}: {k8s}, or systemd RPM installation. In case of a {k8s} deployment, provide the output of the {trento} -support plugin and the scenario dump, as explained in section +support script as explained in section <>. -In case of a systemd deployment, provide the status and the journal of -the trento-web and trento-wanda services. +In case of a systemd deployment, provide the output of the {trento} support plugin, as explained in section <>. In case of a containerized deployment, provide the logs of the trento-web and trento-wanda containers. Use `+docker ps+` to retrieve diff --git a/trento/adoc/trento-requirements.adoc b/trento/adoc/trento-requirements.adoc index 22fcfe11..5271cb84 100644 --- a/trento/adoc/trento-requirements.adoc +++ b/trento/adoc/trento-requirements.adoc @@ -14,7 +14,7 @@ Running all the {trserver} components requires a minimum of 4 GB of RAM, two CPU {trento} is based on event-driven technology. Registered events are stored in a {postgresql} database with a default retention period of 10 days. For each host registered with {trento}, you need to allocate at least 1.5GB of space in the {postgresql} database. -{trserver} supports different deployment scenarios: {k8s}, systemd, and containers. A {k8s}-based deployment of {trserver} is cloud-native and OS-agnostic. It can be performed on the following services: +{trserver} supports different deployment scenarios: {k8s} and systemd. A {k8s}-based deployment of {trserver} is cloud-native and OS-agnostic. It can be performed on the following services: * RKE1 ({rancher_k8s_engine} version 1) * RKE2 @@ -56,5 +56,5 @@ Similarly, the clusters must have unique authkeys in order to be registered in { [[sec-trento-installation-prerequisites]] === Installation prerequisites -* *{trserver}* For a {k8s}-based deployment, you must have access to {suse} public registry for the deployment of {trserver} containers. For a systemd deployment, you must have a registered {sles4sap} 15 (SP3 or higher) distribution. The same applies to a containerized deployment. -* *{tragent}s* A registered {sles4sap} 15 (SP3 or higher) distribution. \ No newline at end of file +* *{trserver}* For a {k8s}-based deployment, you must have access to {suse} public registry for the deployment of {trserver} containers. For a systemd deployment, you must have a registered {sles4sap} 15 (SP4 or higher) or {sles4sap} 16.0 distribution. +* *{tragent}s* A registered {sles4sap} 15 (SP3 or higher) distribution. diff --git a/trento/adoc/trento-sso-integration.adoc b/trento/adoc/trento-sso-integration.adoc index 06255cca..3892837b 100644 --- a/trento/adoc/trento-sso-integration.adoc +++ b/trento/adoc/trento-sso-integration.adoc @@ -93,44 +93,6 @@ OIDC_CALLBACK_URL= + . Restart the application. -==== Enabling OpenID Connect when using Docker images - -To enable OIDC when using Docker images, proceed as follows: - -[arabic] -. If `+trento-web+` container is already running stop and delete the -container before continuing. For that run: -+ -[source,bash] ----- -docker stop trento-web -docker rm trento-web ----- -. Provide the following environment variables to the Docker container -via the `+-e+` option: -+ -[source,bash] ----- -docker run -d \ --p 4000:4000 \ ---name trento-web \ ---network trento-net \ ---add-host "host.docker.internal:host-gateway" \ - -...[other settings]... - -# Required: --e ENABLE_OIDC=true \ --e OIDC_CLIENT_ID= \ --e OIDC_CLIENT_SECRET= \ --e OIDC_BASE_URL= \ - -# Optional: --e OIDC_CALLBACK_URL= \ - -...[other settings]... ----- - ==== Available variables for OpenID Connect OIDC_CLIENT_ID:: @@ -216,48 +178,6 @@ OAUTH2_CALLBACK_URL= + . Restart the application. -[[enabling-oauth-20-when-using-docker-images]] -==== Enabling OAuth 2.0 when using Docker images - -To enable OAuth 2.0 when using Docker images, proceed as follows: - -[arabic] -. If `+trento-web+` container is already running stop and delete the -container before continuing. For that run: -+ -[source,bash] ----- -docker stop trento-web -docker rm trento-web ----- -. Use the following environment variables to the Docker container via -the `+-e+` option: -+ -[source,bash] ----- -docker run -d \ --p 4000:4000 \ ---name trento-web \ ---network trento-net \ ---add-host "host.docker.internal:host-gateway" \ - -...[other settings]... - --e ENABLE_OAUTH2=true \ --e OAUTH2_CLIENT_ID= \ --e OAUTH2_CLIENT_SECRET= \ --e OAUTH2_BASE_URL= \ --e OAUTH2_AUTHORIZE_URL= \ --e OAUTH2_TOKEN_URL= \ --e OAUTH2_USER_URL= \ - -# Optional: --e OAUTH2_SCOPES= \ --e OAUTH2_CALLBACK_URL= \ - -...[other settings]... ----- - [[available-variables-for-oauth-20]] ==== Available variables for OAuth 2.0 @@ -496,60 +416,6 @@ SAML_SIGNED_ENVELOPES= + . Restart the application. -==== Enabling SAML when using Docker images - -To enable SAML when using Docker images, proceed as follows: - -[arabic] -. If `+trento-web+` container is already running stop and delete the -container before continuing. For that run: -+ -[source,bash] ----- -docker stop trento-web -docker rm trento-web ----- -. Use the following environment variables to the Docker container via -the `+-e+` option: -+ -[source,bash] ----- -docker run -d \ --p 4000:4000 \ ---name trento-web \ ---network trento-net \ ---add-host "host.docker.internal:host-gateway" \ - -...[other settings]... - --e ENABLE_SAML=true --e SAML_IDP_ID= \ --e SAML_SP_ID= \ -# Only SAML_METADATA_URL or SAML_METADATA_CONTENT must by provided --e SAML_METADATA_URL= \ --e SAML_METADATA_CONTENT= \ - -# Optional: --e SAML_IDP_NAMEID_FORMAT= \ --e SAML_SP_DIR= \ --e SAML_SP_ENTITY_ID= \ --e SAML_SP_CONTACT_NAME= \ --e SAML_SP_CONTACT_EMAIL= \ --e SAML_SP_ORG_NAME= \ --e SAML_SP_ORG_DISPLAYNAME= \ --e SAML_SP_ORG_URL= \ --e SAML_USERNAME_ATTR_NAME= \ --e SAML_EMAIL_ATTR_NAME= \ --e SAML_FIRSTNAME_ATTR_NAME= \ --e SAML_LASTNAME_ATTR_NAME= \ --e SAML_SIGN_REQUESTS= \ --e SAML_SIGN_METADATA= \ --e SAML_SIGNED_ASSERTION= \ --e SAML_SIGNED_ENVELOPES= \ - -...[other settings]... ----- - ==== Available variables for SAML SAML_IDP_ID:: diff --git a/trento/adoc/trento-systemd-install.adoc b/trento/adoc/trento-systemd-install.adoc index 117104f6..c14f0e4e 100644 --- a/trento/adoc/trento-systemd-install.adoc +++ b/trento/adoc/trento-systemd-install.adoc @@ -1,7 +1,7 @@ include::product-attributes.adoc[] [[sec-systemd-deployment]] -== systemd deployment +=== systemd deployment :revdate: 2025-08-05 @@ -19,16 +19,16 @@ throughout this guide. * SP6 * SP7 -=== List of dependencies +==== List of dependencies * https://www.postgresql.org/[PostgreSQL] * https://rabbitmq.com/[RabbitMQ] * https://nginx.org/en/[NGINX] * https://prometheus.io/[Prometheus] (optional) -=== Install {trento} dependencies +==== Install {trento} dependencies -==== Install Prometheus (Optional) +===== Install Prometheus (Optional) https://prometheus.io/[Prometheus] is not required to run {trento}, but it is recommended, as it allows {trento} to display charts for each host with @@ -38,26 +38,17 @@ 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 +`+/etc/trento/trento-web+`. To use an existing Prometheus installation, set `+CHARTS_ENABLED+` to `+true+` ==== [[prometheus-existing-installation, Use existing installation]] -===== Use existing installation +====== Use existing installation Minimal required Prometheus version is *2.28.0*. -If you have a -https://prometheus.io/docs/prometheus/latest/installation/[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 <> as a reference to -adjust the Prometheus configuration. - [[prometheus-packagehub, Install Prometheus using the *unsupported* PackageHub repository]] -===== Install Prometheus using the *unsupported* PackageHub repository +====== Install Prometheus using the *unsupported* PackageHub repository https://packagehub.suse.com/[PackageHub] packages are tested by SUSE, but they do not come with the same level of support as the core SLES @@ -142,7 +133,7 @@ firewall-cmd --zone=public --add-port=9090/tcp --permanent firewall-cmd --reload ---- -==== Install PostgreSQL +===== Install PostgreSQL The current instructions are tested with the following PostgreSQL versions: @@ -171,7 +162,7 @@ zypper in postgresql-server systemctl enable --now postgresql ---- -===== Configure PostgreSQL +====== Configure PostgreSQL . Start `+psql+` with the `+postgres+` user to open a connection to the database: @@ -244,7 +235,7 @@ listen_addresses = '*' systemctl restart postgresql ---- -==== Install RabbitMQ +===== Install RabbitMQ . Install RabbitMQ server: + @@ -273,7 +264,7 @@ firewall-cmd --reload systemctl enable --now rabbitmq-server ---- -===== Configure RabbitMQ +====== Configure RabbitMQ To configure RabbitMQ for a production system, follow the official suggestions in the @@ -298,7 +289,7 @@ rabbitmqctl add_vhost vhost rabbitmqctl set_permissions -p vhost trento_user ".*" ".*" ".*" ---- -=== Install {trento} using RPM packages +==== Install {trento} using RPM packages The `+trento-web+` and `+trento-wanda+` packages come in the supported SLES4SAP distributions by default. @@ -310,7 +301,7 @@ Install {trento} web and wanda: zypper install trento-web trento-wanda ---- -==== Create the configuration files +===== 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+` @@ -338,7 +329,7 @@ Otherwise websockets fail to connect, causing no real-time updates in the UI. ==== -==== trento-web configuration +===== trento-web configuration ==== [source,bash] @@ -387,7 +378,7 @@ SMTP_PASSWORD=<> ---- ==== -==== trento-wanda configuration +===== trento-wanda configuration ==== [source,bash] @@ -402,7 +393,7 @@ ACCESS_TOKEN_ENC_SECRET=some-secret ---- ==== -==== Start the services +===== Start the services Enable and start the services: @@ -411,7 +402,7 @@ Enable and start the services: systemctl enable --now trento-web trento-wanda ---- -==== Monitor the services +===== Monitor the services Use `+journalctl+` to check if the services are up and running correctly. For example: @@ -422,7 +413,7 @@ journalctl -fu trento-web ---- [[validate-the-health-status-of-trento-web-and-wanda]] -=== Check the health status of trento web and wanda +==== 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. @@ -460,7 +451,7 @@ correctly, the output should be as follows: ---- ==== -=== Install and configure NGINX +==== Install and configure NGINX . Install NGINX package: + @@ -548,13 +539,13 @@ server { ---- ==== -=== Prepare SSL certificate for NGINX +==== Prepare SSL certificate for NGINX Create or provide a certificate for https://nginx.org/en/[NGINX] to enable SSL for {trento}. [[option-1-creating-a-self-signed-certificate]] -==== Create a self-signed certificate +===== Create a self-signed certificate . Generate a self-signed certificate: + @@ -615,7 +606,7 @@ systemctl enable --now nginx ---- [[option-2-using-lets-encrypt-for-a-signed-certificate-using-packagehub-repository]] -==== Create a signed certificate with Let's Encrypt using PackageHub repository +===== Create a signed certificate with Let's Encrypt using PackageHub repository [NOTE] ==== @@ -658,7 +649,7 @@ Certbot certificates are valid for 90 days. Refer to the above link for details on how to renew certificates. ==== -=== Accessing the trento-web UI +==== 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 diff --git a/trento/adoc/trento-uninstall-trento-server.adoc b/trento/adoc/trento-uninstall-trento-server.adoc index 08b94928..db7a5971 100644 --- a/trento/adoc/trento-uninstall-trento-server.adoc +++ b/trento/adoc/trento-uninstall-trento-server.adoc @@ -6,7 +6,7 @@ include::product-attributes.adoc[] The procedure to uninstall the {trserver} depends on the deployment -type: {k8s}, systemd or containerized. The section covers {k8s} +type: {k8s} or systemd. The section covers {k8s} deployments. If {trserver} was deployed manually, you need to uninstall it manually. diff --git a/trento/adoc/trento-update-trento-checks.adoc b/trento/adoc/trento-update-trento-checks.adoc index e079a855..f220eb02 100644 --- a/trento/adoc/trento-update-trento-checks.adoc +++ b/trento/adoc/trento-update-trento-checks.adoc @@ -11,7 +11,7 @@ catalog in their setup whenever updates to existing checks and new checks are released, without waiting for a new version release cycle. The procedure of updating the configuration checks depends on the -{trserver} deployment type: {k8s}, systemd or containerized. +{trserver} deployment type: {k8s} or systemd. In a {k8s} deployment, checks are delivered as a container image, and you can use Helm with the following options to pull the latest image: @@ -33,17 +33,4 @@ can use Zypper to update your checks catalog: {prompt_sudo}zypper ref {prompt_sudo}zypper update trento-checks ---- -==== - -In a containerized deployment, checks are delivered as a container -image, and you can user Docker to pull the latest version into the -trento-checks volume created during the installation process: - -==== -[source,bash,subs="attributes"] ----- -{prompt_user}docker run \ --v trento-checks:/usr/share/trento/checks \ -registry.suse.com/trento/trento-checks:latest ----- -==== +==== \ No newline at end of file diff --git a/trento/adoc/trento-update-trento-server.adoc b/trento/adoc/trento-update-trento-server.adoc index dd50891b..2c356cfc 100644 --- a/trento/adoc/trento-update-trento-server.adoc +++ b/trento/adoc/trento-update-trento-server.adoc @@ -6,7 +6,7 @@ include::product-attributes.adoc[] The procedure to update {trserver} depends on the chosen deployment -option: {k8s}, systemd, or containerized. +option: {k8s} or systemd. Consider the following when performing an update: @@ -66,11 +66,3 @@ In a system deployment, you can use zypper to update {trserver}: systemctl restart trento-wanda ---- ==== - -In a containerized deployment, you can use the same Docker commands as -for the installation. Keep in mind that the volume for the {trento} -checks already exists, so there is no need to create it. Also, the web -and wanda containers must be stopped and removed before they can be -redeployed with the latest version. Also make sure to include in the -Docker commands any other options that you have enabled after the -original installation.