This section describes how to setup and deploy a GLU.Engine from the point when the build button is pressed on the GLU.Console. The pre-requisites required to install and run a GLU.Engine is Java Run time environment (JRE). As Java Run time environment is used to run GLU.Engines it should be possible to run on any OS which supports the Java JRE. See the GLU.Engine Server Specifications guide for details.
Installing Java JRE
Please use the correct install script for the system which you are using. We use the yum command as below, which might not be supported on all Operating Systems, here are a few examples.
$ sudo yum install java-1.8.0 You should remove any previous version of Java installed before installing the version you need, use this command:
$ sudo yum remove java-1.7.0-openjdk
Use the following command to check the Java version installed on the server.
$ java -version openjdk version "1.8.0_201" OpenJDK Runtime Environment (build 1.8.0_201-b09) OpenJDK 64-Bit Server VM (build 25.201-b09, mixed mode)
GLU.Engine Deployment process
GLU recommends the GLU.Engine is run as a user which is not root i.e. glu from the /opt/glu folder. Un-compress the tar file into the folder using the following command:
$ tar -xvf GLUENGINE.tar.gz
GLUENGINE.tar.gz is the file downloaded from the GLU console. The uncompressed tar file contains the shell scripts, text files and folders that come packaged with the GLU.Engine. Navigate to the GLUENGINE folder wherein you will have access to the following files and folders. All these scripts MUST be run in the folder where they were extracted.
Name of document/shell script/folder | Description |
---|---|
stopengine.sh | This will stop only the GLU.Engine. |
status.sh | This will provide a view on the status of the GLU processes.e.g.$ ./status.sh A1_GLU_Test_Basic-5.5-SNAPSHOT is NOT running |
startengine.sh | This shell script can be used to start the GLU.Engine with out prometheus and node exporter, for when these are not being used. |
changelogginglevel.sh | This Shells script will change the logging level of the GLU.Engine. See Changing the logging levelse.g. $ ./changelogginglevel.sh INFO |
engine | This is the folder where the GLU.Engine binaries are. |
Starting a GLU.Engine
Once the initial deploy is complete, the GLU.Engine can be started with the startengine.sh shell script using the following command:
$ ./startengine.sh
As the services start a message will be shown to confirm which services are starting.
Starting services…
The gluware.log will appear in the log folder (this is configured in the GLU.Console, Build Manager, GLU.Engine Settings tool – see GLU.Engine Settings) , these logs are used to examine the execution of the GLU.Engine. If the GLU.Engine starts successfully then the gluware log will have a row showing:
>>>>>> Glu Engine Started Successfully
Stopping a GLU.Engine
To stop the GLU.Engine processes use the stopall shell script with the following command:
$ ./stopengine.sh
The following message will be shown showing the GLU.Engine has stopped.
Stopping services... services Stopped.
GLU.Engine Logs
The gluware.log file is specifically for the GLU.Engine and describes the actions of the start-up processes as well as the ongoing actions the GLU.Engine takes as it handles transactions. It can be found at the path set in the GLU.Engine Settings. The gluware.log name format and the location is configurable in the Logging tab (as below).

SystemD
If you would like to put the control of starting and stopping the GLU.Engine into systemd, you can create a Unit with the contents of the startengine.sh and stopengine.sh.
systemd is a system and service manager for Linux operating systems. It provides a centralized way of managing processes, services, and other components of a Linux system. It replaces traditional init system and provides features such as parallel startup of system services, on-demand activation of daemons, resource management, and other advanced functionalities.
See the example below where the contents of the java command to start the GE is used in the ExecStart and the contents of the shutdown curl is used int he ExecStop.
# # GLU.Engine Unit # # Commands # # sudo cp glu.service /etc/systemd/system/glu.service # # sudo systemctl daemon-reload # sudo service glu start # sudo service glu status # sudo service glu stop # # to run at boot # # sudo systemctl enable glu # [Unit] Description=glu After=syslog.target #StartLimitIntervalSec=0 [Service] Type=simple Restart=always RestartSec=10 User=root WorkingDirectory=/opt/GLU/syntellbp-1.0-SNAPSHOT/ ExecStart= /usr/bin/java -XX:+PrintGCDetails -Xloggc:gc.log -Xms100m -Xmx300m -XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:+UseStringDeduplication -XX:G1HeapRegionSize=32 -XX:G1ReservePercent=15 -XX:InitiatingHeapOccupancyPercent=30 -XX:MetaspaceSize=100M -jar ./engine//syntellbp-1.0-SNAPSHOT.jar --spring.config.additional-location=./engine/config/appSetting.yml ExecStop= /usr/bin/curl --location --request POST 'http://localhost:9195/actuator/shutdown' [Install] WantedBy=multi-user.target
Take note to do the following when using systemd:
1. change the file “test_client_app-1.0-SNAPSHOT’ to match the GLU.Engine name you will be starting & stopping. See startengine.sh where this is defined.
2. change the memory settings “-Xms100m -Xmx300m” to match the settings in the startengine.sh.
3. change the WorkingDirectory to match the correct path/directory for the GLU.Engine
4. change the port “9195” in the ExecStop to match server port, see the stopengine.sh where this will be defined.
5. if multiple GLU.Engines are being run on the same machine, then make the service name unique to each engine, and save the unit file to a unique name i.e “glu-1.service”, adjust cp to reflect new name.
6. Ensure the /usr/bin/java & /usr/bin/curl point to where the paths to java and curl. (whereis command can be used to find this.)