About the automated Install/Migration tool
The flexdeployerinstaller.sh script is an automated process that reduces efforts for installing or upgrading FlexDeploy. There is a configuration file which will need to be configured for your installation, and then the installer can take over. There are three basic modes to the installer: 1) prerequisite checking with no installation or upgrade, 2) first time installation of FlexDeploy and 3) upgrading a current installation of FlexDeploy. You choose prereqs mode with the -p argument. Upgrade or install is selected by the presence of the FlexDeploy war in the webapps folder. If you are upgrading Weblogic, use the -w argument. The apache-tomcat-flexdeploy folder will be cleaned up with each upgrade, so it is important not to place any supporting files in the apache-tomcat-flexdeploy folder. Place them in the FLEXDEPLOY_HOME folder or another subfolder instead. Example of such files may include the SSO configuration file, Keystore and/or Wallet files.Versions / Release Notes
You should always download the latest version before running another install or upgrade, see https://support.flexagon.com for the installer download link. See the Installer Release Notes for more information and to find the latest release.This automated installer will handle
- executing prerequisite checks to ensure the installation/upgrade will be successful
- downloads of FlexDeploy software and influx database software if the server has access to the Internet
- installation of FlexDeploy 5.7.0.12+
- upgrading from version 5.1.0.0+
-
upgrading to FlexDeploy 5.7.0.12+
- NOTE that upgrading to FlexDeploy 10.0 requires you to first upgrade to 9.0 >= 9.0.0.3.
- backing up the current FlexDeploy installation, plugins, and optionally artifacts before upgrading
- backing up the database before upgrading (optional)
- creating or migrating the FlexDeploy database schemas
- installation or configuration of the influx database which is used for reporting and dashboard data for FlexDeploy version 6.0 and higher.
This automated installer will not handle
- downloads of software if the server has no access to the Internet. In this case, the files need to be placed on the FlexDeploy server in locations specified by the installer
- download of security wallets
- upgrading a Kubernetes installation
- install or upgrade on Windows
Installer arguments
The following arguments are available to be used:
- -p run the installer in the prerequisite checking mode. There will be no installation/upgrade performed when using this flag, so it can be run anytime. If the installer detects any issue(s), those will be reported to the logs and displayed on the screen. The prerequisites will also be run during the installation or upgrade process and may stop the process, which is why it is recommended to run this mode until there are no issues being reported. Each issue that is reported will have a possible resolution to the issue to assist you in resolving it. Some of the checks are: verify file system sizes to make sure all required directories have at least the minimum amount, flexdeployinstaller_config.txt file properties are set, java is at the right level, etc. Removing this argument will execute the install/upgrade.
-
-v version Tells the installer what version to install. You can specify versions as 4 numbers separated by periods, or the word latest. (Required argument)
- See http://support.flexagon.com or http://wiki.flexagon.com to find details on latest or specific version. Few examples of specific versions are 8.0.0.1, 8.0.0.4 etc.
- If you are planning to upgrade or install more than one FlexDeploy instances, then make sure to use specific version instead of word latest as meaning of latest will change over time.
- -c <path to>/flexdeployinstaller_config.txt points the installer to the flexdeployinstaller_config.txt file that contains the user configurations. (Required argument)
- -s there are several passwords in the flexdeployinstaller_config.txt file and if a password field is left blank, in this scenario, a prompt for the password will happen (nothing will be stored) and the password is not shown on the screen, similar to other Linux password prompts. The -s option will show the password on the screen as you type.
- -i skip the database backup. This can be done if you have an existing database backup.
- -a skip the artifacts backup. This can be done if you have an existing backup of the artifacts folder or a snapshot of the VM.
- -d Install as a docker container.
- -w Specify that you are upgrading from a WebLogic install to a Tomcat install. Not compatible with the -d option.
Step by Step Guide to Using the installer
Step 0: System Requirements
See FlexDeploy System Requirements for details on software and hardware requirements. See FlexDeploy Architecture for architecture details.Step 1: Database Preparation
Prepare either a Postgres or Oracle database.Postgres
Install the Postgres binaries, and create a flexdeploy database. The automated installer will create FD, FF, and FD_ADMIN schemas. You can use a docker image such as postgres:14 if you pass in thePGDATA parameter.
Either from the commandline with psql
Oracle
Install the Oracle Database binaries and find your jdbc connection string. The automated installer will create FD, FF, and FD_ADMIN schemas in the USERS tablespace. You can use a docker install of Oracle Database. See the Oracle Docker Images for more information.Step 2: Get the Installer
You should always download the latest version before running another install or upgrade, see https://support.flexagon.com for the installer download link. Download flexdeployinstaller.zip and get it to the FlexDeploy server. You can wget it there directly if you have Internet access, or transfer the file from another machine. FLEXDEPLOY_INSTALLER_HOME is folder where installer will be used for installer binaries and configuration files.Step 3: Setup the Configuration File
Step 3.1: Save flexdeployinstaller_config.txt
This step is extremely important to preserve your configuration file from any potential installer upgrades. This step should only be done once: on a new installation or on a first time upgrade with this new process. There is a configuration file (flexdeployinstaller_config.txt) that controls the actions of the installer. It is the most important file for the installer and needs to be saved to avoid being overlaid with any new flexdeployinstaller downloads as this would remove all of your entered configurations. There is a template file located in FLEXDEPLOY_INSTALLER_HOME/flexdeployinstaller. This template file must be copied to any other location, it could be placed in the FLEXDEPLOY_HOME and it would be safe from overlay and easier to find for the next upgrade.Step 3.2: Updating flexdeployinstaller_config.txt
Do not use spaces in any directory and/or password values.
This step should only need to be done once, on a new installation or on a first time upgrade with this new process. Unless there is a change to any of the configuration properties.
FLEXDEPLOY_HOME is a key property as the flexdeployinstaller will determine based on this property if a current installation is running, make sure the directory location is correct (e.g. the FLEXDEPLOY_HOME would be the path up to, but not including, the apache-tomcat-flexdeploy directory. /u01/flexdeploy/apache-tomcat-flexdeploy would have a FLEXDEPLOY_HOME of /u01/flexdeploy.
Step 4: Check the Prerequisites
Step 4.1: Execution
After the flexdeployinstaller_config.txt file is updated, the prerequisite checks should be executed outside of the install/upgrade process. The prerequisite checking process is designed to be run multiple times until all reported issues are resolved. Any issue that is found will be displayed on the screen in the form of the issue and the potential resolution. Run the installer as the user that has access to the docker commands.Step 4.2: Resolution
With the list of issues on the screen, and in the logs (FLEXDEPLOY_HOME/upgrade/logs), each issue must be resolved before continuing. Each issue will provide some level of resolution that can assist in clearing up the given issue.If there are any issues that are not resolved, the next step will fail as it will call the prerequisites also. The prerequisites need to be run on every execution but could stop the process, thus running the prerequisites independently will ensure a clean install/upgrade.