9.0

Edit

Installation overview

caution

Before installing WorkFusion SPA, or any of its components, read this section carefully and perform the required steps.

Server preparation

Make sure the minimum server hardware and software requirements given in the System requirements section are met for each server.

Also, make sure you've discussed this installation with your delivery manager. The license.properties file will need to be requisitioned by the delivery manager to activate SPA during installation.

We advise using a mounted volume for the SPA installation volume, usually /opt/workfusion. It is highly recommended that this volume be separate from the root volume where the operating system is installed.

warning

When ordering servers for the installation of WorkFusion SPA, make sure the system packages listed in Required packages are installed.

If you skip this step during the OS provisioning and setup, the root access is required to install these packages before the Workfusion SPA installation can begin.

High-level installation flow

Here is a high-level overview of the steps involved in installing the Workfusion SPA stack.

Workfusion SPA consists of a small number of individual components.

These components are logically grouped into seven roles, each of which is distributed across seven servers (by default). Our recommended architecture scheme, documented in the Product architecture section, contains the diagram which describes all components and how they are distributed across these seven servers. Here is a listing of the seven server roles: DB, APP, APM, OCR, VDS (VDS-Standalone or VDS-Cluster variations), RPA, BI.

  • Each server role represents a predefined set of software (workfusion-produced binaries and integrated third-party software).
  • Each server role is assumed to be installed on a separate server for the best performance, although some custom combinations of components and their custom distribution across servers is supported (for example, for the high availability of certain components).
  • Custom installation schemes can be performed individually per-customer on-demand.
  • This installation guide describes the default installation scheme where components are distributed across servers as per the scheme described above and in Product architecture.
  • For the purpose of this document, the installation process term is a defined set of actions needing to be performed on each server. In future versions of SPA, installation from a central point (control host) will be an option.
  • The DB server must be installed first. Other servers and roles do not have dependencies upon each other and can be installed in parallel or one-by-one in any order. But the recommended sequence of the installation:
    • Linux servers: DB > APP > APM > OCR > VDS (Standalone or Cluster)
    • Windows servers: RPA, BI can be installed before or after the installation of Linux servers or in parallel
    • Windows servers: RPA server requires Administrative access on the system and permissions for RDP connection into the system. BI server requires Administrative access on the system for the installation.
  • The installation of software components on each Linux server is performed using the same single installation package. It doesn't matter what server role you are provisioning (DB, APP, APM, OCR, or VDS), you'll use the same installation package and the same common config files for any of them.
  • The actual installation steps that need to be performed on each server are described in the rest of the installation documentation.
important

The steps below provide an overview of the installation procedure after the above-mentioned requirements are met. These steps are not meant to be run now. All the steps are described in the rest of the installation documentation.

The installation process on each Linux server (DB, APP, APM, OCR, VDS: vds-master, vds-slave, or vds-standalone) is divided into the pre-installation and actual installation phases. Each phase's steps are broken down as follows:

Phase 1: preinstallation

Environment and server requirements:

  1. Execute preinstall steps. Mind that the preinstall steps require root access on the server. Two scenarios are available here:
    1. Fully automated preinstall steps performed by Workfusion-Installer with a single command: ./install.sh preinstall <server_role>. This is the recommended method. The command should be run as the root user or with sudo permissions.
    2. Manual execution of preinstall steps one-by-one. All preparation steps for each particular Linux server are documented in Run preinstall manually. Each Linux server has common preinstall steps and its own set of preparation steps.
  2. Prepare TLS certificates Preparation according to the documentation and place them into the certificates directory inside the folder where the package was unpacked as described in Use TLS Certificates. You can also perform an automated generation of TLS certificates.
  3. Download the installation package to the server using any preferred method (scp, sftp, web, smb, nfs, rsynk, physical storage device, custom clients,, for example, s3cmd, awscli, and so on).
  4. Uncompress the installation package on the server.
  5. Populate values in two config files (secrets.yml and config.yml) that reside in the folder where the package was uncompressed.
  6. On the APP server, put your license.properties file in the file system, for example, in the directory where installation package was unpacked (provide the full path to the license.properties file in the config.yml configuration file). See your Workfusion Delivery Manager for details about license.properties.

