Installation Requirements

Modified on Fri, 5 Jul at 3:53 PM

In order to install an instance of the Labfolder platform, some requirements have to be met and some may or may not need to be met depending on the deployment model. This article explains.


TABLE OF CONTENTS



Hardware

The minimum resources required to run a fresh Labforward installation. All the recommendations below might increase depending on the number of users and application data load.



LabfolderLaboperatorLabfolder & Laboperator
CPUs6
68
Memory24GB16GB32GB
Total Disk space300GB200GB 400GB


The memory and CPU resources only consider the Kubernetes cluster and Labforward applications. If there is anything else running in the VM, adjust the resource requirements according;

  • The CPUs should be x84-64 or equivalent with 2.5 GHz or more;

    Virtual CPUs (vCPUs) are equally accepted;

  • Disk space should be distributed considering the following locations. These recommendations are true for all products:
    • /var - 250GB. All the remaining space. It stores the application data, container images, logs, and any other application output that might use the filesystem. All possible disk size increases due to business data will happen in /var;
    • /run - 50 GB. It stores any containerd ephemeral data. Sockets, pids, runtime state, mount points, and other plugin data that must not persist between reboots are stored in this location;

    • / - 10 GB. The installation will use multiple folders for different reasons. Labforward recommends adding 10 GB in the root mount point to handle all the other directories.

Considering an Ubuntu 22.04 installation, these are all the directories used for the on-premise cluster installation and their size estimation. These directories and sizes might change depending on the operational system. This information should be used only as a reference instead of definitive values:


  • /usr - 1 GB
  • /root - 8 MB
  • /.kube - 1 MB
  • /home - 3 MB
  • /etc - 0.3 MB
  • /tmp - 1 MB
  • /opt - 100 MB


Email Server

The installation requires an e-mail server with SMTP protocol.


One valid e-mail to send messages related to the login workflows and reports about the application usage to Labforward.


Networking



TLS Certificate

Labforward requires a valid TLS certificate for the domain and all subdomains. 

The certificate chain must include all entities, including the Certificate Authority. The options are (considering labforward.example.com  as the domain):


  • One wildcard certificate covering all subdomains: *.labforward.example.com.


  • Or one certificate with one Subject Alternative Name for each subdomain. The following subdomains must be mapped:


    admin-console.labforward.example.com - Admin console used for application management. Required for all customers;


    account.labforward.example.com - Identity and Authentication Manager (IAM). Used to authenticate all users. Required for all customers;


    fos.labforward.example.com - File Object Storage. Used to download/upload files directly from the browser. Required for all customers;


    labfolder.labforward.example.com - Labfolder application. Required for Labfolder/Labregister clients;


    labregister.labforward.example.com - Labregister application. Required for Labfolder/Labregister clients;


    laboperator.labforward.example.com - Laboperator application. Required for Laboperator clients;


    workflow-editor.labforward.example.com - Required for Laboperator clients;


    connector-manager.labforward.example.com - Required for Laboperator clients.



All subdomain names are configurable. The example above uses the default values.


Labforward supports two options for providing the TLS certificate during the installation:

  • Custom x509 certificate - the customer provides the certificate (.crt) and key (.key)


If the custom certificate is self-signed or has an unknown CA for the browsers or operational systems using the application, then the root certificate (.crt) must be provided.


  • Cert-manager with an automatically generated certificate issued by Let's Encrypt - for more details, check https://letsencrypt.org/how-it-works.


This certificate is recognized by all the common browsers and operational systems;


Let’s Encrypt requires access to the cluster to validate the certificate. For this reason, the following endpoint must be exposed on the public internet /.well-known/acme-challenge/*. Full example of the Let’s Encrypt validation request http://account.labforward.example.com/.well-known/acme-challenge/cr1rsRTImVz_s7HHk7biTQ. It makes one request for each subdomain available.


If exposing part of the cluster to the public internet is impossible, then the customer must provide a custom certificate.



DNS Requirements

Labforward requires a DNS routing the traffic to the cluster machine.


The DNS must cover all the domains used by the TLS certificate.


There are three options to configure the DNS:


  • Custom DNS - The customer is responsible for configuring the DNS

  • Labforward DNS - Labforward will configure the DNS in the https://subdomain.customer-name.labforward.app address. The domain name must end with labforward.app. The subdomain and customer-name are configurable by the customer;

  • No DNS - The customer configures the cluster and each end-user device to connect to the application's IP. For example, by editing the etc/hosts file. This option requires all the clients to be in the same network as the Kubernetes cluster. Notice that changing the cluster IP will require updating all devices. It can be done at the proxy level. Given the extra complexity and security risks, this option is not recommended.



Regardless of the option, the DNS mapping pointing out to the Kubernetes cluster IP** or CNAME must include all the following subdomains:


domain.tld - the domain. It must be mapped for TLS certificate validations and internal redirects inside the cluster

admin-console.labforward.example.com - Required for all customers;


account.labforward.example.com - Required for all customers;


fos.labforward.example.com - Required for all customers;


labfolder.labforward.example.com - Required for Labfolder/Labregister clients;


labregister.labforward.example.com - Required for Labfolder/Labregister clients;


laboperator.labforward.example.com - Required for Laboperator clients;


workflow-editor.labforward.example.com - Required for Laboperator clients;


connector-manager.labforward.example.com - Required for Laboperator clients.


  • Optionally, one wildcard entry plus the domain is accepted:


     *.domain.tld - wildcard for all subdomains;


    domain.tld - the main domain.


    ** By default, the cluster address is the same as its VM address.



Proxy

Proxies are not required for the installation. 


A proxy in the cluster network must use a valid TLS certificate signed by a known CA or the same TLS certificate of the Kubernetes cluster inserted via the admin console.



Operating System

This information only applies if you want to install the cluster using the provided kURL installer.


Note: Labforward recommends ubuntu 20.04.


Alternative operating systems

  • RHEL 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7;
  • Oracle Linux 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7;
  • Amazon Linux 2.


Access Requirements

  • SSH access via root, to run the installer
  • port 8800 access via port-forwarding or firewall rule, to access the administration interface


Tip: For more details about supported systems, check https://kurl.sh/docs/install-with-kurl/system-requirements.



Software 

The installation script installs all the required software, if not already installed; except for CURL, it must be installed before the installation.



Kubernetes Cluster

Any Kubernetes cluster must meet all these requirements: 

  • Kubernetes version 1.27.0 or above;

  • Kubernetes environment - EKS, GKE, AKS, DigitalOcean, kURL;

  • Containerd version 1.6+ as the container runtime;

  • Docker can not be installed in the machine;

  • A persistent volume storage class for the ReadWriteOnce and ReadWriteMany access modes;

  • Cert Manager version 1.7.0 or higher  (optional - when CertManager should be used for certificates);

  • Ingress Controller - we recommend ingress-nginx version 4.0.13 or higher;

  • A fresh namespace. We recommend naming it labforward. KOTS requires root access to this namespace;


Note: The cluster installed via Labforward’s installation script meets all these requirements. In this case, ensure that the installation machine does not have any of the items mentioned above previously installed, as Labforward will install everything for you. It is highly recommended to make the new installation in a fresh machine without any custom dependency.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article