Skip to main content

Host preparation

This section is for users with experience of Linux system administration. Here we describe preparing a host to run applications built with the Genesis Application Platform.

Which OS?​

Genesis runs a set of JVM processes and a few external pieces of software, notably nginx. It requires (in almost all cases) one of a set of supported databases; Genesis Global can provide RPM packages for them, if required.

Our existing build pipeline favours producing either ZIP files or RPM packages. We recommend an OS from the RedHat family: either CentOS 7 or RHEL 7. We have seen good results with AmazonLinux 2.

note

If you choose a different Linux variant, you will need to locate suitable packages to install the database and other software packages.

Processes and dependencies​

For applications built on the platform, there are some dependencies that every running host must meet.

Genesis applications include both server-side and web code.

  • The server-side processes are Java and Kotlin.
  • The web framework is built as NPMs; web application code is served to the client by the server.

Java/Kotlin​

Genesis recommends openjdk-17 as the runtime. Note that the JRE is not sufficient, as installation of Genesis applications includes steps to configure the applications.

Third-party software​

Other packages needed to manage and run Genesis applications are:

  • nginx
  • unzip
  • lmdb

Databases​

Genesis supports several types of database. The currently supported list is:

Installing FoundationDB​

If resilient FoundationDB is required, it can be clustered across multiple hosts. For safety, an odd number of instances are needed. You can find set-up details in FoundationDB's documentation.

Specific preparations​

The default installation location for Genesis applications is in /data, which might not be created by your OS install. If it is not, it must be created mode 0644, as non-root users' data will be written inside, and thus it needs to be readable.

Genesis applications typically run as a non-root user (for a spectrum of reasons, largely security-related). The exact choice of user is in the control of the operator of the host. Genesis currently recommends a separate user per application on a host; multiple applications running as one user creates difficulties in development and operation.

During installation, the username for the application is used to set the file ownership and the behaviour of the start-up scripts. A symlink is created in the user's home directory. Therefore, you must not disable the creation of user home directories.

How many hosts, how big?​

Genesis applications can run quite happily within one host, provided enough CPU and memory are present. We recommend a minimum of 32GB memory. CPU demands vary greatly by application. Idle applications consume very little CPU.

Resilience options involve some customisation of set-up; the platform can integrate with Consul to handle multi-host set-ups. Some larger Genesis-built projects have spread out across more than a dozen hosts to achieve scaling and resilience. Consul at a known-good version can also be downloaded from our Artifactory using the link above.

Clustering is native to Genesis applications. Details of configuring it are covered in our sections on clustering for VMs and clustering for containers.

Disk space required is very application-dependent. Genesis applications log locally by default; log volumes are determined by application activity levels. Genesis applications also use local disk to create local LMDB files to help coordinate data. These are mmap()'d by the processes. Writes are coalesced by the Linux kernel, so IOPS is kept low, but disk usage is still affected by application activity.

If the chosen database is held locally, this also affects disk requirements. Data volumes depend greatly on the application, but the platform requires very little for itself. Consult your application developers on the anticipated data volumes.