Phase 2: actual installation

  1. Execute the following command in the directory where the package was unpacked.

    ./install.sh precheck <server_role>*

    Available options for <server_role> are as follows: db, app, ocr, apm, vds-master, vds-slave, vds-standalone. The command only checks that the software can be installed on this particular server.

    caution

    Without passing this phase, you cannot proceed with the installation. Verbose output of these commands tells you if the requirements are not met.

  2. Execute the following command to perform the actual installation:

    ./install.sh install <server_role>

  3. Execute the following command to performa a post-install check for the installation health:

    ./install.sh check <server_role>

Password complexity verification

Since Installer version: 9.0.0.8

The password complexity verification is implemented for you to use stronger passwords for better security. The mandatory password complexity requirements are listed below:

  • Password must be not shorter than 6 symbols and not longer than 20 symbols.
  • Password must contain at least one capital letter ([A-Z]).
  • Password must contain at least one number ([0-9]).
  • Password must contain at least one of the following special symbols !*#%^@.

All password settings are configured in the secrets.yml file. If these rules aren't applicable, you can turn off the password complexity verification in config.yml with the help of the "passwords check" variable switched to false.

Domain name configuration

The steps below assume that you already have seven servers where the Workfusion software is installed (5 Linux servers + 2 Windows servers).

Before performing any installation steps, configure DNS names for the servers as described in the DNS name configuration section.

TLS certificates

In case of any certificates related requirements, there are two solutions:

  • Trusted Certificates signed by trusted intermediate CA or directly by ROOT CA
  • Self Signed Certificates signed by an untrusted CA

Both cases are described in Using TLS certificates.

warning

The installation time can be significantly delayed if certificates are unavailable.

Network availability between servers:

  • The steps below assume that you already have seven servers where the Workfusion software is installed (5 Linux servers + 2 Windows servers).
  • Check that the following network ports are opened between servers and for end-users as described in the Application ports section.

Installation packages

  • Download links for all required installation packages are provided by WorkFusion.
  • The full distribution of the Workfusion software is a set of files (archives):
    • For DB, APP, APM, OCR, VDS (standalone or cluster) Linux Servers:
      • workfusion-full-release-flat-.tar.gz
    • For RPA Server (Windows):
      • RPAInstaller-.zip
      • Java SE Runtime Environment. Download from Oracle with this link.
    • For BI Server (Windows):
      • WorkFusionAnalyticsInstaller.zip
      • dashboards.zip
      • deploy_scripts.zip
      • wf_automation.zip

VDS installation types

VDS supports two installation types. Choose the one that best suits your needs.

  • VDS Standalone:

    • VDS Standalone: the simplest solution, all VDS components (VDS Master + NFS Share + one VDS Slave) are installed and run on a single server.
    • VDS performance is limited by the server capacity.
    • May be converted to VDS Cluster in future.
    • VDS Standalone type of installation is shown on the Product architecture page in the High-level architecture diagram on top of the page.

  • VDS Cluster:

    • VDS Cluster: a combination of one VDS Master + one or more VDS Slaves.
    • Additional slaves may be configured and added as required at any point after the initial setup.
    • VDS Cluster type of installation is shown on the Product Architecture page in the VDS Standalone vs VDS Cluster diagram.

  • When choosing installation type VDS Standalone or VDS Cluster, ensure the system requirements for your infrastructure are met as described in the System requirements section.

VDS Standalone

  • VDS Standalone is VDS Master + NFS Share + One VDS Slave installed on the same single server.
  • VDS Standalone server can be installed following the instructions in Preinstall steps and Installation steps using vds-standalone as server_role.
  • VDS Standalone may also be installed as sequential execution of all steps from Preinstall steps and Installation steps using vds-master as server_role firstly, and then vds-slave as server_role on the same server.

VDS Cluster

  • VDS Cluster installation consists of a VDS Master server + a number of separate VDS Slave servers.
  • VDS Cluster may also consist of VDS Standalone + a number of separate VDS Slave servers.
warning

Choose the NFS approach before proceeding.

Mind that VDS Cluster uses NFS for sharing data between the master and the slaves. There are several ways of using NFS for clustered VDS setup.

  • NFS on VDS master: This is the default behavior when using clustered VDS. No changes required.
  • NFS on a separate server (provided by customer): If you have a dedicated NFS server for VDS, it is necessary to set up and provide the shared location.
  • NFS on a separate server (configured via installer): NFS will be configured by the installer on a separate server.
    • Follow the instructions in Preinstall steps and Installation steps using vds-nfs as server_role before installing VDS Cluster. Once you choose one of the options above, you should follow the requirements of that configuration according to the System requirements section. Re-configuring of an already installed VDS NFS component is not supported.

Once NFS is configured:

← PreviousNext →