An open cloud-native web console improving on the life of SAP Applications administrators.
Trento is a city on the Adige River in Trentino-Alto Adige/Südtirol in Italy. [...] It is one of the nation's wealthiest and most prosperous cities, [...] often ranking highly among Italian cities for quality of life, standard of living, and business and job opportunities. (source)
This project is a reboot of the "SUSE Console for SAP Applications", also known as the Blue Horizon for SAP prototype, which is focused on automated infrastructure deployment and provisioning for SAP Applications.
As opposed to that first iteration, this new one will focus more on operations of existing clusters, rather than deploying new one.
- Automated discovery of SAP HANA HA clusters;
- SAP Systems and Instances overview;
- Configuration validation for Pacemaker, Corosync, SBD, SAPHanaSR and other generic SUSE Linux Enterprise for SAP Application OS settings (a.k.a. the HA Checks);
- Specific configuration audits for SAP HANA Scale-Up Performance-Optimized scenarios deployed on MS Azure cloud.
The entire Trento application is composed of the following parts:
- One or more Consul Agents in server mode;
- The Trento Web UI (
trento web
); - A Consul Agent in client mode for each target node;
- A Trento Agent (
trento agent
) for each target node.
See the architecture document for additional details.
While the trento web
component has only been tested on openSUSE 15.2
and SLES 15SP2 so far, it should be able to run on most modern Linux distributions.
The trento agent
component could in theory also run on openSUSE, but it does not make much sense as it
needs to interact with different low-level SAP applications components
which are expected to be run in a
SLES for SAP installation.
Running the application will require:
- A running Consul cluster.
We have only tested version Consul version
1.9.x
and, while it should work with any version implementing Consul Protocol version 3, we can´t make any guarantee in that regard.
To build the entire application you will need the following dependencies:
Additionally, for the development we use:
Mockery
^2
See the Development section for details on how to install
mockery
.
Pre-built statically linked binaries are made available via GitHub releases.
You clone also clone and build it manually:
git clone https://github.com/trento-project/trento.git
cd trento
make build
T.B.D.
T.B.D.
The Trento application needs to be paired with a Consul deployment, which is leveraged for service discovery and persistent data storage.
Consul processes are all called "agents", and they can run either in server mode or in client mode.
To start a Consul agent in server mode:
mkdir consul.d
./consul agent -server -ui -bootstrap-expect=1 -client=0.0.0.0 -data-dir=consul-data -config-dir=consul.d
This will start Consul listening to connections from any IP address on the default network interface, using consul-data
as directory to persist data, and consul.d
to autoload configuration files from.
Each Trento Agent instance also needs a Consul agent in client mode, on each target node we want to connect Trento to.
You can start Consul in client mode as follows:
export SERVER_IP_ADDRESS=#your Consul server IP address here
mkdir consul.d
./consul agent -retry-join=$SERVER_IP_ADDRESS -bind='{{ GetInterfaceIP "eth0" }}' -data-dir=consul-agent-data -config-dir=consul.d
Since the client Consul Agent will most likely run on a machine with multiple IP addresses and/or network interfaces, you will need to specify one with the -bind
flag.
Production deployments will require at least three instances of the Consul agent in server mode to ensure fault-tolerance. Be sure to check Consul's deployment guide.
While Consul provides a
-dev
flag to run a standalone, stateless server agent, Trento does not support this mode: it needs a persistent server even during development.
For development purposes, when running everything on a single host machine, no Client Consul Agent is required: the Server Agent exposes the same API and can be consumed by both
trento web
andtrento agent
.
Trento Agents are responsible for discovering HA clusters and reporting their status to Consul. These Agents need to run in the same systems hosting the HA Cluster services, so running them in isolated environments (e.g. serverless, containers, etc.) makes little sense, as they won't be able as the discovery mechanisms will not be able to report any host information.
To start the trento agent:
./trento agent start examples/azure-rules.yaml
Note that we are using
azure-rules.yaml
in this example which collect azure recommendations on cluster settings and state for many HA components. New rules can be created and tuned to adjust to different requirements.
At this point, we can start the web application as follows:
./trento web serve
Please consult the help
CLI command for more insights on the various options.
We use GNU Make as a task manager; here are some common targets:
make # clean, test and build everything
make clean # removes any build artifact
make test # executes all the tests
make fmt # fixes code formatting
make web-assets # invokes the frontend build scripts
make generate # refresh automatically generated code (e.g. static Go mocks)
Feel free to peek at the Makefile to know more.
As stated above, we use mockery
for the generate
target, which in turn is required for the test
target.
You can install it with go install github.com/vektra/mockery/v2
.
Be sure to add the
mockery
binary to your$PATH
environment variable so thatmake
can find it. That usually comes with configuring$GOPATH
,$GOBIN
, and adding the latter to your$PATH
.
To assist in testing & developing Trento, we have added a Dockerfile that will automatically fetch all the required compile-time dependencies to build the binary and finally a container image with the fresh binary in it.
We also provide a docker-compose.yml file that allows to
deploy other required services to run alongside trento
by fetching
the images from the dockerhub registry and running
the containers with your favourite container engine.
If you want to build & start trento web
and it's dependencies, you can use docker-compose
:
git clone https://github.com/trento-project/trento.git
cd trento
docker-compose up
The Web UI should then be reachable as defined in the docker-compose.yml
file
(localhost:8080
by default).
To only build the docker image, instead:
docker build -t trento .
Please note that the
trento agent
component requires to be running on the OS (not inside a container) so, while it is possible to hack thedocker-compose.yml
file to also run a Trento Agent, it makes little sense because most of its internals require direct access to the host of the HA Cluster components.
The SAPControl web service soap client was generated by hooklift/gowsdl, then the methods and structs needed were cherry-picked and adapted. For reference, you can find the full, generated, web service code here.
Please only report bugs via GitHub issues; for any other inquiry or topic use GitHub discussion.
See CONTRIBUTING.md
Copyright 2021 SUSE LLC
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
https://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.