Intro
Flexxible|SUITE includes an automatic update functionality for its basic components:
- Web services that support the console.
- Orchestrator binaries and system services.
- Database services.
This feature allows you to automatically update your system with the latest available version of Flexxible|SUITE. If your system is configured to update automatically, it will detect a new version in a previously configured Azure container and proceed to update its Flexxible|SUITE version.
Requirements
This feature requires connectivity to our Update Manager repository. Please, ensure that traffic is allowed to the following URLs:
How to configure Flexxible|Update manager
The Binaries Repository location should be specified in an Azure Container provided by Flexxible. Additional data must be provided in the Settings section. To access it, click on any of the Settings options in the left side menu and set the filter to All.
The settings you must configure are the following:
AutomaticAutoupdater: This is the setting to enable/disable this functionality. It's set to "false" by default, which means that administrator approval is required to run any update. If it's set to "true", the update will be performed automatically.
Note: please, keep in mind that, if a new update has been manually downloaded and then this setting is set to "true", that update won't be automatically installed.
CheckUpdateInterval: This is the number of minutes between update checks. Values under 10 mins are ignored
Updateinterval: This is the valid daily time range to apply updates. The max range is from 0:00 to 23:59 (UTC)
UpdatesRepositoryConnectionString: This is a connection string to an Azure repository or a UNC path to a network repository containing version updates
UpdatesRepositoryContainer: This is an Azure container that should be provided by Flexxible.
Azure or UNC path
The UpdateRepositoryConnectionString setting is set by default using a connection string of an Azure public repository.
In environments without Azure connectivity, you should configure a UNC path to access to the new versions. This path must have reading permissions in the infrastructure server where the VDIWorkerStructure service is hosted.
The UNC path must have the next syntax:
\\host-name\share-name\flexxibleSuite
Make sure that inside this folder exists a folder with the version number. Please, it's very important to maintain the version pattern to make it works.
This is an example:
Autoupdater VS administrator approval
If the AutomaticAutoupdater setting is set to true, the update will be performed in the update interval.
If the AutomaticAutoupdater setting is set to false, if the system finds a new version in the update interval, this will display for administrator the following message:
This link will open the updates page.
You can select the update if it's in available status.
This will display the following message. If you want to update the selected version, you must accept it.
Then, this will generate the following jobs.
Once the update is finished, you can see the new version at the bottom of the page.
How does Flexxible|Update manager work
The solution sets upgrade cycles to multiple rings, which allows switching from quick refresh rings for minor fixes and new functionalities to slow rings for long-support end versions. A set of unattended automatic update processes connects to Flexxible IT repositories and verifies the availability of new versions.
This process is always driven by the active node of the VDIWorkerStructure service, which runs in the orchestrator role (VM) and it'll be in charge of downloading the binary files and completing the update non-distributed tasks.
The process checks if there is a new version once per hour. But it only starts the update process if it is within the update interval. This value may be individually set up to be applied outside the working hours.
When a new version is detected in the repository, it is downloaded (or copied) to a local folder in the orchestrator VM. Then, the update will be performed like this:
1. Update the database scheme:
Any necessary database structure (new views, fields, indexes...) or data update is performed by invoking the DBUpdater.exe in the VDIWorkerStructure. This creates an "Initialize DB" job in the Jobs section in Flexxible|SUITE.
To assure back-compatibility between components on fix updates, new fields shall not be created in the DB.
This job is independent of the one updating Flexxible|SUITE to its new version so that any error at this stage can be quickly detected.
Only after this job has finished without errors the process will continue.
2. Update the web servers binary files
Before replacing any file, an IIS reset shall be run, to avoid any to be blocked and to force any connected users to log off. A backup will be created prior to update any folder for web site or services so that a manual emergency rollback is possible.
Once the binary files are replaced, the users will be able to continue working in Flexxible|SUITE and the update will only affect those launched jobs.
3. Deploy the new version to the services
Next, the rest of the uncompressed files are copied to a shared folder
(\\%FlexxibleResourcesPath%\Administration\Binaries)
so that the service instances are able to detect the new available version. If so, then they backup, update and restart themselves, to begin working in the new version. Their threads begin to be passive and stop processing new requests until the update is completed.
4. Deploy a new version of VDIClient and VDIClientService
As Flexxible|SUITE services, the equipment agents are distributedly updated. But, as they're permission-limited, Flexxible|SUITE backups the current files and copies the binary files to a less restrictive location:
(\\%FlexxibleResourcesPath%\Clients\Installers).
From this point on, as the infrastructure services do, they'll back up, update and restart themselves as soon as they detect a new version.
5. Complete the installation
When there is no working thread left, the service instances launches the VDIServiceUpdater.exe to complete the update by closing the service instance, waiting 4 minutes (to allow finishing copying files) and then copying the new files to the service instance folder and starting it.
Along the update process, the job tracks the process of service instances auto-updates for up to 240 minutes, reporting its status every 15 minutes.
The status is tracked by the ComponentInstance entity, which represents a windows service or web application instance running on a given machine.
The installation will be marked as completed when Flexxible|SUITE detects that all the infrastructure services have been updated yet, except for the VDIWorkerStructure, which is the one responsible for controlling the installation. Then the auto-updating of this service will be launched.
If a service instance is not updated yet after 70 minutes, it will be restarted.
Finally, the list of installed updates will be displayed in the "Updates" section.
The new Flexxible|SUITE version release notes and the new features, improvements, and fixes will be listed on the selected update detail screen.
Rollback procedure
As described in the previous section, Flexxible|SUITE update is performed in several steps. The rollback procedure depends on which step did the error raised at:
- Error at step #1
In this case, the update would only affect the database. Flexxible|SUITE is designed to set the DB in the right status and it should correctly work after that.
It is recommended that the user responsible for this update performs some tests, in order to verify the suite is working as expected (e.g. to navigate to the main screens in the web console and to run a Synchronise infrastructure job) and to provide some feedback to Flexxible IT. This will help the Flexxible IT team to investigate the error on the next day.
In case the verification tests wouldn't pass, the Flexxible|SUITE DB backup, which was performed at the update procedure start point, it should be restored.
- Error at step #2
At this point, the web binary files should be checked out to confirm they've been updated and so, to rollback them to the previous version ones.
The previous ones should be found in a "_backup" folder hosted on the same web server.
Once those binary files are assessed as correct, the "Error at step #1" instructions should be performed.
- Error at step #3
At this step, it's possible the Flexxible|SUITE infrastructure services have already detected the new version and updated themselves to it.
To rollback them, first remove the binary files from the path where those services usually get the new versions:
(\\%FlexxibleResourcesPath%\Administration\Binaries)
Once that new version is not available to update to, the next step would be to perform the rollback of each one of the infrastructure services.
As previously told, all the services shall auto-backup before the update. These binary files are the ones to be used to run the rollback process.
This will be the backup sequence:
- Disable the service to avoid it to be get up by any configured recovery action.
- Stop the service.
- Replace the binary files.
- Enable the service (Automatic delayed)
- Start the service.
Once those binary files are assessed as correct, the "Error at step #2" instructions should be followed out.
- Error at step #4
It is not recommended to rollback at agent level. If the update process fails at this point, rollback should start at step #3.
Always contact Flexxible IT team after a failed update, for them to fix any issue.