Before you install
Before installing WorkFusion Software, read this section carefully and perform the required preparations.
Servers preparation
Make sure the requirements given in the System requirements section are met for each server.
It is recommended to use mounted HDD/SDD volume for the installation and keep it separate from the root volume where Operating System is installed.
caution
When ordering servers for WorkFusion installation, make sure the system packages listed in Required packages are installed.
If you skip this provision, you'll need root permissions for installing these packages later.
High-level installation flow
Information below helps to create a big picture of what you are going to do during installation of Workfusion software.
The whole Workfusion software product consists of a certain number of components.
These components are logically grouped into 7 "roles" and distributed across 7 servers as default and recommended architecture scheme section contains the diagram which describes all components and how they are distributed across 7 servers: DB, APP, APM, OCR, VDS (VDS-Standalone or VDS-Cluster variations), RPA, BI
- Each server role (APP, DB, APM, etc.) actually represents predefined set of software (workfusion-produced binaries and integrated 3rd-party software);
- Each server role is assumed to be installed on a separate server for best performance, although some custom combinations of components and their custom distribution across servers is supported (e.g. for high availability scenarios);
- Custom installation schemes can be performed individually per-customer on-demand;
- This installation guide describes the default installation scheme.
- Installation process is a defined set of actions which needs to be performed on each server;
- DB server should be installed first. Other servers don't have
dependencies from each other and can be installed in parallel or
one-by-one in any order. Although the recommended sequence of
installation:
Linux servers: DB → APP → APM → OCR → VDS (Standalone or Cluster);
Windows servers: RPA, BI can be installed before or after 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 installation.
- 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.
- Installation steps which need to be performed on each server are described further in documentation.
You don't need to perform the steps below right now. Just read them to get a big picture of what you are going to do. All the steps will be described in detail further in documentation in Preinstall steps and Installation steps sections. Installation process on each Linux server (DB, APP, APM, OCR, VDS [vds-master, vds-slave, or vds-standalone] ) is divided into several parts:
Uploading installation package to the server using any available method (scp, sftp, web, smb, nfs, rsynk, physical storage device, custom clients,, for example, s3cmd, awscli, and so on).
Unpacking installation package on the server.
Filling up two config files (
secrets.ymlandconfig.yml) inside the folder where the package was unpacked.Executing the
./install.sh precheck <server_role>command in the directory where the package was unpacked. Available server roles: db, app, ocr, apm, vds-master, vds-slave, vds-standalone. This command only checks that the software can be installed on this particular server. Without passing this phase it is impossible to proceed with installation.On the APP server put your license file
license.propertieson the file system,, for example, in the directory where installation package was unpacked (you'll need to provide the full path to thelicense.propertiesfile in theconfig.ymlconfiguration file).Executing Preinstall steps. Preinstall steps require root access on the server. Two scenarios are available here:
- Fully automated preinstall steps performed by Workfusion-Installer with a single command
./install.sh preinstall <server_role>. This is recommended way. The command should be run with root user. - Manual execution of Preinstall steps one-by-one. All preparation steps are documented in Run Preinstall Manually section for each particular Linux server.
- Each Linux server (DB, APP, APM, OCR, VDS [vds-master,vds-slave, or vds-standalone]) has common for all servers preinstall steps as well as its own set of preparation steps.
- Fully automated preinstall steps performed by Workfusion-Installer with a single command
Preparation and putting the required TLS certificates into the
certificatesdirectory inside the folder where the package was unpacked as described in Using TLS Certificates or automated generation of TLS certificates also described in the Using TLS Certificates section.Executing command
./install.sh install <server_role>that performs installation.Executing command
./install.sh check <server_role>that checks the software is operational.
Domain name configuration
- The steps below assume that you already have 7 servers where Workfusion Software will be installed (5 Linux servers + 2 Windows servers).
- Before performing any installation steps, please configure DNS names for the servers as described in DNS Names Configuration section.
TLS certificates
In case of any certificate-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 comprehensive guide with step by step examples [9.0.x] Using TLS Certificates.
warning
Install time can be significantly delayed if certs are unavailable.
Network Availability Between Servers:
- The steps below assume that you already have 7 servers where Workfusion Software will be installed (5 Linux servers + 2 Windows servers).
- Check that the following network ports are opened between servers and for end users as described in Application ports section.
Installation packages
- Download links for all required installation packages are provided by WorkFusion.
- The full distribution of 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.zipdashboards.zipdeploy_scripts.zipwf_automation.zip
- For DB, APP, APM, OCR, VDS (standalone or cluster) Linux Servers:
Linux installation package structure
- The main installation package
workfusion-full-release-flat-.tar.gzused for provisioning all Linux servers has the following file structure.
VDS installation types
VDS supports two types of installation. 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 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.
When choosing installation type VDS Standalone or VDS Cluster, ensure system requirements for your infrastructure are met as described in System Requirements](System_Requirements.html) 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 using 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 or separate VDS Slave servers.
Choose NFS approach before proceeding!
Note, 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've chosen one of the options above, you should follow the requirements of that configuration according to System Requirements section. Re-configuring of an already installed VDS NFS component is not supported.
Once NFS has been configured:
For VDS Master server, follow the instructions in Preinstall steps and Installation steps using vds-master as server_role.
For each of the VDS Slave servers, follow the instructions in Preinstall steps and Installation steps using vds-slave as server_role.